tsMuxer Open Source

[a5180007]

Hi justdan96, could you please hold to 2.6.15 as I will keep on submitting commits over the week-end for the additional UHD formats/fps.
Can anybody share the ExtensionData formatting info (Jdobbs ? Pelican ?) for HDR10+, Dolby Vision and SL-HDR so that we can incorporate it into .clpi/.mpls/.bdmv as required.

[justdan96]

Sure, we still have some things to sort out before the point release anyway so I don't mind holding off for a bit.

[Hart2hart]

I can see you guys are busy over at GitHub!
Before I dive in two questions:

o Do you think any of the custom libraries you replaced with standard version would have included custom versions of named functions?

o Is there a module/object interaction diagram or would it be simpler to just pull all source into an ide like visual studio and let it build one?

Thanks!

[jdobbs]

Hi justdan96, could you please hold to 2.6.15 as I will keep on submitting commits over the week-end for the additional UHD formats/fps.
Can anybody share the ExtensionData formatting info (Jddobs ? Pelican ?) for HDR10+, Dolby Vision and SL-HDR so that we can incorporate it into .clpi/.mpls/.bdmv as required.Here's what I found for the MPLS extension based on looking at a number of original discs:

00 00 00 38 Length of ExtensionData()
00 00 00 18 Data block start address
00 00 00 01 24 bits reserved followed by number_of_ext_data_entries (1)
00 03 00 05 ID1 (0x3) and ID2 (0x5) of the extension
00 00 00 18 ext_data_start_address
00 00 00 24 ext_data_length
00 00 00 20 length of following data (?)
01 00 00 00
10 00 00 00
HDR_DATA 24 bytes

Example of HDR_DATA:
33 C2 86 C4 Master Display=G(13250,34500)
1D 4C 0B B8 B(7500,3000)
84 D0 3E 80 R(34000,16000)
3D 13 40 42 WP(15635,16450)
0F A0 00 32 L(40000000,50) = Mastering display luminance: min: 0.0050 cd/m2, max: 4000 cd/m2 = 4000/50
07 8D 02 C5 cll=1933,709Note that the luminance is stored using factors of 10,000 (min * 10,000 and max / 10,000) -- I don't know why. I would assume so they can fit in a 16 bit integer.

Dolby seems to use the same extension, not sure about SL-HDR.

Here is the extension for index.bdmv

00 00 00 20 Length of ExtensionData()
00 00 00 18 Data block start address
00 00 00 01 24 bits reserved followed by number_of_ext_data_entries (1)
00 03 00 01 ID1 (0x3) and ID2 (0x1) of the extension
00 00 00 18 ext_data_start_address
00 00 00 0C ext_data_length
00 00 00 08 I think this is length of following info
21 00 03 00 upper nibble of first byte is disc type (0x2 = BD25/50), not sure about 0x03*
00 00 00 00 seems to be reserved...

*Made a correction to the index.bdmv extension data. I'd put a value of 0x20 at offset 24, and it should have been 0x21

[12/13/2019]

Please note also that for UHD the version_number of the .index, clpi, and MPLS files have to be set to "0300" instead of "0200". In addition the video_format variable in the CLPI's ProgramInfo() table must be set to 0x8 for 2160p. Currently TSMUXER sets it to 0x6 (1080p). The stream_coding_type must be set to 0x24 for HEVC.

In order to do dolby vision, TSMUXER will have to be modified so the stream id for the dolby vision extension stream is set to 4117 and an additional entry for dolby vision must be added to the STN_table()

*Made a correction to the index.bdmv extension data. I'd put a value of 0x20 at offset 24, and it should have been 0x21
[Dec 13, 2019]

[justdan96]

o Do you think any of the custom libraries you replaced with standard version would have included custom versions of named functions?


I'm not too sure actually - but I did pick out the pull requests where the replacements were made so you should be able to check it yourself:
https://github.com/justdan96/tsMuxer/pull/16/commits/b098a6de41fdaaa2aee9f6d9f7a15072f17cf780
https://github.com/justdan96/tsMuxer/pull/22/commits/0fd3b37746af0836ae59bffecf0d75cc53add9cc
https://github.com/justdan96/tsMuxer/pull/21/commits/721d5c12d9591cd48d376b28f19ace39b8fc6cf1


o Is there a module/object interaction diagram or would it be simpler to just pull all source into an ide like visual studio and let it build one?


