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

Justin Ruggles justinruggles
Thu Jan 3 12:34:47 CET 2008

Rich Felker wrote:
> 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...

The frame (byte) size can change, and it is still perfectly valid AC3.
I don't know specifically if it is supported on DVD though.  I maintain
an AC3 encoder which can output VBR, and in about 2 years, I've only had
1 software decoder reported as not being able to handle it.

As for number of samples, it cannot change in AC3, but it can change in
E-AC3, which will hopefully soon become part of the same decoder.  There
is an eventual way around this though.  Since E-AC3 is meant to be
fairly easily convertable to regular AC3, the frames which have less
than six blocks are designed to have the option of grouping them
together as a "frame set" having 6 blocks (1536 samples).  It wouldn't
be that hard to make the parser do that.

And as for channels, it can, and does, change midstream.  For example,
in television broadcasts.  I'll take Michael's advice on when and when
not to trust the header info.

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

Ok. I'll do that.


More information about the ffmpeg-cvslog mailing list