[FFmpeg-devel] H.264 MVC

Kieran Kunhya kieran
Fri Jun 25 19:53:03 CEST 2010

--- On Fri, 25/6/10, Peter Wimmer <pwimmer at gmx.at> wrote:

> From: Peter Wimmer <pwimmer at gmx.at>
> Subject: Re: [FFmpeg-devel] H.264 MVC
> To: "'FFmpeg development discussions and patches'" <ffmpeg-devel at mplayerhq.hu>
> Date: Friday, 25 June, 2010, 18:18
> Hi,
> > IMHO it would be easiest to decode into side-by-side
> format,
> > the output can then just be handled like other 3d
> content.
> Over/under would be smarter, because each view would be
> located in two
> contiguous memory blocks, while data would have to be
> interleaved for
> side-by-side. Anyway, I consider neither one a clean
> solution. The caller of
> libavcodec should have the choice which view(s) to decode
> and retrieve the
> data in separate buffers. Although not used on Blu-ray, MVC
> supports more
> than two views, a flexible solution to handle multi-view
> content would be
> better than over/under. Anyway, there's not need to solve
> the problem now,
> first the decoder must be implemented.
> >The MVC spec itself is part of the H.264 spec here
> > http://www.itu.int/rec/T-REC-H.264 see
> Annex H
> It doesn't mention how to split the MVC stream in two
> seaprate streams with
> different PIDs as used on Blu-ray.
> > We have a ssif sample here http://samples.mplayerhq.hu/3D/small-00000.ssif
> Do you have MP4 sample with one MVC stream? It would be a
> better place to
> start than with the strange two streams of Blu-ray.
> Well, it there are no patches yet, I'll have to start from
> scratch...
> Peter
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel

You should work your way through the MVC conformance vectors found here:


I also agree that each view should be decodable separately.

More information about the ffmpeg-devel mailing list