From: Wenbin Chen
Signed-off-by: Wenbin Chen
---
doc/encoders.texi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index b02737b9df..d6dddc2bd5 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3188,8 +3188,8 @@ recommended
Ronald S. Bultje:
> Hi,
>
> On Thu, Feb 23, 2023 at 1:28 PM Alex <3.1...@ukr.net> wrote:
>
>> Hi!
>> I write custom encoder codec and want to use threads to speed up encoding
>> process. I know what ffmpeg have frame level threads and slices threads,
>> but in my case best option is to use frame
The AVPacket given to an encoder's encode callback
is unreferenced generically on error.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libopusenc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
index
The AVPacket given to an encoder's encode callback
is unreferenced generically on error.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libfdk-aacenc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavcodec/libfdk-aacenc.c b/libavcodec/libfdk-aacenc.c
index
The AVPacket given to an encoder's encode callback
is unreferenced generically on error.
Signed-off-by: Andreas Rheinhardt
---
This stuff should probably be moved into the AudioFrameQueue
someday.
libavcodec/libmp3lame.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git
Jan Ekström:
> Originally in 77b2cd7b41d7ec8008b6fac753c04f77824c514c this
> counter was separate in av_frame_unref, in which the same counter
> was re-utilized multiple times over multiple loops.
>
> This code was then refactored into wipe_side_data as-is in
>
On 3/12/23 17:52, James Almer wrote:
> On 3/12/2023 6:50 PM, Raphaël Zumer wrote:
>> I expanded on this in another email in the chain, but the buffer size needs
>> to be communicated to the user, as it is not embedded in the payload. It
>> seems needlessly convoluted to me to create a separate
Fixes Coverity issue #1518906.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libx264.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index f65ac5dacc..e59939a8a7 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -503,6 +503,7 @@
Fixes Coverity issue #1520669.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_ssim360.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavfilter/vf_ssim360.c b/libavfilter/vf_ssim360.c
index f8ce0744f2..5794275c2c 100644
--- a/libavfilter/vf_ssim360.c
+++
On 3/12/2023 6:50 PM, Raphaël Zumer wrote:
I expanded on this in another email in the chain, but the buffer size needs to
be communicated to the user, as it is not embedded in the payload. It seems
needlessly convoluted to me to create a separate function solely to calculate
the size of the
SSIM360Context.ssim360_hist is an array of four pointers to double;
so sizeof(*ssim360_hist[0]) (=sizeof(double)) is the correct size
to use to calculate the amount of memory to allocate, not
sizeof(*ssim360_hist) (which is sizeof(double*)).
Use FF_ALLOCZ_TYPED_ARRAY to avoid this issue
I expanded on this in another email in the chain, but the buffer size needs to
be communicated to the user, as it is not embedded in the payload. It seems
needlessly convoluted to me to create a separate function solely to calculate
the size of the buffer so that it can be allocated by the user
Quoting Raphaël Zumer (2023-03-02 22:43:29)
> +/**
> + * Serialize dynamic HDR10+ metadata to a user data registered ITU-T T.35
> buffer,
> + * excluding the country code and beginning with the terminal provider code.
> + * @param s A pointer containing the decoded AVDynamicHDRPlus structure.
> +
Originally in 77b2cd7b41d7ec8008b6fac753c04f77824c514c this
counter was separate in av_frame_unref, in which the same counter
was re-utilized multiple times over multiple loops.
This code was then refactored into wipe_side_data as-is in
5d839778b9f3edb682b7f71dde4f80f07c75b098 , keeping the
On Mon, Mar 06, 2023 at 12:36:52AM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 56561/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ESCAPE124_fuzzer-5560363635834880
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
On Thu, Dec 01, 2022 at 12:08:44AM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes:
> 53599/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_IPU_fuzzer-4950102511058944
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>
On 2/27/2023 2:33 PM, Raphaël Zumer wrote:
Resending this patch set due to my mail client messing with the line wrapping
in the messages I sent earlier today.
Below is a copy of the initial explanation.
This patch set implements serialization for HDR10+ dynamic metadata
(AVDynamicHDRPlus),
Possible since 8d226fb9786f34760e80e0d6b403bd63e9ac4ddd.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/allcodecs.c | 2 +-
libavcodec/libvpxdec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index
Forgotten in 6b6f7db81932f94876ff4bcfd2da0582b8ab897e.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libopencore-amr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libopencore-amr.c b/libavcodec/libopencore-amr.c
index fd9e6e6343..641a156129 100644
---
Forgotten in 6b6f7db81932f94876ff4bcfd2da0582b8ab897e.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/libxavs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/libxavs.c b/libavcodec/libxavs.c
index 9ed73d1042..6c29539f24 100644
--- a/libavcodec/libxavs.c
+++
> From: ffmpeg-devel On Behalf Of Raphaël
> Zumer
> Sent: 2023年3月3日 5:43
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 2/2] avutil: add HDR10+ dynamic metadata
> serialization function
>
> Fixed brace style and moved inline buffer size calculation comments to a
> single
On date Sunday 2023-03-05 12:57:38 +0100, Stefano Sabatini wrote:
> On date Wednesday 2023-03-01 15:04:16 +0800, "zhilizhao(赵志立)" wrote:
[...]
> Updated, thanks for the feedback.
> From 672de0e5d15ab8a22f3957222680d847f60bced8 Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini
> Date: Tue, 28 Feb
On 3/9/2023 11:18 AM, Raphaël Zumer wrote:
Hi,
While I omitted adding v2/v3 here, I believe all comments on this set of
patches have been addressed so far, unless anyone strongly disagrees with the
rationale for moving dynamic HDR parsing and serialization to libavutil or with
the function
On date Friday 2023-03-10 12:56:32 +0100, Anton Khirnov wrote:
> ---
> fftools/ffplay.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index d6479aef5f..f09ff59ccc 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@
On date Friday 2023-03-10 12:56:31 +0100, Anton Khirnov wrote:
> These fields are ad-hoc and will be deprecated. Use the recently-added
> AV_CODEC_FLAG_COPY_OPAQUE to pass arbitrary user data from packets to
> frames.
>
> Changes the result of the flcl1905 test, which uses ffprobe to decode
>
Quoting Zhao Zhili (2023-03-11 12:45:30)
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Anton
> > Khirnov
> > Sent: 2023年3月11日 18:37
> > To: 'FFmpeg development discussions and patches'
> > Subject: Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_mux_init: avoid invalid
> >
26 matches
Mail list logo
