GNOME Bugzilla – Bug 529500
[videotestsrc] support for NV12 and NV21
Last modified: 2008-05-21 22:55:06 UTC
This patch add's support for NV12 and NV21 colorspace formats.
Created attachment 109746 [details] [review] add support for NV12 and NV21
- where do the rounding rules come from? - paint_setup_NV12 sets ustride twice and vstride not at all - what's this for?
Created attachment 109775 [details] [review] add support for NV12 and NV21 1 and 2: fixed 3: This format is used by some hardware decoders/sinks.
Could you post a link to the source where you got the rounding rules from?
Like said on IRC I based this on the same stride as currently used (only the luma) for comparable colorspaces (like I420 or YV12). No one was able to tell where I can find the specs about the strides. The only information I can found is on ffourcc.org [1] and that does not talk about the stride for the luma plane just says that it is the same for the chrominance. But after looking around how other programs did the stride I found that the stride for I420 and YV12 is 8 in some xorg drivers[2], at least if I interpret that code correctly. and mplayer[3] doesn't set a stride for planar colorspaces but I don't suppose that we will take that as a reference. So, than I have also a question: Where are the current rounding rules based on? Is that Xv driver or our implementation wrong? [1] http://www.fourcc.org/yuv.php#NV12 [2] http://www.google.com/codesearch?hl=en&q=+%22pPriv-%3EsrcPitch+%3D+(width+%2B+7)+%26+~7%3B%22+show:wkDubdvNK5M:BslqBkyo2rU:GaFsNiUf3q4&sa=N&cd=2&ct=rc&cs_p=http://www.angstrom-distribution.org/unstable/sources/xf86-video-sisusb-X11R7.0-0.7.1.3.tar.bz2&cs_f=xf86-video-sisusb-X11R7.0-0.7.1.3/src/sisusb_video.c#first [3] http://www.google.com/codesearch?hl=en&q=+%22mpi-%3Estride%5B0%5D%3Dmpi-%3Ewidth%3B%22+show:ONk9uu1qiqg:bZksL57wocI:ONk9uu1qiqg&sa=N&cd=7&ct=rc&cs_p=svn://svn.mplayerhq.hu/mplayer/trunk&cs_f=libmpcodecs/vf.c#l362
Rounding rules are based on what X drivers use, which is generally the same as what DirectShow/Video for Windows uses, which is generally the same as whatever the underlying hardware requires. In general, Y sizes are rounded up to multiples of U and V sizes, and then the row strides are rounded up to 4. The latter comes from wanting rows to be disjoint runs of uint32_t's, because of PCI bus issues. I'd be willing to accept code that follows these rules without outside verification.
committed: * gst/videotestsrc/videotestsrc.c (paint_setup_NV12), (paint_setup_NV21), (paint_hline_NV12_NV21): Add support for NV12 and NV21 in videotestsrc