[FFmpeg-cvslog] r11379 - trunk/libavcodec/ac3dec.c

Rich Felker dalias
Thu Jan 3 06:06:11 CET 2008


On Wed, Jan 02, 2008 at 11:52:19PM -0500, Justin Ruggles wrote:
> Rich Felker wrote:
> > On Thu, Jan 03, 2008 at 03:26:30AM +0100, jbr wrote:
> >> Author: jbr
> >> Date: Thu Jan  3 03:26:29 2008
> >> New Revision: 11379
> >>
> >> Log:
> >> add crc check to ac3 decoder
> > 
> > What is the performance impact?? I'm strongly against this change,
> > especially the aspect of outputting _nothing_ (and thus breaking a/v
> > sync!) when crc check fails. If crc check fails, the decoder should
> > instead use error concealment heuristics, and crc should not be
> > checked at all when error concealment is disabled.
> 
> I would definitely rather output audio (either error concealment or
> silence) to keep a/v sync.  But the only reliable way to know if the
> frame size and/or number of channels are correct (and both can change
> mid-stream) is to also check the first CRC code.  And if that fails,
> there is no way to know.

Frame size can change mid-stream? I didn't know varying frame sizes
were supported at all, much less mid-stream. I'm pretty sure DVD does
not allow that. (Here by "frame size" I'm assuming you mean the number
of samples it decodes to, as opposed to the compressed size. But both
are constant on all AC3 streams I know of.) Also, I'm pretty sure no
players support changing number of channels or other stream properties
mid-stream...

> As for performance, I don't really know enough about dezicycles to make
> a judgement, but I did a START_TIMER/STOP_TIMER on ac3_decode_frame()
> with and without the crc check on a 5-minute 5.1-channel audio clip.  My
> processor is an AMD64 X2 6000+ if that makes any difference...
> 
> with:    8014687 dezicycles, 8191 runs, 1 skips
> without: 7935784 dezicycles, 8191 runs, 1 skips

I would benchmark the whole decode for 5-minute clip or something,
rather than benchmarking the individual functions.

Rich




More information about the ffmpeg-cvslog mailing list