tsMuxer Open Source

[filler56789]

Very well, I've managed to make the CLI "stuff" somewhat less messy...
now the bundle includes the source-codes of both zlib and freetype2, in the same way it already included libmediation. Besides, I removed the GUI directory and the Visual Studio & Mac files. All the user has to do is run the autobuild.sh script. CMake is required for building zlib.

Evidently, I modified (i.e., simplified) tsMuxer's makefile (even more). But something strange happened: the mingw32 compiler built the .EXE normally (again), but the mingw64 one stopped the job because of something that it didn't like in the file tsMuxer/src/bitStream.cpp:

for (; len >= 8 && ((unsigned long) src % sizeof(unsigned)) != 0; len -= 8) {


It is strange because yesterday the problem didn't appear when I compiled the 64-bit .exe "manually" :confused:

So I added the cflag "-fpermissive" to the makefile and now the 64-bit compiler doesn't complain anymore.
I know this is not the actual solution to the problem, but it's all that I can do for the time being.

Download the archive from Mediafire:

http://www.mediafire.com/file/ep7zekj2sidq0a8/tsMuxer-CLI-2.6-15-src.7z/file

[gonca]

@manolito
I have the same version of 7zip as you and it opens iso files just fine

[filler56789]

Background: yesterday I intended to do some hexedit(s) in tsMuxerGUI.exe v2.6.12 and so I unpacked (upx -d) it. But then I discovered that the unpacked .EXE crashes when double-clicked :confused:

Question (@justdan96) — does the GUI v2.6.15 have this same "feature" (or design flaw) as the previous one? :confused:

[manolito]

@manolito
I have the same version of 7zip as you and it opens iso files just fine

Yes, mine does, too...

ImgBurn revealed the issue:
Normal ISO files use the ISO9660 + UDF1.02 file system, and 7-Zip opens these ISO files without problems. BluRay ISO files use the UDF2.50 file system, and this ISO format is not compatible with 7-Zip. This even happens on a Win7-64 computer which has built-in support for UDF2.50 (for WinXP users need to install a separate UDF2.50 driver).

So this issue is not the fault of tsMuxeR.

[justdan96]

I'm in the process of fixing up the CMake configuration so the binaries can be built via an automated pipeline for each OS & architecture, once I am home I'll see if filler56789's changes can merge easily into what I've already done so far. Also UPX won't be used in future builds.

[filler56789]

Feature request OR enhancement suggestion (whichever you prefer):

make tsMuxer accept and deal-with pure TrueHD streams, i.e., .thd files without an AC-3 substream. tsMuxer already accepts "coreless" DTS-HD streams, therefore...

Remember, .thd+ac3 is mandatory only for Blu-Ray authoring, not for generic .ts /.m2ts files.

[outgoing]

Another very nice feature to add, long ago Roman commented that he was going to implement but unfortunately did not it finally, is to keep the SubPath of the main playlist that has IG menu (pop up menu) linked in, whenever there is one with this feature ends up losing it. Sometimes it can be restored with bdedit but sometimes it is not fully compatible.

[ryu34]

Feature request OR enhancement suggestion (whichever you prefer):

make tsMuxer accept and deal-with pure TrueHD streams, i.e., .thd files without an AC-3 substream. tsMuxer already accepts "coreless" DTS-HD streams, therefore...

Remember, .thd+ac3 is mandatory only for Blu-Ray authoring, not for generic .ts /.m2ts files.

Would love this feature +1

[SeeMoreDigital]

While we're on the subject of feature requests...

The ability to create compliant HEVC video stream muxes would be nice.

[Gser]

Feature request OR enhancement suggestion (whichever you prefer):

make tsMuxer accept and deal-with pure TrueHD streams, i.e., .thd files without an AC-3 substream. tsMuxer already accepts "coreless" DTS-HD streams, therefore...

Remember, .thd+ac3 is mandatory only for Blu-Ray authoring, not for generic .ts /.m2ts files.

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.

[filler56789]

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]

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]

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]

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.

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]

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]

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 :o :D ).

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

