On Thu, 11 Jan 2018 17:26:59 +0100
Nicolas Ferre wrote:
> Update Wenyou Yang email address.
> Take advantage of this update to move this entry to the MICROCHIP / ATMEL
> location and add the DT binding documentation link.
>
> Signed-off-by: Nicolas Ferre
> Acked-by: Wenyou Yang
Applied.
Than
Make sure the default value at least passes the std_validate() tests.
Signed-off-by: Boris Brezillon
---
drivers/media/v4l2-core/v4l2-ctrls.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core
Width/height and 4CC formats are expressed using u32 types everywhere,
let's fix the v4l2_fill_pixfmt[_mp]() prototypes to do the same.
Signed-off-by: Boris Brezillon
---
Changes in v5:
* New patch
---
drivers/media/v4l2-core/v4l2-common.c | 5 +++--
include/media/v4l2-common.h
this
vdev to the media device.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
--
Changes from v3:
* Rework the media controller registration logic (Boris)
* Fix media controller deregistration (Jonas)
Changes from v2:
* Use kvasprintf instead of kmalloc and snprintf.
* Fix missing
Users can define custom sizeimage and bytesperline as long as they're
big enough to store the amount of pixels required for a specific
width/height under a specific format. Avoid overriding those fields in
this case.
Signed-off-by: Boris Brezillon
---
Hello Hans,
The sizeimage/bytespe
essed comments from Hans and Tomasz on the pixel format
helpers.
Boris Brezillon (8):
media: v4l2-common: Fix v4l2_fill_pixfmt[_mp]() prototypes
media: v4l2-common: Add an helper to apply frmsize constraints
media: v4l2-common: Support custom imagesize/bytesperline in
fill_pixfmt()
rockchi
From: Ezequiel Garcia
Rework the way controls are registered by the driver,
so it can support non-standard controls, such as those
used by stateless codecs.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
--
Changes from v4:
* Remove unused var in rockchip_vpu_ctrls_setup
-off-by: Boris Brezillon
--
Changes from v4:
* Remove vpu_common.h inclusion
* Set ->requires_requests from s_fmt() instead of fixing it at queue
creation time (suggested by Hans)
Changes from v3:
* Update things according to changes done in the patch introducing
custom media control
We're about to add prototypes for the vb2/v4l2 helpers shared by the
encoder/decoder logic in this file, so let's pick a name that reflects
that (rockchip_vpu_common.h was a bit to generic).
Suggested-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
---
Changes from v3:
* None
Ch
The code in rockchip_vpu_v4l2 was hardcoded for encoder support.
Modify it more generic to support the decoder case so that we can
re-use the same vb2/v4l2 ops for both devices.
Co-developed-by: Ezequiel Garcia
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
---
Changes from v4
Use the v4l2_apply_frmsize_constraints() helper instead of open-coding
it.
Signed-off-by: Boris Brezillon
---
Changes in v5:
* New patch
---
.../media/rockchip/vpu/rockchip_vpu_enc.c | 44 ++-
1 file changed, 14 insertions(+), 30 deletions(-)
diff --git a/drivers/staging
The rockchip VPU driver is open-coding this logic which seems pretty
generic. Let's provide an helper to apply the min/max and alignment
constraints on width/height.
Signed-off-by: Boris Brezillon
---
Changes in v5:
* New patch
---
drivers/media/v4l2-core/v4l2-common.c
From: Jonas Karlman
Add necessary bits to support MPEG2 decoding on RK3288.
Signed-off-by: Jonas Karlman
Signed-off-by: Boris Brezillon
---
Changes from v4:
* Stop including rockchip_vpu_common.h
Changes from v3:
* Coding style improvements (Jonas)
* Use ALIGN() instead of div+shift (Jonas
right order: first the coded-format side, then the other,
such that width and height on the raw format side can be taken from
the coded format.
Let's provide a helper that will reset both formats and make sure this
is done in the right order.
Signed-off-by: Boris Brezillon
---
Changes from
drv.c) queue_init() since it will be used
to initialize both type of queues.
The implementation itself will be patched to support the decoding case
when decoder support is added.
Suggested-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
---
Changes from v3:
* None
Changes from v2:
* New
From: Jonas Karlman
Only adds structs and helpers to allow supporting MPEG-2 decoding on
rockchip SoCs. Support for RK3399 and RK3288 will be added in separate
commits
Signed-off-by: Jonas Karlman
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
--
Changes from v4:
* Define
From: Jonas Karlman
Add the necessary bits to support MPEG2 decoding on RK3399.
Signed-off-by: Jonas Karlman
Signed-off-by: Boris Brezillon
---
Changes from v4:
* Stop including rockchip_vpu_common.h
Changes from v3:
* New patch (was part of another patch before)
---
drivers/staging/media
From: Ezequiel Garcia
Introduce support for the Request API. Although the JPEG encoder
does not mandate using the Request API, it's perfectly possible to
use it, if the application wants to.
Signed-off-by: Ezequiel Garcia
Signed-off-by: Boris Brezillon
--
Changes from v3:
* None
Changes
v4l2-mem2mem.c for such situations (same for
> stateful codecs) since it's too complex for drivers to get right IMHO.
>
> Regards,
>
> Hans
>
> Signed-off-by: Hans Verkuil
FWIW,
Tested-by: Boris Brezillon
Reviewed-by: Boris Brezillon
Note that I haven't
On Wed, 22 May 2019 15:39:37 +0900
Tomasz Figa wrote:
> > It would be premature to state that we are excluding. We are just
> > trying to find one format to get things upstream, and make sure we have
> > a plan how to extend it. Trying to support everything on the first try
> > is not going to wo
On Wed, 22 May 2019 09:29:24 +0200
Boris Brezillon wrote:
> On Wed, 22 May 2019 15:39:37 +0900
> Tomasz Figa wrote:
>
> > > It would be premature to state that we are excluding. We are just
> > > trying to find one format to get things upstream, and make sure we have
1.
>
> This patch just renames, no functional changes.
>
> Signed-off-by: Philipp Zabel
Reviewed-by: Boris Brezillon
> ---
> Changes since v1 [1]:
> - Rebased onto "[PATCH v6] Add MPEG-2 decoding to Rockchip VPU" series.
>
> [1] https://patchw
On Wed, 29 May 2019 11:54:17 +0200
Philipp Zabel wrote:
> It can be helpful to know which video device was registered at which
> device node.
>
> Signed-off-by: Philipp Zabel
Reviewed-by: Boris Brezillon
> ---
> drivers/staging/media/hantro/hantro_drv.c | 3 ++-
&g
off-by: Philipp Zabel
Reviewed-by: Boris Brezillon
> ---
> drivers/staging/media/hantro/hantro.h | 2 ++
> drivers/staging/media/hantro/hantro_drv.c | 13 +
> 2 files changed, 15 insertions(+)
>
> diff --git a/drivers/staging/media/hantro/hantro.h
> b/d
On Wed, 29 May 2019 11:54:19 +0200
Philipp Zabel wrote:
> The i.MX8MQ bindings will use different IRQ names ("g1" instead of
> "vdpu", and "g2"), so make them configurable. This also allows to
> register more than two IRQs, which will be required for i.MX8MM support
> later (it will add "h1" inst
On Wed, 29 May 2019 11:54:20 +0200
Philipp Zabel wrote:
> Add support for multiple register ranges with SoC specific names.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/staging/media/hantro/hantro.h | 7 ++-
> drivers/staging/media/hantro/hantro_drv.c | 25 +--
overriding those fields in this case.
> > >>
> > >> We could possibly do the same for bytesperline, but it gets tricky when
> > >> dealing with !MPLANE definitions, so this case is omitted for now and
> > >> ->bytesperline is always overwrit
On Wed, 29 May 2019 09:26:32 -0300
Mauro Carvalho Chehab wrote:
> Em Wed, 29 May 2019 14:16:33 +0200
> Boris Brezillon escreveu:
>
> > On Wed, 29 May 2019 08:58:54 -0300
> > Mauro Carvalho Chehab wrote:
> >
> > > Em Wed, 29 May 2019 13:43:2
On Wed, 29 May 2019 14:31:03 +0200
Hans Verkuil wrote:
> On 5/29/19 2:16 PM, Boris Brezillon wrote:
> > On Wed, 29 May 2019 08:58:54 -0300
> > Mauro Carvalho Chehab wrote:
> >
> >> Em Wed, 29 May 2019 13:43:20 +0200
> >> Hans Verkuil escreveu:
> >
On Wed, 29 May 2019 15:20:52 +0200
Philipp Zabel wrote:
> Hi Boris,
>
> thank you for the review.
>
> On Wed, 2019-05-29 at 13:46 +0200, Boris Brezillon wrote:
> > On Wed, 29 May 2019 11:54:20 +0200
> > Philipp Zabel wrote:
> >
> > > Add sup
On Wed, 29 May 2019 11:04:35 -0300
Ezequiel Garcia wrote:
> On Wed, 2019-05-29 at 14:31 +0200, Hans Verkuil wrote:
> > On 5/29/19 2:16 PM, Boris Brezillon wrote:
> > > On Wed, 29 May 2019 08:58:54 -0300
> > > Mauro Carvalho Chehab wrote:
> > >
> &
On Wed, 29 May 2019 16:06:10 +0200
Boris Brezillon wrote:
> On Wed, 29 May 2019 11:04:35 -0300
> Ezequiel Garcia wrote:
>
> > On Wed, 2019-05-29 at 14:31 +0200, Hans Verkuil wrote:
> > > On 5/29/19 2:16 PM, Boris Brezillon wrote:
> > > > On Wed, 29 M
On Wed, 29 May 2019 17:42:58 +0200
Hans Verkuil wrote:
> On 5/29/19 5:36 PM, Ezequiel Garcia wrote:
> > On Wed, 2019-05-29 at 16:41 +0200, Hans Verkuil wrote:
> >> On 5/3/19 1:42 PM, Boris Brezillon wrote:
> >>> Make sure the default value at least p
On Wed, 29 May 2019 13:59:50 -0300
Ezequiel Garcia wrote:
> On Wed, 2019-05-29 at 18:06 +0200, Boris Brezillon wrote:
> > On Wed, 29 May 2019 17:42:58 +0200
> > Hans Verkuil wrote:
> >
> > > On 5/29/19 5:36 PM, Ezequiel Garcia wrote:
> > > > On We
Hi Ezequiel,
On Wed, 29 May 2019 16:28:11 -0300
Ezequiel Garcia wrote:
> Rework std_init adding an explicit initialization for
> compound controls.
>
> While here, make sure the control is initialized to zero,
> before providing default values for all its fields.
>
> Signed-off-by: Ezequiel Ga
is not aligned on the std_init_compound() open
parens.
The patch looks good otherwise:
Reviewed-by: Boris Brezillon
> {
> struct v4l2_ctrl_mpeg2_slice_params *p_mpeg2_slice_params;
>
> + idx *= ctrl->elem_size;
> + memset(ptr.p + idx, 0, ct
On Thu, 30 May 2019 14:19:08 -0300
Ezequiel Garcia wrote:
> These two control types don't really need a default value,
> as they are not expected to carry any value.
>
> However, it's slightly clearer to initialize them explicitly
> instead of falling back to the switch default.
If they don't c
.MX8MM support
> later (it will add "h1" instead of "vepu").
>
> Signed-off-by: Philipp Zabel
Reviewed-by: Boris Brezillon
> ---
> Changes since v2 [1]:
> - Introduce struct hantro_irq, containing irq name and handler
> - Replace separate integrated arra
ev: Pointer to device for convenient logging using
> * dev_ macros.
> * @clocks: Array of clock handles.
> - * @base:Mapped address of VPU registers.
> + * @bases: Mapped addresses of VPU registers.
I find the name &#
On Fri, 31 May 2019 10:55:19 +0200
Philipp Zabel wrote:
> On i.MX8MQ/MM a separate control block contains registers for per-core
> resets, clock gating, and fuse register control.
>
> Signed-off-by: Philipp Zabel
Reviewed-by: Boris Brezillon
> ---
> drivers/staging/med
On Fri, 31 May 2019 10:55:20 +0200
Philipp Zabel wrote:
> Add devicetree binding documentation for the Hantro G1/G2 VPU on i.MX8MQ
> and for the Hantro G1/G2/H1 VPU on i.MX8MM.
>
> Signed-off-by: Philipp Zabel
> ---
> .../devicetree/bindings/media/imx8m-vpu.txt | 56 +++
Hm,
: Philipp Zabel
Reviewed-by: Boris Brezillon
> ---
> New in v3.
> ---
> drivers/staging/media/hantro/hantro.h| 6 ++
> drivers/staging/media/hantro/hantro_drv.c| 5 +
> drivers/staging/media/hantro/imx8m_vpu_hw.c | 10 ++
> drivers/stagi
to be passed through controls) should be pretty
easy, let's mandate that all slices be prepended with ANNEX B start
codes.
If we ever need to support AVC headers, we can add a new menu control
to select the type of NAL header to use.
Signed-off-by: Boris Brezillon
---
Note: we might want to
We are about to add a menu control, so let's make the code more generic
to support other control types.
Signed-off-by: Boris Brezillon
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 47 -
drivers/staging/media/sunxi/cedrus/cedrus.h | 3 +-
2 files changed, 29 inser
n specific. What's provided by the bitstream is a
list of references that will be used to decode a frame
* ... (add your own)
Feel free to comment on these changes and/or propose alternatives.
Regards,
Boris
Boris Brezillon (6):
media: uapi: h264: Clarify our expectations regarding NAL hea
The H264 uAPI has been modified to expose 2 operation modes: per slice
and per frame decoding.
The cedrus driver only supports per-slice decoding for now.
Signed-off-by: Boris Brezillon
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 13 +
1 file changed, 13 insertions(+)
diff
Those lists can be extracted from the dpb, let's simplify userspace
life and build that list kernel-side (generic helpers will be provided
for drivers that need this list).
Signed-off-by: Boris Brezillon
---
Documentation/media/uapi/v4l/ext-ctrls-codec.rst | 9 -
1 file chang
ing to the
spec, it's actually an array. Make it more explicit by setting dims[0]
and adding a comment explaining why we have this limitation.
Signed-off-by: Boris Brezillon
---
drivers/staging/media/sunxi/cedrus/cedrus.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/stagi
ned-off-by: Boris Brezillon
---
.../media/uapi/v4l/ext-ctrls-codec.rst| 42 ++-
drivers/media/v4l2-core/v4l2-ctrls.c | 9
include/media/h264-ctrls.h| 13 ++
3 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/Documentation/
+Maxime
Oops, just realized Maxime was not Cc-ed on this series.
On Mon, 3 Jun 2019 14:30:20 +0200
Thierry Reding wrote:
> On Mon, Jun 03, 2019 at 01:09:42PM +0200, Boris Brezillon wrote:
> > Some stateless decoders don't support per-slice decoding (or at least
> > not in a
This is needed if we want the core to be able to check _MPLANE support
without having to call the ->vdioc_querycap() hook.
Signed-off-by: Boris Brezillon
---
Changes in v5:
- Drop the fimc-lite and fimc-isp-video hack
Changes in v4:
- Add a hack in fimc-lite and fimc-isp-video ->qu
ad.
Signed-off-by: Boris Brezillon
---
Changes in v5:
- None
Changes in v4:
- None
Changes in v3:
- Send this patch separately (was previously part of the EXT_BUF/FMT
rework)
Changes in v2:
- None
---
drivers/media/pci/intel/ipu3/ipu3-cio2.c | 2 +-
drivers/media/platform/exynos-gsc
On Mon, 3 Jun 2019 16:05:26 +0200
Thierry Reding wrote:
> On Mon, Jun 03, 2019 at 02:51:13PM +0200, Boris Brezillon wrote:
> > +Maxime
> >
> > Oops, just realized Maxime was not Cc-ed on this series.
> >
> > On Mon, 3 Jun 2019 14:30:20 +0200
> > Thierry
On Mon, 03 Jun 2019 14:52:44 -0400
Nicolas Dufresne wrote:
> > > - Dropping the DPB concept in H.264/H.265
> > >
> > > As far as I could understand, the decoded picture buffer (DPB) is a
> > > concept that only makes sense relative to a decoder implementation. The
> > > spec mentions how to mana
On Mon, 3 Jun 2019 14:45:37 +0200
Hans Verkuil wrote:
> On 5/31/19 10:55 AM, Philipp Zabel wrote:
> > For now this just enables MPEG-2 decoding on the Hantro G1 on i.MX8MQ.
> >
> > Signed-off-by: Philipp Zabel
> > ---
> > Changes since v2 [1]:
> > - Adapted to changes in patches 4 and 5
> >
>
On Tue, 4 Jun 2019 09:02:56 +0200
Hans Verkuil wrote:
> On 6/3/19 3:58 PM, Boris Brezillon wrote:
> > Support for multiplanar and singleplanar formats is mutually exclusive,
> > at least in practice. In our attempt to unify support for support for
> > mplane and !mplane in
ad.
Signed-off-by: Boris Brezillon
---
Changes in v6:
- Add missing parens in a test
Changes in v5:
- None
Changes in v4:
- None
Changes in v3:
- Send this patch separately (was previously part of the EXT_BUF/FMT
rework)
Changes in v2:
- None
---
drivers/media/pci/intel/ipu3/ipu3-cio2.
This is needed if we want the core to be able to check _MPLANE support
without having to call the ->vdioc_querycap() hook.
Signed-off-by: Boris Brezillon
---
Changes in v6:
- None
Changes in v5:
- Drop the fimc-lite and fimc-isp-video hack
Changes in v4:
- Add a hack in fimc-lite and fimc-
On Tue, 4 Jun 2019 09:02:56 +0200
Hans Verkuil wrote:
> On 6/3/19 3:58 PM, Boris Brezillon wrote:
> > Support for multiplanar and singleplanar formats is mutually exclusive,
> > at least in practice. In our attempt to unify support for support for
> > mplane and !mplane in
On Tue, 4 Jun 2019 10:12:10 +0200
Thierry Reding wrote:
> On Mon, Jun 03, 2019 at 07:55:48PM -0400, Nicolas Dufresne wrote:
> > Le lundi 03 juin 2019 à 23:48 +0200, Jernej Škrabec a écrit :
> > > Dne ponedeljek, 03. junij 2019 ob 13:09:45 CEST je Boris Brezillo
On Tue, 4 Jun 2019 10:31:57 +0200
Thierry Reding wrote:
> > > > > - Using flags
> > > > >
> > > > > The current MPEG-2 controls have lots of u8 values that can be
> > > > > represented as flags. Using flags also helps with padding.
> > > > > It's unlikely that we'll get more than 64 flags, so us
On Tue, 4 Jun 2019 10:55:03 +0200
Thierry Reding wrote:
> On Mon, Jun 03, 2019 at 02:52:44PM -0400, Nicolas Dufresne wrote:
> [...]
> > There is one thing that come up though, if we enable per-frame decoding
> > on top of per-slice decoder (like Cedrus), won't we force userspace to
> > always com
On Tue, 4 Jun 2019 09:15:28 +
Jonas Karlman wrote:
> On 2019-06-04 11:06, Thierry Reding wrote:
> > On Tue, Jun 04, 2019 at 10:49:21AM +0200, Boris Brezillon wrote:
> >> On Tue, 4 Jun 2019 10:31:57 +0200
> >> Thierry Reding wrote:
> >>
> >&g
On Tue, 4 Jun 2019 09:06:25 +0200
Boris Brezillon wrote:
> Support for multiplanar and singleplanar formats is mutually exclusive,
> at least in practice. In our attempt to unify support for support for
s/support for support for/support for/
> m
1.
>
> This patch just renames, no functional changes.
>
> Signed-off-by: Philipp Zabel
> Reviewed-by: Boris Brezillon
> ---
> MAINTAINERS | 4 +-
> drivers/staging/media/Kconfig | 2 +-
> drivers/staging/media/Makefi
CAP_M2M_MPLANE means the device supports _MPLANE formats for both
capture and output. Adjust the check to avoid EINVAL errors on
such devices.
Fixes: 366c719d6479 ("media: v4l2: Get rid of
->vidioc_enum_fmt_vid_{cap,out}_mplane")
Reported-by: Maxime Jourdan
Signed-off-by: Bo
On Thu, 6 Jun 2019 12:53:57 +0900
Tomasz Figa wrote:
> On Thu, Jun 6, 2019 at 1:46 AM Boris Brezillon
> wrote:
> >
> > CAP_M2M_MPLANE means the device supports _MPLANE formats for both
> > capture and output. Adjust the check to avoid EINVAL errors on
> &g
On Wed, 05 Jun 2019 22:48:08 +0200
Paul Kocialkowski wrote:
> Hi,
>
> Le mardi 04 juin 2019 à 10:16 +0200, Thierry Reding a écrit :
> > On Mon, Jun 03, 2019 at 05:37:11PM +0200, Boris Brezillon wrote:
> > > On Mon, 3 Jun 2019 16:05:26 +0200
> > > Thierry Redin
On Wed, 05 Jun 2019 22:57:21 +0200
Paul Kocialkowski wrote:
> Hi,
>
> Le lundi 03 juin 2019 à 13:09 +0200, Boris Brezillon a écrit :
> > We are about to add a menu control, so let's make the code more generic
> > to support other control types.
>
> Did y
e:
> > > > Le lundi 03 juin 2019 à 23:48 +0200, Jernej Škrabec a écrit :
> > > > > Dne ponedeljek, 03. junij 2019 ob 13:09:45 CEST je Boris Brezillon
> > > > > napisal(a):
> > > > > > The driver only supports per-slice decod
On Thu, 6 Jun 2019 08:51:59 +0200
Boris Brezillon wrote:
> On Thu, 6 Jun 2019 12:53:57 +0900
> Tomasz Figa wrote:
>
> > On Thu, Jun 6, 2019 at 1:46 AM Boris Brezillon
> > wrote:
> > >
> > > CAP_M2M_MPLANE means the device supports _MPLANE formats fo
On Wed, 5 Jun 2019 13:22:42 +0200
Boris Brezillon wrote:
> On Fri, 31 May 2019 10:55:14 +0200
> Philipp Zabel wrote:
>
> > Rename the driver and all relevant identifiers from Rockchip to Hantro,
> > as other Hantro IP based VPU implementations can be supported by the
>
default.
>
> Signed-off-by: Ezequiel Garcia
Reviewed-by: Boris Brezillon
> ---
> Changes from v2:
> * Initialize the controls to zero, instead of default.
>
> Changes from v1:
> * No change.
> ---
> drivers/media/v4l2-core/v4l2-ctrls.c | 4
> 1 file cha
f-by: Ezequiel Garcia
Reviewed-by: Boris Brezillon
> ---
> Changes from v2:
> * Align parameters to parenthesis
> * Drop unneeded zero initialization
>
> Changes from v1:
> * Drop the s/break/return replacements
> * Drop unneeded default cases
> * Fix memset to take account of
ideration.
> + */
> +static inline struct vb2_buffer *vb2_get_buffer(struct vb2_queue *q,
> + unsigned int index)
> +{
> + if (q->num_buffers > 0 && index < q->num_buffers)
No need to check q->num_buffers > 0 because in that case
i
On Thu, 6 Jun 2019 12:44:21 -0300
Ezequiel Garcia wrote:
> Hi,
>
> This patchset introduces a new vb2_get_buffer accessor and then
> uses it on all the drivers that are accessing videobuf2
> private buffer array directly.
Just curious, how did you find all occurrences of direct q->bufs[]
acces
On Thu, 06 Jun 2019 15:13:00 -0300
Ezequiel Garcia wrote:
> On Thu, 2019-06-06 at 19:43 +0200, Boris Brezillon wrote:
> > On Thu, 6 Jun 2019 12:44:21 -0300
> > Ezequiel Garcia wrote:
> >
> > > Hi,
> > >
> > > This patchset introduces a new v
On Fri, 7 Jun 2019 16:56:09 +0300
Dan Carpenter wrote:
> Thus the address of "&ctx->dev->variant->codec_ops[codec_mode]"
> can't possibly be NULL.
>
> Signed-off-by: Dan Carpenter
Reviewed-by: Boris Brezillon
> ---
> drivers/staging/media/roc
to be passed through controls) should be pretty
easy, let's mandate that all slices be prepended with ANNEX B start
codes.
If we ever need to support AVC headers, we can add a new menu control
to select the type of NAL header to use.
Signed-off-by: Boris Brezillon
---
Changes in v2:
* None
n specific. What's provided by the bitstream is a
list of references that will be used to decode a frame
* ... (add your own)
Feel free to comment on these changes and/or propose alternatives.
Regards,
Boris
Changes in v2:
* Allow decoding multiple slices in per-slice decoding mode
* Minor doc
ned-off-by: Boris Brezillon
---
Changes in v2:
* Allow decoding multiple slices in per-slice decoding mode
* Minor doc improvement/fixes
---
.../media/uapi/v4l/ext-ctrls-codec.rst| 46 ++-
drivers/media/v4l2-core/v4l2-ctrls.c | 9
include/media/h2
Those lists can be extracted from the dpb, let's simplify userspace
life and build that list kernel-side (generic helpers will be provided
for drivers that need this list).
Signed-off-by: Boris Brezillon
---
Changes in v2:
* None
---
Documentation/media/uapi/v4l/ext-ctrls-codec.rs
On Mon, 10 Jun 2019 10:52:47 +0200
Boris Brezillon wrote:
> Hello,
>
> This is a first batch of adjustments to the stateless H264 decoder
> uAPI. The first one is about adding support for per-frame decoding,
> which is the only mode supported on some codecs (the hantro G1 block
On Wed, 12 Jun 2019 08:14:35 +
Jonas Karlman wrote:
> On 2019-06-11 14:50, Philipp Zabel wrote:
> > Rename the driver and all relevant identifiers from Rockchip to Hantro,
> > as other Hantro IP based VPU implementations can be supported by the
> > same driver.
> > The RK3288 decoder is Hantr
On Wed, 12 Jun 2019 10:00:45 +0200
Hans Verkuil wrote:
> On 6/12/19 9:55 AM, Hans Verkuil wrote:
> > On 6/11/19 2:50 PM, Philipp Zabel wrote:
> >> There are several other SoCs that contain Hantro IP based VPUs, such as
> >> NXP i.MX8MQ (Hantro G1 and G2) and i.MX8MM (Hantro G1, G2, and H1). To
On Thu, 13 Jun 2019 12:10:39 -0300
Ezequiel Garcia wrote:
> From: Pawel Osciak
>
> Add the parsed VP8 frame pixel format and controls, to be used
> with the new stateless decoder API for VP8 to provide parameters
> for accelerator (aka stateless) codecs.
>
> Signed-off-by: Pawel Osciak
> Sign
On Thu, 13 Jun 2019 12:10:40 -0300
Ezequiel Garcia wrote:
> +static void cfg_parts(struct hantro_ctx *ctx,
> + const struct v4l2_ctrl_vp8_frame_header *hdr)
> +{
> + struct hantro_dev *vpu = ctx->dev;
> + struct vb2_v4l2_buffer *vb2_src;
> + u32 first_part_offset =
cfg->type can be overridden by v4l2_ctrl_fill() and the new value is
stored in the local type var. Fix the tests to use this local var.
Fixes: 0996517cf8ea ("V4L/DVB: v4l2: Add new control handling framework")
Cc:
Signed-off-by: Boris Brezillon
---
drivers/media/v4l2-core/v4l
On Wed, 26 Jun 2019 13:33:41 +0200
Paul Kocialkowski wrote:
> Hi,
>
> On Mon, 2019-06-10 at 10:52 +0200, Boris Brezillon wrote:
> > Those lists can be extracted from the dpb, let's simplify userspace
> > life and build that list kernel-side (generic helpers will be pro
On Wed, 26 Jun 2019 13:30:38 +0200
Paul Kocialkowski wrote:
> Hi,
>
> On Mon, 2019-06-10 at 10:52 +0200, Boris Brezillon wrote:
> > Some stateless decoders don't support per-slice decoding (or at least
> > not in a way that would make them efficient or easy to use).
to be passed through controls) should be pretty
easy, let's mandate that all slices be prepended with ANNEX B start
codes.
If we ever need to support AVC headers, we can add a new menu control
to select the type of NAL header to use.
Signed-off-by: Boris Brezillon
Reviewed-by: Paul Kocialk
R-b on patch 1 and 2
Changes in v2:
* Allow decoding multiple slices in per-slice decoding mode
* Minor doc improvements/fixes
Boris Brezillon (3):
media: uapi: h264: Clarify our expectations regarding NAL header
format
media: uapi: h264: Add the concept of decoding mode
media: u
Those lists can be extracted from the dpb, let's simplify userspace
life and build that list kernel-side (generic helpers will be provided
for drivers that need this list).
Signed-off-by: Boris Brezillon
---
Changes in v3:
* None
Changes in v2:
* None
---
Documentation/media/uapi/v4l/ext-
ned-off-by: Boris Brezillon
Reviewed-by: Paul Kocialkowski
---
Changes in v3:
* s/per-{slice,frame} decoding/{slice,frame}-based decoding/
* Add Paul's R-b
Changes in v2:
* Allow decoding multiple slices in per-slice decoding mode
* Minor doc improvement/fixes
---
.../media/uapi/v4l/ext-
On Fri, 05 Jul 2019 13:40:03 -0300
Ezequiel Garcia wrote:
> Hi Boris, Paul,
>
> On Wed, 2019-07-03 at 14:28 +0200, Boris Brezillon wrote:
> > Looks like some stateless decoders expect slices to be prefixed with
> > ANNEX B start codes (they most likely do some kind of bits
Hi Hans,
On Mon, 22 Jul 2019 17:29:21 +0200
Hans Verkuil wrote:
> On 7/3/19 2:28 PM, Boris Brezillon wrote:
> > Some stateless decoders don't support per-slice decoding (or at least
> > not in a way that would make them efficient or easy to use).
> > Let's expo
On Wed, 24 Jul 2019 12:39:55 +0900
Tomasz Figa wrote:
> Hi Boris,
>
> On Wed, Jul 3, 2019 at 9:28 PM Boris Brezillon
> wrote:
> >
> > Those lists can be extracted from the dpb, let's simplify userspace
> > life and build that list kernel-side (generic helpe
On Fri, 5 Jul 2019 19:16:18 +0200
Boris Brezillon wrote:
> On Fri, 05 Jul 2019 13:40:03 -0300
> Ezequiel Garcia wrote:
>
> > Hi Boris, Paul,
> >
> > On Wed, 2019-07-03 at 14:28 +0200, Boris Brezillon wrote:
> > > Looks like some stateless decode
On Thu, 25 Jul 2019 23:39:11 -0300
Ezequiel Garcia wrote:
> On Thu, 2019-07-25 at 21:36 +0200, Paul Kocialkowski wrote:
> > Hi,
> >
> > On Thu 25 Jul 19, 08:42, Boris Brezillon wrote:
> > > On Fri, 5 Jul 2019 19:16:18 +0200
> > > Boris Brezillon wrote:
On Fri, 26 Jul 2019 08:28:28 +0200
Boris Brezillon wrote:
> On Thu, 25 Jul 2019 23:39:11 -0300
> Ezequiel Garcia wrote:
>
> > On Thu, 2019-07-25 at 21:36 +0200, Paul Kocialkowski wrote:
> > > Hi,
> > >
> > > On Thu 25 Jul 19, 08:42, Boris Brezillo
1 - 100 of 362 matches
Mail list logo
