Dolby Vision now possible through MP4 Mux.

[FubbAyH]

I don't know enough about the bug to know whether the files would be fixable, but it might be worth checking your M2TS files with:

Code: Select all

ffmpeg -i testfile.m2ts -f null -

to see if they're okay. It might be that only DV streams are affected, or something like that.

[Epedemic]

You need to demux the video first, and then run the script on the HEVC file.
example: python hdr10plus_remove.py -i video.hevc -o processed_file.hevc

Thanks for that. Is there an idiots guide on HDR10+ to DV conversion?

I wrote up how this idiot does it here:

https://www.avsforum.com/threads/author ... t-60952335

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Turn HDR10+ metadata into Dolby Vision metadata**
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Command 1: 'hdr10plus_tool extract Video.hevc -o Metadata.json' (Extracts HDR10+ metadata and saves to .json file)

>>Next commands go through Dovi_Tool and v0.5.0 minimum required<<<
Command 2: 'dovi_tool generate -j Extra.json --hdr10plus-json Metadata.json --rpu-out RPUPlus.bin' (combines metadata from edited 'Extra.json' - template is below and you need to do one for every title specifically - and metadata from extracted 'Metadata.json' and combines+converts them into p8 RPU metadata format)

Command 3: 'dovi_tool.exe inject-rpu --input Video.hevc --rpu-in RPUPlus.bin' (Injects HDR10+ generated RPU metadata into HEVC stream turning it into single layer Dolby Vision 8 stream)
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Blank Template for 'Extra.json'
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
{
"length": (title specific framelength here without parenthesis),
"level2": [
{
"target_nits": 100
},
{
"target_nits": 600
},
{
"target_nits": 1000
},
{
"target_nits": 2000
}
],
"level6": {
"max_display_mastering_luminance": (title specific metadata info here without parenthesis),
"min_display_mastering_luminance": (title specific metadata info here without parenthesis),
"max_content_light_level": (title specific metadata info here without parenthesis),
"max_frame_average_light_level": (title specific metadata info here without parenthesis)
}
}
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Another question: I have a few HDR10+ files i want to "convert" to DV, but the

Maximum Content Light Level & Maximum Frame-Average Light Level lines are missing in mediainfo. Is there some default value to use and hope for the best, or are there some way to find the correct values?

[RESET_9999]

@RESET_9999
I used your tool to create measurements of Smurfs.The.Lost.Village.2017 in many times but received result always is a Smurfs.The.Lost.Village.2017.mkv.measurements.incomplete 71.4MB
So should I use it?

I don't know , is that a seamless branching disc? I think so...
How did you rip your disc? do not use mkvtoolnix or makemkv when the disc has multiples m2ts. always use tsmuxer.

Great... I just redid a shitload of bdmv folders to .ts with the bugged tsmuxer :/ Any chance of fixing these corrupt .ts files, or do i have to start ALL over? :/

Yea, 2nd time in 2 months they mess up Dolby Vision. I'll just stop updating tsmuxer unless there's a major update...

Another question: I have a few HDR10+ files i want to "convert" to DV, but the

Maximum Content Light Level & Maximum Frame-Average Light Level lines are missing in mediainfo. Is there some default value to use and hope for the best, or are there some way to find the correct values?

It's not missing, it's just set to 0

[Epedemic]

Thank you once again. You are awesome

[sickb]

Does anyone have an idea why I get different results...
in the first case I have a 49.3mb/s 42.7gb video track
in the seco case I have a 48.0mb/s 41.6gb video track

That's weird indeed. Maybe waste of space in MEL that tsMuxer would solve when muxing? I recently had a title with 1.6 GB MEL, of which RPU was 36MB. You can of course investigate by demuxing BL and EL from both mkvs and compare sizes.

Even better of course is what RESET_9999 suggested and convert to Profile 8.1 "BL+RPU". You'll have no EL at all.

I just tried the same with James Bond: No Time To Die. It's a FEL movie, and it has the same quirk;
- Direct to MKV: 56.6MBPS, 64.7GB, 58,1 GB BL, 6,53 GB EL
- TS-BDMV-MKV: 52.6MBPS, 60.1GB, 58,1 GB BL, 1,93 GB EL
So it removes about 4.6GB of EL somehow..

[x08vick80x]

