When transcoding audio, Dolby Vision is lost

Server Version#: 1.43.1
Player Version#: 5.94.1

WebOS: 33.22.85

MKV files which have DV+HDR can now successfully play DV instead of falling back to HDR, since recent LG webOS updates. However, if the audio has to be transcoded, while the video is direct streaming, it doesn’t activate DV and instead will fallback to HDR.

This can be seen in a single file which has two audio tracks, e.g. TrueHD and DDP. With DDP selected, DV successfully activates. With TrueHD, audio transcoding is required and DV does not activate.

Because the video is direct streamed, I would hope that DV could be retained. Is this a bug and/or area that could be enhanced, or a fundamental issue that will never be solved?

Here are a couple of other threads about the same thing that were just ignored and got auto-locked. Please acknowledge the issue

https://forums.plex.tv/t/mkv-dolby-vision-playback-falls-back-to-hdr-when-audio-transcode-is-happening-on-webos25/934509

I’ve tested this, and yes LG does not like TrueHD 7.1 audio tracks. Sometimes the tv will force the HDR video and try to decode the 7.1 audio, and the stream will buffer.

So with a 7.1 audio track, the TV will take the HDR stream and poorly decode the 7.1 audio

If you mux in an 5.1 audio track and select it, DV works fine and the sound is fine, everything direct plays.

A proper fix for the LG app would be to request the plex server to transcode the 7.1 to 5.1 and direct play the video. There currently is no way that I can see to force this to happen. Mux in a 5.1 or find a video that has dual audio tracks already and choose 5.1.

I am fine with the audio being transcoded as not being able to play TrueHD on native TV apps is a known and well documented limitation for all TVs. I’m also fine with the transcoding method, in my experience it transcodes to 1mb/s DD+ which is transparent to my ears.

Once the audio has to be transcoded, the whole package has to be put together again in a new container, that’s why the video will only ever “Direct Stream” rather than “Direct Play” in this scenario.

I know that detection of Dolby Vision can be container dependent, for example, historically on LG, Direct Play of an mkv container with Dolby Vision would never activate Dolby Vision. In recent months, LG have fixed this specific issue, so mkv Dolby Vision is possible, but I mention this just because container-specific issues with Dolby Vision are a known thing, and I suspect the container Plex is using to repackage the transcoded audio and original video suffers the same problem.

I would really appreciate some acknowledgement of the issue from a Plex Employee. @BigWheel seems quite responsive from recent experience!

The problem is likely licensing. Plex is apparently permitted to pass Dolby Vision through to the client, but is not allowed to use unlicensed code for transcoding.

To be clear, it is passing the video through without transcoding. It’s Direct Stream. My suspicion is it’s more to do with how they are packaging the Direct Stream with the audio on the fly and compatibility issues with the client, rather than licensing, but it’d be good to get a developer’s insight.