Dolby Vision now possible through MP4 Mux.

[yusesope]

I am still refining the whole process, You are right, it takes less time. On my pc between 20 and 30 minutes....

If you need a hand, as soon as I can, I'll answer you.

Can you share your source code with me? I'm happy to help you compile a Mac version.

After the October 2 update on BETA, there is no longer any source code for Mac.
Then take the GAMMA version for example: for now it only works on Windows ... when I have time I will extend support to Linux as well.
Windows and Linux are the only platforms I can experiment with.

The performance of VM is very poor on my computer, so I have to reboot into Windows every time.

I'm sorry for the inconvenience.
On my 400€ machine the VMs have the same performance as the primary OS: I can hardly believe that your Mac (iMac 2020 ??? ... MacBook Pro >= 2018 ???) struggles!

Can you also share the modified source code of Dolby's mp4muxer? I cannot reproduce a working mp4 file. Please share the source code so I can know what you've changed.

I simply forced the value of "sample_entry_name_flag" (setting it to 1) through the "p_usr_cfg_es" pointer.
Add the row

Code: Select all

p_usr_cfg_es->sample_entry_name_flag = 1;

on line 7012 of the mp4_muxer.c file.

This type of solution is fine for my experiments.
For something more dynamic, you'd better add a switch (something like --force-hvc1 1) in the frontend (mp4_muxer_app.c).
I have not checked but I think it is possible by modifying the ema_mp4_mux_set_input function in such a way that it accepts the value of the new switch and with the latter set usr_cfg_es->sample_entry_name_flag

[kws53]

FIRST - Very fine work Yusesope.

Ran GAMMA on 1917...
With no additional switches and Profile 8:
SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
With -skip_hdr10plus:
SMPTE ST 2086, HDR10 compatible

Speed was 10.5x (AMD Ryzen 9 3900x), so 11minutes20seconds. No idea how to determine whether FEL or MEL (no MakeMKV...). And BDInfo doesn't provide this info either. 3rd party app?

Most importantly - how do I get DolbyVision?

[yusesope]

FIRST - Very fine work Yusesope.

Ran GAMMA on 1917...
With no additional switches and Profile 8:
SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
With -skip_hdr10plus:
SMPTE ST 2086, HDR10 compatible

Speed was 10.5x (AMD Ryzen 9 3900x), so 11minutes20seconds. No idea how to determine whether FEL or MEL (no MakeMKV...). And BDInfo doesn't provide this info either. 3rd party app?

Most importantly - how do I get DolbyVision?

The input file must be a dual track dual layer profile 7 file (e.g. an m2ts file inside the decrypted folder of a UHD-BD)

The mkv file obtained after the program has finished is not recognized as a file with DoVi!
Needs to be patched!

Did you use the mkv patcher as indicated in the third step (HERE)?

I don't understand what you mean when you talk about FEL or MEL: if in the first command line you used "-mode 2" then, when the patcher asks you, type 8 otherwise your file (FEL or MEL, it doesn't matter) will be a profile 7 and you will have to type 7 when prompted by the patcher!

[baohen1510]

What wrong ? Pls help me

F:\DOLBYVISION\MAKEMKVDOLBYVISION>python-3.7.6.amd64\python.exe src\MKV_patcher.py


Please, drag and drop here the MKV file and press ENTER:
G:\DV.mkv

