3D-plane numbers differing from tsMuxer info

von Suppé · Post by **von Suppé** » Sat May 25, 2024 2:17 am

Lectori salutem,

Being busy with the Hobbit extended 3D trilogy (UK) I noticed differing 3D-plane numbers shown by DGDemux GUI vs. latest tsMuxer GUI.

Please feel free to correct me if I'm wrong, I've read to believe that (within BD specs) the subtitles order in mpls doesn't necessarily have to match the order of the PIDs. Where in the past tsMuxer did suffer from a bug in assuming these orders were the same, with the result of possibly showing wrongly assigned plane numbers. This bug has long been ironed out in tsMuxer.

So, whilst assuming tsMuxer is showing the proper offset numbers and DGDemux showing different numbers, does this matter be looked upon, or am I wrongly informed? I have read the DGDemux.txt

but couldn't find any relevant info on such matter.

Post by **Rocky** » Sat May 25, 2024 6:42 am

That is not good. I'll test it with the 3D disks I have on hand. What is the TSMuxerGUI version?

von Suppé · Post by **von Suppé** » Sat May 25, 2024 7:08 am

tsMuxer 2024-05-12
version number in GUI: git-cb04552

https://github.com/justdan96/tsMuxer/re ... 18/w64.zip

I have the BD ISOs here in case you need something from this UK version

Post by **Rocky** » Sun May 26, 2024 10:43 am

It seems that you are perhaps misinformed that tsMuxer has ironed out its issues. It appears to me (with Prometheus_3D) to still be assuming the planes are in PID order. My plane numbers are parsed from the MPLS according to spec and they agree with BD3D2MK3D, which rolz has meticulously researched and implemented.

rolz wrote: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.

https://forum.doom9.org/showthread.php? ... ost1882670

Britney · Post by **Britney** » Sun May 26, 2024 4:19 pm

von Suppé wrote: ↑
Sat May 25, 2024 2:17 am
Lectori salutem

I feel like that's not fair to bimbos (not me).

Post by **Bullwinkle** » Sun May 26, 2024 4:22 pm

Ya never know. How can we be sure?

Post by **Sherman** » Sun May 26, 2024 6:09 pm

if ne1 says ______ fill in the blanks
then you know

von Suppé · Post by **von Suppé** » Mon May 27, 2024 3:04 am

Rocky wrote: ↑
Sun May 26, 2024 10:43 am
...My plane numbers are parsed from the MPLS according to spec and they agree with BD3D2MK3D, which rolz has meticulously researched and implemented.

Yes, I know r0lZ has put in much effort to deal with this matter and his BD3D2MK3D tool would show the correct values. Few years ago I actually got back on the matter at VH (FYI I am Ennio there): https://forum.videohelp.com/threads/395 ... ost2603430

Yet the 3D trilogy I aforementioned does show different in DGDemux GUI. Where both BD3D2MK3D and tsMuxer show 3d-plane 2 for the english PGS, DGDemux shows plane 3. Is it possible both tsMuxer and BD3D2MK3D are wrong here?

I you'd like I can upload some key elements out of the ISOs.

Post by **Rocky** » Mon May 27, 2024 5:53 am

von Suppé wrote: ↑
Mon May 27, 2024 3:04 am
Yet the 3D trilogy I aforementioned does show different in DGDemux GUI. Where both BD3D2MK3D and tsMuxer show 3d-plane 2 for the english PGS, DGDemux shows plane 3. Is it possible both tsMuxer and BD3D2MK3D are wrong here?

I you'd like I can upload some key elements out of the ISOs.

Anything is possible. Please provide the MPLS file that behaves that way as well as a screenshot of DGDemuxGUI displaying the streams for that MPLS.

Once I get that please keep checking back in case I need anything else. Thank you.

von Suppé · Post by **von Suppé** » Mon May 27, 2024 6:37 am

Here ya go: https://mega.nz/file/jogQAISJ#CfZO4xV8t ... 63nQBjfVSM

Post by **Rocky** » Mon May 27, 2024 6:56 am

Thank you. Please provide 00049.clpi from the CLIPINF folder.

Post by **Rocky** » Mon May 27, 2024 8:32 am

I cobbled up a 00049.clpi but I'm going to need the full disk. Please provide a link to purchase it or offer to provide it under fair use. If you agree to the latter, can send FTP details, etc. in PM.

von Suppé · Post by **von Suppé** » Mon May 27, 2024 9:08 am

No problem. Please provide me with info as to how to do so.

Post by **Rocky** » Tue May 28, 2024 12:19 pm

OK, the problem is that the list of plane numbers in the STN_table_SS excludes hidden PGS tracks, whereas I have been including them. Should be an easy fix.

Now, regarding the hidden streams, tsMuxer shows no plane for them, while BD3D2MK3D shows them with plane 1. I plan to follow tsMuxer in this regard. Any thoughts?

von Suppé · Post by **von Suppé** » Tue May 28, 2024 1:08 pm

I have no idea what to think about the hidden PGS. My gut feel says to follow BD3D2MK3D found value instead of tsMuxer's none.

