> On Jan 31, 2023, at 02:22, Leo Izen wrote:
>
> On 1/30/23 12:08, Zhao Zhili wrote:
>>> -Original Message-
>>> From: ffmpeg-devel On Behalf Of Leo Izen
>>> Sent: 2023年1月31日 0:50
>>> To: ffmpeg-devel@ffmpeg.org
>>> Cc: Leo Izen
>>> Subject: [FFmpeg-devel] [PATCH v2]
Fixes: memleak
Signed-off-by: Michael Niedermayer
---
libavformat/lafdec.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavformat/lafdec.c b/libavformat/lafdec.c
index b78ec3649c..f6d2d5f235 100644
--- a/libavformat/lafdec.c
+++ b/libavformat/lafdec.c
@@ -253,6 +253,15 @@
Fixes: OOM
Fixes:
54572/clusterfuzz-testcase-minimized-ffmpeg_dem_LAF_fuzzer-4974038870523904
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/lafdec.c | 2 ++
1 file changed, 2 insertions(+)
The decoder is quite slow with max n taps
Fixes: Timeout
Fixes:
54063/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BONK_fuzzer-5087362407596032
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
Patch attached.
From 5b578bc4bef6932a19e39c0da93a9e2d4cf90d7b Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Mon, 30 Jan 2023 22:24:24 +0100
Subject: [PATCH] avcodec/media100: pass pix_fmt to upper context
Signed-off-by: Paul B Mahol
---
libavcodec/media100.c | 1 +
1 file changed, 1
On Mon, 30 Jan 2023, John Coiner wrote:
Marton Balint wrote:
This does not look right, because AFAIK you always want to insert an AUD
unless it is already there. I guess that is why current code works as it
is, it assumes if an AUD is already present, then IDR-s are already
prefixed with
Jan 30, 2023, 17:49 by mich...@niedermayer.cc:
> On Thu, Dec 15, 2022 at 02:13:49AM +0100, Lynne wrote:
>
>> This list is incomplete, and just contains those I could see
>> while looking at the recent git log. If it looks like I've forgotten you, I
>> definitely haven't!
>> We may complete the
Patch attached.
Fixes relative recent thd regression.
From 1715a7f4b0487c9ecebfedfc796377022a85baec Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Mon, 30 Jan 2023 19:35:36 +0100
Subject: [PATCH] avcodec/mlpdec: parse and use substream info bits
Signed-off-by: Paul B Mahol
---
On 1/30/23 12:08, Zhao Zhili wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of Leo Izen
Sent: 2023年1月31日 0:50
To: ffmpeg-devel@ffmpeg.org
Cc: Leo Izen
Subject: [FFmpeg-devel] [PATCH v2] avutil/{color_utils, csp}: merge color_utils
into csp and expose API
On 1/27/23, Michael Niedermayer wrote:
> On Wed, Jan 25, 2023 at 10:28:38PM +0100, Paul B Mahol wrote:
>> Patch attached.
>
> breaks probetest
>
> tools/probetest 256 4096
> testing size=1
> testing size=2
> testing size=4
> testing size=8
> testing size=16
> testing size=32
> testing size=64
>
Marton Balint wrote:
> This does not look right, because AFAIK you always want to insert an AUD
> unless it is already there. I guess that is why current code works as it
> is, it assumes if an AUD is already present, then IDR-s are already
> prefixed with SPS/PPS, and no magic is needed.
I'm not
On 1/30/23, Zhao Zhili wrote:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of Leo Izen
>> Sent: 2023年1月31日 0:50
>> To: ffmpeg-devel@ffmpeg.org
>> Cc: Leo Izen
>> Subject: [FFmpeg-devel] [PATCH v2] avutil/{color_utils, csp}: merge
>> color_utils into csp and expose API
>>
>>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Leo Izen
> Sent: 2023年1月31日 0:50
> To: ffmpeg-devel@ffmpeg.org
> Cc: Leo Izen
> Subject: [FFmpeg-devel] [PATCH v2] avutil/{color_utils, csp}: merge
> color_utils into csp and expose API
>
> libavutil/color_utils contains some
On 1/27/23 07:18, Leo Izen wrote:
libjxl only accepts 16-bit buffers with its API, but it can
accept 9-bit to 15-bit input via a 16-bit buffer, provided the flag
is set declaring the buffer to be of the respective significant depth.
Likewise, it can only provide pixel data on decode as a 16-bit
libavutil/color_utils contains some avpriv_ symbols that map
enum AVTransferCharacteristic values to gamma-curve approximations and
to the actual transfer functions to invert them (i.e. -> linear).
There's two issues with this:
(1) avpriv is evil and should be avoided whenever possible
(2)
On Thu, Dec 15, 2022 at 02:13:49AM +0100, Lynne wrote:
> This list is incomplete, and just contains those I could see
> while looking at the recent git log. If it looks like I've forgotten you, I
> definitely haven't!
> We may complete the list at a later date.
>
> This makes it such that those
On Ma, 2023-01-30 at 08:55 +0100, Anton Khirnov wrote:
> Quoting Xiang, Haihao (2023-01-30 06:23:21)
> > From: Haihao Xiang
> >
> > This is a regression since commit fbdba9a1a69fe4df413d9e9df1b11db522946e75
> >
> > input_image is freed in vaapi_encode_wait() however it is still used in
> >
Hi Marton,
Thanks for pointing out
https://patchwork.ffmpeg.org/project/ffmpeg/patch/tencent_ee0e40de9a569fe5ab454e6e700a2da79...@qq.com/
Adding prints to h264_mp4toannexb_bsf.c shows that it's not reached in
the sequence that reproduces bug 10148 so it seems to be unrelated.
I found a simpler
James Almer (12023-01-23):
> What's the difference between a RFC and a "I have this idea, what do you
> think of this mock up?" email? That if suggestions are made to improve or
> change said approach, then at worst what happens is that the writer wasted
> /his/ time writing 30k lines of which a
Anton Khirnov (12023-01-20):
> Callers currently have two ways of adding filters to a graph - they can
> either
> - create, initialize, and link them manually
> - use one of the avfilter_graph_parse*() functions, which take a
> (typically end-user-written) string, split it into individual filter
Anton Khirnov (12023-01-30):
> This hack is used to limit the visibility of some AVFilterLink fields to
> only certain files. Replace it with the same pattern that is used e.g.
> in lavf AVStream/FFstream and avoid exposing these internal fields in a
> public header completely.
> ---
>
On 1/30/23, Nicolas George wrote:
> Paul B Mahol (12023-01-30):
>> libavfilter support overlapping frames and frames with gaps, look into
>> aresample filter and its async options.
>
> aresample is a very special case. And for audio filters, the duration is
> carried by nb_samples, not duration.
On 1/30/23, Anton Khirnov wrote:
> This hack is used to limit the visibility of some AVFilterLink fields to
> only certain files. Replace it with the same pattern that is used e.g.
> in lavf AVStream/FFstream and avoid exposing these internal fields in a
> public header completely.
Looks fine on
Paul B Mahol (12023-01-30):
> libavfilter support overlapping frames and frames with gaps, look into
> aresample filter and its async options.
aresample is a very special case. And for audio filters, the duration is
carried by nb_samples, not duration.
--
Nicolas George
This hack is used to limit the visibility of some AVFilterLink fields to
only certain files. Replace it with the same pattern that is used e.g.
in lavf AVStream/FFstream and avoid exposing these internal fields in a
public header completely.
---
libavfilter/avfilter.c | 191
On 1/30/23, Nicolas George wrote:
> Paul B Mahol (12023-01-30):
>> > The duration of a frame is equal to the difference between its
>> > timestamp
>> > and the timestamp of the next frame.
>> Only in special cases.
>
> No, in libavfilter, always; libavfilter does not support overlapping
> frames
Paul B Mahol (12023-01-30):
> > The duration of a frame is equal to the difference between its timestamp
> > and the timestamp of the next frame.
> Only in special cases.
No, in libavfilter, always; libavfilter does not support overlapping
frames nor gaps. And if you want to make a point, you
Gcc flag -fsemantic-interposition, which is on by default with current
gcc versions, makes the compiler assume exported symbols can be
interposed by the linker, which prevents various kinds of optimization.
Since we do not support such interposition and disable it with
-Bsymbolic, explicitly
On 1/30/23, Nicolas George wrote:
> Paul B Mahol (12023-01-30):
>> It is not redundant, it describes how much frame lasts.
>> There is no other way to derive it.
>
> The duration of a frame is equal to the difference between its timestamp
> and the timestamp of the next frame.
Only in special
On 1/30/23, Francesco Carusi wrote:
> On 28/01/2023 16:32, Paul B Mahol wrote:
>> On 1/28/23, Francesco Carusi wrote:
>>> On 27/01/2023 18:31, Paul B Mahol wrote:
On 1/27/23, Francesco Carusi wrote:
> On 26/01/2023 17:37, Paul B Mahol wrote:
>> On 1/26/23, Francesco Carusi wrote:
Paul B Mahol (12023-01-30):
> It is not redundant, it describes how much frame lasts.
> There is no other way to derive it.
The duration of a frame is equal to the difference between its timestamp
and the timestamp of the next frame.
--
Nicolas George
On 1/30/23, Nicolas George wrote:
> Paul B Mahol (12023-01-27):
>> From b4f835c4ef6e0e0bbe6adef8235381e56f3f91df Mon Sep 17 00:00:00 2001
>> From: Paul B Mahol
>> Date: Fri, 27 Jan 2023 23:34:02 +0100
>> Subject: [PATCH 1/4] avfilter/framesync: calculate frame duration too
>>
>> Signed-off-by:
Quoting Francesco Carusi (2023-01-30 11:48:36)
> From 7b006d958b0d226269362b9a811bd210ae41adcd Mon Sep 17 00:00:00 2001
> From: yethie
> Date: Mon, 30 Jan 2023 11:41:53 +0100
> Subject: [PATCH 1/1] enhanced drawtext filter
This is not the way we do development. Every logical change you're doing
---
libavcodec/avcodec.c | 36 +---
libavcodec/decode.c | 9 ++---
libavcodec/encode.c | 19 +--
libavcodec/h264dec.c | 14 +++---
4 files changed, 51 insertions(+), 27 deletions(-)
diff --git a/libavcodec/avcodec.c
Anton Khirnov (12023-01-27):
> This is not forcing timestamps on output frames. This is solving the
> general problem where the correct matching of input frames is determined
> by some external logic. The specific case that is of interest to me is
> where this logic is the ffmpeg CLI framerate
On 28/01/2023 16:32, Paul B Mahol wrote:
On 1/28/23, Francesco Carusi wrote:
On 27/01/2023 18:31, Paul B Mahol wrote:
On 1/27/23, Francesco Carusi wrote:
On 26/01/2023 17:37, Paul B Mahol wrote:
On 1/26/23, Francesco Carusi wrote:
On 26/01/2023 14:21, Paul B Mahol wrote:
On 1/26/23,
Paul B Mahol (12023-01-27):
> From b4f835c4ef6e0e0bbe6adef8235381e56f3f91df Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Fri, 27 Jan 2023 23:34:02 +0100
> Subject: [PATCH 1/4] avfilter/framesync: calculate frame duration too
>
> Signed-off-by: Paul B Mahol
> ---
>
Paul B Mahol (12023-01-27):
> From b4f835c4ef6e0e0bbe6adef8235381e56f3f91df Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Fri, 27 Jan 2023 23:34:02 +0100
> Subject: [PATCH 1/4] avfilter/framesync: calculate frame duration too
>
> Signed-off-by: Paul B Mahol
> ---
>
On 1/30/23, Xiang, Haihao wrote:
> From: Haihao Xiang
>
> Include hstack_qsv, vstack_qsv and xstack_qsv. They may accept input
> streams with different sizes.
>
> Examples:
> $ ffmpeg -hwaccel qsv -hwaccel_output_format qsv -i input.mp4 \
> -filter_complex "[0:v][0:v]hstack_qsv" -f null -
>
> $
From: Haihao Xiang
Include hstack_qsv, vstack_qsv and xstack_qsv. They may accept input
streams with different sizes.
Examples:
$ ffmpeg -hwaccel qsv -hwaccel_output_format qsv -i input.mp4 \
-filter_complex "[0:v][0:v]hstack_qsv" -f null -
$ ffmpeg \
-hwaccel qsv -hwaccel_output_format qsv -i
40 matches
Mail list logo
