Dolby Vision incorrectly sized enhancement layer

[chrisrosser]

When playing Dolby Vision + HDR (profile 7 or 8 ) content on my LG G3 using Jellyfin with WebOS app I sometimes get an incorrectly sized enhacement layer. Has anyone else hit this issue and found a solution? Many thanks for your help!

[TheDreadPirate]

There are various bugs with our WebOS app when "prefer fMP4" is enabled. You will need to disable that setting, but you will lose HDR (due to transcoding) until we update the WebOS.

[chrisrosser]

I can confirm the issue is present with prefer fMP4 enabled and disabled. This setting doesn't appear to make any difference to this particular problem. The key issue appears to be aspect ratio.

File that works perfectly:
Codec: HEVC
AVC: No
Profile: Main 10
Level: 150
Resolution: 3840x2160
Aspect ratio: 16:9
Anamorphic: No
Interlaced: No
Framerate: 24
Bitrate: 18942 kbps
Bit depth: 10 bit
Video range: HDR
Video range type: DOVIWithHDR10
DV title: DV Profile 8.1 (HDR10)
DV version major: 1
DV version minor: 0
DV profile: 8
DV level: 6
DV rpu preset flag: 1
DV el preset flag: 0
DV bl preset flag: 1
DV bl signal compatibility id: 1
Colour space: bt2020nc
Colour transfer: smpte2084
Colour primaries: bt2020
Pixel format: yuv420p10le
Ref frames: 1

Problem file:
Codec: HEVC
AVC: No
Profile: Main 10
Level: 153
Resolution: 3840x1608
Aspect ratio: 2.40:1 <<<<<< This is the only real difference between these two files.
Anamorphic: No
Interlaced: No
Framerate: 23.976025
Bitrate: 25653 kbps
Bit depth: 10 bit
Video range: HDR
Video range type: DOVIWithHDR10
DV title: DV Profile 8.1 (HDR10)
DV version major: 1
DV version minor: 0
DV profile: 8
DV level: 6
DV rpu preset flag: 1
DV el preset flag: 0
DV bl preset flag: 1
DV bl signal compatibility id: 1
Colour space: bt2020nc
Colour transfer: smpte2084
Colour primaries: bt2020
Pixel format: yuv420p10le
Ref frames: 1

[theguymadmax]

There is a fix for Dolby Vision on webOS in 10.9.8. While I don't think your issue falls within the scope of this PR, I still recommend upgrading if you haven't already done so.

[chrisrosser]

10.9.8 does not fix this issue unfortunately. 

More research has found something interesting. Dolby Vision content can have a different Canvas Size vs Active Image Size.

It appears that jellyfin -ffmpeg may be using the Active Image Size rather than the canvas size to scale the DV metadata.

More info here: https://partnerhelp.netflixstudios.com/h...a-Overview

[TheDreadPirate]

More research has found something interesting. Dolby Vision content can have a different Canvas Size vs Active Image Size.

It appears that jellyfin -ffmpeg may be using the Active Image Size rather than the canvas size to scale the DV metadata.

More info here: https://partnerhelp.netflixstudios.com/h...a-Overview

In my work flow my re-compression script automatically removes black bars.  But I noticed that with HDR content the bars are never removed and I figured it had something to do with the DV metadata including the black bars.  This confirms that.

This was before I started converting DV to HDR10, though.

[chrisrosser]

More research has found something interesting. Dolby Vision content can have a different Canvas Size vs Active Image Size.

It appears that jellyfin -ffmpeg may be using the Active Image Size rather than the canvas size to scale the DV metadata.

More info here: https://partnerhelp.netflixstudios.com/h...a-Overview

In my work flow my re-compression script automatically removes black bars.  But I noticed that with HDR content the bars are never removed and I figured it had something to do with the DV metadata including the black bars.  This confirms that.

This was before I started converting DV to HDR10, though.

Yes it seems like the DV Canvas is always 16:9 regardless of the active area of the image. Who would be the best group to chase this bug down? I've posted in the Jellyfin-web and Jellyfin-webos repo. Should I also post a bug in the main Jellyfin repo?

[TheDreadPirate]

My understanding is that Jellyfin in WebOS, in a direct play scenario, passes the video to LG's internal player unmodified. Including the enhancement layer. So its not really a Jellyfin problem, per se. So you'd have to report it to LG directly (good luck with that).

Even then, I'm honestly not sure if this is a problem vs working as intended with a "bad" source file. You could try adding back black bars with ffmpeg, but that requires re-encoding.

https://stackoverflow.com/questions/4667...s-to-video

Or get a different source file without the black bars removed.

[chrisrosser]

My understanding is that Jellyfin in WebOS, in a direct play scenario, passes the video to LG's internal player unmodified.  Including the enhancement layer.  So its not really a Jellyfin problem, per se.  So you'd have to report it to LG directly (good luck with that).

Even then, I'm honestly not sure if this is a problem vs working as intended with a "bad" source file.  You could try adding back black bars with ffmpeg, but that requires re-encoding.

https://stackoverflow.com/questions/4667...s-to-video

Or get a different source file without the black bars removed.

There is a remux to .ts to play on LG with HDR. I don't think the source file is bad. It plays fine on other hardware. Perhaps the issue is in the remuxing?