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

Michael Niedermayer michaelni
Mon Jan 25 03:28:48 CET 2010


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.

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.
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

>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?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- 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/833cfcc4/attachment.pgp>



More information about the ffmpeg-devel mailing list