> On Jun 16, 2025, at 07:39, Michael Niedermayer wrote:
>
> On Fri, Jun 13, 2025 at 05:08:30PM +0300, Martin Storsjö wrote:
>> On Fri, 13 Jun 2025, Tristan Matthews wrote:
>>
>>> ---
>>> tests/checkasm/h264dsp.c | 37 +
>>> 1 file changed, 37 insertions(+)
>>
From: Zhao Zhili
---
tests/checkasm/h264dsp.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/tests/checkasm/h264dsp.c b/tests/checkasm/h264dsp.c
index f5f9650224..006532e08b 100644
--- a/tests/checkasm/h264dsp.c
+++ b/tests/checkasm/h264dsp.c
@@ -328,7 +328,7
Got it. I don't mind writing a CUDA variant of this and submitting it
separately. What's the reasoning behind preferring a plain CUDA filter over
an NPP based one?
On Sun, Jun 15, 2025 at 5:37 PM Timo Rothenpieler
wrote:
> On 16.06.2025 02:14, Jorge Estrada wrote:
> > This patch adds the pad_npp
On 16.06.2025 02:14, Jorge Estrada wrote:
This patch adds the pad_npp video filter. A filter similar to the existing pad
filter but accelerated by NPP.
I'm honestly not keen on adding another npp based filter, specially one
this simple that a plain CUDA filter could easily do as well.
My go
This patch adds the pad_npp video filter. A filter similar to the existing pad
filter but accelerated by NPP.
The filter shares the same options as the software pad filter.
Example usage:
ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i input.mp4 -vf
"pad_npp=w=iw+100:h=ih+100:x=-1:y=-1:colo
On Fri, Jun 13, 2025 at 05:08:30PM +0300, Martin Storsjö wrote:
> On Fri, 13 Jun 2025, Tristan Matthews wrote:
>
> > ---
> > tests/checkasm/h264dsp.c | 37 +
> > 1 file changed, 37 insertions(+)
>
> Both patches LGTM, thank you!
will apply
thx
[...]
--
Micha
On Sat, Jun 14, 2025 at 05:08:36PM +0800, Zhao Zhili wrote:
>
>
> > On Jun 14, 2025, at 16:33, Lidong Yan
> > wrote:
> >
> > In libavformat/rtmpproto.c:gen_connect(), if check on string length
> > or check on codec fourcc failed, ff_rtmp_packet_create() allocated
> > data in pkt would leak. Ad
I wasn't able to repro in a windows 11 arm64 VM. It seems the builds at
fate.ffmpeg.org are also unaffected.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
Make runtime AVStream.codecpar codec_id updates optional and disabled
by default, so that avformat API clients can enable this feature explicitly
when they add support for runtime codec changes.
Accordingly, codec_close should not assume that the codec_id cannot change.
This fixes 'ffprobe 1_poc.m
On Sat, Jun 14, 2025 at 9:24 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Pavel Koshevoy:
> > Make runtime AVStream.codecpar codec_id updates optional and disabled
> > by default, so that avformat API clients can enable this feature
> explicitly
> > when they add support for ru
Hi Kacper
On Sun, Jun 15, 2025 at 05:57:09PM +0200, Kacper Michajlow wrote:
[...]
> Maybe it's time to retire the trac? It is quite slow by design and not
> really actively maintained anymore. Holding onto legacy software
> always increases the burden of maintainability.
While performance is jus
On Sun, Jun 15, 2025 at 03:42:14PM +0200, Michael Niedermayer wrote:
> Hi
>
> On Sun, Jun 15, 2025 at 03:35:15PM +0200, Michael Niedermayer wrote:
> > Hi all
> >
> > As it seems someone figured out how to make AI solve anubis, which made trac
> > rather slow due to the DDOS from 100 different IPs
On 15.06.2025 19:25, Clément Péron wrote:
On Sun, 15 Jun 2025 at 18:05, Gyan Doshi wrote:
On 2025-06-15 09:17 pm, Clément Péron wrote:
On Sun, 15 Jun 2025 at 17:33, Gyan Doshi wrote:
On 2025-06-15 08:59 pm, Marth64 wrote:
thanks both
Pushed as 90424a447556c45f035a128d673607bff05d0fd6
Thanks for the ack, pushed
___
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".
Andreas Rheinhardt:
> Patches attached.
>
> - Andreas
>
Will apply this patchset tomorrow unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, vi
Andreas Rheinhardt:
> Patches attached.
>
> - Andreas
>
Will apply my patches of this patchset tomorrow unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To u
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg4videodec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 313d73157f..32b2dec1d6 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavc
On Sun, 15 Jun 2025 at 18:05, Gyan Doshi wrote:
>
>
>
> On 2025-06-15 09:17 pm, Clément Péron wrote:
> > On Sun, 15 Jun 2025 at 17:33, Gyan Doshi wrote:
> >>
> >>
> >> On 2025-06-15 08:59 pm, Marth64 wrote:
> >>> thanks both
> >> Pushed as 90424a447556c45f035a128d673607bff05d0fd6
> > Not an issue
From: Andreas Rheinhardt
Possible by using block_index.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ituh263dec.c | 35 +--
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/libavcodec/ituh263dec.c b/libavcodec/ituh263dec.c
index 896556edfb..80
From: Andreas Rheinhardt
There is no need to use two loops.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ituh263enc.c | 38 ++
1 file changed, 10 insertions(+), 28 deletions(-)
diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
index d1d07bc
From: Andreas Rheinhardt
Only used by the decoder now that the encoder solves
out-of-slice predictions by setting the out-of-slice
values appropriately.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg4video.h| 44 ---
libavcodec/mpeg4videodec.c | 47 ++
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/flvenc.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/libavcodec/flvenc.c b/libavcodec/flvenc.c
index 8f07c3c778..184e688ebd 100644
--- a/libavcodec/flvenc.c
+++ b/libavcod
From: Andreas Rheinhardt
Always-true since 1c40a179222f638e88c8e7b1a374753a00b0f979
which made 4863671d888273392e9dcc2429f3852c00330498 superfluous.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavc
From: Andreas Rheinhardt
The whole dc_val array is initialized (to 1024) immediately
after the allocation.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 8473
Hello Michael,
On Sun, Jun 15, 2025 at 11:53 AM Michael Niedermayer
wrote:
> The wiki has the huge advantage that people can edit it easily
>
> Editing the docs people have to do a git checkout, edit a file
> with an editor, make a git commit read patch submission rules
> submit a patch to ML or
From: Andreas Rheinhardt
The check for whether we can use the fast path to process
AC coefficients used the qscale value belonging to a different
slice; this worked in practice, because the predicted AC values
are zero in this case, so it does not matter whether we use
the fast or the slow path.
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg_er.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mpeg_er.c b/libavcodec/mpeg_er.c
index 4b171354c7..0b919f0ced 100644
--- a/libavcodec/mpeg_er.c
+++ b/libavcodec/mpeg_er.c
@@ -96,7
From: Andreas Rheinhardt
(GCC did not perform this on its own; Clang did.)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 4701
From: Andreas Rheinhardt
Now that every slice (and therefore every thread) uses its own
DC array, one can simply set the out-of-slice DC values to its
expected values (this is not possible for the decoders due
to error resilience).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h263enc.h
From: Andreas Rheinhardt
This fixes data races (which are UB) in the MPEG-4 and H.263+
encoder when predicting DC values; these encoders unconditionally
read values from the line above the current line and only check
lateron (via first_slice_line) whether said prediction can be used
at all. It wi
From: Andreas Rheinhardt
The chroma mb_type[1] and mb_type[2] pointers are unused.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vc1.h| 2 +-
libavcodec/vc1_block.c | 96 ++---
libavcodec/vc1_loopfilter.c | 10 ++--
libavcodec/vc1_mc.c
From: Andreas Rheinhardt
The chroma dc_val pointers are mostly unused (accesses use
dc_val[0] and block_index), so remove them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ituh263dec.c| 2 +-
libavcodec/ituh263enc.c| 2 +-
libavcodec/mpeg4video.h| 3 +--
libavcodec/mpeg4vid
From: Andreas Rheinhardt
Up until now, they are marked as dirty (filled with 1), meaning that
the entries are in need of a reset via ff_clean_intra_table_entries();
but actually, the entries are initialized to the state that
ff_clean_intra_table_entries() produces, so they can be marked
as non-di
From: Andreas Rheinhardt
They are currently allocated separately per slice; allocating them
jointly allows to avoid saving them in ff_update_duplicate_context().
The way it is done also avoids allocating ac_val for encoders that
don't need it (e.g. H.263 or H.263+ with AIC).
This entailed movin
From: Andreas Rheinhardt
This is in preparation for removing removing ac_val[1]
and ac_val[2]. ff_mpeg4_clean_buffers() was the last user of them.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg4video.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcod
From: Andreas Rheinhardt
The chroma pointers ac_val[1] and ac_val[2] are no longer used anywhere.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ituh263dec.c| 2 +-
libavcodec/mpeg4video.c| 8 +---
libavcodec/mpeg4videodec.c | 6 ++
libavcodec/mpeg4videoenc.c | 4 ++--
li
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index b481d1eef4..64563a509b 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegv
From: Andreas Rheinhardt
Said block will only be referenced by blocks from the same macroblock,
which will read the new AC values instead of the reset values
from this function.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-
From: Andreas Rheinhardt
The underlying element type has always a size of 32B,
so that the pointer is always at least 16B aligned.
Clang uses this to upgrade the (inlined) memset to
aligned stores. GCC doesn't (it does it only when
the alignment hint is provided via __builtin_assume_aligned).
Si
From: Andreas Rheinhardt
These are already mostly unused; not using them here is in
preparation for removing them altogether. Use block_index[4..5]
instead for addressing.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 15 ---
1 file changed, 8 insertions(+), 7 dele
From: Andreas Rheinhardt
All callers check the corresponding entry of MpegEncContext.mbintra_table
and if set (indicating that the intra tables might have been written to
when decodeing a intra MB, so that they are "dirty"), call
ff_clean_intra_table_entries(), which resets them to default values
From: Andreas Rheinhardt
This is the only place where it is used.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/flvenc.c | 22 --
libavcodec/flvenc.h | 4
libavcodec/ituh263enc.c | 24 +++-
3 files changed, 23 insertions(+), 27 deletions
From: Andreas Rheinhardt
Namely with block_index and block_wrap.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ituh263enc.c | 23 +++
1 file changed, 7 insertions(+), 16 deletions(-)
diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
index ae67907722..8126bf
From: Andreas Rheinhardt
Allocate them before the slice contexts, so that they are automatically
copied to the slice contexts. This avoids having to set them in a loop.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_enc.c | 148 ++---
1 file changed,
From: Andreas Rheinhardt
This will allow to perform initializations between ff_mpv_common_init()
and ff_mpv_init_duplicate_contexts() that will be automatically
copied to the slice contexts.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 8 +---
libavcodec/mpegvideo_enc
From: Andreas Rheinhardt
They are freed with av_freep(), so the pointers are already consistent.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index f3e4d4c386..84736f8b5b 100644
-
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 2a1961b61a..24960ec00a 100755
--- a/configure
+++ b/configure
@@ -2959,7 +2959,7 @@ cook_decoder_select="audiodsp sinewin"
cr
From: Andreas Rheinhardt
It only needs mpegvideoencdsp, motion_est.o and ratecontrol.o.
Signed-off-by: Andreas Rheinhardt
---
configure | 2 +-
libavcodec/Makefile | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 24960ec00a..6d7a89d8
From: Andreas Rheinhardt
It only needs mpegvideoencdsp, motion_est.o and
some H.263 specific parts.
Signed-off-by: Andreas Rheinhardt
---
configure | 2 +-
libavcodec/Makefile | 2 +-
libavcodec/h263.c | 5 -
libavcodec/ituh263enc.c | 41 ++---
From: Andreas Rheinhardt
This will allow to relax the dependency on mpegvideoenc
for several codecs.
Signed-off-by: Andreas Rheinhardt
---
configure| 3 ++-
libavcodec/Makefile | 4 ++--
libavcodec/aarch64/Makefile | 4 ++--
libavcodec/arm/Makefile | 4 ++
From: Andreas Rheinhardt
It is already set during init.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/svq1enc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/svq1enc.c b/libavcodec/svq1enc.c
index cdcf1de712..0caed73097 100644
--- a/libavcodec/svq1enc.c
+++ b/libavcodec/svq1
From: Andreas Rheinhardt
The motion estimation code only uses block_index[0..3],
so only initialize that (just like estimate_motion_thread()
in mpegvideo_enc.c).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/svq1enc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/svq1enc.c
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/svq1enc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/libavcodec/svq1enc.c b/libavcodec/svq1enc.c
index e3061baff4..cdcf1de712 100644
--- a/libavcodec/svq1enc.c
+++ b/libavcodec/svq1enc.c
@@ -80,10 +80,6 @@
From: Andreas Rheinhardt
It only depends upon the dimensions (which do not change).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/svq1enc.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/libavcodec/svq1enc.c b/libavcodec/svq1enc.c
in
From: Andreas Rheinhardt
It is not really needed, as none of the buffers allocated
in ff_mpv_common_init() are used lateron; in fact, ff_mpv_common_init()
is called with MpegEncContext.width and height equal to zero
(as well as encoding equal to zero, so that the error resilience
parts are initia
From: Andreas Rheinhardt
Forgotten after 919e749772d09900b41877e21ccb994fab0013ab.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/motion_est.c | 180
1 file changed, 90 insertions(+), 90 deletions(-)
diff --git a/libavcodec/motion_est.c b/libavcodec/
From: Andreas Rheinhardt
Forgotten in 65015003f5c4b83a8202abfa7420ccf37cde6ce3;
after said commit, freeing scratchbuf on error in svq1_encode_frame()
could lead to segfaults lateron, because the buffer will not
be allocated again.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/svq1enc.c | 1
From: Andreas Rheinhardt
Given that the MPEG-1/2 decoders unquantize the blocks
on their own, block_last_index is only used to signal
to ff_mpv_reconstruct_mb() whether a block is skipped
or not; but this is only checked for inter macroblocks,
so it is unnecessary to set block_last_index for intr
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/rv10.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
index 7f7f7aeba2..9f4dea6141 100644
--- a/libavcodec/rv10.c
+++ b/libavcod
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ituh263enc.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
index a1eee8cded..ab6edafd4d 100644
--- a/libavcodec/ituh
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ituh263enc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
index 4fdf9cf402..a1eee8cded 100644
--- a/libavcodec/ituh263enc.c
+++ b/libavcodec/i
From: Andreas Rheinhardt
Overriding the number of coefficients is only necessary if
ac_pred is in used, not for h263_aic alone (for which only
the DC coefficient is predicted) as it is done here.
And since d50635cd247e17fe16c63219b9ae80d45a8185b1
the H.263 unquantize-intra functions override the
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/ituh263dec.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavcodec/ituh263dec.c b/libavcodec/ituh263dec.c
index 5e1d15e557..896556edfb 100644
--- a/libavcodec/ituh263dec.c
+++ b/libavcode
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/rv10.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
index 1aae92a358..7f7f7aeba2 100644
--- a/libavcodec/rv10.c
+++ b/libavcodec/rv10.c
@@ -284,6
From: Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt
---
libavcodec/rv10.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
index 482af8e52a..1aae92a358 100644
--- a/libavcodec/rv10.c
+++ b/libavcodec/rv10.c
@@ -284,7 +284,6
This patchset is a mix of mpegvideo-related patches. The second half
(beginning with avcodec/ituh263dec: Simplify AIC handling) mostly has a
theme, namely improving dc_val and ac_val handling in mpegvideo. The first
is just other stuff which I found while investigating the latter.
Andreas Rheinhar
Hi Marth64
On Sun, Jun 15, 2025 at 11:06:47AM -0500, Marth64 wrote:
> On Sun, Jun 15, 2025 at 10:57 AM Kacper Michajlow
> wrote:
> > Maybe it's time to retire the trac? It is quite slow by design and not
> > really actively maintained anymore. Holding onto legacy software
> > always increases the
Hi Kacper
On Sun, Jun 15, 2025 at 05:57:09PM +0200, Kacper Michajlow wrote:
> On Sun, 15 Jun 2025 at 16:53, James Almer
> wrote:
> >
> > On 6/15/2025 10:35 AM, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > As it seems someone figured out how to make AI solve anubis, which made
> > > trac
>
Hi
On Sun, Jun 15, 2025 at 11:53:28AM -0300, James Almer wrote:
> On 6/15/2025 10:35 AM, Michael Niedermayer wrote:
> > Hi all
> >
> > As it seems someone figured out how to make AI solve anubis, which made trac
> > rather slow due to the DDOS from 100 different IPs, which eventually
> > we had t
On 6/15/2025 4:58 PM, Michael Niedermayer wrote:
> I hoped someone just made a honest mistake with their AI agents.
Why are we assuming this is an AI agent and not a stupid DDoS?
> But if its a botnet
> why would a botnet target ffmpegs bug tracker ?
It is common on cybercrime forums to DDoS thi
Jack Lau,
> I indeed did not notice this grammar issue, and I will be more careful next
> time.
No worries at all, the grammar issue was already there. Thanks for the
fix, will push.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.or
Hi James
On Sun, Jun 15, 2025 at 11:45:42AM -0300, James Almer wrote:
> On 6/15/2025 10:42 AM, Michael Niedermayer wrote:
> > Hi
> >
> > On Sun, Jun 15, 2025 at 03:35:15PM +0200, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > As it seems someone figured out how to make AI solve anubis, whic
--- Begin Message ---
Hello to all, I didn't mean to publish this, this was in my drafts and
it somehow was sent without me asking to, I ask you to ignore this as I
didn't mean to send this
My apologizes
On 6/15/25 6:03 PM, Emma Romano wrote:
---
libavcodec/vp3.c | 3 +++
1 file changed, 3
On Sun, Jun 15, 2025 at 10:57 AM Kacper Michajlow
wrote:
> Maybe it's time to retire the trac? It is quite slow by design and not
> really actively maintained anymore. Holding onto legacy software
> always increases the burden of maintainability.
I do feel that a good portion of wiki technical do
On 2025-06-15 09:17 pm, Clément Péron wrote:
On Sun, 15 Jun 2025 at 17:33, Gyan Doshi wrote:
On 2025-06-15 08:59 pm, Marth64 wrote:
thanks both
Pushed as 90424a447556c45f035a128d673607bff05d0fd6
Not an issue for me but just a remark the email is wrong: "Author:
Clément Péron "
It is th
Hi Derek
On Sun, Jun 15, 2025 at 02:53:57PM +0100, Derek Buitenhuis wrote:
> On 6/15/2025 2:42 PM, Michael Niedermayer wrote:
> > for the record, heres btw the 100 IP addresses from where the attack
> > yesterday
> > happened: (i think timo said there where more addresses later but thats the
> >
On Sun, 15 Jun 2025 at 16:53, James Almer
wrote:
>
> On 6/15/2025 10:35 AM, Michael Niedermayer wrote:
> > Hi all
> >
> > As it seems someone figured out how to make AI solve anubis, which made trac
> > rather slow due to the DDOS from 100 different IPs, which eventually
> > we had to block.
> > (
Jack Lau via ffmpeg-devel:
> diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
> index 86e8935fee..2a3905891d 100644
> --- a/libavformat/tls_openssl.c
> +++ b/libavformat/tls_openssl.c
> @@ -415,7 +415,11 @@ error:
> */
> static EVP_PKEY *pkey_from_pem_string(const char *pem_str
On Sun, 15 Jun 2025 at 17:33, Gyan Doshi wrote:
>
>
>
> On 2025-06-15 08:59 pm, Marth64 wrote:
> > thanks both
>
> Pushed as 90424a447556c45f035a128d673607bff05d0fd6
Not an issue for me but just a remark the email is wrong: "Author:
Clément Péron "
Regards,
>
> Regards,
> Gyan
>
> _
On 2025-06-15 08:59 pm, Marth64 wrote:
thanks both
Pushed as 90424a447556c45f035a128d673607bff05d0fd6
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link
thanks both
___
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".
On 2025-06-15 08:41 pm, Clément Péron wrote:
usefull -> useful
seperately -> separately
reciever -> receiver
Will apply.
Regards,
Gyan
Signed-off-by: Clément Péron
---
doc/filters.texi| 2 +-
libavdevice/avfoundation.m | 4 ++--
libavfilter/vf_nlmeans_opencl.c |
> On Jun 15, 2025, at 23:17, Andreas Rheinhardt
> wrote:
>
> Zhao Zhili:
>>> Otherwise the extradata used would be ISOBMFF if the input is
>>> even though we use the *_mp4toannexb BSFs to convert it to
>>> annex B to feed it to the actual decoder.
>>>
>>> (The mediacodec decoders also use sai
> On Jun 15, 2025, at 11:38, Andreas Rheinhardt
> wrote:
>
> Jack Lau via ffmpeg-devel:
>> api doc: https://docs.openssl.org/1.0.2/man3/BIO_s_mem
>>
>> In higher versions (openssl 1.0.2 and higher),
>> the function signature is BIO *BIO_new_mem_buf(const void *buf, int len),
>> so passing a c
Zhao Zhili:
>> Otherwise the extradata used would be ISOBMFF if the input is
>> even though we use the *_mp4toannexb BSFs to convert it to
>> annex B to feed it to the actual decoder.
>>
>> (The mediacodec decoders also use said BSFs, yet they process
>> the extradata in a way that works even when
--- Begin Message ---
api doc: https://docs.openssl.org/1.0.2/man3/BIO_s_mem
In higher versions (openssl 1.0.2 and higher),
the function signature is BIO *BIO_new_mem_buf(const void *buf, int len),
so passing a const string doesn't cause an warnings.
However, in lower versions of OpenSSL,
the func
usefull -> useful
seperately -> separately
reciever -> receiver
Signed-off-by: Clément Péron
---
doc/filters.texi| 2 +-
libavdevice/avfoundation.m | 4 ++--
libavfilter/vf_nlmeans_opencl.c | 2 +-
libavformat/mxfenc.c| 2 +-
4 files changed, 5 insertions(+), 5 d
On 6/15/2025 10:35 AM, Michael Niedermayer wrote:
Hi all
As it seems someone figured out how to make AI solve anubis, which made trac
rather slow due to the DDOS from 100 different IPs, which eventually
we had to block.
(maybe timo has time to write an incident report?)
Some questions
* does so
On 6/15/2025 10:42 AM, Michael Niedermayer wrote:
Hi
On Sun, Jun 15, 2025 at 03:35:15PM +0200, Michael Niedermayer wrote:
Hi all
As it seems someone figured out how to make AI solve anubis, which made trac
rather slow due to the DDOS from 100 different IPs, which eventually
we had to block.
On 6/15/2025 2:42 PM, Michael Niedermayer wrote:
> for the record, heres btw the 100 IP addresses from where the attack yesterday
> happened: (i think timo said there where more addresses later but thats the
> list
> when i looked)
These look like residential IPs from a botnet (all same ISP, so p
Hi
On Sun, Jun 15, 2025 at 03:35:15PM +0200, Michael Niedermayer wrote:
> Hi all
>
> As it seems someone figured out how to make AI solve anubis, which made trac
> rather slow due to the DDOS from 100 different IPs, which eventually
> we had to block.
for the record, heres btw the 100 IP address
Hi all
As it seems someone figured out how to make AI solve anubis, which made trac
rather slow due to the DDOS from 100 different IPs, which eventually
we had to block.
(maybe timo has time to write an incident report?)
Some questions
* does someone know how to make trac use/set cache-control he
Hi Andreas
On Sun, Jun 15, 2025 at 05:24:34AM +0200, Andreas Rheinhardt wrote:
> Pavel Koshevoy:
> > Make runtime AVStream.codecpar codec_id updates optional and disabled
> > by default, so that avformat API clients can enable this feature explicitly
> > when they add support for runtime codec cha
On Sat, Jun 14, 2025 at 07:36:11PM -0600, Pavel Koshevoy wrote:
> On Sat, Jun 14, 2025 at 3:56 PM Michael Niedermayer
> wrote:
>
> > On Sat, Jun 14, 2025 at 01:58:28PM -0600, Pavel Koshevoy wrote:
> > > Make runtime AVStream.codecpar codec_id updates optional and disabled
> > > by default, so tha
LGTM from a readability perspective
___
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".
LGTM, good catch
___
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".
96 matches
Mail list logo
