In addition, should you want to make use of the 3D subtitles on the bluray, re-ripping and converting using BD3D2MK3D also gives you the benefit of being able to keep the original subtitle-depth.
+ Reply to Thread
Results 61 to 87 of 87
I have played the BD I had rebuilt on two Samsung and one LG bluray players. I can confirm it contains 3D video. I am not sure if you had rebuilt differently from what I did. Anyway I will try other methods to make the 3D SBS mkv or maybe just bite the bullet & take the Makemkv path to recreate it. Thanks for all your help. Have a good weekend
The 3D subtitles can be converted for SBS or TAB by BD3D2MK3D, but of course if they are still present in the source BD. (BTW, the SEI messages are not lost when you convert a 3D movie from a BD to a MKV with MakeMKV, because MakeMKV doesn't re-encode the video. The copy is not destructive, and BD3D2MK3D can still find the 3D info.)
I'm hoping someone can help me because I must be doing something wrong. I'm trying to use MakeMKV 1.15.3 and BD3D2MK3D 1.2 to rip some of my 3D blu-rays for playback on an Oculus Rift 2. The problem that I'm running into is that the left and right images are not being reassembled by the player correctly, which I suspect is something in the tags and not so much in the actual video files themselves. I'm using defaults everywhere for half (and tried full) side-by-side. The opening Paramount logo, for example, has the Paramount mountain dead center. However, what I see is the left half of the image touching the right edge of the screen and the right half of the image touching the left edge of the screen so instead of () I see )(, if that makes sense. 2D playback looks fine, opening the file in VLC appears to show the right and left halves at the same time and they look fine as well, so I just don't understand why the 3D player is struggling with it (I've tried two different players, BigscreenVR and GizmoVR. I downloaded a sample SBS file online and that had no problems. Ideas?
I have no experience with your VR players, so I can't help directly, but can you post here an image extracted from the sample SBS you have downloaded, or just post here the link where I can download the sample myself ? Perhaps that will help me.
Can you confirm that the aspect ratio of the movie created by BD3D2MK3D is correct (the image doesn't look stretched in a specific direction) ?
Also, have you checked BD3D2MK3D with several movies, or just one ? It is possible that a movie reacts differently for some reason.
I'm guessing that it's something in the metadata for aspect ratio or the like that is causing the issue because the image "looks" fine, see attached. But what I do notice is that unlike the sample video I downloaded, VLC is not properly stretching this video to take up the whole screen, so for some reason those black borders on the side appear to be messing with how the player reassemble the video into a 3D image. FFPROBE gives the following information but I'm happy to provide whatever will help me get to the bottom of this. This was done as a Full SBS with all defaults selected to my knowledge.
Input #0, matroska,webm, from 'Star Trek Test 3D-SBS 1080p 3D-Full-SBS.mkv': Metadata: title : Star Trek Test AUTHOR : BD3D2MK3D 1.20 creation_time : 2020-12-01T14:27:00.000000Z TITLE-eng : Star Trek Test ENCODER : 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 ENCODER_SETTINGS: --crf 23 --preset medium --sar 1:1 --range tv --colormatrix bt709 --frame-packing 3 DATE_ENCODED : 2020-12-01 ORIGINAL_MEDIA_TYPE: Blu-ray 3D Duration: 00:00:30.07, start: 0.000000, bitrate: 7905 kb/s Chapter #0:0: start 0.000000, end 0.054000 Metadata: title : 1 - 0:00:00 Chapter #0:1: start 0.054000, end 30.072000 Metadata: title : Chapter 01 Stream #0:0: Video: h264 (High), yuv420p(tv, bt709/unknown/unknown, progressive), 3840x1080 [SAR 1:1 DAR 32:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.9 5 tbc (default) Metadata: title : 3D Full-SBS (x264 high CRF 23 preset medium) stereo_mode : left_right Side data: stereo3d: side by side Stream #0:1(eng): Audio: aac (LC), 48000 Hz, 5.1, fltp Metadata: title : English (AC3 converted to AAC 5.1 quality 0.5) Stream #0:2: Attachment: text Metadata: filename : __ENCODE_3D_MOVIE.avs mimetype : text/plain Stream #0:3: Attachment: none Metadata: filename : __ENCODE_3D.cmd mimetype : text/x-msdos-batch Stream #0:4: Attachment: text Metadata: filename : BD3D2MK3D.log mimetype : text/plain
Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc Metadata: stereo_mode : block_lr BPS-eng : 37413487 DURATION-eng : 02:02:22.209875000 NUMBER_OF_FRAMES-eng: 176037 NUMBER_OF_BYTES-eng: 34337205383 SOURCE_ID-eng : 001011 _STATISTICS_WRITING_APP-eng: MakeMKV v1.15.3 win(x64-release) _STATISTICS_WRITING_DATE_UTC-eng: 2020-11-30 02:22:17 _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES SOURCE_ID Side data: stereo3d: frame alternate Stream #0:1(eng): Audio: ac3, 48000 Hz, 5.1(side), fltp, 640 kb/s (default) Metadata: title : Surround 5.1 BPS-eng : 640000 DURATION-eng : 02:02:22.240000000 NUMBER_OF_FRAMES-eng: 229445 NUMBER_OF_BYTES-eng: 587379200 SOURCE_ID-eng : 001100 _STATISTICS_WRITING_APP-eng: MakeMKV v1.15.3 win(x64-release) _STATISTICS_WRITING_DATE_UTC-eng: 2020-11-30 02:22:17 _STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES SOURCE_ID
[Attachment 56026 - Click to enlarge]
Unfortunately, there is no well designed standard for Full-SBS, and the aspect ratio necessary for a specific player may be different than for another one. It's why, in BD3D2MK3D, there are two options to change the aspect ratio for full-SBS : see the menu Settings -> Full-SBS/T&B Aspect Ratio. The aspect ratio is saved in two different locations, hence the two options, but most players take only one of them into account. Change the two options and try again with a short clip.
For Half-SBS, the standard is well defined, and should be OK for all players, including for VR. But it might be necessary to configure the player for the correct Half/Full mode.
Thanks for those hints. I tried switching both the full/half setting as well as changing the AR setting but that didn't seem to make any difference, the output always looks the same in both players I try.
Does this sample help?
Well, the sample is encoded in HSBS with BD3D2MK3D, and it is IMO perfect. Full screen as it should (with only black borders above and below the picture due to the original Cinemascope format). A good 3D player should display it correctly. I'm not sure why the VR players display it wrongly. Perhaps there is a setting to change somewhere, but the two AR in the sample are correct, since there is no other choice for HSBS.
BTW, please do not test 3D material with VLC. Use a real 3D player like PotPlayer. Or extract the source image directly from the video clip, and do not post a screen capture of the player's window. In your capture above, the vertical black borders have been added at playback time by PotPlayer itself, to fill the empty space between the image and the border of the window. It's obviously not a problem in the video.
Here is a capture of an image from your sample made with PotPlayer. As you can see, there is no useless black border.
[Attachment 56028 - Click to enlarge]
When the correct 3D options are used, the AR is correct, like with this anaglyph rendering, again with PotPlayer :
[Attachment 56029 - Click to enlarge]
Sorry, but I can't help much more. Try to contact the authors of the VR players to get some help. And if you find the issue, please post the explanation here. I'm curious to know what's the source of the problem, and perhaps I will modify slightly BD3D2MK3D if it is sufficient to solve the problem.
Thank you for your help r0lZ. I had meant to download one of those recommended players but the kids had used up the internet cap so I was trying to avoid overage until this month started new, but I just grabbed PotPlayer for future testing. I agree with you that everything appears correct so I'll try to reach out to the VR player developers to see why both of their programs fail in the same way on this material but work correctly on something else I downloaded. I just figured I must have one stupid thing set somewhere that's causing an issue. If I find a resolution, I will let you all know. Or if you know of a good 3D player for VR headsets I could try, I'm all ears (and eyes). Thanks.
Sadly, I have no experience with VR. I bought a cheap headset, but not good enough to watch a movie, and I gave it to a kid. Currently, I prefer my Samsung TV.
Good luck !
Did you perhaps alter something in the "Clone Subtitle positions" tool?
I recently noticed that, when only the "Y-coordinates" are checked in the tool's configuration window, none of the vertical coordinates of the guidefile are copied to the output xml.
It does not matter whether "Process only the subtitles in the upper half part" is checked or not.
Can you have a look at it please?
Hum, strange. Yes, I will have a look. Thanks.
[EDIT] Damn ! Yes, it's a stupid bug !
I will release a new version soon...
Wow, that was quick! Thanks for the fix, r0lZ
I'm having trouble getting my finger on an old "tsMuxer 3D" issue. I can't remember exactly. I think you'll know, though.
It had something to do with tsMuxer not showing the right 3D-plane for certain SUPs (of certain discs?). Also the order of how the SUPs were displayed (or set!) in tsMuxer's tracklist was to be significant for a proper 3D mux.
Ring a bell? I also would not know if that issue is solved with the newer tsMuxer builds. At the time I didn't make notes and I plainly lost track
Yes, I remember perfectly that problem. In the old tsMuxeR, the (so called) 3D-Planes were assigned sequentially to the subtitles streams. Most of the times it's correct, but not always. The closed-source versions of tsMuxeR ignore the field in the MPLS file containing the real assignments, and it's the cause of the bug. In some cases, this has disastrous results (especially when the M2TS contains hidden "phantom subtitle streams" as I call them, not referenced in the MPLS). As you know probably, BD3D2MK3D shows you the correct assignments in its first tab, and you can therefore use it to correctly remux a 3DBD with any version of tsMuxeR. But don't worry. When the source code of tsMuxeR has been released officially, its development has continued, and I have noticed that bug (as well as another one) to the programmers. Although the current version is still somewhat unstable, that two bugs have been fixed. The version of tsMuxeR currently distributed with BD3D2MK3D works perfectly fine for the demux process and the 3D-Planes assignments. However, I don't use it to remux, and therefore I don't know if remuxing a 3DBD is safe with that version or with the latest one.
Thanks for your instant-acces knowledge, r0lz.
I am also trying to figure out what consequences there are by altering the order of SUPs in the track-window before remuxing.
Would you know a specific disc title that has this bug?
As long as each 3D-plane is associated with the right subtitle stream and you do a movie-only backup, you can freely change the order of the streams. The problems occurs if you don't know to what stream a 3D-Plane is associated, or if the information is wrong (like sometimes with the old versions of tsMuxeR).
I call "phantom stream" a subtitle, audio or even video stream that is not referenced in a specific MPLS, but is present in the M2TS. Usually, that streams are referenced in other MPLS with the same movie, but with unusual characteristics (such as a secondary video stream displayed in PIP mode within the main video, a director comment available only when the movie is played in 2D, or even specific subtitles designed for the 2D version only). Imagine that there is, say, a phantom subtitle stream in the second position and the third stream is a regular 3D stream with a 3D-Plane. The total number of 3D-Planes is 2, since there is no need for a 3D-Plane for the phantom stream. But the old tsMuxeR will display a wrong info, with the second 3D-Plane assigned to the second stream (phantom), and that's totally useless. And, more importantly, the third stream (the second real stream in the MPLS) will have no 3D-Plane at all. If you don't pay attention, you will remux the third stream in 2D. That's what I call a catastrophic situation. Also, since the order of the streams is not always respected, even if all streams have a 3D-Plane, you may end up with the wrong 3D-Plane for a specific language. Although the depths of most subtitles will be corrects, some subtitles larger than their equivalent from the correct stream may have a wrong depth and enter into the foremost objects. There is also a problem with forced subtitles that may be completely absent in the original stream, and therefore will have no valid depth value in the 3D-Plane, and be presented on the surface of the screen, in 2D.
So, anyway, it is important to assign the correct 3D-Plane to the correct stream, and the new tsMuxeR should do it correctly (although, I repeat, I have no experience with the remux operation).
Unfortunately, I don't remember what BD has phantom streams or an unusual 3D-Planes order. Sorry. But don't worry. If you have never noticed major problems with your 3D subtitles, that means probably that you have been lucky, or that the wrong assignment was not so catastrophic !
Thanks for your explanation. Crystal clear.
tsMuxeR, here at Doom9. So, if you use the latest version, be careful. I don't know for sure if the version distributed with BD3D2MK3D has similar problems, but I don't think so.
I would also like to reassure the BD3D2MK3D users. The latest posts in this thread are not about BD3D2MK3D, which does not use tsMuxeR to remux a 3DBD. I can guarantee that the version distributed with BD3D2MK3D does correctly what it should do (without of course being able to exclude that there are still unknown small bugs).
I do movie-only remuxing to 3D iso, adding my home-brew subtitles. Therefor I use a tool that BD3D2MK3D is also using, but with other versions and other usage.
Last edited by Ennio; 10th Dec 2020 at 06:08.
thankyou so much for support.
I'm currentrly trying to use BD3D2MK3D in order to convert a 3d iso movie I've got on my computer to SBS. I have no joy.
The demuxing process runs smoothly, but when I try to run __ENCODE_3D_LAUNCHER on my project dir the process starts and stay put, without progress. Checking trough process monitor shows that there's no CPU usage by the encoder process.
I've tried to change --frames 205979 to --frames 1800 in the avisynth script file, to have faster a viewable result, buy no joy.
The computer is a Windows10 based, CPU is a AMD Athlon II X4 620E, got 16GB ram on board. I've installed AviSynth+ version 3.6.1
Well, strange. It's the first this problem is reported.
Can you please send me the BD3D2MK3D.log file (in the project folder) ? (See my email address at the bottom of my home page. Link in my signature.)
Try also to launch directly __ENCODE_3D.cmd (without passing by the launcher). That may help.
Also, perhaps x264 is blocked by your antivirus. If the command prompt window stays open but there in no CPU activity, that may be the case. Examine the log of your antivirus and/or try to disable it.
Finally, can you tell me if it's your first attempt to encode a movie ? The problem might be caused by a corrupted ISO. Try with another one.
BD3D2MK3D v1.22 is available.
It adds a new option available when you encode in Half-Top/Bottom to use the even and odd lines of the source material instead of merging them with a resize. If you have a LG passive 3D TV that can display the full 1080p resolution, you will benefit from this option, as there is no need to resize the image, and all details are retained. But please note that it is suitable only if your TV has the correct polarity: the even lines must correspond to the left eye and the odd lines to the right eye. In all other polarity configuration (such as "checkered") or if you have an active TV, this option is not recommended. (Thanks to Muf for suggesting this option.)
v1.22 (January 2, 2021)
- Added an option to use the even/odd lines for the left and right views to encode in Half-T&B mode for a LG 3DTV, while retaining the full 1080p resolution. (Thx Muf!)
- Updated x265 to the latest version (v3.4+35)