Guide to convert BD 3D to 3D Left+Right Stereoscopic and Anaglyph

[Nico8583]

I don't think it's so easy :-/ (I believe I've read something about it) and IMHO there is no interest to create a single M2TS with copy instead of demux it, no ?

[r0lZ]

Hi Frank!

There are several drawbacks if we decide to use the M2TS without demuxing.

First, afaik, as noted by Nico, there is no way to process a MPLS file, and therefore no way to process the titles made of several parts. OK, there are probably some methods that could work, like the one suggested by Neuron2, but the point is to save some time and disc space, so joining the files is not a good idea imo. It should be possible to process each M2TS file independently, with several FRIMSource commands, but the previous versions of BD3D2MK3D used that trick with ssifSource, and we know that it was very difficult to start the encoding due to timeout problems when avisynth initializes all ssifSource commands at the same time. I guess we'll have the same problem with FRIMSource.

It is also difficult and slow to encode directly from a physical blu-ray disc, because the BD players are slow and noisy. The disc can also become very hot if it has to spin in the drive during hours. OK, some peoples encode from a mounted ISO, but I can't exclude the fact that many peoples use the original BD decoded on the fly by AnyDVD HD.

Also, I need to demux the audio and subtitle streams anyway (to convert them when necessary) and I need to count the number of frames during the demux process, so the demux phase cannot be completely avoided.

If you want to convert the subtitles to 3D, BD3D2MK3D needs to extract the 3D-planes from the MVC stream, and currently it can do that only if the MVC stream has been previously demuxed.

I prefer also to copy all necessary files in one directory, because the user can launch the encode at any time, without having to be sure that the BD is still in the drive or the ISO is still mounted.

Only FRIMSource can decode the M2TS files directly, and currently I have a little preference for DGMVCSource. (I have had a problem that I have never reported here with FRIMSource and a specific BD. It was unable to decode or serve the last frames of the movie and therefore the avisynth script was stopped waiting indefinitely for FRIMSource to finish its job. DGMVCSource doesn't have that problem.)

Also, currently, I don't know how to know for sure what MVC MPLS corresponds to the AVC MPLS. To determine what MPLS is probably the dependent view, I use the file sizes. The size of the AVC MPLS + the size of the MVC MPLS must be equal to the size of the SSIF. That simple trick works well most if the times, but I cannot exclude the fact that it is not impossible to have several MPLS files that have exactly the same size, and therefore I will not be able to determine for sure which one must be used.

Would it be useful to add an option to use the direct method but if that method is used only when FRIMSource is selected and not DGMVCSource, and when the movie is made of a single file, and when the user has not selected any subtitle stream or when the option to convert it to 3D is not used, and when the program can determine what MPLS file contains the MVC stream? If all these conditions are met, I should be able to use your method. The demux process will have to be done anyway, but it will probably be somewhat faster because there is much less data to write to HDD. I can add that option if you wish, but honestly I think it's just another option that very few peoples will use and that will make the GUI even more complicated.

I agree that I should start a new thread for BD3D2MK3D. I did not want to do it before because the program was still somewhat unstable, and the info about the 3D conversion was centralised in this thread, but now, with DGMVCSource and FRIMSource, we have a very stable method and imo my program is mature enough to have its own thread. I'll create it when a new version will be ready...

[r0lZ]

Originally Posted by frank

What do you think about extending BD3D2MK3D to the 3rd option: Blu-ray 3D encoding with FRIMencode() to BD or MKV3D.
Now MakeMKV can generate stereo MKVs (mkv standard compliant) from BD3D and Stereoscopic Player plays it well.
The development goes ahead...

Well, I don't think I'll do that. The point of my program is to convert a 3D BD to SBS or T&B, and you are free to burn the resulting 3D MKV on a BD or DVD to play it with your BD player if you wish. If you want to copy a BD 3D to a BD 3D, you should use a BD copier or BD Rebuilder.

I will think about the possibility to encode to MK3D with FRIMencode, but afaik currently there is only very limited support for that format (except stereoscopic player) and therefore don't expect that soon. When enough 3D TVs and BD players will support that format, I will probably add that option...

[frank]

Thank you for your very detailed explanation. You've convinced me. mpls and subs operations need MVC.
And in that special case where demuxing isn't needed I can easy modify the script.
Uh, it's time to buy a new disk...

I wait with joy on your new BD3D2MK3D thread.

[Thalyn]

Originally Posted by sef

And who knows.. (Maybe it takes place during the transition between layers on Blue Ray disc?)..

I've always worked from files on my harddrive - plus I've tried a few different extraction methods (tsMuxer, eac3to, MakeMKV, etc). It's possible the layer transition still has some kind of residual effect on the data (a "layer change here!" flag that the AVISynth plugins don't like, for example), and both issues present in kinda the right place to be as a result of a layer change, but it's definitely weird.

Though that does remind me... I should grab a new nightly of Handbrake and try their QuickSync path again on it. If you use QSV encoding you can also use QSV decoding, instead of just DXVA, which I've used in the past to give the same error on just the AVC stream. That was a fairly early QSV implementation I tried last time, though, so maybe they've been able to solve it.

[slavanap]

Originally Posted by r0lZ

First, afaik, as noted by Nico, there is no way to process a MPLS file, and therefore no way to process the titles made of several parts. OK, there are probably some methods that could work, like the one suggested by Neuron2, but the point is to save some time and disc space, so joining the files is not a good idea imo. It should be possible to process each M2TS file independently, with several FRIMSource commands, but the previous versions of BD3D2MK3D used that trick with ssifSource, and we know that it was very difficult to start the encoding due to timeout problems when avisynth initializes all ssifSource commands at the same time. I guess we'll have the same problem with FRIMSource.

Have you tried mplsSource function from the latest ssifSource4 plugin? It can glue all ssif parts without going out of memory.
Nevertheless, I admit, ssifSource4 is slow enough itself and audio processing need to be done separately, but I'm going to fix these issues.

[r0lZ]

Yes, I know that your tool can join the parts, but BD3D2MK3D uses DGMVCSource or FRIMSource, and not ssifSource. (I may add it later if it's necessary to process "difficult" BDs like Pacific Rim, but currently, its syntax and usage is too different from the two other methods to be easily integrated. I don't want to multiply the different methods in the same GUI.)

And I think the problem with the previous versions was not related to the memory, but to timeout issues. When a script starts, all Source commands must be executed, even if they are chained together to source different parts of a long clip, because the script has to know the total number of frames and it must verify the compatibility of the different parts (and it must probably do other things as well). Since these commands require some time to initialize themselves, when the MPLS has hundreds of SSIF parts, the script takes to long to start, and an error occurs. Maybe it's also related to the memory, I don't know, but IMO fixing memory problems may not be sufficient. Anyway, I wish you good luck with the current developments of ssifSource4. Thanks for your continuous efforts.

[frencher]

L'Extravagant voyage du jeune et prodigieux T.S. Spivet (perpetual movement)
La 3D relief vue par Jean-Pierre Jeunet

[r0lZ]

Why do you post these links?

BTW, I like very much the films by Jean-Pierre Jeunet, but T.S. Spivet is not particularly good, perhaps because it's an American film, and he has not been free to do what he wants really. However, his conception of the 3D is the best I've seen in a movie. Nicely done and very original.

[frencher]

r0lZ it's just a really movie shot in 3D and can be used for comparison with 3D fake ex: World War Z
How did you get the 3D effect in this film?

[r0lZ]

Ah, OK.

As I said, I like the 3D in that film. It is much more intelligent than in most (all?) other 3D films. For example, when T.S. Spivet imagines a new invention, the engine appears as an independent object in 3D, in front of the screen. It's exactly that kind of idea that I like in all films by Jeunet (except in Alien 4, another minor US film), and he has nicely adapted his world to the 3D. I like also very much the fact that Jeunet is a perfectionist, as in all his films, and he has shot the movie with the quality of the 3D in mind. IMO, it's the best 3D movie so far, perhaps with Hugo Cabret by Martin Scorsese. (I like that one for the marvellous scenes in the big clock, really spectacular in 3D.)

I don't like much the US blockbusters like Pacific Rim or Hansel & Gretel, shot with boxing gloves, without any imagination, and obviously made only to make money. The 3D is mainly fake (conversion), except in the scenes with a lot of computer graphics. In that kind of films, the 3D is mainly a commercial argument. And that works! I have watched that films in 3D, even if I don't like them! ;-)

