[FFmpeg-cvslog] r18860 - in trunk/libavcodec: ac3dec.c ac3dec_data.c ac3dec_data.h eac3dec.c

[Michael Niedermayer]

On Wed, May 20, 2009 at 06:35:55PM -0400, Justin Ruggles wrote:
> Michael Niedermayer wrote:
> > On Tue, May 19, 2009 at 10:13:34PM -0400, Justin Ruggles wrote:
> >> Michael Niedermayer wrote:
> >>> On Tue, May 19, 2009 at 06:23:38PM -0400, Justin Ruggles wrote:
> >>>> Michael Niedermayer wrote:
> >>>>> On Sun, May 17, 2009 at 08:53:27AM +0200, jbr wrote:
[...]
> 
> > 
> >> The other is in the 6-point IDCT, which splits a single "pre-mantissa"
> >> value into 6 mantissas, one for each of the 6 AC-3 blocks.  The result
> >> is shifted to 24-bit before combining with exponents.
> >>
> > 
> >> The AC-3 spec does not give requirements regarding precision.  The only
> >> clues are in the precision of the tables, and occasionally some vague
> >> wording in the text.
> > 
> > Leaving precission undefined, while surely annoying does not mean that
> > you can use any arbitrary poor precission.
> > More so the listerner will not say: ohh it sounds worse than my 8bit 8khz
> > original soundblaster, but hey the spec has no precission requirement so
> > iam happy with it.
> > 
> > Thus
> > 1. If a spec has a requirement on precission that should be followed
> > 2. Independant of 1. precission should at least be sufficient to not cause
> >    _any_ audible artifacts with high end equipment. (there may be inherit
> >    artifacts in a codec independant of precission used but none should be
> >    added through use of insufficient precission.)
> > 
> > Now as testing for lack of "audible artifacts" in all files is not easy,
> > simply using the required precission of a similar better worded spec like
> > in this case mp3 seems like a good compromise
> > 
> > Also leaving precission unspecified might mean that the author had a
> > float/double based decoder in mind (though of course its bad if this
> > is not explicitly stated)
> > Now if so this doesnt mean that any arbitrary small number of bits is
> > sufficient for a fixed point implementation of such float/double decoder.
> 
> I completely understand the point with regard to comparable functions
> such as the full block MDCT, but as far as I know, MP3 does not have
> anything like this secondary DCT that sort of encodes the frequency of
> the frequency or whatever.

mp3 does have a 2 level transform too ...


>  But given that, I do understand that it
> means it needs more testing since the effects of precision reduction in
> this transform on the audibility of artifacts are not documented publicly.

Testing audibility would require testing with hundreads of widely variing
test samples.
with mp3 i didnt hear a problem with the decoder in CONFIG_MPEGAUDIO_HP=0
until someone (maybe gabu) eons ago send me a mp3 that did produce clearly
audible artifacts in some rather silent part. That is IIRC ...



> 
> >>  For the IDCT, the spec just says, "Any fast
> >> technique may be used to invert the DCT in Enhanced AC-3 decoders."
> > 
> > Yes it says "any fast" not "any approximate"
> > fast may be related to inaccurate in many algorithms but the spec says
> > fast not approximate.
> 
> Yes, I understand the difference.  I was just pointing out that it
> doesn't say anything about the accuracy.
> 
> >>  The
> >> tables for pre-mantissas, which are the input to the IDCT are all
> >> 16-bit.  The output is treated like normal AC-3 mantissas, which are
> >> also only 16-bit.  I didn't see the point of shifting the 16-bit
> >> pre-mantissas up to 24 bits just for the 6-point IDCT.
> > 
> > I think you should read (or experment with) rounding errors and
> > precission as it does not seem you listen to me
> > 
> > Or for the matter of fact you could check how many bits idcts for
> > video uses internally compared to its input and output.
> > or you could try a int16_t mdct and listen to how that sounds (should
> > based on your reasoning sound perfect...)
> 
> Our AC-3 encoder does an int16_t mdct...  But I do get your point.

without checking the source my memory says it scales the input though
to use the whole 16bit even in silent parts, so this may with some luck
not be as bad as the mp3 case ...

> 
> I will change the IDCT back to 24-bit soon and do more testing of
> accuracy, audibility of artifacts, and speed before reconsidering using
> 16-bit.

maybe you could use CONFIG_MPEGAUDIO_HP like mp3 does ?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20090523/12a098d5/attachment.pgp>