[FFmpeg-devel] [PATCH] Ac3/AAC parser: remove incomplete first frames
Sun Jan 24 23:13:53 CET 2010
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'm not against the change, but I'm pretty sure Michael has said on
several occasions that parsers should not discarding anything.
>> 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?
err = parse_frame_header(s);
av_log(avctx, AV_LOG_ERROR, "frame sync error\n");
>> 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
> 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.
It doesn't do that at all with ffplay. The fact that it doesn't give
frame sync errors with mplayer is odd. It means that the decoder is
getting synced but incomplete frames after a seek. To me that suggests
an mplayer issue.
More information about the ffmpeg-devel