cron job: media_tree daily build: OK
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Oct 27 05:00:13 CEST 2018 media-tree git hash:3b796aa60af087f5fec75aee9b17f2130f2b9adc media_build git hash: 0c8bb27f3aaa682b9548b656f77505c3d1f11e71 v4l-utils git hash: c36dbbdfa8b30b2badd4f893b59d0bd4f0bd12aa edid-decode git hash: 5eeb151a748788666534d6ea3da07f90400d24c2 gcc version:i686-linux-gcc (GCC) 8.2.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.18.0-2-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.57-i686: OK linux-3.16.57-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.123-i686: OK linux-3.18.123-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.52-i686: OK linux-4.1.52-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.159-i686: OK linux-4.4.159-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.131-i686: OK linux-4.9.131-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.74-i686: OK linux-4.14.74-x86_64: OK linux-4.15.18-i686: OK linux-4.15.18-x86_64: OK linux-4.16.18-i686: OK linux-4.16.18-x86_64: OK linux-4.17.19-i686: OK linux-4.17.19-x86_64: OK linux-4.18.12-i686: OK linux-4.18.12-x86_64: OK linux-4.19-i686: OK linux-4.19-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
Re: [RFP] Which V4L2 ioctls could be replaced by better versions?
Hi Tomasz, On Friday, 26 October 2018 14:41:26 EEST Tomasz Figa wrote: > On Thu, Sep 20, 2018 at 11:42 PM Hans Verkuil wrote: > > Some parts of the V4L2 API are awkward to use and I think it would be > > a good idea to look at possible candidates for that. > > > > Examples are the ioctls that use struct v4l2_buffer: the multiplanar > > support is really horrible, and writing code to support both single and > > multiplanar is hard. We are also running out of fields and the timeval > > isn't y2038 compliant. > > > > A proof-of-concept is here: > > > > https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=v4l2-buffer=a > > 95549df06d9900f3559afdbb9da06bd4b22d1f3 > > > > It's a bit old, but it gives a good impression of what I have in mind. > > On a related, but slightly different note, I'm wondering how we should > handle a case where we have an M format (e.g. NV12M with 2 memory > planes), but only 1 DMA-buf with all planes to import. That generally > means that we have to use the same DMA-buf FD with an offset for each > plane. In theory, v4l2_plane::data_offset could be used for this, but > the documentation says that it should be set by the application only > for OUTPUT planes. Moreover, existing drivers tend to just ignore > it... The following patches may be of interest. https://patchwork.linuxtv.org/patch/29177/ https://patchwork.linuxtv.org/patch/29178/ > There is also the opposite problem. Sometimes the application is given > 3 different FDs but pointing to the same buffer. If it has to work > with a video device that only supports non-M formats, it can either > fail, making it unusable, or blindly assume that they all point to the > same buffer and just give the first FD to the video device (we do it > in Chromium, since our allocator is guaranteed to keep all planes of > planar formats in one buffer, if to be used with V4L2). > > Something that we could do is allowing the QBUF semantics of M formats > for non-M formats, where the application would fill the planes[] array > for all planes with all the FDs it has and the kernel could then > figure out if they point to the same buffer (i.e. resolve to the same > dma_buf struct) or fail if not. > > [...] > > > Do we have more ioctls that could use a refresh? S/G/TRY_FMT perhaps, > > again in order to improve single vs multiplanar handling. > > I'd definitely be more than happy to see the plane handling unified > between non-M and M formats, in general. The list of problems with > current interface: > > 1) The userspace has to hardcode the computations of bytesperline for > chroma planes of non-M formats (while they are reported for M > formats). > > 2) Similarly, offsets of the planes in the buffer for non-M formats > must be explicitly calculated in the application, > > 3) Drivers have to explicitly handle both non-M and M formats or > otherwise they would suffer from issues with application compatibility > or sharing buffers with other devices (one supporting only M and the > other only non-M), > > 4) Inconsistency in the meaning of planes[0].sizeimage for non-M > formats and M formats, making it impossible to use planes[0].sizeimage > to set the luma plane size in the hardware for non-M formats (since > it's the total size of all planes). > > I might have probably forgotten about something, but generally fixing > the 4 above, would be a really big step forward. -- Regards, Laurent Pinchart
[PATCH] media: v4l uapi docs: few minor corrections and typos
Signed-off-by: Sean Young --- Documentation/media/uapi/v4l/app-pri.rst | 2 +- Documentation/media/uapi/v4l/audio.rst| 2 +- Documentation/media/uapi/v4l/dev-capture.rst | 2 +- Documentation/media/uapi/v4l/dev-teletext.rst | 2 +- Documentation/media/uapi/v4l/format.rst | 2 +- Documentation/media/uapi/v4l/mmap.rst | 22 +-- Documentation/media/uapi/v4l/open.rst | 2 +- Documentation/media/uapi/v4l/tuner.rst| 4 ++-- Documentation/media/uapi/v4l/userp.rst| 8 +++ Documentation/media/uapi/v4l/video.rst| 4 ++-- 10 files changed, 25 insertions(+), 25 deletions(-) diff --git a/Documentation/media/uapi/v4l/app-pri.rst b/Documentation/media/uapi/v4l/app-pri.rst index a8c41a7ec396..e03929ebe899 100644 --- a/Documentation/media/uapi/v4l/app-pri.rst +++ b/Documentation/media/uapi/v4l/app-pri.rst @@ -8,7 +8,7 @@ Application Priority When multiple applications share a device it may be desirable to assign them different priorities. Contrary to the traditional "rm -rf /" school -of thought a video recording application could for example block other +of thought, a video recording application could for example block other applications from changing video controls or switching the current TV channel. Another objective is to permit low priority applications working in background, which can be preempted by user controlled diff --git a/Documentation/media/uapi/v4l/audio.rst b/Documentation/media/uapi/v4l/audio.rst index 5ec99a2809fe..725a61b59cb1 100644 --- a/Documentation/media/uapi/v4l/audio.rst +++ b/Documentation/media/uapi/v4l/audio.rst @@ -31,7 +31,7 @@ outputs applications can enumerate them with the :ref:`VIDIOC_ENUMAUDOUT ` ioctl, respectively. The struct :c:type:`v4l2_audio` returned by the :ref:`VIDIOC_ENUMAUDIO` ioctl also contains signal -:status information applicable when the current audio input is queried. +status information applicable when the current audio input is queried. The :ref:`VIDIOC_G_AUDIO ` and :ref:`VIDIOC_G_AUDOUT ` ioctls report the current diff --git a/Documentation/media/uapi/v4l/dev-capture.rst b/Documentation/media/uapi/v4l/dev-capture.rst index 4218742ab5d9..09949ac54be4 100644 --- a/Documentation/media/uapi/v4l/dev-capture.rst +++ b/Documentation/media/uapi/v4l/dev-capture.rst @@ -99,6 +99,6 @@ requests and always returns default parameters as :ref:`VIDIOC_G_FMT ` +A video capture device may support the :ref:`read() function ` and/or streaming (:ref:`memory mapping ` or :ref:`user pointer `) I/O. See :ref:`io` for details. diff --git a/Documentation/media/uapi/v4l/dev-teletext.rst b/Documentation/media/uapi/v4l/dev-teletext.rst index 2648f6b37ea3..436c7393759a 100644 --- a/Documentation/media/uapi/v4l/dev-teletext.rst +++ b/Documentation/media/uapi/v4l/dev-teletext.rst @@ -10,7 +10,7 @@ This interface was aimed at devices receiving and demodulating Teletext data [:ref:`ets300706`, :ref:`itu653`], evaluating the Teletext packages and storing formatted pages in cache memory. Such devices are usually implemented as microcontrollers with serial interface -(I:sup:`2`\ C) and could be found on old TV cards, dedicated Teletext +(I\ :sup:`2`\ C) and could be found on old TV cards, dedicated Teletext decoding cards and home-brew devices connected to the PC parallel port. The Teletext API was designed by Martin Buck. It was defined in the diff --git a/Documentation/media/uapi/v4l/format.rst b/Documentation/media/uapi/v4l/format.rst index 3e3efb0e349e..dc8ccd8bf982 100644 --- a/Documentation/media/uapi/v4l/format.rst +++ b/Documentation/media/uapi/v4l/format.rst @@ -12,7 +12,7 @@ Data Format Negotiation Different devices exchange different kinds of data with applications, for example video images, raw or sliced VBI data, RDS datagrams. Even -within one kind many different formats are possible, in particular an +within one kind many different formats are possible, in particular there is an abundance of image formats. Although drivers must provide a default and the selection persists across closing and reopening a device, applications should always negotiate a data format before engaging in diff --git a/Documentation/media/uapi/v4l/mmap.rst b/Documentation/media/uapi/v4l/mmap.rst index 670596c1a4f7..0f0968799e69 100644 --- a/Documentation/media/uapi/v4l/mmap.rst +++ b/Documentation/media/uapi/v4l/mmap.rst @@ -231,17 +231,17 @@ up the output is started with :ref:`VIDIOC_STREAMON `. In the write loop, when the application runs out of free buffers, it must wait until an empty buffer can be dequeued and reused. -To enqueue and dequeue a buffer applications use the :ref:`VIDIOC_QBUF` -and :ref:`VIDIOC_DQBUF ` ioctl. The status of a buffer -being mapped, enqueued, full or empty can be determined at any time -using the :ref:`VIDIOC_QUERYBUF` ioctl. Two methods exist to suspend -execution of the application until one or more buffers can be dequeued. -By default
Re: [RFP] Which V4L2 ioctls could be replaced by better versions?
On Thu, Sep 20, 2018 at 11:42 PM Hans Verkuil wrote: > > Some parts of the V4L2 API are awkward to use and I think it would be > a good idea to look at possible candidates for that. > > Examples are the ioctls that use struct v4l2_buffer: the multiplanar support > is > really horrible, and writing code to support both single and multiplanar is > hard. > We are also running out of fields and the timeval isn't y2038 compliant. > > A proof-of-concept is here: > > https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=v4l2-buffer=a95549df06d9900f3559afdbb9da06bd4b22d1f3 > > It's a bit old, but it gives a good impression of what I have in mind. On a related, but slightly different note, I'm wondering how we should handle a case where we have an M format (e.g. NV12M with 2 memory planes), but only 1 DMA-buf with all planes to import. That generally means that we have to use the same DMA-buf FD with an offset for each plane. In theory, v4l2_plane::data_offset could be used for this, but the documentation says that it should be set by the application only for OUTPUT planes. Moreover, existing drivers tend to just ignore it... There is also the opposite problem. Sometimes the application is given 3 different FDs but pointing to the same buffer. If it has to work with a video device that only supports non-M formats, it can either fail, making it unusable, or blindly assume that they all point to the same buffer and just give the first FD to the video device (we do it in Chromium, since our allocator is guaranteed to keep all planes of planar formats in one buffer, if to be used with V4L2). Something that we could do is allowing the QBUF semantics of M formats for non-M formats, where the application would fill the planes[] array for all planes with all the FDs it has and the kernel could then figure out if they point to the same buffer (i.e. resolve to the same dma_buf struct) or fail if not. [...] > Do we have more ioctls that could use a refresh? S/G/TRY_FMT perhaps, again in > order to improve single vs multiplanar handling. I'd definitely be more than happy to see the plane handling unified between non-M and M formats, in general. The list of problems with current interface: 1) The userspace has to hardcode the computations of bytesperline for chroma planes of non-M formats (while they are reported for M formats). 2) Similarly, offsets of the planes in the buffer for non-M formats must be explicitly calculated in the application, 3) Drivers have to explicitly handle both non-M and M formats or otherwise they would suffer from issues with application compatibility or sharing buffers with other devices (one supporting only M and the other only non-M), 4) Inconsistency in the meaning of planes[0].sizeimage for non-M formats and M formats, making it impossible to use planes[0].sizeimage to set the luma plane size in the hardware for non-M formats (since it's the total size of all planes). I might have probably forgotten about something, but generally fixing the 4 above, would be a really big step forward. Best regards, Tomasz
Re: [PATCH 1/2] vicodec: Have decoder propagate changes to the CAPTURE queue
On Fri, Oct 19, 2018 at 10:00 PM Ezequiel Garcia wrote:
>
> On Fri, 2018-10-19 at 09:14 +0200, Hans Verkuil wrote:
> > On 10/18/2018 06:08 PM, Ezequiel Garcia wrote:
> > > The decoder interface (not yet merged) specifies that
> > > width and height values set on the OUTPUT queue, must
> > > be propagated to the CAPTURE queue.
> > >
> > > This is not enough to comply with the specification,
> > > which would require to properly support stream resolution
> > > changes detection and notification.
> > >
> > > However, it's a relatively small change, which fixes behavior
> > > required by some applications such as gstreamer.
> > >
> > > With this change, it's possible to run a simple T(T⁻¹) pipeline:
> > >
> > > gst-launch-1.0 videotestsrc ! v4l2fwhtenc ! v4l2fwhtdec ! fakevideosink
> > >
> > > Signed-off-by: Ezequiel Garcia
> > > ---
> > > drivers/media/platform/vicodec/vicodec-core.c | 15 +++
> > > 1 file changed, 15 insertions(+)
> > >
> > > diff --git a/drivers/media/platform/vicodec/vicodec-core.c
> > > b/drivers/media/platform/vicodec/vicodec-core.c
> > > index 1eb9132bfc85..a2c487b4b80d 100644
> > > --- a/drivers/media/platform/vicodec/vicodec-core.c
> > > +++ b/drivers/media/platform/vicodec/vicodec-core.c
> > > @@ -673,6 +673,13 @@ static int vidioc_s_fmt(struct vicodec_ctx *ctx,
> > > struct v4l2_format *f)
> > > q_data->width = pix->width;
> > > q_data->height = pix->height;
> > > q_data->sizeimage = pix->sizeimage;
> > > +
> > > + /* Propagate changes to CAPTURE queue */
> > > + if (!ctx->is_enc && V4L2_TYPE_IS_OUTPUT(f->type)) {
> >
> > Do we need !ctx->is_enc? Isn't this the same for both decoder and encoder?
> >
>
> Well, I wasn't really sure about this. The decoder document clearly
> says that changes has to be propagated to the capture queue, but that
> statement
> is not in the encoder spec.
>
> Since gstreamer didn't needs this, I decided not to add it.
>
> Perhaps it's something to correct in the encoder spec?
Hmm, in the v2 of the documentation I sent recently, the CAPTURE queue
of an encoder doesn't have width and height specified. For formats
that have the resolution embedded in bitstream metadata, this isn't
anything that the userspace should be concerned with. I forgot about
the formats that don't have the resolution in the metadata, so we
might need to bring them back. Then the propagation would have to be
there indeed.
> > > + ctx->q_data[V4L2_M2M_DST].width = pix->width;
> > > + ctx->q_data[V4L2_M2M_DST].height = pix->height;
> > > + ctx->q_data[V4L2_M2M_DST].sizeimage = pix->sizeimage;
> >
> > This is wrong: you are copying the sizeimage for the compressed format as
> > the
> > sizeimage for the raw format, which is quite different.
> >
>
> Doh, you are right.
>
> > I think you need to make a little helper function that can update the
> > width/height
> > of a particular queue and that can calculate the sizeimage correctly.
> >
I wish we had generic helpers to manage all the formats in one place,
rather than duplicating the handling in each driver. I found many
cases of drivers not reporting bytesperline correctly or not handling
some formats (other than default and so often not tested) correctly.
If we could just have the driver call
v4l2_fill_pixfmt_mp_for_format(_mp, pixelformat, width, height,
...), a lot of boilerplate and potential source of errors could be
removed. (Bonus points for helpers that can convert pixfmt_mp for a
non-M format, e.g. NV12, into a pixfmt_mp for the corresponding M
format, e.g. NV12M, so that all the drivers that can support M formats
can also handle non-M formats automatically.)
One thing to note, though, is that there might be driver specific
alignment constraints in the play, so care must be taken.
Best regards,
Tomasz
