Detect DTS-HD in Matroska

[andrewlewis]

[REQUIRED] Use case description

Support DTS-HD passthrough with audio contained in the Matroska container. See #2147 for more context.

Proposed solution

As the container does not explicitly signal DTS-HD vs DTS, we need to inspect the first audio access unit to determine if the audio is in DTS-HD format. See #2147 (comment) for more details.

Alternatives considered

We could add a flag to allow apps to force the extractor to advertise DTS-HD instead of DTS, but it seems preferable to have the extractor determine the media type correctly based on the media, without external information.

[cncb-gh]

Does this change in 2.14.0 have anything to do with this?

Allow fall back from DTS-HD to DTS when playing via passthrough.

[andrewlewis]

292700e doesn't directly address this (MatroskaExtractor still doesn't create a DTS-HD track).

[moneytoo]

The remaining piece to submit this workaround would be having a way to identify that the track is DTS-HD by looking at the start of the first sample. If someone on this thread knows what's needed to distinguish the two formats based on one access unit, please leave a comment and we can get this fixed.

Seems like this is the magic other tools use to detect HD.

FFmpeg:

#define DCA_HD_MARKER     0x64582025

mp4parser:

sync == 0x64582025 // DTS_SYNCWORD_SUBSTREAM

[moneytoo]

General DTS-HD detection is really only about presence of DTS extension substream sync word (0x64582025). We need to have access to up to 16383 + 4 bytes of data (max frame size + sync word of the second frame). We already have DtsUtil.getDtsFrameSize() helper for navigation to that second frame.

I'm already doing that in MatroskaExtractor.writeSampleData() to update mime type using track.output.format(). Is there any other/better place for detection? While the bitstream output is properly marked as DTS-HD and played correctly, the track details in track selectors are not updated.

I'm receiving feedback that this solution works properly for users with various DTS-HD content (Master Audio, High Resolution Audio). (I would send a PR but cause I'm only a hobby dev, my patch is really sloppy.)

However when using this, I encountered an issue resulting in no audio playback at all. Somehow this doesn't work when I use Geniatech ATV-598Max (somewhat obscure, but Google certified Android TV 7.1 device) and ONKYO TX-NR509. Setting DTS-HD mime type break playback while DTS mime type works. However VLC can output playable DTS-HD on the same hardware just fine. (I will do more testing when I will have access to different box) Could this be because VLC possibly uses IEC 61937 instead (just guessing)?

[cncb-gh]

Any progress here?

[RyuzakiKK]

@moneytoo I suppose the patch you were talking about is androidx/media@e3f9625 ?

Would you mind opening a PR about it? I confirm that it allows my system (Nvidia Shield 2019 + Samsung soundbar) to correctly detect DTS-HD. Even if your patch still needs to be cleaned up, having it in a PR is usually the best way to receive feedback on the design and suggestions on improvements.

[moneytoo]

@RyuzakiKK Yes, that's the one. I mostly reused some already circulating patch and I may not be aware of all the format internals. However, as I no longer have any TV device or receiver so I don't dare to do anything on this PR as I cannot test anything.