tsMuxer Open Source

[ocean]

Hi everyone, I don't know if the topic has already been raised, but BDinfo after the mux with tsMuxeR, reads the Bitrate of the Blu-Ray, but not those of the Blu-Ray UHD, the problem is in the m2ts container, here are 2 examples:

Blu-ray

https://i.ibb.co/qDHm8LB/Immagine.png (https://ibb.co/qDHm8LB)


Blu-Ray UHD

https://i.ibb.co/M5MKd3C/Immagine-copy.png (https://ibb.co/M5MKd3C)

[MrVideo]

Could yo tell me which graphic programs should I use in order to edit PNG images?
PhotoShop ($$$$)
Gimp (Free)

[MrVideo]

I just noticed that the GUI About tab doesn't list the version number. I understand that all of the nightly builds are the same version, so the nightly build date should be listed as well.

[outgoing]

Hi everyone, I don't know if the topic has already been raised, but BDinfo after the mux with tsMuxeR, reads the Bitrate of the Blu-Ray, but not those of the Blu-Ray UHD, the problem is in the m2ts container, here are 2 examples:


This bug reminds me of a similar one in another program. The metadata is broken to be able to list the bitrate properly. If it is confirmed it is an error that should be fixed.

Glad to see you here again. :D

[mariner]

Greetings to all for creating this wonderful tool.

Two questions:

1. Is DD+ 5.1 sound track supported when creating BDMV folder? It appears some have reported getting error 135 message when doing so.

2. Can this be used to create BDMV consisting of multiple HEVC titles? Or any suggestion for a suitable tool?

Many thanks and best regards,

[MrVideo]

I can crash the Sep 6th nightly build (Win7-64) extremely easily. Just do a remove of any of the tracks and you can easily cause it to crash. Changing the order of the track removal can make it not crash, but after a successful M2TS muxing, doing a remove of the imported files resulted in a crash when removing that last of the two files.

Going back to the June 1st build results in it working, without crashing.

[ocean]

Hi outgoing thank you, nice to see you again, the problem described above, I found an analogy in the encoder used, ATEME Titan File 3.9.0 (4.9.0.0), the titles that use this encoder generate the problem.

[a5180007]

BDinfo after the mux with tsMuxeR, reads the Bitrate of the Blu-Ray, but not those of the Blu-Ray UHD, the problem is in the m2ts container

Should be fixed in the Bintray nightly-2020-09-13--02-21-33.

[outgoing]

Nice, great work!!

[iSeries]

Not sure if this is a bug or not but using the latest nightly, remuxing full disc backup of Midsommar Director's Cut to m2ts, tsMuxer is adding a -13 second audio delay relative to video (shown in MediaInfo). No delay is indicated in the original playlist/m2ts. I have no idea how to stop tsMuxer from adding this delay.

[imhh11]

Hi, I'm having this issue with the latest build (2020-09-13--02-21-33 )

https://ibb.co/9yPxzQn

[a5180007]

Hi, I'm having this issue with the latest build (2020-09-13--02-21-33 )

https://ibb.co/9yPxzQn
@imhh11 sorry, my mistake... The next Bintray nightly should fix this.

[imhh11]

thank you @a5180007

[varekai]

@a5180007 and justdan96
Thanks for the continuing tsMuxer updates, much appreciated!

[BloodyRipper]

I can crash the Sep 6th nightly build (Win7-64) extremely easily. Just do a remove of any of the tracks and you can easily cause it to crash. Changing the order of the track removal can make it not crash, but after a successful M2TS muxing, doing a remove of the imported files resulted in a crash when removing that last of the two files.

