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:
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?
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.
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.
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.
I extract the BL and EL files through eac3to, the movie is Despicable Me (2010), to extract charge in eac3to the main mpls, since the movie is in several m2ts, it generates the BL and EL, I use the yusesope tool in its latest version and when the process is at 99.9% it gives me the following error.
I extract the BL and EL files through eac3to, the movie is Despicable Me (2010), to extract charge in eac3to the main mpls, since the movie is in several m2ts, it generates the BL and EL, I use the yusesope tool in its latest version and when the process is at 99.9% it gives me the following error.
Greetings
Don't worry, the file you got is complete (only one byte is missing).
The error is due to your input file: it is not complete at the end.
I extract the BL and EL files through eac3to, the movie is Despicable Me (2010), to extract charge in eac3to the main mpls, since the movie is in several m2ts, it generates the BL and EL, I use the yusesope tool in its latest version and when the process is at 99.9% it gives me the following error.
Greetings
Don't worry, the file you got is complete (only one byte is missing).
The error is due to your input file: it is not complete at the end.
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?
the problem is not the conversion of the color space.
The problem is understanding how to generate new RPU metadata without distorting the color correction/grading work done in post production and the entire vision of the director.
With what we've discovered, you could take a video shot on your cell phone and insert random RPU metadata.
The video would be reproduced by activating Dolby Vision but the colors would be completely wrong!
Here's my success story for Gemini Man 2019 which is a 60fps movie which plays much more fluent.
I'm using Fedora 31 Linux but I've also posted windows links
- Click Input File and select atmos.mp4
- Under Track Input and Output format change "ac3" to "thd+ac3" then click Add
- In the bottom click RUN CL and wait
When finished you will have a "atmos.mp4_.thd+ac3" file, rename this to "atmos.ac3"
Now launch justdan96's version of TsMuxerGUI then add your movie file: "gemini_dv.hevc" and audio file: "atmos.ac3".
So I have tried this method for Gemini man and Sonic 2019 and both of them freeze every 2 seconds during playback. My tv is lg oled c9. The files were stored in an external hdd connected to the tv via usb. All other souble layered dolby vision mp4 files created using the original method in the first post of this thread play fine. Maybe my tv can't properly play .ts file/single layered dolby vision file?
Here's my success story for Gemini Man 2019 which is a 60fps movie which plays much more fluent.
I'm using Fedora 31 Linux but I've also posted windows links
- Click Input File and select atmos.mp4
- Under Track Input and Output format change "ac3" to "thd+ac3" then click Add
- In the bottom click RUN CL and wait
When finished you will have a "atmos.mp4_.thd+ac3" file, rename this to "atmos.ac3"
Now launch justdan96's version of TsMuxerGUI then add your movie file: "gemini_dv.hevc" and audio file: "atmos.ac3".
So I have tried this method for Gemini man and Sonic 2019 and both of them freeze every 2 seconds during playback. My tv is lg oled c9. The files were stored in an external hdd connected to the tv via usb. All other souble layered dolby vision mp4 files created using the original method in the first post of this thread play fine. Maybe my tv can't properly play .ts file/single layered dolby vision file?
Well, i'm not sure, but it sounds like what my E6 did when i accidentially fed it a .mp4 with a Atmos thd+ac3 file renamed to .ac3 waaaay back.... My suggestion: Try with a clean ac3 file and see if that helps, and then figure out how to do a proper thd+ac3 track afterwards (or put both in and switch between them and see if one or both works)
Here's my success story for Gemini Man 2019 which is a 60fps movie which plays much more fluent.
I'm using Fedora 31 Linux but I've also posted windows links
- Click Input File and select atmos.mp4
- Under Track Input and Output format change "ac3" to "thd+ac3" then click Add
- In the bottom click RUN CL and wait
When finished you will have a "atmos.mp4_.thd+ac3" file, rename this to "atmos.ac3"
Now launch justdan96's version of TsMuxerGUI then add your movie file: "gemini_dv.hevc" and audio file: "atmos.ac3".
So I have tried this method for Gemini man and Sonic 2019 and both of them freeze every 2 seconds during playback. My tv is lg oled c9. The files were stored in an external hdd connected to the tv via usb. All other souble layered dolby vision mp4 files created using the original method in the first post of this thread play fine. Maybe my tv can't properly play .ts file/single layered dolby vision file?
Well, i'm not sure, but it sounds like what my E6 did when i accidentially fed it a .mp4 with a Atmos thd+ac3 file renamed to .ac3 waaaay back.... My suggestion: Try with a clean ac3 file and see if that helps, and then figure out how to do a proper thd+ac3 track afterwards (or put both in and switch between them and see if one or both works)
Why don't just demux TrueHD track with tsmuxer? It's perfectly recognised, when muxing back with DV hevc file.
That clarified a lot for me.