Dolby Vision now possible through MP4 Mux.

[box4m]

Thanks for the hard work as always, yusecope! A quick question about mode 2 when used with FEL titles. Is the data in the enhancement layer merged somehow into the base layer, or is it simply discarded? And regardless, if the resulting BL+RPU track is meant to be profile 5, is there also an IPT color space conversion being done? If not, then wouldn't it produce some color oddities during playback when forced to a profile 5 file in tsmuxer?

When "mode 2" is used to process FEL titles, the Enhancement Layer is completely removed.
The tool also does not perform any color space conversion.
As I said in the past (referring to the files obtained in "mode 2"):

...the Base Layer is non-standard (it has a different color space than the IPTPQc2/IPT one) as extracted from a Bluray disk.
It should appear better than an HDR stream (since metadata is dynamic and non-static) but will not reach its maximum splendor due to the lack of data contained in the EL layer.
The lack of this information, however, could lead, in some cases, to evident chromatic aberrations.

Not surprisingly, in my tool, "mode 1" is the default.
Owners of devices capable of playing only movies with dvhe.05 profile, however, would have had DVDFab as their only choice.
It seemed right to me to offer them a free alternative.

"The Enhancement Layer is completely removed" - does this mean DV is removed?

edit: well stupid question but what does it mean?

[yusesope]

"The Enhancement Layer is completely removed" - does this mean DV is removed?

edit: well stupid question but what does it mean?

profiles 5 and 8 are BL + RPU (there is no EL).
So my tool (in mode 2) removes EL in case the input source is of type BL + EL + RPU.

[Arbigator]

That process looks fine except I never demux the audio file to begin with, just the video tracks.

https://drive.google.com/file/d/1q5v4-J ... gPqCD/view

That's the version of tsmuxer that most have been using. For the last step, just load in yusecope's resulting HEVC file and then the original mpls file, uncheck the two original hevc tracks, and mux. If this doesnt work, you might want to also try the newer mkv method.

So I tried again with that version of tsMuxer, and it didn't work... Then I thought to try it again but on a different computer, and it works without any issues! I don't know what it is that it doesn't like about the first computer, both are Intel, one is a 7th gen i5, the other a 10th gen i5. I hate computers... Thanks for all your help!

[stephon1024]

First off, yusesope, thanks so much for this tool!!!

Is there anyway to use handbrake to compress the base file before using your special tool?

I've been doing it in handbrake then using Tsmuxer to extract the hevc file - but when I pop it in the tool it only starts analyzing and building the base layer and ignores the enhancement layer...

Wondering if I'm missing something. For all intents and purposes the handbraked version of my base layer should be identical to the larger one (except for size obviously) it's HEVC Main 10 level 5.1... etc. Even used handbrake to put in the appropriate HDR metadata tags, etc. This is what the tool looks like when it's done:

Capture.JPG (63.14 KiB) Viewed 20724 times

Like I said before yusesope, you're the best! Such a cool tool you created...

[Woodstock]

I've been doing it in handbrake then using Tsmuxer to extract the hevc file - but when I pop it in the tool it only starts analyzing and building the base layer and ignores the enhancement layer...

Handbrake does not handle HDR, let alone DV, so you lose the color mapping.

Also, if you compress the main video track, the hints in the DV track would no longer be valid.

[stephon1024]

I've been doing it in handbrake then using Tsmuxer to extract the hevc file - but when I pop it in the tool it only starts analyzing and building the base layer and ignores the enhancement layer...

Handbrake does not handle HDR, let alone DV, so you lose the color mapping.

Also, if you compress the main video track, the hints in the DV track would no longer be valid.

Hey Woodstock, the EL i've already separated from the MakeMKV backup. So I had both streams, base and enhancement - are you saying that even though I have a base layer and a EL, there is still DV info on that base layer? That would make sense if true, but I was under the impression that there isn't anything special about the base layer, it's the EL where all the DV info lives. So shouldn't I be able to compress the base layer without removing the DV info? Then just use yusesope's tool to add the DV EL back?

It was an attempt... The massive BL_EL_RPU file that I created plays on my LG C9 but it stutters like mad making me think it's too much for the SOC on the C9 to handle. I get the DV tag showing up in the upper right and it looks amazing... just doesn't play right. This is my attempt to lower the overall bitrate of the stream

[Woodstock]

I cannot give you specifics because I've been ignoring most of the Dolby and HDR stuff (not important to me). But the "enhancement layer" would be applied against the base layer... and running the base layer through a non-HDR tool like handbrake is going to change the what the enhancement applies to.