There isn't a diagram currently. I just had a quick search around and it looks like maybe Doxygen can be used together with Graphviz to generate one. Something for me to think about!

[a5180007]

@jdobbs thanks, this HDR metadata info is exactly what I was looking for!

Current progress:
- The patch for changing BD version to 0300 has already been merged in the master;
- The patch for setting coding_type to 0x24 has also already been merged in the master;
- I've just submitted the patch for setting video_format to 8 for UHD;
- Also bugs were corrected for frame size limitation, and for MP4/AAC and EAC3 bitrates and channels.

@justdan96 tsMuxeR should now be able to author UHD but without HDR.
The HDR modifs in .clpi, .mpls and .bdmv will require a bit of time, first I need to understand how to extract the HDR metadata info from the HEVC SEI.
Let's say HDR (excl. Dolby Vision) will be my objective for 2.6.17...

[staina]

Where it is possible download new version for Windows?
How is far full support UHD Bluray including HDR, Dolby Vision, Dolby Atmos?
Is already fixed loaded 3D - plane at 3D Bluray?

Thank for answer. Staina

[Video Dude]

Hopefully there will be a reconsideration and 32 bit binaries can be built. One main way to capture transport streams from hardware is the 1394 firewire port. There are no Windows 64 bit drivers that work. Using a Windows 32 bit version is a must. Users don't want to capture on 1 PC and then transfer to stream to a second machine to mux.

[filler56789]

Hopefully there will be a reconsideration and 32 bit binaries can be built.

32-bit binaries CAN be built. The problem is, justdan96 simply doesn't care about them. Also, his workflow became *nix-centric, which means even the Windows builds of tsMuxeR now require a posix-threaded compiler.

[a5180007]

@xavery @justdan96 under Windows/MSVC I can't remove #include "stdafx.h" from textSubtitles.cpp without having 171 errors (!!), see file:
Error.Log.txt (https://github.com/justdan96/tsMuxer/files/3907591/Error.Log.txt)

Any alternative to get rid of stdafx.h ?

Edit : found the solution: actually the "rarely-used stuff from Windows headers" is still required i.e. we need to add #define WIN32_LEAN_AND_MEAN in textSubtitles.h

[Richard1485]

Additionally I've taken a close look at tsMuxerGUI and there aren't any actual code dependencies on tsMuxer - so a drop-in replacement could be created.

That would be useful. On Linux, I found that the GUI worked fine but threw a series of errors upon first use, most of which seemed to relate to cosmetic aspects of the interface. (At the time, I was using 2.6.9 for reasons outlined earlier in the thread.)

[justdan96]

I didn't think there would be much demand for 32-bit binaries, it does look like the demand is there so I'm pretty sure it would be easy enough to set up in CMake and I can just create a separate build.

Latest (64-bit) binaries for the CLI are available on GitHub, I'm still working on getting the GUI created automatically but I now know how I'll get tsMuxerGUI builds made for Linux and Windows so it's just MacOS where I need to do some more experimenting.

Also I moved house over the weekend so things may be a bit slower the next couple of weeks while I get broadband set up.

[hubblec4]

Hi justdan96

Very nice to see this project is going on. Could you tell me where I can download the latest version?

[filler56789]

Could you tell me where I can download the latest version?

From my Mediafire folder:

http://www.mediafire.com/file/4nlp9ap0wijbhqb/tsMuxeR64-2.6.15.b-.rar/file

[justdan96]

Hi justdan96

Very nice to see this project is going on. Could you tell me where I can download the latest version?

Official binaries are available on GitHub, take a look at the readme for more details!

https://github.com/justdan96/tsMuxer

[filler56789]

Official binaries are available on GitHub, take a look at the readme for more details!

https://github.com/justdan96/tsMuxer

Evidently justdan96 ignores the fact that not everybody has /wants-to-create a GitHub account.

To download the pre-compiled binaries head over to the following URL (YOU MUST BE LOGGED IN)

[FilipeAmadeuO]

Evidently justdan96 ignores the fact that not everybody has /wants-to-create a GitHub account.
I must say that i do agree :)
Any chance to download binary without sign in to GitHub ?

[hubblec4]

Official binaries are available on GitHub, take a look at the readme for more details!

https://github.com/justdan96/tsMuxer

Was not so easy to find, but I found it. It seems there is a tsMuxer.exe only at the moment, right?

I'm mostly interested in demuxing. How good works the new tsMuxeR?