Going back to the June 1st build results in it working, without crashing.
Should be fixed starting with 2020-09-17--02-22-29 (https://bintray.com/justdan96/tsMuxer/tsMuxerGUI-Nightly/2020-09-17--02-22-29#files), please report if this keeps happening.

[Peter_A]

I found an issue with an audio delay being introduced, according to MediaInfo, and the audio/video sync is off during playback, when using version 2020-09-18--02-23-09.

Using the same source and version 2020-06-25--02-11-43 (with the same settings), there is no delay introduced, and video/audio sync appears to be correct.

I'm not sure what's causing this, or in which version this started (since I jumped from 6/25 to 9/28). Any idea what the issue may be?

Using version 2020-09-18--02-23-09
Audio #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Muxing mode : Stream extension
Codec ID : 134
Duration : 1 h 42 min
Bit rate mode : Variable
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Delay relative to video : -1 s 668 ms
Language : English
Source : 00000.m2ts / 00000.m2ts

Audio #2
ID : 4353 (0x1101)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 1 h 42 min
Bit rate mode : Constant
Bit rate : 224 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Delay relative to video : -1 s 668 ms
Stream size : 165 MiB
Language : English
Service kind : Complete Main
bsid : 6
Dialog Normalization : -27
Dialog Normalization : -27 dB
compr : 1.94
compr : 1.94 dB
dynrng : 1.26
dynrng : 1.26 dB
dsurmod : 1
dsurmod : Not Dolby Surround encoded
acmod : 2
lfeon : 0
dialnorm_Average : -27
dialnorm_Average : -27 dB
dialnorm_Minimum : -27
dialnorm_Minimum : -27 dB
dialnorm_Maximum : -27
dialnorm_Maximum : -27 dB
dialnorm_Count : 1100
compr_Average : 2.20
compr_Average : 2.20 dB
compr_Minimum : -1.80
compr_Minimum : -1.80 dB
compr_Maximum : 5.74
compr_Maximum : 5.74 dB
compr_Count : 828
dynrng_Average : 1.79
dynrng_Average : 1.79 dB
dynrng_Minimum : -1.97
dynrng_Minimum : -1.97 dB
dynrng_Maximum : 5.88
dynrng_Maximum : 5.88 dB
dynrng_Count : 1058
format_identifier : AC-3
Source : 00000.m2ts / 00000.m2ts

Using version 2020-06-25--02-11-43
Audio #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Muxing mode : Stream extension
Codec ID : 134
Duration : 1 h 42 min
Bit rate mode : Variable
Channel(s) : 6 channels
Channel layout : C L R Ls Rs LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 SPF)
Bit depth : 24 bits
Compression mode : Lossless
Language : English
Source : 00000.m2ts / 00000.m2ts

Audio #2
ID : 4353 (0x1101)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 1 h 42 min
Bit rate mode : Constant
Bit rate : 224 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 165 MiB
Language : English
Service kind : Complete Main
bsid : 6
Dialog Normalization : -27
Dialog Normalization : -27 dB
compr : 1.94
compr : 1.94 dB
dynrng : 1.26
dynrng : 1.26 dB
dsurmod : 1
dsurmod : Not Dolby Surround encoded
acmod : 2
lfeon : 0
dialnorm_Average : -27
dialnorm_Average : -27 dB
dialnorm_Minimum : -27
dialnorm_Minimum : -27 dB
dialnorm_Maximum : -27
dialnorm_Maximum : -27 dB
dialnorm_Count : 1090
compr_Average : 2.23
compr_Average : 2.23 dB
compr_Minimum : -1.80
compr_Minimum : -1.80 dB
compr_Maximum : 5.74
compr_Maximum : 5.74 dB
compr_Count : 818
dynrng_Average : 1.80
dynrng_Average : 1.80 dB
dynrng_Minimum : -1.97
dynrng_Minimum : -1.97 dB
dynrng_Maximum : 5.88
dynrng_Maximum : 5.88 dB
dynrng_Count : 1048
format_identifier : AC-3
Source : 00000.m2ts / 00000.m2ts

[FilipeAmadeuO]

Audio delay bug seems to be acorrected in today binary:
https://github.com/justdan96/tsMuxer/commit/6fb457b961734fbdf20d95fc65623563480bc176

[Peter_A]

Audio delay bug seems to be acorrected in today binary:
https://github.com/justdan96/tsMuxer/commit/6fb457b961734fbdf20d95fc65623563480bc176

Thanks. I'll test the new version out. I did check for an update yesterday and did not see one, but I did not check today before posting (which I should have done).

Have the releases been pretty stable lately, in general?

[imhh11]

@a5180007

For the dual layer profile 7.06 TS files, it says: Dolby Vision, Version 1.0, dvhe.07.06, EL+RPU, 8 compatible / SMPTE ST 2086, HDR10 compatible
for the dual layer profile 7.06 MP4 files, it says Dolby Vision, Version 1.0, dvhe.07.06, EL+RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible

what is ''8 compatible'' ? this is a long shot but could it be the reason of the bug with the dual layer DV TS/M2TS files on the Sony x700? I think it worth a try.

thank you !

[cogira]

@a5180007

For the dual layer profile 7.06 TS files, it says: Dolby Vision, Version 1.0, dvhe.07.06, EL+RPU, 8 compatible / SMPTE ST 2086, HDR10 compatible
for the dual layer profile 7.06 MP4 files, it says Dolby Vision, Version 1.0, dvhe.07.06, EL+RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible

what is ''8 compatible'' ? this is a long shot but could it be the reason of the bug with the dual layer DV TS/M2TS files on the Sony x700? I think it worth a try.

thank you !

+1
I have the same problem since long time ago.

[a5180007]

what is ''8 compatible'' ?
@imhh11 you might have something. The Dolby spec 1.2 for the Dovi descriptor is:

https://i.imgur.com/shJ7WXg.png

