From d2642485d694027ad8c918844cee0e547cc11bcb Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Thu, 16 Feb 2012 14:23:54 -0300 Subject: [media] V4L: Add V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 media bus format This patch adds media bus pixel code for the interleaved JPEG/UYVY image format used by S5C73MX Samsung cameras. This interleaved image data is transferred on MIPI-CSI2 bus as User Defined Byte-based Data. It also defines an experimental vendor and device specific media bus formats section and adds related DocBook documentation. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/compat.xml | 4 ++ Documentation/DocBook/media/v4l/subdev-formats.xml | 44 ++++++++++++++++++++++ 2 files changed, 48 insertions(+) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index c6ae4c9d0e0c..4fdf6b562d1c 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2582,6 +2582,10 @@ ioctls. Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl. + + Vendor and device specific media bus pixel formats. + . + diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532ebbbbe..a0a936455fae 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -2565,5 +2565,49 @@ + +
+ Vendor and Device Specific Formats + + + Experimental + This is an experimental +interface and may change in the future. + + + This section lists complex data formats that are either vendor or + device specific. + + + The following table lists the existing vendor and device specific + formats. + + + Vendor and device specific formats + + + + + + + Identifier + Code + Comments + + + + + V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 + 0x5001 + + Interleaved raw UYVY and JPEG image format with embedded + meta-data used by Samsung S3C73MX camera sensors. + + + + +
+
+ -- cgit v1.2.3 From c3010097a79fc741d27b07e068598fd9468ca41f Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Wed, 3 Oct 2012 07:44:53 -0300 Subject: [media] V4L: Add V4L2_PIX_FMT_S5C_UYVY_JPG fourcc definition This patch adds definition of the Samsung S5C73M3 camera specific image format. V4L2_PIX_FMT_S5C_UYVY_JPG is a two-planar format, the first plane contains interleaved UYVY and JPEG data followed by meta-data. The second plane contains additional meta-data needed for extracting JPEG and UYVY data stream from the first plane. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/pixfmt.xml | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index 1ddbfabe3195..fce143726fd5 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -996,6 +996,34 @@ the other bits are set to 0. Old 6-bit greyscale format. Only the most significant 6 bits of each byte are used, the other bits are set to 0. + + V4L2_PIX_FMT_S5C_UYVY_JPG + 'S5CI' + Two-planar format used by Samsung S5C73MX cameras. The +first plane contains interleaved JPEG and UYVY image data, followed by meta data +in form of an array of offsets to the UYVY data blocks. The actual pointer array +follows immediately the interleaved JPEG/UYVY data, the number of entries in +this array equals the height of the UYVY image. Each entry is a 4-byte unsigned +integer in big endian order and it's an offset to a single pixel line of the +UYVY image. The first plane can start either with JPEG or UYVY data chunk. The +size of a single UYVY block equals the UYVY image's width multiplied by 2. The +size of a JPEG chunk depends on the image and can vary with each line. +The second plane, at an offset of 4084 bytes, contains a 4-byte offset to +the pointer array in the first plane. This offset is followed by a 4-byte value +indicating size of the pointer array. All numbers in the second plane are also +in big endian order. Remaining data in the second plane is undefined. The +information in the second plane allows to easily find location of the pointer +array, which can be different for each frame. The size of the pointer array is +constant for given UYVY image height. +In order to extract UYVY and JPEG frames an application can initially set +a data pointer to the start of first plane and then add an offset from the first +entry of the pointers table. Such a pointer indicates start of an UYVY image +pixel line. Whole UYVY line can be copied to a separate buffer. These steps +should be repeated for each line, i.e. the number of entries in the pointer +array. Anything what's in between the UYVY lines is JPEG data and should be +concatenated to form the JPEG stream. + + -- cgit v1.2.3 From 5ebef0fbe0f72fa911088800c5d0bc7a872c35de Mon Sep 17 00:00:00 2001 From: "Lad, Prabhakar" Date: Mon, 1 Oct 2012 08:17:36 -0300 Subject: [media] media: v4l2-ctrls: add control for test pattern add V4L2_CID_TEST_PATTERN of type menu, which determines the internal test pattern selected by the device. Signed-off-by: Lad, Prabhakar Signed-off-by: Manjunath Hadli Acked-by: Sakari Ailus Acked-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/controls.xml | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 272a5f718509..a84a08ca51dc 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -4267,6 +4267,16 @@ interface and may change in the future. pixels / second. + + V4L2_CID_TEST_PATTERN + menu + + + Some capture/display/sensor devices have + the capability to generate test pattern images. These hardware + specific test patterns can be used to test if a device is working + properly. + -- cgit v1.2.3 From e3b1b4e732e18befcfa428bac1c487f681fbc36a Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 19 Sep 2012 11:14:39 -0300 Subject: [media] DocBook: various updates w.r.t. v4l2_buffer and multiplanar Clarify the behavior of v4l2_buffer in the multiplanar case, including fixing a false statement: you can't set m.planes to NULL when calling DQBUF. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/io.xml | 6 ++++-- Documentation/DocBook/media/v4l/vidioc-qbuf.xml | 3 +-- Documentation/DocBook/media/v4l/vidioc-querybuf.xml | 11 +++++++---- 3 files changed, 12 insertions(+), 8 deletions(-) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index 97f785add841..b5d1cbdc558b 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -677,8 +677,10 @@ memory, set by the application. See for details. length Size of the buffer (not the payload) in bytes for the - single-planar API. For the multi-planar API should contain the - number of elements in the planes array. + single-planar API. For the multi-planar API the application sets + this to the number of elements in the planes + array. The driver will fill in the actual number of valid elements in + that array. diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml index 6a821a65a5ae..2d37abefce13 100644 --- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml @@ -121,8 +121,7 @@ remaining fields or returns an error code. The driver may also set field. It indicates a non-critical (recoverable) streaming error. In such case the application may continue as normal, but should be aware that data in the dequeued buffer might be corrupted. When using the multi-planar API, the -planes array does not have to be passed; the m.planes -member must be set to NULL in that case. +planes array must be passed in as well. By default VIDIOC_DQBUF blocks when no buffer is in the outgoing queue. When the diff --git a/Documentation/DocBook/media/v4l/vidioc-querybuf.xml b/Documentation/DocBook/media/v4l/vidioc-querybuf.xml index 6e414d7b6df7..a597155c052d 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querybuf.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querybuf.xml @@ -48,8 +48,8 @@ Description - This ioctl is part of the memory -mapping I/O method. It can be used to query the status of a + This ioctl is part of the streaming + I/O method. It can be used to query the status of a buffer at any time after buffers have been allocated with the &VIDIOC-REQBUFS; ioctl. @@ -71,6 +71,7 @@ the structure. In the flags field the V4L2_BUF_FLAG_MAPPED, +V4L2_BUF_FLAG_PREPARED, V4L2_BUF_FLAG_QUEUED and V4L2_BUF_FLAG_DONE flags will be valid. The memory field will be set to the current @@ -79,8 +80,10 @@ contains the offset of the buffer from the start of the device memory, the length field its size. For the multi-planar API, fields m.mem_offset and length in the m.planes -array elements will be used instead. The driver may or may not set the remaining -fields and flags, they are meaningless in this context. +array elements will be used instead and the length +field of &v4l2-buffer; is set to the number of filled-in array elements. +The driver may or may not set the remaining fields and flags, they are +meaningless in this context. The v4l2_buffer structure is specified in . -- cgit v1.2.3 From 4d08f670e63200cc092724de8c95f81df606b1a5 Mon Sep 17 00:00:00 2001 From: Arun Kumar K Date: Wed, 3 Oct 2012 22:19:05 -0300 Subject: [media] v4l: Add fourcc definitions for new formats Add the following new fourcc definitions, for multiplanar YCbCr: V4L2_PIX_FMT_NV21M, V4L2_PIX_FMT_NV12MT_16X16 and compressed formats: V4L2_PIX_FMT_H264_MVC, V4L2_PIX_FMT_VP8. Signed-off-by: Jeongtae Park Signed-off-by: Naveen Krishna Chatradhi Signed-off-by: Arun Kumar K Acked-by: Kamil Debski Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 17 ++++++++++++----- Documentation/DocBook/media/v4l/pixfmt.xml | 10 ++++++++++ 2 files changed, 22 insertions(+), 5 deletions(-) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml index 5274c24d11e0..a990b34d911a 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml @@ -1,11 +1,13 @@ - + - V4L2_PIX_FMT_NV12M ('NM12') + V4L2_PIX_FMT_NV12M ('NM12'), V4L2_PIX_FMT_NV21M ('NM21'), V4L2_PIX_FMT_NV12MT_16X16 &manvol; - V4L2_PIX_FMT_NV12M - Variation of V4L2_PIX_FMT_NV12 with planes + V4L2_PIX_FMT_NV12M + V4L2_PIX_FMT_NV21M + V4L2_PIX_FMT_NV12MT_16X16 + Variation of V4L2_PIX_FMT_NV12 and V4L2_PIX_FMT_NV21 with planes non contiguous in memory. @@ -22,7 +24,12 @@ The CbCr plane is the same width, in bytes, as the Y plane (and of the image), but is half as tall in pixels. Each CbCr pair belongs to four pixels. For example, Cb0/Cr0 belongs to Y'00, Y'01, -Y'10, Y'11. +Y'10, Y'11. +V4L2_PIX_FMT_NV12MT_16X16 is the tiled version of +V4L2_PIX_FMT_NV12M with 16x16 macroblock tiles. Here pixels +are arranged in 16x16 2D tiles and tiles are arranged in linear order in memory. +V4L2_PIX_FMT_NV21M is the same as V4L2_PIX_FMT_NV12M +except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte. V4L2_PIX_FMT_NV12M is intended to be used only in drivers and applications that support the multi-planar API, diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml index fce143726fd5..bf94f417592c 100644 --- a/Documentation/DocBook/media/v4l/pixfmt.xml +++ b/Documentation/DocBook/media/v4l/pixfmt.xml @@ -758,6 +758,11 @@ extended control V4L2_CID_MPEG_STREAM_TYPE, see 'AVC1' H264 video elementary stream without start codes. + + V4L2_PIX_FMT_H264_MVC + 'MVC' + H264 MVC video elementary stream. + V4L2_PIX_FMT_H263 'H263' @@ -793,6 +798,11 @@ extended control V4L2_CID_MPEG_STREAM_TYPE, see 'VC1L' VC1, SMPTE 421M Annex L compliant stream. + + V4L2_PIX_FMT_VP8 + 'VP8' + VP8 video elementary stream. + -- cgit v1.2.3 From 2e81dde94316dfaa19f0b6f9d4131ef7eaf124a3 Mon Sep 17 00:00:00 2001 From: Arun Kumar K Date: Wed, 3 Oct 2012 22:19:06 -0300 Subject: [media] v4l: Add control definitions for new H264 encoder features New controls are added for supporting H264 encoding features like: - MVC frame packing, - flexible macroblock ordering, - arbitrary slice ordering, - hierarchical coding. Signed-off-by: Jeongtae Park Signed-off-by: Naveen Krishna Chatradhi Signed-off-by: Arun Kumar K Acked-by: Kamil Debski Signed-off-by: Sylwester Nawrocki Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/controls.xml | 268 ++++++++++++++++++++++++++- 1 file changed, 267 insertions(+), 1 deletion(-) (limited to 'Documentation/DocBook') diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index a84a08ca51dc..7fe5be1d3bbb 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -1586,7 +1586,6 @@ frame counter of the frame that is currently displayed (decoded). This value is the decoder is started. - V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE  @@ -2269,6 +2268,14 @@ encoder or editing process may produce.". Applicable to the MPEG1, MPEG2, MPEG4 encoders. + + + V4L2_CID_MPEG_VIDEO_VBV_DELAY  + integer + Sets the initial delay in milliseconds for +VBV buffer control. + + V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE  @@ -2334,6 +2341,265 @@ Applicable to the MPEG4 decoder. vop_time_increment value for MPEG4. Applicable to the MPEG4 encoder. + + + V4L2_CID_MPEG_VIDEO_H264_SEI_FRAME_PACKING  + boolean + + Enable generation of frame packing supplemental enhancement information in the encoded bitstream. +The frame packing SEI message contains the arrangement of L and R planes for 3D viewing. Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_SEI_FP_CURRENT_FRAME_0  + boolean + + Sets current frame as frame0 in frame packing SEI. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE  + enum v4l2_mpeg_video_h264_sei_fp_arrangement_type + + Frame packing arrangement type for H264 SEI. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_CHEKERBOARD  + Pixels are alternatively from L and R. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_COLUMN  + L and R are interlaced by column. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_ROW  + L and R are interlaced by row. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_SIDE_BY_SIDE  + L is on the left, R on the right. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TOP_BOTTOM  + L is on top, R on bottom. + + + V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TEMPORAL  + One view per frame. + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO  + boolean + + Enables flexible macroblock ordering in the encoded bitstream. It is a technique +used for restructuring the ordering of macroblocks in pictures. Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE  + enum v4l2_mpeg_video_h264_fmo_map_type + + When using FMO, the map type divides the image in different scan patterns of macroblocks. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_INTERLEAVED_SLICES  + Slices are interleaved one after other with macroblocks in run length order. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_SCATTERED_SLICES  + Scatters the macroblocks based on a mathematical function known to both encoder and decoder. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_FOREGROUND_WITH_LEFT_OVER  + Macroblocks arranged in rectangular areas or regions of interest. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_BOX_OUT  + Slice groups grow in a cyclic way from centre to outwards. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_RASTER_SCAN  + Slice groups grow in raster scan pattern from left to right. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_WIPE_SCAN  + Slice groups grow in wipe scan pattern from top to bottom. + + + V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_EXPLICIT  + User defined map type. + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO_SLICE_GROUP  + integer + + Number of slice groups in FMO. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO_CHANGE_DIRECTION  + enum v4l2_mpeg_video_h264_fmo_change_dir + + Specifies a direction of the slice group change for raster and wipe maps. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_RIGHT  + Raster scan or wipe right. + + + V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_LEFT  + Reverse raster scan or wipe left. + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO_CHANGE_RATE  + integer + + Specifies the size of the first slice group for raster and wipe map. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_FMO_RUN_LENGTH  + integer + + Specifies the number of consecutive macroblocks for the interleaved map. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_ASO  + boolean + + Enables arbitrary slice ordering in encoded bitstream. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_ASO_SLICE_ORDER  + integer + Specifies the slice order in ASO. Applicable to the H264 encoder. +The supplied 32-bit integer is interpreted as follows (bit +0 = least significant bit): + + + + + + Bit 0:15 + Slice ID + + + Bit 16:32 + Slice position or order + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING  + boolean + + Enables H264 hierarchical coding. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_TYPE  + enum v4l2_mpeg_video_h264_hierarchical_coding_type + + Specifies the hierarchical coding type. +Applicable to the H264 encoder. +Possible values are: + + + + + + V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_B  + Hierarchical B coding. + + + V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_P  + Hierarchical P coding. + + + + + + + + V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER  + integer + + Specifies the number of hierarchical coding layers. +Applicable to the H264 encoder. + + + + + V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP  + integer + Specifies a user defined QP for each layer. Applicable to the H264 encoder. +The supplied 32-bit integer is interpreted as follows (bit +0 = least significant bit): + + + + + + Bit 0:15 + QP value + + + Bit 16:32 + Layer number + + + + + -- cgit v1.2.3