tsMuxer Open Source

[filler56789]

Originally Posted by a5180007

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-secur...cation/10216/5

and

https://github.community/t/disable-r...the-2fa/2333/2

[imhh11]

Originally Posted by 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.

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]

Originally Posted by imhh11

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.
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]

Originally Posted by imhh11

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.

[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




Actually, this is normal ?

[a5180007]

Originally Posted by cogira

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"...

[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/1bU0...ew?usp=sharing

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

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

[a5180007]

Originally Posted by yannick92

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]

Originally Posted by imhh11

same scene in dual layer TS with the bug:
https://drive.google.com/file/d/1Cy6...ew?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 . I've simply removed the dependency_pid part, instead of moving it to the end.

[yannick92]

Originally Posted by a5180007

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

[imhh11]

Originally Posted by a5180007

Could you please test this version . I've simply removed the dependency_pid part, instead of moving it to the end.

same black screen issue

[a5180007]

Originally Posted by imhh11

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/1ZRw...ew?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]

Originally Posted by imhh11

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]

Originally Posted by Emulgator

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.