However:
Mediainfo Code for decoding the descriptor (https://github.com/MediaArea/MediaInfoLib/blob/702d6b20c7bdaccf2dc2b7c5d6ceca673d5c608a/Source/MediaInfo/Multiple/File_Mpeg_Descriptors.cpp#L3457)

Ffmpeg Code for decoding the descriptor (https://github.com/FFmpeg/FFmpeg/blob/e71d73b09652f4fc96e512a7d6d4c2ab41860f27/libavformat/mpegts.c#L2170)

Neither ffmpeg nor mediainfo read the dependency_pid, they read directly the compatibility_id !!! Hence the 8 (first nibble of PID 0x1011).

So as version 1 seems to be incorrect, I will change the descriptor to version 2 major, and put the reading of the compatibility_id just after reading the BL flag.

[yannick92]

Hello,

What future for the new "IETF BCP 47 language tags" and its implementation in TsMuxer?
thx

https://gitlab.com/mbunkus/mkvtoolnix/-/wikis/Languages-in-Matroska-and-MKVToolNix

[imhh11]

So as version 1 seems to be incorrect, I will change the descriptor to version 2 major, and put the reading of the compatibility_id just after reading the BL flag.

great thank you !


EDIT:

I get a black screen with the latest version and DV isn't triggered.
Mediainfo now say DV Version 2.0 but is Dolby Vision Version 1.0 bluray compatible possible ?

[MrVideo]

Should be fixed starting with 2020-09-17--02-22-29 (https://bintray.com/justdan96/tsMuxer/tsMuxerGUI-Nightly/2020-09-17--02-22-29#files), please report if this keeps happening.
OK, Will do. Thanks.

[a5180007]

I get a black screen with the latest version and DV isn't triggered.
Mediainfo now say DV Version 2.0 but is Dolby Vision Version 1.0 bluray compatible possible ?

@imhh11, so your player would not be compatible with DV 2.0 ? Could you please try https://github.com/jcdr428/tsMuxer/suites/1234807529/artifacts/18624616, to see whether DV 1.0 still works with the swap compatibility_id / dependency_pid.

Edit: Mediainfo now shows 'Blu-ray compatible' instead of '8 compatible'.

[imhh11]

thanks this version looks promising. I'll be home in a couple of hours to try it...

Maybe @cogira will try before me.

[cogira]

@imhh11, so your player would not be compatible with DV 2.0 ? Could you please try https://github.com/jcdr428/tsMuxer/suites/1234807529/artifacts/18624616, to see whether DV 1.0 still works with the swap compatibility_id / dependency_pid.

Edit: Mediainfo now shows 'Blu-ray compatible' instead of '8 compatible'.

The linkk is not valid

[a5180007]

The linkk is not valid

The link is valid, you simply need to register on Github. Alternative OneDrive link. (https://1drv.ms/u/s!AqRZp848Q4jUgbRk_yF6IAPsuZcdww?e=1Rzzej)

[cogira]

I download it from alternative link. will test and report.
Thank you

[cogira]

I made ts and m2ts versions.
Both have the same behaviour:
Black screen
the file does not start to play and the counter stays at zero.
The x700 player hangs and do not respond anymore to the commands. Had to pull out the power chord and then reconnect again to restablish the correct player operation.

[filler56789]

The link is valid, you simply need to register on Github.

Which nowadays is not a good idea, considering that GitHub was bought my µ$oft and µ$oft ruined GitHub,
I mean,

https://github.community/t/new-security-feature-device-verification/10216/5

and

https://github.community/t/disable-remove-email-device-verification-prompt-on-login-not-the-2fa/2333/2

[imhh11]

I made ts and m2ts versions.
Both have the same behaviour:
Black screen
the file does not start to play and the counter stays at zero.
The x700 player hangs and do not respond anymore to the commands. Had to pull out the power chord and then reconnect again to restablish the correct player operation.

same result. Damn, I really thought that version would fix the x700 bug. Back to w64-nightly-2020-09-19--02-23-22 I guess.

thank's anyway @a5180007

[a5180007]

same result. Damn, I really thought that version would fix the x700 bug. Back to w64-nightly-2020-09-19--02-23-22 I guess.

@cogira @imhh11 please try this alternative (https://1drv.ms/u/s!AqRZp848Q4jUgbRlz31ddXi1M9-VCQ?e=Ki7iJQ).
I've put the reserved nibble at the end. If it does not work and nobody can advise on the right DOVI descriptor syntax, I am out of ideas...


bl_present_flag 1
dv_bl_signal_compatibility_id 4
If (!bl_present_flag) {
dependency_pid 13
reserved 3
}
reserved 4

[cogira]

Tested as before. Unfortunately nothing has changed. Exactly the same problems.
Thank you for your efforts @a5180007

[imhh11]

yep, I confirm. Same behavior but the file is Dolby vision V2 ... is the same change but with DV V1 possible ?

[a5180007]

yep, I confirm. Same behavior but the file is Dolby vision V2 ... is the same change but with DV V1 possible ?

@imhh11 @cogira same but with V1 (https://1drv.ms/u/s!AqRZp848Q4jUgbRmAfndIPLFatLFHA?e=bEg0NJ).

[cogira]

Tested and same results. Thank you again.

[yannick92]

Hi,

In the git-e7133f9 version, I noticed in the remux a change in the management of SEIs compared to 2.6.12.

Could there be an impact on the correct functioning of the files obtained with this new method?
Viewing problem?
Compatibility on video players? etc ...

In my case, I mainly use a PS3 to watch my remux movies.
Thank you in advance for your clarifications

Yannick


On the 2.6.12

17495


Actually, this is normal ?

17496

[a5180007]

Tested and same results. Thank you again.
Ok. So I will revert to previous v1 Dovi descriptor as described in the Dobly spec 1.2. Until somebody can confirm the structure of the v2 Dovi descriptor or give a working profile 7 sample, Mediainfo will keep on showing "8 compatible"... :mad:

[imhh11]

this sample is probably useless because it's a single layer BL+EL+RPU but this TS file play properly and does not have any bug on the x700.
https://drive.google.com/file/d/1bU026TmdlcJiH6mraPy8FBinpBVZIxhd/view?usp=sharing

same scene in dual layer TS with the bug:
https://drive.google.com/file/d/1Cy6QFAZu8HBnl59ohFHElQosS2bVhAAm/view?usp=sharing

same scene in dual layer mp4 without the bug:
https://drive.google.com/file/d/1sMvvwnBix0ZBQistaddqrgdtoz8qVlG9/view?usp=sharing

[a5180007]

In the git-e7133f9 version, I noticed in the remux a change in the management of SEIs compared to 2.6.12.

Could there be an impact on the correct functioning of the files obtained with this new method?
Viewing problem?
Compatibility on video players? etc ...


Bonjour Yannick, 2.6.12 was buggy: it did not detect the situation where two different pps can have the same id, resulting in corrupted H264 muxed stream. With 2.6.15, when this situation is detected, tsMuxer stops adding the timing SEI to the H264 stream. Therefore the resulting stream is still missing the timing SEI (as was the original stream), but at least it is not corrupted.

So this is still work in progress, as ultimately tsMuxer should correct and add the timing SEI when two different pps or sps with the same id are detected.

[a5180007]

same scene in dual layer TS with the bug:
https://drive.google.com/file/d/1Cy6QFAZu8HBnl59ohFHElQosS2bVhAAm/view?usp=sharing


Thanks @imhh11, but it does not help. Dovi descriptor is:

descriptor_tag: 0xb0
descriptor_length: 7
dv_version_major: 1
dv_version_minor: 0
dv_profile: 7
dv_level: 6
rpu_present_flag: 1
el_present_flag: 1
bl_present_flag: 0
dependency_pid: 0x1011
reserved: 0b111
dv_bl_signal_compatibility_id: 6
reserved: 0b1111

Buggy despite being strictly as per Dolby document.
What I need is a non-buggy profile 7.

Could you please test this version (https://1drv.ms/u/s!AqRZp848Q4jUgbRnhVUh1BMq_uC91g?e=LSHdV6) . I've simply removed the dependency_pid part, instead of moving it to the end.

[yannick92]

Bonjour Yannick, 2.6.12 was buggy: it did not detect the situation where two different pps can have the same id, resulting in corrupted H264 muxed stream. With 2.6.15, when this situation is detected, tsMuxer stops adding the timing SEI to the H264 stream. Therefore the resulting stream is still missing the timing SEI (as was the original stream), but at least it is not corrupted.

So this is still work in progress, as ultimately tsMuxer should correct and add the timing SEI when two different pps or sps with the same id are detected.

Ok, thanks for the explanations, it's a little clearer for me ...

Nevertheless, I am asking myself several legitimate questions about the use of new versions of TsMuxer as a plugin in another software that I have been using constantly for a long time now ...: "PS3Muxer Copyright (C) 2011 Anton Burdinuk"

Can I allow myself to do a quick parenthesis on its operation with the TsMuxer plugin (currently 1.10.6) as well as my questions?

Concretely, I mainly use a PS3 to play my video files, but as you probably know, this one has a lot of compatibility restrictions (fat 32, ts and m2ts only, ac-3 only, Level H264 4.1 max. .)

So I use the excellent PS3Muxer for converting MKV to the PS3.
Very practical and of high quality, in its operation it uses different plugins.
It is an "All in One", so it goes all at once: demuxer (MKV Extract), re-encode the DTS audio in AC-3 ( ffmpeg), remux in m2ts (TsMuxer) and splitter in Fat 32.
However, there has not been an update since 2011, but it still works great!

So I come to my questions: it uses version 1.10.6 of TsMuxer, is it also bugged on SEI like version 2.6.12?
I also noticed that there is no longer the line "H264 bitstream changed: insert nal unit delimiters" in the last versions of TsMuxer, is this normal and what are the consequences?

For all practical purposes, here is a functioning log of PS3Muxer.

Thanks to the whole team

Yannick

17497

[imhh11]

Could you please test this version (https://1drv.ms/u/s!AqRZp848Q4jUgbRnhVUh1BMq_uC91g?e=LSHdV6) . I've simply removed the dependency_pid part, instead of moving it to the end.

same black screen issue :(

[a5180007]

same black screen issue :(

Ok, I give up :)
The latest nightly should be back as before, with the Mediainfo "8 compatible" and the x700 pixellisation issue when the player is stopped.

[imhh11]

all good, it's not a big issue. :)
I watched 50&+ TS DV movies and they all work like a charm while with the mp4 container, some won't play or will freeze. thank's again for your work!



EDIT:

I dont know if this could help but when you play/stop this LG file, it fixes the bug where normally, you had to reboot the player to fix it. I tried many other videos(netflix/amazon/bluray/sdr file/hdr file) and none was able to do that.
So since the LG file also have an EL(but is single layer), it looks like x700 get stuck in a faulty mode when you play a dual layer TS but then playing back the lg file can somehow reset it.
lg demo
https://drive.google.com/file/d/1ZRwhD-PeD6Wptwcxtc8KYMwP1R32vcxg/view?usp=sharing

I hope you understand what I'm saying, my english is not so good. Credit goes to @cogira for finding this workaround



EDIT2: also, i just noticed that when you remux that file using the latest nightly, the HEVC stream disappear from mediainfo.

[a5180007]

EDIT2: also, i just noticed that when you remux that file using the latest nightly, the HEVC stream disappear from mediainfo.

After analysis, this behavior is the same since 2.6.12. Another thing to look at...

[mczuzlak]

Hello folks. I'm using tsmuxer explicitly for remuxing my retail uhd-bd backups with dark grey subtitles ( subtitle edit export as blu-ray sup) I've created my self as I'm sensitive to the retails way too bright ones.
Most of the time I can play them just fine on my oppo-203 as iso or bd folder.
I've a slight problem now with The Fifth Element GBR release that came out just recently with dolby vision. ( I can provide mediainfo export or something if needed )
I do everything as usual import the playlist of the main title add my sup file and hit muxing. The resulting output freezes at a certain frame near the beginning. It occurs right after the part where you can see the studiocanal logo.
It's strange as even though it's the main title I see even on the retails bd backup that after this scene my AVR shows a spilt second change in the codec as it would start a new title. Thats the part where tsmuxer seems to have a problem.

I hope I could describe it well. Is this maybe a known bug with other releases as well ? Any older nightlies I should try ?

Thanks

EDIT : Remuxing the tsmuxer output ( the one that freezes ) with CloneBD resolves the problem. No more freeze after that.
I wish tsmuxer could do the same.

[Emulgator]

That would look like changing parameters mid-stream.
Well possible for broadcast, never thought that would be Blu-ray legal. A new kind of copy protection ?
IIRC something regarding mid-stream audio codec or channel count changes had been reported from satellite broadcasts...
Modern chipsets may obey that. If that can be handled by vanilla tsMuxeR as remux ? Doubt that.
Maybe you will have to demux before and append these streams in tsMuxeR.

I would suggest to try DGDemux (now with preview), you will comfortably see which playlist it is.
Lets see if it handles such demux already...

[MrVideo]

Well possible for broadcast, never thought that would be Blu-ray legal. A new kind of copy protection?
AFAIK, U.S. OTA broadcasters are not allowed to change from AC3-5.1 to AC3-2.0, and vice versa.
IIRC something regarding mid-stream audio codec or channel count changes had been reported from satellite broadcasts...
There are several C-Band services that change from AC3-5.1 to AC3-2.0 and back. Even the main Ku-Band PBS network feed switches back and forth.