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.
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!shawnc22 wrote: ↑Thu May 21, 2020 4:30 amThat 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.
Handbrake does not handle HDR, let alone DV, so you lose the color mapping.stephon1024 wrote: ↑Sat May 23, 2020 3:57 pmI'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...
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?Woodstock wrote: ↑Sat May 23, 2020 4:08 pmHandbrake does not handle HDR, let alone DV, so you lose the color mapping.stephon1024 wrote: ↑Sat May 23, 2020 3:57 pmI'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...
Also, if you compress the main video track, the hints in the DV track would no longer be valid.
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.stephon1024 wrote: ↑Sat May 23, 2020 4:16 pmHey 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?Woodstock wrote: ↑Sat May 23, 2020 4:08 pmHandbrake does not handle HDR, let alone DV, so you lose the color mapping.stephon1024 wrote: ↑Sat May 23, 2020 3:57 pmI'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...
Also, if you compress the main video track, the hints in the DV track would no longer be valid.
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
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!MartyMcNuts wrote: ↑Sun May 24, 2020 12:09 amI 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.stephon1024 wrote: ↑Sat May 23, 2020 4:16 pmHey 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
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.
For this type of experiment, I recommend using the 0.0.4 alfa version of my tool.stephon1024 wrote: ↑Sat May 23, 2020 3:57 pmIs there anyway to use handbrake to compress the base file before using your special tool?
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.yusesope wrote: ↑Sun May 24, 2020 6:40 amFor this type of experiment, I recommend using the 0.0.4 alfa version of my tool.stephon1024 wrote: ↑Sat May 23, 2020 3:57 pmIs there anyway to use handbrake to compress the base file before using your special 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".
Because (lowering the bitrate) you reduce the amount of information inside BL.
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 wrote: ↑Sun May 24, 2020 10:16 amBecause (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.
I am sincerely happy to read what you write.PapitaHD wrote: ↑Sun May 24, 2020 10:55 amThat 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 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 ).yusesope wrote: ↑Sun May 24, 2020 11:27 amI am sincerely happy to read what you write.PapitaHD wrote: ↑Sun May 24, 2020 10:55 amThat 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.
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).