Seamless branching disc's supported? Remove/Skip identical frames?
I had read that the last old rev of tsMuxeR has issues with subtitle streams, this issues are fixed?

E-AC3 EX support?

[Video Dude]

I didn't think there would be much demand for 32-bit binaries, it does look like the demand is there so I'm pretty sure it would be easy enough to set up in CMake and I can just create a separate build.


Thank you justdan96. Much appreciated.

[r0lZ]

I'm mostly interested in demuxing. How good works the new tsMuxeR?
I have just tried it to demux a few 3D DBs (not UHD), and it seems to work correctly.

Seamless branching disc's supported? Remove/Skip identical frames?

I suppose that the code that does that in the original version has not been modified, so I guess it's OK.

I had read that the last old rev of tsMuxeR has issues with subtitle streams, this issues are fixed?

Unfortunately, that bug has been added in v2.6.10 or v2.6.11, and I suppose that the latest closed source version (v2.6.12) has been used as the basis for the open source development. So, I suppose that the bug is still present. Unfortunately, that bug happens only in some relatively rare cases, and I don't remember what BD has caused it, so I have been unable to check if the bug is still present. I will try to find a good example and report it here, but that may take some time. Currently, if you want to be sure, I suggest to use v2.6.9 (although it has other bugs with the 3D-planes, not important for a 2D BD, but that should be fixed too). Or, use the new version and verify carefully the subtitles timings. If you find an example of bad timings, report it yourself, to help the developers.

[hubblec4]

Thanks for your answer r0IZ. When I have a bit time I will test some BDs and report issues.

[r0lZ]

BTW, I've found the post I wrote about that subtitle timing bug. You can read it here (https://forum.doom9.org/showthread.php?p=1689236#post1689236).
As you can see, it happens only with movies with several parts (multi-angle, multi-story or simply split for protection purpose), and furthermore it's not always the case. For example, the multi-angle Disney BD are not affected. Difficult to test in that conditions, but you can exclude all BDs made of only a single M2TS.

[hubblec4]

OK, I read this post, interesting. I hope justdan96 can fix all this issues.
Mostly BDs are authored with one m2ts file, but all the great movies have often multiple editions and for me is it a must to store all editions in a single mkv.

[justdan96]

I must say that i do agree :)
Any chance to download binary without sign in to GitHub ?

I'm working on it! I've opened an issue in GitHub to track it and I just today got a tsMuxerGUI build working on MacOSX so the official binaries for the CLI and GUI should be going into the "Releases" section on GitHub soon.

It will just be slow progress for a while, there's lots of things we still need to sort out for my house move - least of all broadband!

[FilipeAmadeuO]

I'm working on it! I've opened an issue in GitHub to track it and I just today got a tsMuxerGUI build working on MacOSX so the official binaries for the CLI and GUI should be going into the "Releases" section on GitHub soon.

It will just be slow progress for a while, there's lots of things we still need to sort out for my house move - least of all broadband!
Perfect. I am GUI type user so take your time :)

[filler56789]

FWIW... Baldrick is sharing the "unofficial" 2.6.15 binaries for Mac, Linux and Windows — but no GUI yet (sadly - ?)

https://www.videohelp.com/software/tsMuxeR

[gonca]

You can always try the GUI from 2.6.12 with tsMuxeR.exe 2.6.15.
Seems to work ok

[jdobbs]

To those who are making changes:

