Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Detect DTS-HD in Matroska #6225

Open
andrewlewis opened this issue Jul 25, 2019 · 5 comments
Open

Detect DTS-HD in Matroska #6225

andrewlewis opened this issue Jul 25, 2019 · 5 comments

Comments

@andrewlewis
Copy link
Collaborator

[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
Copy link

cncb-gh commented May 28, 2021

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
Copy link
Collaborator Author

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

@moneytoo
Copy link
Contributor

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
Copy link
Contributor

moneytoo commented Aug 9, 2021

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
Copy link

cncb-gh commented Aug 16, 2022

Any progress here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants