Official Dolby Vision MKV spec support

[tazlord]

Open an MKV file that contains two(2) video tracks. The first track is the (re-encoded) DV base layer. The second track is the DV enhanced layer. Then merge the two tracks into a single track that is DV single layer compliant.

This is already done in upcoming 1.15.4 , but it was done mostly to please those who made double-layer DV MKVs before the spec was available. So, if MakeMKV sees two video tracks in MKV file, first being HEVC without DV EL and second being DV EL+RPU, it would merge them into one video track (the track order is important, DV layer must be second video track).

Great! I look forward to testing that out.

This however does not solve the re-encoding problem - if you have a proper DV MKV file with a single video track, you can open and re-encode it as base layer in handbrake, but you would end up with original MKV and new re-encoded base video track. If you combine them to a single MKV, you will get 2 valid video tracks:
1. original base + EL + RPU
2. re-encoded base

Then you have somehow tell MakeMKV to keep re-encoded base, but extract DV EL+RPU from another track. This is easy to do technically, the question is about UI. The easiest way probably would be the track ordering as well: if the second track contains Base+EL+RPU, then discard base, extract EL+RPU and inject into first track. Something like that...

Interesting. As Mr_Orange mentioned, I feel this is a very specific use case.
For me, this scenario would never present itself because all of my DV MKV projects start with 2 completely separate video tracks/files ripped directly from the original disc:
1. BL.hevc
2. EL+RPU.hevc

At that point I can re-encode track/file #1 and move forward with creating a library asset. However, I lose the EL+RPU info because my main media streamer/player (Plex) doesn't support reading DV EL+RPU data from a 2nd video track, as well as many other wide gamut issues that Plex has. Hence, the entire reason I am looking for a solution to apply BL+EL+RPU all in a single video track (also because the Plex devs take literal years to implement new features that matter).

[mike admin]

Then you have somehow tell MakeMKV to keep re-encoded base, but extract DV EL+RPU from another track. This is easy to do technically, the question is about UI. The easiest way probably would be the track ordering as well: if the second track contains Base+EL+RPU, then discard base, extract EL+RPU and inject into first track. Something like that...

It seems like a very, very specific use case!

Ok, I honestly don't get it.

Imagine you have a (proper) DV MKV file - made by recent MakeMKV or any other tool. The point is that it is a MKV file with DV according to a spec - single video track.

You want to re-encode the video with handbrake (or any other encoder) , but keep the DV data and the other audio/subtitle tracks intact.

Your workflow?

Currently proposed workflow - open original MKV in encoder, leave for the night for re-encoding, then add produced video track to MKV and pass thorough MakeMKV. It is a bit ugly, but should work.
Another option - somehow split original single video track into two video tracks - base + EL, then do the same - re-encode base, combine to single MKV and the pass thorough MakeMKV. But then you have an additional step to extract EL, and I'm not sure such tool is readily available.

[Mr_Orange]

Then you have somehow tell MakeMKV to keep re-encoded base, but extract DV EL+RPU from another track. This is easy to do technically, the question is about UI. The easiest way probably would be the track ordering as well: if the second track contains Base+EL+RPU, then discard base, extract EL+RPU and inject into first track. Something like that...

It seems like a very, very specific use case!

Ok, I honestly don't get it.

Imagine you have a (proper) DV MKV file - made by recent MakeMKV or any other tool. The point is that it is a MKV file with DV according to a spec - single video track.

You want to re-encode the video with handbrake (or any other encoder) , but keep the DV data and the other audio/subtitle tracks intact.

Your workflow?

Currently proposed workflow - open original MKV in encoder, leave for the night for re-encoding, then add produced video track to MKV and pass thorough MakeMKV. It is a bit ugly, but should work.
Another option - somehow split original single video track into two video tracks - base + EL, then do the same - re-encode base, combine to single MKV and the pass thorough MakeMKV. But then you have an additional step to extract EL, and I'm not sure such tool is readily available.

Sorry, I was agreeing with you. I don't really get it either. I'm not sure what is wrong with the original MKV produced by MakeMKV that there needs to be another process.

[manuelrn]

Open an MKV file that contains two(2) video tracks. The first track is the (re-encoded) DV base layer. The second track is the DV enhanced layer. Then merge the two tracks into a single track that is DV single layer compliant.

This is already done in upcoming 1.15.4 , but it was done mostly to please those who made double-layer DV MKVs before the spec was available. So, if MakeMKV sees two video tracks in MKV file, first being HEVC without DV EL and second being DV EL+RPU, it would merge them into one video track (the track order is important, DV layer must be second video track).