Very very interesting... I would like to test it but I'm not sure what values I have to put in the Extra.json, could someone help please ? If I understand well and from what mediainfo tells me :

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 h 32 min
Bit rate : 4 511 kb/s
Width : 3 840 pixels
Height : 1 600 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Variable
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.031
Stream size : 4.82 GiB (88%)
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0050 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 977 cd/m2
Maximum Frame-Average Light Level : 344 cd/m2

I would fill the json like this :

{
"length": 9120, //which is the video duration converted to seconds
"level2": [
{
"target_nits": 100
},
{
"target_nits": 600
},
{
"target_nits": 1000
},
{
"target_nits": 2000
}
],
"level6": {
"max_display_mastering_luminance": 1000, //don't know if cd/m2 is needed here
"min_display_mastering_luminance": 0.0050,
"max_content_light_level": 977,
"max_frame_average_light_level": 344
}
}

I have an error : Error: invalid type: floating point 0.005, expected u16 at line 19 column 50

PS : wouldn't be possible to reduce max luminence in the extra.json considering that OLED TVs can't reach 1000nits ? (Mine is around 700)

[staknhalo]

I just tried the same with James Bond: No Time To Die. It's a FEL movie, and it has the same quirk;
- Direct to MKV: 56.6MBPS, 64.7GB, 58,1 GB BL, 6,53 GB EL
- TS-BDMV-MKV: 52.6MBPS, 60.1GB, 58,1 GB BL, 1,93 GB EL
So it removes about 4.6GB of EL somehow..

what happens when you mux the smaller fel stream alone (no BL stream) into mkv and try to playback? do you still see obvious motion/video data as with full fel or is it all green/solid blank color always as with mel?

[RESET_9999]

I just tried the same with James Bond: No Time To Die. It's a FEL movie, and it has the same quirk;
- Direct to MKV: 56.6MBPS, 64.7GB, 58,1 GB BL, 6,53 GB EL
- TS-BDMV-MKV: 52.6MBPS, 60.1GB, 58,1 GB BL, 1,93 GB EL
So it removes about 4.6GB of EL somehow..

I don't see why someone would use that workflow, it doesn't make sense. If you want a ST-DL file, do not use makemkv, just use yusesope tool.

here's the problem:



what is strange though is that eac3to detect a video delay in both streams with the DT-DL TS...

top= original

[sickb]

I don't see why someone would use that workflow, it doesn't make sense. If you want a ST-DL file, do not use makemkv, just use yusesope tool.

My reasoning is that I would like to keep the TS for now to enjoy playback on a Blu Ray player of today, but if in the future there's a good ST-DL player, even from mkv, I can still derive one that would be as good as when derived from the original disk.
I'll try yuseope tool, but what I understood it's slower and its not as convenient as the makemkv ui.

[fox0910]

I don't know enough about the bug to know whether the files would be fixable, but it might be worth checking your M2TS files with:

Code: Select all

ffmpeg -i testfile.m2ts -f null -

to see if they're okay. It might be that only DV streams are affected, or something like that.

I use tsmuxer (latest) for DV mkv to m2ts conversation.
I checked result m2ts by ffmpeg.
m2ts is OK, no error.
P.S. tsmuxer (Jan 23th) don't start on Ubuntu 20.04.

[ArArdin]

I just tried the same with James Bond: No Time To Die. It's a FEL movie, and it has the same quirk;
- Direct to MKV: 56.6MBPS, 64.7GB, 58,1 GB BL, 6,53 GB EL
- TS-BDMV-MKV: 52.6MBPS, 60.1GB, 58,1 GB BL, 1,93 GB EL
So it removes about 4.6GB of EL somehow..

I don't have that movie to check. In this case of FEL size being reduced that much I'd be worried. Any playback problems with the two?

I'm suspicious to this tsMuxer bug FubbAyH did head-up. I wonder if it's introduced since the devs have been working on the implementation of muxing TrueHD and EAC3 without embedded AC3. FubbAyH mentioning 23 January as apparent last working date seems consistent.

When tsMuxer produced flawed output in the past, couple of times I empirically concluded that the problem had to be in the demuxing. Sometimes also using ffmpeg didn't help. A tool I don't like for it's demuxing abilities alltogether actually.
In case of any issue and always with a seamless branched disc, first thing I do is demuxing all streams directly from the (UHD)BD iso using DGDemux. And then go from there. Saved my @ss quite some times. Not only with Dolby Vision issues.

[FubbAyH]

