2015-05-08, 14:53
Currently on Pi you need to include "3D.SBS" or "3D.TAB" in filename, or identify 3D SBS/TAB in video OSD.
As the file is not really SBS/TAB it would make sense to also support "3D.MVC".
We need to decide whether to render the GUI as half-SBS, half-TAB, full-SBS or full-TAB.
full-SBS/full-TAB is pretty expensive (16M for the framebuffer, and on Pi it is triple buffered). It would also reduce the gui FPS in this mode, so currently we use "half" modes on Pi.
It would be nice to detect 3D support (through ffmpeg) before playback starts, so matching filenames is not required and file is automatically identified.
Automatically detecting if file is left-right or right-left would be useful. It appears the MVC bitstream doesn't contain that information, but I suspect it is somewhere within ISO.
We do have someone who has been investigating .ssif parsing, but work is currently stalled.
If you can work on this now, then feel free, although please keep us informed of progress.
Our plan was to handle this in libblueray.
I suspect you've discovered this, but the blu-ray folder structure contains a .ssif file which includes the complete movie, interleaved as a chunk of right-eye data, followed by a chunk of left-eye + audio + subs. There are also files like "0000.m2ts" and "0001.m2ts" which are virtual files that use hard links to ssif file. The lower number if left-eye + audio + subs and the number + 1 is right eye.
Our view was that reading the ssif file directly would likely result in more efficient file/network accesses compared to trying to merge the 0000.m2ts / 0001.m2ts files.
The chunk size was quite large, meaning that from seeking, you would have to read the whole right-eye chunk (which contains many video frames), and then after the first picture from left-eye chunk could return the first complete left+right+audio+subs chunk. Back of the envelope calculations suggested that was okay (right-eye bitrate is typically about half the left-eye's which helps). Even on 100Mb/s network seek time should be below 1 second.
E.g. ssif stream looks like:
[ R R R R R R R R ] [ L L L L L L L L ] [ R R R R R R R R ] [ L L L L L L L L ] [ R R R R R R R R ] [ L L L L L L L L ]
L : left eye + audio + subs
R: right eye
After reading:
[ R R R R R R R R ] [ L ]
You can produce [ LR ], and as each L picture is parsed you emit a new [ LR ]
We believe this new [ LR LR LR LR LR LR LR LR ] stream will be handled by ffmpeg's mt2s parser.
A minor ffmpeg patch is needed to handle MVC inside mp4 files.
As the file is not really SBS/TAB it would make sense to also support "3D.MVC".
We need to decide whether to render the GUI as half-SBS, half-TAB, full-SBS or full-TAB.
full-SBS/full-TAB is pretty expensive (16M for the framebuffer, and on Pi it is triple buffered). It would also reduce the gui FPS in this mode, so currently we use "half" modes on Pi.
It would be nice to detect 3D support (through ffmpeg) before playback starts, so matching filenames is not required and file is automatically identified.
Automatically detecting if file is left-right or right-left would be useful. It appears the MVC bitstream doesn't contain that information, but I suspect it is somewhere within ISO.
We do have someone who has been investigating .ssif parsing, but work is currently stalled.
If you can work on this now, then feel free, although please keep us informed of progress.
Our plan was to handle this in libblueray.
I suspect you've discovered this, but the blu-ray folder structure contains a .ssif file which includes the complete movie, interleaved as a chunk of right-eye data, followed by a chunk of left-eye + audio + subs. There are also files like "0000.m2ts" and "0001.m2ts" which are virtual files that use hard links to ssif file. The lower number if left-eye + audio + subs and the number + 1 is right eye.
Our view was that reading the ssif file directly would likely result in more efficient file/network accesses compared to trying to merge the 0000.m2ts / 0001.m2ts files.
The chunk size was quite large, meaning that from seeking, you would have to read the whole right-eye chunk (which contains many video frames), and then after the first picture from left-eye chunk could return the first complete left+right+audio+subs chunk. Back of the envelope calculations suggested that was okay (right-eye bitrate is typically about half the left-eye's which helps). Even on 100Mb/s network seek time should be below 1 second.
E.g. ssif stream looks like:
[ R R R R R R R R ] [ L L L L L L L L ] [ R R R R R R R R ] [ L L L L L L L L ] [ R R R R R R R R ] [ L L L L L L L L ]
L : left eye + audio + subs
R: right eye
After reading:
[ R R R R R R R R ] [ L ]
You can produce [ LR ], and as each L picture is parsed you emit a new [ LR ]
We believe this new [ LR LR LR LR LR LR LR LR ] stream will be handled by ffmpeg's mt2s parser.
A minor ffmpeg patch is needed to handle MVC inside mp4 files.