This however does not solve the re-encoding problem - if you have a proper DV MKV file with a single video track, you can open and re-encode it as base layer in handbrake, but you would end up with original MKV and new re-encoded base video track. If you combine them to a single MKV, you will get 2 valid video tracks:
1. original base + EL + RPU
2. re-encoded base

Then you have somehow tell MakeMKV to keep re-encoded base, but extract DV EL+RPU from another track. This is easy to do technically, the question is about UI. The easiest way probably would be the track ordering as well: if the second track contains Base+EL+RPU, then discard base, extract EL+RPU and inject into first track. Something like that...

Hi Mike, is there an estimated release date for this new version?

I find it a very useful feature in some cases and I am sure that several people will find it helpful.

Thank you very much as always!

[EvilWays1]

Sorry if I missed it in a previous post, but I'm trying to make sure I'm ripping a UHD with DV right using MakeMKV.

I'm using MakeMKV 1.15.3, and I'm ripping Atomic Blonde as a self-lesson on this. In MakeMKV, I see duplicate titles with the exact same setup except the second title doesn't have Chapters. The Video section of each Title shows "MpegH HEVC Main10@L5.1 (dvhe.07.06 BL+FEL+RPU)". MediaInfo also shows "HDR format: Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible".

Now here's where I'm kind of lost: are the two layers ripped as part of the single video track when I click to Save Selected Titles? I tried ripping just one of the titles (the one with chapters), and fed it in to MKVToolNix to see if I did it right, but I only see the one video track, and not much in regard to details about the video track.

[shawnc22]

Sorry if I missed it in a previous post, but I'm trying to make sure I'm ripping a UHD with DV right using MakeMKV.

I'm using MakeMKV 1.15.3, and I'm ripping Atomic Blonde as a self-lesson on this. In MakeMKV, I see duplicate titles with the exact same setup except the second title doesn't have Chapters. The Video section of each Title shows "MpegH HEVC Main10@L5.1 (dvhe.07.06 BL+FEL+RPU)". MediaInfo also shows "HDR format: Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible".

Now here's where I'm kind of lost: are the two layers ripped as part of the single video track when I click to Save Selected Titles? I tried ripping just one of the titles (the one with chapters), and fed it in to MKVToolNix to see if I did it right, but I only see the one video track, and not much in regard to details about the video track.

You're doing it right, both layers are stored in the single video track.

[preserve]

In MakeMKV, I see duplicate titles with the exact same setup except the second title doesn't have Chapters.

You'll see the difference under "Source file name" in the "Title information" section of the right side pane. The one with chapters is an mpls playlist, the one without is the source m2ts video file.

[EvilWays1]

You're doing it right, both layers are stored in the single video track.

Got it. Thanks!

Now, if I want to reduce the overall filesize from ripped from disc size of 48+ GB, can I send the whole MKV file through Handbrake or will I have to separate the layers of the video track and only run the BL through so as to not ruin anything for DV?

[lexyz]

It seems Emby for AbdroidTV 1.8.55 beta supports DV in mkv

[MartyMcNuts]

You're doing it right, both layers are stored in the single video track.

Got it. Thanks!

Now, if I want to reduce the overall filesize from ripped from disc size of 48+ GB, can I send the whole MKV file through Handbrake or will I have to separate the layers of the video track and only run the BL through so as to not ruin anything for DV?

I doubt Handbrake can be used for UHD as I don't think it can do HDR. In any case, the layers must be separated as only the BL can be re-encoded.

What I do is:

1. Rip to folder using MakeMKV.
2. Use NVENCC64 command line to re-encode BL, keeping HDR (and HDR10+ metadata if included).
3. Use TSmuxer to create a new copy of the original m2ts file swapping out the original BL for my encoded BL.
4. Open the UHD folder in MakeMKV to create a MKV file with HDR/DV (and HDR10+ if included)


Now, I'm also unsure how well (or if at all) these files play as I currently don't have a TV with Dolby Vision. Hopefully soon!!

[EvilWays1]

I doubt Handbrake can be used for UHD as I don't think it can do HDR. In any case, the layers must be separated as only the BL can be re-encoded.

What I do is:

1. Rip to folder using MakeMKV.
2. Use NVENCC64 command line to re-encode BL, keeping HDR (and HDR10+ metadata if included).
3. Use TSmuxer to create a new copy of the original m2ts file swapping out the original BL for my encoded BL.
4. Open the UHD folder in MakeMKV to create a MKV file with HDR/DV (and HDR10+ if included)


Now, I'm also unsure how well (or if at all) these files play as I currently don't have a TV with Dolby Vision. Hopefully soon!!

