On Wed, Mar 23, 2022 at 04:57:16PM +0100, Anton Khirnov wrote:
> It is not used in the encoder.
> ---
> libavcodec/snow.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
this is segfaulting with some fuzzed file
==30657== Invalid read of size 8
==30657==at
Signed-off-by: Andreas Rheinhardt
---
libavcodec/error_resilience.h | 1 -
libavcodec/h264dec.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/libavcodec/error_resilience.h b/libavcodec/error_resilience.h
index bb770ff674..2187586618 100644
--- a/libavcodec/error_resilience.h
+++
Modifying the main context by a slice thread is racy;
so constify the pointer to it in H264SliceContext.
The code itself was already compatible with this change.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264dec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Since 7be2d2a70cd20d88fd826a83f87037d14681a579 only one context
is used. Moving it to H264Context from H264SliceContext is natural.
One could access the ERContext from H264SliceContext
via H264SliceContext.h264->er; yet H264SliceContext.h264 should
naturally be const-qualified, because slice
ff_er_frame_start() initializes ERContext.error_count
to three times the number of macroblocks to decode.
Later ff_er_add_slice() reduces this number by the amount
of macroblocks whose AC resp. DC resp. MV have been finished
(so every correctly decoded MB counts three times).
So the frame has been
On Wed, Mar 23, 2022 at 07:03:24AM -0400, Leo Izen wrote:
> This commit adds support to libavformat for muxing
> and demuxing Jpeg XL images as image2 streams.
> ---
> libavformat/allformats.c | 1 +
> libavformat/img2.c | 1 +
> libavformat/img2dec.c| 21 +
>
On Thu, Mar 24, 2022 at 6:12 AM Danil Chapovalov
wrote:
>
> ---
> libavcodec/libvpxenc.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index dff1d06b0e..463a658bb0 100644
> --- a/libavcodec/libvpxenc.c
> +++
On Thu, Mar 24, 2022 at 04:20:01PM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> This is mostly straightforward. The major complication is that, as a
> result of the 16-bit chunk size limitation, ICC profiles may need to be
> split up into multiple chunks.
>
> We also need to make sure to
ons 2022-03-23 klockan 16:26 +1100 skrev Peter Ross:
> on glibc memory.h drags in string.h, but codec2 does not use any
> str* or mem* functions. additionally, memory.h is not part of the
> C99 or POSIX standards.
> ---
> libavformat/codec2.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git
---
libavcodec/libvpxenc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index dff1d06b0e..5db31db5dc 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1250,6 +1250,7 @@ static int
From: Niklas Haas
This is mostly straightforward. The major complication is that, as a
result of the 16-bit chunk size limitation, ICC profiles may need to be
split up into multiple chunks.
We also need to make sure to allocate enough extra space in the packet
to fit the ICC profile, so modify
From: Niklas Haas
We re-use the PNGEncContext.zstream for deflate-related operations.
Other than that, the code is pretty straightforward. Special care needs
to be taken to avoid writing more than 79 characters of the profile
description (the maximum supported).
To write the (dynamically sized)
From 446777e4333726cb05843ff16ac76e9eb83a5e57 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Tomas=20H=C3=A4rdin?=
Date: Sun, 2 Jan 2022 15:47:30 +0100
Subject: [PATCH] web/consulting: add myself
---
src/consulting | 12
1 file changed, 12 insertions(+)
diff --git a/src/consulting
---
libavcodec/libvpxenc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index dff1d06b0e..463a658bb0 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1625,6 +1625,12 @@ static int vpx_encode(AVCodecContext *avctx,
Hi Ming
Thanks for working on V4L2 M2M - it's nice to see people using it.
On Thu, 24 Mar 2022 at 06:13, Ming Qian wrote:
>
> if the v4l2 buffer is supported to export dma-buf,
> then we can report it to AV_PIX_FMT_DRM_PRIME,
> so the caller can pass it to other hardware device,
> such as
24 Mar 2022, 07:14 by ming.q...@nxp.com:
> the dequeue of capture queue will be blocked until
> decoded frame available or an input buffer is ready to be dequeued.
> but it may cause death waiting in some case.
> For example, it has enqueued the first input frame,
> and then blocks at
For the reason similar to decoder,
Set a reasonable timeout instead of -1
to avoid dead waiting in some case.
Signed-off-by: Ming Qian
---
libavcodec/v4l2_context.c | 4 ++--
libavcodec/v4l2_context.h | 2 +-
libavcodec/v4l2_m2m_enc.c | 5 -
3 files changed, 7 insertions(+), 4 deletions(-)
the dequeue of capture queue will be blocked until
decoded frame available or an input buffer is ready to be dequeued.
but it may cause death waiting in some case.
For example, it has enqueued the first input frame,
and then blocks at ff_v4l2_context_dequeue_frame.
For some reason, the decoder
if the v4l2 buffer is supported to export dma-buf,
then we can report it to AV_PIX_FMT_DRM_PRIME,
so the caller can pass it to other hardware device,
such as display it directly without copy frame data.
Signed-off-by: Ming Qian
---
libavcodec/v4l2_buffers.c | 115
19 matches
Mail list logo
