V4L2 Codec

V4L2 Codec

Yami V4L2 wrapper targets for Chrome video codec acceleration, not Camera. https://github.com/halleyzhao/yami-share/blob/master/Yami_V4L2_wrapper_for_Chrome.pdf

V4L2 Codec uses V4L2 interface to define decode/encode APIs.
There is V4L2 input device as camera, v4l2 output device for 2D rendering. when we combine these two devices together, data flows in and out; it becomes codec interface. V4L2 interface comes with Linux in nature, so, V4L2 interface can be widely used.

comparing with other codec standard (like OMXIL):

• V4L2 is simple since it focuses on codec only (not necessary for the concept of framework)
• The standard itself is thorough and stable, since it almost extends nothing of V4l2 spec.
• the threads of V4L2 codec is a little complex, there are at least four threads:
• two threads for v4l2 interface: one for device pool, one for device operation (deque, enque etc)
• two threads are internal worker to drive data input and output respectively.

V4L2 wrapper targets Chrome
-- uses V4L2 as codec interface/standard for Chrome media
On Android, there is "media codec" interface from StageFright; on Windows, there is DXVA; similar does MAC OS. These interfaces divide work clearly between chrome and media infrastructure.
However, There is no such interface on Linux/ChromeOS, it makes the situation pretty bad: Google created the VAVDA for VAAPI, Nvidia proposed OMX-VxA, Samsung uses V4L2 interface; there is also some internal implementation as mediasdk-VEA, yami-VxA. We don't need so many implementation, but a standard interface to follow. [here VDA means to video decode acceleration interface, VEA means to video encode acceleration interface; and VXA for both] Now, Nvidia follows v4l2 interface, I think intel need follow it as well. So that, Chrome/Google is required to support one interface only(for Linux/ChromeOs), and Intel keeps the platform differentiation in its codec library.