tsMuxer Open Source

[justdan96]

So I've managed to contact the original author of tsMuxer and he has agreed to turn tsMuxer into an open source project.

You can find the project's home at GitHub here:
https://github.com/justdan96/tsMuxer

You can download the latest nightly build from here:
https://github.com/justdan96/tsMuxer/releases

Now the latest nightly build: https://github.com/justdan96/tsMuxer/releases
Because: https://forum.doom9.org/showthread.php?p=1935864#post1935864

Please post any bugs or enhancement requests either in this thread or as issues on the GitHub repo.

[videoh]

Just release the code and stop trying to take private control over it!

[justdan96]

I'm not exercising control over it. In its current state the code does not compile and is effectively unusable. Releasing it in that state would not really do anyone any good.

[Groucho2004]

I'm not exercising control over it. In its current state the code does not compile and is effectively unusable. Releasing it in that state would not really do anyone any good.As I understand from your first post, it doesn't compile on/for Linux. No mention of Windows so I presume it can be built for Windows.

So, why are you not releasing the code?

[justdan96]

It doesn't compile on any platform, I'd like to get it into a working state before it goes up publicly and the author expressed a wish for it to be released responsibly so I am trying to follow through on that.

[filler56789]

I'm not exercising control over it. In its current state the code does not compile and is effectively unusable.
Releasing it in that state would not really do anyone any good.

You are mistaken. Just release the current source-code and add an appropriate big-fat disclaimer or something.
And for the time being at least, don't use GitHub, use a file sharing site such as Mediafire.
In this way ordinary users won't even try to compile it and the experienced programmers may try to make it work.

[videoh]

Maybe others can straighten things out faster than you. ;)

[justdan96]

Releasing on GitHub was what the author requested. From the sounds of things people want the code released regardless of whether it is in a working state or not so I'll give the author a bit more time to send over the missing header files, but if I don't get a response I'll release with a disclaimer that the code doesn't work (in its current state).

I appreciate the feedback, since the program will be soon owned by the community it's good to gauge how people want it to be handled.

[videoh]

Missing files is quite a bit different from "it doesn't compile"!

[StainlessS]

Maybe you could at least name the missing headers. [maybe they are standard ones, EDIT: From DirectX SDK or something]

[justdan96]

The program used non-standard libraries for types, files, queues, threads and more - and these weren't included with the code. I made a bit more progress with switching them for the standard libraries last night and added a to do list to the readme.

I'll give the author a bit more time to respond to my message and otherwise will release it on the weekend.

[filler56789]

The program used non-standard libraries for types, files, queues, threads and more - and these weren't included with the code. I made a bit more progress with switching them for the standard libraries last night and added a to do list to the readme.

That's good. :thanks:

I'll give the author a bit more time to respond to my message and otherwise will release it on the weekend.

Please define weekend.
Or which weekend...

[justdan96]

Sorry I meant to release it last Sunday but things got on top of me. The author shared the missing headers - but it still doesn't compile. I'll revert the code to the original sources and just add the todo items to the readme for switching to standard libraries. I'll also add an issue to get past the specific compile error I am having. Once that's done I'll make the repo public. I hope I can get that done this week.

[videoh]

Thank you, justdan96. Your efforts are greatly appreciated!

[justdan96]

I managed to make a lot of progress tonight - fixed the compiler error, figured out how to get the 32-bit libraries needed to compile on Ubuntu and finally got a working build of both tsMuxer and tsMuxerGUI!
I have now made the repository public so you can all try compiling for your platform or just hack away at the code: https://github.com/justdan96/tsMuxer
Thanks to everyone for being so patient, hopefully this will lead to a lot of healthy discussion and collaboration!

[filler56789]

I managed to make a lot of progress tonight - fixed the compiler error, figured out how to get the 32-bit libraries needed to compile on Ubuntu and finally got a working build of both tsMuxer and tsMuxerGUI!
I have now made the repository public so you can all try compiling for your platform or just hack away at the code: https://github.com/justdan96/tsMuxer
Thanks to everyone for being so patient, hopefully this will lead to a lot of healthy discussion and collaboration!

:thanks: — I starred the project.

[justdan96]

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

[filler56789]

1)
I have it compiling in Visual Studio 2017 - I'll update the repo soon.
Nice! :)

2) Suggestion: create a TODO list :sly:
For example, TSmuxer doesn't support MPEG-4 ASP, even though MPEG-4 ASP is defined in the TS specification;
and it doesn't support Opus audio either :-/
Besides, it has a problem with some types of DTS Express: https://forum.doom9.org/showthread.php?p=1703668#post1703668

[justdan96]

Thanks for those, I'll create a section in the readme for that information.

[SeeMoreDigital]

1)

Nice! :)