But I have an idea. Eventhough the hidden SUPs in this case are of no importance to me (won't use them in my remux), I wanna do the right thing here. I'm gonna do a remux with the hidden subtitles authored two times: one without 3D-plane assignment (tsMuxer) and one assigned with the value found by BD3D2MK3D. Then I'll take a look at the remux in 3D and compare it with viewing the native ISO. This way I can maybe determine how the subs are at least meant/authored to be displayed. If no number is assigned, the PGS should appear on screen-depth ("2D"). This can go well throughout the whole movie, but I can imagine some subs interfering with video-objects. Have to see.
I'll have a go with this; please give it a rest for now and allow me a couple of days time. Sound good?

von Suppé · Post by **von Suppé** » Wed May 29, 2024 2:53 am

Already done. It rather quickly became obvious that the hidden Japanese PGS natively has a 3D-plane assigned. Depths change throughout, appearing consistent with the video. Whereas with no depth assignment the subs are sometimes very hard to read because they interfere with video.
So my general thought for hidden subs would be that they too need a 3D-plane assigned, to which I'd go for values found by BD3D2MK3D.

Post by **Rocky** » Wed May 29, 2024 8:54 am

According to my understanding, to try to assign a plane number to a hidden stream requires parsing the MVC SEI and doing some heuristics, which I currently do not do. So I will report the plane for hidden streams as 255, consistent with tsMuxer.

Please test this and let me know if there are any issues:

https://rationalqm.us/misc/DGDemux_vonsuppe.zip

von Suppé · Post by **von Suppé** » Wed May 29, 2024 9:57 am

GUI looks good, first demuxing went flawless. Will do some more runs.

Rocky wrote: ↑
Wed May 29, 2024 8:54 am

According to my understanding, to try to assign a plane number to a hidden stream requires parsing the MVC SEI and doing some heuristics, which I currently do not do.

Maybe it can be done easier? Hidden PGS don't have to be hidden in other playlists. As an example here, the Japanese PGS isn't hidden in both playlist 00099 and 00101. Where it does show a plane value: 1. Since these playlists refer to the same m2ts/SSIF, maybe it's a handy idea to retrieve values from other playlists and combine the values in the playlist(s) where they are shown as "hidden"?

Post by **Rocky** » Wed May 29, 2024 10:52 am

Thank you for your testing.

von Suppé wrote: ↑
Wed May 29, 2024 9:57 am
Hidden PGS don't have to be hidden in other playlists. As an example here, the Japanese PGS isn't hidden in both playlist 00099 and 00101. Where it does show a plane value: 1. Since these playlists refer to the same m2ts/SSIF, maybe it's a handy idea to retrieve values from other playlists and combine the values in the playlist(s) where they are shown as "hidden"?

It's so easy for you to just click around on the MPLSs and see things. Therefore, and because this is getting into unusual cases, I won't try to automate that.

von Suppé · Post by **von Suppé** » Thu May 30, 2024 3:39 am

Ok, fair enough. Already happy with the fix for non-hidden subs.
For which I thank you.

Post by **Rocky** » Sat Jun 01, 2024 7:42 am

You are welcome. Released as build 74. Marking resolved.

hubblec4 · Post by **hubblec4** » Sun Jun 02, 2024 11:35 am

Hi Rocky

I have to report an issue and I guess it has to do with the latest fix.

cE don't work with DGDemux 1.0.0.74, so I looked into the logs and found the following:

Code: Select all

DGDemux 1.0.0.74 by Donald A. Graft
Copyright (C) 2019-2023 Donald A. Graft, All Rights Reserved [Made in Frostbite Falls, Minnesota]

Files:
00351.m2ts

Streams:
   2: *Video [AVC 23.976 1080p 16:9]
.........

The PID of the video stream is not correct.

with DGDemux 1.0.0.73 it looks like this:

Code: Select all

Streams:
1011: Video [AVC 23.976 1080p 16:9]

I have attached a disc chunk for first quick look. Main video mpls is 00001.mpls.

Post by **Rocky** » Sun Jun 02, 2024 11:53 am

Thanks I should I have noticed that. Squirrel tunnel vision. Will fix straightaway.

Post by **Rocky** » Sun Jun 02, 2024 12:02 pm

Fixed. Please re-download 74.

hubblec4 · Post by **hubblec4** » Sun Jun 02, 2024 12:17 pm

The video PID is now there, but cE don't work, and I found one more difference.

For all audio streams the language tag is missing:

1.0.0.74:

Code: Select all

Streams:
1011: Video [AVC 23.976 1080p 16:9]
1100: THD 48000 8ch (+ embedded AC3)
1101: AC3 5.1 48 640
1102: AC3 5.1 48 640
1103: AC3 5.1 48 640
1104: AC3 5.1 48 640
1105: AC3 5.1 48 640
1106: AC3 5.1 48 640
1107: AC3 2.0 48 224
1108: AC3 5.1 48 640

1.0.0.73:

Code: Select all

Streams:
1011: Video [AVC 23.976 1080p 16:9]
1100: THD 48000 8ch (+ embedded AC3) [eng]
1101: AC3 5.1 48 640 [ces]
1102: AC3 5.1 48 640 [deu]
1103: AC3 5.1 48 640 [spa]
1104: AC3 5.1 48 640 [ita]
1105: AC3 5.1 48 640 [hun]
1106: AC3 5.1 48 640 [pol]
1107: AC3 2.0 48 224 [eng]
1108: AC3 5.1 48 640 [eng]