Dolby Vision now possible through MP4 Mux.

[Angryunibrow]

the command program suddenly stopped working with birds of prey. anyone the same issue? the DV file is continue 0kb. anyone the same?

Worked fine for me

[box4m]

profile 7 is dual layer or no?

yep

amazing

[thetoad]

Have just created an ATMOS/DV for Gemini Man and have a few questions for the group. My process is simple: Clean ISO -> MPLS -> TSMuxer->TS or M2TS. Questions:

1) Why is the M2TS file 1.5GB larger? The same source file was used for both results - I simply used a different muxing option (TS vs M2TS) in TSMuxer and the TS file is 78,662,097 KB vs M2TS is 80,364,042 KB. Seems like an awful lot of overhead for M2TS. MediaInfo shows that the Overall/Maximum bit rate is 91.8/35.5 Mb/s for the TS, whereas for the M2TS file they are 93.7/35.5. Curious?

2) What is the advantage to using M2TS? My setup is NAS->X700->DV/ATMOS AVR->4K TV. It seems that the X700 has pause/FF/RW issues with TS files - same issue with M2TS?

3) MediaInfo tells me that neither file has the THD track (but MKV Toolnix disagrees, must be bug in MediaInfo). Although clearly not the case, MediaInfo audio shows:
Compression mode : Lossy
Stream size : 536 MiB (1%)

4) Both files show: Dolby Vision, Version 1.0, dvhe.07.07, EL+RPU, 8 compatible / SMPTE ST 2086, HDR10 compatible. Is this compatible with correct profile.level for usage in X700? (What is level exactly?)

Thanks in advance...

M2TS files are basically (almost literally) the exact same thing as TS, just a bit more than 2% larger. (i.e. 188 byte packets vs 192 byte packets). i.e. per packet they have an extra 4 byte header. The only advantage M2TS has over TS is that its the bluray spec, and TS isn't (due to the 4 byte extra header). That's it.

For example: take any code that can parse TS streams, teach it that M2TS streams have 192 byte packets instead of 188 byte packets (so reading should be based on 192 byte, not 188 byte, boundaries) and to ignore the first 4 bytes (so treat byte 5 of the m2ts packets as byte 1 of a TS packet, byte 192 of the m2ts packet as byte 188 of a TS packet....) and the code will work perfectly, because they are effectively the same exact same thing at that point.

[idpseudonymous]

I understand that the Shield reads only DV marked as profile 5. However Blu-ray profile 7 dual tracks changed to single tracks should be profile 8 and not profile 5, as the BL is BT.2100 and not Dolby IPT colorspace. The Shield SoC seems to be able to read any DV as long as it is marked profile 5, so this is something that should be addressed by NVidia in a firmware rather than allowing to disseminate non-compliant DV files.

I think the Shield is good with reading single track+dual layer dv profile 4, and single track+single layer profile 5 and 8 videos. Dual track+dual layer profile 7 videos have always been the problem, hence yusecope's tool to merge the tracks but keep the layers still separate (or the -mode 2 option to also merge the layers). The issue somebody was having was with an Apple TV 4k not reading a ST+SL file in prof 8, but when the same video track is remuxed in 5, it'd work perfectly. Probably an issue with the Apple TV not supporting prof 8

Apple TV 4K only supports Profile 5. Apparently, the all-new Shield TV supports Profile 4 and 5. And with Profile 4, you get both: single track dual layer and single track single layer and all with lossless audio and ATMOS/DTS-X.

Sorry I am new to all this. Trying to learn more and making my way through the long thread. But maybe someone can answer my question real quick.

Question about Audio Coding 3 + Meridian Lossless Packing Dolby TrueHD with Atmos. Is this lossless audio or Lossy audio?

I am not sure what the answer is. The wonder woman Media info detail shows lossless and Shazam looks lossy to me but what does the AC3 + Meridian lossless packing do?

https://en.wikipedia.org/wiki/Dolby_TrueHD writes,

" Dolby TrueHD is a lossless multi-channel audio codec ... It is one of the successors to the Dolby Digital (AC-3) surround sound codec "

" Dolby TrueHD uses Meridian Lossless Packing (MLP) as its mathematical basis for compressing audio samples"

I discovered this forum from https://forums.plex.tv/t/dolby-vision-d ... lex/561151 explaining the workflow/tools. Will using this method result in lossless audio that is not AC3 + Meridian lossless packing

TIA
-------------------------------------------------------------------------------------------------------------------
Wonder Woman media info audio file
ID : 2
Format : MLP FBA 16-ch
Format/Info : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Codec ID : A_TRUEHD
Duration : 2 h 21 min
Bit rate mode : Variable
Bit rate : 4 279 kb/s
Maximum bit rate : 7 509 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 1 200.000 FPS (40 SPF)
Compression mode : Lossless
Stream size : 4.22 GiB (29%)
Language : English
Default : Yes
Forced : No
Number of dynamic objects : 11

