Caps for full-range YUV data?
mgruenke at Tycoint.com
Thu Jul 28 20:37:07 PDT 2011
On Thursday, July 28, 2011 at 17:51 -0400, David Schleef wrote:
> In video, pretty much nobody does full-range components, because
> there aren't any underlying video standards for it.
When it comes to conventional video sources (e.g. broadcast, authoring,
and post-production systems; consumer & professional digital video
camcorders), I think you're probably right. However, if one looks at
slightly less conventional sources, such as network cameras (aka IP
cameras) and digital still cameras, you might find that full-range video
is a bit more common.
Conversely, I know that some older MJPEG-based digital video capture &
editing systems used what I refer to as the '601' range (alluding to the
venerable component digital video standard, ITU-R Rec. BT.601).
Regarding your caps, I'm concerned about the potential for conflation
with color space that the property name 'color-matrix' seems to imply.
MPEG-4 (ISO/IEC 14496) part 2 (Video) and part 10 (AVC/H.264) both treat
these as distinct & independent concepts. In part 2, the relevant
fields are called video_range and matrix_coefficients (there's also
transfer_characteristics (i.e. gamma) and colour_primaries). In part
10, four fields analogous to these exist, although the equivalent of
video_range is instead called the video_full_range_flag.
In DirectShow (and elsewhere), Microsoft also implemented enum
MFNominalRange (http://msdn.microsoft.com/en-us/library/ms705659) as an
independent field (MF_MT_VIDEO_NOMINAL_RANGE), such as in
Interestingly, it can indicate two further ranges, as well.
Therefore, for both practical reasons and the precedent set by these
standards & implementations, I feel a separate 'video-range' property
would be warranted. Did you consider this option, or what's the
rationale behind 'color-matrix'?
BTW, thank you for videotestsrc! It's surprisingly useful! :)
(Hint to others: try changing the 'pattern' property.)
More information about the gstreamer-devel