Dark Bars on certain 4k movies

[ph1go]

Hey folks,
I have this strange issue on my Bravia 9 (Android TV), that some 4k movies have "dark bars" inside the movie.
When watching the exact same file on my AppleTV 4K it does not show them.
I think this issue is somehow created on the internal app, because watching the file on the PC does also not show this bars.

I believe this is the issue.
https://github.com/google/ExoPlayer/issues/8803
My understanding is that the issue is how the UI is rendered when the Dolby Vision video is not 3840x2160.  All the Dolby Vision movies I've encountered were still 3840x2160 canvases even though the actual movie was a narrower aspect ratio.  If your movie's canvas is 3840x1600, the Dolby Vision metadata is still 3840x2160 most of the time but the black bars on the bottom and top are baked into the DV metadata.  Whatever Sony is doing does not render the black bars as part of the video and thus compresses the DV metadata vertically, resulting in uneven brightness.

The issue in this thread is absolutely a media issue (specifically a Dolby Vision issue) and not a TV/Jellyfin/etc issue.

The files have been encoded with bad DV RPU cropping values but it's fixable - it's not necessary to strip out the DV. There's a (Windows) tool called DDVT ( https://forum.doom9.org/showthread.php?t=183479 ) that does all the work for you. It uses dovi_tool ( https://github.com/quietvoid/dovi_tool ) under the hood but offers a more convenient way to fix this particular problem (and others).

After downloading the scripts and tools into the same directory (the tools into their own "tools" subdirectory), run DDVT_FILEINFO.cmd <path to bad DV file> in an elevated command prompt. Then, select C to "CHECK RPU CROPPING VALUES" and then S when it inevitably comes back and says "CROPPING VALUES INCORRECT. Press [S] to fix them!".

