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: Fri Aug 24 05:00:15 CEST 2018
media-tree git hash:da2048b7348a0be92f706ac019e022139e29495e
media_build
Le jeudi 23 août 2018 à 16:31 +0200, Hans Verkuil a écrit :
> > I propose adding these capabilities:
> >
> > #define V4L2_BUF_CAP_HAS_REQUESTS 0x0001
> > #define V4L2_BUF_CAP_REQUIRES_REQUESTS0x0002
> > #define V4L2_BUF_CAP_HAS_MMAP 0x0100
> > #define
Le jeudi 23 août 2018 à 10:05 +0200, Paul Kocialkowski a écrit :
> Hi,
>
> On Wed, 2018-08-22 at 14:33 -0300, Ezequiel Garcia wrote:
> > On Wed, 2018-08-22 at 16:10 +0200, Paul Kocialkowski wrote:
> > > Hi,
> > >
> > > On Tue, 2018-08-21 at 17:52 +0900, Tomasz Figa wrote:
> > > > Hi Hans, Paul,
Hi Stanimir,
On 2018-08-22 18:07, Stanimir Varbanov wrote:
Hi Vikash,
Could you give a try below patch on your environment? You should keep
your 1/4 to 3/4 patches and replace your 4/4 with the below one.
You have to drop the compatible string in firmware DT subnode (keep
only
iommus).
I
Hi all,
After reading through the comments I came to the following conclusions:
On 08/04/18 15:50, Hans Verkuil wrote:
> Hi all,
>
> While the Request API patch series addresses all the core API issues, there
> are some high-level considerations as well:
>
> 1) How can the application tell
This fixes this warning:
Documentation/media/uapi/dvb/video_function_calls.rst:9: WARNING: toctree
contains
reference to nonexisting document 'uapi/dvb/video-set-attributes'
Signed-off-by: Hans Verkuil
---
diff --git a/Documentation/media/uapi/dvb/video_function_calls.rst
Hi Helmut,
On Thu, Aug 23, 2018 at 09:52:09AM +0200, Helmut Grohne wrote:
> Clock frequencies are not exact values, but rather imprecise, physical
> properties. The present pll computation however, treats them as exact.
> It tries to compute parameters that attain the requested pix_clock
>
Hi Helmut,
Thank you for the patch.
On Thursday, 23 August 2018 10:52:09 EEST Helmut Grohne wrote:
> Clock frequencies are not exact values, but rather imprecise, physical
> properties. The present pll computation however, treats them as exact.
> It tries to compute parameters that attain the
Hi all,
Based on the discussion on the mailinglist I came to the following conclusions
which I will be implementing on top of the reqv18 patches:
On 08/16/18 12:25, Hans Verkuil wrote:
> Laurent raised a few API issues/questions in his review of the documentation.
>
> I've consolidated those in
On 08/20/18 09:17, Tomasz Figa wrote:
> Hi Hans,
>
> On Fri, Aug 17, 2018 at 7:09 PM Hans Verkuil wrote:
>>
>> On 17/08/18 12:02, Tomasz Figa wrote:
>>> On Thu, Aug 16, 2018 at 8:15 PM Mauro Carvalho Chehab
>>> wrote:
Em Thu, 16 Aug 2018 12:25:25 +0200
Hans Verkuil escreveu:
While decoding you need to make sure you do not get values < 0
or > 255. Note that since this code will also be used in userspace
utilities the clamp macro isn't used since that is kernel-only.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/vicodec/codec-fwht.c | 10 --
1 file
On 08/23/2018 09:32 AM, Hans Verkuil wrote:
> From: Hans Verkuil
>
> - add support for quantization parameters
> - support many more pixel formats
> - code simplifications
> - rename source and use proper prefixes for the codec: this makes it
> independent from the vicodec driver and easier to
Hi,
On Wed, 2018-08-22 at 14:33 -0300, Ezequiel Garcia wrote:
> On Wed, 2018-08-22 at 16:10 +0200, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Tue, 2018-08-21 at 17:52 +0900, Tomasz Figa wrote:
> > > Hi Hans, Paul,
> > >
> > > On Mon, Aug 6, 2018 at 6:29 PM Paul Kocialkowski
> > > wrote:
> > >
Clock frequencies are not exact values, but rather imprecise, physical
properties. The present pll computation however, treats them as exact.
It tries to compute parameters that attain the requested pix_clock
exactly. Failing that, it gives up.
The new implementation approximates the requested
From: Hans Verkuil
The codec source is generic and not vicodec specific. It can be used
by other drivers or userspace as well. So rename the source and header
to something more generic (codec-fwht.c/h) and prefix the defines, types
and functions with fwht_.
Signed-off-by: Hans Verkuil
---
From: Hans Verkuil
Simplify some blocktype/is_intra checks.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/vicodec/vicodec-codec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/media/platform/vicodec/vicodec-codec.c
From: Hans Verkuil
The flags field can be removed from struct vicodec_q_data.
This simplifies the flags handling elsewhere.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/vicodec/vicodec-core.c | 26 +--
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git
From: Hans Verkuil
Split off the decode and encode functions into a separate
source that can be reused elsewhere.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/vicodec/Makefile | 2 +-
.../media/platform/vicodec/codec-v4l2-fwht.c | 325
From: Hans Verkuil
Exit the loop immediately once it is clear that the plane
cannot be compressed. Also clear the PCODED bit and fix the
PCODED check (it should check for the bit) in the caller code.
Signed-off-by: Hans Verkuil
---
drivers/media/platform/vicodec/vicodec-codec.c | 10
From: Hans Verkuil
Instead of hardcoding the quantization parameter (or 'DEADZONE_WIDTH'
as it was called in the codec) make this configurable through two
controls: one for I frames, one for P frames.
Also allow changing these parameters and the GOP_SIZE parameter while
streaming.
From: Hans Verkuil
- add support for quantization parameters
- support many more pixel formats
- code simplifications
- rename source and use proper prefixes for the codec: this makes it
independent from the vicodec driver and easier to reuse in userspace
(similar to what we do for the
From: Hans Verkuil
Add support for 4:2:2, 4:4:4 and RGB 24/32 bits formats.
This makes it a lot more useful, esp. as a simple video compression
codec for use with v4l2-ctl/qvidcap.
Note that it does not do any conversion between e.g. 4:2:2 and 4:2:0
or RGB and YUV: it still just compresses
These formats are compressed 12-bit raw bayer formats with four different
pixel orders. They are similar to 10-bit bayer formats 'IPU3'.
The formats added by this patch are
V4L2_PIX_FMT_SBGGR12SP
V4L2_PIX_FMT_SGBRG12SP
V4L2_PIX_FMT_SGRBG12SP
V4L2_PIX_FMT_SRGGB12SP
Signed-off-by: Edgar Thier
23 matches
Mail list logo
