On Fri, Feb 14, 2020 at 11:45 AM Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > > Am Fr., 14. Feb. 2020 um 01:26 Uhr schrieb Hendrik Leppkes > <h.lepp...@gmail.com>: > > > > On Fri, Feb 14, 2020 at 12:29 AM Carl Eugen Hoyos <ceffm...@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 - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
