OSDN Git Service

[media] DocBook v4l: update bytesperline handling
authorHans Verkuil <hverkuil@xs4all.nl>
Wed, 11 Mar 2015 12:00:45 +0000 (09:00 -0300)
committerMauro Carvalho Chehab <mchehab@osg.samsung.com>
Thu, 2 Apr 2015 21:20:19 +0000 (18:20 -0300)
commit2ddb77bb1138dccb5067690e8696e991093e22c6
tree9fdf05e5488485493b5ac99ecdfe3c0c3f9993d4
parent3259aa57dba142c04da3f37e207f9cbcf30a76df
[media] DocBook v4l: update bytesperline handling

The documentation says that the bytesperline field in v4l2_pix_format refers
to the largest plane in the case of planar formats (i.e. multiple planes
stores in a single buffer).

For almost all planar formats the first plane is also the largest (or equal)
plane, except for two formats: V4L2_PIX_FMT_NV24/NV42. For this YUV 4:4:4
format the second chroma plane is twice the size of the first luma plane.

Looking at the very few drivers that support this format the bytesperline
value that they report is actually that of the first plane and not that
of the largest plane.

Rather than fixing the drivers it makes more sense to update the documentation
since it is very difficult to use the largest plane for this. You would have
to check what the format is in order to know to which plane bytesperline
belongs, which makes calculations much more difficult.

This patch updates the documentation accordingly.

Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Documentation/DocBook/media/v4l/pixfmt.xml
Documentation/DocBook/media/v4l/vidioc-g-fbuf.xml