[filler56789]

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/mx0pzjne721x28u/tsMuxer-2.6.15-posixthreads.rar/file

[filler56789]

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 :goodpost: :thanks:

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

[justdan96]

In case anyone is wondering why there haven't been any binaries produced so far it's primarily because how long it has taken for me to produce a build pipeline.

I wanted to use dockcross and osxcross Docker containers but ran into all sorts of issues getting them set up to build the project. After a while I had to scrap the whole effort and start over.

I set things up in a VM to get Linux, Windows and MacOS builds all being produced successfully, I'm now transferring that setup over to a new, clean Docker container. Once that's all completed and tested I'll use GitHub Actions to get builds created automatically on each push.

It's taking a while I know but the upshot will make things a lot easier to manage going forward!

[filler56789]

...
I set things up in a VM to get Linux, Windows and MacOS builds all being produced successfully, I'm now transferring that setup over to a new, clean Docker container. Once that's all completed and tested I'll use GitHub Actions to get builds created automatically on each push.

Have you checked that the Windows binaries that you've managed to build DO NOT depend on external libraries?

Namely, on winpthreads, seh and libstdc++.

Because when I use the winpthread-ed GCC from the MinGW-w64 project with MSYS2, the 64-bit .EXE is not linked statically to those libraries; and when I used the "toolchain" provided by pacman, even zlib could not be linked statically.

[qyot27]

-DCMAKE_EXE_LINKER_FLAGS="-static-libstdc++ -static -pthread" when configuring resolves it with vanilla MSys2 with default repo packages.

Comparison with ldd:
'plain' build without the additional linker flags:
$ ldd tsmuxer-plain.exe
ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7fff09500000)
KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7fff09400000)
KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7fff065f0000)
GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7fff07910000)
win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7fff072f0000)
gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7fff07350000)
zlib1.dll => /mingw64/bin/zlib1.dll (0x62e80000)
msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7fff08d10000)
msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7fff07510000)
ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7fff06490000)
USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7fff07b40000)
gdiplus.dll => /c/WINDOWS/WinSxS/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.18362.418_none_17b1a56c6d9fd02b/gdiplus.dll (0x7ffed5a00000)
libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x61440000)
libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000)
libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc40000)
combase.dll => /c/WINDOWS/System32/combase.dll (0x7fff089d0000)
RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7fff08000000)
bcryptPrimitives.dll => /c/WINDOWS/System32/bcryptPrimitives.dll (0x7fff06af0000)

With the linker flags given above:
$ ldd tsmuxer.exe
ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7fff09500000)
KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7fff09400000)
KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7fff065f0000)
GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7fff07910000)
win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7fff072f0000)
gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7fff07350000)
msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7fff07510000)
ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7fff06490000)
USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7fff07b40000)
msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7fff08d10000)
gdiplus.dll => /c/WINDOWS/WinSxS/amd64_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.18362.418_none_17b1a56c6d9fd02b/gdiplus.dll (0x7ffed5a00000)
combase.dll => /c/WINDOWS/System32/combase.dll (0x7fff089d0000)
RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7fff08000000)
bcryptPrimitives.dll => /c/WINDOWS/System32/bcryptPrimitives.dll (0x7fff06af0000)


The actual filesizes also corroborate this; the binary using the above linker flags is a whole 3MB larger (before stripping).

[justdan96]

You should be able to set the CMake flag "TSMUXER_STATIC_BUILD", which should generate a static build automatically.

For the Docker container specifically the Windows builds produced only use static dependencies and don't have any sort of external dependencies - I checked with Dependency Walker.

[qyot27]

You should be able to set the CMake flag "TSMUXER_STATIC_BUILD", which should generate a static build automatically.
That'll work too. I didn't remember that CMakeLists for each subdir had been added.

[filler56789]

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

I've just updated my GitHub repository accordingly:

https://github.com/filler56789/RV-tsMuxeR

[justdan96]

I've started creating the GitHub actions to create the builds for all 3 platforms. I haven't quite finished yet but if people could test the builds produced I'd really appreciate it!
https://github.com/justdan96/tsMuxer/actions