Please choose the profile to assign (7 or :
8
Traceback (most recent call last):
File "F:\DOLBYVISION\MAKEMKVDOLBYVISION\python-3.7.6.amd64\lib\site-packages\bitstring.py", line 833, in _initialise
init_without_length_or_offset[k](self, v)
KeyError: 'uint'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "src\MKV_patcher.py", line 243, in <module>
patched_data = mkv_patcher.inject_dolby_vision(dolby_vision_data)
File "src\MKV_patcher.py", line 217, in inject_dolby_vision
self.init_elements()
File "src\MKV_patcher.py", line 159, in init_elements
el_property["size"] = self.read_variable_size_int()
File "src\MKV_patcher.py", line 138, in read_variable_size_int
parsedValue = BitArray(uint=(self.mkv_data[pos:pos + 8] & (~self.get_len_mark(length))).uint,length=length)
File "src\MKV_patcher.py", line 127, in get_len_mark
return BitArray(uint=1 << (8 - int(length / ),length=8)
File "F:\DOLBYVISION\MAKEMKVDOLBYVISION\python-3.7.6.amd64\lib\site-packages\bitstring.py", line 3059, in __new__
y = Bits.__new__(BitArray, auto, length, offset, **kwargs)
File "F:\DOLBYVISION\MAKEMKVDOLBYVISION\python-3.7.6.amd64\lib\site-packages\bitstring.py", line 812, in __new__
x._initialise(auto, length, offset, **kwargs)
File "F:\DOLBYVISION\MAKEMKVDOLBYVISION\python-3.7.6.amd64\lib\site-packages\bitstring.py", line 838, in _initialise
init_with_length_only[k](self, v, length)
File "F:\DOLBYVISION\MAKEMKVDOLBYVISION\python-3.7.6.amd64\lib\site-packages\bitstring.py", line 1388, in _setuint
raise CreationError(msg, uint, length, (1 << length) - 1)
bitstring.CreationError: 256 is too large an unsigned integer for a bitstring of length 8. The allowed range is [0, 255].

F:\DOLBYVISION\MAKEMKVDOLBYVISION>pause
Press any key to continue . . .

[Manixx2020beyound]

So I got curious about the iPhone 12 pro doblyvision which I haven’t gotten yet,
But I do have the pro11 MAX, so I uploaded the captured I phone 12 clip dovi on the pro max 11 & ran I movie on the max 11pro
And I movie on the 11 produce a doblyvision
File slightly different from the original.
Produced an profile 8 id36 doblyvision hlg.
So I phone 11pro can encode dovi/rpu/bl
Which played in doblyvision on my dv devices.
I’ll post a media info later today.
My second test is to use uhbd dual to single layer mp4 in I move to encode in doblyvision
My question is does any further minuplation needed to uhd mp4s so I movie can accept them.
I’m also going to try on my MacBook Pro.

[kws53]

The input file must be a dual track dual layer profile 7 file (e.g. an m2ts file inside the decrypted folder of a UHD-BD)

It is a dual track, dual layer m2ts file from the original - see Image 1. How can I tell whether it is a profile 7 file?
Specifically: \BDMV\STREAM\00294.m2ts from the 1917 ISO [US]

The mkv file obtained after the program has finished is not recognized as a file with DoVi!
Needs to be patched!

Did you use the mkv patcher as indicated in the third step (HERE)?

Indeed - see Image 2.

I don't understand what you mean when you talk about FEL or MEL: if in the first command line you used "-mode 2" then, when the patcher asks you, type 8 otherwise your file (FEL or MEL, it doesn't matter) will be a profile 7 and you will have to type 7 when prompted by the patcher!

I didn't use any switches other than the "-skip_hdr10plus" for my comparison.

[HongyuS]

And I movie on the 11 produce a doblyvision
File slightly different from the original.
Produced an profile 8 id36 doblyvision hlg.
So I phone 11pro can encode dovi/rpu/bl
Which played in doblyvision on my dv devices.

Any iOS/iPadOS device later than iPhone 8 / iPad Pro 2017 should be able to encode and play DoVi (requires latest iOS and iMovie for iOS)
And yes, the file should be slightly different in size. Because iMovie re-encodes the base-layer and also re-calibrates the DoVi RPU.

And for further info, which @yusesope might also be interested in, iMovie re-encodes any HDR into Dolby Vision (HDR10, HLG, HLG+DoVi). I guess iMovie only generates new RPU. Old RPU data only used when decoding.

My second test is to use uhbd dual to single layer mp4 in I move to encode in doblyvision
My question is does any further minuplation needed to uhd mp4s so I movie can accept them.

You should use the latest yusesope's tool (both BETA and GAMMA should work), and when muxing to mp4, you should make these modifications to mp4muxer suggested by yusesope.

I simply forced the value of "sample_entry_name_flag" (setting it to 1) through the "p_usr_cfg_es" pointer.
Add the row

Code: Select all

p_usr_cfg_es->sample_entry_name_flag = 1;

on line 7012 of the mp4_muxer.c file.

For something more dynamic, you'd better add a switch (something like --force-hvc1 1) in the frontend (mp4_muxer_app.c).
I have not checked but I think it is possible by modifying the ema_mp4_mux_set_input function in such a way that it accepts the value of the new switch and with the latter set usr_cfg_es->sample_entry_name_flag

I’m also going to try on my MacBook Pro.

For now (before Apple releases macOS Big Sur), only iMovie for iOS can encode DoVi. I tried Mac version yesterday, didn't work.

[yusesope]

What wrong ? Pls help me

If you followed all the instructions, then there is a problem with the patcher ... in the next few days I will release a new version which, in case of error, generates a log file that you can post. Through the latter I can understand how to fix the problem and improve the patcher.
Be patient and hold on ...

It is a dual track, dual layer m2ts file from the original - see Image 1. How can I tell whether it is a profile 7 file?
Specifically: \BDMV\STREAM\00294.m2ts from the 1917 ISO [US]
.........................................
Indeed - see Image 2.
.........................................
I didn't use any switches other than the "-skip_hdr10plus" for my comparison.

If the m2ts file with those characteristics comes from a UHD-BD then it is a profile 7.

My question is: if you say you didn't use the "-mode 2" switch (which is used to generate files with profile 8 ) but only the one to discard HDR10+ metadata then why did you patch the file by assigning a profile 8?

The file cannot be patched multiple times - I recommend starting from scratch!

Use my GAMMA version and at the third and last step assign the correct profile as I explained in the previous post.

The characteristics of the final MKV file depend on the switches used in the first step.

1917 is a FEL movie so you can get:

• 1917 FEL profile 7
• 1917 MEL profile 7
• 1917 profile 8 (profile 8 has no enhancement layer)

All previous variants may or may not have HDR10+ (depends on whether you used or didn't use -skip_hdr10plus)

Check the MKV file with Mediainfo at the end.

[kws53]

Ran GAMMA on 1917...
With no additional switches and Profile 8:
SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
With -skip_hdr10plus:
SMPTE ST 2086, HDR10 compatible

Speed was 10.5x (AMD Ryzen 9 3900x), so 11minutes20seconds. No idea how to determine whether FEL or MEL (no MakeMKV...). And BDInfo doesn't provide this info either. 3rd party app?

Most importantly - how do I get DolbyVision?

The input file must be a dual track dual layer profile 7 file (e.g. an m2ts file inside the decrypted folder of a UHD-BD)

The mkv file obtained after the program has finished is not recognized as a file with DoVi!
Needs to be patched!

Did you use the mkv patcher as indicated in the third step (HERE)?

I don't understand what you mean when you talk about FEL or MEL: if in the first command line you used "-mode 2" then, when the patcher asks you, type 8 otherwise your file (FEL or MEL, it doesn't matter) will be a profile 7 and you will have to type 7 when prompted by the patcher!

Yusesope - After re-reading your original response, I may have not been clear in my original post. (also see my follow-up post earlier). NOTE: all mkv files were checked with MediaInfo (results are shown)
1) GAMMA ran flawlessly. ALL operations including the PATCH. NOTE: each file was run independently of the other - no patches on patches...
2) Since I didn't know whether I was dealing with an FEL or MEL file, and didn't know whether I needed profile 7 or profile 8, I ran multiple trials:

1. NO additional switches, profile 7, strictly default settings and then patch. Result was HDR+ file (SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible)
2. Adding the <-skip_hdr10plus> switch and then patch. As expected, the result was HDR file (SMPTE ST 2086, HDR10 compatible)
3. <-mode 2> switch, profile 8, and then patch. Result was HDR+ file (SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible)

The original M2TS is indeed Dual Layer DolbyVision (see attachment below). BUT I cannot determine if the ORIGINAL M2TS has MEL or FEL. What software will determine that?

Showing Dual Layer DolbyVision

Dual Layer.png (10.85 KiB) Viewed 22701 times

NEW INFORMATION: I dropped the original M2TS file into MediaInfo and found that it did not show DolbyVision, but HDR+, yet EAC3TO indicates otherwise. (again, see above)

[kws53]

If the m2ts file with those characteristics comes from a UHD-BD then it is a profile 7.

My question is: if you say you didn't use the "-mode 2" switch (which is used to generate files with profile 8 ) but only the one to discard HDR10+ metadata then why did you patch the file by assigning a profile 8?

The file cannot be patched multiple times - I recommend starting from scratch!

Use my GAMMA version and at the third and last step assign the correct profile as I explained in the previous post.

The characteristics of the final MKV file depend on the switches used in the first step.

1917 is a FEL movie so you can get:

• 1917 FEL profile 7
• 1917 MEL profile 7
• 1917 profile 8 (profile 8 has no enhancement layer)

All previous variants may or may not have HDR10+ (depends on whether you used or didn't use -skip_hdr10plus)

Check the MKV file with Mediainfo at the end.

My response and yours crossed paths. (see my post immediately above).
To your questions:

• I did use -mode 2 when producing profile 8
• I never patched multiple times
• I assigned correct profile depending on the switch and Title length (everything worked...)
• I check all of the MKV files with MediaInfo - hence I was able to provide you with the results

My issue right now is that I can produce an HDR+ profile 7 or profile 8 version. I can't produce a DolbyVideo profile version at all. Am I confusing HDR+ and DolbyVision, because EAC3TO says DolbyVision on the original video, but MediaInfo says HDR+ on the original M2TS file.

[koolkunz]

How does it work.
Given as input a Dual Track Dual Layer DoVi file (for now use the m2ts files present in the decrypted folders of your UHD-BDs), the tool should return a Single Track Dual Layer MKV file ready to be played on your devices.

python-3.7.6.amd64\python.exe src\app.py -mux -exp \path\to\your\original\file.m2ts

As written, this command line will generate a FEL or MEL file.
If you have a FEL file and want a MEL file, add the -fel_to_mel switch before the -mux one.
If you have a FEL or MEL file and want an 8.1 profile file add the -mode 2 switch before the -mux one.

I have a couple of questions that might sound dumb (please bear with me I got my first Dolby Vision TV-Sony X900H last week only)

1) When we are converting FEL file to MEL we are losing the advantages FEL has over MEL right?

