On Tue, Jul 12, 2022 at 8:43 PM Michael Niedermayer
wrote:
> Fixes: out of array access
> Fixes:
> 48799/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LAGARITH_fuzzer-4764457825337344
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> S
Actually I was speaking about framepool, and not bufferpool.
framepool is intended to get an "AVFrame *" from a pool, by "ff_frame_pool_get".
At the moment it is available only internally to "libavfilter".
It permits an important improvement on performances, by using a pool. So it
should be very
Hi,
Are there any further comments on this patch or can it be committed?
Thanks,
Alan
On Tue, Apr 26, 2022 at 10:00 AM Alan Kelly wrote:
> The main loop processes blocks of 16 pixels. The tail processes blocks
> of size 4.
> ---
> libswscale/x86/scale_avx2.asm | 44 ++
Pushing this back up to the top. This is required to enable the previous
patch in this chain. Thanks
On Fri, Apr 22, 2022 at 10:04 AM Alan Kelly wrote:
> Ping!
>
> On Thu, Feb 17, 2022 at 11:04 AM Alan Kelly wrote:
>
>> ff_shuffle_filter_coefficients shuffles the tail as required.
>> ---
>> li
Yes, I know the version 4.1.6 is very old. But I stuck in 4.1.x versions
because I need NDI support.
In the file "framepool.h" there are only some very high level functions to deal
with AVFrame pool:
"FFFramePool *ff_frame_pool_video_init(...);FFFramePool
*ff_frame_pool_audio_init(...);void ff_f
The only duration field currently present in AVFrame is pkt_duration,
which is semantically restricted to those frames that are output by
decoders.
Add a new field that stores the frame's duration without regard for how
that frame was produced. Deprecate pkt_duration.
---
doc/APIchanges | 3
---
libavformat/mux.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index 31361f9b46..a3b50dadb6 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -1417,7 +1417,14 @@ static int write_uncoded_frame_internal(AVFormatContext
---
doc/filters.texi| 2 +-
libavfilter/buffersrc.c | 7 +++
libavfilter/f_loop.c| 14 ++
libavfilter/vf_deshake_opencl.c | 7 +++
libavfilter/vf_drawtext.c | 16
5 files changed, 45 insertions(+), 1 deletion(-)
dif
---
fftools/ffprobe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index f156663019..a041241e1e 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2570,8 +2570,8 @@ static void show_frame(WriterContext *w, AVFrame *frame,
AV
---
tests/api/api-h264-test.c | 2 +-
tests/api/api-seek-test.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/api/api-h264-test.c b/tests/api/api-h264-test.c
index b9230c65cb..c89f1ba41a 100644
--- a/tests/api/api-h264-test.c
+++ b/tests/api/api-h264-test.c
@@ -154,7
---
libavdevice/alsa_enc.c| 9 -
libavdevice/pulse_audio_enc.c | 9 -
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/libavdevice/alsa_enc.c b/libavdevice/alsa_enc.c
index ac09e33c49..e461829d03 100644
--- a/libavdevice/alsa_enc.c
+++ b/libavdevice/alsa_enc.
---
libavcodec/crystalhd.c | 2 +-
libavcodec/cuviddec.c | 2 +-
libavcodec/decode.c| 14 ++
libavcodec/encode.c| 11 ++-
libavcodec/gifdec.c| 2 +-
libavcodec/libdav1d.c | 2 +-
libavcodec/mfenc.c | 2 +-
libavcodec/rawdec.c| 2 +-
8 files changed,
---
libavfilter/vf_showinfo.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 6efcafce28..2c8514fc80 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -709,10 +709,13 @@ static int filter
---
fftools/ffmpeg.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e7384f052a..effcfa1b91 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1107,8 +1107,8 @@ static void do_video_out(OutputFile *of,
(nb_filtergra
You can get a very big improvement of performances in the special (but very
likely) case of: "(dst_linesize == bytewidth && src_linesize == bytewidth)"
In this case in fact We can "Coalesce rows", that is using ONLY ONE MEMCPY,
instead of a smaller memcpy for every row (that is looping for heig
On Wed, Jul 13, 2022 at 11:38 AM Marco Vianini <
marco_vianini-at-yahoo...@ffmpeg.org> wrote:
> You can get a very big improvement of performances in the special (but
> very likely) case of: "(dst_linesize == bytewidth && src_linesize ==
> bytewidth)"
>
> In this case in fact We can "Coalesce row
The -shortest option (which finishes the output file at the time the
shortest stream ends) is currently implemented by faking the -t option
when an output stream ends. This approach is fragile, since it depends
on the frames/packets being processed in a specific order. E.g. there
are currently some
Quoting Michael Niedermayer (2022-07-08 18:58:11)
> On Fri, Jun 17, 2022 at 12:27:18PM +0200, Anton Khirnov wrote:
> > The current version of this set can also be found in my tree
> > git://git.khirnov.net/libav
> > branch ffmpeg_mt/mux
>
> There are really many files changing, its hard to say for
Quoting Bryce Newman (2022-07-12 19:20:17)
> Hello,
> Can someone please have a look at this patch request?
> Thank you in advance.
Metadata is intended for user-presentable strings, not structured
values.
The least bad way of exporting this I can think of is adding a
demuxer-private AV_OPT_FLAG_
Quoting Andreas Rheinhardt (2022-07-11 12:57:32)
> >
> > Good point - attribute.h would otherwise have been the natural spot, but
> > I agree that it'd be better to not make it public at all. In what header
> > would you prefer to have it?
> >
>
> The typical place we put such things is libavuti
Quoting Andreas Rheinhardt (2022-07-10 01:10:21)
> and remove FF_CODEC_CAP_INIT_THREADSAFE
> All our native codecs are already init-threadsafe
> (only wrappers for external libraries and hwaccels
> are typically not marked as init-threadsafe yet),
> so it is only natural for this to also be the def
On 7/13/2022 5:03 AM, Marco Vianini wrote:
Actually I was speaking about framepool, and not bufferpool.
framepool is intended to get an "AVFrame *" from a pool, by "ff_frame_pool_get".
At the moment it is available only internally to "libavfilter".
It permits an important improvement on perform
Quoting Gyan Doshi (2022-07-11 08:46:48)
>
>
> On 2022-07-11 12:21 am, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2022-07-10 20:02:38)
> >>
> >> On 2022-07-10 10:46 pm, Anton Khirnov wrote:
> >>> Quoting Gyan Doshi (2022-07-08 05:56:21)
> On 2022-07-07 03:11 pm, Anton Khirnov wrote:
>
You should probably add new entries to the schema file instead.
https://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/ffprobe.xsd;h=3af621a17ae884adfeacb7cd50c60e1553808188;hb=HEAD#l93
Once frame->pkt_duration is gone, ffprobe shouldn't keep printing a
frame->duration value as "pkt_duration" and
On 2022-07-13 06:00 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2022-07-11 08:46:48)
On 2022-07-11 12:21 am, Anton Khirnov wrote:
Quoting Gyan Doshi (2022-07-10 20:02:38)
On 2022-07-10 10:46 pm, Anton Khirnov wrote:
Quoting Gyan Doshi (2022-07-08 05:56:21)
On 2022-07-07 03:11 pm, Anton K
> On Jul 11, 2022, at 5:44 PM, Michael Niedermayer
> wrote:
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/mxf.c| 3 +++
> libavformat/mxf.h| 1 +
> libavformat/mxfdec.c | 48
> 3 files changed, 52 insertions(+)
>
> diff --git a
Anton Khirnov (12022-07-13):
> ---
> doc/filters.texi| 2 +-
> libavfilter/buffersrc.c | 7 +++
> libavfilter/f_loop.c| 14 ++
> libavfilter/vf_deshake_opencl.c | 7 +++
> libavfilter/vf_drawtext.c | 16
> 5 files ch
I did following tests on Windows 10 64bit.I compiled code in Release.
I copied my pc camera frames 1000 times (resolution 1920x1080):
With Coalesce (MY PATCH):copy_cnt=100 size=1920x1080 tot_time_copy(us)=36574
(average=365.74)copy_cnt=200 size=1920x1080 tot_time_copy(us)=78207
(average=391.03
On Wed, Jul 13, 2022 at 5:02 PM Marco Vianini <
marco_vianini-at-yahoo...@ffmpeg.org> wrote:
> I did following tests on Windows 10 64bit.I compiled code in Release.
> I copied my pc camera frames 1000 times (resolution 1920x1080):
> With Coalesce (MY PATCH):copy_cnt=100 size=1920x1080
> tot_time
On 13.07.2022 11:38, Marco Vianini wrote:
You can get a very big improvement of performances in the special (but very likely) case of:
"(dst_linesize == bytewidth && src_linesize == bytewidth)"
Isn't all that matters dst_linesize == src_linesize, and then you can
memcpy() the whole plane?
On Wednesday, July 13, 2022 at 05:08:27 PM GMT+2, Paul B Mahol
wrote:
On Wed, Jul 13, 2022 at 5:02 PM Marco Vianini <
marco_vianini-at-yahoo...@ffmpeg.org> wrote:
> I did following tests on Windows 10 64bit.I compiled code in Release.
> I copied my pc camera frames 1000 times (reso
On Wednesday, July 13, 2022 at 02:02:18 PM GMT+2, James Almer
wrote:
On 7/13/2022 5:03 AM, Marco Vianini wrote:
> Actually I was speaking about framepool, and not bufferpool.
> framepool is intended to get an "AVFrame *" from a pool, by
> "ff_frame_pool_get".
> At the moment it is
On Wed, Jun 29, 2022 at 10:15 AM Vignesh Venkatasubramanian
wrote:
>
> On Wed, Jun 29, 2022 at 12:24 AM Paul B Mahol wrote:
> >
> >
> >
> > On Wed, Jun 29, 2022 at 9:21 AM Paul B Mahol wrote:
> >>
> >>
> >>
> >> On Tue, Jun 28, 2022 at 9:01 PM Vignesh Venkatasubramanian
> >> wrote:
> >>>
> >>>
It is merged already.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Stores the item ids of all the items found in the file and
processes the primary item at the end of the meta box. This patch
does not change any behavior. It sets up the code for parsing
alpha channel (and possibly images with 'grid') in follow up
patches.
Signed-off-by: Vignesh Venkatasubramanian
On Mon, Jul 11, 2022 at 3:25 PM James Zern
wrote:
>
> On Thu, Jun 30, 2022 at 2:04 PM Vignesh Venkatasubramanian
> wrote:
> >
> > Stores the item ids of all the items found in the file and
> > processes the primary item at the end of the meta box. This patch
> > does not change any behavior. It s
On Wed, Jul 13, 2022 at 9:08 AM Paul B Mahol wrote:
>
>
> It is merged already.
Oops, sorry about that. Thanks for merging!
--
Vignesh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscri
On 7/13/2022 12:54 PM, Marco Vianini wrote:
Sorry, my mail client was using html format.
I hope now the mail will be sent correctly.
You can get a very big improvement of performances in the special (but very likely) case of:
"(dst_linesize == bytewidth && src_linesize == bytewidth)"
In this
Should fix ticket #3361
Signed-off-by: James Almer
---
This also needs an update to some fate ref samples i'll upload before pushing
(fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which are now decoded
properly as he_aac mono, so the .s16 files need to be replaced).
libavcodec/aacdec_te
On Tue, 12 Jul 2022, Hubert Mazur wrote:
Provide neon implementation for pix_abs16_x2 function.
Performance tests of implementation are below.
- pix_abs_0_1_c: 283.5
- pix_abs_0_1_neon: 39.0
Benchmarks and tests run with checkasm tool on AWS Graviton 3.
Signed-off-by: Hubert Mazur
---
libavc
The height is hardcoded in some of the me_cmp functions, but not
in all of them. But in the case of all other functions, it's hardcoded
in the same place in SIMD functions as in the C reference functions,
while this one function differs from the behaviour of the C code.
(Before 542765ce3eccbca587d
Previously, the checkasm test always passed h=8, so no other cases
were tested.
Out of the me_cmp functions, in practice, some functions are hardcoded
to always assume a 8x8 block (ignoring the h parameter), while others
do use the parameter. For those with hardcoded height, both the
reference C f
Checkasm doesn't currently test this codepath.
---
libavcodec/aarch64/me_cmp_neon.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aarch64/me_cmp_neon.S b/libavcodec/aarch64/me_cmp_neon.S
index e49d049fc2..31db3793d9 100644
--- a/libavcodec/aarch64/me_cmp_neon.S
Don't use the last random offset, but a static one.
---
tests/checkasm/motion.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/checkasm/motion.c b/tests/checkasm/motion.c
index 79e4358941..87b20d1c10 100644
--- a/tests/checkasm/motion.c
+++ b/tests/checkasm/motion.c
@@
Before: Cortex A53A72A73 Graviton 3
pix_abs_0_3_neon: 183.7 112.7 97.5 41.2
After:
pix_abs_0_3_neon: 175.7 109.2 92.0 41.2
---
libavcodec/aarch64/me_cmp_neon.S | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/libavcodec/aarch64
Using absolute-difference-accumulate does use twice the amount of
absolute-difference instructions, but avoids the need for the
uaddl and add instructions, reducing the total number of instructions
by 3.
These can be interleaved in the rest of the calculation, to avoid
tight dependencies at the en
The max height is 16; the max difference per pixel is 255, and
a .8h element can easily contain 16*255, thus keep accumulating
in two .8h vectors, and just do the final accumulation at the
end.
This requires a minor register renumbering in ff_pix_abs16_xy2_neon.
Before: Cortex A53A72
The AArch64 assembly accesses those symbols directly, without
indirection via e.g. the GOT on ELF. In order for this not to
require text relocations, those symbols need to be resolved fully
at link time, i.e. those symbols can't be interposable.
Normally, so far, this is achieved when linking shar
On Wed, Jul 13, 2022 at 12:58:54PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2022-07-08 18:58:11)
> > On Fri, Jun 17, 2022 at 12:27:18PM +0200, Anton Khirnov wrote:
> > > The current version of this set can also be found in my tree
> > > git://git.khirnov.net/libav
> > > branch ffm
On Tue, 2022-06-14 at 09:23 +0800, Fei Wang wrote:
> From: Xu Guangxin
>
> We will generate a new frame for a missed reference. The frame can only
> be used for reference. We assign an invalid decode sequence to it, so
> it will not be involved in any dpb process.
>
> Tested-by: Fei Wang
> Sign
> Using parameter from AVCodecContext to reset qsv codec is more suitable
> for MFXVideoENCODE_Reset()'s usage. Per-frame metadata is more suitable
> for the usage of mfxEncodeCtrl being passed to
> MFXVideoENCODE_EncodeFrameAsync(). Now change it to use the value
> from AVCodecContext.
>
> Signed
From: Zhao Zhili
There is an implicit cast from double to int64_t in time unit of
second.
---
libavformat/flvdec.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index c5d3c63bd0..a78d720295 100644
--- a/libavform
From: Zhao Zhili
Firstly, the timestamps generated from framerate are inaccurate for
variable framerate mode.
Secondly, the timestamps always start from zero, while pts/dts can
start from nonzero. FLV demuxer rejects such index with message:
"Found invalid index entries, clearing the index".
---
On Tue, 2022-06-14 at 09:23 +0800, Fei Wang wrote:
> From: Xu Guangxin
>
> suppose
> a. You have 3 frames, 0, 1, 4096.
> b. The ltMask is 0xfff and use_msb is 0.
> c. The 0, 1 are lt refs for 4096.
> d. you are decoding frame 4096, and get the 0 frame.
> Since 4096 & ltMask is 0 too, even you wan
Quoting Michael Niedermayer (2022-07-14 00:12:59)
> On Wed, Jul 13, 2022 at 12:58:54PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2022-07-08 18:58:11)
> > > On Fri, Jun 17, 2022 at 12:27:18PM +0200, Anton Khirnov wrote:
> > > > The current version of this set can also be found in
On Tue, 2022-06-14 at 09:23 +0800, Fei Wang wrote:
> From: Xu Guangxin
>
> Even resolution or number of picture stores changes, we still need
> follow no_output_of_prior_pics_flag in next IDR.
>
> Tested-by: Fei Wang
> Signed-off-by: Xu Guangxin
> ---
> libavcodec/hevcdec.c | 7 ---
> 1 f
Quoting Gyan Doshi (2022-07-10 20:02:38)
>
>
> On 2022-07-10 10:46 pm, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2022-07-08 05:56:21)
> >>
> >> On 2022-07-07 03:11 pm, Anton Khirnov wrote:
> >>> Quoting Gyan Doshi (2022-07-04 18:29:12)
> This is a per-file input option that adjusts an inp
57 matches
Mail list logo
