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

[Carl Eugen Hoyos]

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.

Carl Eugen