How hard would it be to flag a secondary video track and set its PID as 4117? I'm testing using v2.6.15 in creation of the UHD Blu-Ray's M2TS (so that BD Rebuilder doesn't have to remux/correct the video streams and PMT packets again afterward). I have it working for non-DolbyVision sources, but in order to support DolbyVision, I need to be able to have the dolby stream's PID be 4117 in the packet headers and the PMT.

Any help would be deeply appreciated.

[BloodyRipper]

To those who are making changes:

How hard would it be to flag a secondary video track and set its PID as 4117? I'm testing using v2.6.15 in creation of the UHD Blu-Ray's M2TS (so that BD Rebuilder doesn't have to remux/correct the video streams and PMT packets again afterward). I have it working for non-DolbyVision sources, but in order to support DolbyVision, I need to be able to have the dolby stream's PID be 4117 in the packet headers and the PMT.

Any help would be deeply appreciated.
The code actually looks ready for setting custom PIDs for the elementary streams making up the TS, but these are currently hardcoded to a number of base values which are then offset by the number of the given streams already in the TS, according to its type.

Would you be okay with setting a custom PID via the meta file? Sounds like it could suit your use case.

[jdobbs]

The code actually looks ready for setting custom PIDs for the elementary streams making up the TS, but these are currently hardcoded to a number of base values which are then offset by the number of the given streams already in the TS, according to its type.

Would you be okay with setting a custom PID via the meta file? Sounds like it could suit your use case.That would be perfect.

[a5180007]

How hard would it be to flag a secondary video track and set its PID as 4117? I'm testing using v2.6.15 in creation of the UHD Blu-Ray's M2TS (so that BD Rebuilder doesn't have to remux/correct the video streams and PMT packets again afterward).

@jdobbs I am working on it: it needs an early scan of the hevc streams -to detect the DV \x62 (+\x01) nal_unit_type- before tsMuxer assigns the new video PIDs.

I'll push the patch as soon as the patch for HDR10/HDR10+ has been merged/tested.

[filler56789]

@justdan96:

the 24-bit DTS-Express muxing bug in the GUI, ¿has it been fixed?

[jdobbs]

@jdobbs I am working on it: it needs an early scan of the hevc streams -to detect the DV \x62 (+\x01) nal_unit_type- before tsMuxer assigns the new video PIDs.

I'll push the patch as soon as the patch for HDR10/HDR10+ has been merged/tested.Can you give me a heads up when it gets integrated?

This new version sure makes BD-RB's life easier. All it has to do now is do updates to the MPLS & CLPI after a TSMUXER run (except, of course, for DV). That's the easy (and quick) part. If you need anything from me, just let me know.

Thanks!

[jdobbs]

@jdobbs I am working on it: it needs an early scan of the hevc streams -to detect the DV \x62 (+\x01) nal_unit_type- before tsMuxer assigns the new video PIDs.

I'll push the patch as soon as the patch for HDR10/HDR10+ has been merged/tested.Also, please note that I corrected a mistake I had in the post about extensions. I'd mistakenly put a value of 0x20 instead of 0x21 in one bye of the index.bdmv extension.

[BloodyRipper]

Can you give me a heads up when it gets integrated?

This new version sure makes BD-RB's life easier. All it has to do now is do updates to the MPLS & CLPI after a TSMUXER run (except, of course, for DV). That's the easy (and quick) part. If you need anything from me, just let me know.

Thanks!
I took the liberty of implementing this via an explicit parameter in the meta file. The pull request (https://github.com/justdan96/tsMuxer/pull/74) is already there, but will probably be merged to master only after I add support in the GUI as well. You can download the experimental build here (https://drive.google.com/open?id=1GrqSNIJP_1wU4ND69FkDCMTaJGI_jQaQ). PIDs can be assigned to streams by adding a simple numeric parameter called "pid" to the stream description in the meta file, for example :


V_MPEG4/ISO/AVC, "raw/video.h264", insertSEI, contSPS, pid=666
A_AC3, "raw/audio01.ac3", pid=0xf0f

Perhaps you can test if everything works fine while proper support for DV streams is in the works. The custom PIDs are of course also used in the PMT.

[filler56789]

Ouch, it seems justdan96 really loves to complicate things :scared:

Create Way of Downloading Binaries without Sign-In

https://github.com/justdan96/tsMuxer/issues/60

Why he doesn't simply upload the releases to GitHub OR share the "beta binaries" on Google Drive /Mediafire /whatever is beyond me.

[a5180007]

Also, please note that I corrected a mistake I had in the post about extensions. I'd mistakenly put a value of 0x20 instead of 0x21 in one bye of the index.bdmv extension.

@jdobbs, in fact I've put 0x51 in the commit (5=66/100 GB disk 123 Mbps, 1=4k). The patch includes reading of HDR10/HDR10+ metadata in the hevc SEI nal, detection of DV nal_unit, adding the HDR10/HDR10+ attribute in the .mpls and .clpi, the additional DV field in the playlist STN table, and the extention data to .mpls and .bdmv. So the change to the DV PID is really all what is missing.

The best would be that justdan96 pushes the HDR commit to an alternative branch for thorough testing.

Edit:
21 00 03 00 upper nibble of first byte is disc type (0x2 = BD25/50), not sure about 0x03*
The new BDEdit has been of great help, thanks pelican. The second byte in the .bdmv is : 3-bit zero/reserved, isHDR10+, isSL-HDR2, isDV, isHDR10, isSDR.

Are there any Blu-ray already released with SL-HDR2 ?

[jdobbs]

@jdobbs, in fact I've put 0x51 in the commit (5=66/100 GB disk 123 Mbps, 1=4k). The patch includes reading of HDR10/HDR10+ metadata in the hevc SEI nal, detection of DV nal_unit, adding the HDR10/HDR10+ attribute in the .mpls and .clpi, the additional DV field in the playlist STN table, and the extention data to .mpls and .bdmv. So the change to the DV PID is really all what is missing.

The best would be that justdan96 pushes the HDR commit to an alternative branch for thorough testing.

Edit:

The new BDEdit has been of great help, thanks pelican. The second byte in the .bdmv is : 3-bit zero/reserved, isHDR10+, isSL-HDR2, isDV, isHDR10, isSDR.

Are there any Blu-ray already released with SL-HDR2 ?Can the 0x51 be modified to 0x21? Most of the reencodes I do are output to BD-25/50. I don't even have a burner that supports 66/100. If not, I can do it after the fact, I guess (as I do now).

When will this patch show up in the nightly releases (if that is the plan)?

Where do I get a copy of the latest BDEDIT? I looked at the BDEDIT thread and it looked like the last edit was many years ago. I use BDEDIT all the time. It's really useful software.

[jdobbs]

I took the liberty of implementing this via an explicit parameter in the meta file. The pull request (https://github.com/justdan96/tsMuxer/pull/74) is already there, but will probably be merged to master only after I add support in the GUI as well. You can download the experimental build here (https://drive.google.com/open?id=1GrqSNIJP_1wU4ND69FkDCMTaJGI_jQaQ). PIDs can be assigned to streams by adding a simple numeric parameter called "pid" to the stream description in the meta file, for example :


V_MPEG4/ISO/AVC, "raw/video.h264", insertSEI, contSPS, pid=666
A_AC3, "raw/audio01.ac3", pid=0xf0f

Perhaps you can test if everything works fine while proper support for DV streams is in the works. The custom PIDs are of course also used in the PMT.Thanks! I'll test it. Does this version also have the other changes made recently (like the correction for muxing HEVC UHD so it doesn't lose frames)?

[mood]

with lastest "w32-nightly-2019-12-14--14-44-59" build give me "tsMuxeR not found!" error and I have the "tsMuxeR.exe" and "tsMuxerGUI.exe" in the same folder.

Anyone can help??

[justdan96]

with lastest "w32-nightly-2019-12-14--14-44-59" build give me "tsMuxeR not found!" error and I have the "tsMuxeR.exe" and "tsMuxerGUI.exe" in the same folder.

I can see you've opened an issue, I'll respond in there.

Also I can see people have found the Bintray location for the nightly builds - that automated workflow is still a work in progress but once I have fully updated the documentation and have it all working correctly I'll post it here!

[BloodyRipper]

Thanks! I'll test it. Does this version also have the other changes made recently (like the correction for muxing HEVC UHD so it doesn't lose frames)?
No, not yet, since this build was made from the master with my "custom PID" patch applied. The UHD patch is still waiting to be merged, though I could prepare a build that includes it if you'd like to test it out.

[jdobbs]

I've noticed that a lot of UHD sources get this error:

- Bitstream exception std::exception. It does not have to be! Please contact application support team for more information.

Does anyone have an idea what causes this? Interestingly, if I take the same streams, mux them into an MKV, and then use the MKV as the source for TSMUXER -- the error goes away.

[Edit] It looks like this is a bug in TSMUXER's scanning of the bitstream. When it gets run through MKVMERGE the Access Unit Delimiter (AUD) is removed. That changes the whole stream. Since the AUD is required for UHD-BD this doesn't represent a solution. When I run my own remuxing routine the output works correctly, so it isn't a problem with the stream itself. Too bad.

Does anyone have the time to take a look at this? I could provide an hevc stream that causes the error (although it is about 20GB).

[jdobbs]

No, not yet, since this build was made from the master with my "custom PID" patch applied. The UHD patch is still waiting to be merged, though I could prepare a build that includes it if you'd like to test it out.Yes, please. For it to be useful for UHD muxing, it would need to have both the track designation for DolbyVision and a working (no "hidden"/"lost" frames) M2TS.

But, if it is too much work, I can just wait for the changes that a5180007 is submitting.

[jdobbs]

The second byte in the .bdmv is : 3-bit zero/reserved, isHDR10+, isSL-HDR2, isDV, isHDR10, isSDR.So after reading this I looked at the value on a group of discs with Dolby Vision. There doesn't seem to be a lot of consistency. Here are some examples of values I found: Alita: 0x16, Aquaman:0x06, Gridelwald: 0x06, Matrix Rev: 0x07, MI: 0x07, Mortal Engines: 0x07

The value in "Alita" makes you think there are at least 4 bits involved. They all had bits 1 & 2 set, so I guess that's what is needed for Dolby Vision -- but it makes me wonder what bits 0 and 3 mean. A guess would be that bit 1 is the indicator for HDR10, since it is there as a baseline with the Dolby -- and bit 2 is the flag for DV.

Does the new BDEDIT explain them?

[Edit] Looked at a couple standard HDR10 discs, and bit 1 (only) is set... so that is consistent with what I guessed above. In BD-Rebuilder I kept the original values for full backups, but used 0x03 for DV on movie-only -- that explains why I got a report that DV wasn't working on movie-only. That's good to know.

[SeeMoreDigital]

With regard to Dolby Vision encoded discs...

Would the fact that some have been encoded using MEL (10-bit minimal enhancement layer) or FEL (12-bit full enhancement layer) make any difference when generating re-muxes?

Disc info: https://forum.blu-ray.com/showthread.php?t=276448


Cheers

[jdobbs]

With regard to Dolby Vision encoded discs...

Would the fact that some have been encoded using MEL (10-bit minimal enhancement layer) or FEL (12-bit full enhancement layer) make any difference when generating re-muxes?

Disc info: https://forum.blu-ray.com/showthread.php?t=276448


CheersGood question... but I don't have an answer. Anyone else?

[a5180007]

Can the 0x51 be modified to 0x21? Most of the reencodes I do are output to BD-25/50. I don't even have a burner that supports 66/100. If not, I can do it after the fact, I guess (as I do now).

It can easily be changed to 0x21, but what gives the most compatibility? If we change to 0x21, wouldn't it limit all plays to BD-25/50 disks ?

When will this patch show up in the nightly releases (if that is the plan)?

justdan96 advised on some conflicts with previous commits (the omission of "overrides"...) from @BloodyRipper. I sent you a PM with my latest build, which includes Dolby Vision. If you can test and report any issues...

Where do I get a copy of the latest BDEDIT? I looked at the BDEDIT thread and it looked like the last edit was many years ago. I use BDEDIT all the time. It's really useful software.

You go on http://bdedit.pel.hu/ , kindly donate 10EUR and ask pelican to send you the link. Largely worth it !!

So after reading this I looked at the value on a group of discs with Dolby Vision. There doesn't seem to be a lot of consistency. Here are some examples of values I found: Alita: 0x16, Aquaman:0x06, Gridelwald: 0x06, Matrix Rev: 0x07, MI: 0x07, Mortal Engines: 0x07

The value in "Alita" makes you think there are at least 4 bits involved. They all had bits 1 & 2 set, so I guess that's what is needed for Dolby Vision -- but it makes me wonder what bits 0 and 3 mean. A guess would be that bit 1 is the indicator for HDR10, since it is there as a baseline with the Dolby -- and bit 2 is the flag for DV.

Does the new BDEDIT explain them?

0x06 = DV + HDR10 : Ok for Aquaman and Grindewald.
0x07 = DV + HDR10 + SDR : Ok for Mortal Engines and MI.
0x16 = HDR10+ : Alita BD is authored incorrectly.

[Edit : see correction below. Alita is also correct HDR10+ + DV + HDR10]

The baseline should be SDR -there are quite a few UHD that are BT709. And yes, BDEdit shows these flags in the index.bdmv extension data -and shows the mpls HDR metadata (color primaries, maxCLL etc).

[FilipeAmadeuO]

Alita UHD 4K has both HDR10+ and Dolby Vision. Probably that’s why it’s 0x16...

[jdobbs]

It can easily be changed to 0x21, but what gives the most compatibility? If we change to 0x21, wouldn't it limit all plays to BD-25/50 disks ? It's probably best to just leave it. I can modify it as needed.

Just a note, though. You may have already thought of this... but if you set this value to 0x51 it will also affect the value to be used in TS_recording_rate in the ClipInfo() table of the CLPI.