(2015-03-18 14:59)popcornmix Wrote:
(2015-03-18 14:49)noggin Wrote: There's some clever UDF-ery going on as well isn't there - so that the H264 stream (used also for 2D) appears twice on the disk - though both appearances point to the same data? One is a standard H264 2D Blu-ray stream, with the second file pointing to both the 2D AVC and the additional MVC stream - or am I totally out of whack?
I don't believe that is the case. For an MVC ISO/folder you see:
00000.m2ts is a perfectly standard 2D H.264 file, that can be played by any H.264 compliant player.
$ ls -l ~/mnt2/BDMV/STREAM/
-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
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.