[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