This is the official BD3D2MK3D support thread at VideoHelp.
BD3D2MK3D is a tool to convert a 3D blu-ray (or a 3D AVC+MVC MKV created with MakeMKV) to Half or Full side-by-side (SBS), top-and-bottom (TAB) or frame-sequential (FS) 3D MKV.
BD3D2MK3D home (hosted at VideoHelp, thanks Baldrik !)
The current version of BD3D2MK3D is v1.33.
The latest version of BD3D2MK3D cal always be downloaded here: BD3D2MK3D.7z
The full modification history can be viewed or downloaded here: Version history
Please post all feature requests, bug reports or general comments about BD3D2MK3D in this thread, or at the BD3D2MK3D thread at Doom9. I will try to reply as soon as possible.
An old thread about BD3D2MK3D up to v1.17 can still be viewed here at Doom9. It contains a lot of useful information but is now closed. A search for BD3D2MK3D here or at Doom9 can also be useful.
Happy 3D viewing !
+ Reply to Thread
Results 1 to 30 of 464
BD3D2MK3D v1.18 implemented several fixes and little improvements:
v1.18 (December 24, 2019)
- Added Subtitle Tools -> Crop Transparent XML/PNG Background to remove the useless invisible parts of a XML/PNG subtitle stream. This may be necessary fo convert full-width subtitles to 3D.
- The --alpha-crop 0 argument has been added to all BDSup2Sub command lines so that it will not crop the transparent background of the XML/PNG streams any more, except when necessary.
- The Verify 3D-planes Compatibility subtitle tool has been improved to include a global score indicating roughly the compatibility of each 3D-Plane with the analysed subtitle stream.
- The presence of all required files in the toolset folder is now verified at startup, as some antivirus software may quarantine some exe files due to false positive.
- Fix: eac3to crash when an AC3+ audio stream is converted to stereo.
- Workaround for a possible bug when checking for M$ .NET v4 on some systems.
- Little bug fixed: The _POSTPROCESS_2D.cmd file was not executed after a 2D encoding due to a typo in the filename.
- Updated x264 to the latest version (v0.159.2991)
- Updated mkvtoolnix to the latest version (v41.0.0 "Samarra")
- Updated the Intel library libmfxsw32.dll to version 220.127.116.11
- DGMVCDecode is now withdrawn and has been removed. It was useless anyway, and baby is happy.
v1.19 (January 1, 2020)
- The home of BD3D2MK3D has changed and is now http://download.videohelp.com/r0lZ/BD3D2AVS/index.html
- The support thread at Doom9 is now https://forum.doom9.org/showthread.php?t=177317
- There is a new support thread at VideoHelp here: https://forum.videohelp.com/threads/395498-BD3D2MK3D-Convert-3D-BDs-or-MKV-to-3D-SBS-T...Support-thread
Thank you very nuch for this awesome application. I'm not an encoder expert, so I'm currently trying to understand how it works.
There is one parameter that is not clear for me, at least which value I have to setup: the CRF.
What I would like to understand if is it possible to approximately calculate the size of the final encoded SBS file. For example, I have one BD (40 GB size). I setup CRF=15 and I got a final file of 18 GB. So it's about 55% compression. I would like to compresso it at least 40/45%.
Obviously I can reduce the CRF value, but is there a way to calculate the right value before encoding?
No. By definition, the CRF mode compresses differently according to the content of the movie and the quality of the images. For example, a clean computer graphics movie (like a Pixar film) will be compressed very much (because the frames of a same shot are very similar to each other), but an old film with much noise will be less compressed (because the noise makes it difficult to locate similar parts in the images). It's the interest of the CRF mode: it produces always s similar quality for the same CRF value, regardless of the difficulty to compress the movie. But that means that the final file size is difficult to predict. I have read somewhere that lowering the CRF value by 3 has the effect of multiplying the file size of the video stream approximately by 2. But you need to encode the movie at least once to apply that formula, and I don't think that it is always correct. Also, a slower preset compresses better that the fast ones, so the CRF value is not the only thing to take into account. (The CQ mode is similar to CRF, but without the ability, that CRF has, to compress more when the human eye cannot see the details, such as in a fast moving action scene. It is therefore not recommended to use CQ.)
In the other hand, the ABR and 2-pass modes can be used to obtain a precise file size, but the quality will greatly differ for different films, even if they have the same length. It's why you should NEVER trust the numerous advices found on the internet claiming that a specific bitrate is necessary to encode a movie correctly. That doesn't take into account the fact that a movie is not another one. Only the CRF and CQ modes are smart enough to offer a constant quality, BECAUSE they DO NOT use the same bitrate for all movies. Note also that ABR is forced to obey the bitrate specified on the command line, but it doesn't know in advance what parts of the movie will be difficult or easy to compress, and it will therefore encode everything the same way. That means that some easy parts will have an unnecessary high bitrate, and the difficult parts will exhibit artefacts because the bitrate is not sufficient for the difficulty. 2-pass is supposed to solve that problem, as the first pass is used mainly to analyse the difficulty of the encoding, and the second pass encodes according to the stats produced during the first pass. Although much better, the result is not perfect, as the first pass is a relatively fast analysis, that doesn't take everything into account. Constraining the bitrate is always a disadvantage, even if it is possible to minimize it. Therefore, the 2-pass mode is always slightly less good than CRF for the same global bitrate, and ABR is certainly the less good option. Of course, another drawback of 2-pass is that the encoding takes much longer.
Also, I really think that the bitrate of most commercial BDs is selected specifically so that the movie doesn't fit on a single-layer BD. It's probably some kind of protection and certainly a selling point. x264 and x265 are very good encoders, able to offer almost the same quality than a commercial BD for a much smaller file size.
So, my conclusion is that you should always use the CRF mode, unless you really need a specific bitrate or final file size, for example to burn the MKV on a DVD with the best quality possible. In that case only, 2-pass with file-size control is recommended. And trust your eyes instead of the misleading advices about the bitrate. It is perfectly possible to encode a clean movie with a very low bitrate. Just find the good CRF value for you, and use it for all movies.
Thank you for the very good detailed answer. So I'll go to CRF for sure, the space occupied by final SBS mkv is not a problem for me since I'll keep my file in my NAS with enough space. So I'll try with CRF 12 and let's see.
Thanks for the continued updates to this most excellent app!Steve
I'm trying to rip my (UK?) 3D Blu-ray of Avatar for watching in VR, using MakeMKV and BD3D2MK3D. I've ripped a bunch of other films and they all went fine.
Problem is with Avatar it has some automatic subtitles for the Na'vi speak, so there's 2 English sub tracks, but every time I render the movie with BD3D2MK3D these subtitles are getting squashed together, so every single line in the movie gets a subtitle. Obviously what I want is the original experience with just subs on the Na'vi speak.
The actual MKV produced by MakeMKV is perfect, it has both of the English subs. When I load it into BD3D2MK3D it shows 2 English subs, but I just can't get them to stay separate when BD3D2MK3D renders the file. I always end up with a single Eng sub track, or with none.
I've tried about 10 times now (2+ hrs each attempt) with every variety of the below settings I can think of. I've tried separating the 3D planes, just selecting one of the Eng sub tracks, selecting both, selecting everything etc.
Thanks in advance for any help. Related pics-
Last edited by fish998; 20th Mar 2020 at 11:21.
I don't remember right now how the subtitles of Avatar are authored.
Unfortunately, in an original BD, there are two possibilities to author the forced subtitles (the Navi subs in Avatar) :
The complete English subs and the forced subs (Navi) can be in their own streams. This means that there are at least two physical streams with the same language code. It's the most frequent case, and the easier to understand. You should only need to determine precisely in what stream the subtitle you need are authored, and select that stream in MakeMKV. (With this method, the MakeMKV "(forced only)" sub-streams are useless and can be ignored.) Usually, the first stream available in a specific language contains the complete subs, and the second the forced subs only, but in rare circumstances, that can be the opposite, or the second stream can contain specific subtitles like the subtitles for hearing impaired, or the director comments. The only way to be sure is to play the original BD with a good player, that doesn't swap the subtitle streams. Of course, it does not hurt to select all streams in the languages you are interested in, just to be sure to rip all potentially useful streams, but you will have to determine what stream contains what later, with a player and BD3D2MK3D.
The second authoring method is when the forced (Navi) subs are mixed in the same stream, with all English subs, and simply individually marked as forced with the "forced" flag. MakeMKV offers always an option to extract the forced subtitles "sub-stream" only. as if it was a real independent stream. You should select it (and if you are sure that you don't need the other subs, leave the other subtitle streams unticked, to have less confusing streams in the final MKV). See the example I've uploaded (the Russian forced sub only is selected).
Unfortunately, MakeMKV (like BD3D2MK3D) has no way to know what method is used with a particular BD without a very long processing (involving to demux the subtitle streams), and therefore you cannot guess what method to use when you are in front of the MakeMKV GUI. I suggest to tick all streams, including the "(forced only)", in the language you want to include in the final SBS. You should be able to determine later what stream to use with a good player. Unfortunately, a MKV file cannot contain subtitle streams with some subtitles marked as forced and others not, so the only method to leave the two possibilities to the user is to include the two streams.
When you have generated the AVC MKV with MakeMKV, play it with a good player. I suggest to use PotPlayer, but any player that doesn't change the order of the streams should be OK. (You can even start the playback of the MKV with the associated player with the Preview button in tab 1 of BD3D2MK3D.) In the player, select each subtitle stream one at a time and play various segments of the movie until you are sure of the content of each stream. In BD3D2MK3D, select the stream(s) you want to add in the final SBS or T&B MKV in tab 2 (and, if you want so, the stream to hardcode over the video in the last tab).
So, there is nothing really difficult, but I agree that the lack of preview in MakeMKV and the two different authoring methods of the forced subtitles can be confusing. Anyway, the secret is to determine the content of each subtitle stream, including the forced-only sub-streams, with a good player, and note their order. BD3D2MK3D shows always the streams in the order of the MPLS, as all good players and ripping software should do. Most of the confusion comes from the fact that many players change the order of the streams without a good reason.
Right, had a look at the log and there's definitely an error with the default Eng subtitle track (track 8). I've attached the log but the relevant bit is-
Loading E:/Avatar 3D/MKV3D/MKV3D.track_8.Eng.sup
Detected 83 forced captions.
child killed: unknown signal
*** BDSup2Sub close error: child killed: unknown signal
*** Found 102 captions, including 83 forced captions.
ERROR: Can't convert "MKV3D.track_8.Eng.sup" to XML/PNG format!
Btw I realize now that the 2 Eng Subs aren't getting smushed together, just the failed track 8 is missing. Track 7 has subs for all dialogue including the Navi stuff.
Last edited by fish998; 20th Mar 2020 at 15:28.
OK, I'm not very surprised. I wrote this in my previous post:
Normally, a 3D movie is stored in the 3DBD as two different M2TS, the main and dependent M2TS, merged together as the SSIF. The first one contains everything necessary to play the movie in 2D: the main 2D video view, the audio and the subtitle tracks. The dependent M2TS contains the additional material to play the movie in 3D: the AVC video stream (the dependent 3D view), and the 3D-Planes (aka offset-sequences) to display the subtitles properly in 3D. But the dependent M2TS must NOT contains the subtitle streams, only the 3D depth values.
Avatar and a couple of other movies do not obey this rule. The dependent M2TS contains also some subtitle streams, with single full-screen subtitles with warnings like "Put your 3D-Glasses now!". I don't know why they did that, but the fact is that for each regular subtitle track in the main M2TS, an obscure track with the same UID exists in the dependent M2TS. If the player or demuxer (or in this case MakeMKV) uses the combined SSIF file instead of the two M2TS to do its job, it cannot distinguish the parts of the subtitle stream pertaining to the regular 2D M2TS from the one from the dependent M2TS, since they share the same UID. These two mixed streams confuse the player/demuxer, and it may crash, issue a lot of error messages or just do what it thinks is correct, but with a bad result.
It's why I have abandoned eac3to to demux the 3DBD, and opted for tsMuxeR, that can demux only the "good" subtitle streams, without errors. I don't know how MakeMKV works, but it may be the culprit. (However, I'm not sure, as it seems to be capable of demuxing correctly the complete English subs.)
I can only suggest to use another method to decrypt your 3DBD in this precise case. If you can manage to create a decrypted ISO, you can normally safely use BD3D2MK3D directly to process it.
Sorry, but I can't help much more.
I used the following two for mats 1> "--profile high --ref 5 --deblock 1:-3:-3" and "profile=high:ref=5:deblock=-3,-3" but in both it was unable to open 3DMKV.h264
can anyone show me an example how to write those commands in additional option?
Is it a warning in the command prompt window when you begin the encoding ?
Also, you can see the final command in __ENCODE_3D.cmd. Please verify that there is no mutually exclusive arguments. In particular, the preset and level specified in the GUI are passed automatically, and they may not be compatible with your arguments.
Anyway, you should not need the quotes in the arguments. They are passed to the command as you have typed them, and with the quotes, the whole content will be considered as a single argument. Similarly, afaik, the = are not supported by x264/x265.
Honestly, I'm not sure that specifying arguments yourself makes much sense. Currently, the Presets are very well designed, and usually, the commands lines found on the internet give less good results than the equivalent preset. So, imo, unless you really need to specify some arguments, you should avoid them.
If you can understand the problem, and if it comes from the way BD3D2MK3D handles the command and the additional arguments, please let me know. I may have to fix a bug...
I did a short test, with CRF 18, preset slow, tune none, force level 4.1 and 8-bit of colour, plus your arguments:
--profile high --ref 5 --deblock 1:-3:-3
The result is OK, and plays correctly with 10 different software players, and with my (capricious) Samsung 3D TV.
What player or hardware do you use to play the final MKV file ?
I can only repeat that most of the times, the recommendations on the internet are useless at best, and often completely wrong.
Anyway, if you insist to use your parameters, try them. As I wrote above, they work. Unless you have a conflict with the other parameters, and in that case, the warning should explain what's wrong. Without more info, I can't help you.
edit: BTW which one of the following should i select? left or right?
Last edited by WiNT3R; 28th Mar 2020 at 23:46.
MakeMKV is supposed to add the correct left/right information in the AVC+MVC MKV file it generates, and BD3D2MK3D should just need to retrieve it. But I have had to add the possibility to change it manually because at the beginning, that information was not included in the MKV created by MakeMKV, and later, when they have added the information, a bug was present that made the left/right info often wrong. I suppose that currently, the information is correctly retrieved in the original BD3D and written without bug in the MKV, but honestly, I'm not sure, so the possibility to overwrite the order detected by BD3D2MK3D is still available.
Anyway, unless you see a warning highlighted in red in the first tab, explaining that the information has not been found or that you are using an old version of MakeMKV, known to have the bug, you should not modify the left/right setting yourself. It is hopefully correct. Note also that the vast majority (perhaps 95%) of the movies are encoded in the "classic order": left-view in the main AVC stream (and of course the right view in the dependent MVC stream), so if you are not sure, try that first. But if BD3D2MK3D has selected automatically the other option (Right view in AVC stream), then you should normally leave it as it is. And if the views are inverted in the final SBS, please report the bug to the authors of MakeMKV. BD3D2MK3D cannot guess that information if it is not properly included in the source MKV.
You can also click the [?] button to see more info about that option and how to use it.
This may have always been present or recently included and I missed it. Could you perhaps add a "3d test preview" option? Something where it will only encode say the first 5 or 10 mins of a film? This way you can check the file much sooner (in my case SBS) and make sure everything is set as it should be before wasting a good number of hours only to find you needed to adjust some other options before encoding.
Yes, this has already been requested several times. Unfortunately, I can only limit the encoding to a certain number of frames, but it is not possible to encode a specific segment somewhere after the beginning of the movie, because the MVC decoding is sequential. It cannot skip some frames and continue later. So, the short answer is : it's not implemented because it's not possible.
But you can easily limit the encoding yourself to a certain number of frames. Just create the project normally, then do a backup of the file __ENCODE_3D.cmd, and edit the original to change the frame number in the x264 or x265 command, like in this example :
"D:\BD3D2MK3D\toolset\x264_x64.exe" --output-depth 8 ^ --crf 18 --preset slow --level 4.1 --vbv-bufsize 78125 --vbv-maxrate 62500 ^ --sar 1:1 --range tv --colormatrix bt709 ^ --frame-packing 3 --qpfile chapters_3D.qpfile --frames 7200 --fps 24000/1001
Launch the encoding normally. The final MKV will be created with the complete audio and subtitle tracks, but with only the first 5 minutes of the video. Watch the result, and if it's OK, just restore the backup of __ENCODE_3D.cmd and relaunch the encoding.
You can also launch the original project, and type Control-C during the encoding, say when the encoding reaches frame 7200. When prompted if you want to abort the batch job, reply no, so that the muxing will be done. This is the simplest way to do it, but it is less precise than the edit method.
I hope this is sufficient for you.
Your additional parameters are incorrect.
And, BTW, it doesn't make much sense to encode with preset ultrafast (the most basic preset, giving very big file sizes) and trying to fine-tune it with additional arguments. The ultrafast preset should be used only for testing purposes, when the encoding duration is more important than the video quality.
I can only repeat what I wrote above:
First of all thanks for keeping the tool up-to-date. Appreciated!
Second, I have maybe a stupid question. Since I'm no expert whatsoever encoding blurays to .mkv with h264 I would like to ask you why there's a huge difference in size and bitrate between encodings. Let's say I have an animated Bluray that I convert with these simple parameters: Audio convert to AC3 5.1, Half-Top & Bottom, X264 CRF, Q18, Slow, Force Level 4.1 (for compatibility with embedded 3DTV player). Now, the size and bitrate is good, around 7GB and Overall 9.900kb/s and I can't see any blocking with fogs, fadeouts and crowded scenes. Looking good.
Then I convert a live action Bluray with lots of fog, fadeouts, sparkles, FX, crowded scenes... you get my drift. After using the same simple parameters I get around 5GB of size and around 6.700kb/s. Further inspection shows blocking and some (faint) color banding. I compared the same Bluray with a scene release and the scene release doesn't have those artifacts, and the video stream is HUGE in comparison. Around 13GB with 10.500kb/s.
I understand that there's no apparent benefits on tinkering with settings while using x264 compared to, for example, x265 as it is well matured and the codec will do all the work properly considering frame-by-frame analysis, and that my solution would be using a lower CRF (like 17 or 16), but I would like to understand: Why does it encode so differently from one Bluray to the other? Why does the quality and size diminish?
How can I tune the encoding and ensure enough kb/s so the video is almost flawless? Like the scene release.
Any help will be greatly appreciated.
Last edited by slit; 18th May 2020 at 09:27.
Thanks for the thanks.
Have you read my reply here ? It doesn't answer exactly your question, but it's a good introduction on how CRF works. I wrote, among other things, that normally, encoding in CRF ensures a constant quality, regardless of the "difficulty" to encode the movie (such as grainy images). So what you wrote surprises me. It's the first time I see someone obtaining different qualities with the same CRF value.
I think that the size of the video can be explained by the nature of the image. You wrote that there are scenes with fog, for example. Fog reduces the contrast, making the image smoother and easier to encode. Also, CRF is smart enough to compress more the objects moving rapidly (or the whole scene when the camera moves rapidly), because the eye cannot see the defects when the image changes rapidly. That means that if you analyse a fast moving scene frame by frame, you will probably see some defects not present in the quiet scenes. IMO, it's a quality. A film is not made to be stopped and analysed. It must be perceived in its continuity. Anyway, if you don't like that feature of CRF, use CQ. It's almost the same encoding, but without that kind of optimisation. Of course, for the same overall bitrate, the quality of the quite scenes will be slightly less good for the benefit of the fast moving scenes.
The problem of the banding is well known. To compress the video efficiently, the encoder begins by removing the grain and the noise from the image. Most of the time, that's OK, but in certain scenes (usually in smooth shades of blue, like in underwater scenes) this has the effect of creating more or less visible banding artifacts, because the natural dithering has vanished, in favour of pure coloured stripes. There are two solutions for that problem, but none is totally satisfactory. You can either increase the overall bandwidth (or, for CRF, reduce the CRF value). The encoder will have to remove less noise. This will of course generate a larger file, but with less defects. Or you can increase the colour depth. When there are more colors available to the encoder, the bands of colors are less large and contrasted, and therefore less visible. Personally, I don't like that solution much, as 10 bit of colors (or 12 with x265) increases also the file size, and makes the final MKV incompatible with many hardware players. Also, when the original BD is encoded in 8-bit, it is almost useless to force a greater colour depth in the MKV, as the encoder will try to stick as closely as possible to the original colors, and the additional colours will only be used to a limited extent, which greatly reduces the profit.
Unfortunately, there is no magical solution. You cannot expect the same quality with a 5 GB MKV than with the original BD, usually weighing at least 30 GB. But as I write usually, trust your eyes. Analysing closely the image, perhaps with software tools that compare the image with the original is interesting for the developers, but not really useful to the users. Watch the movie normally, and if you can perceive annoying flaws, decrease the CRF value.
If you need a more technical answer to your interesting question, please post it in a forum about x264 encoding. I'm not an x264 expert, and perhaps they will be able to help you better than me. And if it's the case, please post a link here to direct the other users to the solution. Thanks in advance !
Thanks for the thanks for the thanks
I will try the 10 bit solution for banding issues, as I also have a laptop to play the files. About CRF, I understand what you're saying, and I appreciate your explanation. Yes I did read your other post and now I have a better knowledge, but what I'm trying to do is to set some settings in BD3D2MK3D that will greatly enhance the bitrate. You say specificly "increase the overall bandwidth", how can I do such thing in your tool? I don't really care about space if it's around halved (let's say max 20GB) from the original Bluray. I want to force more size for better (ie closer to the original) picture quality. The only thing I can think of is to lower the CRF. Is this the only method or are there any extra settings that I can tweak in your tool? Like the above 10GB scene releases use?
Well, you can of course encode in 2-pass, but for the same bitrate, CRF is better, because the bitrate is not constrained. The advantage of 2-pass is ONLY that you can predict the final size. Something not really important if size doesn't matter.
Otherwise, you can indeed decrease the CRF. I have read somewhere that decreasing it by 3 doubles the size of the h264 stream, but I have never tried to verify that. So, if you use CRF 12, you should obtain a file size around 20 GB for your second movie. But as always with CRF, you may obtain a totally different file size with other movies. Anyway, the file size is certainly a good indicator of the quality.
You can also try to change the preset. A slower preset computes longer and therefore compresses better for the same quality (although it's not always the case). But a lower preset creates a movie more difficult to decode, and the playback may be choppy on slow hardware players. I use the slow preset, because my TV accepts it without problem, but slower presets are less good for my TV.
r0lZ, love your tool! I've always felt that 3D tech was never utilized fully; 3D movies are great, but the tech has so many other uses. But I digress.
I have managed to get every, non-anaglyph, 3D movie working beautifully through Plex on my TV except one. Prometheus is pissing me off. I understand that it is encoded backwards (right eye first), but when I play the finished version I get a file that my TV thinks is 3D but is 2D. If I swap the eyes (__ENCODE_3D_MOVIE, SelectEven/Odd) I get a file that is 3D, but I have to wear my glasses backwards.
With any luck, I'm missing something obvious that you'll notice immediately. I've attached the log and encode files that result in 3D but not 3D video.
Thanks in advance.