Dolby Vision now possible through MP4 Mux.

[Donpoku]

I didn't watch the whole video but at 5:15 he is playing a single layer DV rip. Also later in the video he mentioned that it doesn't play double layer.

It's an mp4, so it could be either profile. it's almost surely 7 though given this info by Nancy from the Ugoos staff:

Dual layer currently is no problem. for single layer, Amlogic will update new SDK for s922x-j soon. Shortly after we receive the SDK we will push a new update.

Hi m8 can u find out if it pays 3D ISO please? Thx
If it does 3D ISO + Dual layer Dolby Vision(which format specifically btw?), then I'll also swap my M9702 for it.

[Angryunibrow]

I didn't watch the whole video but at 5:15 he is playing a single layer DV rip. Also later in the video he mentioned that it doesn't play double layer.

It's an mp4, so it could be either profile. it's almost surely 7 though given this info by Nancy from the Ugoos staff:

Dual layer currently is no problem. for single layer, Amlogic will update new SDK for s922x-j soon. Shortly after we receive the SDK we will push a new update.

Why does this sound too good to be true.....

[Grencola]

Hi m8 can u find out if it pays 3D ISO please? Thx
If it does 3D ISO + Dual layer Dolby Vision(which format specifically btw?), then I'll also swap my M9702 for it.

it's quite possible, I'll look into it.

Why does this sound too good to be true.....

Well it's 2020, we should start seeing more and more of these devices surface. Minix even finally wrote back and said they're also waiting on the Amlogic SDK releasing at the end of the month so they can get dv colors to look proper, so everything sounds pretty legit.

[whatsmyname]

It's already happened the Ugoos AM6 Plus plays profile 7 dv rips in kodi 18.6 (seek to 5:15ish): https://drive.google.com/file/d/1cpBJSM ... Wt_2A/view I've also heard from people who have successfully played DV profile 5 rips in kodi 19 on their shield. both devices are quickly shaping up to be m9702 killers..

I didn't watch the whole video but at 5:15 he is playing a single layer DV rip. Also later in the video he mentioned that it doesn't play double layer.

Are you saying hes playing a dv single layer video in kodi 18.6?

Yes, he said he created a couple of single layer videos and they are played by the Google Video Player (apparently it's an alpha version, you can't skip/rewind/pause, only stop) in Kodi.

I didn't watch the whole video but at 5:15 he is playing a single layer DV rip. Also later in the video he mentioned that it doesn't play double layer.

It's an mp4, so it could be either profile. it's almost surely 7 though given this info by Nancy from the Ugoos staff:

Dual layer currently is no problem. for single layer, Amlogic will update new SDK for s922x-j soon. Shortly after we receive the SDK we will push a new update.

I have no idea about this device, so maybe it can play profile 7, but in the video he definetly said it plays single layer but no double layer video.
Idk what it can do, just telling you what he said in the video.

[Grencola]

I have no idea about this device, so maybe it can play profile 7, but in the video he definetly said it plays single layer but no double layer video.
Idk what it can do, just telling you what he said in the video.

Thanks for clarifying! The colors I'm the video seem ok, but maybe the dv fixes in the new sdk will make it even better. cool that it can do both profiles though since 7 has already been confirmed.

[shawnc22]

The 0.0.4 ALFA version of my program is out.
As always, I have updated my original post (at the bottom). HERE.

Two main changes:

• the ability to manage raw streams extracted from REMUXed files (out there, into the wild) that in the past have retained the stream relating to the Enhancement Layer.

• given the requests of different users, I have introduced the DEMUX function. Starting from a raw Single Track Double Layer HEVC file (BL_EL_RPU.hevc) it is possible to restore the Base Layer (BL.hevc) and the Enhancement Layer (EL_RPU.hevc)

People who are afraid of black screens with white writing (a.k.a command line), can use the handy "MUXER.bat" (the old "start_bl_el_rpu_builder.bat") and "DEMUXER.bat" files and follow the instructions on the screen.
The more practical ones can run the program with the "-h" switch and see the help output.

Considerations:

