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

Michael Niedermayer michaelni
Mon Jan 25 11:19:57 CET 2010

On Sun, Jan 24, 2010 at 07:22:33PM -0800, Baptiste Coudurier wrote:
> 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 ?

most of the audio parsers can only sync probabilistically
thats because the syncword used can occur in the middle of a frame
so you might have a 1000:1 chance that the first sync will be wrong
droping an additional frame should correct that, alternatively the
parser could try to check the syncword of the next frame as well but
that too is just improving probabiity at the price of higher complexity
and requireing future data, the droping seems easier

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100125/f388930f/attachment.pgp>

More information about the ffmpeg-devel mailing list