2) Suggestion: create a TODO list :sly:
For example, TSmuxer doesn't support MPEG-4 ASP, even though MPEG-4 ASP is defined in the TS specification;
and it doesn't support Opus audio either :-/
Besides, it has a problem with some types of DTS Express: https://forum.doom9.org/showthread.php?p=1703668#post1703668
And... TSmuxer does not support HEVC of-course.

[filler56789]

And... TSmuxer does not support HEVC of-course.
What :confused:

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

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

[SeeMoreDigital]

What :confused:

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

https://github.com/justdan96/tsMuxer/blob/master/CHANGELOG.md#tsmuxer-255And 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]

What :confused:

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

https://github.com/justdan96/tsMuxer/blob/master/CHANGELOG.md#tsmuxer-255It 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:
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]

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]

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]

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? :confused:

[staina]

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]

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

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]

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]

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 :mad:

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

[filler56789]

Update 2:

I had to copy the zlib and the freetype libraries to the "......./i686-w64-mingw32/lib" directory, and now finally there exists a tsMuxeR.exe v2.6.15.

tsMuxeR version 2.6.15. github.com/justdan96/tsMuxer

But nope, there is no reason for celebrating yet.

[justdan96]

@qyot27 I merged the CMake stuff a bit early as I wanted to test the cross compilation, sorry should have done that on a separate branch.

@filler56789 Good to see you got the 32 bit zlib and Freetype libraries set up and the compile working. Once the crossbuild stuff is finished we should be able to generate Windows, Linux and Mac binaries easily using Docker.

[filler56789]

At last, here goes the pesky binary...
Play at your own risk :rolleyes:

http://www.mediafire.com/file/3pc2y8mab9ykhge/tsMuxeR-2.6.15-CLI.7z/file

[manolito]

Thanks very much for this build... :D

On my ancient computer (CPU without SSE2 support, WinXP) all the tsMuxeR.exe CLI executables from v.1.10.6 upwards crashed. This one doesn't, and the CLI works nicely with the older 2.6.12 GUI.

Only one thing does not work: Trying to create a BluRay ISO file directly results in a broken ISO and this error message:
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
terminate called after throwing an instance of 'std::runtime_error'
what(): Wrong Parameter.
No big deal...


Cheers
manolito

[filler56789]

@manolito: you're welcome :)

And to whom this may interest, here goes a 64-bit build:

http://www.mediafire.com/file/nq6nffseb4nyu87/tsMuxeR-2.6.15-CLI-64.7z/file

P.S.:

@justdan96: time to update the README.md alright.

"the program currently only compiles 32-bit executables, even on 64-bit systems"

[filler56789]

Only one thing does not work: Trying to create a BluRay ISO file directly results in a broken ISO and this error message:

Creating Blu-ray stream info and seek index
Creating Blu-ray playlist
Mux successful complete
Finalize ISO disk
terminate called after throwing an instance of 'std::runtime_error'
what(): The parameter is incorrect.


This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Very interesting indeed, I have just confirmed the problem exists...

On the other hand, the 64-bit edition seems to be okay :confused:

Creating Blu-ray stream info and seek index
Creating Blu-ray playlist
Mux successful complete
Finalize ISO disk
Muxing time: 5 sec

The resulting .ISO is recognized by WinRAR, MediaInfo, and it is "playable" as well.

[manolito]

I just tested the official v. 2.6.12 on a different computer, and when trying to directly create a BD ISO there is no error message at all, but the resulting ISO is just as broken. The only difference when using your 2.6.15 CLI executable is the error message followed by Win7-64 telling me that the application is not working any more and must be closed.

So this error must already have been there before 2.6.15.


//EDIT//
Sorry I have to correct myself... :confused:
The ISO files created by v. 2.6.12 do work, they play in all the players I threw them at. What does not work is trying to open them in 7-Zip, and I am not sure if this has something to do with my 7-Zip version (19.00 x64). I remember that I was able to open ISOs in 7-Zip, but with an older 32-bit version.

But the 64-bit CLI version indeed works flawlessly for me under the 32-bit GUI.


(Probably stupid) question:
Can I use your 64-bit CLI version under the 32-bit GUI?

[filler56789]

I just tested the official v. 2.6.12 on a different computer, and when trying to directly create a BD ISO there is no error message at all, but the resulting ISO is just as broken. The only difference when using your 2.6.15 CLI executable is the error message followed by Win7-64 telling me that the application is not working any more and must be closed.

So this error must already have been there before 2.6.15.

Thanks for reporting. I had no use for the ISO feature of TSMuxer, so I had never tried it.

(Probably stupid) question:
Can I use your 64-bit CLI version under the 32-bit GUI?

I thought the answer should be "no", but because I am stubborn, I ran a quick test, and discovered that the answer is "yes" :eek:

[manolito]

:p:p:p:p

[outgoing]

Thanks for reporting. I had no use for the ISO feature of TSMuxer, so I had never tried it.

The feature to create the .iso is basic to create a 3D bluray image, without this function will not work to build a 3D.