At the very least, whatever you use to reduce the size must pass through the original HDR data and maintain the same frame rate. And I do know that handbrake can't do that for you.

[MartyMcNuts]

I've been doing it in handbrake then using Tsmuxer to extract the hevc file - but when I pop it in the tool it only starts analyzing and building the base layer and ignores the enhancement layer...

Handbrake does not handle HDR, let alone DV, so you lose the color mapping.

Also, if you compress the main video track, the hints in the DV track would no longer be valid.

Hey Woodstock, the EL i've already separated from the MakeMKV backup. So I had both streams, base and enhancement - are you saying that even though I have a base layer and a EL, there is still DV info on that base layer? That would make sense if true, but I was under the impression that there isn't anything special about the base layer, it's the EL where all the DV info lives. So shouldn't I be able to compress the base layer without removing the DV info? Then just use yusesope's tool to add the DV EL back?

It was an attempt... The massive BL_EL_RPU file that I created plays on my LG C9 but it stutters like mad making me think it's too much for the SOC on the C9 to handle. I get the DV tag showing up in the upper right and it looks amazing... just doesn't play right. This is my attempt to lower the overall bitrate of the stream

I have previously used NVencC64 command line to compress the base layer of Gemini Man and it still worked in yusesope's tool. Once muxed to ts file, mediainfo shows it as DV. (I do not have a Dolby Vision TV so could not test the files) although I did provide some sample links. I'm not sure if I used the right tsmuxer version but you could test these and see if they work for you before going any further.

See https://www.makemkv.com/forum/viewtopic ... 145#p87824

If they work for you and you want to give it a try, let me know and I can give you the nvenc command.

[stephon1024]

Handbrake does not handle HDR, let alone DV, so you lose the color mapping.

Also, if you compress the main video track, the hints in the DV track would no longer be valid.

Hey Woodstock, the EL i've already separated from the MakeMKV backup. So I had both streams, base and enhancement - are you saying that even though I have a base layer and a EL, there is still DV info on that base layer? That would make sense if true, but I was under the impression that there isn't anything special about the base layer, it's the EL where all the DV info lives. So shouldn't I be able to compress the base layer without removing the DV info? Then just use yusesope's tool to add the DV EL back?

It was an attempt... The massive BL_EL_RPU file that I created plays on my LG C9 but it stutters like mad making me think it's too much for the SOC on the C9 to handle. I get the DV tag showing up in the upper right and it looks amazing... just doesn't play right. This is my attempt to lower the overall bitrate of the stream

I have previously used NVencC64 command line to compress the base layer of Gemini Man and it still worked in yusesope's tool. Once muxed to ts file, mediainfo shows it as DV. (I do not have a Dolby Vision TV so could not test the files) although I did provide some sample links. I'm not sure if I used the right tsmuxer version but you could test these and see if they work for you before going any further.

See https://www.makemkv.com/forum/viewtopic ... 145#p87824

If they work for you and you want to give it a try, let me know and I can give you the nvenc command.

Marty, thank you so much for the response man! I didn't see that thread you posted, but it's exactly what I'm experiencing!

I'm going to give your test files a run on my LG C9, if they work and report back DV... You're a savior. I'll check out NVencC64 too... I'm guessing I'm just losing some DV metadata in Handbrake when I'm compressing. It's funny, handbrake nightly transfers HDR10 data just fine (if you use the right "advanced options" settings...) but completely erases DV data in the base layer...

I will report back to you as soon as I test the files you posted, it's late and I'm probably already in trouble with the wife...

Thanks again!

[yusesope]

Is there anyway to use handbrake to compress the base file before using your special tool?

For this type of experiment, I recommend using the 0.0.4 alfa version of my tool.

You're right when you say "it's the EL where all the DV info lives" but keep in mind that the info contained in EL are "calibrated" on those inside BL.
If you re-encode BL, logically, you should also modify EL.
No one has yet reversed the algorithm needed to generate new RPU metadata (and, in the case of FEL layers, new frames).

Imagine a guy (BL layer) with a weight of 180Kg who, after following a diet, reaches a body weight of 80Kg.
His clothes (EL layer) are now unusable but the clothing stores (the algorithm) are closed due to the quarantine.
The guy will be forced to use his old clothes.
He will always have clothes on but his style will be a little "sui generis".

[PapitaHD]

