Re: [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification
I shared PDF version of this RFC on Google drive: https://drive.google.com/drive/folders/1hed-mTVI7dj0M_iab4DTfx5kPMLoeX8R On Thu, Sep 19, 2019 at 8:15 PM Keiichi Watanabe wrote: > > Hi Hans, > Thank you for your feedback. > > On Thu, Sep 19, 2019 at 6:53 PM Hans Verkuil wrote: > > > > Hi Keiichi, > > > > On 9/19/19 11:34 AM, Keiichi Watanabe wrote: > > > [Resending because of some issues with sending to virtio-dev. Sorry for > > > the noise.] > > > > > > This patch proposes virtio specification for new virtio video decode > > > device. > > > This device provides the functionality of hardware accelerated video > > > decoding from encoded video contents provided by the guest into frame > > > buffers accessible by the guest. > > > > > > We have prototype implementation for VMs on Chrome OS: > > > * virtio-vdec device in crosvm [1] > > > * virtio-vdec driver in Linux kernel v4.19 [2] > > > - This driver follows V4L2 stateful video decoder API [3]. > > > > > > Our prototype implementation uses [4], which allows the virtio-vdec > > > device to use buffers allocated by virtio-gpu device. > > > > > > Any feedback would be greatly appreciated. Thank you. > > > > I'm not a virtio expert, but as I understand it the virtio-vdec driver > > looks like a regular v4l2 stateful decoder devices to the guest, while > > on the host there is a driver (or something like that) that maps the > > virtio-vdec requests to the actual decoder hardware, right? > > > > What concerns me a bit (but there may be good reasons for this) is that > > this virtio driver is so specific for stateful decoders. > > > > We aim to design a platform-independent interface. The virtio-vdec protocol > should be designed to be workable regardless of APIs, OS, and platforms > eventually. > > Our prototype virtio-vdec device translates the virtio-vdec protocol to a > Chrome's video decode acceleration API instead of talking to hardware decoders > directly. This Chrome's API is an abstract layer for multiple decoder APIs on > Linux such as V4L2 stateful, V4L2 slice, Intel's VAAPI. > > That is to say the guest driver translates V4L2 stateful API to virtio-vdec > and > the host device translates virtio-vdec to Chrome's API. So, I could say that > this is already more general than a mere V4L2 stateful API wrapper, at least. > > I'd appreciate if you could let me know some parts are still specific to V4L2. > > > > How does this scale to stateful encoders? Stateless codecs? Other M2M > > devices like deinterlacers or colorspace converters? What about webcams? > > > > We're designing virtio protocol for encoder as well, but we are at an early > stage. So, I'm not sure if we should/can handle decoder and encoder in one > protocol. I don't have any plans for other media devices. > > > > In other words, I would like to see a bigger picture here. > > > > Note that there is also an effort for Xen to expose webcams to a guest: > > > > https://www.spinics.net/lists/linux-media/msg148629.html > > > > Good to know. Thanks. > > > This may or may not be of interest. This was an RFC only, and I haven't > > seen any follow-up patches with actual code. > > > > There will be a half-day meeting of media developers during the ELCE > > in October about codecs. I know Alexandre and Tomasz will be there. > > It might be a good idea to discuss this in more detail if needed. > > > > Sounds good. They are closely working with me. > > Regards, > Keiichi > > > Regards, > > > > Hans > > > > > > > > [1] > > > https://chromium-review.googlesource.com/q/hashtag:%22virtio-vdec-device%22+(status:open%20OR%20status:merged) > > > [2] > > > https://chromium-review.googlesource.com/q/hashtag:%22virtio-vdec-driver%22+(status:open%20OR%20status:merged) > > > [3] https://hverkuil.home.xs4all.nl/codec-api/uapi/v4l/dev-decoder.html > > > (to be merged to Linux 5.4) > > > [4] https://lkml.org/lkml/2019/9/12/157 > > > > > > Signed-off-by: Keiichi Watanabe > > > --- > > > content.tex | 1 + > > > virtio-vdec.tex | 750 > > > 2 files changed, 751 insertions(+) > > > create mode 100644 virtio-vdec.tex > > > > > > diff --git a/content.tex b/content.tex > > > index 37a2190..b57d4a9 100644 > > > --- a/content.tex > > > +++ b/content.tex >
Re: [PATCH] [RFC RESEND] vdec: Add virtio video decode device specification
Hi Hans,
Thank you for your feedback.
On Thu, Sep 19, 2019 at 6:53 PM Hans Verkuil wrote:
>
> Hi Keiichi,
>
> On 9/19/19 11:34 AM, Keiichi Watanabe wrote:
> > [Resending because of some issues with sending to virtio-dev. Sorry for the
> > noise.]
> >
> > This patch proposes virtio specification for new virtio video decode
> > device.
> > This device provides the functionality of hardware accelerated video
> > decoding from encoded video contents provided by the guest into frame
> > buffers accessible by the guest.
> >
> > We have prototype implementation for VMs on Chrome OS:
> > * virtio-vdec device in crosvm [1]
> > * virtio-vdec driver in Linux kernel v4.19 [2]
> > - This driver follows V4L2 stateful video decoder API [3].
> >
> > Our prototype implementation uses [4], which allows the virtio-vdec
> > device to use buffers allocated by virtio-gpu device.
> >
> > Any feedback would be greatly appreciated. Thank you.
>
> I'm not a virtio expert, but as I understand it the virtio-vdec driver
> looks like a regular v4l2 stateful decoder devices to the guest, while
> on the host there is a driver (or something like that) that maps the
> virtio-vdec requests to the actual decoder hardware, right?
>
> What concerns me a bit (but there may be good reasons for this) is that
> this virtio driver is so specific for stateful decoders.
>
We aim to design a platform-independent interface. The virtio-vdec protocol
should be designed to be workable regardless of APIs, OS, and platforms
eventually.
Our prototype virtio-vdec device translates the virtio-vdec protocol to a
Chrome's video decode acceleration API instead of talking to hardware decoders
directly. This Chrome's API is an abstract layer for multiple decoder APIs on
Linux such as V4L2 stateful, V4L2 slice, Intel's VAAPI.
That is to say the guest driver translates V4L2 stateful API to virtio-vdec and
the host device translates virtio-vdec to Chrome's API. So, I could say that
this is already more general than a mere V4L2 stateful API wrapper, at least.
I'd appreciate if you could let me know some parts are still specific to V4L2.
> How does this scale to stateful encoders? Stateless codecs? Other M2M
> devices like deinterlacers or colorspace converters? What about webcams?
>
We're designing virtio protocol for encoder as well, but we are at an early
stage. So, I'm not sure if we should/can handle decoder and encoder in one
protocol. I don't have any plans for other media devices.
> In other words, I would like to see a bigger picture here.
>
> Note that there is also an effort for Xen to expose webcams to a guest:
>
> https://www.spinics.net/lists/linux-media/msg148629.html
>
Good to know. Thanks.
> This may or may not be of interest. This was an RFC only, and I haven't
> seen any follow-up patches with actual code.
>
> There will be a half-day meeting of media developers during the ELCE
> in October about codecs. I know Alexandre and Tomasz will be there.
> It might be a good idea to discuss this in more detail if needed.
>
Sounds good. They are closely working with me.
Regards,
Keiichi
> Regards,
>
> Hans
>
> >
> > [1]
> > https://chromium-review.googlesource.com/q/hashtag:%22virtio-vdec-device%22+(status:open%20OR%20status:merged)
> > [2]
> > https://chromium-review.googlesource.com/q/hashtag:%22virtio-vdec-driver%22+(status:open%20OR%20status:merged)
> > [3] https://hverkuil.home.xs4all.nl/codec-api/uapi/v4l/dev-decoder.html (to
> > be merged to Linux 5.4)
> > [4] https://lkml.org/lkml/2019/9/12/157
> >
> > Signed-off-by: Keiichi Watanabe
> > ---
> > content.tex | 1 +
> > virtio-vdec.tex | 750
> > 2 files changed, 751 insertions(+)
> > create mode 100644 virtio-vdec.tex
> >
> > diff --git a/content.tex b/content.tex
> > index 37a2190..b57d4a9 100644
> > --- a/content.tex
> > +++ b/content.tex
> > @@ -5682,6 +5682,7 @@ \subsubsection{Legacy Interface: Framing
> > Requirements}\label{sec:Device
> > \input{virtio-input.tex}
> > \input{virtio-crypto.tex}
> > \input{virtio-vsock.tex}
> > +\input{virtio-vdec.tex}
> >
> > \chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
> >
> > diff --git a/virtio-vdec.tex b/virtio-vdec.tex
> > new file mode 100644
> > index 000..d117129
> > --- /dev/null
> > +++ b/virtio-vdec.tex
> > @@ -0,0 +1,750 @@
> > +\section{Video Decode Device}
> > +\label{sec:Device Types / Video Decode Device}
> > +
> > +virtio-vdec is a virtio based video
[PATCH] [RFC RESEND] vdec: Add virtio video decode device specification
[Resending because of some issues with sending to virtio-dev. Sorry for the
noise.]
This patch proposes virtio specification for new virtio video decode
device.
This device provides the functionality of hardware accelerated video
decoding from encoded video contents provided by the guest into frame
buffers accessible by the guest.
We have prototype implementation for VMs on Chrome OS:
* virtio-vdec device in crosvm [1]
* virtio-vdec driver in Linux kernel v4.19 [2]
- This driver follows V4L2 stateful video decoder API [3].
Our prototype implementation uses [4], which allows the virtio-vdec
device to use buffers allocated by virtio-gpu device.
Any feedback would be greatly appreciated. Thank you.
[1]
https://chromium-review.googlesource.com/q/hashtag:%22virtio-vdec-device%22+(status:open%20OR%20status:merged)
[2]
https://chromium-review.googlesource.com/q/hashtag:%22virtio-vdec-driver%22+(status:open%20OR%20status:merged)
[3] https://hverkuil.home.xs4all.nl/codec-api/uapi/v4l/dev-decoder.html (to be
merged to Linux 5.4)
[4] https://lkml.org/lkml/2019/9/12/157
Signed-off-by: Keiichi Watanabe
---
content.tex | 1 +
virtio-vdec.tex | 750
2 files changed, 751 insertions(+)
create mode 100644 virtio-vdec.tex
diff --git a/content.tex b/content.tex
index 37a2190..b57d4a9 100644
--- a/content.tex
+++ b/content.tex
@@ -5682,6 +5682,7 @@ \subsubsection{Legacy Interface: Framing
Requirements}\label{sec:Device
\input{virtio-input.tex}
\input{virtio-crypto.tex}
\input{virtio-vsock.tex}
+\input{virtio-vdec.tex}
\chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
diff --git a/virtio-vdec.tex b/virtio-vdec.tex
new file mode 100644
index 000..d117129
--- /dev/null
+++ b/virtio-vdec.tex
@@ -0,0 +1,750 @@
+\section{Video Decode Device}
+\label{sec:Device Types / Video Decode Device}
+
+virtio-vdec is a virtio based video decoder. This device provides the
+functionality of hardware accelerated video decoding from encoded
+video contents provided by the guest into frame buffers accessible by
+the guest.
+
+\subsection{Device ID}
+\label{sec:Device Types / Video Decode Device / Device ID}
+
+28
+
+\subsection{Virtqueues}
+\label{sec:Device Types / Video Decode Device / Virtqueues}
+
+\begin{description}
+\item[0] outq - queue for sending requests from the driver to the
+ device
+\item[1] inq - queue for sending requests from the device to the
+ driver
+\end{description}
+
+Each queue is used uni-directionally. outq is used to send requests
+from the driver to the device (i.e., guest requests) and inq is used
+to send requests in the other direction (i.e., host requests).
+
+\subsection{Feature bits}
+\label{sec:Device Types / Video Decode Device / Feature bits}
+
+There are currently no feature bits defined for this device.
+
+\subsection{Device configuration layout}
+\label{sec:Device Types / Video Decode Device / Device configuration layout}
+
+None.
+
+\subsection{Device Requirements: Device Initialization}
+\label{sec:Device Types / Video Decode Device / Device Requirements: Device
Initialization}
+
+The virtqueues are initialized.
+
+\subsection{Device Operation}
+\label{sec:Device Types / Video Decode Device / Device Operation}
+
+\subsubsection{Video Buffers}
+\label{sec:Device Types / Video Decode Device / Device Operation / Buffers}
+
+A virtio-vdec driver and a device use two types of video buffers:
+\emph{bitstream buffer} and \emph{frame buffer}. A bitstream buffer
+contains encoded video stream data. This buffer is similar to an
+OUTPUT buffer for Video for Linux Two (V4L2) API. A frame buffer
+contains decoded video frame data like a CAPTURE buffers for V4L2 API.
+The driver and the device share these buffers, and each buffer is
+identified by a unique integer called a \emph{resource handle}.
+
+\subsubsection{Guest Request}
+
+The driver queues requests to the outq virtqueue. The device MAY
+process requests out-of-order. All requests on outq use the following
+structure:
+
+\begin{lstlisting}
+enum virtio_vdec_guest_req_type {
+VIRTIO_VDEC_GUEST_REQ_UNDEFINED = 0,
+
+/* Global */
+VIRTIO_VDEC_GUEST_REQ_QUERY = 0x0100,
+
+/* Per instance */
+VIRTIO_VDEC_GUEST_REQ_OPEN = 0x0200,
+VIRTIO_VDEC_GUEST_REQ_SET_BUFFER_COUNT,
+VIRTIO_VDEC_GUEST_REQ_REGISTER_BUFFER,
+VIRTIO_VDEC_GUEST_REQ_ACK_STREAM_INFO,
+VIRTIO_VDEC_GUEST_REQ_FRAME_BUFFER,
+VIRTIO_VDEC_GUEST_REQ_BITSTREAM_BUFFER,
+VIRTIO_VDEC_GUEST_REQ_DRAIN,
+VIRTIO_VDEC_GUEST_REQ_FLUSH,
+VIRTIO_VDEC_GUEST_REQ_CLOSE,
+};
+
+struct virtio_vdec_guest_req {
+le32 type;
+le32 instance_id;
+union {
+struct virtio_vdec_guest_req_open open;
+struct virtio_vdec_guest_req_set_buffer_count set_buffer_count;
+struct virtio_vdec_guest_req_register_buffer register_buffer;
+struct
[PATCH] [RFC] vdec: Add virtio video decode device specification
This patch proposes virtio specification for new virtio video decode
device.
This device provides the functionality of hardware accelerated video
decoding from encoded video contents provided by the guest into frame
buffers accessible by the guest.
We have prototype implementation for VMs on Chrome OS:
* virtio-vdec device in crosvm [1]
* virtio-vdec driver in Linux kernel v4.19 [2]
- This driver follows V4L2 stateful video decoder API [3].
Our prototype implementation uses [4], which allows the virtio-vdec
device to use buffers allocated by virtio-gpu device.
Any feedback would be greatly appreciated. Thank you.
[1]
https://chromium-review.googlesource.com/q/hashtag:%22virtio-vdec-device%22+(status:open%20OR%20status:merged)
[2]
https://chromium-review.googlesource.com/q/hashtag:%22virtio-vdec-driver%22+(status:open%20OR%20status:merged)
[3] https://hverkuil.home.xs4all.nl/codec-api/uapi/v4l/dev-decoder.html (to be
merged to Linux 5.4)
[4] https://lkml.org/lkml/2019/9/12/157
Signed-off-by: Keiichi Watanabe
---
content.tex | 1 +
virtio-vdec.tex | 750
2 files changed, 751 insertions(+)
create mode 100644 virtio-vdec.tex
diff --git a/content.tex b/content.tex
index 37a2190..b57d4a9 100644
--- a/content.tex
+++ b/content.tex
@@ -5682,6 +5682,7 @@ \subsubsection{Legacy Interface: Framing
Requirements}\label{sec:Device
\input{virtio-input.tex}
\input{virtio-crypto.tex}
\input{virtio-vsock.tex}
+\input{virtio-vdec.tex}
\chapter{Reserved Feature Bits}\label{sec:Reserved Feature Bits}
diff --git a/virtio-vdec.tex b/virtio-vdec.tex
new file mode 100644
index 000..d117129
--- /dev/null
+++ b/virtio-vdec.tex
@@ -0,0 +1,750 @@
+\section{Video Decode Device}
+\label{sec:Device Types / Video Decode Device}
+
+virtio-vdec is a virtio based video decoder. This device provides the
+functionality of hardware accelerated video decoding from encoded
+video contents provided by the guest into frame buffers accessible by
+the guest.
+
+\subsection{Device ID}
+\label{sec:Device Types / Video Decode Device / Device ID}
+
+28
+
+\subsection{Virtqueues}
+\label{sec:Device Types / Video Decode Device / Virtqueues}
+
+\begin{description}
+\item[0] outq - queue for sending requests from the driver to the
+ device
+\item[1] inq - queue for sending requests from the device to the
+ driver
+\end{description}
+
+Each queue is used uni-directionally. outq is used to send requests
+from the driver to the device (i.e., guest requests) and inq is used
+to send requests in the other direction (i.e., host requests).
+
+\subsection{Feature bits}
+\label{sec:Device Types / Video Decode Device / Feature bits}
+
+There are currently no feature bits defined for this device.
+
+\subsection{Device configuration layout}
+\label{sec:Device Types / Video Decode Device / Device configuration layout}
+
+None.
+
+\subsection{Device Requirements: Device Initialization}
+\label{sec:Device Types / Video Decode Device / Device Requirements: Device
Initialization}
+
+The virtqueues are initialized.
+
+\subsection{Device Operation}
+\label{sec:Device Types / Video Decode Device / Device Operation}
+
+\subsubsection{Video Buffers}
+\label{sec:Device Types / Video Decode Device / Device Operation / Buffers}
+
+A virtio-vdec driver and a device use two types of video buffers:
+\emph{bitstream buffer} and \emph{frame buffer}. A bitstream buffer
+contains encoded video stream data. This buffer is similar to an
+OUTPUT buffer for Video for Linux Two (V4L2) API. A frame buffer
+contains decoded video frame data like a CAPTURE buffers for V4L2 API.
+The driver and the device share these buffers, and each buffer is
+identified by a unique integer called a \emph{resource handle}.
+
+\subsubsection{Guest Request}
+
+The driver queues requests to the outq virtqueue. The device MAY
+process requests out-of-order. All requests on outq use the following
+structure:
+
+\begin{lstlisting}
+enum virtio_vdec_guest_req_type {
+VIRTIO_VDEC_GUEST_REQ_UNDEFINED = 0,
+
+/* Global */
+VIRTIO_VDEC_GUEST_REQ_QUERY = 0x0100,
+
+/* Per instance */
+VIRTIO_VDEC_GUEST_REQ_OPEN = 0x0200,
+VIRTIO_VDEC_GUEST_REQ_SET_BUFFER_COUNT,
+VIRTIO_VDEC_GUEST_REQ_REGISTER_BUFFER,
+VIRTIO_VDEC_GUEST_REQ_ACK_STREAM_INFO,
+VIRTIO_VDEC_GUEST_REQ_FRAME_BUFFER,
+VIRTIO_VDEC_GUEST_REQ_BITSTREAM_BUFFER,
+VIRTIO_VDEC_GUEST_REQ_DRAIN,
+VIRTIO_VDEC_GUEST_REQ_FLUSH,
+VIRTIO_VDEC_GUEST_REQ_CLOSE,
+};
+
+struct virtio_vdec_guest_req {
+le32 type;
+le32 instance_id;
+union {
+struct virtio_vdec_guest_req_open open;
+struct virtio_vdec_guest_req_set_buffer_count set_buffer_count;
+struct virtio_vdec_guest_req_register_buffer register_buffer;
+struct virtio_vdec_guest_req_bitstream_buffer bitstream_buffer;
+struct
Re: [RFC PATCH V0 1/4] media: platform: mtk-isp: Add Mediatek sensor interface driver
Hi, thank you Louis for the patch! And, thank you Tomasz for adding me to CC in this thread:) Let me add only general comments because I don't have enough knowledge about the technical details of this device. Please see my comments inline. On Tue, Mar 5, 2019 at 4:51 PM Tomasz Figa wrote: > > +CC Shik and Keiichi > > On Thu, Feb 21, 2019 at 4:22 PM Louis Kuo wrote: > > > > This patch adds Mediatek's sensor interface driver. Sensor interface driver > > is a MIPI-CSI2 host driver, namely, a HW camera interface controller. > > It support a widely adopted, simple, high-speed protocol primarily intended > > for point-to-point image and video transmission between cameras and host > > devices. > > > > The mtk-isp directory will contain drivers for multiple IP blocks found in > > Mediatek ISP system. It will include ISP Pass 1 driver, sensor interface > > driver, DIP driver and face detection driver. > > > > Signed-off-by: Louis Kuo > > --- > > drivers/media/platform/Makefile|2 + > > drivers/media/platform/mtk-isp/Makefile| 14 + > > drivers/media/platform/mtk-isp/isp_50/Makefile | 17 + > > .../media/platform/mtk-isp/isp_50/seninf/Makefile |4 + > > .../platform/mtk-isp/isp_50/seninf/mtk_seninf.c| 1339 > > > > .../mtk-isp/isp_50/seninf/seninf_drv_def.h | 201 +++ > > .../platform/mtk-isp/isp_50/seninf/seninf_reg.h| 992 +++ > > 7 files changed, 2569 insertions(+) > > create mode 100644 drivers/media/platform/mtk-isp/Makefile > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/Makefile > > create mode 100644 drivers/media/platform/mtk-isp/isp_50/seninf/Makefile > > create mode 100644 > > drivers/media/platform/mtk-isp/isp_50/seninf/mtk_seninf.c > > create mode 100644 > > drivers/media/platform/mtk-isp/isp_50/seninf/seninf_drv_def.h > > create mode 100644 > > drivers/media/platform/mtk-isp/isp_50/seninf/seninf_reg.h > > > > diff --git a/drivers/media/platform/Makefile > > b/drivers/media/platform/Makefile > > index e6deb25..9fef94f 100644 > > --- a/drivers/media/platform/Makefile > > +++ b/drivers/media/platform/Makefile > > @@ -75,6 +75,8 @@ obj-$(CONFIG_VIDEO_ROCKCHIP_RGA) += rockchip/rga/ > > > > obj-y += omap/ > > > > +obj-y += mtk-isp/ > > + > > obj-$(CONFIG_VIDEO_AM437X_VPFE)+= am437x/ > > > > obj-$(CONFIG_VIDEO_XILINX) += xilinx/ > > diff --git a/drivers/media/platform/mtk-isp/Makefile > > b/drivers/media/platform/mtk-isp/Makefile > > new file mode 100644 > > index 000..9d245f0 > > --- /dev/null > > +++ b/drivers/media/platform/mtk-isp/Makefile > > @@ -0,0 +1,14 @@ > > +# > > +# Copyright (C) 2018 MediaTek Inc. > > +# > > +# This program is free software: you can redistribute it and/or modify > > +# it under the terms of the GNU General Public License version 2 as > > +# published by the Free Software Foundation. > > +# > > +# This program is distributed in the hope that it will be useful, > > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > +# GNU General Public License for more details. > > +# > > + > > +obj-y += isp_50/ > > \ No newline at end of file > > diff --git a/drivers/media/platform/mtk-isp/isp_50/Makefile > > b/drivers/media/platform/mtk-isp/isp_50/Makefile > > new file mode 100644 > > index 000..bd8cd19 > > --- /dev/null > > +++ b/drivers/media/platform/mtk-isp/isp_50/Makefile > > @@ -0,0 +1,17 @@ > > +# > > +# Copyright (C) 2018 MediaTek Inc. > > +# > > +# This program is free software: you can redistribute it and/or modify > > +# it under the terms of the GNU General Public License version 2 as > > +# published by the Free Software Foundation. > > +# > > +# This program is distributed in the hope that it will be useful, > > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > > +# GNU General Public License for more details. > > +# > > + > > +ifeq ($(CONFIG_MTK_SENINF),y) > > +obj-y += seninf/ > > +endif > > + > > diff --git a/drivers/media/platform/mtk-isp/isp_50/seninf/Makefile > > b/drivers/media/platform/mtk-isp/isp_50/seninf/Makefile > > new file mode 100644 > > index 000..f1b2e2d > > --- /dev/null > > +++ b/drivers/media/platform/mtk-isp/isp_50/seninf/Makefile > > @@ -0,0 +1,4 @@ > > +MODULE = mtk_seninf > > +LIB_FILES = mtk_seninf > > + > > +obj-$(CONFIG_MTK_SENINF) += mtk_seninf.o > > diff --git a/drivers/media/platform/mtk-isp/isp_50/seninf/mtk_seninf.c > > b/drivers/media/platform/mtk-isp/isp_50/seninf/mtk_seninf.c > > new file mode 100644 > > index 000..7ac8a4a > > --- /dev/null > > +++ b/drivers/media/platform/mtk-isp/isp_50/seninf/mtk_seninf.c > > @@ -0,0 +1,1339 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * Copyright (C) 2016 MediaTek Inc. > > + * > > + * This program is free software; you can redistr
[PATCH v2] media: vivid: Support 480p for webcam capture
Support 640x480 as a frame size for video input devices of vivid.
Signed-off-by: Keiichi Watanabe
---
drivers/media/platform/vivid/vivid-vid-cap.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c
b/drivers/media/platform/vivid/vivid-vid-cap.c
index 58e14dd1dcd3..6cf910a60ecf 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -51,7 +51,7 @@ static const struct vivid_fmt formats_ovl[] = {
};
/* The number of discrete webcam framesizes */
-#define VIVID_WEBCAM_SIZES 5
+#define VIVID_WEBCAM_SIZES 6
/* The number of discrete webcam frameintervals */
#define VIVID_WEBCAM_IVALS (VIVID_WEBCAM_SIZES * 2)
@@ -59,6 +59,7 @@ static const struct vivid_fmt formats_ovl[] = {
static const struct v4l2_frmsize_discrete webcam_sizes[VIVID_WEBCAM_SIZES] = {
{ 320, 180 },
{ 640, 360 },
+ { 640, 480 },
{ 1280, 720 },
{ 1920, 1080 },
{ 3840, 2160 },
@@ -74,9 +75,11 @@ static const struct v4l2_fract
webcam_intervals[VIVID_WEBCAM_IVALS] = {
{ 1, 4 },
{ 1, 5 },
{ 1, 10 },
+ { 2, 25 },
{ 1, 15 },
{ 1, 25 },
{ 1, 30 },
+ { 1, 40 },
{ 1, 50 },
{ 1, 60 },
};
--
2.19.0.605.g01d371f741-goog
Re: [PATCH] media: vivid: Support 480p for webcam capture
Let me back to the topic about interval.
I'd like to send a nex version of this patch to avoid duplication of intervals.
We need to choose two intervals from the three options: 1/20, 2/25 and 1/40.
As Mauro said, we would want to have 2/25 for a fractional rate.
Then, I think adding 2/25 and 1/40 will work well.
If it's okay, I will send an updated version.
Best regards,
Kei
On Tue, Oct 9, 2018 at 4:00 AM, Mauro Carvalho Chehab
wrote:
> Em Mon, 8 Oct 2018 20:31:10 +0200
> Hans Verkuil escreveu:
>
>> > (gdb) list *vivid_fillbuff+0x1e9b
>> > 0x1936b is in vivid_fillbuff
>> > (drivers/media/platform/vivid/vivid-kthread-cap.c:495).
>> > 490 ms % 1000,
>> > 491 buf->vb.sequence,
>> > 492 (dev->field_cap ==
>> > V4L2_FIELD_ALTERNATE) ?
>> > 493 (buf->vb.field ==
>> > V4L2_FIELD_TOP ?
>> > 494 " top" : " bottom") : "");
>> > 495 tpg_gen_text(tpg, basep, line++ * line_height, 16,
>> > str);
>> > 496 }
>> > 497 if (dev->osd_mode == 0) {
>> > 498 snprintf(str, sizeof(str), " %dx%d, input %d ",
>> > 499 dev->src_rect.width,
>> > dev->src_rect.height, dev->input);
>> >
>>
>> There is a bug with hflip handling in that function. Nothing to do with the
>> resolution. I could reproduce it by just checking the hflip control.
>> I'll investigate.
>
> Ah! Well, as I said, I got it only once last week while trying to use
> vivid for some event racing test. I didn't have time to actually
> seek. On that time, the bug only manifested when I changed the frame
> rate.
>
> Thanks,
> Mauro
Re: [PATCH] media: vivid: Support 480p for webcam capture
Hi all,
On Fri, Oct 5, 2018 at 6:18 PM, Hans Verkuil wrote:
> On 10/03/18 09:08, Keiichi Watanabe wrote:
>> I think 480p is a common frame size and it's worth supporting in vivid.
>> But, my patch might be ad-hoc. Actually, I'm not sure which values are
>> suitable for the intervals.
>
> I can apply this ad-hoc patch as-is.
>
> Or do you want to postpone this and work on a more generic solution?
> Although I am not sure what that would look like.
I prefer providing a more flexible way rather than this ad-hoc patch.
It would be helpful if there is a way of changing supported frame sizes easily.
Perhaps, Kieran and me would use it, at least:)
>
> Proposals are welcome!
>
> The main purpose of this code is to have something that kind of acts like
> a real webcam that has various resolutions, and a slower framerate for
> higher resolutions (as you would expect).
This sounds reasonable, so I guess we can keep this way as default and
provide a way for specifying extra frame sizes as an option.
For example, how about a module option like this?
"webcam_sizes=640x480@15,320x240@30"
If this parameter is passed to vivid, vivid works like a webcam that
supports the following 7 pairs of frame size and fps:
- 5 pairs of frame sizes and fps, as with the current implementation
- 640x480 (15fps)
- 320x240 (30fps)
If this parameter is not passed, vivid's behavior won't change from
the current one.
How do you think?
We might want to stop using the default framesizes, i.e. vivid only
supports framesize/fps that passed as the option.
But, if we do so, the parameter will become mandatory and it would be annoying.
So, I personally like to keep the default framesizes.
Best regards,
Kei
>
> Regards,
>
> Hans
>
>>
>> We might want to add a more flexible/extensible way to specify frame sizes.
>> e.g. passing frame sizes and intervals as module parameters
>>
>> Kei
>>
>> On Wed, Oct 3, 2018 at 4:06 PM, Keiichi Watanabe
>> wrote:
>>> Support 640x480 as a frame size for video input devices of vivid.
>>>
>>> Signed-off-by: Keiichi Watanabe
>>> ---
>>> drivers/media/platform/vivid/vivid-vid-cap.c | 5 -
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c
>>> b/drivers/media/platform/vivid/vivid-vid-cap.c
>>> index 58e14dd1dcd3..da80bf4bc365 100644
>>> --- a/drivers/media/platform/vivid/vivid-vid-cap.c
>>> +++ b/drivers/media/platform/vivid/vivid-vid-cap.c
>>> @@ -51,7 +51,7 @@ static const struct vivid_fmt formats_ovl[] = {
>>> };
>>>
>>> /* The number of discrete webcam framesizes */
>>> -#define VIVID_WEBCAM_SIZES 5
>>> +#define VIVID_WEBCAM_SIZES 6
>>> /* The number of discrete webcam frameintervals */
>>> #define VIVID_WEBCAM_IVALS (VIVID_WEBCAM_SIZES * 2)
>>>
>>> @@ -59,6 +59,7 @@ static const struct vivid_fmt formats_ovl[] = {
>>> static const struct v4l2_frmsize_discrete webcam_sizes[VIVID_WEBCAM_SIZES]
>>> = {
>>> { 320, 180 },
>>> { 640, 360 },
>>> + { 640, 480 },
>>> { 1280, 720 },
>>> { 1920, 1080 },
>>> { 3840, 2160 },
>>> @@ -75,6 +76,8 @@ static const struct v4l2_fract
>>> webcam_intervals[VIVID_WEBCAM_IVALS] = {
>>> { 1, 5 },
>>> { 1, 10 },
>>> { 1, 15 },
>>> + { 1, 15 },
>>> + { 1, 25 },
>>> { 1, 25 },
>>> { 1, 30 },
>>> { 1, 50 },
>>> --
>>> 2.19.0.605.g01d371f741-goog
>>>
>
Re: [PATCH 6/5] vicodec: Support multi-planar APIs
On Fri, Jul 20, 2018 at 5:30 PM, Hans Verkuil wrote:
> On 07/20/2018 08:59 AM, Keiichi Watanabe wrote:
>> Support multi-planar APIs in the virtual codec driver.
>> Multi-planar APIs are enabled by the module parameter 'multiplanar'.
>>
>> Signed-off-by: Keiichi Watanabe
>
> Thank you for contributing this code! I've folded it into patch series
> (I just posted v2) and added a Co-Developed-by tag.
>
Thanks, Hans! That sounds good.
> BTW, for future reference: always run v4l2-compliance after making driver
> changes. It caught a bunch of missing checks in this code. I've fixed those,
> but you should always check V4L2 driver changes with v4l2-compliance.
>
Sorry for the inconvenience. I'll use v4l2-compliance next time.
Best regards,
Keiichi
> Regards,
>
> Hans
>
>> ---
>> drivers/media/platform/vicodec/vicodec-core.c | 219 ++
>> 1 file changed, 171 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/media/platform/vicodec/vicodec-core.c
>> b/drivers/media/platform/vicodec/vicodec-core.c
>> index 12c12cb0c1c0..1717f44e1743 100644
>> --- a/drivers/media/platform/vicodec/vicodec-core.c
>> +++ b/drivers/media/platform/vicodec/vicodec-core.c
>> @@ -29,6 +29,11 @@ MODULE_DESCRIPTION("Virtual codec device");
>> MODULE_AUTHOR("Hans Verkuil ");
>> MODULE_LICENSE("GPL v2");
>>
>> +static bool multiplanar;
>> +module_param(multiplanar, bool, 0444);
>> +MODULE_PARM_DESC(multiplanar,
>> + " use multi-planar API instead of single-planar API");
>> +
>> static unsigned int debug;
>> module_param(debug, uint, 0644);
>> MODULE_PARM_DESC(debug, "activates debug info");
>> @@ -135,8 +140,10 @@ static struct vicodec_q_data *get_q_data(struct
>> vicodec_ctx *ctx,
>> {
>> switch (type) {
>> case V4L2_BUF_TYPE_VIDEO_OUTPUT:
>> + case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
>> return &ctx->q_data[V4L2_M2M_SRC];
>> case V4L2_BUF_TYPE_VIDEO_CAPTURE:
>> + case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
>> return &ctx->q_data[V4L2_M2M_DST];
>> default:
>> WARN_ON(1);
>> @@ -530,7 +537,10 @@ static int vidioc_querycap(struct file *file, void
>> *priv,
>> strncpy(cap->card, VICODEC_NAME, sizeof(cap->card) - 1);
>> snprintf(cap->bus_info, sizeof(cap->bus_info),
>> "platform:%s", VICODEC_NAME);
>> - cap->device_caps = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING;
>> + cap->device_caps = V4L2_CAP_STREAMING |
>> + (multiplanar ?
>> + V4L2_CAP_VIDEO_M2M_MPLANE :
>> + V4L2_CAP_VIDEO_M2M);
>> cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
>> return 0;
>> }
>> @@ -576,20 +586,44 @@ static int vidioc_g_fmt(struct vicodec_ctx *ctx,
>> struct v4l2_format *f)
>>
>> q_data = get_q_data(ctx, f->type);
>>
>> - f->fmt.pix.width= q_data->width;
>> - f->fmt.pix.height = q_data->height;
>> - f->fmt.pix.field= V4L2_FIELD_NONE;
>> - f->fmt.pix.pixelformat = q_data->fourcc;
>> - if (q_data->fourcc == V4L2_PIX_FMT_FWHT)
>> - f->fmt.pix.bytesperline = 0;
>> - else
>> - f->fmt.pix.bytesperline = q_data->width;
>> - f->fmt.pix.sizeimage= q_data->sizeimage;
>> - f->fmt.pix.colorspace = ctx->colorspace;
>> - f->fmt.pix.xfer_func= ctx->xfer_func;
>> - f->fmt.pix.ycbcr_enc= ctx->ycbcr_enc;
>> - f->fmt.pix.quantization = ctx->quantization;
>> + switch (f->type) {
>> + case V4L2_BUF_TYPE_VIDEO_CAPTURE:
>> + case V4L2_BUF_TYPE_VIDEO_OUTPUT:
>> + f->fmt.pix.width= q_data->width;
>> + f->fmt.pix.height = q_data->height;
>> + f->fmt.pix.field= V4L2_FIELD_NONE;
>> + f->fmt.pix.pixelformat = q_data->fourcc;
>> + if (q_data->fourcc == V4L2_PIX_FMT_FWHT)
>> + f->fmt.pix.bytesperline = 0;
>> + else
>> + f->fmt.pix.bytesperline = q_data->width;
>> + f->fmt.pix.sizeimage= q_data->sizeimage;
>> + f->fmt.pix.colorspace = ctx->colorspace;
>> + f->fmt.pix.xfer_func= ctx-
[PATCH 6/5] vicodec: Support multi-planar APIs
Support multi-planar APIs in the virtual codec driver.
Multi-planar APIs are enabled by the module parameter 'multiplanar'.
Signed-off-by: Keiichi Watanabe
---
drivers/media/platform/vicodec/vicodec-core.c | 219 ++
1 file changed, 171 insertions(+), 48 deletions(-)
diff --git a/drivers/media/platform/vicodec/vicodec-core.c
b/drivers/media/platform/vicodec/vicodec-core.c
index 12c12cb0c1c0..1717f44e1743 100644
--- a/drivers/media/platform/vicodec/vicodec-core.c
+++ b/drivers/media/platform/vicodec/vicodec-core.c
@@ -29,6 +29,11 @@ MODULE_DESCRIPTION("Virtual codec device");
MODULE_AUTHOR("Hans Verkuil ");
MODULE_LICENSE("GPL v2");
+static bool multiplanar;
+module_param(multiplanar, bool, 0444);
+MODULE_PARM_DESC(multiplanar,
+" use multi-planar API instead of single-planar API");
+
static unsigned int debug;
module_param(debug, uint, 0644);
MODULE_PARM_DESC(debug, "activates debug info");
@@ -135,8 +140,10 @@ static struct vicodec_q_data *get_q_data(struct
vicodec_ctx *ctx,
{
switch (type) {
case V4L2_BUF_TYPE_VIDEO_OUTPUT:
+ case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
return &ctx->q_data[V4L2_M2M_SRC];
case V4L2_BUF_TYPE_VIDEO_CAPTURE:
+ case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
return &ctx->q_data[V4L2_M2M_DST];
default:
WARN_ON(1);
@@ -530,7 +537,10 @@ static int vidioc_querycap(struct file *file, void *priv,
strncpy(cap->card, VICODEC_NAME, sizeof(cap->card) - 1);
snprintf(cap->bus_info, sizeof(cap->bus_info),
"platform:%s", VICODEC_NAME);
- cap->device_caps = V4L2_CAP_VIDEO_M2M | V4L2_CAP_STREAMING;
+ cap->device_caps = V4L2_CAP_STREAMING |
+ (multiplanar ?
+V4L2_CAP_VIDEO_M2M_MPLANE :
+V4L2_CAP_VIDEO_M2M);
cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
}
@@ -576,20 +586,44 @@ static int vidioc_g_fmt(struct vicodec_ctx *ctx, struct
v4l2_format *f)
q_data = get_q_data(ctx, f->type);
- f->fmt.pix.width= q_data->width;
- f->fmt.pix.height = q_data->height;
- f->fmt.pix.field= V4L2_FIELD_NONE;
- f->fmt.pix.pixelformat = q_data->fourcc;
- if (q_data->fourcc == V4L2_PIX_FMT_FWHT)
- f->fmt.pix.bytesperline = 0;
- else
- f->fmt.pix.bytesperline = q_data->width;
- f->fmt.pix.sizeimage= q_data->sizeimage;
- f->fmt.pix.colorspace = ctx->colorspace;
- f->fmt.pix.xfer_func= ctx->xfer_func;
- f->fmt.pix.ycbcr_enc= ctx->ycbcr_enc;
- f->fmt.pix.quantization = ctx->quantization;
+ switch (f->type) {
+ case V4L2_BUF_TYPE_VIDEO_CAPTURE:
+ case V4L2_BUF_TYPE_VIDEO_OUTPUT:
+ f->fmt.pix.width= q_data->width;
+ f->fmt.pix.height = q_data->height;
+ f->fmt.pix.field= V4L2_FIELD_NONE;
+ f->fmt.pix.pixelformat = q_data->fourcc;
+ if (q_data->fourcc == V4L2_PIX_FMT_FWHT)
+ f->fmt.pix.bytesperline = 0;
+ else
+ f->fmt.pix.bytesperline = q_data->width;
+ f->fmt.pix.sizeimage= q_data->sizeimage;
+ f->fmt.pix.colorspace = ctx->colorspace;
+ f->fmt.pix.xfer_func= ctx->xfer_func;
+ f->fmt.pix.ycbcr_enc= ctx->ycbcr_enc;
+ f->fmt.pix.quantization = ctx->quantization;
+ break;
+ case V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE:
+ case V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE:
+ f->fmt.pix_mp.width = q_data->width;
+ f->fmt.pix_mp.height= q_data->height;
+ f->fmt.pix_mp.field = V4L2_FIELD_NONE;
+ f->fmt.pix_mp.pixelformat = q_data->fourcc;
+ f->fmt.pix_mp.num_planes= 1;
+ if (q_data->fourcc == V4L2_PIX_FMT_FWHT)
+ f->fmt.pix_mp.plane_fmt[0].bytesperline = 0;
+ else
+ f->fmt.pix_mp.plane_fmt[0].bytesperline = q_data->width;
+ f->fmt.pix_mp.plane_fmt[0].sizeimage = q_data->sizeimage;
+ f->fmt.pix_mp.colorspace= ctx->colorspace;
+ f->fmt.pix_mp.xfer_func = ctx->xfer_func;
+ f->fmt.pix_mp.ycbcr_enc = ctx->ycbcr_enc;
+ f->fmt.pix_mp.quantization = ctx->quantization;
+ break;
+ default:
+ return -EINVAL;
+ }
return 0;
}
@@ -607,16 +641,41
Re: [PATCH v2 1/2] media: v4l2-ctrl: Add control for VP9 profile
Hi, Hans. Thank you for the review. Your idea sounds good. However, I think that changing V4L2_CID_MPEG_VIDEO_VPX_PROFILE to an enum breaks both of s5p-mfc and venus drivers. This is because they call 'v4l2_ctrl_new_std' for it. For menu controls, 'v4l2_ctrl_new_std_menu' must be used. https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c#L2678 https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/qcom/venus/vdec_ctrls.c#L133 I can fix them within the commit for adding VP8_PROFILE control, but cannot confirm that it works on real devices since I don't have them. What should I do? Best regards, Keiichi On Fri, Jun 8, 2018 at 10:00 PM Nicolas Dufresne wrote: > > > > Le ven. 8 juin 2018 08:56, Stanimir Varbanov a > écrit : >> >> Hi Hans, >> >> On 06/08/2018 12:29 PM, Hans Verkuil wrote: >> > On 05/30/2018 09:16 AM, Keiichi Watanabe wrote: >> >> Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired >> >> profile for VP9 encoder and querying for supported profiles by VP9 encoder >> >> or decoder. >> >> >> >> An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE cannot be >> >> used for querying since it is not a menu control but an integer >> >> control, which cannot return an arbitrary set of supported profiles. >> >> >> >> The new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE is a menu control as >> >> with controls for other codec profiles. (e.g. H264) >> > >> > Please ignore my reply to patch 2/2. I looked at this a bit more and what >> > you >> > should do is to change the type of V4L2_CID_MPEG_VIDEO_VPX_PROFILE to enum. >> > >> > All other codec profile controls are all enums, so the fact that >> > VPX_PROFILE >> > isn't is a bug. Changing the type should not cause any problems since the >> > same >> > control value is used when you set the control. >> > >> > Sylwester: I see that s5p-mfc uses this control, but it is explicitly added >> > as an integer type control, so the s5p-mfc driver should not be affected by >> > changing the type of this control. >> > >> > Stanimir: this will slightly change the venus driver, but since it is a >> > very >> > recent driver I think we can get away with changing the core type of the >> > VPX_PROFILE control. I think that's better than ending up with two controls >> > that do the same thing. >> >> I agree. Actually the changes shouldn't be so much in venus driver. > > > Also fine on userspace side, since profiles enumeration isn't implemented yet > in FFMPEG, GStreamer, Chrome > > >> >> -- >> regards, >> Stan
[PATCH] media: v4l2-ctrl: Add control for VP9 profile
Add a new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE for selecting desired
profile for VP9 encoder and querying for supported profiles by VP9 encoder
or decoder.
An existing control V4L2_CID_MPEG_VIDEO_VPX_PROFILE cannot be
used for querying since it is not a menu control but an integer
control, which cannot return an arbitrary set of supported profiles.
The new control V4L2_CID_MPEG_VIDEO_VP9_PROFILE is a menu control as
with controls for other codec profiles. (e.g. H264)
Signed-off-by: Keiichi Watanabe
---
.../media/uapi/v4l/extended-controls.rst | 26 +++
drivers/media/v4l2-core/v4l2-ctrls.c | 12 +
include/uapi/linux/v4l2-controls.h| 8 ++
3 files changed, 46 insertions(+)
diff --git a/Documentation/media/uapi/v4l/extended-controls.rst
b/Documentation/media/uapi/v4l/extended-controls.rst
index 03931f9b1285..4f7f128a4998 100644
--- a/Documentation/media/uapi/v4l/extended-controls.rst
+++ b/Documentation/media/uapi/v4l/extended-controls.rst
@@ -1959,6 +1959,32 @@ enum v4l2_vp8_golden_frame_sel -
Select the desired profile for VPx encoder. Acceptable values are 0,
1, 2 and 3 corresponding to encoder profiles 0, 1, 2 and 3.
+.. _v4l2-mpeg-video-vp9-profile:
+
+``V4L2_CID_MPEG_VIDEO_VP9_PROFILE``
+(enum)
+
+enum v4l2_mpeg_video_vp9_profile -
+This control allows to select the profile for VP9 encoder.
+This is also used to enumerate supported profiles by VP9 encoder or
decoder.
+Possible values are:
+
+
+
+.. flat-table::
+:header-rows: 0
+:stub-columns: 0
+
+* - ``V4L2_MPEG_VIDEO_VP9_PROFILE_0``
+ - Profile 0
+* - ``V4L2_MPEG_VIDEO_VP9_PROFILE_1``
+ - Profile 1
+* - ``V4L2_MPEG_VIDEO_VP9_PROFILE_2``
+ - Profile 2
+* - ``V4L2_MPEG_VIDEO_VP9_PROFILE_3``
+ - Profile 3
+
+
High Efficiency Video Coding (HEVC/H.265) Control Reference
---
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index d29e45516eb7..401ce21c2e63 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -431,6 +431,13 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
"Use Previous Specific Frame",
NULL,
};
+ static const char * const vp9_profile[] = {
+ "0",
+ "1",
+ "2",
+ "3",
+ NULL,
+ };
static const char * const flash_led_mode[] = {
"Off",
@@ -614,6 +621,8 @@ const char * const *v4l2_ctrl_get_menu(u32 id)
return mpeg4_profile;
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
return vpx_golden_frame_sel;
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
+ return vp9_profile;
case V4L2_CID_JPEG_CHROMA_SUBSAMPLING:
return jpeg_chroma_subsampling;
case V4L2_CID_DV_TX_MODE:
@@ -841,6 +850,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP:return "VPX
P-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_VPX_PROFILE: return "VPX
Profile";
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE: return "VP9
Profile";
+
/* HEVC controls */
case V4L2_CID_MPEG_VIDEO_HEVC_I_FRAME_QP: return "HEVC
I-Frame QP Value";
case V4L2_CID_MPEG_VIDEO_HEVC_P_FRAME_QP: return "HEVC
P-Frame QP Value";
@@ -1180,6 +1191,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum
v4l2_ctrl_type *type,
case V4L2_CID_DEINTERLACING_MODE:
case V4L2_CID_TUNE_DEEMPHASIS:
case V4L2_CID_MPEG_VIDEO_VPX_GOLDEN_FRAME_SEL:
+ case V4L2_CID_MPEG_VIDEO_VP9_PROFILE:
case V4L2_CID_DETECT_MD_MODE:
case V4L2_CID_MPEG_VIDEO_HEVC_PROFILE:
case V4L2_CID_MPEG_VIDEO_HEVC_LEVEL:
diff --git a/include/uapi/linux/v4l2-controls.h
b/include/uapi/linux/v4l2-controls.h
index 8d473c979b61..56203b7b715c 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -589,6 +589,14 @@ enum v4l2_vp8_golden_frame_sel {
#define V4L2_CID_MPEG_VIDEO_VPX_P_FRAME_QP (V4L2_CID_MPEG_BASE+510)
#define V4L2_CID_MPEG_VIDEO_VPX_PROFILE
(V4L2_CID_MPEG_BASE+511)
+#define V4L2_CID_MPEG_VIDEO_VP9_PROFILE
(V4L2_CID_MPEG_BASE+512)
+enum v4l2_mpeg_video_vp9_profile {
+ V4L2_MPEG_VIDEO_VP9_PROFILE_0 = 0,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_1 = 1,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_2 = 2,
+ V4L2_MPEG_VIDEO_VP9_PROFILE_3 = 3,
+};
+
/* CIDs for HEVC encoding. */
#define V4L2_CID_MPEG_VIDEO_HEVC_MIN_QP(V4L2_CID_MPEG_BASE +
600)
--
2.17.0.441.gb46fe60e1d-goog
