tsMuxer Open Source

[filler56789]

Originally Posted by SeeMoreDigital

And... TSmuxer does not support HEVC of-course.

What

Yes, it does! But not for Ultra HD Blu-ray authoring, for example.

https://github.com/justdan96/tsMuxer...md#tsmuxer-255

[SeeMoreDigital]

Originally Posted by filler56789

What

Yes, it does! But not for Ultra HD Blu-ray authoring, for example.

https://github.com/justdan96/tsMuxer...md#tsmuxer-255

And there-in lies the problem

Plus the 4K UHD HEVC in .m2ts muxes that TSmuxer currently generates are a little unstable in some hardware playback devices...

[jdobbs]

Originally Posted by filler56789

What

Yes, it does! But not for Ultra HD Blu-ray authoring, for example.

https://github.com/justdan96/tsMuxer...md#tsmuxer-255

It will mux HEVC/UHD. But it has several muxing bugs when doing a HEVC/UHD stream. For example it flags them as 1080p and it misses frames, or more accurately it thinks some frames are a part of a previous frame and muxes them as a part of it. The result is a stream that gets progressively more out of sync (at least those that are encoded for blu-ray UHD by X265). It also uses the wrong stream type, needs to update the headers to version 3, and add UHD extension data to the clpi files and index.bdmv.

With that said... the last publicly released version was 2.6.12 -- so I'm not sure what has changed since then, there seems to have been three minor version updates since then.

I've been working on an algorithm that remuxes TSMUXER output to make it UHD compliant. I'm happy to see the release of the code. I'd rather help fix the original code than have to scan through a 50GB M2TS file fixing issues as I find them.

[justdan96]

Sorry I've been very busy recently but I'll be updating the documentation in the repo very soon. Jdobbs it sounds like you have a good idea of the issue so I'll be stealing your description to add to the todo list

[Selur]

Thanks for releasing the code!

[r0lZ]

As far as I know, there are at least 2 bugs related to the subtitles in the demux function:

Originally Posted by r0lZ

Do NOT use v2.6.11 or v2.6.12 as they have a big bug with the time codes of the subtitle streams of some BDs. AFAIK, v2.6.10 has never been released publicly, so the last known good version is v2.6.9, for Windows and Linux. However, even v2.6.9 has some bugs, notably the association of the subtitles with the 3D-Plane numbers, often wrong. (But this bug affects only the info and the remux of the 3D BDs.)

