•  Previous
  • 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 256
  • Next 
 
Thread Rating:
  • 15 Vote(s) - 4.27 Average
Kodi Media Player Options with 3D MVC & HD Audio
#46
(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.

makemkv will take the raw BluRay ISO as input and produce an mkv output fill without re-encoding. The bitstream is untouched, and the file will be FULL HD ([email protected] for each eye).
When this file is played on the Pi, it will be 3D with FULL HD resolution (i.e. twice as many pixels as the usual half-SBS or half-TAB encodes).
Reply
#47
Right, as full SBS rips (3840 x 1080) are almost double the filesize aren't they? While MakeMKV's MVC MKV's are actually slightly smaller than ISO counterparts (movie only) of the same titles. MKV I think requires less headroom than ISO.
[H]i-[d]eft [M]edia [K]een [V]ideosaurus
Kodi 3D MVC Hardware Options
Kodi A/V Samples wiki
3D: Zidoo X9S | Intel D34010WYK w/Kodi MVC build
4K: nVidia Shield TV (2nd gen)
Reply
#48
Small point regarding table in post #1: left/right eye switching is supported by RPi (added in #0316 build).
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#49
Thanks, will update it.
[H]i-[d]eft [M]edia [K]een [V]ideosaurus
Kodi 3D MVC Hardware Options
Kodi A/V Samples wiki
3D: Zidoo X9S | Intel D34010WYK w/Kodi MVC build
4K: nVidia Shield TV (2nd gen)
Reply
#50
Huh. Surprised about the 3d MVC MKV development. Will this be something that will work on Chromebox's? Ultimately I'm still hopeful that Nvidia's Android TV Shield box will support 24p, HD audio, MPEG2 & VC1 licensing, and proper deinterlacing and that can be an all in one device (Netflix and Google's LiveTV app), but the Chromebox is a damn good device other then a few software quirks with other skins and bad playback of one video file. MVC support would be the cherry on top as I just figured I would put a blu ray in my PS4 if I wanted to do 3D.
Reply
#51
(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.
Reply
#52
(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.
Absolutely; best news this week; heck, in however long, especially as it was unexpected.
[H]i-[d]eft [M]edia [K]een [V]ideosaurus
Kodi 3D MVC Hardware Options
Kodi A/V Samples wiki
3D: Zidoo X9S | Intel D34010WYK w/Kodi MVC build
4K: nVidia Shield TV (2nd gen)
Reply
#53
(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.

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.
Reply
#54
(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.

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.
Reply
#55
@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.
If I have helped you or increased your knowledge, click the 'thank user' button to give thanks :) (People with less than 20 posts won't see the "Thank you" button.)
Reply
#56
(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.

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?
Reply
#57
(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.

Code:
Format profile                           : Stereo [email protected] / [email protected]
MultiView_Count                          : 2
Those lines are the magic that show it's MVC.
Reply
#58
(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.
Reply
#59
(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.

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

I would say platform = hardware+OS
Reply
  •  Previous
  • 1
  • 2
  • 3
  • 4(current)
  • 5
  • 6
  • 256
  • Next 
 
Thread Rating:
  • 15 Vote(s) - 4.27 Average



Logout Mark Read Team Forum Stats Members Help
Kodi Media Player Options with 3D MVC & HD Audio4.2715