[FFmpeg-devel] AAC rtp_parse_packet RFC3640 compliance

Jorge Pedroso jpedroso
Fri Apr 24 14:33:35 CEST 2009


I've come to know that rtpdec.c rtp_parse_packet isn't quite RFC3640  
compliant when handling AAC packets. Namely, rtp_parse_mp4_au instead  
of gathering each AU header it concatenates them into a big one and  
returns only that AU header.

rtp_parse_mp4_au says:
> /* XXX: We handle multiple AU Section as only one (need to fix this  
> for interleaving) In my test, the FAAD decoder does not behave  
> correctly when sending each AU one by one but does when sending the  
> whole as one big packet...*/

OK, this works for FAAD but breaks almost everything else, right?

Moreover, av_read_frame documentation seems to me a bit misguiding  
when saying:
> If the audio frames have a variable size (e.g. MPEG audio), then it  
> contains one frame.
This is true when reading a 3GP file from disk but false when reading  
from the RTP stream. When reading from the RTP stream av_read_frame  
returns the RTP payload minus the AU header(s). Is it safe/realistic  
to assume that a big AU Data Section trimmed from the RTP payload  
packet is a valid AAC audio frame?

For the sake of context, I was feeding Apple's AudioQueue directly  
with the AAC packets. My workaround was to ignore the AVCodecContext's  
codec_id overriding CODEC_ID_AAC with CODEC_ID_NONE so that  
rtp_parse_packet and av_read_frame return the RTP payload as is. Then  
I do the AU parse myself.

Since I have most of the code, should I or do I qualify to submit a  
patch for this?

Thanks for your time.
Jorge Pedroso

More information about the ffmpeg-devel mailing list