[FFmpeg-devel] AAC rtp_parse_packet RFC3640 compliance
Mon Apr 27 13:54:05 CEST 2009
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.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 ;-)
More information about the ffmpeg-devel