On Wed, Feb 13, 2019 at 2:53 PM Alexandre Courbot wrote:
> [snip]
> +Buffers used as reference frames can be queued back to the ``CAPTURE`` queue
> as
> +soon as all the frames they are affecting have been queued to the ``OUTPUT``
> +queue. The driver will refrain from using the reference buffer
Documents the protocol that user-space should follow when
communicating with stateless video decoders.
The stateless video decoding API makes use of the new request and tags
APIs. While it has been implemented with the Cedrus driver so far, it
should probably still be considered staging for a shor
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: Wed Feb 13 05:00:13 CET 2019
media-tree git hash:6fd369dd1cb65a032f1ab9227033ecb7b759656d
media_build git
On Tue, Feb 12, 2019 at 6:37 PM Frederic Chen
wrote:
>
> Dear Laurent and Sakari,
>
> I appreciate your messages.
>
> On Sat, 2019-02-09 at 20:17 +0200, Laurent Pinchart wrote:
> > On Sat, Feb 09, 2019 at 05:59:07PM +0200, Sakari Ailus wrote:
> > > Hi Frederic,
> > >
> > > Could you cc the devicet
On Wed, Feb 13, 2019 at 6:22 AM Ezequiel Garcia wrote:
>
> Hey Tomasz,
>
> On Tue, 2019-02-12 at 21:50 +0900, Tomasz Figa wrote:
> > Hi Maxime,
> >
> > On Mon, Feb 11, 2019 at 11:39 PM Maxime Ripard
> > wrote:
> > > Hi,
> > >
> > > Here is a new version of the H264 decoding support in the cedrus
Greetings:
This is to call your attention to a regression that showed up in kernel 4.20;
the behavior is still present in 5.0-rc6.
Please look at https://bugzilla.kernel.org/show_bug.cgi?id=202565 for details.
Also, the forum post https://bbs.archlinux.org/viewtopic.php?id=244097 has
further d
The call to of_parse_phandle() returns a node pointer with refcount
incremented thus it must be explicitly decremented here after the last
usage.
The of_find_device_by_node() takes a reference to the underlying device
structure, we also should release that reference.
Hans Verkuil says:
The cec dri
The call to of_parse_phandle() returns a node pointer with refcount
incremented thus it must be explicitly decremented here after the last
usage.
The of_find_device_by_node() takes a reference to the underlying device
structure, we also should release that reference.
This patch fixes those two issu
The call to of_parse_phandle() returns a node pointer with refcount
incremented thus it must be explicitly decremented here after the last
usage.
The of_find_device_by_node() takes a reference to the underlying device
structure, we also should release that reference.
Hans Verkuil says:
The cec dri
The call to of_parse_phandle() returns a node pointer with refcount
incremented thus it must be explicitly decremented here after the last
usage.
The of_find_device_by_node() takes a reference to the underlying device
structure, we also should release that reference.
Hans Verkuil says:
The cec dri
FYI,
Please find the Attached and send proforma invoice
Thank you
<>
Hey Tomasz,
On Tue, 2019-02-12 at 21:50 +0900, Tomasz Figa wrote:
> Hi Maxime,
>
> On Mon, Feb 11, 2019 at 11:39 PM Maxime Ripard
> wrote:
> > Hi,
> >
> > Here is a new version of the H264 decoding support in the cedrus
> > driver.
>
> Thanks for working on this. Please see my comments below.
On Tue, 2019-02-12 at 14:05 +0100, Maxime Ripard wrote:
> Hi,
>
> On Mon, Feb 11, 2019 at 04:21:47PM +0100, Hans Verkuil wrote:
> > > I think the API should be designed with 4k video in mind. So if some of
> > > these constants would be too small when dealing with 4k (even if the
> > > current HW
On Thu, Jan 17, 2019 at 7:50 AM Philipp Zabel wrote:
>
> Add a single imx-media mem2mem video device that uses the IPU IC PP
> (image converter post processing) task for scaling and colorspace
> conversion.
> On i.MX6Q/DL SoCs with two IPUs currently only the first IPU is used.
>
> The hardware on
On 2/12/19 3:34 AM, Philipp Zabel wrote:
Hi Steve,
On Mon, 2019-02-11 at 17:20 -0800, Steve Longerbeam wrote:
[...]
Should we support YUV BT.601 <-> YUV REC.709 conversions? That would
require separate encodings for input and output.
How about if we pass the input and output encodings to th
Dne torek, 12. februar 2019 ob 11:43:14 CET je Maxime Ripard napisal(a):
> Hi,
>
> On Mon, Feb 11, 2019 at 08:21:31PM +0100, Jernej Škrabec wrote:
> > > + reg = 0;
> > > + /*
> > > + * FIXME: This bit tells the video engine to use the default
> > > + * quantization matrices. This will obviously
On 2/12/19 2:17 AM, Philipp Zabel wrote:
Hi Steve,
On Mon, 2019-02-11 at 10:24 -0800, Steve Longerbeam wrote:
[...]
Looking more closely at these coefficients now, I see you are right,
they are the BT.601 YUV full-range coefficients (Y range 0 to 1, U and V
range -0.5 to 0.5). Well, not even
Dne torek, 12. februar 2019 ob 13:47:13 CET je Maxime Ripard napisal(a):
> On Mon, Feb 11, 2019 at 04:48:17PM -0300, Ezequiel Garcia wrote:
> > On Mon, 2019-02-11 at 15:39 +0100, Maxime Ripard wrote:
> > > Introduce some basic H264 decoding support in cedrus. So far, only the
> > > baseline profile
On Tue, Feb 12, 2019 at 01:48:00PM +, Kieran Bingham wrote:
> On 07/02/2019 09:13, Hans Verkuil wrote:
> > drivers/media/platform/vsp1/vsp1_drm.c:
> > drivers/media/platform/vsp1/vsp1_drm.c:336 vsp1_du_pipeline_setup_brx()
> > error: we previously assumed 'pipe->brx' could be null (see line 2
Hi,
gentle ping..
On 19-01-23 13:54, Marco Felsch wrote:
> Hi,
>
> Just a ping.
>
> The kbuilder reports some warning which I will fix in a v2 but I still
> waiting for feedback from you.
>
> Regards,
> Marco
>
> On 18-12-18 15:12, Marco Felsch wrote:
> > Hi,
> >
> > this patch set adds the
Hi Mauro,
gentle ping..
On 19-01-29 17:07, Marco Felsch wrote:
> Hi,
>
> this is the v4 of my TVP5150 series which adds the of_graph support.
> Basically this series was just rebased on top of the media-tree/master
> as mentioned by Mauro [1].
>
> I dropped commit ("media: tvp5150: fix irq_requ
Main addition is adding proper packed 32-bit YUV support.
Also fixes a long-standing vsp1 smatch warning and reorganizes the
extended control part of the documentation.
Regards,
Hans
The following changes since commit 6fd369dd1cb65a032f1ab9227033ecb7b759656d:
media: vimc: fill in bus
Hi Hans,
On 07/02/2019 09:13, Hans Verkuil wrote:
> drivers/media/platform/vsp1/vsp1_drm.c:
> drivers/media/platform/vsp1/vsp1_drm.c:336 vsp1_du_pipeline_setup_brx()
> error: we previously assumed 'pipe->brx' could be null (see line 244)
>
> smatch missed that if pipe->brx was NULL, then later
Hi Wen,
On 2/12/19 2:04 PM, Wen Yang wrote:
> Hi Hans, thank you for your comments.
> I will use my company's mailbox and submit a v2 patch to fix these problems
> tomorrow.
I made a bunch of patches fixing this yesterday. It's available here:
https://git.linuxtv.org/hverkuil/media_tree.git/log
Hi,
On Mon, Feb 11, 2019 at 04:21:47PM +0100, Hans Verkuil wrote:
> > I think the API should be designed with 4k video in mind. So if some of
> > these constants would be too small when dealing with 4k (even if the
> > current HW doesn't support this yet), then these constants would have to
> > be
Hi Maxime,
On Mon, Feb 11, 2019 at 11:39 PM Maxime Ripard
wrote:
>
> Hi,
>
> Here is a new version of the H264 decoding support in the cedrus
> driver.
Thanks for working on this. Please see my comments below.
>
> As you might already know, the cedrus driver relies on the Request
> API, and is
Hello Patrick Boettcher,
The patch 173a64cb3fcf: "[media] dib8000: enhancement" from Apr 22,
2013, leads to the following static checker warning:
drivers/media/dvb-frontends/dib8000.c:2132 dib8000_get_init_prbs()
error: buffer overflow 'lut_prbs_2k' 14 <= 14
drivers/media/dvb-fro
On Mon, Feb 11, 2019 at 04:48:17PM -0300, Ezequiel Garcia wrote:
> On Mon, 2019-02-11 at 15:39 +0100, Maxime Ripard wrote:
> > Introduce some basic H264 decoding support in cedrus. So far, only the
> > baseline profile videos have been tested, and some more advanced features
> > used in higher prof
Hi Steve,
On Mon, 2019-02-11 at 17:20 -0800, Steve Longerbeam wrote:
[...]
> > Should we support YUV BT.601 <-> YUV REC.709 conversions? That would
> > require separate encodings for input and output.
>
> How about if we pass the input and output encodings to the init ic task
> functions, but fo
Hi,
On Mon, Feb 11, 2019 at 08:21:31PM +0100, Jernej Škrabec wrote:
> > + reg = 0;
> > + /*
> > +* FIXME: This bit tells the video engine to use the default
> > +* quantization matrices. This will obviously need to be
> > +* changed to support the profiles supporting custom
> > +
On Mon, Feb 11, 2019 at 02:12:25PM -0300, Ezequiel Garcia wrote:
> On Mon, 2019-02-11 at 15:39 +0100, Maxime Ripard wrote:
> >
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index d6eed479c3a6..6fc955926bdb 100644
> > --- a/include/uapi/linux/videodev2.h
> > +
Hi Steve,
On Mon, 2019-02-11 at 10:24 -0800, Steve Longerbeam wrote:
[...]
> Looking more closely at these coefficients now, I see you are right,
> they are the BT.601 YUV full-range coefficients (Y range 0 to 1, U and V
> range -0.5 to 0.5). Well, not even that -- the coefficients are not
> be
Dear Laurent and Sakari,
On Sat, 2019-02-09 at 20:20 +0200, Laurent Pinchart wrote:
> Hello Frederic,
>
> On Sat, Feb 09, 2019 at 05:59:35PM +0200, Sakari Ailus wrote:
> > Hi Frederic,
> >
> > Thanks for the patchset.
> >
> > Could you also cc the devicetree list, please?
> >
> > On Fri, Feb
Dear Laurent and Sakari,
I appreciate your messages.
On Sat, 2019-02-09 at 20:17 +0200, Laurent Pinchart wrote:
> On Sat, Feb 09, 2019 at 05:59:07PM +0200, Sakari Ailus wrote:
> > Hi Frederic,
> >
> > Could you cc the devicetree list, please?
> >
> > On Fri, Feb 01, 2019 at 07:21:25PM +0800, Fr
Got it, I'll submit another patch after your patch merged.
Thanks,
Fish
Hans Verkuil 於 2019年2月8日 週五 下午5:58寫道：
>
> On 1/30/19 10:11 AM, Fish Lin wrote:
> > Add following V4L2 QP parameters for H.264:
> > * V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MIN_QP
> > * V4L2_CID_MPEG_VIDEO_H264_I_FRAME_MAX_QP
>
35 matches
Mail list logo
