Re: [virtio-dev] Re: [RFC PATCH v6] virtio-video: Add virtio video device specification

[Alexander Gordeev <alexander.gordeev@opensynergy.com>]

On 20.12.22 18:39, Cornelia Huck wrote:
>>>>> +\subsubsection{Image formats}\label{sec:Device Types / Video Device / Supported formats / Image formats}
>>>>> +
>>>>> +The fourcc code of each supported image format is given, as well as its
>>>>> +number of planes, physical buffers, and eventual subsampling.
>>>>> +
>>>>> +\begin{description}
>>>>> +\item[\field{RGB3}]
>>>>> +one RGB plane where each component takes one byte, i.e.~3 bytes per
>>>>> +pixel.
>>>>> +\item[\field{NV12}]
>>>>> +one Y plane followed by interleaved U and V data, in a single buffer.
>>>>> +4:2:0 subsampling.
>>>>> +\item[\field{NV12}]
>>>>> +same as \field{NV12} but using two separate buffers for the Y and UV
>>>>> +planes.
>>>> s/NV12/NM12/ ?
>>>>
>>>>
>>>>> +\item[\field{YU12}]
>>>>> +one Y plane followed by one Cb plane, followed by one Cr plane, in a
>>>>> +single buffer. 4:2:0 subsampling.
>>>>> +\item[\field{YM12}]
>>>>> +same as \field{YU12} but using three separate buffers for the Y, U and V
>>>>> +planes.
>>>>> +\end{description}
>>>> This looks like V4L2 formats. Maybe add a V4L2 reference? At least the
>>>> V4L2 documentation has a nice description of exact plane layouts.
>>>> Otherwise it would be nice to have these layouts in the spec IMO.
>>> Ah, so this is all V4L2? It looks like we really want to refer to the
>>> existing V4L2 headers (like we already do for FUSE in the virtiofs
>>> case). Are those headers sufficient to specify the formats, or do we
>>> need anything else?
>> Yes, these fourcc code seem to come from V4L2:
>> https://docs.kernel.org/userspace-api/media/v4l/pixfmt-yuv-planar.html
>> I also think we want to have a reference to V4L2 in the spec here, because:
>> 1. V4L2 docs have the nice component/plane layouts that help convert or
>> match these format definitions with other APIs.
>> 2. These fourcc codes are not used anywhere else except in V4L2. I think
>> this is the only place, that distinguishes coontiguous and non
>> contiguous buffers with a fourcc code. So without a reference this may
>> look quite weird. With a reference this looks logical, because I guess
>> any virtio video driver for a Linux guest would naturally implement V4L2.
> Maybe the best way to handle this would be to link to both the UAPI
> header file (via Linus' tree on kernel.org, as we do for FUSE), and to
> the .rst file(s) that describe what this all means (probably also via
> kernel.org). The header file would definitely be a normative reference;
> not sure whether the .rst files would be normative or non-normative, but
> we can figure that out later. That's certainly better than trying to
> replicate existing definitions and explanations.

I like the plan. I also think it is better to reference the definitions
and explanations, not replicate them. Thanks!

--
Alexander Gordeev
Senior Software Engineer

OpenSynergy GmbH
Rotherstr. 20, 10245 Berlin

Phone: +49 30 60 98 54 0 - 88
Fax: +49 (30) 60 98 54 0 - 99
EMail: alexander.gordeev@opensynergy.com

www.opensynergy.com

Handelsregister/Commercial Registry: Amtsgericht Charlottenburg, HRB 108616B
Geschäftsführer/Managing Director: Régis Adjamah


Please mind our privacy notice<https://www.opensynergy.com/datenschutzerklaerung/privacy-notice-for-business-partners-pursuant-to-article-13-of-the-general-data-protection-regulation-gdpr/> pursuant to Art. 13 GDPR. // Unsere Hinweise zum Datenschutz gem. Art. 13 DSGVO finden Sie hier.<https://www.opensynergy.com/de/datenschutzerklaerung/datenschutzhinweise-fuer-geschaeftspartner-gem-art-13-dsgvo/>