Firstly; this is information on how to extract your legally bought copy of 3D movies so you can play them on devices that do not use optical media (e.g. a VR headset). I do not condone piracy.
Whether you want to make a backup, or to convert it to a more usable format, 3D movies can be ripped from Blu-Ray discs. My primary use case is using my VR headset to view 3D movies in a virtual theater; which cannot be done with 3D Blu-rays directly. And since you can no longer buy 3D televisions, this is really the only practical way of viewing them. Not to mention you do not get the shutter flicker headache you do with 3D TVs. Two apps I highly recommend for viewing are Pigasus and Big Screen (I personally LOVE the retro theater environment in Big Screen). Both will allow you to either play from local media on the device, or stream from a DLNA server (e.g. Plex).
This is a multi step operation, and regrettably, will require Windows for one of the stages as the free tool to convert the 3D information is Windows only. I will update if I ever find a way to get Windows out of the workflow.
The first step is to get MakeMKV, which can extract almost any media as an MKV file. When you read in the disc in MakeMKV, most will be obvious which track to rip; it’ll be the largest one. In some instances, particularly with Disney movies, there will be several that appear to be identical. This is usually where the majority of the movie is the same, but the credits or title may be in another language. E.g. with Disney ones, you will see the source file name as “00800.mpls”, with a few others. 800 is the U.S. version, and they one you will likely want. If you prefer another language, you’ll have to do your own research to find out which number corresponds to which language; I don’t know. Some releases purposefully create a bunch of false tracks that will slice the movie up into random order. There is no set way to know which one is correct if you come across one, other than to search the forums for the correct one to rip.
When you choose the movie, turn down the little triangle, and make sure you check “Mpeg4 MVC High@L4.1/StereoHigh@L4.1”; it will not be checked by default. The MVC track is the track that contains the 3D information, so is obviously necessary for this to work. Check all the audio and subtitles you want.
Now you have a large MKV file that contains the 3D movie. Unfortunately, very few players will interpret the MVC data, so you can’t just play the MKV. For example, VLC will just play the left (main) channel, but you will not see anything 3D. So what we need to do is generate the separate left and right channels, and put them side-by-side (I choose side-by-side rather than over/under because it is easier to line them up; the frames often have black bars on the top and bottom which complicates the over/under method).
The next step is to extract the H.264 RAW stream from the MKV, as the tool in the next stage only operates on raw streams. To extract it, the easiest way is with mkvextract from the MKVToolNIX package. You can use the following script; just call it with the name of the MKV you extracted earlier:
#!/bin/bash -x
FILE="$1"
mkvextract -f tracks "${FILE}" 0:"$( basename "${FILE}" .mkv )".h264 --fullraw
If you are doing this step in windows, just adapt the command accordingly.
Now you have a raw H.264 stream, which contains the full left channel data, interleaved with the MVC data that will be used to generate a full right eye image. Unfortunately, now, you will have to use a Windows machine. You will need the FRIM software (or alternate site), which uses the Intel Media SDK for the actual MVC processing, and you will also need ffmpeg, an absolutely indispensable tool for all things media.
Now because it is Windows, the next steps are clunky and awkward, or you have to use linux to make your life easier. There are two ways you can do this:
Method 1 – The Windows way (ugly)
You are going to need two command prompts because piping in Windows is a horrible joke.
I have two small batch files, which I call “frimin.bat” and “frimout.bat”. If the names are not clear, you will run “frimout.bat”, which will generate data and send it out to “frimin.bat” which will take the data from frimout and process it.
The “frimout.bat” script:
FRIM_x64_version_1.31\x64\FRIMDecode64.exe -i:mvc %1 -sbs -o \\.\pipe\frimdataThe “frimin.bat” script:
ffmpeg -y -f rawvideo -vcodec rawvideo -s 3840x1080 -pix_fmt yuv420p -thread_queue_size 128 -r 24000/1001 -i \\.\pipe\frimdata -i %1 -c:v prores_ks -profile:v 3 -vendor apl0 -pix_fmt yuv422p10le -c:a copy -sn -map 0:v:0 -map 1 -map -1:v %1-sbs.mkvMethod 2 – The Linux way (with proper piping)
The second way you can do it is to bring linux in to the picture with Windows Services for LInux (i.e. WSL). After you install that, you can install the linux version of ffmpeg, and then you can use proper piping:
#!/bin/bash
FRIM_x64_version_1.31/x64/FRIMDecode64.exe -i:mvc "$1" -sbs -o - | ffmpeg -y -f rawvideo -vcodec rawvideo -s 3840x1080 -pix_fmt yuv420p -r 24000/1001 -i - -i "$2" -c:v prores_ks -profile:v 3 -vendor apl0 -pix_fmt yuv422p10le -c:a copy -sn -map 0:v:0 -map 1 -map -1:v "$2"-sbs.mkvThis takes two parameters; the h264 RAW file, and then the MKV you ripped from the Blu-Ray.
For both methods, if you look at the commands, you can kind of infer what is going on, but I will break it down.
The FRIMDecode64.exe command takes the RAW H.264 stream you extracted as the input. It will take the left and right channels, and arrange them as a side-by-side image stream in raw YUV 4:2:0 to a named pipe “frimdata”. It has no timing or any other information, so you have to match the source. Fortunately, 3D sources are 24 fps (at least, I have not run across any at another frame rate).
The ffmpeg command will read the data from the named pipe created by FRIMDecode64.exe. You have to specify that it is raw data, and that the size will be 3840×1080, the color format is YUV 4:2:0, and the frame rate is 24 fps (technically 23.976; hence the 24000/1001). Now you will see a lot of content out on the net that does half-frame side-by-side where the image is still 1920×1080 and the horizontal is squished and you lose half of the data. There were good reasons to do this many many years ago (mostly because 3D TVs could not handle full width streams), but systems nowadays can more than handle the full frame data, so I do not see any reason to discard the data. If you prefer the poorer quality to save a little space, just set the size you want on the ffmpeg command.
You will notice that it is reading from two inputs; all the options so far apply to the first input, which is the named pipe. The second input is the original MKV that you extracted with MakeMKV; we will be pulling the audio in from that file.
Now here is where you have to make a decision. ffmpeg can output pretty much any format you like. What I am doing here is outputting to ProRes, because I prefer Handbrake for my final encodes. If you are comfortable with ffmpeg, you can use it to output your final result directly here. The how of that is its own tutorial, and beyond the scope of this one.
I choose the prores_ks algorithm because it seems to have more options than prores_aw. I set the profile to be 3; the HQ profile. I hard set the vendor tag to be from Apple (as this is their codec). This may not be necessary, but does not hurt. Now here, I write the output in YUV 4:2:2, 10-bit. This is actually able to store more data than is in the original, but it also means that there will be little to no loss (ProRes is technically a lossy format, so I want to get a decent reduction without losing much data).
The remainder of the command tells it to copy the audio tracks as-is, discard subtitles (they are just in the way in this part of the work-flow), map the video from the first stream (0) to be the first (only) stream in the output (0). Then we map everything else in the second input (1 – the original MKV file), but NOT the video stream (-map -1:v).
So, you first run “frimout.bat” with the H.264 stream file in one of your command windows. It will open the named pipe and block until something reads from it.
In the second command window, you then run “frimin.bat” with the name of the original MKV file. You will then see ffmpeg start to encode, and FRIMDecode64.exe will output the frame count as it processes.
I could not find any way to do this in one command as a real pipe because Windows is stupid. If someone out there knows how to do it in one command prompt/batch file (or even a PowerShell command), I would gratefully take the information and update this accordingly.
Now, sit back and wait. Once it completes, you’ll have a very large (200-400ish GB) file that Handbrake can read and convert to your final form.