BD3D2MK3D v1.36: Convert 3D BDs or MKV to 3D SBS, TAB or FS MKV - Support thread

[r0lZ]

Originally Posted by FTP

However, it's surprising it's the reason of the crash, as why would the accent be a problem for the 64 bits versions and not the 2.6.0 in 32 bits?

Honestly, I don't know. Perhaps because the 64-bit version is newer and it uses the UTF-8 character encoding, while the 32-bit version still use the infamous Windows codepages.

I will add a check in BD3D2MK3D, and if it detects non-ASCII characters in the path, it will issue a warning.

Originally Posted by FTP

You previously said both should work.
If we forget about BD3D2MK3D not detecting the official JRE in the Help menu, how can I test if BD3D2MK3D is in fact able to use this official JRE for the subtitles?

Yes, both should work. And the OpenJDK version should work equally fine with Plex and all other Java based applications.
As I wrote, have a look at the log. The command that is used by BD3D2MK3D during a subtitles conversion is written. If it's BDSup2Sub++.exe, it's the C++ version, and if it's BSSup2Sub.jar, it's the Java version.

Originally Posted by FTP

Thanks very much for your great support!

You're welcome.
I hope you will find a good solution for Plex. I can't help you, as I don't use Plex, but if you find the setting to modify, please post it here. Your finding will certainly be useful to other users.

[FTP]

Originally Posted by FTP

Understand. I'll have a look at Plex. I would be surprised if there's no solution as I've read a lot of BD3D2MK3D users using it to later on play the movies on Plex.

Indeed, you're right it's a question of player.
Regarding Plex, some players work fine, some don't:

• Web: OK
• Windows: NOK
• iOS (iPhone/iPad): NOK
• tvOS (Apple TV): NOK
• WebOS (LG): OK
• Android TV: OK

And unfortunately, I would like the Apple TV player to work.
So I've open a topic on the Plex forum, I hope I'll get an answer.
https://forums.plex.tv/t/subtitles-o...players/898754

I started by asking if there are specific settings and if not, I'll ask if they can fix the issue, but I'm not that confident. It looks like the issue exists for a very long time
https://forums.plex.tv/t/sbs-3d-subtitle-support/280710
No answer, no fix since 2018.

[r0lZ]

Thanks for the information.
I agree that they probably won't do anything. These forums where threads are automatically closed after a certain amount of time are made specifically to prevent a particular request from having to be considered. It doesn't make me want to be interested in Plex!

[r0lZ]

V1.24 is here. It's not a major update, but it fixes a few little bugs, and it includes the newest versions of the third-party tools.

v1.34 (January 6, 2024)
- Fixed a few very little bugs
- Wraped with the latest version of freeWrap (v6.75)
- Updated tsMuxeR Open Source to the latest version (git-7f8667d 2024-06-06-02-00-53)
- Updated x264 to the latest version (v 0.164.3204)
- Updated x265 to the latest version (v 4.1+54)
- Updated mkvtoolnix to the latest version (v89.0 'And the Melody Still Lingers On (Night in Tunisia)')

As usual, you can download it here: BD3D2MK3D.7z

Note that this version has been only slightly tested. If you encounter any problem, you can still download v1.33 here.

[r0lZ]

Sorry, due to important changes in tsMuxeR, BD3D2MK3D v1.34 doesn't work correctly. I am currently fixing it, but that may take some time. In the meantime, use v1.33, that can still be downloaded here.

[r0lZ]

Hopefully, the bug related to tsMuxeR is fixed. Sorry for the inconvenience.

v1.35 (January 11, 2025)
- Fixed a big bug in v1.34 due to different output filenames in the latest tsMuxeR. Sorry!

Download latest version: BD3D2MK3D.7z

[tebasuna51]

Thanks r0lZ

[Enet47]

Originally Posted by r0lZ

Hopefully, the bug related to tsMuxeR is fixed. Sorry for the inconvenience.

Download latest version: BD3D2MK3D.7z

I'm starting to convert my 3D files to full-sbs but my media players wouldn't detect it as full-sbs. Then when I looked at the mkv header it is set to 3840x2160 not 3840x1080. The Video Display height property is set to 2160 but the Video Display Pixel property is set to 1080. Both should be set to 1080 so I think that maybe you are producing 3840x2160 files which is why my media players won't detect the full-sbs. I can modify the header to 1080p but that makes things worse futher down my display chain.

[r0lZ]

Originally Posted by Enet47

Both should be set to 1080 [...]

Well, unfortunately, for Full-SBS, there is no precise standard for the display resolution and aspect ratio. It's because originally, only Half-SBS has been defined officially. Therefore, the "correct" AR to use depends of the player. It's why there is a menu Settings -> Full SBS/T&B Aspect Ratio. Try to play with that settings. (Note that you can manually modify the AR and resolution settings without having to re-create the whole project. See the __ENCODE_3D.cmd and __MUX_3D_OPTIONS.json files.)

Also, a good player should retrieve the 3D mode from the video header (the frame-packing property of the x264 encoder) and/or from the MKV header (the stereo-mode property). All other methods are bizarre, non-official and prone to errors.