As noted in the other thread, v2.6.11 and v2.6.12 produce often wrong timecodes when demuxing a 3D bluray. (I don't know if that bug affects also the 2D blurays.) Unfortunately, I don't remember what BD is a good example of the problem. V2.6.9 is the last version without that bug, so if you have the sources of that version, it should be easy to find the origin of the bug.

The other important bug with the subtitles is also related to the 3D BD. The MPLS file contains the extensions with the 3D-specific information, like what tsMuxeR calls the "3D-Planes", in fact the "Offset Sequences" necessary to display the subtitles at the correct depth on screen. There is usually one 3D-Plane per subtitle stream, although it's not mandatory as the same 3D-Plane can be used for several streams. The bug is that tsMuxeR assumes that the 3D-Planes are assigned to the subtitles streams in the order of their UID. It's not correct. The MPLS file describes precisely the subtitle streams, ans they do not have to be in the order of their UID, although it's often the case.

So, for example, if there are 4 subtitle streams in the BD, stored in the MPLS in the standard order, tsMuxeR will assign the 4 first 3D-Planes to that 4 streams, and it will probably be correct. But if the 4 streams are presented in the MPLS in another order, it will be wrong. And if the same 3D-Plane is assigned to several subtitle streams in the MPLS, it will assign it only once, and the last subtitle streams will not have any 3D-Plane at all. To summarize, tsMuxeR ignores the content of the MPLS when it assigns the 3D-Planes to the subtitle streams. That's an important bug, although the wrong information is only displayed, and never used during the demux operation. I don't know if tsMuxeR does the same error when it remuxes a 3D-BD, but I suppose so.

[staina]

Originally Posted by r0lZ

As far as I know, there are at least 2 bugs related to the subtitles in the demux function:

As noted in the other thread, v2.6.11 and v2.6.12 produce often wrong timecodes when demuxing a 3D bluray. (I don't know if that bug affects also the 2D blurays.) Unfortunately, I don't remember what BD is a good example of the problem. V2.6.9 is the last version without that bug, so if you have the sources of that version, it should be easy to find the origin of the bug.

The other important bug with the subtitles is also related to the 3D BD. The MPLS file contains the extensions with the 3D-specific information, like what tsMuxeR calls the "3D-Planes", in fact the "Offset Sequences" necessary to display the subtitles at the correct depth on screen. There is usually one 3D-Plane per subtitle stream, although it's not mandatory as the same 3D-Plane can be used for several streams. The bug is that tsMuxeR assumes that the 3D-Planes are assigned to the subtitles streams in the order of their UID. It's not correct. The MPLS file describes precisely the subtitle streams, ans they do not have to be in the order of their UID, although it's often the case.

So, for example, if there are 4 subtitle streams in the BD, stored in the MPLS in the standard order, tsMuxeR will assign the 4 first 3D-Planes to that 4 streams, and it will probably be correct. But if the 4 streams are presented in the MPLS in another order, it will be wrong. And if the same 3D-Plane is assigned to several subtitle streams in the MPLS, it will assign it only once, and the last subtitle streams will not have any 3D-Plane at all. To summarize, tsMuxeR ignores the content of the MPLS when it assigns the 3D-Planes to the subtitle streams. That's an important bug, although the wrong information is only displayed, and never used during the demux operation. I don't know if tsMuxeR does the same error when it remuxes a 3D-BD, but I suppose so.

At Remux from 3D Bluray disk stays 3D-Planes at subtitles streams so as to original 3D Bluray.

[filler56789]

1) In the README of TSMuxer, instead of "To compile tsMuxer and tsMuxerGUI on Windows..." you should have written "To compile tsMuxer and tsMuxerGUI with Microsoft Visual Studio". Stop denying the existence of MSYS2 and MinGW-w64

2) even though I don't like CMake, perhaps it will be the best (or only) way to please all the possible "building environments" at the same time...

[justdan96]

1) Yeah that wording makes sense. I'm trying to create a Makefile for nmake currently but there doesn't appear to be an easy way to convert a VC++ project to a Makefile, so it's taking a bit of time. I initially tried an Msys2 compile but it didn't work, I can give it another go, though.

2) I'm open to suggestions on that. My original idea was to use dockcross but there's a lot of dependencies to factor in. Linux, Mac and Windows are all supposed to be supported and right now I'm just compiling in VMs on VirtualBox, but that will be difficult to turn into a reproducible pipeline without some trickery.

Edit: An update on 1) - I did manage to get it working with Msys2. I will be updating the readme and Makefiles in the repos but I think this should replace the VC++ method as it will be way easier to create a pipeline with Msys2 over VC++.

[qyot27]

It only took a couple hours (because I was going in blind and starting from scratch, essentially), but I went ahead and whipped up a very barebones CMakeLists.txt to get the ball rolling (and because I'm partial to anything that can use Ninja, regardless of the size of the project; the only other option there is meson, AFAIK, but I don't have any Python skills to speak of). I was able to verify that there were no problems building libmediation and the tsmuxer cli for 64-bit. The pull request is already live, but it could easily remain a WIP unmerged thing until the major kinks are hammered out.

[justdan96]

I'll try this out when I get back from holiday, great to see how people are taking the project forward!

[r0lZ]

Originally Posted by staina

At Remux from 3D Bluray disk stays 3D-Planes at subtitles streams so as to original 3D Bluray.

No, the problem is when tsMuxeR shows the information from the ORIGINAL BD 3D. Since that information is not always correct, if you demux the streams and then remux them with the incorrect information, the result is wrong, and the 3D-Planes are not assigned to the correct streams any more.

[filler56789]

Originally Posted by justdan96

I have it compiling in Visual Studio 2017 - I'll update the repo soon.

So, ¿why haven't you released the .EXEs (both the CLI and the GUI) version 2.6.15?

[staina]

Originally Posted by r0lZ

