summaryrefslogtreecommitdiff
path: root/NewGstVideo.moin
diff options
context:
space:
mode:
author192.94.94.106 <proxysb02.ext.ti.com>2010-09-20 16:15:03 +0000
committer192.94.94.106 <proxysb02.ext.ti.com>2010-09-20 16:15:03 +0000
commit5de02a6e488bce1c43c81dde53930f87635bae81 (patch)
tree263627cfb3a5f545f445d3738f61ccf80b57e038 /NewGstVideo.moin
parent6f51be6158861979f50ce23b0fcf01c4805dba56 (diff)
Diffstat (limited to 'NewGstVideo.moin')
-rw-r--r--NewGstVideo.moin7
1 files changed, 7 insertions, 0 deletions
diff --git a/NewGstVideo.moin b/NewGstVideo.moin
index ba25c04..18d3914 100644
--- a/NewGstVideo.moin
+++ b/NewGstVideo.moin
@@ -5,6 +5,9 @@ The caps themselves (to replace {{{video/x-raw-{yuv,rgb,gray,etc} }}}) should su
* interlaced buffer layout possibilities
* stereo buffer layout possibilities
* combinations of the above
+ * use fourcc's, or some fourcc-like value for rgb/grey caps (maybe string.. quarks for fast '==' comparison)
+ * note that if all raw video formats are supported w/ some fourcc-like value, then perhaps the caps name should just be {{{video/x-raw}}}
+ * what about bayer?
And should be flexible enough to support addition of new features later. Which means some way to negotiate between different elements which may or may not support the new feature.
@@ -31,6 +34,10 @@ Open points:
* some formats, like I420, could have two differing definitions of rowstride. (1) U and V planes have same stride in bytes as Y, or (2) U and V planes have 1/2 stride as Y.
* in some cases, it might be nice to have some flexibility to allow support for non-packed planar/semi-planar formats. In some cases where decoder requires padding or cropping for edges, or certain alignment requirements, the U and V planes may not start immediately after the previous frame.
+= Interlaced caps =
+
+= RGB/grey caps =
+
= Stereo video support in an existing branch =
Stereo caps have been proposed in a Google Summer of Code development branch (see [[http://gitorious.org/video3d/video3d]]). One of the important points in choosing how to extend existing caps to support a way to specify whether the video stream was stereo or not was the fact that we don't want existing plugins to accept silently a stereo stream and treat it as normal stream, as the interpretation of a {{{width x height}}} buffer is totally different if the buffer is stereo or not. Therefore, the addition of a field such as {{{"stereo=true"}}} or {{{"channels=2"}}} to existing video caps was not used.