I've got a Dolby Vision capable TV (LG C9 series), so hopefully it doesn't puke on my tests. I'll just have to figure out how to use NVEncC64 and TSmuxer (I've messed around a bit with MKVGuiNix, but not sure if it will work for this).

[MartyMcNuts]

I doubt Handbrake can be used for UHD as I don't think it can do HDR. In any case, the layers must be separated as only the BL can be re-encoded.

What I do is:

1. Rip to folder using MakeMKV.
2. Use NVENCC64 command line to re-encode BL, keeping HDR (and HDR10+ metadata if included).
3. Use TSmuxer to create a new copy of the original m2ts file swapping out the original BL for my encoded BL.
4. Open the UHD folder in MakeMKV to create a MKV file with HDR/DV (and HDR10+ if included)


Now, I'm also unsure how well (or if at all) these files play as I currently don't have a TV with Dolby Vision. Hopefully soon!!

I've got a Dolby Vision capable TV (LG C9 series), so hopefully it doesn't puke on my tests. I'll just have to figure out how to use NVEncC64 and TSmuxer (I've messed around a bit with MKVGuiNix, but not sure if it will work for this).

MKVtoolnix won't work for this. TSmuxer is very easy. Use the (04.06 fix) version. To use nvencc64 (I'm using v5.22) you need a compatible NVIDIA graphics card. Mine is a RTX 2070.

Here is the nvencc64 command I used to encode the BL @25000 and include the HDR/HDR10+ info.:

NVEncC64 --avhw -i G:\BACK_TO_THE_FUTURE_PART_II\BDMV\STREAM\00294.m2ts --output-res 3840x2160 --fps 23.976 --codec h265 --preset quality --level 5.1 --profile main10 --tier high --output-depth 10 --lookahead 32 --vbrhq 25000 --output-buf 64 --aud --colorprim bt2020 --colormatrix bt2020nc --dhdr10-info copy --transfer auto --chromaloc 2 --master-display copy --max-cll copy -o "G:\BACK_TO_THE_FUTURE_PART_II\BL_shrunk.hevc"


Once I have my BL-shrunk.hevc file:

1. I open up TSmuxer and drag/drop this file.

2. Then I drag/drop the original m2ts file (00294.m2ts renamed to 00294-old.m2ts) from the ripped UHD folder and deselect the first segment from this original m2ts file.

3. Change the output to "M2TS muxing", using the original file name as the output name,so this new file is 00294.m2ts and save to the STREAM folder.

Here is a pic to show you.

TSmuxer-pic.jpg (269.63 KiB) Viewed 27894 times

Once TSmuxer has completed, open the UHD folder in MakeMKV to create your new (already re-encoded) MKV file with HDR/HDR10+/DV.

Here is a MakeMKV pic. As you can see, the file is no longer 80+GB. It is my re-encoded file.

MakeMKV-pic.jpg (173.24 KiB) Viewed 27887 times

Now create the MKV file and you are done!

Here is a pic from MediaInfo showing the video of my newly created MKV:

MediaInfo-pic.jpg (73.92 KiB) Viewed 27848 times

[Mr_Orange]

You guys just need to buy more storage. All this muxing, shrinking, remuxing, time, stress, electricity is costing you a lot more than another 10TB hard drive.

[MartyMcNuts]

You guys just need to buy more storage. All this muxing, shrinking, remuxing, time, stress, electricity is costing you a lot more than another 10TB hard drive.

Well, as a pensioner, I can't afford $500 fora 10TB hard drive. Besides,my current (6 year old) NAS only supports up to 4TB drives and is already max'd out at 16TB (which is 2/3rds full).

Also, I don't know about you but I cannot see any difference between my re-encoded MKV's @ 25 Mb/s and the original on my 78" TV and it saves me half the space.

I'll have to invest in a new NAS eventually but it will be a while yet!

[EvilWays1]

You guys just need to buy more storage. All this muxing, shrinking, remuxing, time, stress, electricity is costing you a lot more than another 10TB hard drive.

I currently live in an apartment, so I don't have the space (or proper power setup) for a large storage server. Right now, I only have a Synology DS1815+ NAS that I am in the process of retiring, but that won't happen until I have the replacement NAS built and running (based on UnRAID with ZFS community addon) which won't be ready for some time as I've just started obtaining parts. Not to mention, I tend to occasionally stream outside of my network. Reducing the amount of bandwidth needed to stream outside my network means I don't cripple the already weak CPU in the DS1815+ due to transcoding (regardless of format, but particularly from a 4k source being kept at 4k). When I'm on a soon-to-be built city-wide fiber network for internet, then transcoding ahead of time shouldn't be an issue bandwidth wise.

I'm transcoding/muxing/etc. for current convenience, where just "buying more storage" doesn't fix other issues at present.