Make sure there's 2-3x the original file of space on the drive where the bad file resides (it makes a temp dir next to it where it demuxes the video) and, a word of warning, the script outputs the files to the root of the drive from which the script is running so if you're looking in the original media folder, you'll think it hasn't done anything (especially confusing if the media's not on the same drive as the scripts). Then replace the original media, rescan with Jellyfin and voila, you have working DV with no translucent black borders over the video.

[TheDreadPirate]

It is both a media issue AND a device specific issue.

The media issue is that the canvas was shrunk to a size smaller than the DV RPU. Or the HEVC video and RPU were taken from different sources and muxed together.

The device specific issue is that the RPU is scaled to match the canvas. This latter issue doesn't happen on most devices. AFAICT, this only happens on Sony devices.

However, your solution sounds reasonable and plausible if you don't want to get rid of the RPU entirely to convert the video to plain HDR10.

[ph1go]

It is both a media issue AND a device specific issue.

The media issue is that the canvas was shrunk to a size smaller than the DV RPU.  Or the HEVC video and RPU were taken from different sources and muxed together.

The device specific issue is that the RPU is scaled to match the canvas.  This latter issue doesn't happen on most devices.  AFAICT, this only happens on Sony devices.

However, your solution sounds reasonable and plausible if you don't want to get rid of the RPU entirely to convert the video to plain HDR10.

Ok, well it happens on my LG C4 as well. It's only occasionally that I run into it, usually on Blu-ray rips but just recently on a WEB-DL TV show (which prompted me to look the fix up again). The issue only presents itself and needs fixing on the first 3 episodes of the season though, the rest of them are fine, which made me think it was more likely an error made during the encode than anything else. It does look like the DV might've been muxed in from elsewhere, though - the streaming service (Amazon) doesn't seem to offer it from what I can see.

[TheDreadPirate]

Interesting. I've only heard of this issue on Sony with Android TV. I'll keep this in mind.

[theguymadmax]

The issue in this thread is absolutely a media issue (specifically a Dolby Vision issue) and not a TV/Jellyfin/etc issue.

The files have been encoded with bad DV RPU cropping values but it's fixable - it's not necessary to strip out the DV. There's a (Windows) tool called DDVT ( https://forum.doom9.org/showthread.php?t=183479 ) that does all the work for you. It uses dovi_tool ( https://github.com/quietvoid/dovi_tool ) under the hood but offers a more convenient way to fix this particular problem (and others).

After downloading the scripts and tools into the same directory (the tools into their own "tools" subdirectory), run DDVT_FILEINFO.cmd <path to bad DV file> in an elevated command prompt. Then, select C to "CHECK RPU CROPPING VALUES" and then S when it inevitably comes back and says "CROPPING VALUES INCORRECT. Press [S] to fix them!".

Make sure there's 2-3x the original file of space on the drive where the bad file resides (it makes a temp dir next to it where it demuxes the video) and, a word of warning, the script outputs the files to the root of the drive from which the script is running so if you're looking in the original media folder, you'll think it hasn't done anything (especially confusing if the media's not on the same drive as the scripts). Then replace the original media, rescan with Jellyfin and voila, you have working DV with no translucent black borders over the video.

Thanks for sharing this fix! I've used the Dovi scripts before, but I hadn't checked them recently, so I didn't realize they had a fix for the  cropping issue. I've been aware of this problem for a while, and it's not exclusive to Sony. In fact, a user posted about the same issue just last week, and they had a Sharp TV. I have a sample file, and removing the DV layer worked for me, but this solution is much better if you want to preserve the DV metadata.

[farshman]

Hey folks,
I have this strange issue on my Bravia 9 (Android TV), that some 4k movies have "dark bars" inside the movie.
When watching the exact same file on my AppleTV 4K it does not show them.
I think this issue is somehow created on the internal app, because watching the file on the PC does also not show this bars.

I believe this is the issue.
https://github.com/google/ExoPlayer/issues/8803
My understanding is that the issue is how the UI is rendered when the Dolby Vision video is not 3840x2160.  All the Dolby Vision movies I've encountered were still 3840x2160 canvases even though the actual movie was a narrower aspect ratio.  If your movie's canvas is 3840x1600, the Dolby Vision metadata is still 3840x2160 most of the time but the black bars on the bottom and top are baked into the DV metadata.  Whatever Sony is doing does not render the black bars as part of the video and thus compresses the DV metadata vertically, resulting in uneven brightness.

The issue in this thread is absolutely a media issue (specifically a Dolby Vision issue) and not a TV/Jellyfin/etc issue.

The files have been encoded with bad DV RPU cropping values but it's fixable - it's not necessary to strip out the DV. There's a (Windows) tool called DDVT ( https://forum.doom9.org/showthread.php?t=183479 ) that does all the work for you. It uses dovi_tool ( https://github.com/quietvoid/dovi_tool ) under the hood but offers a more convenient way to fix this particular problem (and others).

After downloading the scripts and tools into the same directory (the tools into their own "tools" subdirectory), run DDVT_FILEINFO.cmd <path to bad DV file> in an elevated command prompt. Then, select C to "CHECK RPU CROPPING VALUES" and then S when it inevitably comes back and says "CROPPING VALUES INCORRECT. Press [S] to fix them!".

Make sure there's 2-3x the original file of space on the drive where the bad file resides (it makes a temp dir next to it where it demuxes the video) and, a word of warning, the script outputs the files to the root of the drive from which the script is running so if you're looking in the original media folder, you'll think it hasn't done anything (especially confusing if the media's not on the same drive as the scripts). Then replace the original media, rescan with Jellyfin and voila, you have working DV with no translucent black borders over the video.

Anyway to tell from mediainfo if it has been cropped incorrectly? Or some other way besides DDVT or running it on the TV?

[thorleif]

The issue in this thread is absolutely a media issue (specifically a Dolby Vision issue) and not a TV/Jellyfin/etc issue.

The files have been encoded with bad DV RPU cropping values but it's fixable - it's not necessary to strip out the DV. There's a (Windows) tool called DDVT ( https://forum.doom9.org/showthread.php?t=183479 ) that does all the work for you. It uses dovi_tool ( https://github.com/quietvoid/dovi_tool ) under the hood but offers a more convenient way to fix this particular problem (and others).

After downloading the scripts and tools into the same directory (the tools into their own "tools" subdirectory), run DDVT_FILEINFO.cmd <path to bad DV file> in an elevated command prompt. Then, select C to "CHECK RPU CROPPING VALUES" and then S when it inevitably comes back and says "CROPPING VALUES INCORRECT. Press [S] to fix them!".

Make sure there's 2-3x the original file of space on the drive where the bad file resides (it makes a temp dir next to it where it demuxes the video) and, a word of warning, the script outputs the files to the root of the drive from which the script is running so if you're looking in the original media folder, you'll think it hasn't done anything (especially confusing if the media's not on the same drive as the scripts). Then replace the original media, rescan with Jellyfin and voila, you have working DV with no translucent black borders over the video.

Thank you very much for explaining the fix. Are you aware of any similar fix that works in Linux?