OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


On Mon, Dec 19 2022, Alexander Gordeev <alexander.gordeev@opensynergy.com> wrote:

> Hello Alexandre,
>
> Thanks for the update. Please check my comments below.
> I'm new to the virtio video spec development, so I may lack some
> historic perspective. I would gladly appreciate pointing me to some
> older emails explaining decisions, that I might not understand. I hope
> to read through all of them later. Overall I have a lot of experience in
> the video domain and in virtio video device development in Opsy, so I
> hope, that my comments are relevant and useful.

Thank you for commenting! I know the virtio spec, but I'm not familiar
with the video part, so your feedback is highly appreciated :)

Prior discussions should be in the virtio-dev archives; at least v3
(https://lists.oasis-open.org/archives/virtio-dev/202002/msg00002.html)
and v4
(https://lists.oasis-open.org/archives/virtio-dev/202006/msg00072.html)
seem to have gotten some feedback.

[A note to Alexandre: You'll want to send your patches to virtio-comment
as well as virtio-dev; virtio-comment is for commenting on the spec
including proposing updates, while virtio-dev is for discussing virtio
development. Yes, I know that we haven't always been strict about that
in the past.]

>
> On 08.12.22 08:23, Alexandre Courbot 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?



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]