Jump to content

Please support DolbyVision


TurkeyMan

Recommended Posts

TurkeyMan

Hi everyone,

I noticed when I updated server and client recently that FINALLY, transcoding audio no longer causes HDR video to be transcoded at the same time.

This is great, because I've spent the last year manually remuxing every piece of HDR material I own with an additional LG supported EAC3 track. All those DTS-HD MA tracks will automatically transcode now while still playing the video... huzzah!

The other main case where I'm constantly manually remuxing media is for DV content. LG TV's will only play DV content in specific conditions; they are:

1. MP4 container

2. one single audio track in a supported format

3. no bitmap subs (but any number of mov_text streams are fine)

When I transcode DV content, it usually means I have to destroy the source material, since I can't just mux in an additional supported audio track, but I have to remove all unsupported tracks... so I lose the lossless audio track, and also any commentary, etc. Have to choose a single language in multi-language media, etc.

Emby can do anything I can do server side, and in this case, it's leading to the destruction of source media, so it would be really valuable to have this fixed.

I suggest, for the LG TV client, when playing media with DV in the video, it should request that the server transcode to MP4, and the remux-ed stream needs to only include the selected audio track. If it's a supported track, it can be copied in, if it's not, it should transcode to eac3, or maybe even LPCM (why not?). When remixing DV, it's essential that "-strict unofficial" is given to ffmpeg on the command line; without that, the DV metadata gets lost in transit.

Please consider this feature, so that we can stop destroying our source media.

More and more releases are DV these days; I'd even say MOST new releases, so it's pretty much essential.

Cheers!

Link to comment
Share on other sites

TurkeyMan

This isn't a playback issue, is a feature request. There's no bug, it's just not supported.

LG client needs to detect DV content and request the server perform a very specific remux to play it.

What level of flexibility do clients have regarding requests from the server? Can the client drive the remux specifics? Can client give an ffmpeg command line, or does server need specific involvement too?

Link to comment
Share on other sites

TurkeyMan

Oh? When was that introduced? I never saw any mention of it anywhere. I'll check my versions first...

Link to comment
Share on other sites

SamES
11 hours ago, TurkeyMan said:

This isn't a playback issue, is a feature request. There's no bug, it's just not supported.

LG client needs to detect DV content and request the server perform a very specific remux to play it.

What level of flexibility do clients have regarding requests from the server? Can the client drive the remux specifics? Can client give an ffmpeg command line, or does server need specific involvement too?

Unless the video, audio or subs track needs conversion (ie: video exceeds bitrate, TrueHD/ATMOS, DTS, PGS Subs, etc) then the client will DirectPlay.

It's then up to the TV (not the client or server) to detect and play DV.

DirectPlay means exactly that, the TV plays it Directly - no influence by Emby.

Of course, if it tries to DirectPlay and there is an unsupported format or file error (ie: an incompatible DV track) then the client/server will start transcoding to provide something that's playable, but in this case preserving DV might not be possible.

Link to comment
Share on other sites

TurkeyMan

I've tested both cases fairly comprehensively now.

Case 1 - Compatible audio - direct play is used

Case 2 - Audio needs transcode - remux is used

Neither case do what I suggest above, and neither case work. DV needs special-case handling, and it requires remux in both cases.

Direct play just plays HDR10 and DV is ignored unless the source media file is precisely compatible. Remux is required to an MP4 container, and for non-selected audio streams to be stripped out for DV to play on LG tv's.

In the transcoding audio case, remuxing is happening naturally, but also doesn't work because the wrong container format is selected.

Whenever any transcode occurs, it seems to always select HLS. Does DV also work from a HLS stream? Why wouldn't it choose MP4 which is known to work properly?

I can't share server logs from direct-plays, since no transcode occurred, so there's no log to share... that's the most frequent case and the primary issue that needs fixing (virtually all TV releases these days).

The less common (usually bluray content) case where transcoding audio, I've attached a log. This file has DV, but there's no mention of that in the log, so I guess it's probably not considering it when selecting ffmpeg transcode parameters.

Also, very importantly, "-strict unofficial" does not appear on the command line, so the DV metadata will be stripped without it.

ffmpeg-remux-7328effd-f2e8-4e67-8b3a-ec1735b671c4_1.txt

Link to comment
Share on other sites

TurkeyMan

On a tangent, but FWIW, I really wish Emby would show DV, HDR10+, and HLG when presenting media info. It'd be nice if it also showed Atmos aswell next to the audio codec.

Currently, if the content is HDR10, HDR10+, or any DV profile other than 5 with a HDR base layer, it just says HDR10. Dual metadata DV + HDR10+ doesn't make note, and just says HDR10.

If it is HLG (pretty common for British content), or if it is DV profile 5 (with no base layer, colours are wonky if played incorrectly), then it doesn't show HDR10 or any marking at all; it appears as if it's SDR.

