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
[PATCH v1] media: ov13858: Check for possible null pointer
Check for possible null pointer to avoid crash. Signed-off-by: Chiranjeevi Rapolu --- drivers/media/i2c/ov13858.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/ov13858.c b/drivers/media/i2c/ov13858.c index c8bbc1f..45bb872 100644 --- a/drivers/media/i2c/ov13858.c +++ b/drivers/media/i2c/ov13858.c @@ -1612,7 +1612,8 @@ static int ov13858_init_controls(struct ov13858 *ov13858) OV13858_NUM_OF_LINK_FREQS - 1, 0, link_freq_menu_items); - ov13858->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY; + if (ov13858->link_freq) + ov13858->link_freq->flags |= V4L2_CTRL_FLAG_READ_ONLY; pixel_rate_max = link_freq_to_pixel_rate(link_freq_menu_items[0]); pixel_rate_min = link_freq_to_pixel_rate(link_freq_menu_items[1]); @@ -1635,7 +1636,8 @@ static int ov13858_init_controls(struct ov13858 *ov13858) ov13858->hblank = v4l2_ctrl_new_std( ctrl_hdlr, &ov13858_ctrl_ops, V4L2_CID_HBLANK, hblank, hblank, 1, hblank); - ov13858->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY; + if (ov13858->hblank) + ov13858->hblank->flags |= V4L2_CTRL_FLAG_READ_ONLY; exposure_max = mode->vts_def - 8; ov13858->exposure = v4l2_ctrl_new_std( -- 2.7.4
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&id=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 :ref:`VIDIOC
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&id=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: [RFC] Stateless codecs: how to refer to reference frames
Hi Hans, On Wed, Oct 24, 2018 at 6:52 PM Hans Verkuil wrote: > > HI Alexandre, > > On 10/24/2018 10:16 AM, Alexandre Courbot wrote: > > Hi Hans, > > > > On Fri, Oct 19, 2018 at 6:40 PM Hans Verkuil wrote: > >> > >> From Alexandre's '[RFC PATCH v3] media: docs-rst: Document m2m stateless > >> video decoder interface': > >> > >> On 10/19/18 10:09, Alexandre Courbot wrote: > >>> Two points being currently discussed have not been changed in this > >>> revision due to lack of better idea. Of course this is open to change: > >> > >> > >> > >>> * The other hot topic is the use of capture buffer indexes in order to > >>> reference frames. I understand the concerns, but I doesn't seem like > >>> we have come with a better proposal so far - and since capture buffers > >>> are essentially well, frames, using their buffer index to directly > >>> reference them doesn't sound too inappropriate to me. There is also > >>> the restriction that drivers must return capture buffers in queue > >>> order. Do we have any concrete example where this scenario would not > >>> work? > >> > >> I'll stick to decoders in describing the issue. Stateless encoders probably > >> do not have this issue. > >> > >> To recap: the application provides a buffer with compressed data to the > >> decoder. After the request is finished the application can dequeue the > >> decompressed frame from the capture queue. > >> > >> In order to decompress the decoder needs to access previously decoded > >> reference frames. The request passed to the decoder contained state > >> information containing the buffer index (or indices) of capture buffers > >> that contain the reference frame(s). > >> > >> This approach puts restrictions on the framework and the application: > >> > >> 1) It assumes that the application can predict the capture indices. > >> This works as long as there is a simple relationship between the > >> buffer passed to the decoder and the buffer you get back. > >> > >> But that may not be true for future codecs. And what if one buffer > >> produces multiple capture buffers? (E.g. if you want to get back > >> decompressed slices instead of full frames to reduce output latency). > >> > >> This API should be designed to be future-proof (within reason of course), > >> and I am not at all convinced that future codecs will be just as easy > >> to predict. > >> > >> 2) It assumes that neither drivers nor applications mess with the buffers. > >> One case that might happen today is if the DMA fails and a buffer is > >> returned marked ERROR and the DMA is retried with the next buffer. There > >> is nothing in the spec that prevents you from doing that, but it will mess > >> up the capture index numbering. And does the application always know in > >> what order capture buffers are queued? Perhaps there are two threads: one > >> queueing buffers with compressed data, and the other dequeueing the > >> decompressed buffers, and they are running mostly independently. > >> > >> > >> I believe that assuming that you can always predict the indices of the > >> capture queue is dangerous and asking for problems in the future. > >> > >> > >> I am very much in favor of using a dedicated cookie. The application sets > >> it for the compressed buffer and the driver copies it to the uncompressed > >> capture buffer. It keeps track of the association between capture index > >> and cookie. If a compressed buffer decompresses into multiple capture > >> buffers, then they will all be associated with the same cookie, so > >> that simplifies how you refer to reference frames if they are split > >> over multiple buffers. > >> > >> The codec controls refer to reference frames by cookie(s). > > > > So as discussed yesterday, I understand your issue with using buffer > > indexes. The cookie idea sounds like it could work, but I'm afraid you > > could still run into issues when you don't have buffer symmetry. > > > > For instance, imagine that the compressed buffer contains 2 frames > > worth of data. In this case, the 2 dequeued capture buffers would > > carry the same cookie, making it impossible to reference either frame > > unambiguously. > > But this is a stateless codec, so each compressed buffer contains only > one frame. That's the responsibility of the bitstream parser to ensure > that. Just as we are making the design future-proof by considering the case where we get one buffer per slice, shouldn't we think about the (currently hypothetical) case of a future codec specification in which slices contain information that is relevant for several consecutive frames? It may be a worthless design as classic reference frames are probably enough to carry redundant information, but wanted to point the scenario just in case. > > The whole idea of the stateless codec is that you supply only one frame > at a time to the codec. > > If someone indeed puts multiple frames into a single buffer, then > the behavior is likely undefined. Does anyone have any idea wha
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(&pixfmt_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
