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

Reimar Döffinger Reimar.Doeffinger
Sun Jan 24 22:53:42 CET 2010


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.

> For AC-3, if the partial frame is out of sync, the decoder will
> print/return a frame sync error and skip the partial frame.  If it is
> synced but only partial (e.g. truncated stream) it will decode any
> complete blocks and use use error concealment for the truncated blocks.

I can't really see where the code would check for being in sync?

> I don't know why there would be "annoying sounds" after seeking.  Maybe
> there is data left in the parser buffer?  Do you have a sample I could
> test?  Is this happening with ffplay?

I think I can slightly hear it when wildly seeking around in
http://samples.mplayerhq.hu/A-codecs/AC3/ac3-sound-sample.vob
there's a bit of a blip right after seeking.
And all those
[ac3 @ 0x980c6d0]incomplete frame
[ac3 @ 0x980c6d0]invalid frame size
upon seeking are a bit annoying IMO.



More information about the ffmpeg-devel mailing list