Again, this issue above is really critical to solve for DV profile 5 content where the colours are all messed up when the DV metadata is stripped, although profile 5 is not so common and only existed during ~2020-2022, where modern DV favours profile 8 and often comes with dual metadata, including DV profile 8 AND HDR10+.

  • Agree 1
Link to comment
Share on other sites

Quote

I can't share server logs from direct-plays, since no transcode occurred, so there's no log to share... that's the most frequent case and the primary issue that needs fixing (virtually all TV releases these days).

As SamES pointed out, the LG video player handles it automatically. We've seen reports of it not always happening and we think that LG might not be making it available for all third party apps.

Link to comment
Share on other sites

TurkeyMan

You say LG handles what automatically? I've done quite a bit of testing now, it only plays DV under very specific circumstances. Emby needs to remux to help the TV along.

This is en easy fix, I have to do it manually for basically everything recently. But it's really not a good thing to do manually, because it destroys source material, and I don't have unlimited hard drive space to store the fixed material and the original unmolested material both. It can remux on the fly, no need for manual fixing.

Edited by TurkeyMan
Link to comment
Share on other sites

TurkeyMan

Literally any media file that is not EXACTLY:

- MP4 container

- Only one single audio track in AAC or (E)AC3

- Only text subs present

If the media has DV video, and it doesn't meet those exact criteria, Emby should remux.

If it does not meet those exact specs, the remux should:

1. Output MP4

2. Strip all audio tracks except the one the user selected to play; transcoding to EAC3 if required

3. Strip all bitmap subs (leave all mov_text subs in the stream so user can swap quickly)

That logic will cause DV to work reliably on LG TV's. (...and I'm told Samsung may have the same pattern? I can't confirm)

Failing any of those criteria, the TV just bails out and enters its own fallback mode.

Link to comment
Share on other sites

TurkeyMan

I have done extensive combinatorial experiments on all those axiis I mention to find the limits which the TV will play. The specs I describe are the limits I have shown to work on my TV (LG CX generation) reliably. I have a friend with an older C9, and he reports the same configuration limits.

Link to comment
Share on other sites

TurkeyMan

As as above, it would really be ideal if Emby detected and showed in the UI that Dolby Vision is present. Users then have the information they need to understand if their media is playing correctly or not; most people probably don't know that their content is DV, and is not playing correctly.

Link to comment
Share on other sites

2 minutes ago, TurkeyMan said:

As as above, it would really be ideal if Emby detected and showed in the UI that Dolby Vision is present. Users then have the information they need to understand if their media is playing correctly or not; most people probably don't know that their content is DV, and is not playing correctly.

HI, yes this is coming with the 4.8 server reiease.

Link to comment
Share on other sites

TurkeyMan
4 minutes ago, Luke said:

HI, yes this is coming with the 4.8 server reiease.

Perfect! Please while you're at it, also detect and show HDR10+ (ideally showing 2 icons if DV and HDR10+ are both present, which is common these days), and also HLG. Currently, HLG shows nothing at all and appears like SDR material. I'd love to see Atmos too.

Edited by TurkeyMan
Link to comment
Share on other sites

SamES
3 hours ago, TurkeyMan said:

Literally any media file that is not EXACTLY:

- MP4 container

- Only one single audio track in AAC or (E)AC3

- Only text subs present

If the media has DV video, and it doesn't meet those exact criteria, Emby should remux.

If it does not meet those exact specs, the remux should:

1. Output MP4

2. Strip all audio tracks except the one the user selected to play; transcoding to EAC3 if required

3. Strip all bitmap subs (leave all mov_text subs in the stream so user can swap quickly)

That logic will cause DV to work reliably on LG TV's. (...and I'm told Samsung may have the same pattern? I can't confirm)

Failing any of those criteria, the TV just bails out and enters its own fallback mode.

I believe for LG mp4 is a requirement, but multiple audio and sub tracks shouldn’t be an issue, as long as you’re not playing an audio or sub track that needs converting

I would like to see details of a specific file that meets these requirements but doesn’t work. 

Media info, ffmpeg and server logs would be helpful

Link to comment
Share on other sites

TurkeyMan

I assumed what you say, but it's wrong. I tested this thoroughly, many combinations trying to find the TV's limits. If there is 2 audio tracks, even if they are both in a correctly supported codec, it doesn't work.

Server logs don't emit anything for direct-play. I don't think I have copies of my many test subjects. You can create one just as easily as I can... just take any file:

ffmpeg -i has-dv.mkv -c copy -map 0:v -map 0:a:0 -strict unofficial out.mp4

it will work

ffmpeg -i has-dv.mkv -c copy -map 0:v -map 0:a:0 -map 0:a:0 -strict unofficial out.mp4

it will not work

It's hard to make a small test to send you because DV needs to be copied varbatim, so it can't be trimmed down without wrecking the DV data. I can't extract a 1-minute video for testing, DV transcode tests require to remux the whole media for testing. Large files.