• as for the first point, I recommend to always use the copy of your original disc. Technically speaking, REMUXed files may have lost important information during their creation. So a 1:1 copy of a BD disc may be different than a 1:1 copy of a REMUXed file. Take a look at the counters: if the total number of Access Units of BL Layer is different from that of EL Layer (the numbers you see in parentheses), it is likely that the file obtained does not work correctly (especially if the difference is greater than 1).
  
  WARNING

  Out of curiosity, I tested my program using a REMUXed mkv (Birds of Prey) that can be found "into the wild".
  The first video stream is already a BL_EL_RPU stream (evidently they used the latest version of MakeMKV) and then they added a second video stream which is actually the Enhancement Layer.
  A mess...
  
  If you mux (using my program) these anomalous video streams you will create a file with duplicate layers (because part of them were already present in the first stream which, strictly speaking, should be the Base Layer and not Base Layer + Enhancement Layer).
  
  Pay attention to the REMUX (with two video streams) created after the release of the latest version of MakeMKV (v1.15.1).
  
  The good news is that, if you notice it before making a mess, you can directly import the REMUX file into tsMuxer and tick only the box of the first video stream!

• As for the second point, if you intend to use the DEMUX function starting from REMUXed files (even those created with the latest version of MakeMKV), in case you want to recreate a BL_EL_RPU.hevc file you MUST NECESSARILY use version 0.0.4 ALFA of my program. Previous versions (<= 0.0.3) will not be able to complete the analysis and writing cycle of the file.

• It's an experimental version, there are likely to be errors in the code ( ).
  If you provide me with relevant feedback, I will try to improve it!

unfortunately Yusesope's tool didn't helped for my setup, since it only makes dvhe.08.06, BL+RPU and dvhe.06.06, BL+EL+RPU

what I need is dvhe.05.06, BL+RPU

My tool returns a RAW HEVC file.
If you don't like meat prepared by the cook, don't take it out on the supplier who sold him raw meat.
There is a reason (widely debated on the pages of this thread) why tsMuxer chose one profile and not another.
In your case, since you need a file with profile dvhe.05, I would simply force the application behavior by modifying the source code you find on Github. Just comment out the part of the code that decides the type of profile (the file is hevcStreamReader.cpp), insert two simple lines of code ("profile = 5;" the first and "compatibility = 0;" the second) and compile the app with the changes made.

The user @shawnc22 has done this in the past. He's kind and resourceful, maybe you could ask him if you're having trouble.

It'd be interesting to "split" them into separate layers. Maybe see if we can use the RPU with x265's RPU option, though I don't know if that would even work.

What you are referring to are RPU metadata. If you want to know what's inside, @jcdr428 (one of tsMuxer's contributors) has lines of code suitable for this purpose: you could ask him if he wants to share his work.

At the moment, the algorithm that generates these metadata is unknown.
I believe that if you re-encode the various layers with x265 you must also modify the RPU parameters at the same time.
Without the algorithm that generates them, however, I don't think it can be done.

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?

[yusesope]

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.

[shawnc22]

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.

Got it, thanks for the clarification! It seems to me that a FEL->MEL conversion, and maybe followed by a conversion to IPTPQc2/IPT color space if profile 5 is desired, is kind of the “holy grail” for maximizing compatibility across devices. I know the Shield has been playing FEL titles fine, but I’ve always wondered if it’s doing it correctly since only profile 4 MEL is supposedly supported. FEL->MEL does seem like a daunting task, but maybe not as impossible as it once looked according to mike here?

2. Dolby engineering is sort of "straightforward". For years(!!!) we have discussed what a complex job would be to convert DV streams and how million dollar software and NDA specs are required. Outcome? Converting from double-PID to single-PID is a matter of prefixing a single byte per packet. And with Dolby patents released in December 2019 we now know entire DV RPU structure - MakeMKV currently detects MEL and FEL streams, and to do so it parses 90% of RPU unit. It is not that hard. So, with current knowledge, even the "impossible" task of converting double-layer FEL to single-layer MEL looks quite doable - not as trivial as prefixing a byte, but not an impossible task either - decode EL layer, render data, encode coefficients back with MEL parameters, profit. Code complexity - like any codec, similar to decoding an ac3 frame.

And as for the IPTPQc2 conversion, I know the colorspace is a dolby proprietary one, but maybe the conversation here is of some help:

https://github.com/mpv-player/mpv/issue ... -613134501

[Epedemic]

A few (stupid?) questions:

dvhe.04.06 is to be understood as a Dolby Vision (dv) HEVC (he) 10 bit 4K 24fps (06) file, with a 1080p MEL or FEL (04) right?

