[FFmpeg-devel] AAC rtp_parse_packet RFC3640 compliance

[Luca Abeni]

Jorge Pedroso wrote:
> On Apr 24, 2009, at 1:55 PM, Luca Abeni wrote:
> [...]
>> rtp_parse_mp4_au() works in a funny way, because it does not returns
>> AAC frames...
> I'm aware of this. What intrigues me is that it doesn't respect that 
> number of frames when filling the au_headers array in RTPPayloadData.

Well, as you noticed, au_headers is used in a strange way... I do not
know why the code is written like this; I only know that the general
idea with libavformat's rtp demuxer is that it does not split the stream
in frames, but relies on an AVCodecParser.


>> It simply returns an integer number of AAC frames, assuming
>> that a "parser" (see libavcodec/aac_ac3_parser.c) will split this in
>> frames later.
> Are you referring to RTPPayloadData's nb_au_headers?

No, I am referring to the AAC parser that is contained in libavcodec.


> Moreover, in order to split, how does the parser know the size of each 
> individual AAC frame if, from what I said above, that information was 
> lost when concatenating each AU-header-size in au_headers[0].size?

Well, I think it can know it by parsing the stream... No?


>> Or... Maybe the problem is that rtp_parse_open() "forgets" to set
>> st->need_parsing = AVSTREAM_PARSE_FULL for the AAC case?
>> Try setting it, and the problem should be fixed.
> Indeed, it does forget. I did tried setting it manually after my 
> av_find_stream_info(), but still av_read_frame() gives me nothing that 
> resembles a valid AAC frame. I include my tests with the multiple 
> approaches attached.

Well, I do not know what to say here... You probably found a bug either
in the RTP demuxer or in the AAC parser.
I am not sure about the impact of this bug (receiving AAC audio from RTP
seems to work fine), but I think patches are welcome as usual ;-)



				Luca