(2015-03-18, 17:53)looun Wrote: i am not explain well,i am talking about file conversion can play raspi , source MVC out MKV( MVA ) with FULL HD SBS(or the right name) , 1 frame double information/resolution.

(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:

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.

(2015-03-19, 01:38)noggin Wrote: Must say this is an incredible development. When a £30 Pi 2 can decode and output Full HD 3D content, that's pretty amazing.

(2015-03-19, 01:38)noggin Wrote:

(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:

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.

(2015-03-19, 06:27)deborah_c Wrote:

(2015-03-19, 01:38)noggin Wrote:

(2015-03-18, 14:59)popcornmix Wrote: 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.

(2015-03-19, 06:27)deborah_c Wrote:

(2015-03-19, 01:38)noggin Wrote:

(2015-03-18, 14:59)popcornmix Wrote: 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.

(2015-03-19, 07:57)nickr Wrote: @deborah_c - is there a tool that can tell me whether an mkv file holds an mvc 3d stream? I downloaded some samples (pointed to in the rpi oe test builds thread) and I can't seem to get mediainfo to shed any light on the fact that they are stereoscopic. Example:

http://pastebin.com/VGRbuXss

EDIT to add, thanks for your efforts. We all appreciate it.

(2015-03-19, 10:44)Skank Wrote: Very nice someone is working on it.
But thats only for pi?
Or are you working on software decoding as well (ffmpeg?)

I mean, can we expect kodi to support mvc in future as well cause of your work?

(2015-03-19, 14:14)popcornmix Wrote:

(2015-03-19, 10:44)Skank Wrote: Very nice someone is working on it.
But thats only for pi?
Or are you working on software decoding as well (ffmpeg?)

I mean, can we expect kodi to support mvc in future as well cause of your work?

Yes, we are only working on MVC for Pi. Some work (like the demuxing of MVC from ISO/folders) will be useful to all platforms, and will be pushed upstream.

But you need a platform that can support MVC decode.
Currently ffmpeg doesn't support this and that's not something we'll be adding. I'm sure ffmpeg will support it one day, but it's hard to say when.
There are other platforms that offer hardware MVC support. In theory they could be made to support MVC in the same way as the Pi,
but it requires a certain amount of plumbing, knowledge of how the GPU returns the right eye view, and some way of rendering it.

(2015-03-19, 14:57)Skank Wrote: Platform you mean OS?
Like windows?