Edited by TurkeyMan
Link to comment
Share on other sites

TurkeyMan

Actually, I eat my words... that test above DID work for me just now, but I have produced similar tests before which failed. I'll make some more to isolate the difference. I think the last test like this I made I had one EAC3 stream, and another AC3 stereo stream which was a commentary track. Both supported codecs, but it didn't work. I'll try and reproduce my test a few days ago which failed.

I also tested an episode of Squid Game, which has English and Korean audio streams, it only worked when I removed the Korean stream... I'll try and recreate that test too.

Link to comment
Share on other sites

TurkeyMan

Damn it, I deleted the original mkv of the files I made those >1 audio stream tests with... there's a great example of the dangers of destroying original media!

I'll download it again, probably take overnight.

Link to comment
Share on other sites

rbjtech

I've been though this pain when I got my C7 - back in 2017 (Jeez, 6 years ago.. 🙄) - DV5/7 via MP4 and Audio worked back then - so unless something has changed - it did work.

I however gave up in the end as there was a 100Mbit Ethernet limit (and I didn't want to use wireless) and ARC (as expected) - would not passthough HD Audio.  I think this is still the case even with EARC on later models - but I have not kept myself updated on this.

So I got a Shield Pro (2019) - and have never looked back.

I'll do some more LG testing - as I do have family with LG TV's that may want this one day ..

Link to comment
Share on other sites

TurkeyMan

Okay, I reproduced my failure case, my earlier test matrix didn't test multiple audio streams with same codec, so I missed a success case. Most of my transcode cases start with a DTS-HD MA track (from blurays), so I add a second additional EAC3 track, and the test fails with that configuration.

The rule is: it may contain multiple audio tracks but ALL audio tracks must be in supported formats.

I ran these tests:

Test 1: a:0 eac3 - WORKS

Test 2: a:0 eac3, a:1 eac3 - WORKS

Test 3: a:0 eac3, a:1 flac - WORKS

Test 4: a:0 eac3, a:1 dts - FAIL (default track is supported codec)

Test 5: a:0 dts, a:1 eac3 - FAIL (choose to play second track)

So, the rule is not "one single supported audio track", the rule is "all audio tracks must be supported codec". No DTS/TrueHD tracks, even if they're not being played, and even if they're not track #0.

I noticed Emby reported "recovering from playback error" for the failing tests, so I checked for a log [attached], although it's not interesting, it just means the test failed.

 

So, I think this is the proper set of rules is:

- MP4 container

- All audio tracks must be supported codec (not just the one that's playing)

- Only text subs present

- Must remux with "-strict unofficial" flag to ffmpeg

ffmpeg-directstream-4f4f9038-fe40-4946-b4cb-c35593ea203c_1.txt

Link to comment
Share on other sites

rbjtech

So, again from memory, the LG App has a nasty habit of skipping the Audio track to find a playable track and not reporting this to emby - ie you think it's playing one track, but it's actually playing another.   The AVR display is the only way to see what the internal LG 'player' is actually using ...

Going to do some tests shortly ..

Link to comment
Share on other sites

TurkeyMan

I did one more test: a:0 eac3, a:1 aac, a:2 flac, 23 mov_text subs

It played and worked. So, any unsupported audio streams need to be stripped out during remux, supported streams should be left in (so user can switch streams in realtime). If the user selects to play one of the unsupported streams, it should transcode to eac3 in the remux.

Link to comment
Share on other sites

TurkeyMan
14 minutes ago, rbjtech said:

Going to do some tests shortly ..

You could reproduce my tests above? That'd confirm same behaviour between C7 and CX.

My tests:

Get a TV episode with DV and a single EAC3 stream (most recent shows are like this) as test subject.

ffmpeg -i 'source-media.mkv' -c copy -map 0:v -map 0:a:0 -strict unofficial test-ac3.mp4
ffmpeg -i 'source-media.mkv' -c copy -map 0:v -map 0:a:0 -map 0:a:0 -strict unofficial test-ac3-ac3.mp4
ffmpeg -i 'source-media.mkv' -c copy -c:a:1 flac -map 0:v -map 0:a:0 -map 0:a:0 -strict unofficial test-ac3-flac.mp4
ffmpeg -i 'source-media.mkv' -c copy -c:a:1 dca -map 0:v -map 0:a:0 -map 0:a:0 -strict unofficial -strict -2 test-ac3-dts.mp4
ffmpeg -i 'source-media.mkv' -c copy -c:a:0 dca -map 0:v -map 0:a:0 -map 0:a:0 -strict unofficial -strict -2 test-dts-ac3.mp4
ffmpeg -i 'source-media.mkv' -c copy -c:a:1 aac -c:a:2 flac -map 0:v -map 0:a:0 -map 0:a:0 -map 0:a:0 -map 0:s -strict unofficial test-ac3-aac-flac-subs.mp4

 

Edited by TurkeyMan
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...