No, the problem is when tsMuxeR shows the information from the ORIGINAL BD 3D. Since that information is not always correct, if you demux the streams and then remux them with the incorrect information, the result is wrong, and the 3D-Planes are not assigned to the correct streams any more.

So this with me never yet not happened to. Into tsMuxer I'm load playlist with main movie, selected audio and subtitles, that I want leave and created new Bluray folder or Bluray ISO and 3D- Planes were to be associated as with original Bluray.

For example:

Original Bluray

1. subtitle stream ENG - 3D-Planes 1
2. subtitle stream JPN - 3D-Planes 2
3. subtitle stream TUR - 3D-Planes 3
4. subtitle stream RUS - 3D-Planes 4
5. subtitle stream POL - 3D-Planes 5

Remux Bluray select subtitle stream 1,3,5

1. subtitle stream ENG - 3D-Planes 1
2. subtitle stream TUR - 3D-Planes 3
3. subtitle stream POL - 3D-Planes 5

[justdan96]

Originally Posted by filler56789

So, ¿why haven't you released the .EXEs (both the CLI and the GUI) version 2.6.15?

I'd been prioritising the build pipeline work and getting some of the cruft out of the repo like the use of non-standard libraries.

If you need any help with compiling with Msys2 please let me know.

[r0lZ]

Originally Posted by staina

So this with me never yet not happened to. Into tsMuxer I'm load playlist with main movie, selected audio and subtitles, that I want leave and created new Bluray folder or Bluray ISO and 3D- Planes were to be associated as with original Bluray.

For example:

Original Bluray

1. subtitle stream ENG - 3D-Planes 1
2. subtitle stream JPN - 3D-Planes 2
3. subtitle stream TUR - 3D-Planes 3
4. subtitle stream RUS - 3D-Planes 4
5. subtitle stream POL - 3D-Planes 5

Remux Bluray select subtitle stream 1,3,5

1. subtitle stream ENG - 3D-Planes 1
2. subtitle stream TUR - 3D-Planes 3
3. subtitle stream POL - 3D-Planes 5

Most of the times, it works fine, because the subtitles streams are stored in the MPLS in the order of their PID, like this:
(The first number is the order in the playlist, the second is the PID.)
1. 4608 ENG - 3D-Planes 1
2. 4609 JPN - 3D-Planes 2
3, 4610 TUR - 3D-Planes 3
4. 4611 RUS - 3D-Planes 4
5. 4612 POL - 3D-Planes 5
But that order is not at all mandatory. The streams can be stored in the MPLS in a different order, like this:
1. 4608 ENG - 3D-Planes 1
2, 4610 TUR - 3D-Planes 2
3. 4609 JPN - 3D-Planes 3
4. 4611 RUS - 3D-Planes 4
5. 4612 POL - 3D-Planes 5
Note the inversion of the PID of streams 2 and 3. The two streams are stored in a relatively unusual order, but it's perfectly legal, and that happens! In the example above, the 3D-Planes are correctly assigned, because they are tied to the correct stream, in the order of the playlist. But tsMuxeR fails, when it show the information for such a 3D BD, because it assumes that the streams are stored in the order of their PID:
1. 4608 ENG - 3D-Planes 1
3, 4609 JPN - 3D-Planes 2
2. 4610 TUR - 3D-Planes 3
4. 4611 RUS - 3D-Planes 4
5. 4612 POL - 3D-Planes 5
The effect is that, in this example, streams 2 and 3 have the wrong 3D-Planes.

