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

[von Suppé]

Not having such a mkv, did you look into MKVToolnix's header editor to see what can be altered in the "Video projection information" section?
The coded height of 1088 strikes me as odd for 3D. I wonder if this, in conjunction with HSBS (or HT&B) where half of a resolution is used anyways, would add to Plex's confusion.

[r0lZ]

Welcome to the Doom9 forums, zaudio !

I don't have Plex here, but I don't understand its report. The only places where the aspect ratio is specified is in the x264/x265 command (in the file __ENCODE_3D.cmd) and in the MKV muxing options (in the __MUX_3D_OPTIONS.json file). Here they are:
In the x264 command: --sar 1:1 (meaning square pixel)
In the MKV mux options: --aspect-ratio 0:16/9 (meaning again square pixel, given the 1080x1920 resolution)
Anamorphic is never specified (but it's not completely absurd, since the two views must be upscaled horizontally to re-create the original images for the two eyes).
Of course, the resolution is kept unmodified by BD3D2MK3D, and should therefore be 1080x1920. Obviously, the "Coded Height 1088" info comes from nowhere.

I agree that the aspect ratio settings can be problematic when the output format is Full-SBS or Full-TAB, and it's why there are options to change them, but for HSBS or HTAB, they are certainly correct.
Here is what MediaInfo displays with a HSBS encoded by BD3D2MK3D:

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
MultiView_Count                          : 2
MultiView_Layout                         : Side by Side (left eye first)
Format settings                          : CABAC / 4 Ref Frames
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 4 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 1 h 26 min
Bit rate                                 : 4 746 kb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.095
Stream size                              : 2.86 GiB (81%)
Title                                    : 3D Half-SBS (x264 high@L4.1 CRF 22 preset slow)
Writing library                          : x264 core 161 r3027 4121277
Encoding settings                        (removed)
Default                                  : Yes
Forced                                   : No
Color range                              : Limited
Matrix coefficients                      : BT.709

As you can see, the aspect ratio and the height are correct, there is nothing about anamorphic, and everything looks correct. So, I can only assume that Plex is the culprit.

Now, to reply to your question, you can, as von suppé suggests, edit the MKV header with mkvtoolnix. If you have the original project, you can also edit manually the __MUX_3D_OPTIONS.json file to change or completely remove the aspect ratio information. Then, just launch __MUX_3D.cmd to remux the file with the new settings.
You cal also modify or remove the SAR in the x264 command, but of course, you will have to re-encode the video stream completely.

Anyway, I suggest to contact the authors of Plex. And if you can find a solution, please let us know. I may add a settings or a workaround to avoid the problem.

[zaudio]

Yes I have looked at all the tools MKVToolnix offers; header editor; using mkvmerge directly to update aspect ration, display size, I also messed around with editing the options in the CMD files generated by BD3D2MK3D, looked at the avisynth script, all of it. Nothing seems to affect plex playback, and the common theme to files that are playing wrong are those two tags I mentioned; and it seems plex is applying an anormorphic squash/stretch depending on how think of it. Not knowing where those two are coming from, I can only guess it is mkvmerge adding them for some odd reason; I even tried running the .264 file output from AVISynth througha tool to change the aspect ration in there... but it already reports as SAR 1:1 anyway... and of course made zero difference. I tried mkvmerge's --engage option to not use the source file ar also... no difference.
Hopefully someone has a solution to this... it does appear that hsbs files created bu BD3D2MK3D 1.22 all do this from what I can tell

[zaudio]

Something else I noticed was when trying to edit my mkv headers with ffmpeg, using such as :

ffmpeg -i video.mkv -vcodec copy -acodec copy -bsf:v h264_metadata=sample_aspect_ratio=1/1 video2.mkv

in the output for the video stream I see:
Stream #0:0: Video: h264 (High), yuv420p(tv, bt709/unknown/unknown, progressive), 1920x1080 [SAR 1:1 DAR 16:9], SAR 2:1 DAR 32:9, 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc (default)

Notice the extra SAR 2:1 DAR 32:9

Maybe you could check your mkv with ffmeg ? It's not just plex; I suspect that second set of display properties is what is throwing plex...

[r0lZ]

Originally Posted by zaudio

Maybe you could check your mkv with ffmeg ? It's not just plex; I suspect that second set of display properties is what is throwing plex...

Well, I don't know why the second set appears. As you know, it is never specified. The advantage of HSBS or HTAB over Full-SBS/TAB is that the dimension and aspect ratio of the combined (SBS) image are identical to the dimension and aspect ratio of the two views after having splitted the video and resized the views. Therefore, the resolution MUST be 1920x1080, the PAR 16:9 and the SAR 1:1. But indeed, the two views are anamorphic in the combined picture, since they have to be resized to occupy the whole screen. I suspect therefore that PLEX and ffmpeg know that the video must be resized, and display that phantom second set of options, deduced automatically. But anyway, I can't modify that in BD3D2MK3D, especially if you have already tested with other AR values or without any AR settings at all.

Again, I think that the display problem is due to a bug in Plex (although I don't understand why it can play other 3D-SBS material correctly).

Perhaps you should try to remove the flags telling that the material is encoded in 3D-HSBS ? Maybe it's that flags that confuse Plex ? (Remove --frame-packing 3 in the x264 command and --stereo-mode 0:1 in the MKV options.) You may also need to remove the "SBS" or "3D-lrq" strings from the filename. Without that informations, Plex should be unable to detect that the video is in 3D and should display the two views side by side. Then try to change the display mode to switch to 3D, and see if that makes a difference.

[von Suppé]

Originally Posted by r0lZ

...although I don't understand why it can play other 3D-SBS material correctly

Maybe because this correctly played SBS material doesn't have properties and/or metadata that make Plex state the "Coded Height 1088"? I'm still suspecting this and wonder if (again, combined with certain 3D/AR flags) it makes Plex play 3D-SBS faulty. Even if Plex would suffer from "faulty reading of" or "miscomposing" video-information, all 'n' all there must be something different compared to 3D-SBS files that do play correctly. Maybe a dodgy source?
Or is it indeed anamorphic encoding? I don't even dare to think BD3D2MK3D would steer x264 to do so, but maybe (unawarely set) hardware-acceleration encodes anamorphic.

Anyways, "1088-related" or not, it would be interesting to dive into the properties and headers of a 3D-SBS file that Plex does play properly and see if there's any discrepancy in comparison. If not, maybe a demux and comparison of the elementary video-streams can shine some light.

[zaudio]

Originally Posted by r0lZ

Well, I don't know why the second set appears. As you know, it is never specified. The advantage of HSBS or HTAB over Full-SBS/TAB is that the dimension and aspect ratio of the combined (SBS) image are identical to the dimension and aspect ratio of the two views after having splitted the video and resized the views. Therefore, the resolution MUST be 1920x1080, the PAR 16:9 and the SAR 1:1. But indeed, the two views are anamorphic in the combined picture, since they have to be resized to occupy the whole screen. I suspect therefore that PLEX and ffmpeg know that the video must be resized, and display that phantom second set of options, deduced automatically. But anyway, I can't modify that in BD3D2MK3D, especially if you have already tested with other AR values or without any AR settings at all.

Again, I think that the display problem is due to a bug in Plex (although I don't understand why it can play other 3D-SBS material correctly).

Perhaps you should try to remove the flags telling that the material is encoded in 3D-HSBS ? Maybe it's that flags that confuse Plex ? (Remove --frame-packing 3 in the x264 command and --stereo-mode 0:1 in the MKV options.) You may also need to remove the "SBS" or "3D-lrq" strings from the filename. Without that informations, Plex should be unable to detect that the video is in 3D and should display the two views side by side. Then try to change the display mode to switch to 3D, and see if that makes a difference.

I have set an encode going with what you suggested to see if that helps. I think I did try the stereomode flag removal before... but not also the framepacking.
It does some odd the coded height is larger than the height also... but all this still makes me think something is encoded into the mkv files being produced; the fact that ffmpeg spots it, plex spots it... I do not believe those apps are analyzing the actual video frame... they are reading that from somewhere surely?
For sure, if Plex would not pay attention to the flag, that would help, but the chances of my getting them to do that are likely not good. If the file is marked anamorphic somehow, then they would likely suggest their app is doing the right thing playing at such.

I'll update the end of today when my new encode is completed if that makes a difference.
I watched a non-BD3D2MK3D encoded HSBS movie in 3D last night in plex right through... it played great. That also has 3D and HSBS in the title... so it certainly is not that.
One other thought I have had is to try an older version of mkvmerge for the mux_3d step... maybe all that stuff they recently added to support LG TVs is adding the anamorphic tagging? How old can I go without breaking the process?

[zaudio]

Ok using MediaInfo to output video inforamtion,
this file plays perfectly in plex:

Format                                   : Matroska
Format version                           : Version 4
File size                                : 17.5 GiB
Duration                                 : 1 h 47 min
Overall bit rate mode                    : Variable
Overall bit rate                         : 23.3 Mb/s
Movie name                               : Moana.2016.1080p.3D.BluRay.Half-SBS.x264.DTS-HD.MA.7.1
Encoded date                             : UTC 2017-02-20 18:51:16
Writing application                      : mkvmerge v9.6.0 ('Slave To Your Mind') 64bit
Writing library                          : libebml v1.3.4 + libmatroska v1.4.5
Cover                                    : Yes
Attachments                              : small_cover.jpg / small_cover_land.jpg / cover.jpg / cover_land.jpg

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
Format settings                          : CABAC / 2 Ref Frames
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 2 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 1 h 47 min
Nominal bit rate                         : 15.5 Mb/s
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.312
Title                                    : Moana.2016.1080p.3D.BluRay.Half-SBS.x264.DTS-HD.MA.7.1-FGT
Writing library                          : x264 core 142
Encoding settings                        : cabac=1 / ref=1 / deblock=1:-1:-1 / analyse=0x3:0 / me=hex / subme=5 / psy=0 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=0 / threads=8 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=2 / b_pyramid=0 / b_adapt=1 / b_bias=0 / direct=1 / weightb=0 / open_gop=0 / weightp=0 / keyint=24 / keyint_min=13 / scenecut=40 / intra_refresh=0 / rc=abr / mbtree=0 / bitrate=15500 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00
Default                                  : Yes
Forced                                   : No
Color range                              : Limited
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

and this one is one of mine that does not play properly, and is vertically squashed:

Format                                   : Matroska
Format version                           : Version 4
File size                                : 12.0 GiB
Duration                                 : 1 h 42 min
Overall bit rate mode                    : Variable
Overall bit rate                         : 16.7 Mb/s
Movie name                               : Frozen.2013.3D.1080p.h264.DTS-HDMA.HSBS-ZA / Frozen.2013.3D.1080p.h264.DTS-HDMA.HSBS-ZA
Encoded by                               : ZA
Encoded date                             : UTC 2021-05-15 14:46:28
Writing application                      : mkvmerge v51.0.0 ('I Wish') 32-bit
Writing library                          : libebml v1.4.0 + libmatroska v1.6.2 / x264_x64.exe / x264 0.161.3027 4121277 / (libswscale 5.6.100) / (libavformat 58.33.100) / (lsmash 2.16.1) / built on Oct 26 2020, gcc: 8.2-win32 20190215 / x264 configuration: --chroma-format=all / libx264 configuration: --chroma-format=all / x264 license: GPL version 2 or later / libswscale/libavformat license: LGPL version 2.1 or later
Original source form                     : Blu-ray 3D
Cover                                    : Yes
Attachments                              : cover_land.jpg / small_cover_land.jpg / __ENCODE_3D_MOVIE.avs / __ENCODE_3D.cmd / BD3D2MK3D.log
AUTHOR                                   : BD3D2MK3D 1.22
DATE_ENCODED                             : 2021-05-15
ENCODER_SETTINGS                         : --crf 13 --preset slow --level 5.0 --vbv-bufsize 168750 --vbv-maxrate 168750 --sar 1:1 --range tv --colormatrix bt709 --frame-packing 3

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L5
MultiView_Count                          : 2
MultiView_Layout                         : Side by Side (left eye first)
Format settings                          : CABAC / 5 Ref Frames
Format settings, CABAC                   : Yes
Format settings, Reference frames        : 5 frames
Codec ID                                 : V_MPEG4/ISO/AVC
Duration                                 : 1 h 42 min
Width                                    : 1 920 pixels
Height                                   : 1 080 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 23.976 (24000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Title                                    : 3D Half-SBS (x264 high@L5.0 CRF 13 preset slow)
Writing library                          : x264 core 161 r3027 4121277
Encoding settings                        : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=13.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=168750 / vbv_bufsize=168750 / crf_max=0.0 / nal_hrd=none / filler=0 / frame-packing=3 / ip_ratio=1.40 / aq=1:1.00
Default                                  : Yes
Forced                                   : No
Color range                              : Limited
Matrix coefficients                      : BT.709

[zaudio]

Would it be worth swapping in an older version of MKVMerge? How old could I go without causing a problem?
Meanwhile I await the result of dropping the framepacking and stereo mode, that is encoding as I write this.

[zaudio]

Hey Success! At least with my own encodes. Removing framepacking=3 and stereo-mode:1 from the appropriate setting files for the encode and mux has removed the anamorphic and PAR 2:! from the plex meta data, and I can now play my test mkv file in both kodi and plex!!! yay.
So what can I do for encodes from others that were encoded this way - I guess nothing without reencoding them, which would not be good.
So using your software, I just need to not let it continue to the encode after the demux; and remove those settings each time. Is there a way to removed those using some option in your GUI?

Thanks for the suggestion... at least it worked!

[r0lZ]

Yes, it's the only main difference I have noticed between the first and second MediaInfo reports. However, it is absolutely abnormal to have to remove an important information about the 3D format. That information is required by many hardware or software players to switch automatically to the right 3D-mode when the movie is played. Therefore, that confirms that the bug is in Plex, and not in BD3D2MK3D.

Of course, there is no option to remove those important settings. I could add an option to do it automatically, but I would prefer to let the Plex authors fix the bug. Currently, you can remove manually the two options before launching the encoding. Also, test if removing only the MultiView_Layout from the MKV header is sufficient. If it's the case, you will be able to fix your old encodings with the mkvtoolnix header editor, without having to re-encode or remux the MKV. But if you need to fix also the frame-packing information from the AVC video stream, you will probably have to re-encode the whole file (unless a tool to patch the stream without re-encoding it exists somewhere; I don't know).

Anyway, I suggest to try to contact the Plex authors. If they accept to fix the bug, the problem will be solved. Otherwise, let me know, and I will probably add an option as a workaround.

[von Suppé]

Damn, you guys beat me to it by minutes

Originally Posted by r0lZ

...it is absolutely abnormal to have to remove an important information about the 3D format. That information is required by many hardware or software players to switch automatically to the right 3D-mode when the movie is played.

I am confused now. What I then don't understand is, how come when I view MediaInfo on a BD3D2MK3D created3D mkv, at the x264 encoding settings, I don't find the framepacking=3 argument?

[EDIT] @zaudio:
Does that file with Plex's "Coded height 1088" statement also play back properly after you've removed framepacking=3 and stereo-mode:1 ?

[zaudio]

Originally Posted by von Suppé

Damn, you guys beat me to it by minutes


I am confused now. What I then don't understand is, how come when I view MediaInfo on a BD3D2MK3D created3D mkv, at the x264 encoding settings, I don't find the framepacking=3 argument?

[EDIT] @zaudio:
Does that file with Plex's "Coded height 1088" statement also play back properly after you've removed framepacking=3 and stereo-mode:1 ?

Yes, it plays fine

[zaudio]

Originally Posted by r0lZ

Yes, it's the only main difference I have noticed between the first and second MediaInfo reports. However, it is absolutely abnormal to have to remove an important information about the 3D format. That information is required by many hardware or software players to switch automatically to the right 3D-mode when the movie is played. Therefore, that confirms that the bug is in Plex, and not in BD3D2MK3D.

Of course, there is no option to remove those important settings. I could add an option to do it automatically, but I would prefer to let the Plex authors fix the bug. Currently, you can remove manually the two options before launching the encoding. Also, test if removing only the MultiView_Layout from the MKV header is sufficient. If it's the case, you will be able to fix your old encodings with the mkvtoolnix header editor, without having to re-encode or remux the MKV. But if you need to fix also the frame-packing information from the AVC video stream, you will probably have to re-encode the whole file (unless a tool to patch the stream without re-encoding it exists somewhere; I don't know).

Anyway, I suggest to try to contact the Plex authors. If they accept to fix the bug, the problem will be solved. Otherwise, let me know, and I will probably add an option as a workaround.

I just retried MKVToolNix, and just removing the stero-mode (I think my earlier test was to set it to 0)... now I removed it. That actually worked so long as I removed my file from plex, rescanned, then added it back and rescanned. Refreshing metadata was not enough.
So that is even better, as I can still encode with the framepacking 3; seems not to affect my hardware if it is missing; but it seems it is the stereo mode that causes the plex issue.
I'm sure I tried just removing stereo mode in the mux_3d before... but maybe I did not remove the file file from plex totally first.

[zaudio]

Ok, so I have reported this issue to Plex as a bug; hopefully they might take notice... this time... as I found it was previously reported in 2018 (now I know what to look for), and they did nothing to fix it since.

[r0lZ]

Originally Posted by von Suppé

I am confused now. What I then don't understand is, how come when I view MediaInfo on a BD3D2MK3D created3D mkv, at the x264 encoding settings, I don't find the framepacking=3 argument?

It is present. Look near the end of the line (from the second MediaInfo report above):

Encoding settings : cabac=1 / ref=5 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=8 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=crf / mbtree=1 / crf=13.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=168750 / vbv_bufsize=168750 / crf_max=0.0 / nal_hrd=none / filler=0 / frame-packing=3 / ip_ratio=1.40 / aq=1:1.00

[r0lZ]

Originally Posted by zaudio

Ok, so I have reported this issue to Plex as a bug; hopefully they might take notice... this time... as I found it was previously reported in 2018 (now I know what to look for), and they did nothing to fix it since.

OK, I see. I can add an hidden setting to remove that option as a workaround, but you will have to edit the BD3D2MK3D configuration file manually to enable it.

The frame-packing info in the h264 stream is required by many players, and notably by Youtube and my Samsung TV, but the stereo-mode in the MKV header is ignored by most players. It's a pity, as it is more informative than the frame-packing info, because it describes also the order of the views. But since BD3D2MK3D produces always SBS, TAB or FS 3D with the left view first (the de-facto standard), regardless of the order of the views in the original BD, not specifying the orders of the views with the stereo-mode should not be a big problem. So, you can probably safely remove the stereo-mode flag, but you should keep the frame-packing.

BTW, setting stereo-mode=0 or removing it completely should have the same effect. But with Plex, who knows ?

zaudio, can you post a link to the Plex bug report ? If I can, I will add my voice to the concert of complains ! ;-)

[von Suppé]

Originally Posted by r0lZ

It is present. Look near the end of the line (from the second MediaInfo report above):

I know. I was referring to an old SBS testfile I created with BD3D2MK3D where I coundn't find it.

But it's solved, sigh. Mark this day, as it's a sad one. I am deeply ashamed to confess I had MediaInfo's "View" not set right to be able to see the entire encodings string.
Surely times of penance and atonement are upon me...

[r0lZ]

Originally Posted by von Suppé

Surely times of penance and atonement are upon me...

Then I wish you a good retreat in meditation and prayer !

Note that the framepacking cannot be specified if you encode with x265 or, probably, with the vast majority of the other encoders. It seems that 3D is reserved to h264 and considered as incompatible with other codecs. Perhaps because a 3DBD is always encoded in h264 ?

[von Suppé]

Originally Posted by r0lZ

Note that the framepacking cannot be specified if you encode with x265 or, probably, with the vast majority of the other encoders. It seems that 3D is reserved to h264 and considered as incompatible with other codecs. Perhaps because a 3DBD is always encoded in h264 ?

Actually, I always had some idea that SBS/T&B frames were to be encoded like a 2D frame. So a 3D capable player would recognize it by a header or 3D-flag, and thereby do the splitting, stretching etc.
I must be wrong then. Just curious as to what the "framepacking = ..." argument actually does in terms of encoding?