[FFmpeg-devel] [PATCH] E-AC-3 spectral extension
Benjamin Larsson
banan
Tue Jun 2 10:08:30 CEST 2009
Justin Ruggles wrote:
> Benjamin Larsson wrote:
>
>> Michael Niedermayer wrote:
>>
>>> On Sat, May 30, 2009 at 11:43:12PM -0400, Justin Ruggles wrote:
>>>
>>>
>>>> Michael Niedermayer wrote:
>>>>
>>>>
>>>>> On Sun, May 17, 2009 at 02:23:34PM -0400, Justin Ruggles wrote:
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I was recently made aware that some French TV station(s) will soon (if
>>>>>> not already) start using E-AC-3 streams in their broadcasts which
>>>>>> utilize spectral extension. I was also given some samples (thanks j-b
>>>>>> and Anthony), which I uploaded to mphq:
>>>>>> http://samples.mplayerhq.hu/A-codecs/AC3/eac3/csi_miami_*
>>>>>>
>>>>>> So I decided to revisit my SPX patch. The previous version was done
>>>>>> with all integer arithmetic, but it turns out that it's really not
>>>>>> accurate enough for spectal extension processing. The resulting
>>>>>> decoded
>>>>>> output had a max bandwidth of about 2kHz less when using 24-bit fixed
>>>>>> point vs. floating point, and was only slightly higher than without
>>>>>> any
>>>>>> SPX processing at all. Making just the square roots floating point
>>>>>> raised the bandwidth about 1kHz, and making the rest (noise/signal
>>>>>> scaling, spx coords, and notch filters) floating point added about
>>>>>> another 1kHz.
>>>>>>
>>>>>> I was able to compare the output to Nero's E-AC-3 decoder (thanks
>>>>>> madshi), and the results are very close considering that AC-3 uses
>>>>>> random noise for zero-bit mantissas:
>>>>>> stddev: 131.16 PSNR: 53.96
>>>>>>
>>>>>>
>>>>> i wouldnt call 131.16 close
>>>>>
>>>>>
>>>> Well, considering I don't know how the Nero decoder differs, it's not
>>>> bad. I don't know how the Nero decoder ends up with higher bandwidth
>>>> than it should, it very likely uses a different random noise generator,
>>>> and it could do dithering in the float-to-int16 conversion.
>>>>
>>>>
>>> dither in float2int might account for ~1.0 stdev maybe but we are 2
>>> magnitudes above that.
>>>
>>> about the PRNG, well just decode a AC3 with 2 different PRNGS and compare
>>> by how much they differ
>>>
>>> also you can take neros output and ours and create a wav file with the
>>> sample wise differences.
>>> looking at that / listening to it might provide a hint about what is that
>>> differs.
>>>
>>>
>> My guess is a sample delay. I know Siarhei wrote some patch for
>> tiny_psnr to calculate that.
>>
>
> hmmm, looks like you were right... off by 1. After resyncing, this is
> the result:
> stddev: 19.75 PSNR: 70.41 bytes: 3998720/ 3999744
>
> -Justin
>
A PSNR of 70 is quite good from what I remember.
MvH
Benjamin Larsson
More information about the ffmpeg-devel
mailing list