I use tsmuxer (latest) for DV mkv to m2ts conversation.
I checked result m2ts by ffmpeg.
m2ts is OK, no error.

Thank you for doing a check. That's good to know that it isn't happening in every scenario. I was doing decrypted disc backup MPLS to M2TS so maybe it only happens there.

When tsMuxer produced flawed output in the past, couple of times I empirically concluded that the problem had to be in the demuxing. Sometimes also using ffmpeg didn't help. A tool I don't like for it's demuxing abilities alltogether actually.
In case of any issue and always with a seamless branched disc, first thing I do is demuxing all streams directly from the (UHD)BD iso using DGDemux. And then go from there. Saved my @ss quite some times. Not only with Dolby Vision issues.

Thanks for bringing DGDemux to our attention. It looks promising but one gotcha is that it has an option to keep the AC3 core with the THD (which we need for X800M2 compatibility) but using that disables the seamless gap processing. So to use the gap processing we'd have to re-add the AC3 core afterwards (presumably re-encoding from the gap-fixed THD), and then remux again so we'd still be at the mercy of tsMuxer bugs.

I rather wish that tsMuxer would release stable versions so that we could all test them thoroughly and have confidence that they're working right.

[ArArdin]

So to use the gap processing we'd have to re-add the AC3 core afterwards (presumably re-encoding from the gap-fixed THD)

I doubt. I always demux into separate TrueHD and separate AC3. I never tried demuxing TrueHD+AC3 with seamless branching, so I honestly wouldn't know whether DGDemux could or could not apply proper gap-processing in such a track. Actually I'd bet my bottom dollar it would do a proper job. I don't think the writer of DGDemux could live with himself when output would not be right. If you say differently, so be it.
Either way,

and then remux again so we'd still be at the mercy of tsMuxer bugs.

Yes. But at least you've lost any demuxing issues by tsMuxer.

Oddly enough, for mkv creation that is, you can import both (DG)demuxed video elementary streams (with desired audio and subs of course) into mkvtoolnix. Eventhough MKVToolnix doesn't officially support DV dualtrack duallayer, it will mux as mkv with 2 videotracks. You don't want this result for playback. But import this into MakeMKV and run: the 2nd videotrack will be recognised and auto-assumed as EL. MakeMKV will spit out a proper DV profile 7 singletrack duallayer mkv. Fun, hey?

[sickb]

Replaced my switch and cabling today, and the 800M2 seems to fare better so far.
Sometimes I have truehd movies start without audio, but when I FF/RWD a bit, it works.

after also replacing the ethernet adapter for the M1 Mac which is my DLNA/SMB/NFS server and solving some other issues with my router, things seem to really look up for the X800M2... so far 2 movie successes, encounting.
almost feel bad now for ordering the M9203... still looking forward to try it out, compare and see if at least CEC is better.
Also BDMV+ISO and MKV TrueHD/Atrmos support would be a boon. The question is what will it do worse..
No idea yet about STDL TS, but DTDL and profile 8.1 for MEL to the rescue I suppose.

When tsMuxer produced flawed output in the past, couple of times I empirically concluded that the problem had to be in the demuxing. Sometimes also using ffmpeg didn't help. A tool I don't like for it's demuxing abilities alltogether actually.
In case of any issue and always with a seamless branched disc, first thing I do is demuxing all streams directly from the (UHD)BD iso using DGDemux. And then go from there. Saved my @ss quite some times. Not only with Dolby Vision issues.

What is it with awesome tools and leaving us Mac folk in the want
I was happy MakeMKV, DVDFab, TSMuxer and dovitool were on Mac, only to find myself wanting eac3to, clonebd+anydvd, and now DGDemux Parallels only gets us so far esp. on M1.

[FubbAyH]

I never tried demuxing TrueHD+AC3 with seamless branching, so I honestly wouldn't know whether DGDemux could or could not apply proper gap-processing in such a track. Actually I'd bet my bottom dollar it would do a proper job. I don't think the writer of DGDemux could live with himself when output would not be right. If you say differently, so be it.

I didn't actually test it myself, I'm just going from what's in DGDemux.txt:

-nsthd: The 'no split thd' option demuxes THD with it's embedded AC3 as a single THD+AC3
stream. When this option is omitted, THD is demuxed into two separate streams, one THD
without embedded AC3, and one AC3. Note that file gaps processing for the THD and embedded
AC3 streams is performed only when this option is not given, i.e., when the streams are
split.