What output formats are you planning to support? What I would love to see is mainly playback of side-by-side files in quad-buffered opengl (nvidia quadro/3dvision output to 120hz monitor, active glasses) and horizontal interlaced (Zalman monitor, circular polarized passive glasses) format. <blockquote type="cite">2010/05/23 0:51 "David Schleef" <<a href="mailto:ds@entropywave.com">ds@entropywave.com</a>>: On Tue, May 18, 2010 at 07:12:26AM +0000, Martin Bisson wrote: > My work is based on the proposal ma...The goal, imo, is to define how GStreamer handles stereo video *natively*, that is, elements can automatically differentiate between normal and stereo video, caps negotiation works as one would expect, playback of a stereo video on a normal monitor would allow for the option of viewing in mono or with red/green glasses, etc. A lower goal would be to create elements that manipulate stereo video, but entirely manually. I'm only concerned with the former. There are two main options: Use pairs of well-known raw image layouts (i.e., I420, YUY2, UYVY, etc.), probably consecutive in memory, for the left and right images. Or, define a bunch of new fourccs that mean "stereo video" that correspond to existing layouts, but enhanced for stereo. Using existing layouts: I recommend packing the two pictures consecutively in memory, left then right. The main rationale is that conversion to a normal picture is simply changing the size and/or pointer of the buffer and changing caps. Other packing arrangements might be important in the future, so having a manditory caps field marking the packing would be a good idea. I recommend using a new caps type, perhaps video/x-raw-yuv-stereo or some such, instead of using video/x-raw-yuv,stereo=true. Using video/x-raw-yuv leads to endless compatibility problems: elements that currently handle video/x-raw-yuv would silently do the wrong thing with stereo video. Using x-raw-yuv would mean width/height in the caps would be double the *actual* width/height of the mono video, which is hacky. Also, converting from stereo to mono in many cases would require copying. Defining new fourccs: This has the obvious disadvantage that we'd either need to keep these internal to GStreamer, or make them well-known enough for other people to use them. Integrating with existing elements (and libgstvideo) is straightfoward. Adding new layouts (side-by-side, top-bottom, memory consecutive, etc.) is simple, although adds *lots* more fourccs. I think that overall, using new fourccs would involve writing less code and be less prone to bugs. It is my preference. Oh yeah, other methods such as dual pads for left/right, or buffer flags, are non-starters: our attempts at dual pads for float audio failed miserably, and we don't have any buffer flags available. And there are other reasons which I don't feel like enumerating right now. dave... ------------------------------------------------------------------------------ __________________...</blockquote>