--------------------------------------------------------------------------------------------------------------------------------------------------------------

General
ID : 1 (0x1)
Complete name : B:\Media\Blu-Ray_Movies\Shazam! (2019) - 2160p Dolby Vision Atmos\Shazam! (2019) - 2160p Dolby Vision Atmos.m2ts
Format : BDAV
Format/Info : Blu-ray Video
File size : 78.7 GiB
Duration : 2 h 11 min
Overall bit rate mode : Variable
Overall bit rate : 85.5 Mb/s
Maximum Overall bit rate : 35.5 Mb/s

Video
ID : 4117 (0x1015)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : Dolby Vision, Version 1.0, dvhe.08.06, BL+EL+RPU / SMPTE ST 2086, HDR10 compatible
Codec ID : 36
Duration : 2 h 11 min
Bit rate : 81.7 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
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.411
Stream size : 75.2 GiB (96%)
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: 4000 cd/m2
Maximum Content Light Level : 1351 cd/m2
Maximum Frame-Average Light Level : 384 cd/m2

Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3 MLP FBA 16-ch
Format/Info : Audio Coding 3 + Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Muxing mode : Stream extension
Codec ID : 131
Duration : 2 h 11 min
Bit rate mode : Variable
Bit rate : 448 kb/s
Maximum bit rate : 5 931 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 422 MiB (1%)
Language : English
Service kind : Complete Main
Number of dynamic objects : 15
Bed channel count : 1 channel
Bed channel configuration : LFE

[darrrkmanxxx]

Has anyone achieved profile 5 in a TS?

[Angryunibrow]

Has anyone achieved profile 5 in a TS?

Every movie

[yusesope]

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.

[ragico]

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!

First a very big thank you for the new tool.
I am going to try the Demux tool. Once demuxed how can I mux again with the new Alfa tool in -mode 2 (BL+RPU)?

Edit: Demuxed Cold Pursuit BL_EL_RPU and got BL and EL_RPU. Muxed this 2 files with your new tool in -mode 2 and the muxed file in tsmuxer profile5 (single layer). This final file works beautifully in Apple 4k via Infuse app with DV and LPCM audio.
Thank you maestro, you are a genius.

[EvanVanVan]

Hi,

I read the the past 10+ pages but couldn't see anything definitive, did something new come out where DV rips with lossless audio are possible?

Thanks

[Epedemic]

First of all thank you for these new developements!

And then a little reminder that this is still very much "beta" all the way through:

My setup is a Shield Pro 2019 -> Onkyo RZ820 -> LG E6 OLED.

I was losing my mind over this: I saw some rather nasty color banding/oversaturation on some DV content: First i noticed it in Westworld Season 1 Episode 1, the second scene, about 2:40 in, where Dolores wakes up, i saw some green bands on her skin, primarily her right arm (center screen) and... ehm, chest, and on the wall when she is walking down the stairs afterwards. Thought it was badly colored, but when playing in regular HDR in Kodi it looked fine. So i tried The Mandalorian Episode 1 on D+, and immediately spotted horrible banding in the very first scene (on the right side of the screen) and an overblown highlight in the light coming through the clouds.... Tried the TV built in app: looked much better.... So i suspected the shield. But it seems it plays DV content just fine after a reboot. ONCE... And then stuff with DV i play/stream afterwards suffers issues... It *might* be triggered by Kodi somehow... It *might* be triggered by refresh rate change... It *might* just be my particular system, but that is all speculation.

tl;DR: You may need to reboot your shield before playing or streaming DV content... It *might* be buggy and produce banding/oversaturation otherwise...

[Donpoku]

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.

A drink on me m8 skillfully genius Thx

[Donpoku]

Hi,

I read the the past 10+ pages but couldn't see anything definitive, did something new come out where DV rips with lossless audio are possible?

Thanks

Yes in TS/M2TS format and mkv(storage purpose only as no software/hardware can read it yet)

[Trujax]

I have compiled a TsMuxer that forces dvhe.05.06 profile. It works nice where 08.06 played choppy in my Lg. You can find it here http://katfile.com/1uvd80v1b0zd/tsMuxer ... ).zip.html

[darrrkmanxxx]

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.

Of course man, thanks you so much for helping. I just didn't knew that it has to do with tsmuxer and not with your tool. That's why I'm asking.

[darrrkmanxxx]

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.

Of course man, thanks you so much for helping. I just didn't knew that it has to do with tsmuxer and not with your tool. That's why I'm asking.