Do you encode your files with x264 or x265 ? Unfortunately, h265 does not support the frame-packing property, because all 3D video streams are supposed to be encoded in h264. Many hardware players support only the frame-packing and ignore the MKV stereo-mode. It's a pity.

Originally Posted by Enet47

Then when I looked at the mkv header it is set to 3840x2160 not 3840x1080.

Indeed, that's bizarre. I will have a look...

But no, BD3D2MK3D does NOT produce 3840x2160 files. It uses only the anisynth commands HorizontalReduceBy2 or VerticalReduceBy2 to produce Half-SBS or Half-TAB. For Full-SBS/TAB, the original images are just stacked together horizontally or vertically, without any resize.

[Enet47]

Originally Posted by r0lZ

Indeed, that's bizarre. I will have a look...

But no, BD3D2MK3D does NOT produce 3840x2160 files. It uses only the anisynth commands HorizontalReduceBy2 or VerticalReduceBy2 to produce Half-SBS or Half-TAB. For Full-SBS/TAB, the original images are just stacked together horizontally or vertically, without any resize.

Hi. Thanks for checking. I looked at the code and saw the same as you but I was hoping that there was something I was missing or maybe there was an x264 option I could use to force the resolution.

I checked a second file I recently converted to full SBS and it has the same issue. When I do "fix" the Display Height attribute then my SVP software interpolation software can't play it properly. I convert it with full-sbs and this happens, there's nothing else which is why I was surprised that there's nothing obvious in the code that is causing this.

[Enet47]

Originally Posted by r0lZ

Well, unfortunately, for Full-SBS, there is no precise standard for the display resolution and aspect ratio. It's because originally, only Half-SBS has been defined officially. Therefore, the "correct" AR to use depends of the player. It's why there is a menu Settings -> Full SBS/T&B Aspect Ratio. Try to play with that settings. (Note that you can manually modify the AR and resolution settings without having to re-create the whole project. See the __ENCODE_3D.cmd and __MUX_3D_OPTIONS.json files.)

Also, a good player should retrieve the 3D mode from the video header (the frame-packing property of the x264 encoder) and/or from the MKV header (the stereo-mode property). All other methods are bizarre, non-official and prone to errors.

Do you encode your files with x264 or x265 ? Unfortunately, h265 does not support the frame-packing property, because all 3D video streams are supposed to be encoded in h264. Many hardware players support only the frame-packing and ignore the MKV stereo-mode. It's a pity.


Indeed, that's bizarre. I will have a look...

But no, BD3D2MK3D does NOT produce 3840x2160 files. It uses only the anisynth commands HorizontalReduceBy2 or VerticalReduceBy2 to produce Half-SBS or Half-TAB. For Full-SBS/TAB, the original images are just stacked together horizontally or vertically, without any resize.

I've sorted the stuttering issue. That was from my side. But I still have to manually update the MKV header of each full SBS file I convert. Something somewhere in the software is setting the display height attribute to 2160. I wonder if it is somehow taking it from the screen resolution when the conversion is happening?

[r0lZ]

Not sure, but the problem may be caused by a confusion about what means "display height". I haven't much time to check that currently, but IMO the display width and height are another way to specify the aspect ratio of the video picture at display time. And if it's really the case, the display dimension must be 1920x1080 or 3840x2160 or any multiple of this dimension.
In the other hand, the physical width for full-SBS has to be two times the display width, due to the horizontal stacking of the two views.

[r0lZ]

OK, I did a quick test with the different aspect ratio settings of BD3D2MK3D. Everything seems correct.

First test, with the Full-SBS Aspect Ratio options set to 32:9 and SAR 1:1 (first option for the two settings). Here is what I get:

Originally Posted by Mediainfo

Width : 3 840 pixels
Height : 1 080 pixels
Display aspect ratio : 3.556

(3.556 is another way to write 32:9)

Originally Posted by mkvinfo

| + Pixel width: 3840
| + Pixel height: 1080
| + Display width: 3840
| + Display height: 1080

When loaded in mkvtoolnix GUI, the Display width and height, without surprise, is 3840x1080 (32:9). IMO, that value is not correct, since the Display AR is 16:9, but most hardware and software players need that format. In practice, they require the SBS image AR, not the Display AR. It's why there is an option to control that value in BD3D2MK3D

Second test, with the settings set to 16:9 and SAR 1:2.

Originally Posted by Mediainfo

Width : 3 840 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9

Originally Posted by mkvinfo

| + Pixel width: 3840
| + Pixel height: 1080
| + Display width: 3840
| + Display height: 2160

In mkvtoolnix, the Display width and height is, again, perfectly coherent: 3840x2160 (equal to 1920x1080 and 16:9)
Again, everything is perfectly coherent with the chosen settings.

So, there is no problem with BD3D2MK3D. You may need a specific setting for your player, but you can easily select it in the GUI.

BTW, may I know what player(s) you use ?

[Enet47]

I think maybe the tests below have been swapped?

Originally Posted by r0lZ