And of course, I don't like the conversions like what they did with Jurassic Park or Titanic. They are not bad films, but they have not been shot in 3D, and the post-process to convert them to 3D cannot be completely satisfactory.

In fact, my real interest for the 3D comes from the animation. I love animation, and I have worked on some animated movies and TV series in computer graphics in the past (before the 3D fashion). Of course, in computer animation like the Pixar movies, all difficulties related to the 3D cameras are inexistent, and the result is marvellous. There are so many 3D animated movies that I love that I can't quote them all.

Note: For the English peoples here, the name of the movie by Jeunet is, in English, The Young and Prodigious T.S. Spivet. It's his second US film, after Alien 4. IMO, Jeunet is much more creative when he has the freedom of a French production than in the US environment, where producers are real censors. Despite being a minor film, T.S. Spivet is a good example of what should be a film in 3D.

[frank]

Oh, Hitchcock's Dial M for Murder 1954 3D, a masterpiece for such an old movie.
---

In latest BD3D2MK3D v0.39 you cannot select BDSup2Sub.jar anymore.
One option is greyed out. If you change the .ini then you can work with Java but the creation of subs fails.

> "" -Xmx256m -jar "C:\\Users\\Chef\\BD3D2MK3D\\toolset\\BDSup2Sub.jar"
   "C:\Users\Chef\Videos\movie 3D\00000_mpls\00000.track_4608.Ger.sup"
   -o "C:/Users/Chef/Videos/movie 3D/00000_mpls/00000.track_4608.Ger_forced.3D_2D/temp_2D.xml" 
   --palette-mode keep --minimum-time 1 --convert-fps 24p,24p
