tsMuxer Open Source

[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.
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]

Originally Posted by FilipeAmadeuO

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]

Originally Posted by justdan96

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]

Originally Posted by 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.

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]

Originally Posted by BloodyRipper

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]

Originally Posted by jdobbs

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]

Originally Posted by a5180007

@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]

Originally Posted by a5180007

@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]

Originally Posted by jdobbs

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 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. 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

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]

Originally Posted by jdobbs

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:

Originally Posted by jdobbs

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]

Originally Posted by a5180007

@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]

Originally Posted by BloodyRipper

I took the liberty of implementing this via an explicit parameter in the meta file. The pull request 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. 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??