2) When we are converting FEL file to 8.1, does the FEL data get retained?

Also I see your exoplayer being reffered a lot in your previous posts but I couldnt find it please link it.

And can anyone guide me to what is the difference between the various dolby vision profiles?

MY final goal is to be able to play FEL dolby vision mkvs/mp4s/ts through Plex or Kodi on my Sony X900H (Android TV). MEL/8.1 profile MKVs/MP4s play correctly already.

[yusesope]

My second test is to use uhbd dual to single layer mp4 in I move to encode in doblyvision

Any iOS/iPadOS device later than iPhone 8 / iPad Pro 2017 should be able to encode and play DoVi (requires latest iOS and iMovie for iOS)
And yes, the file should be slightly different in size. Because iMovie re-encodes the base-layer and also re-calibrates the DoVi RPU.

And for further info, which @yusesope might also be interested in, iMovie re-encodes any HDR into Dolby Vision (HDR10, HLG, HLG+DoVi). I guess iMovie only generates new RPU. Old RPU data only used when decoding.

At the moment it seems to be the only correct way to encode a UHD-BD with DoVi (we should then evaluate the quality of the file obtained ... I expressed my personal opinion HERE)
Keep experimenting and if you find anything unusual, post it here.

GAMMA ran flawlessly. ALL operations including the PATCH

1. NO additional switches, profile 7, strictly default settings and then patch. Result was HDR+ file (SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible)
2. Adding the <-skip_hdr10plus> switch and then patch. As expected, the result was HDR file (SMPTE ST 2086, HDR10 compatible)
3. <-mode 2> switch, profile 8, and then patch. Result was HDR+ file (SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible)

I can't produce a DolbyVideo profile version at all

Only the latest version of Mediainfo (Version 20.09, 2020-10-09) is capable of detecting DV in a MKV container.
I sincerely hope your version of Mediainfo is up to date...
otherwise...
I will look for you, I will find you, and I will patch you...

If the problem is not Mediainfo, then I kindly ask you to upload a 10 second sample of one of your MKV files obtained using GAMMA.
Use this command:

src\FFmpeg\ffmpeg_win_x64.exe -ss 0 -t 10 -i \path\to\GAMMA\output\file.mkv -c copy \path\to\file_cut_10_sec.mkv

TO THE COMMUNITY:
Have any of you bought the new Chromecast with Google TV?
If so, have you tried any files with DV?
On the audio side, how does it behave?
Thank you.


I think I've found a way to create MP4 files as well. GAMMA could then generate MP4 files with DV, keeping in mind the limitations of the container (ATMOS/TrueHD -> PCM 7.1 and not PGS subtitles. All other codecs, up to DTS:X, would be supported instead).
LG CX 2020 owners, for example, may be interested - they could take advantage of GAMMA's speed to generate MP4 files with DV (profile 8.1) and with custom audio and subtitles.
Is anyone interested or am I wasting my time?

[Manixx2020beyound]

I also have the google chromecast 4K dv
Its like the Xbox-1 only does LLDV no rgb8 capable dv. But as a consumer’s u would never know that without a vertex.
Plays well/ better frame rate matching than firestick,
Colors are a diff story, ( more testing needed).
Audio I can let u guys know later today.
Any clips I can test??
Audio wise??

[yusesope]

I also have the google chromecast 4K dv

Is that the one with the remote? The latest one?

EDIT:
Ok, the image clear up any doubts!

Its like the Xbox-1 only does LLDV no rgb8 capable dv. But as a consumer’s u would never know that without a vertex.
Plays well/ better frame rate matching than firestick,
Colors are a diff story, ( more testing needed).

Interesting, keep us updated!

Audio I can let u guys know later today.
Any clips I can test??

You can use these samples to test both Dolby and DTS.
Thank you.

[DaMacFunkin]

I also have the google chromecast 4K dv
Its like the Xbox-1 only does LLDV no rgb8 capable dv. But as a consumer’s u would never know that without a vertex.
Plays well/ better frame rate matching than firestick,
Colors are a diff story, ( more testing needed).
Audio I can let u guys know later today.
Any clips I can test??
Audio wise??

Hi, I have Chromecast with Google TV and frame rate switching is not supported, also there is no HD audio support and Plex app is outputting AAC 5.1 / 7.1 as PCM 2.0.
All these limitations are currently being discussed on Kodi and Plex forums.