[FFmpeg-devel] [PATCH] Ac3/AAC parser: remove incomplete first frames

Baptiste Coudurier baptiste.coudurier
Mon Jan 25 04:22:33 CET 2010

On 1/24/10 6:28 PM, Michael Niedermayer wrote:
> On Sun, Jan 24, 2010 at 02:25:21PM -0800, Baptiste Coudurier wrote:
>> On 1/24/10 1:53 PM, Reimar D?ffinger wrote:
>>> On Sun, Jan 24, 2010 at 04:43:51PM -0500, Justin Ruggles wrote:
>>>> Reimar D?ffinger wrote:
>>>>> this is what causes decode errors and annoying sounds after seeking.
>>>>> The following patch has one annoyance: if there is a frame starting
>>>>> right at position 0 it will still return a 0-sized frame initially
>>>>> (and claim to have consumed 0 bytes).
>>>>> But now that I can say for sure that the problem is there maybe
>>>>> someone will fix it properly (or I'll threaten to apply this).
>>>> I thought that parsers are not supposed to discard anything.  The AC-3
>>>> parser used to discard partial frames, but it was changed to send them
>>>> to the decoder.
>>> I think it should discard as much as necessary so that a arbitrarily
>>> cut valid file will not cause errors. But I am biased.
>> I agree with this as well, and it's also necessary when stream copying. You
>> don't want partial frames in the output. That is I'm biased as well.
>> I believe a PARSER_FLAG_OUTPUT_PARTIAL_FRAMES can be introduced and set by
>> the user application if partial frames are not wanted, this applies to all
>> parsers (mp3, mpeg1/2, h264).
>> Then user application should set AVFMT_FLAG_OUTPUT_PARTIAL_FRAMES in
>> AVFormatContext->flags which will set PARSER_FLAG_OUTPUT_PARTIAL_FRAMES in
>> return.
>> Comments and flags name suggestions very welcome.
> Our raw/mpeg seeking code is less than ideal currently
> What it should do is search for the proper pos prior to all the needed
> keyframes + an extra frame or 2 prior to the keyframe for parser
> synchronization.
> Once it found that it should seek there and drop all frames prior to
> the synchronization point / keyframe in each stream.

I'm working on this, for index building and actually the parsers for at 
least mpegaudio and mpegvideo works reliably if you drop the first bytes 
from the packet returned by the mpeg ps/ts demuxers.

Mechanism is:
1) Seek to the ps or ts packet.
2) Call read_packet
3) Discard first bytes from the returned packet
4) Call the parser

> About the flag, iam not sure what the flag should do exactly?
> In some parsers we know for certain when we have the true begin of
> a frame in a truncated stream.
> In some parsers we only know with increasing propability that we
> have synched and return valid frames now.

Do you know which ones does not know and why ?

> I think a solution outside of the parsers that seeks farther to
> the left by a few frames and then throws the parser output away
> would be better than individual parsers trying to apply some
> droping based on guesswork. That is for the parsers that dont
> know with certainity when they have synchronized.
>  From the users point of view things should look like:
> * after seeking there must be no patial frames at the begin.
> * the very first frame of a stream if its partial should be marked as such
>    maybe a flag in AVPacket.flags

This seems a good idea to mark the frame as partial if these partial 
frames are outputted.

>  From the parser point of view IMHO:
> the parser should not discard parts of the stream but rather inform the
> caller if it is likely partial or not (if somone wants this information)
> If thats insufficient iam not opposed to add a flag to change behavior?

Well, you can mark them and output them, or you can simply discard them 
internally to simplify the user application. The latter is easier 
obviously. The flag would be used to change the behavior.

Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org

More information about the ffmpeg-devel mailing list