OK, I did a quick test with the different aspect ratio settings of BD3D2MK3D. Everything seems correct.

First test, with the Full-SBS Aspect Ratio options set to 32:9 and SAR 1:1 (first option for the two settings). Here is what I get:

(3.556 is another way to write 32:9)

When loaded in mkvtoolnix GUI, the Display width and height, without surprise, is 3840x1080 (32:9). IMO, that value is not correct, since the Display AR is 16:9, but most hardware and software players need that format. In practice, they require the SBS image AR, not the Display AR. It's why there is an option to control that value in BD3D2MK3D

That's not what I'm getting. For SAR 1:1 I get 3840x2160 for Display Height. If I change Display Height to 3840x1080 then mpv player plays it correctly.

Originally Posted by r0lZ

Second test, with the settings set to 16:9 and SAR 1:2.


In mkvtoolnix, the Display width and height is, again, perfectly coherent: 3840x2160 (equal to 1920x1080 and 16:9)
Again, everything is perfectly coherent with the chosen settings.

So, there is no problem with BD3D2MK3D. You may need a specific setting for your player, but you can easily select it in the GUI.

BTW, may I know what player(s) you use ?

OK I will try with SAR 1:2 and hopefully this will give me 3840x1080. I will let you know how it goes. Thanks

[r0lZ]

Originally Posted by Enet47

I think maybe the tests below have been swapped?

Certainly not. It's what my code does, it's exactly what it produces and it's perfectly coherent.

Originally Posted by Enet47

That's not what I'm getting. For SAR 1:1 I get 3840x2160 for Display Height. If I change Display Height to 3840x1080 then mpv player plays it correctly.

That's not right at all.
What application do you use to read that values? It seems totally wrong!
And what is "mpv player"? Is it MPC (Media Player Classic)?

[Enet47]

Originally Posted by r0lZ

Certainly not. It's what my code does, it's exactly what it produces and it's perfectly coherent.


That's not right at all.
What application do you use to read that values? It seems totally wrong!
And what is "mpv player"? Is it MPC (Media Player Classic)?

I'm using the latest version of MKVToolNiX GUI and with SAR1:1
Video display height is 2160
video pixel height is 1080.

The player is mpv player which is like MPC with MadVR but much more (text based) configurable and even better picture quality.

[r0lZ]

It's exactly what I wrote:

Originally Posted by r0lZ

First test, with the Full-SBS Aspect Ratio options set to 32:9 and SAR 1:1 (first option for the two settings). Here is what I get:
...
When loaded in mkvtoolnix GUI, the Display width and height, without surprise, is 3840x1080 (32:9).

But note the AR set to 32:9. It's the combination of the AR plus the SAR that produces the display width/height. It is very difficult to know what setting a specific player takes into account and what setting it ignores. You should play with the two settings until you obtain the correct configuration for your player (and you may also have to play with the 3D and AR settings of the player).

I did not know the MPV player. It seems interesting. But anyway try with another player, just to be sure. I suggest Potplayer, probably the most versatile to play 3D videos (but I'm not sure for MadVR).

[Enet47]

Originally Posted by r0lZ

It's exactly what I wrote:


But note the AR set to 32:9. It's the combination of the AR plus the SAR that produces the display width/height. It is very difficult to know what setting a specific player takes into account and what setting it ignores. You should play with the two settings until you obtain the correct configuration for your player (and you may also have to play with the 3D and AR settings of the player).

I did not know the MPV player. It seems interesting. But anyway try with another player, just to be sure. I suggest Potplayer, probably the most versatile to play 3D videos (but I'm not sure for MadVR).

Thanks. I tried SAR 1:2 but display height is still set to 2160 and pixel height is still 1080. But if I replace 2160 with 1080 then mpv is OK with it. I will just leave the defaults as is then modify the header.

[Ksanto]

Hi, firstly thank for the work done. I want to make a Bug report:

I have now tried to convert my PAL 3DBD of Mad Max Fury road to Full frame side by side, three times with different quality settings. Every time between the 30 and 40 min mark, the frames change sides from left to right and vise versa. I have verified that this is indeed the File and not the players fault (using Plex Web and a Pico 4 / Pico 4 Ultra) by also testing it on my PC. Have already searched for this error online but did not find any mentions of this.

DB3D2MK3D Version used: 1.35 (Tcl/Tk 8.6.13 wrapped with freeWrap 6.75)
Windows Version used: Windows 10 (2009 22.12.2020 19045.5854)
Hardware used: i7 3520M
decryption software used: Passkey 9 9.4.7.6

Tell me if I can provide any additional Information that would help identifying the Problem.


Regards
Ksanto

[r0lZ]

Welcome to the Doom9 forum and thank you for your report, Ksanto.

You are the first person to report that problem. I did Mad Max myself without problem.

Can you disable the hardware acceleration (menu Settings/MVC Decoder/Hardware acceleration)? That's often the cause of similar issues. If that's sufficient, you may need to update your Intel drivers, or continue to decode without hardware acceleration.

If that doesn't work, please let me know and we will try other workarounds.