BD3D2MK3D v1.17: Convert 3D BDs or MKV to 3D SBS, T&B or Frame-sequential MKV

[tomilein]

@r0lZ
Hello and thank's for your reply.

You are right, it's fast and easier way over MkvToolnix.

Works great.

Thank's for statement.

@tebasuna51

Hello and thanks you too for the Hint.

[r0lZ]

v1.1 (July 13, 2017)
- Added Cinavia detection by right-clicking on an audio track in tab 2. See also the Help -> Cinavia Detection menu.
- Tools -> Convert Audio: Added the possibility to specify a positive or negative gain.
- Convert SRT to ASS 3D: Added the percentage of the margin height in the analysis of the guide file (useful for SubtitleEdit)
- Added Help -> BDSup2Sub (Java) Version.
- Fix: The list of MPLS files of the Preview M2TS menu was sometimes wrong for multi-angle movies
- Fix: Some typos.
- Updated the MkvToolnix exes to the latest version (v13.0.0)
- Updated x264 to the latest version (v0.152.2851)
- Updated x265 to the latest version (v2.4+36)
- Updated the Intel Media SDK (libmfxsw32.dll) to the latest version (v7.17.4.21, 2017)
- FRIMSource v1.27 has NOT been updated yet, due to a possible bug. See the BD3D2MK3D and FRIM threads at Doom9 for more info.

This version is mainly an update of the external tools used by BD3D2MK3D, but it contains also some improvements. I have also added the possibility to check the audio streams (one at a time) for Cinavia using CinDe. See the help menu for details.
Download: BD3D2MK3D.7z

[r0lZ]

Please note that the new version of FRIMSource has NOT been included in this release, because it crashes for me. Videofan3d has released it recently (thanks!) but on my machine, it crashes systematically as soon as I try to decode a MVC stream. Videofan3d is unable to reproduce the problem, and therefore he cannot fix the bug (if any). The problem might also be caused by something on my system. More info in the FRIM thread.

So, to help videofan3d, I ask you to try the new FRIMSource (32-bit) and report here or in the FRIM thread if it works for you. If it appears that I'm the only one with that problem, the next release of BD3D2MK3D will contain the new version.

To check the new FRIMSource, do this:

1. Copy the FRIMSource.dll from the toolset directory of BD3D2MK3D elsewhere (or rename it), just to be able to restore it if the new FRIMSource doesn't work for you.
2. Grab the new FRIMSource.dll from the "FRIM version 1.27 (x86)" archive available in the FRIM thread, and put it in the toolset directory. (You don't need to copy all files. FRIMSource.dll is sufficiant. Be sure to use the 32-bit version!)
3. Open BD3D2MK3D and verify if FRIMSource is selected in the Settings -> MVC Decoder menu.
4. Similarly, be sure to select Settings -> MVC Decoder -> Hardware acceleration -> Disabled, especially if you have the Intel CPU compatible with the hardware acceleration.
5. Create a new BD3D2MK3D project.
6. Launch the encoding of the project created by BD3D2MK3D. It will either crash immediately, or work fine. Report the result here.

If you have the right Intel chipset, please test also if FRIMSource works also in hardware accelerated mode. Be sure to install the latest Intel drivers, and select Settings -> MVC Decoder -> Hardware acceleration -> Enabled. Everything else is identical.

Note that you can check FRIMSource with an existing project as well. To use FRIMSource in software mode, you may have to edit the "__ENCODE_3D_MOVIE.avs" file, and verify the following lines:
The LoadPlugin("FRIMSource.dll") must be active (without the "#" character at the beginning of the line), and you can comment out the LoadPlugin("DGMVCDecode.dll"), like this:

LoadPlugin("D:\Tcl\work\BD3D2MK3D\toolset\LoadHelper.dll")
#LoadPlugin("DGMVCDecode.dll")
LoadPlugin("FRIMSource.dll")

Similarly, the FRIMSource command should be active, and the DGMVCSource command MUST be commented out, like this:

# Load the two video streams (128606 frames per stream)
#interleaved = DGMVCSource("00000.track_4113.264", "00000.track_4114.mvc", view = 0, frames = 128606, mode = "auto") # Old syntax for mode: hw = 0
interleaved = FRIMSource("mvc", "00000.track_4113.264", "00000.track_4114.mvc", num_frames = 128606, cache = 2, platform = "sw")

(The arguments of the commands may differ. Do not change them, except the platform argument, as explained below. You should only verify the "#" characters at the beginning of the lines.)

To test the software mode, verify that the last argument of the FRIMSource command is:

platform = "sw"

You can also force the hardware mode with platform = "hw", but that works only if you have a compatible Intel CPU with the right Intel drivers correctly installed.

Experienced users can also download this archive, and encode the test.avs script from the command line or with Simple X264 Launcher, or just preview it in AvsPMod.

When you report here if FRIMSource works or not, please be sure to specify if you have tested it in hardware or software mode.

Thanks in advance for any help!

[tebasuna51]

In __ENCODE_3D_MOVIE.avs:

...
LoadPlugin("D:\Programa\Video\BD3D2MK3D\toolset\LoadHelper.dll")
#LoadPlugin("DGMVCDecode.dll")
LoadPlugin("FRIMSource.dll")

##LoadPlugin("VSFilter.dll")
#LoadPlugin("SupTitle.dll")
# Load the two video streams (158712 frames per stream)
#interleaved = DGMVCSource("00009.track_4113.264", "00009.track_4114.mvc", view = 0, frames = 158712, mode = "sw") # Old syntax for mode: hw = 1
interleaved = FRIMSource("mvc", "00009.track_4113.264", "00009.track_4114.mvc", num_frames = 158712, cache = 2, platform = "sw")
...

Of course can't load ("FRIMSource.dll")

modified to:

LoadPlugin("D:\Programa\Video\BD3D2MK3D\toolset\FRIMSource.dll")

and is working now without crash.

W7 64 bits, Avs+ r2508, MT (both 32 and 64 bits)

[r0lZ]

Thanks for your test, but, normally, you don't need to provide the full path because the LoadHelper.dll (with the full path) is there to add its path to the search path of avisynth. It's the (only) goal of LoadHelper: You can simply specify the path once, and all other LoadPlugin commands can be specified without the full path (as long as the DLLs are in the same directory, of course). You can verify that LoadHelper works if you use DGMVCDecode instead of FRIM.

All versions of BD3D2MK3D since a long time use that technique and it has always worked. On my computer, the LoadPlugin("FRIMSource.dll") works as expected. The old FrimSource.dll works fine without specifying its path, but the new one crashes, with or without its path. And when the DLL is not found, avisynth displays a clear error message in the video, something like "LoadPlugin: unable to load "full\path\to\plugin.dll" ...". It is not shown for me, and it's an evidence that the plugin is found and loaded (or, at least, avisynth tries to load it).

Anyway, for my tests here, I have not used LoadHelper, and I have specified the full path to FRIMSource.dll, with the same result. It crashes. And BTW, it crashes without any error message by avisynth. I can only see the infamous Windows dialog "An avisynth script editor has stopped working. Windows is checking for a solution to the problem. [Cancel]". :-(

[vadlerg]

Hi r0lZ,

At first thank you for this nice piece of work. I really like BD3D2MKV3D.
I’ve recently invested in an LG 3D UHD TV set and started experimenting with 3D encodings. The TV itself goes very easy with 4K Level 5.1 materials - my impression is - it may like HEVC more than H264 if it’s possible. 3D functions are working well so I’ve tried to play 3840 x 2160 Half-OU (3840 x 1080 Top/Bottom) encoded movie and it presents an astonishing crisp 3D picture.
So my question: If I’ve a normal 1920 x 1080 3D Blu-ray and wanting to create a 4k 10bit Half-OU HEVC movie then what is the correct settings in BD3D2MKV3D?
I suppose the settings are forcing profile 5.0 and setting Full-OU for stacking. After creating the .avs script I should edit the stacking line with .BicubicResize(3840, 2160) what is a horizontal resize by 2.
Is this correct?

[r0lZ]

Thanks for your kind words!

Personally, I don't think that you will obtain a better picture by encoding in 4K Half-OU. IMO, it is better to simply encode in 2K Full-OU, without any resize at all. It's why there is no possibility to do it from the GUI (plus the impossibility to generate 3D subtitles for 4K).

If you want to do it anyway, you will have to generate the project in HALF-T&B (because otherwise the aspect ratios will be incorrects). I suppose that you know already how to select the x265 encoder and set its color depth to 10-bit.

When the project has been generated, edit the __ENCODE_3D_MOVIE.avs script to replace the original resizes with your own. It's easy. Look near the end of the script. You will need to change the line highlighted in red below and add another line:

[...]
# Build Top & Bottom stream
StackVertical(VerticalReduceBy2(Left), VerticalReduceBy2(Right))
AssumeFPS("ntsc_film")

# Hardcode subtitles
[...]

The final script should be like this:

[...]
# Build Top & Bottom stream
StackVertical(Left, Right)
LanczosResize(3840, 2160)
AssumeFPS("ntsc_film")

# Hardcode subtitles
[...]

In the example above, I have used the classic lanczos resize method, but you can use another method, and/or specify additional parameters if you wish.

Save the script and encode normally. I don't think that there are other things to change. Try to encode a short clip first, just to be sure, but that should work.

Please note that it is currently not possible to generate 3D subtitles suitable for the UHD (in SBS or T&B) due to limitations in the external tools currently used by BD3D2MK3D, but if you need to encode a movie with subtitles, it should be possible to hardcode them on the video. Let me know if you need to learn how to do it.

Good luck!

[tebasuna51]

And when the DLL is not found, avisynth displays a clear error message in the video, something like "LoadPlugin: unable to load "full\path\to\plugin.dll" ...".

Yes, the message was:

Avisynth error:
Cannot load file 'D:/tmp/1/Musketeers/00009/FRIMSource.dll'. Platform returned code 126:
No se puede encontrar el módulo especificado.

Same path than __ENCODE_3D_MOVIE.avs

Same problem with DGMVCDecode.dll

If you use LoadHelper.dll in previous versions to do the job, and work previously for me, maybe is by my recent change from AviSynth to AviSynth+

EDIT:
Yes, work all fine with AviSynth 2.60, even with the new FRIMSource.dll

[r0lZ]

Ah, OK, so AviSynth+ doesn't handle the path "normally". Good to know. Maybe it's something to tell to the author.

But so, beside the path problem, the new FRIMSource.dll works correctly for you. Damn! What could be wrong on my system?

[tebasuna51]

About Avs+ Plugin Autoloader you can see http://avisynth.nl/index.php/AviSynth%2B

Is easy replace the LoadHelper.dll function but then you need different avs for each system.
I don't think than authors change the Avs+ behaviour.

[r0lZ]

Thanks.

Originally Posted by tebasuna51

I don't think than authors change the Avs+ behaviour.

Is it not supposed to be compatible with the "classic" avisynth? Currently, it is not.

[tebasuna51]

You can follow a recent discussion about compatibility here https://forum.doom9.org/showthread.p...53#post1811053

[vadlerg]

Originally Posted by r0lZ

Personally, I don't think that you will obtain a better picture by encoding in 4K Half-OU. IMO, it is better to simply encode in 2K Full-OU, without any resize at all. It's why there is no possibility to do it from the GUI (plus the impossibility to generate 3D subtitles for 4K).

I don't wish to open a discussion about screen resolution, but that is obvious VGA is superior to CGA or EGA. Or better described 3840 x 1080 for the left and right eye is four times as many pixels as 1920 x 540 am I right?
If it's not straight enough - VerticalReduceBy2(X) throws away every second line so it will be never so nice as keeping all the lines.

https://www.cnet.com/news/4k-tvs-wit...-those-pixels/

So for 4K UHD passive TV owners it would be nice to have the possibility to set the option for 3d 4k 10bit UHD. (for ex. DVDFab has it) I am kindly requesting the feature if you mind.

I will experiment further but your recommended enlarging is not expecting the 4x data in the calculations so I do not know how the automatic settings for the encode will work.

[r0lZ]

Originally Posted by vadlerg

I don't wish to open a discussion about screen resolution, but that is obvious VGA is superior to CGA or EGA.

Right, but here, the ORIGINAL resolution is 1920x1080 per view. If you encode in Full-SBS or Full-T&B, the resolution is untouched, without any resize. It's obviously the best way to preserve the original quality. If you upscale the views to double the height or width, the gain is minimal, since you can only extrapolate new pixels out of the existing ones. Actually, even with a good resize filter, the quality IS somewhat degraded. However, I can agree that a good resize of the source can be (but is not necessarily) better than letting the TV doing it.

Originally Posted by vadlerg

Or better described 3840 x 1080 for the left and right eye is four times as many pixels as 1920 x 540 am I right?

UHD Half-T&B is only two times the number of original pixels, not 4x.

Originally Posted by vadlerg

If it's not straight enough - VerticalReduceBy2(X) throws away every second line so it will be never so nice as keeping all the lines.

Wrong. VerticalReduceBy2 use a much more sophisticated algorithm, similar to bilinear or bicubic. No pixels are thrown away. A resize to shrink an image does NOT need complex resize filters, as no new pixels are created. And it's even more simple to divide the height exactly by 2. In this precise case, you cannot do a better job than with VerticalReduceBy2. I've checked several filters, and the ReduceBy2 filters are extremely good and fast. There is no reason to use a slower filter. And with my suggestion to encode in standard HD but in FULL-OU, the resolution of both images is unchanged, and the VerticalReduceBy2 filter is never used.

Originally Posted by vadlerg

https://www.cnet.com/news/4k-tvs-wit...-those-pixels/

Thanks for the link, but I will read the article tomorrow. I have to go.

Originally Posted by vadlerg

So for 4K UHD passive TV owners it would be nice to have the possibility to set the option for 3d 4k 10bit UHD. (for ex. DVDFab has it) I am kindly requesting the feature if you mind.

Perhaps I'll do it, but it's not in my priority.

Originally Posted by vadlerg

I will experiment further but your recommended enlarging is not expecting the 4x data in the calculations so I do not know how the automatic settings for the encode will work.

That's correct. I forgot to explain that you have to select at least level 5. But I don't know much HEVC encoding, and currently, BD3D2MK3D doesn't handle the x265 levels anyway, even for standard HD Half or Full-SBS/T&B. You have to specify the correct options yourself.

[r0lZ]

I've read the article about the advantages of 4K passive 3D TV over standard 2K active or passive 3D TV, and I agree completely. But the fact is that it doesn't say that the picture is better when the 3D source is in 4K. It's only the resolution of the TV that matters, because the drawback of a passive TV is that it can only use every second line to display the image for a specific eye, and that introduces problems similar to the old crappy interlaced NTSC or PAL videos. With the vertical resolution doubled, the TV can display all lines of the 2K source (but still with blank lines between them, but they are thin enough to be barely visible). Of course, to do this, the source must be encoded in Full-T&B, not in half-T&B. And it's what you get if you select the Full option in the last tab of BD3D2MK3D. There is absolutely no need to enlarge the width of the video to benefit of that advantage of the 4K passive TVs. So, upscaling the video to UHD Half-T&B has exactly the same effect but is not better than Full-T&B, since the height of the picture is equal to the original in both cases.

The only gain of UHD Half-T&B over HD Full-T&B might be in the horizontal resolution, totally independent of the quality of the 3D. As I wrote above, there might be a very little gain because the software (and slow) resize made with avisynth might be better than the resize made in real time by the hardware of the TV, but that's another thing, not related at all to the 3D. And since modern TVs have powerful graphic cards specialized in that kind of treatment, I'm not convinced that their resize is less good than a software resize. It may even be better.

Anyway, if you really want to encode heavy 3D movies with twice as much pixels than in Full-T&B, you know now how to do it. Personally, I'm still not convinced of the interest of implementing that feature in BD3D2MK3D. Of course, I may change my mind if someone can prove that the interest is big, or if there are enough peoples requesting that feature.

[vadlerg]

Thank you for your effort understanding my situation. I have made Full-OU encoding already so I got 1920 x 1600 Top/Bottom picture where is no right chance to tell the TV set which AR the original picture was. So the AR is never correct in this case. eg. looks like 4:3 on 16:9. There is two solution as far as I see. One is setting an AR value for the picture in the stream and hope the TV set understands it. The second and safe one is upscale horizontal by 2. At the and I will have a 3840 x 1600 (or 2160) Full-OU encoding with the right AR and no lines lost from the original encoding. That is my goal.

Originally Posted by r0lZ

Personally, I'm still not convinced of the interest of implementing that feature in BD3D2MK3D. Of course, I may change my mind if someone can prove that the interest is big, or if there are enough peoples requesting that feature.

I don't think the interest is a big one. Home 3D is dying slowly. UHD 4K Blu-ray has no profile definition for UHD 3D so there will be no movie releases in 4k 3D. I got this 2016 TV model nearly at half-price with excellent features. My smallest kid is a real 3D fan and I had the promise since years to have a 3d TV set. So we have it and I am creating the 4k 3D for it. Thanks again.

[r0lZ]

The problem of the aspect ratio is certainly due to the cropping of the black bars of your movie shot in Cinemascope format. It is well known that most 3D TVs MUST have a non-cropped, full 16:9 3D picture, as otherwise they extend it to occupy the whole screen. It's probably due to the badly defined 3D standard, that imposes the 16:9 format. And it's why I have never added a crop option in BD3D2MK3D. It's explained in details in the Help -> Why no crop? menu.

In your example, the HD full-T&B 3D movie MUST have the resolution 1920x2160. Everything else is wrong. Dot.

Note also that BD3D2MK3D sets the correct aspect ratio in the video stream (SAR) and in the MKV container (PAR). But most TVs do not take them into account.

[Majinseed]

first off, thank you so much for this little gem.
after having bought a 3d-capable tv I now need to go trough a lot of disks and your tool is really great!

however, I might have found a bug. There is a checkbox to prevent the encoder logs etc from being added to the output file, but apparently they still are being added.

[Python_61]

I am getting the following error message when BD3D2MK3d v 1.1 attempts to encode a 3D video, on my laptop.

"The type of file 'MKV3D_3d.264' could not be recognized"

My desktop does not give me this error.

Does anyone here know what I need to do to eliminate this error?

Thanks
Python_61

[sfatula]

Ok, confused by subtitles. I did try and read previous discussions, but, could not find my specific case and could have missed it. I have the BD Avatar 3D. On this bluray, is a set of subtitles. One of them (4608) has forced subs included with non forced subs.

In the ideal world, what I want is the forced subs only to be displayed, though, one day I may need all subs. So, in other words, I do want both types. But for now, I do not want to display all subs.

Using KODI as a player, the doc for Kodi says:

"Many movies have subtitles encoded for secondary languages spoken during the film – when these are added to the movie, they are known as forced subtitles and are always visible (despite not being hard encoded). As of Gotham, Kodi recognizes and respects the forced flag for showing subtitles (even if subtitles are turned off by default, the forced flag will trigger them being turned on). "

It also says:
"If you are using an .mkv file, the forced subtitles may be included in the file when originally encoded. If so, Kodi will automatically recognize that they are present and will display them at the appropriate times. If they are not included, or if the header was not properly edited, you will need to use external subtitles."

So, in theory, Kodi will respect the forced flag and only show those if subtitles are disabled. But I have done something wrong? What actually happens is Kodi displays all subtitles, disabled or not. That makes me think they have been merged and encoded into the video by bd3d2mk3d perhaps?

Is there a way to include the subtitles (with both forced and non forced) into the mkv file so that Kodi can only display the forced ones unless subtitles are turned on? Confused. Does the format actually matter for Kodi, vobsub vs bluray sup? Hardcode is set to none on page 5. I selected the top option for 4608, and checked nothing thinking this would simply include the subtitles as is (both forced and unforced)