[FFmpeg-devel] TrueHD decoder bug or something else is wrong
Sun Jul 19 20:14:25 CEST 2009
On Sun, Jul 19, 2009 at 7:44 PM, Ramiro Polla<ramiro.polla at gmail.com> wrote:
> On Sun, Jul 19, 2009 at 12:52 PM, Konstantin
> Dimitrov<kosio.dimitrov at gmail.com> wrote:
>> i have 3 very small TrueHD samples and the raw PCM (stereo, 16bit,
>> 48kHz) sources from which they are created (taken from Blu-ray disc),
>> you can find them here:
>> http://rapidshare.com/files/257596582/thd_samples.tar.bz2.html (size: 144Kb)
> Please don't use rapidshare. Follow http://ffmpeg.org/bugreports.html
> and upload the files to our FTP.
i renamed the files with more descriptive names and uploaded them to
the FTP: /MPlayer/incoming/thd_samples_lossless_check_failed
>> and the files are as follows:
>> sample0[1-3]_stereo_16bit_48khz.thd : the TrueHD sample
>> sample0[1-3]_stereo_16bit_48khz.pcm : raw PCM source - both Left and
>> Right channel
>> sample0[1-3]_stereo_16bit_48khz_left.pcm : raw PCM source - Left channel only
>> sample0[1-3]_stereo_16bit_48khz_right.pcm : raw PCM source - Right channel only
>> for example when i use FFmpeg version SVN-r19371 with
>> sample02_stereo_16bit_48khz.thd i get:
>> [truehd @ 0xf92870]Lossless check failed - expected 92, calculated bf.
>> and as a result Left channel is decoded byte-by-byte identical with
>> the source, but there are some different bytes in the Right channel
>> compared to the source.
>> the problem with other two samples is similar, but with them both
>> channels are decoded not byte-by-byte identical with the source and
>> there are several different bytes.
>> so, as the subject says, does some bug in the TrueHD decoder cause the
>> problem or something else is wrong like corrupted TrueHD stream?
> What program did you use to create the TrueHD stream?
they are from Blu-ray disc that has the same audio stream encoded in
DTS-HD MA and TrueHD.
i decoded bit-perfectly DTS-HD MA stream with eac3to + arcsoft and
then the TrueHD stream with FFmpeg version SVN-r19371. however, FFmpeg
version SVN-r19371 reported:
[truehd @ 0xf92870]Lossless check failed - expected fd, calculated e0.
[truehd @ 0xf92870]Lossless check failed - expected 92, calculated bf.
[truehd @ 0xf92870]Lossless check failed - expected 06, calculated 0d.
and the 2 files - the one produced by decoding the DTS-HD MA stream
and the one produced by decoding the TrueHD stream are different on 3
small places (only several bytes difference) - exactly where the
"Lossless check failed" errors is reported.
then i spent some time to cut the 3 places from TrueHD stream which
caused the "Lossless check failed" error and that is how sample*.thd
files were created - they are very short and contain only the
4 bytes F8726FBA (TrueHD sync word) data01
4 bytes F8726FBA (TrueHD sync word) data02
i.e. two consecutive TrueHD "frames" (i don't know if "frame" is the
respectively, *.pcm files were created with cutting the corresponding
part from the PCM stream produced by DTS-HD MA stream decoded with
eac3to + arcsoft.
> What does an official TrueHD decoder produce?
unfortunately, even eac3to can't make Nero TrueHD decoder to work
(bit-perfectly decode) with TrueHD 2.0 channels stream. so, there is
no way how to check the output produced by official TrueHD decoder -
Nero TrueHD decoder is the only one available that i'm aware of and it
can't decode bit-perfectly TrueHD 2.0 channels stream.
> Ramiro Polla
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
More information about the ffmpeg-devel