Just check the "Artifacts" on the latest run of "Build for Linux", "Build for Windows" and "Build for Mac".

[filler56789]

https://github.com/justdan96/tsMuxer/actions

Just check the "Artifacts" on the latest run of "Build for Linux", "Build for Windows" and "Build for Mac".

Hummm, only the 64-bit .EXE, that's not good for the users of Windows XP :)

(I know, XP should be dead and buried, but don't forget tsMuxeR had been a 32-bit-only application since its zer0th day...)

P.S.: ¿¿¿ where is the new GUI ???

[justdan96]

Hummm, only the 64-bit .EXE, that's not good for the users of Windows XP :)

If they are dedicated enough to use an operating system that went out of support over 5 years ago I'd like to think they are dedicated enough to compile it themselves :)

P.S.: ¿¿¿ where is the new GUI ???

I haven't added Qt5 to the Docker container yet. For Windows it would be straightforward, Linux a bit more difficult as I'd need to compile Qt5 as static and Mac even more complicated as I'd have to compile Qt5 as static with osxcross.

Long story short, I'll get it sorted but it could take some time.

[qyot27]

If they are dedicated enough to use an operating system that went out of support over 5 years ago I'd like to think they are dedicated enough to compile it themselves :)
There are modern-ish platforms that use 32-bit Windows 10. Kind of but not really niche things like the Quantum Byte/Byte Plus or other mini-PCs. A lot of them (like the Byte3) have since moved to 64-bit Windows 10 or Ubuntu or leave OS installation to the user, but the first couple generations from ~2015-2017 used 32-bit Windows and 32-bit UEFI.

That means either having a separate i686-w64-mingw32 toolchain that needs to be invoked, or the existing toolchain needs to be multilib-enabled (in which case it's just a matter of throwing in some -m32 flags and telling it where the /lib directory is for i686, sometimes it might require overriding the CMAKE_SYSROOT, but not often).

What would be a showstopper specifically for XP is if MXE builds its toolchain with Secure API support turned on in MinGW-w64, as that will restrict everything it builds to Vista+.

[a5180007]

Hi all,

Another bug for aac muxing. In brief, the aac frame size is written on 13 bits (bits 31-43 in the frame), however tsMuxeR takes into account only the first 11 bits. So when the aac frame size is above 2048 bytes, tsMuxeR incorrectly reports a bad frame and discards it.

In aac.cpp, replace line 52:

int AACCodec::getFrameSize(uint8_t* buffer)
{
return buffer[4]*8 + (buffer[5] >> 5);
}

with

int AACCodec::getFrameSize(uint8_t* buffer)
{
return ((buffer[3] & 0x03) << 11) + (buffer[4] << 3) + (buffer[5] >> 5);
}

[SeeMoreDigital]

Another bug for aac muxing.
LC-AAC or HE-AAC?

[a5180007]

LC-AAC or HE-AAC?

All AAC types.
Edit: I've just tried and I can confirm, tsMuxeR accepts LC and HE and the above fixes both.

[justdan96]

That means either having a separate i686-w64-mingw32 toolchain that needs to be invoked, or the existing toolchain needs to be multilib-enabled (in which case it's just a matter of throwing in some -m32 flags and telling it where the /lib directory is for i686, sometimes it might require overriding the CMAKE_SYSROOT, but not often).

I suppose I can look at making a CMake option for it, if the demand is there.

Also @a5180007 thanks for the bug reports, I'll get those created in GitHub as issues so we can take a closer look at them.

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. Qt is pretty heavyweight for a simple application. My preference would be an application that can be made cross-platform with ease that doesn't depend on large GUI frameworks. I don't think we can swap out Qt for something like Nuklear that easily within the existing application so it may even be easier to rewrite it (if someone out there can prove me wrong I'd be very thankful!).

I'll create an issue for it so we can track it.

[a5180007]

Also tsMuxeR cannot demux correctly mp4 aac 5.1 : the problem seems to be linked to a bug from ffmpeg. tsMuxeR takes the channel count from 'mp4a' atom (cf. movDemuxer.cpp line 1252), but as noted here (http://ffmpeg.org/pipermail/ffmpeg-user/2019-February/043300.html) ffmpeg sets the channel count to 2 in 'mp4a' atom even for aac 5.1, and the correct channel count has to be taken from 'esds' atom.

The following should correct the bug, could anybody please test and report:
In movDemuxer.cpp add line 186 as follows:

if (isAAC) {
m_aacRaw.m_channels = m_sc->channels; // added line
m_aacRaw.buildADTSHeader(dst, frameSize + AAC_HEADER_LEN);
memcpy(dst + AAC_HEADER_LEN, buff, frameSize);
dst += frameSize + AAC_HEADER_LEN;
}
and add line 1454 as follows:

if (st->parsed_priv_data) {
((MovParsedAudioTrackData*)st->parsed_priv_data)->isAAC = true;
st->parsed_priv_data->setPrivData(st->codec_priv, st->codec_priv_size);
st->channels = (st->codec_priv[1] >> 3) & 0x0f; // added line: copy channel count from 'esds' AudioSpecificConfig
}

[a5180007]

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;



Ok, so I have tried to get totally rid of the max frame size limitation, as HEVC UHD frames can be several MBs.

The following should do the trick, could anybody please test and report:

In mpegStreamReader.cpp at line 130:

//if (m_bufEnd - m_curPos < MAX_AV_PACKET_SIZE) { // remove condition : size of frame is now checked for all frames
uint8_t* nextNal = NALUnit::findNALWithStartCode(min(m_curPos + 3,m_bufEnd), m_bufEnd, m_longCodesAllowed);
if (nextNal == m_bufEnd) {
storeBufferRest();
return NEED_MORE_DATA;
}
//}

and at line 65, remove truncating of last frame:

avPacket.size = m_tmpBufferLen; //changed from min(MAX_AV_PACKET_SIZE, m_tmpBufferLen);
}
/*if (m_tmpBufferLen > MAX_AV_PACKET_SIZE) {
LTRACE(LT_ERROR, 2, "Too large last buffer (" << m_tmpBufferLen << " bytes). Truncate buffer to " <<
MAX_AV_PACKET_SIZE << " bytes. It does not have to be!");
} */

With this fix the MAX_AV_PACKET_SIZE can be left = 32768 (although I don't know where this value comes from...)

[justdan96]

Thank you so much a5180007, I'll test these fixes myself and if they are resolved I'll publish the test cases as well.

[FilipeAmadeuO]

Thank you so much a5180007, I'll test these fixes myself and if they are resolved I'll publish the test cases as well.
Can you publish new binaries here for testing ?
Any plan to build with GUI ?

[Hart2hart]

To go back a step and sorry if I missed it...

Were binaries produced that would be “like” V2.6.12 so we can compare results to the long exiting binary files. This would provide a great starting point for enhancements to 3D and HEVC 4K images.

Excellent that TSMuxeR has been released to community. I’ll jump in at some point.

[justdan96]

Sorry I didn't update fully here, here is the quote from the readme:

To download the pre-compiled binaries head over to the following URL (you must be logged in) https://github.com/justdan96/tsMuxer/actions and click on the latest action for your chosen platform (Windows, Mac or Linux). In the Artifacts section in the top-right you can download a ZIP file containing the executable for tsMuxer.

At the moment only the CLI is included, the GUI is not yet available.

We've had quite a few good enhancements and bug fixes go into the repo recently so I think we are close to a release of 2.6.16. I want to get a nice automated workflow for creating the releases in GitHub so it may take a while for me to develop it.

Yes the binaries will be similar to 2.6.12, you can test the CLI now and use the older GUI if you can't (or don't want to) compile it yourself. Once I get the automated builds in GitHub working with tsMuxerGUI as well you can use the official binaries for that as well.

It would be fantastic if people can compare the older versions to the latest, you can post the results to this forum thread or if you encounter a specific issue with what you think is the root cause you can create an issue on GitHub.