[FFmpeg-devel] [PATCH] [Issue 632] AAC: Decode TNS order zero properly from the bitstream
Fri Sep 12 16:35:05 CEST 2008
2008/9/12 Michael Niedermayer <michaelni at gmx.at>:
> On Fri, Sep 12, 2008 at 11:06:29AM +0100, Robert Swain wrote:
>> 2008/9/12 Alex Converse <alex.converse at gmail.com>:
>> > As per tns_data() from the spec, direction and coef_compression are
>> > not coded if order == 0.
>> Yes, looks fine and correct to me. Michael - do you want me to request
>> your OK for such patches or would you prefer I just apply them if I
>> think they're OK?
> you are maintainer of the code so of course can you apply something if
> you think its ok
OK. :) I tend to air on the side of caution because I don't want to
>> > Even after this, something is still wrong with al04_44 (Issue 632) as
>> > we are only getting 8 bits of conformance.
>> It may be useful to analyse where in the stream the significant
>> differences occur in case it's a few isolated cases spread across the
>> file. I used this technique previously with success. Basically I
>> printed out the channel element types for each channel, found the
>> position of the difference in terms of samples (I used `cmp -l` and
>> calculated from that bearing in mind that the first AAC frame does not
>> get output, but whatever suits you), and then look at the code and the
>> tools used for that channel element to figure out where it's going
> Its also possible to hack both the reference decoder (or some other
> FOSS decoder) and ffmpeg by disabling a specific feature like TNS.
> and then compare how different the output is. If the difference stays
> its likely not TNS if the difference gets smaller it likely is TNS.
> this method can then be used with one tool at a time until the
> problem is found.
> Its not exactly quick but should have a low failure rate and should be
> able to cut down the amount of code which has to be looked through for
> the issue
An interesting approach. I like it.
More information about the ffmpeg-devel