Is there anyway to use handbrake to compress the base file before using your special tool?

For this type of experiment, I recommend using the 0.0.4 alfa version of my tool.

You're right when you say "it's the EL where all the DV info lives" but keep in mind that the info contained in EL are "calibrated" on those inside BL.
If you re-encode BL, logically, you should also modify EL.
No one has yet reversed the algorithm needed to generate new RPU metadata (and, in the case of FEL layers, new frames).

Imagine a guy (BL layer) with a weight of 180Kg who, after following a diet, reaches a body weight of 80Kg.
His clothes (EL layer) are now unusable but the clothing stores (the algorithm) are closed due to the quarantine.
The guy will be forced to use his old clothes.
He will always have clothes on but his style will be a little "sui generis".

I've experimented a lot, re-encoding the BL layer with staxrip/x265 and 0.0.4alfa always merged it with EL without any problem. Also I have an m9702 so I can just mux the re-encoded BL and EL into full UHD BDVM structure (with tsMuxeR) and DV works. I spent hours by testing the results (re-encoded BL+EL), comparing them scene by scene to the HDR10 base layer and also to the full untouched UHD BluRay on my LG C8 Oled and I really beleive this method works perfectly. I've never noticed any difference between the files with re-encoded BL and the full UHD BluRays, but the differences were pretty significant comparing them to the untouched HDR10-base layer. I used the following movies for my tests: Aquaman, The Meg, Fantastic Beasts 2, Midway, Game of Thrones S08E03.
Using the right x265 settings, only the bitrate will be lower but everything else (including the HDR10 metadata) will be the same as in the original BL so I don't see why wouldn't it work.

[yusesope]

Using the right x265 settings, only the bitrate will be lower but everything else (including the HDR10 metadata) will be the same as in the original BL so I don't see why wouldn't it work.

Because (lowering the bitrate) you reduce the amount of information inside BL.
EL aims to improve the performance of BL but if that information that needed to be improved is no longer there, there may be a risk of producing artifacts.

I'm not saying that this method doesn't work but I'm sure that the magic machine built by Dolby would return different ELs and RPUs using files with different bitrates.

Unfortunately, I don't have a screen compatible with Dolby Vision technology and I can express myself only by looking at the sequences of 0 and 1.

[PapitaHD]

Using the right x265 settings, only the bitrate will be lower but everything else (including the HDR10 metadata) will be the same as in the original BL so I don't see why wouldn't it work.

Because (lowering the bitrate) you reduce the amount of information inside BL.
EL aims to improve the performance of BL but if that information that needed to be improved is no longer there, there may be a risk of producing artifacts.

I'm not saying that this method doesn't work but I'm sure that the magic machine built by Dolby would return different ELs and RPUs using files with different bitrates.

Unfortunately, I don't have a screen compatible with Dolby Vision technology and I can express myself only by looking at the sequences of 0 and 1.

That all sounds logical, but I watched about 20 titles from start to finish all with re-encoded BLs and I've never seen any artifacts. And I used one of the best player+screen (screen was professionally calibrated) combos that is available for DV-testing purposes.

[yusesope]

That all sounds logical, but I watched about 20 titles from start to finish all with re-encoded BLs and I've never seen any artifacts. And I used one of the best player+screen (screen was professionally calibrated) combos that is available for DV-testing purposes.

I am sincerely happy to read what you write.

However, if someone asks me, I don't have the data to be able to certify the validity of this method.

It would be interesting to know the values ​​you use when encoding BL.
And it would be even more interesting to find out what the minimum bitrate value is before some artifacts appear (compared to the original bitrate).

[PapitaHD]

That all sounds logical, but I watched about 20 titles from start to finish all with re-encoded BLs and I've never seen any artifacts. And I used one of the best player+screen (screen was professionally calibrated) combos that is available for DV-testing purposes.

I am sincerely happy to read what you write.

However, if someone asks me, I don't have the data to be able to certify the validity of this method.

It would be interesting to know the values ​​you use when encoding BL.
And it would be even more interesting to find out what the minimum bitrate value is before some artifacts appear (compared to the original bitrate).

I always use crf 14-18, which generates variable bitrate. For newer movies that were recorded with digital cameras and have completely smooth picture I usually lower the bitrate to 40-60% of the original, but for grainy stuff (older movies recorded on film) I never go below 65%. Besides that, I mostly use default "slow preset" settings with a few changes (deblock -3:-3, no-sao, no-open-gop, bframes 8 ).