요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
3
**********************
4
Standard Image Formats
5
**********************
7
In order to exchange images between drivers and applications, it is
8
necessary to have standard image data formats which both sides will
9
interpret the same way. V4L2 includes several such formats, and this
10
section is intended to be an unambiguous specification of the standard
11
image data formats in V4L2.
13
V4L2 drivers are not limited to these formats, however. Driver-specific
14
formats are possible. In that case the application may depend on a codec
15
to convert images to one of the standard formats when needed. But the
16
data can still be stored and retrieved in the proprietary format. For
17
example, a device may support a proprietary compressed format.
18
Applications can still capture and save the data in the compressed
19
format, saving much disk space, and later use a codec to convert the
20
images to the X Windows screen format when the video is to be displayed.
22
Even so, ultimately, some standard formats are needed, so the V4L2
23
specification would not be complete without well-defined standard
24
formats.
26
The V4L2 standard formats are mainly uncompressed formats. The pixels
27
are always arranged in memory from left to right, and from top to
28
bottom. The first byte of data in the image buffer is always for the
29
leftmost pixel of the topmost row. Following that is the pixel
30
immediately to its right, and so on until the end of the top row of
31
pixels. Following the rightmost pixel of the row there may be zero or
32
more bytes of padding to guarantee that each row of pixel data has a
33
certain alignment. Following the pad bytes, if any, is data for the
34
leftmost pixel of the second row from the top, and so on. The last row
35
has just as many pad bytes after it as the other rows.
37
In V4L2 each format has an identifier which looks like ``PIX_FMT_XXX``,
38
defined in the :ref:`videodev2.h <videodev>` header file. These
39
identifiers represent
40
:ref:`four character (FourCC) codes <v4l2-fourcc>` which are also
41
listed below, however they are not the same as those used in the Windows
42
world.
44
For some formats, data is stored in separate, discontiguous memory
45
buffers. Those formats are identified by a separate set of FourCC codes
46
and are referred to as "multi-planar formats". For example, a
47
:ref:`YUV422 <V4L2-PIX-FMT-YUV422M>` frame is normally stored in one
48
memory buffer, but it can also be placed in two or three separate
49
buffers, with Y component in one buffer and CbCr components in another
50
in the 2-planar version or with each component in its own buffer in the
51
3-planar case. Those sub-buffers are referred to as "*planes*".
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
표준 형식이 필요한 이유
1-24Driver와 application이 이미지를 교환하려면 양쪽이 같은 방식으로 해석하는 표준 data 형식이 필요합니다. V4L2는 여러 표준 형식을 포함하며 이 절은 그 형식을 모호하지 않게 규정합니다.
Driver는 이 표준 형식에만 제한되지 않고 전용 proprietary 형식을 제공할 수 있습니다. Application은 필요할 때 codec으로 표준 형식에 변환할 수 있으며 원본은 전용 형식 그대로 저장·복원할 수 있습니다. 예를 들어 proprietary compressed data를 그대로 capture해 disk 공간을 아끼고, 나중에 표시할 때 codec으로 X Window 화면 형식으로 바꿀 수 있습니다.
그럼에도 최종 상호 운용을 위해 잘 정의된 표준 형식이 필요하며, 이 정의 없이는 V4L2 명세가 완전할 수 없습니다.
.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
**********************
Standard Image Formats
**********************
In order to exchange images between drivers and applications, it is
necessary to have standard image data formats which both sides will
interpret the same way. V4L2 includes several such formats, and this
section is intended to be an unambiguous specification of the standard
image data formats in V4L2.
V4L2 drivers are not limited to these formats, however. Driver-specific
formats are possible. In that case the application may depend on a codec
to convert images to one of the standard formats when needed. But the
data can still be stored and retrieved in the proprietary format. For
example, a device may support a proprietary compressed format.
Applications can still capture and save the data in the compressed
format, saving much disk space, and later use a codec to convert the
images to the X Windows screen format when the video is to be displayed.
Even so, ultimately, some standard formats are needed, so the V4L2
specification would not be complete without well-defined standard
formats.행 순서·FourCC·multi-planar
25-51V4L2 표준 형식은 주로 uncompressed 형식입니다. Pixel은 memory에서 왼쪽에서 오른쪽, 위에서 아래 순서로 놓입니다. Image buffer의 첫 byte는 맨 위 행의 가장 왼쪽 pixel이고, 오른쪽으로 진행한 뒤 row alignment를 위한 0개 이상의 padding byte가 이어질 수 있습니다. Padding 뒤에는 다음 행의 왼쪽 pixel이 오며 마지막 행 뒤에도 다른 행과 같은 수의 padding byte가 붙습니다.
각 형식 identifier는 `videodev2.h`에 정의된 `PIX_FMT_XXX` 모양이며 FourCC code를 나타냅니다. 여기서 쓰는 FourCC는 Windows 생태계의 FourCC와 같지 않습니다.
일부 형식은 서로 떨어진 memory buffer에 data를 나누며 별도 FourCC로 식별되는 multi-planar 형식입니다. YUV422 frame은 일반적으로 buffer 하나에 놓지만 2-planar에서는 Y와 CbCr를 두 buffer에, 3-planar에서는 각 component를 자체 buffer에 둘 수 있습니다. 이 하위 buffer를 plane이라고 합니다.
맨 위·맨 왼쪽 pixel→같은 행을 오른쪽으로 진행→row alignment padding→다음 행의 맨 왼쪽 pixel→마지막 행 뒤 동일 padding
Padding을 포함해 모든 행이 같은 stride를 유지합니다.
항목설명
Single-planarY와 Cb/Cr component를 memory buffer 하나에 저장
2-planarY는 첫 buffer, interleaved CbCr는 둘째 buffer
3-planarY, Cb, Cr component마다 별도 buffer
YUV422 예시로 plane의 의미를 구분합니다.
The V4L2 standard formats are mainly uncompressed formats. The pixels
are always arranged in memory from left to right, and from top to
bottom. The first byte of data in the image buffer is always for the
leftmost pixel of the topmost row. Following that is the pixel
immediately to its right, and so on until the end of the top row of
pixels. Following the rightmost pixel of the row there may be zero or
more bytes of padding to guarantee that each row of pixel data has a
certain alignment. Following the pad bytes, if any, is data for the
leftmost pixel of the second row from the top, and so on. The last row
has just as many pad bytes after it as the other rows.
In V4L2 each format has an identifier which looks like ``PIX_FMT_XXX``,
defined in the :ref:`videodev2.h <videodev>` header file. These
identifiers represent
:ref:`four character (FourCC) codes <v4l2-fourcc>` which are also
listed below, however they are not the same as those used in the Windows
world.
For some formats, data is stored in separate, discontiguous memory
buffers. Those formats are identified by a separate set of FourCC codes
and are referred to as "multi-planar formats". For example, a
:ref:`YUV422 <V4L2-PIX-FMT-YUV422M>` frame is normally stored in one
memory buffer, but it can also be placed in two or three separate
buffers, with Y component in one buffer and CbCr components in another
in the 2-planar version or with each component in its own buffer in the
3-planar case. Those sub-buffers are referred to as "*planes*".
요약·해설
pixfmt-intro.rst:1-51표준 형식은 driver와 application의 공통 해석을 보장하며 pixel은 좌상단부터 row 순서로 놓이고 필요하면 component별 plane으로 분리됩니다.