summaryrefslogtreecommitdiffstats
path: root/Documentation/DocBook/media/v4l/pixfmt.xml
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2012-10-12 12:39:17 +0900
committerLinus Torvalds <torvalds@linux-foundation.org>2012-10-12 12:39:17 +0900
commit4f1cd91497774488ed16119ec3f54b3daf1561de (patch)
tree190ed2b2ecbbfe371740cf6e29d9aefd25ecc3e3 /Documentation/DocBook/media/v4l/pixfmt.xml
parent759e00b8a8883be28357426206d2f1752827e38a (diff)
parentbf3b202b41999f88f091632f13842b7234bd58b7 (diff)
downloadtalos-op-linux-4f1cd91497774488ed16119ec3f54b3daf1561de.tar.gz
talos-op-linux-4f1cd91497774488ed16119ec3f54b3daf1561de.zip
Merge branch 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
Pull second set of media updates from Mauro Carvalho Chehab: "Despite its size, most of the stuff here is trivial. This series contains: - s5p-mfc: additions at the driver and at the core to support H.264 hardware codec; - Some improvements at s5p and davinci embedded drivers; - Some V4L2 compliance fixes applied on a few drivers; - Several random trivial patches, including several fixes and a few new board support additions; Notes: 1) Some Exynos media patches were dependent on some -arm fixes that got merged on changeset 782cd9e. That's why this pull request is based that changeset. 2) As promised, I reviewed the pending VB2 DMABUF series. While setting a test environment, it was noticed that the upstream support for Samsung Exynos 4 boards (smdk310 and Origen) are broken upstream, likely due to regressions: both defconfigs are wrong and regulator settings for both boards are broken. That, allied with some bug at the dummy regulator driver, causes OOPSes during boot time. Long story short: even fixing the above, the proposed patches OOPSed when running the DMABUF test. Not sure yet if the OOPSes are due to some other undetected regressions, or due to some bug on the patches. Due to the above, DMABUF patches for vb2 got NACKed for 3.7." * 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media: (109 commits) [media] m5mols: Add missing #include <linux/sizes.h> [media] stk1160: Add support for S-Video input Revert "[media] omap3isp: Replace cpu_is_omap3630() with ISP revision check" [media] dvb: LNA implementation changes [media] v4l2-ioctl: fix W=1 warnings [media] v4l2-ioctl: add blocks check for VIDIOC_SUBDEV_G/S_EDID [media] omap3isp: Fix compilation error in ispreg.h [media] rc-msi-digivox-ii: Add full scan keycodes [media] cx25821: testing the wrong variable [media] tda18271-common: hold the I2C adapter during write transfers [media] ds3000: add module parameter to force firmware upload [media] drivers/media: Remove unnecessary semicolon [media] winbond: remove space from driver name [media] iguanair: cannot send data from the stack [media] omap3isp: Replace cpu_is_omap3630() with ISP revision check [media] dvb-usb: print small buffers via %*ph [media] uvc: Add return code check at vb2_queue_init() [media] em28xx: Replace memcpy with struct assignment [media] bt8xx: Add video4linux control V4L2_CID_COLOR_KILLER [media] mem2mem_testdev: Use devm_kzalloc() in probe ... Conflicts: arch/arm/mach-davinci/include/mach/da8xx.h
Diffstat (limited to 'Documentation/DocBook/media/v4l/pixfmt.xml')
-rw-r--r--Documentation/DocBook/media/v4l/pixfmt.xml38
1 files changed, 38 insertions, 0 deletions
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml
index 1ddbfabe3195..bf94f417592c 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -758,6 +758,11 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
<entry>'AVC1'</entry>
<entry>H264 video elementary stream without start codes.</entry>
</row>
+ <row id="V4L2-PIX-FMT-H264-MVC">
+ <entry><constant>V4L2_PIX_FMT_H264_MVC</constant></entry>
+ <entry>'MVC'</entry>
+ <entry>H264 MVC video elementary stream.</entry>
+ </row>
<row id="V4L2-PIX-FMT-H263">
<entry><constant>V4L2_PIX_FMT_H263</constant></entry>
<entry>'H263'</entry>
@@ -793,6 +798,11 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
<entry>'VC1L'</entry>
<entry>VC1, SMPTE 421M Annex L compliant stream.</entry>
</row>
+ <row id="V4L2-PIX-FMT-VP8">
+ <entry><constant>V4L2_PIX_FMT_VP8</constant></entry>
+ <entry>'VP8'</entry>
+ <entry>VP8 video elementary stream.</entry>
+ </row>
</tbody>
</tgroup>
</table>
@@ -996,6 +1006,34 @@ the other bits are set to 0.</entry>
<entry>Old 6-bit greyscale format. Only the most significant 6 bits of each byte are used,
the other bits are set to 0.</entry>
</row>
+ <row id="V4L2-PIX-FMT-S5C-UYVY-JPG">
+ <entry><constant>V4L2_PIX_FMT_S5C_UYVY_JPG</constant></entry>
+ <entry>'S5CI'</entry>
+ <entry>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.
+<para>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.</para>
+<para>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. </para>
+</entry>
+ </row>
</tbody>
</tgroup>
</table>
OpenPOWER on IntegriCloud