On Mon, 11 Nov 2024, Timo Rothenpieler wrote:
On 11/11/2024 15:02, Ronald S. Bultje wrote:
Hi,
On Sun, Nov 10, 2024 at 6:53 PM Michael Niedermayer
wrote:
Hi
I have been given recordings of VDD by the Reconnaissance General Bureau.
(didnt listen to all yet)
IIUC there was a talk where
On Monday, November 11th, 2024 at 3:12 AM, Rémi Denis-Courmont
wrote:
> > I recently read a news article about impressive AVX-512 optimizations
> > of Motion Compensation functions and I'd like to learn more.
> > Unfortunately, the article merely linked the post on X, which
> > included a screen
On 11/11/2024 15:02, Ronald S. Bultje wrote:
Hi,
On Sun, Nov 10, 2024 at 6:53 PM Michael Niedermayer
wrote:
Hi
I have been given recordings of VDD by the Reconnaissance General Bureau.
(didnt listen to all yet)
IIUC there was a talk where it was suggested (by kieran?) to have some
assembl
On Mon, 11 Nov 2024 17:00:42 +
Derek Buitenhuis wrote:
> This only convinces me further that it this whole setup ins't for for
> purpose, and is being run by people who have no concept of actual
> security. This is totally insane.
I think it would be wiser to point to other administration of
Hi Marton
On Mon, Nov 11, 2024 at 08:44:32AM +0100, Marton Balint wrote:
>
>
> On Mon, 11 Nov 2024, Michael Niedermayer wrote:
>
> > Hi all
> >
> > as we will likely have 15k available from STF "2024" for another
> > task/project
> > what should it be used for ?
> >
> > I think the obvious o
Recent changes in MSYS2 have changed the default console code page, which was
discussed here: https://github.com/msys2/MINGW-packages/issues/22462
This results in FFMpeg compiled with that toolchain no longer accepting UTF-8
paths,
unless the UTF-8 codepage is actively selected through fftools.ma
On Mon, 11 Nov 2024, Lars Weber wrote:
Recent changes in MSYS2 have changed the default console code page, which was
discussed here: https://github.com/msys2/MINGW-packages/issues/22462
This results in FFMpeg compiled with that toolchain no longer accepting UTF-8
paths,
unless the UTF-8 codepa
Hi,
On Sun, Nov 10, 2024 at 6:53 PM Michael Niedermayer
wrote:
> Hi
>
> I have been given recordings of VDD by the Reconnaissance General Bureau.
> (didnt listen to all yet)
>
> IIUC there was a talk where it was suggested (by kieran?) to have some
> assembly langauge course on FFmpeg github. IM
Hi,
On Fri, Nov 8, 2024 at 10:38 AM Ronald S. Bultje wrote:
> Before:
> $ make tools/enc_recon_frame_test
> $ tools/enc_recon_frame_test ~/Movies/cif/bus_cif.y4m libx264 'tune=psnr'
> Error submitting a frame for encoding
>
> After:
> All 150 encoded frames match
> ---
> tools/enc_recon_frame_t
On Mon, 11 Nov 2024 14:07:21 +
AV Muppet via ffmpeg-devel wrote:
> On Monday, November 11th, 2024 at 3:12 AM, Rémi Denis-Courmont
> wrote:
>
> > > I recently read a news article about impressive AVX-512
> > > optimizations of Motion Compensation functions and I'd like to
> > > learn more. U
From 4067c58be8e719a55d89e68aaa9d3db19b88b32f Mon Sep 17 00:00:00 2001
From: Chen
Date: Fri, 8 Nov 2024 22:21:19 -0800
Subject: [PATCH] Fix memory leak in the libx265
---
libavcodec/libx265.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libx265.c b
On Mon, Nov 11, 2024 at 04:25:00PM +0200, Martin Storsjö wrote:
> On Mon, 11 Nov 2024, Timo Rothenpieler wrote:
>
> >
> >
> > On 11/11/2024 15:02, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Sun, Nov 10, 2024 at 6:53 PM Michael Niedermayer
> >
> > > wrote:
> > >
> > > > Hi
> > > >
> > >
On Mon, Nov 11, 2024 at 4:27 AM Frank Plowman wrote:
>
>
> On 10/11/2024 12:13, Nuo Mi wrote:
> > This commit introduced a regression to
> VVC_HDR_UHDTV1_OpenGOP_3840x2160_50fps_HLG10_mosaic.ts.
> >
> > Root Cause:
> > The AV_CEIL_RSHIFT(a, b) macro uses bit tricks that work only when -a is
> a n
On Mon, Nov 11, 2024 at 10:02:27AM +, Derek Buitenhuis wrote:
> On 11/10/2024 2:59 PM, Michael Niedermayer wrote:
> > Its there since a long time:
> > https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/doc/infra.txt
>
> [...]
>
> > If something is missing, its not going to improve on its own
On Mon, Nov 11, 2024 at 5:31 PM compn wrote:
>
> On Mon, 11 Nov 2024 17:00:42 +
> Derek Buitenhuis wrote:
>
> > This only convinces me further that it this whole setup ins't for for
> > purpose, and is being run by people who have no concept of actual
> > security. This is totally insane.
>
>
On Mon, Nov 11, 2024 at 08:56:16AM +0100, Niklas Haas wrote:
> From: Niklas Haas
>
> Most logic from this filter has been co-opted into swscale itself,
> allowing the resulting filter to be substantially simpler as it no
> longer has to worry about context initialization, interlacing, etc.
>
> S
On 11/11/2024 10:47 PM, Michael Niedermayer wrote:
On Mon, Nov 11, 2024 at 08:56:16AM +0100, Niklas Haas wrote:
From: Niklas Haas
Most logic from this filter has been co-opted into swscale itself,
allowing the resulting filter to be substantially simpler as it no
longer has to worry about cont
On 11/11/2024 4:56 AM, Niklas Haas wrote:
From: Niklas Haas
This is a preliminary step to separating these into a new struct. This
commit contains no functional changes, it is a pure search-and-replace.
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas
---
libswscale/aarch64/swsc
On 11/10/2024 2:59 PM, Michael Niedermayer wrote:
> Its there since a long time:
> https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/doc/infra.txt
[...]
> If something is missing, its not going to improve on its own.
> Someone will have to say _what_ is missing and work toward filling it in.
P
On 10/11/2024 23:57, James Almer wrote:
> On 11/10/2024 3:38 PM, Frank Plowman wrote:
>> These assembly optimisations can use MMX. They failed to reset the
>> floating-point state when they are done, hence subsequent floating-point
>> operations return nonsense values.
>>
>> This fixes the FATE fa
On 11/6/2024 2:48 PM, Michael Niedermayer wrote:
> do i unilaterally decide who i trust as root, maybe.
Q.E.D.
That, along with Fabrice's control of ffmpeg.org and French trademark,
despite not havign contributed in 20 years, purely for ego reasons, mean
we can never move to a truly community run
On Mon, Nov 11, 2024 at 4:24 AM Frank Plowman wrote:
> This was the only floating point logic in the native VVC decoder.
>
👍, applied.
>
> Signed-off-by: Frank Plowman
> ---
> libavcodec/vvc/intra_utils.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libav
On Sat, Nov 2, 2024 at 1:27 PM Zhao Zhili wrote:
> From: Zhao Zhili
>
> There were static functions which built for x86_32, but the simd
> functions they reference only available for x86_64.
>
Thank you, Zhili,
Merged
> ---
> libavcodec/x86/vvc/vvcdsp_init.c | 5 +
> 1 file changed, 5 inse
Hi,
Le 11 novembre 2024 04:11:22 GMT+02:00, AV Muppet via ffmpeg-devel
a écrit :
>Dear ffmpeg developers,
>
>I recently read a news article about impressive AVX-512 optimizations
>of Motion Compensation functions and I'd like to learn more.
>Unfortunately, the article merely linked the post on X
I have confirmed that these failures in FATE were due to the insufficient
floating point precision of a 32-bit environment.
The commit 82467b635efced67c1767cb810af1f3c31a2e493 introduces the improved
dequantization in FF_DWT97_INT path and makes FFmpeg compliant for ISO/IEC
15444-4 (Conformance
Thanks.
I found the cause of these UBSAN errors.
I will send a patch to fix those soon.
> On Nov 10, 2024, at 0:54, James Almer wrote:
>
> On 11/8/2024 2:23 AM, Pierre-Anthony Lemieux wrote:
>> Ok will merge the patch below.
>
> src/libavcodec/jpeg2000dec.c:1972:117: runtime error: left shift
This patch fixes undefined behaviour error in left shift
operations in jpeg2000dec.c and jpeg2000htdec.c.
Signed-off-by: Osamu Watanabe
---
libavcodec/jpeg2000dec.c | 6 +++---
libavcodec/jpeg2000htdec.c | 6 +++---
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/jpeg
From: Niklas Haas
This rewrite cleans up the code to use AVFrames and the new swscale API. The
log format has also been simplified and expanded to account for the new
options. (Not yet implemented)
The self testing code path has also been expanded to test the new swscale
implementation against t
From: Niklas Haas
As part of a larger, ongoing effort to modernize and partially rewrite
libswscale, it was decided and generally agreed upon to introduce a new
public API for libswscale. This API is designed to be less stateful, more
explicitly defined, and considerably easier to use than the ex
Hi,
Le 11 novembre 2024 01:44:26 GMT+02:00, Michael Niedermayer
a écrit :
>Hi all
>
>as we will likely have 15k available from STF "2024" for another task/project
>what should it be used for ?
>
>I think the obvious options are:
>
>1. gitlab / forgeyo setup + hw + maintaince on our infrastructur
Hi
On Mon, Nov 11, 2024 at 05:00:42PM +, Derek Buitenhuis wrote:
> On 11/11/2024 4:42 PM, Michael Niedermayer wrote:
> > Publically listing which developer provides which part of the DNS infra
> > makes it easier to attack not harder.
> > That said, i suspect who provides what was mentioned in
On Tue, 5 Nov 2024, Marton Balint wrote:
On Mon, 4 Nov 2024, James Almer wrote:
On 11/4/2024 5:30 PM, Marton Balint wrote:
If the audio loop stops inside an audio frame, the leftover buffer
contains the
end of the frame, which is not looped. The length supposed to be the
part
On Monday, November 11th, 2024 at 12:09 PM, compn wrote:
> are you trying to say that ffmpeg should take down the tweet?
I only provided my observations (with the caveat that I'm still potentially
lacking context). What anyone might want to do about it isn't for me to say.
If you'd like to che
Le 11 novembre 2024 18:42:37 GMT+02:00, Michael Niedermayer
a écrit :
>On Mon, Nov 11, 2024 at 10:02:27AM +, Derek Buitenhuis wrote:
>> On 11/10/2024 2:59 PM, Michael Niedermayer wrote:
>> > Its there since a long time:
>> > https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/doc/infra.txt
On 11/11/2024 4:42 PM, Michael Niedermayer wrote:
> Publically listing which developer provides which part of the DNS infra
> makes it easier to attack not harder.
> That said, i suspect who provides what was mentioned in the past already
It is already publically available info to anyone who can l
On Mon, 11 Nov 2024 18:17:11 +
Kieran Kunhya via ffmpeg-devel wrote:
> On Mon, Nov 11, 2024 at 5:31 PM compn wrote:
> >
> > what is your goal?
> >
> > thanks
> > -compn
>
> Here are some quotes presented without comment:
if your goal is to post old quotes, thats cool.
one of my goals is
On Tue, 12 Nov 2024, martin schitter wrote:
The git history of Patches here on this mailinglist are usually rewritten
whenever one of the reviewers requests some change, but the typical workflow
in github/gitlab doesn't use or even forbids this kind of changes in uploaded
code resp. forced pus
On 11.11.24 08:11, Diederick C. Niehorster wrote:
I have no personal experience with gitlab, but it:
I'm a long term GitLab user. I use it for most of my work on self-hosted
instances but also on gitlab.com.
In the past it was a really impressive alternative to github, which
provided use
Hi Chen,
> On Nov 12, 2024, at 01:09, chen wrote:
>
> From 4067c58be8e719a55d89e68aaa9d3db19b88b32f Mon Sep 17 00:00:00 2001
>
> From: Chen
>
> Date: Fri, 8 Nov 2024 22:21:19 -0800
>
> Subject: [PATCH] Fix memory leak in the libx265
>
>
>
>
> ---
>
> libavcodec/libx265.c | 4 +++-
>
> 1
On Tue, Nov 12, 2024 at 3:38 AM Zhao Zhili wrote:
>
> cleanup() release library static allocations, and I don’t see lock or
> reference count
> within x265_cleanup(). So call cleanup() will break other x265 encoder
> instance,
> right?
x265 already crashes when trying to run two encodes with di
haven't seen arpi in a while so remove his root authorized key + remove
him from maintainers. maybe he'll come back?
anyone know how to contact tim nicholson? his mails are
bouncing. https://uk.linkedin.com/in/tim-nicholson-7a2a3963
-compn
diff --git a/MAINTAINERS b/MAINTAINERS
index 7ac5614c18..
41 matches
Mail list logo
