[FFmpeg-devel] [PATCH]lavc/mlp_parse: Read wordlength from 0xba streams

Paul B Mahol onemda at gmail.com
Fri Feb 14 13:02:28 EET 2020


On 2/14/20, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> Am Fr., 14. Feb. 2020 um 11:48 Uhr schrieb Hendrik Leppkes
> <h.leppkes at gmail.com>:
>>
>> On Fri, Feb 14, 2020 at 11:45 AM Carl Eugen Hoyos <ceffmpeg at gmail.com>
>> wrote:
>> >
>> > Am Fr., 14. Feb. 2020 um 01:26 Uhr schrieb Hendrik Leppkes
>> > <h.leppkes at gmail.com>:
>> > >
>> > > On Fri, Feb 14, 2020 at 12:29 AM Carl Eugen Hoyos <ceffmpeg at gmail.com>
>> > > wrote:
>> > > >
>> > > > Attached patch allows detecting s16 truehd streams encoded with
>> > > > FFmpeg, only tested with FFmpeg's encoder, I did not look into any
>> > > > specification.
>> > >
>> > > According to Dolbys Bitstream specification this read does not seem
>> > > right. It reads half of a reserved field and 3 single-bit control
>> > > fields - in a structure called "channel meaning", which otherwise only
>> > > includes fields on channel assignment and interpretation, so this
>> > > field being in there seems weird.
>> > > Also, why would they code a literal value, and not a lookup table with
>> > > fewer bits like the 0xbb case does?
>> > >
>> > > Unless we can find an actual real-world sample from a licensed encoder
>> > > that can confirm the presence and accuracy of this field, I'm going to
>> > > assume its not correct. It looks to me like it may be writing a MLP
>> > > (ie. 0xbb) header, and not a TrueHD header - beyond the first
>> > > differences, anyway. The high-level bitstream specification was not
>> > > available when mlpenc.c was initially written.
>> >
>> > Thank you for looking into this!
>> > Is there a link to the high-level bitstream specification?
>> >
>>
>> Its here:
>> https://developer.dolby.com/globalassets/technology/dolby-truehd/dolbytruehdhighlevelbitstreamdescription.pdf
>
> Thank you.
> The way I read this document is that precision is not stored and that we
> need
> a decoder option to force decoding less than 24 bits.

No, your patch is nonsense.

Encoder stores only 24 bit pcm, 16bit pcm is upconverted to 24 bit
inside encoder,
which is far from ideal.


More information about the ffmpeg-devel mailing list