[noggin]

I don't believe that is the case. For an MVC ISO/folder you see:

Code:

$ ls -l ~/mnt2/BDMV/STREAM/
total 24109856
-r--r--r-- 1 nobody nogroup 18870153216 Jan 11 23:26 00000.m2ts
-r--r--r-- 1 nobody nogroup  5818337280 Jan 11 23:29 00001.m2ts
dr-xr-xr-x 2 nobody nogroup          92 Jan 11 23:30 SSIF

00000.m2ts is a perfectly standard 2D H.264 file, that can be played by any H.264 compliant player.
It is also used as the left eye with MVC video. The smaller 00001.m2ts file contains the right eye data.
It can't be played in isolation as it depends of the frames from 00000.m2ts (which is why it is smaller - left and right eye views are usually very similar).

No magic that I'm aware of. If you want 2D H.264 you read 00000.m2ts.
If you want 3D MVC you merge (e.g. by comparing decode timestamps) 00000.m2ts and 00001.m2ts, and decode that.

Thanks for clarifying - when I looked at some BD 3D stuff I was a bit confused (possibly as to why you had to rip 3D BDs as ISOs not folders at one point?) and must have convinced myself it worked differently. What you say makes total sense.

Two, time-stamp co-incident, m2ts files. One file contains a 2D H264 stream (and audio) which is the 2D compatible eye and is the left-eye feed for a 3D player. The other file contains an MVC stream, which is effectively left/right eye difference data, itself compressed, which allows a right eye to be contstructed in reference to the 2D left eye stream. (It's a bit like M+S stereo in some ways I guess - though not quite the same)

The second stream is much smaller as it is only left/right difference data - and there is a lot of redundancy between the eye feeds.

That's why MVC encoding is preferable to Full Resolution SBS or TAB H264 encoding as a single double-height or double-width file (effectively being treated as a double-resolution 2D file) - as that won't exploit redundancy between the two eye feeds.

Must say this is an incredible development. When a £30 Pi 2 can decode and output Full HD 3D content, that's pretty amazing.

Thank you! (I'm the person working on the MVC decode at low level.)

You're both partly right! The 00000.m2ts and 00001.m2ts files are the two component streams that make up the full MVC stream; if you remultiplex them using the DTS timestamps in the streams, then you get something that the Raspberry Pi's hardware decoder can handle. There's also an interleaved file (SSIF/00000.ssif) which consists of the same data, interleaved at a larger block level. This is where the filesystem trickery comes in: the SSIF file contains the same actual data blocks as the two .m2ts files. (Actually, it's kind of the other way round: the SSIF file is laid out on disc so that a 3D player just reads it continuously; a 2D player skips the derived view parts. The aim here is to optimise head motion.) As yet, I haven't figured out where the data that tells you which blocks of the SSIF file are which, though -- I think it's somewhere in the clip files, but I haven't investigated in detail yet, and the specs don't seem to be public.

I have prototype code remultiplexing streams in RPi's omxplayer code, so it shouldn't be too far off, I hope. However, at the moment we're working on making the core decode really robust.

Thanks deborah_c - glad to know I wasn't totally off. I remember not understanding how a 50GB BD could contain files which totalled more than 50GB - so if the SSIF and M2TS are the same content mapped differently - that makes sense.

And continued good luck with the great work.