And dvhe.06.06 should not exist according to https://www.dolby.com/us/en/technologie ... levels.pdf ?

But as i generate 04.06 files using both the makemkv->eac3to->tsmuxer and yusesope's tool in default mode, and both play fine on my Shield 2019, i must be doing everything right?

However i found some files from another source in dvhe.06.06 which plays equally fine, so i really shouldn't give a damn, and assume both are good as long as they play, but with slightly different metadata tagging?

[VictorLemon]

Hello, a question to see who can help me, when the movie is in several m2ts, how can I extract the BL and EL files to mount with the tool?
a greeting

[Epedemic]

Hello, a question to see who can help me, when the movie is in several m2ts, how can I extract the BL and EL files to mount with the tool?
a greeting

eac3to will do that.

[shawnc22]

A few (stupid?) questions:

dvhe.04.06 is to be understood as a Dolby Vision (dv) HEVC (he) 10 bit 4K 24fps (06) file, with a 1080p MEL or FEL (04) right?

And dvhe.06.06 should not exist according to https://www.dolby.com/us/en/technologie ... levels.pdf ?

But as i generate 04.06 files using both the makemkv->eac3to->tsmuxer and yusesope's tool in default mode, and both play fine on my Shield 2019, i must be doing everything right?

However i found some files from another source in dvhe.06.06 which plays equally fine, so i really shouldn't give a damn, and assume both are good as long as they play, but with slightly different metadata tagging?

Profile 6 is a deprecated standard, so you're not going to find it in the latest dolby docs. The difference between 4 and 6 is in its backwards compatibility ID (SDR for 4 and HDR for 6). Purely specs-wise, the video tracks generated from yusecope's tool and makemkv should be either profile 6 or 7 since they are HDR10 compatible. But since most devices don't support profiles 6/7, they are forced to profile 4 in tsmuxer (either through an older version of tsmuxer or a modified nightly version). When playing back DV content on a supported device, the backwards compatibility ID doesn't matter, so it's not really a big deal to incorrectly label these files as 4 for the pure purpose of DV playback.

In terms of the Shield, yusecope has mentioned in the past that when exoplayer encounters an unsupported DV profile, it likely looks at the video stream and then chooses the best suitable supported profile to play the file. So for instance when it encounters a BL+EL+RPU track that's labeled profile 6 or 7, it will fallback to treating it as profile 4 and still play them just fine.

[olevelo]

So are you saying that if we play back one of the profile 4 videos on a non-DV device we won't even get HDR10?

[Epedemic]

Profile 6 is a deprecated standard, so you're not going to find it in the latest dolby docs. The difference between 4 and 6 is in its backwards compatibility ID (SDR for 4 and HDR for 6). Purely specs-wise, the video tracks generated from yusecope's tool and makemkv should be either profile 6 or 7 since they are HDR10 compatible. But since most devices don't support profiles 6/7, they are forced to profile 4 in tsmuxer (either through an older version of tsmuxer or a modified nightly version). When playing back DV content on a supported device, the backwards compatibility ID doesn't matter, so it's not really a big deal to incorrectly label these files as 4 for the pure purpose of DV playback.

In terms of the Shield, yusecope has mentioned in the past that when exoplayer encounters an unsupported DV profile, it likely looks at the video stream and then chooses the best suitable supported profile to play the file. So for instance when it encounters a BL+EL+RPU track that's labeled profile 6 or 7, it will fallback to treating it as profile 4 and still play them just fine.

Thanks That clarified a lot for me.

[shawnc22]

So are you saying that if we play back one of the profile 4 videos on a non-DV device we won't even get HDR10?

With a fully-compliant profile 4 video, no, I don't believe you will get even HDR10 on a non-DV device. Take the LG DV demo from here for example:

https://4kmedia.org/lg-dolby-comparison-uhd-4k-demo/

This file in mediainfo is listed as:

Code: Select all

Dolby Vision, Version 1.0, dvhe.04.06, BL+EL+RPU

whereas the profile 4/6 files we have been generating is labeled as:

Code: Select all

Dolby Vision, Version 1.0, dvhe.04.06, BL+EL+RPU / SMPTE ST 2086, HDR10 compatible

On my Xbox one X, the LG demo doesn't even trigger HDR, but the other files will. This then brings up the question whether devices are really looking at just the profile to determine playback capabilities or at the actual content of the video stream. This I honestly have no idea and could simply be a device-to-device question.