/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
index 57f0066f4cff
/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
index 57f0066f4cff
rspace.
>>
>> Signed-off-by: Hans Verkuil
>> Suggested-by: Sakari Ailus
>> ---
>> include/uapi/linux/videodev2.h | 13 +
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videode
d-by: Sakari Ailus
> ---
> include/uapi/linux/videodev2.h | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 530638dffd93..7a34eb93437e 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b
Add new macros V4L2_FOURCC_CONV and V4L2_FOURCC_ARGS for use
in code that prints a fourcc. These macros can be used in both
kernel and userspace.
Signed-off-by: Hans Verkuil
Suggested-by: Sakari Ailus
---
include/uapi/linux/videodev2.h | 13 +
1 file changed, 13 insertions(+)
diff
Lin
---
Documentation/media/uapi/v4l/buffer.rst | 11 ++-
include/uapi/linux/videodev2.h | 2 ++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/media/uapi/v4l/buffer.rst
b/Documentation/media/uapi/v4l/buffer.rst
index 1cbd9cde57f3..9e636f4118f5
From: buil...@linuxtv.org
Pull request: https://patchwork.linuxtv.org/patch/58252/
Build log: https://builder.linuxtv.org/job/patchwork/10603/
Build time: 00:35:01
Link:
https://lore.kernel.org/linux-media/1be8ac17-349b-ef4d-299d-4f3888949...@xs4all.nl
Summary: 8 patches and/or PDF generation wit
Hi Mauro,
This PR takes Ezequiel's series adding H.264 decoding for hantro
(https://patchwork.linuxtv.org/project/linux-media/list/?series=603).
The first patch (lib/sort.c) is Acked by Andrew Morton and is intended to
go in through the media subsystem since this is the first driver that us
Verkuil
---
Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8
Documentation/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 10 insertions(+)
diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
b
Documentation/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 5 +++--
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
index 822d6730e7d2
Add this new V4L2_DEC_CMD_FLUSH decoder command and document it.
Signed-off-by: Hans Verkuil
---
Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst | 11 ++-
Documentation/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files
ad of
>> 'all']
>> Acked-by: Tomasz Figa
>> ---
>> Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8
>> Documentation/media/videodev2.h.rst.exceptions | 1 +
>> include/uapi/linux/videodev2.h | 1 +
>> 3 files
ia/uapi/v4l/vidioc-decoder-cmd.rst | 11 ++-
>> Documentation/media/videodev2.h.rst.exceptions | 1 +
>> include/uapi/linux/videodev2.h | 1 +
>> 3 files changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/media/uapi/v4l/vidioc-deco
On Thu, Aug 15, 2019 at 5:12 PM Alexandre Courbot wrote:
>
> On Wed, Aug 14, 2019 at 9:53 PM Paul Kocialkowski
> wrote:
> >
> > Hi,
> >
> > On Mon 12 Aug 19, 13:05, Hans Verkuil wrote:
> > > From: Maxime Jourdan
> > >
> > > Add an enum_fmt format flag to specifically tag coded formats where
> >
).
> >
> > Signed-off-by: Hans Verkuil
> > ---
> > Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8
> > Documentation/media/videodev2.h.rst.exceptions | 1 +
> > include/uapi/linux/videodev2.h | 5 +++--
> > 3 files changed,
.exceptions | 1 +
> include/uapi/linux/videodev2.h | 1 +
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> index 57f0066f4cff..0b
e-parsing step is not required
> (but still possible, of course).
>
> Signed-off-by: Hans Verkuil
> ---
> Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8
> Documentation/media/videodev2.h.rst.exceptions | 1 +
> include/uapi/linux/videodev2.h
On Wed, Aug 14, 2019 at 9:53 PM Paul Kocialkowski
wrote:
>
> Hi,
>
> On Mon 12 Aug 19, 13:05, Hans Verkuil wrote:
> > From: Maxime Jourdan
> >
> > Add an enum_fmt format flag to specifically tag coded formats where
> > dynamic resolution switching is supported by the device.
> >
> > This is usefu
ooks good to me!
Reviewed-by: Paul Kocialkowski
Cheers,
Paul
> Signed-off-by: Hans Verkuil
> ---
> Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8
> Documentation/media/videodev2.h.rst.exceptions | 1 +
> include/uapi/linux/videodev2.h | 5 +++--
4all.nl: added flag to videodev2.h.rst.exceptions]
> [hverkuil-ci...@xs4all.nl: updated commit text: 'one or more' instead of
> 'all']
> Acked-by: Tomasz Figa
> ---
> Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8
> Documentation/media/videodev2.
Add this new V4L2_DEC_CMD_FLUSH decoder command and document it.
Signed-off-by: Hans Verkuil
---
Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst | 11 ++-
Documentation/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files
/linux/videodev2.h | 5 +++--
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
index 822d6730e7d2..ebc05ce74bdf 100644
--- a/Documentation/media/uapi/v4l/vidioc-enum
]
[hverkuil-ci...@xs4all.nl: updated commit text: 'one or more' instead of 'all']
Acked-by: Tomasz Figa
---
Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8
Documentation/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
ream into
> > > > > > frames or fields (see the corresponding pixelformat descriptions
> > > > > > for details).
> > > > > >
> > > > > > If this flag is set, then this pre-parsing step is not required
> > > > > >
;>>>> If this flag is set, then this pre-parsing step is not required
>>>>> (but still possible, of course).
>>>>>
>>>>> Signed-off-by: Hans Verkuil
>>>>> ---
>>>>> Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8
required
> > > > (but still possible, of course).
> > > >
> > > > Signed-off-by: Hans Verkuil
> > > > ---
> > > > Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8
> > > > Documentation/media/videodev2.h.rst.exceptions | 1 +
>
rmat descriptions
> > > for details).
> > >
> > > If this flag is set, then this pre-parsing step is not required
> > > (but still possible, of course).
> > >
> > > Signed-off-by: Hans Verkuil
> > > ---
> > > Docum
t required
> > (but still possible, of course).
> >
> > Signed-off-by: Hans Verkuil
> > ---
> > Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8 ++++
> > Documentation/media/videodev2.h.rst.exceptions | 1 +
> > include/uapi/linux/videode
ion/media/uapi/v4l/vidioc-enum-fmt.rst | 8
> Documentation/media/videodev2.h.rst.exceptions | 1 +
> include/uapi/linux/videodev2.h | 5 +++--
> 3 files changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.
Add this new V4L2_DEC_CMD_FLUSH decoder command and document it.
Signed-off-by: Hans Verkuil
---
Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst | 11 ++-
Documentation/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files
]
[hverkuil-ci...@xs4all.nl: updated commit text: 'one or more' instead of 'all']
Acked-by: Tomasz Figa
---
Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8
Documentation/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
/videodev2.h | 5 +++--
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
index 822d6730e7d2..4e24e671f32e 100644
--- a/Documentation/media/uapi/v4l/vidioc-enum
/videodev2.h | 5 +++--
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
index 822d6730e7d2..4e24e671f32e 100644
--- a/Documentation/media/uapi/v4l/vidioc-enum
]
[hverkuil-ci...@xs4all.nl: updated commit text: 'one or more' instead of 'all']
Acked-by: Tomasz Figa
---
Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8
Documentation/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
/videodev2.h | 5 +++--
3 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
index 822d6730e7d2..4e24e671f32e 100644
--- a/Documentation/media/uapi/v4l/vidioc-enum
]
[hverkuil-ci...@xs4all.nl: updated commit text: 'one or more' instead of 'all']
Acked-by: Tomasz Figa
---
Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 8
Documentation/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
and up
Reviewed-by: Kieran Bingham
> ---
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 9d9705ceda76..2427bc4d8eba 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -518,7 +518,13 @@ struct v4
ayer format. In any case, you can't have duplicates, so change the
> fourcc of
> V4L2_PIX_FMT_BGRA444.
>
> Signed-off-by: Hans Verkuil
> Cc: # for v5.2 and up
Maybe a Fixes: line ?
Reviewed-by: Laurent Pinchart
> ---
> diff --git a/include/uapi/linux/vid
Hans Verkuil
Cc: # for v5.2 and up
---
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 9d9705ceda76..2427bc4d8eba 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -518,7 +518,13 @@ struct v4l2_pix_format {
#d
On 6/7/19 8:45 AM, Hans Verkuil wrote:
> On 6/7/19 8:11 AM, Tomasz Figa wrote:
>> On Wed, May 22, 2019 at 7:56 PM Hans Verkuil
>> wrote:
I share the same experience. Bitstream buffers are usually so small that
you can always find a physically contiguous memory region for them and a
On 6/7/19 8:11 AM, Tomasz Figa wrote:
> On Wed, May 22, 2019 at 7:56 PM Hans Verkuil wrote:
>>> I share the same experience. Bitstream buffers are usually so small that
>>> you can always find a physically contiguous memory region for them and a
>>> memcpy() will be faster than the overhead of get
t; Le mercredi 15 mai 2019 à 14:54 -0400, Nicolas Dufresne a écrit :
> >>>>>>>>>>>> Le mercredi 15 mai 2019 à 19:42 +0200, Paul Kocialkowski a écrit
> >>>>>>>>>>>> :
> >>>>>>>>>>>>> Hi,
d as flags. Using flags also helps with padding.
>>>>>>>>> It's unlikely that we'll get more than 64 flags, so using a u64 by
>>>>>>>>> default for that sounds fine (we definitely do want to keep some room
>>>>>>>>>
;>> It's unlikely that we'll get more than 64 flags, so using a u64 by
> >>>>>>> default for that sounds fine (we definitely do want to keep some room
> >>>>>>> available and I don't think using 32 bits as a default is good
> >>>>>
t; > > > > > It's unlikely that we'll get more than 64 flags, so using a u64
> > > > > > > > by
> > > > > > > > default for that sounds fine (we definitely do want to keep
> > > > > > &
r that sounds fine (we definitely do want to keep some room
>>>>>>> available and I don't think using 32 bits as a default is good enough).
>>>>>>>
>>>>>>> I think H.264/HEVC per-control flags should also be moved to u64.
>>&
Hi,
On Tue, 2019-06-04 at 11:05 +0200, Boris Brezillon wrote:
> 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 o
t to keep some
> > > > > > room
> > > > > > available and I don't think using 32 bits as a default is good
> > > > > > enough).
> > > > > >
> > > > > > I think H.264/HEVC per-control flags should also be moved to u64
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 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 compute l0/l1 even though the HW might be handling that ? Shall
> we in
U driver in the works, we now have a
> > > better idea of what the situation is like on platforms other than
> > > Allwinner. This email shares my conclusions about the situation and how
> > > we should update the MPEG-2, H.264 and H.265 controls accordingly.
> > >
&g
gt; > > > > It's unlikely that we'll get more than 64 flags, so using a u64 by
> > > > > default for that sounds fine (we definitely do want to keep some room
> > > > > available and I don't think using 32 bits as a default is good
> > &g
On Mon, Jun 03, 2019 at 09:41:17PM +0200, Boris Brezillon wrote:
> 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 buff
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 implementa
ms other than
> > Allwinner. This email shares my conclusions about the situation and how
> > we should update the MPEG-2, H.264 and H.265 controls accordingly.
> >
> > - Per-slice decoding
> >
> > We've discussed this one already[0] and Hans has submitted
how
> we should update the MPEG-2, H.264 and H.265 controls accordingly.
>
> - Per-slice decoding
>
> We've discussed this one already[0] and Hans has submitted a patch[1]
> to implement the required core bits. When we agree it looks good, we
> should lift the restriction
In case of watchdog timeout detected while doing mode detection,
it's better triggering video engine hardware reset immediately so
this commit fixes code for the case. Other than the case, it will
trigger video engine hardware reset after RESOLUTION_CHANGE_DELAY.
Signed-off-by: Jae Hyun Yoo
Revie
On 5/24/19 6:17 PM, Jae Hyun Yoo wrote:
In case of watchdog timeout detected while doing mode detection,
it's better triggering video engine hardware reset immediately so
this commit fixes code for the case. Other than the case, it will
trigger video engine hardware reset after RESOLUTION_CHANG
ro" appears un-documented --
>> check ./Documentation/devicetree/bindings/vendor-prefixes.yaml
>> #3013: FILE: drivers/staging/media/allegro-dvt/allegro-core.c:3013:
>> +{ .compatible = "allegro,al5e-1.1" },
>>
>> Please send a followup patch addre
o-core.c:3013:
> + { .compatible = "allegro,al5e-1.1" },
>
> Please send a followup patch addressing it.
Huh? Something went wrong: this is the patch that is in my for-v5.3f branch:
https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=for-v5.3f&id=ae4e36dd1945380ccd97090d2099f67be9a976d8
That's not what you tried to merge.
Regards,
Hans
Em Tue, 28 May 2019 20:10:27 +0200
Hans Verkuil escreveu:
> The following changes since commit 9bec226d8c79fcbc95817b082557f72a79d182f5:
>
> media: v4l2-pci-skeleton.c: fix doc warning (2019-05-28 13:14:28 -0400)
>
> are available in the Git repository at:
>
> git://linuxtv.org/hverkuil/me
| 3032
+++
drivers/staging/media/allegro-dvt/nal-h264.c | 1001
+
drivers/staging/media/allegro-dvt/nal-h264.h | 208 +
12 files changed, 4327 insertions(+), 5 deletions(-)
create mode 100644
This is v8 of the Allegro DVT H.264 encoder driver found in the EV
family of the Xilinx ZynqMP platform.
v7 caused the following smatch warnings. I fixed these warnings and added
smatch to my list of tools to run before submitting patches.
drivers/staging/media/allegro-dvt/allegro-core.c:1849:36
_vpu_enc.c | 2 +-
.../vpu/{rockchip_vpu_common.h => rockchip_vpu_v4l2.h} | 6 +++---
5 files changed, 7 insertions(+), 7 deletions(-)
rename drivers/staging/media/rockchip/vpu/{rockchip_vpu_common.h =>
rockchip_vpu_v4l2.h} (88%)
diff --git a/drivers/staging/me
On 5/28/19 5:00 PM, Michael Tretter wrote:
> On Tue, 28 May 2019 15:54:58 +0200, Hans Verkuil wrote:
>> Hi Michael,
>>
>> On 5/28/19 3:09 PM, Michael Tretter wrote:
>>> This is v7 of the Allegro DVT H.264 encoder driver found in the EV
>>> family of the Xili
On Tue, 28 May 2019 15:54:58 +0200, Hans Verkuil wrote:
> Hi Michael,
>
> On 5/28/19 3:09 PM, Michael Tretter wrote:
> > This is v7 of the Allegro DVT H.264 encoder driver found in the EV
> > family of the Xilinx ZynqMP platform.
> >
> > I moved the driver
Hi Michael,
On 5/28/19 3:09 PM, Michael Tretter wrote:
> This is v7 of the Allegro DVT H.264 encoder driver found in the EV
> family of the Xilinx ZynqMP platform.
>
> I moved the driver back to staging, because the v4l2 stateful encoder spec is
> not finished, yet. Once the s
This is v7 of the Allegro DVT H.264 encoder driver found in the EV
family of the Xilinx ZynqMP platform.
I moved the driver back to staging, because the v4l2 stateful encoder spec is
not finished, yet. Once the spec is finished, this driver shall be tested
against the final v4l2-compliance and
On 5/27/19 3:45 PM, Michael Tretter wrote:
> On Wed, 22 May 2019 15:49:45 +0200, Michael Tretter wrote:
>> On Wed, 22 May 2019 14:04:23 +0200, Hans Verkuil wrote:
>>> On 5/13/19 7:21 PM, Michael Tretter wrote:
>>>> This is v6 of the Allegro DVT H.264 encoder driver
On Wed, 22 May 2019 15:49:45 +0200, Michael Tretter wrote:
> On Wed, 22 May 2019 14:04:23 +0200, Hans Verkuil wrote:
> > On 5/13/19 7:21 PM, Michael Tretter wrote:
> > > This is v6 of the Allegro DVT H.264 encoder driver found in the EV
> > > family of
In case of watchdog timeout detected while doing mode detection,
it's better triggering video engine hardware reset immediately so
this commit fixes code for the case. Other than the case, it will
trigger video engine hardware reset after RESOLUTION_CHANGE_DELAY.
Signed-off-by: Jae Hyun Yoo
---
v
On 2019-05-15 12:09, Paul Kocialkowski wrote:
> Hi,
>
> With the Rockchip stateless VPU driver in the works, we now have a
> better idea of what the situation is like on platforms other than
> Allwinner. This email shares my conclusions about the situation and how
> we should up
Le mercredi 22 mai 2019 à 12:08 +0200, Thierry Reding a écrit :
> > 3. Does the HW do support single interrupt per frame (RK3288 as an
> > example does not, but RK3399 do)
>
> Yeah, we definitely do get a single interrupt at the end of a frame, or
> when an error occurs. Looking a bit at the re
two
> different pixel formats. It sounds like essentially the same thing, just
> with a different method.
>
> One advantage I see with your approach is that it more formally defines
> how slices are passed. This might be a good thing to do anyway. I'm not
> sure if software st
Le mercredi 22 mai 2019 à 11:29 +0200, Paul Kocialkowski a écrit :
> Le mercredi 22 mai 2019 à 10:32 +0200, Thierry Reding a écrit :
> > On Wed, May 22, 2019 at 09:29:24AM +0200, Boris Brezillon wrote:
> > > On Wed, 22 May 2019 15:39:37 +0900
> > > Tomasz Figa wrote:
> > >
> > > > > It would be p
Le mercredi 22 mai 2019 à 10:20 +0200, Boris Brezillon a écrit :
> 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
; > > > > > With the Rockchip stateless VPU driver in the works, we now have a
> > > > > > better idea of what the situation is like on platforms other than
> > > > > > Allwinner. This email shares my conclusions about the situation and
> &g
On Wed, 22 May 2019 14:04:23 +0200, Hans Verkuil wrote:
> On 5/13/19 7:21 PM, Michael Tretter wrote:
> > This is v6 of the Allegro DVT H.264 encoder driver found in the EV
> > family of the Xilinx ZynqMP platform.
> >
> > Only minor changes this time. I droppe
On 5/13/19 7:21 PM, Michael Tretter wrote:
> This is v6 of the Allegro DVT H.264 encoder driver found in the EV
> family of the Xilinx ZynqMP platform.
>
> Only minor changes this time. I dropped the implementation of the
> selection api, removed all references mentioning the dec
Le mercredi 15 mai 2019 à 14:54 -0400, Nicolas Dufresne a écrit :
> >>>>>>>>>>>> Le mercredi 15 mai 2019 à 19:42 +0200, Paul Kocialkowski a écrit
> >>>>>>>>>>>> :
> >>>>>>>>>>>>> Hi,
>
(per-slice and/or per-frame) and adapt our ffmpeg reference to be able
> to operate in both modes.
>
> That adds some complexity for userspace, but I don't think we can avoid
> it at this point and it feels better than having two different pixel
> formats (which would probably
gt;>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Le mercredi 15 mai 2019 à 10:42 -0400, Nicolas Dufresne a écrit
>>>>>> :
>>>>>>>>>>>>>> L
mercredi 15 mai 2019 à 10:42 -0400, Nicolas Dufresne
> > > > > > > > > > > > a écrit
> > > > > :
> > > > > > > > > > > > > Le mercredi 15 mai 2019 à 12:09 +0200, Paul
> >
of what the situation is like on platforms other than
> > > > > Allwinner. This email shares my conclusions about the situation and
> > > > > how
> > > > > we should update the MPEG-2, H.264 and H.265 controls accordingly.
> > > > >
>
Le mercredi 22 mai 2019 à 10:32 +0200, Thierry Reding a écrit :
> On Wed, May 22, 2019 at 09:29:24AM +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
On Wed, May 22, 2019 at 09:29:24AM +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
> > > a plan how to ex
gt; > > Le mercredi 15 mai 2019 à 12:09 +0200, Paul
> > > > > > > > > > > > Kocialkowski a
> > > > écrit :
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
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
> > > a plan how to extend
edi 15 mai 2019 à 12:09 +0200, Paul Kocialkowski a écrit :
> > > > > > > Hi,
> > > > > > >
> > > > > > > With the Rockchip stateless VPU driver in the works, we now have a
> > > > > > > better idea of what the sit
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
; > > > > Le mercredi 15 mai 2019 à 12:09 +0200, Paul Kocialkowski a
> > > écrit :
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > >
t the situation is like on platforms other than
> > > > > Allwinner. This email shares my conclusions about the situation and
> > > > > how
> > > > > we should update the MPEG-2, H.264 and H.265 controls accordingly.
> > > > >
> > >
idea of what the situation is like on platforms other than
> > > > > Allwinner. This email shares my conclusions about the situation and
> > > > > how
> > > > > we should update the MPEG-2, H.264 and H.265 controls accordingly.
> > > > >
&
ialkowski a écrit :
> > > > Hi,
> > > >
> > > > With the Rockchip stateless VPU driver in the works, we now have a
> > > > better idea of what the situation is like on platforms other than
> > > > Allwinner. This email shares my conclusions
> > > > > > With the Rockchip stateless VPU driver in the works, we now have a
> > > > > > better idea of what the situation is like on platforms other than
> > > > > > Allwinner. This email shares my conclusions about the situation and
> &
stateless VPU driver in the works, we now have a
> > > better idea of what the situation is like on platforms other than
> > > Allwinner. This email shares my conclusions about the situation and how
> > > we should update the MPEG-2, H.264 and H.265 controls accordingly
better idea of what the situation is like on platforms other than
> > > > > Allwinner. This email shares my conclusions about the situation and
> > > > > how
> > > > > we should update the MPEG-2, H.264 and H.265 controls accordingly.
> > > > &g
Kocialkowski a écrit :
> > > > Hi,
> > > >
> > > > With the Rockchip stateless VPU driver in the works, we now have a
> > > > better idea of what the situation is like on platforms other than
> > > > Allwinner. This email shares my conclusi
teless VPU driver in the works, we now have a
> > > better idea of what the situation is like on platforms other than
> > > Allwinner. This email shares my conclusions about the situation and how
> > > we should update the MPEG-2, H.264 and H.265 controls accordingly.
> &g
a
> > > > > > > > > écrit
> > :
> > > > > > > > > > Le mercredi 15 mai 2019 à 12:09 +0200, Paul Kocialkowski a
> > écrit :
> > > > > > > > > > > Hi,
> > > > > > > > > > >
&
1 - 100 of 928 matches
Mail list logo
