tsMuxer Open Source

[filler56789]

Originally Posted by Gser

Demuxing DTS-HD files with the lossless part included also produces non-compliant .dts files (should be .dtshd) that DTS-HD Master Audio Suite fails to recognize. eac3to and mkvextract also have this problem.

IIRC, it's because the Master Audio Suite and the certified BD authoring tools expect that the .DTSHD files
(High-Resolution Audio, Lossless with or without the "core", and DTS Express)
include a header and a footer — but the containers, even the Blu-Ray transport stream, are not expected to store the DTSHD header and footer.

EDIT — I wrote "even the Blu-Ray transport stream" but
I should have written «especially the Blu-Ray transport stream», because
a transport stream cannot have global headers.

[outgoing]

any progress in the tsMuxer project?

[TEB]

I have access on a Harmonic A/V Analyser at work, and i can run through some TS files and check for compliancy if its needed!

[filler56789]

Originally Posted by outgoing

any progress in the tsMuxer project?

Not yet, sadly

But while the bug fixes and the enhancements don't happen, I have a couple of suggestions:

1) an overdue update to the README.md — for example, the instructions for building tsMuxer with MinGW-w64 && MSYS2 are not entirely correct, in fact they are a bit misleading;

2) forget the QT-based GUI and replace it with a .NET/Mono one — I think stax76 could do this

[Selur]

forget the QT-based GUI and replace it with a .NET/Mono one

Why? (personally I prefer Qt/C++ over .NET)

[filler56789]

Originally Posted by Selur

Why? (personally I prefer Qt/C++ over .NET)

Good question
In other words, I don't have a good answer for that.

Personally I would like a GUI which could be [easily] compiled in MinGW-w64, just like Xvid's VfW configuration dialog can...
but then perhaps I would be "asking for too much"

[filler56789]

And FWIW, a new issue has been opened
(but not by me)

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

[justdan96]

I've been able to get a build pipeline working to easily create Windows and Linux builds using Docker, I'll next try to add Mac and if that all appears to work I'll push to the repo. The readme will have to be updated for sure but it's going to make compiling a heck of a lot easier. I'll add the binaries that are produced to the repo as well.

Sorry for the recent lack of updates, my job has been keeping me very busy recently. If there is anyone else who wants to get involved please do - pull requests are always welcome!

[staina]

When will release new version supporting UHD Bluray, eventually how is far her development?

Thank you Staina

[justdan96]

At the moment I'm focusing on being able to consistently produce binaries for all platforms (Windows, Linux, Mac) and ensuring that the output is bug-free.

[outgoing]

Thanks anyway to everyone involved in the development of this excellent program.

[staina]

Originally Posted by r0lZ

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

You're right, checked I'm my 3D movies and at some is 3D-plane other in tsMuxer compared to BD3D2MK3D. I hope that the BD3D2MK3D displays these value right so I shall have to these 3D movies recreate.

[r0lZ]

Yes, the 3D-Plane list is right in BD3D2MK3D, because it is extracted from the MPLS file, and not guessed blindly like with tsMuxer.

@ developers: This is an important bug. Please do not forget it when you will fix the tsMuxer bugs. Thanks in advance.

[a5180007]

Hi all, before all I thank the tsMuxer developer for his fantastic software, and for accepting to release the source code.

Originally Posted by jdobbs

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)

There is a bug creating unsynchronized AV with some HEVC files, due to insufficient size of coded picture buffer.
In brief, when reading a nal the end of the buffer is reached before finding the next nal start_code, and the PTS is not incremented for this nal.

(Edit: correction changed)
I have corrected the bug on my side by simply changing the line 7 in avPacket.h from:

const static int MAX_AV_PACKET_SIZE = 32768;

to

const static int MAX_AV_PACKET_SIZE = 800000;

I am not a developer and have limited coding knowledge, so I won't submit a patch.

[a5180007]

Originally Posted by jdobbs

It also uses the wrong stream type

Replace lines 41 and 42 in tsPacket.h

//static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x24;
static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x06;

with

static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x24;
// static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x25; /* HEVC conforming to profile */

Edit note: should normally be 0x25, but seems to be 0x24 in UHD Blu-rays

[justdan96]

What would be the simplest way to check that these changes have resolved the issues?

[filler56789]

Originally Posted by a5180007

Replace lines 41 and 42 in tsPacket.h

//static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x24;
static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x06;

with

static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x24;
// static const uint8_t STREAM_TYPE_VIDEO_H265      = 0x25; /* HEVC conforming to profile */

Edit note: should normally be 0x25, but seems to be 0x24 in UHD Blu-rays

Thanks for chiming in.
But an actual solution should be not a mere replacement, but an additional possibility plus a "Select_Case" thing

(apologies for the VBspeak ).

Because tsMuxer is a transport stream multiplexer, not only a basic Blu-Ray authoring tool.

[filler56789]

Originally Posted by staina

When will release new version supporting UHD Bluray, eventually how is far her development?

Very far, sadly.

And the fact that the new tsMuxeR is becoming Linux-centric (so to speak) only makes things worse IMNSHO.

[filler56789]

Okay, since the GitHub repository was created 3.5 months ago and the owner has released ZERO binaries thus far, here go two CLI .exes built from the "improved" source-code...
Notice, the "improved" source-code requires a POSIX-threaded compiler, so I had to download old packages from the MinGW-w64 project @ SourceForge and use them in my MSYS2 environment; no way I would screw my MSYS2 setup with the "toolchains" provided by the MSYS2 devilopers.
The 32-bit binary seems to be OK; the 64-bit .EXE requires the three DLLs included in the archive.
No GUI because I have no interest in downloading the terabyte-sized QT5 stuff.

LINK: http://www.mediafire.com/file/mx0pzj...reads.rar/file

[filler56789]

Originally Posted by nevcairiel

Its a shame that they don't want to implement the stuff with native threading. winpthreads is kinda crappy.
Especially since someone already did all the work and made a header file with std::thread support for win32 threading model as well.

https://github.com/meganz/mingw-std-threads

Many thanks for the useful post, nevcairiel

I followed the instructions and managed to build the new tsMuxeR with the Win32-threaded GCC