Note also that sometimes, a MPLS doesn't references all streams. Some subtitle streams are present in the M2TS, but not in the MPLS, like this:
1. 4608 ENG - 3D-Planes 1
X. 4609 JPN
2. 4610 TUR - 3D-Planes 2
3. 4611 RUS - 3D-Planes 3
4. 4612 POL - 3D-Planes 4
In this example, the JPN track is not referenced in the MPLS, and therefore it cannot be selected when that MPLS is played with a real BD player. I call it a "phantom stream", present in the M2TS, but not in the MPLS. Usually, another MPLS references that stream normally. I have no idea why some BDs are authored that way, but it's relatively frequent, especially for the Japanese language.
As a consequence, in this example, the JPN track has no 3D-Plane assigned (in this MPLS of course). TsMuxeR should simply omit it, and display only the streams referenced in the MPLS, like this:
1. 4608 ENG - 3D-Planes 1
2. 4610 TUR - 3D-Planes 2
3. 4611 RUS - 3D-Planes 3
4. 4612 POL - 3D-Planes 4
But it doesn't do that. Again, it assumes wrongly that the 3D-Planes must be assigned one at a time to all streams in the M2TS, in the order of their PID, and it shows this:
1. 4608 ENG - 3D-Planes 1
X. 4609 JPN - 3D-Planes 2
2. 4610 TUR - 3D-Planes 3
3. 4611 RUS - 3D-Planes 4
4. 4612 POL
Again, it's completely wrong (except for the first track). The unreferenced JPN track appears where it should be hidden, and it inherits the 3D-Plane of the next stream. Then, all 3D-Planes are off by 1. And the POL stream has lost its 3D-Plane completely.

I think that the problem is that tsMuxeR doesn't use really the MPLS to retrieve its information, at least for the stuff related to the 3D-Planes. Since it is a muxer/demuxer, it prefers to trust what it finds in the M2TS (or SSIF) files, and it assumes that the PIDs of the streams determines their order. But that's not correct. The 3D-Plane numbers are stored in the MPLS and are based on the information and order from the same MPLS.

Trust me, I have studied closely that bug, after several problems I have encountered when I have written BD3D2MK3D. It's obviously a major bug. BTW, you can use my program to examine how the 3D-Planes are assigned to the subtitle streams. I have written my own MPLS parser, because it was impossible to trust the 3D-Planes information displayed by tsMuxeR.

[filler56789]

Originally Posted by justdan96

I'd been prioritising the build pipeline work and getting some of the cruft out of the repo like the use of non-standard libraries.

Actually I was thinking less of my own curiosity and more of the curiosity of most users of tsMuxer... I bet most /all of them would like to test v2.6.15 and compare it to v2.60.12, and we already know they don't have the interest in "creating the binaries with their own hands" so to speak...

If you need any help with compiling with Msys2 please let me know.

Getting only the command-line .EXE compiled would be sufficient for my current level of curiosity. Until some days ago (I don't remember how many) I could only compile the libmediation stuff and satisfy the needs of the matroska-thing — of course the old error messages were replaced with the new ones, but that was a start and I intended to learn with them later... but now that there is a CMakeLists.txt, "nothing works anymore" :–/, CMake only says the configuring job contained errors and had to be stopped...

My original goal was download and install the other "dependencies" of tsMuxer's source-code and try again, but those dependencies should be in their, let's say, «original form», not in their mingw-blah-blah-name-of-the-package form. I have been using MSYS2 regularly since 2016 and until recently I never had to deal the mingw-prefixed packages which are "installed" in the mingw32 and mingw64 directories and not only look very-misplaced but also can mean a waste of HDD space (because of unnecessarily-duplicated files).

[filler56789]

Update 1:

This time I ignored the CMake stuff, and after building libmediation, I tried to build tsmuxer.exe, and this is what I got:

<MINGW32> make
make: *** No rule to make target 'src/textSubtitlesRenderWin32.cpp', needed by 'all'.  Stop.

[qyot27]

I don't know why the CMakeLists.txt was merged, it was still a WIP pull request and I hadn't done any further work on it (including testing it on anything other than native Linux); a couple of files in tsmuxer's CLI directory had to be moved to a subdirectory so that they wouldn't get globbed into the file list and choke GCC with platform-irrelevant errors. But the Makefile hadn't been made aware of this move yet. In the meantime, just search for textSubtitlesRenderFT.cpp and textSubtitlesRenderWin32.cpp in the Makefile and change the path from src/ to src/osdep/.

[filler56789]

@qyot27: many thanks for the useful post *THUMBS UP*

Modifying the tsMuxer CLI makefile worked; but I also had to add another edit so that it could find "path-to/include/freetype2".
Now I get these errors

r:/msys2x86/gccs32/zer0th/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lz
r:/msys2x86/gccs32/zer0th/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: cannot find -lfreetype
collect2.exe: error: ld returned 1 exit status
make: *** [Makefile:74: ../bin/tsMuxeR.exe] Error 1