*** BDSup2Sub open error: couldn't execute "": no such file or directory

BD3D2MK3D console shows:

"C:\\Windows\\System32\\java.exe"

That's wrong.

Old v0.38 works.


Win7 x64, Java 1.7 b60 32bit

[r0lZ]

I agree for the Hitch, but the BD 3D is terrible! The quality of the picture is horrible. I prefer the 2D version with a crisp picture.

I will have a look for the Java bug. Normally, the program tries to determine the java path automatically, but it may fail if you are running a 64-bit Windows. The program requires the 32-bit version of java. I suppose it's the problem, because system32, despite its name, holds only 64-bit programs and DLLs. The 32-bit version should be in SYSWOW64 or in "Program Files (x86)".

Can you open the console (from the File menu) and type (case sensitive):

JavaVersion false true

It should reply with a dialog, and print the path of your java.exe in the console. I guess it will find nothing, because only the 32-bit version of Java is installed.

It's strange if it works with the v0.38. Are you sure you haven't uninstalled the 32-bit version? Anyway, I will have a look.

Thanks for the bug report.

[frank]

BD3D2MK3D v0.39 console shows indeed
C:\Windows\System32\java.exe
but that is a fake.
The v0.38 console shows the same wrong path.

The java.exe (x86) actually lies in
Program Files (x86)\Java\jre7\bin and in SysWOW64.

Maybe there is a Registry problem. I have deinstalled Java x64 some time ago.
But v0.38 works, then there must be a path problem.

[r0lZ]

Since BD3D2MK3D is a 32-bit app, it sees the 32-bit system files in system32, although the real path is SYSWOW64. The 64-bit programs, on the other hand, see the 64-bit system files in system32, and the 32-bit files in SYSWOW64, as they are really. So, BD3D2MK3D displays the correct path, from his point of view. (It doesn't see java.exe in Program Files (x86) probably because that directory is not in the system path.) To see the right paths, you have to use a 32-bit program (such as cmd.exe from the SYSWOW64 directory). Same thing for the registry editor. If you use regedit.exe, you'll see the registry for the 64-bit programs, irrelevant for BD3D2MK3D. That's horribly complex, but he, it's Microsoft!

In the config file, there are two settings related to BDSup2Sub.jar:

set ::config(useBDS2Sjava)    1
set ::config(javapath)        {C:\Windows\System32\java.exe}

With that settings, it works perfectly on my Win7 x64 with both versions of java installed.

When BD3D2MK3D starts, it checks the values of your config file, and if the javapath doesn't exist, it tries to find it with the DOS command "where java" (executed in a 32-bit shell). If the command returns nothing, it tries to use simply "java.exe" (without any path). Finally, it executes the javapath command with the argument -version. If that command cannot be executed, it assumes that java is not properly installed, and it disables the option to select BDSup2Sub.jar in the settings menu.
IMO, that logic should work, but perhaps there is something special on your system that prevents the java -version command to run.

I will compare the current code with the code of v0.38. Maybe I'll understand what's wrong...

[jdobbs]

Only Microsoft could come up with the concept of storing 64 bit files in a folder called "SYSTEM32" and storing the 32 bit files in folder called "SYSWOW64".

I understand the history... but it is still hilarious.

[r0lZ]

Yes, it's crazy, especially with that redirections to other folders when you are using 32-bit programs. It is almost impossible to understand what should go where, and what paths should be used.

Anyway, I think I have found the reason of the java bug. It's not related to the java path, 32 or 64-bit. In the last version, I have moved the test for the java path earlier in my code, so that the program can display a warning if java is not found, because it will use BDSup2Sub++ instead, and the risk of bugs is important. As a consequence, the setting from the config file was not saved correctly. The program worked fine if the settings were saved with the correct path, but if the path was blank, even after having installed correctly java 32-bit, the path was still blank in the config file, and therefore the program refused to enable the Use BDSup2Sub.jar option.
I will send a beta version to frank, and if he confirm that the fix works well, I will release v0.40...

[frank]

Thanks for the clarification of SysWOW64.
M$ sucks. They will never make a clean system, look at the updates... In one month up to 1 GB new files! A never ending story.

New BD3D2M3D 0.40 worked well.

[r0lZ]

OK, so, as promised, I have started a new thread for BD3D2MK3D.

Please post all comments, feature requests, bug reports and questions about BD3D2MK3D in the new thread. But continue to use this thread for general questions about 3D conversion (not directly related to my program) or if you want to contact the author of a third-party tool that my program uses and that has been developed here.

Don't forget to subscribe to the new thread if you want to be notified when a new version of BD3D2MK3D will be available. I will not announce the new releases in this thread any more.

V0.40 is available, and is announced here for the last time:

# v0.40 (July 2, 2014)
# - Fixed bug with java not being found and therefore the Use BDSup2Sub.jar option was disabled.

Download: BD3D2MK3D.7z

[tebasuna51]

9 post moved to http://forum.doom9.org/showthread.php?t=170828