On Tue, Jun 3, 2025 at 2:32 PM Andreas Rheinhardt
wrote:
>
> Patches attached.
>
> - Andreas
All lgtm, thanks for the cleanup.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
We were using a mix of pointers to local variables read via AV_RL32/64 and
pointers directly to the texture buffer as keys to interact with the lookback
hashtables. On big-endian systems, these produced different values. This change
makes all hashtable interactions use direct pointers to the textur
On Mon, Jun 02, 2025 at 11:25:43AM +0200, Quentin RENARD wrote:
> > If this filter is meant to be same as existing zoompan but more precise,
> > then you should modify the original filter with a mode option for FP use.
>
> Thing is I hesitated modifying the existing zoompan but there are a few
>
Hi,
for the sake of also having given a technical answer:
> You say that, but I don't see that at all. In 3 of your 4 cases, the
> two sets of fields seem to be close to identical with no good reason
> to be separate
Let's go through it once again:
1. AV_SUBTITLE_FLOW_NORMAL
"close to identi
On Mon, Jun 02, 2025 at 09:47:56AM +0800, Nuo Mi wrote:
> From: Frank Plowman
>
> My OpenPGP key is available at
>
> https://keys.openpgp.org/vks/v1/by-fingerprint/34E248D6B7DF476970C7330403A84C6A098F2C6B
>
> and
>
> https://keyserver.ubuntu.com/pks/lookup?op=get&search=0x34e248d6b7df476970c73
Hi Andreas
On Mon, Jun 02, 2025 at 05:47:41PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > This allows adjusting them to exactly match whatever is fastest on
> > a given CPU for each type.
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/examples/avio_read_callback.c
Hi Zach
On Tue, Jun 03, 2025 at 11:34:17AM -0700, Zach Swena wrote:
[...]
> The way I see it, rudeness has been present on all sides of most of the
> conflicts I have seen on the ML lately and it is way too easy to reflect
> rudeness back so yes I think everyone on here needs to get over it and w
>
> all members of fflabs where aware of it as i asked about the license
> situation it in the private
> fflabs IRC channel. I asked there because fflabs/jb has a lawyer
>
Do you understand that the lawyer of FFlabs represents the interests of
FFlabs and does not represent the interests of FFmpeg?
Hello everybody,
as I am so tired about people who are claiming that the two additional fields
(subtitle-start & -duration) would not be required and I would not have made
plausible why those would be needed and it would be doable with the pts and
duration fields of AVFrame alone, that I'm set
Rashad Tatum:
> Add implementation for changing the play rate for rtsp streams.
> ---
> libavformat/avformat.h| 6 ++
> libavformat/demux.h | 6 ++
> libavformat/demux_utils.c | 6 ++
> libavformat/rtsp.c| 1 +
> libavformat/rtsp.h| 10 ++
> libavf
Patches attached.
- Andreas
From 7cc1c15bb30c47edb354512fffb1f4148e7e0a9f Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Tue, 3 Jun 2025 21:38:41 +0200
Subject: [PATCH 1/9] avcodec/Makefile: Only compile hashtable.o when needed
Signed-off-by: Andreas Rheinhardt
---
libavcodec/Makefile
On 6/3/2025 1:40 PM, Nicolas George wrote:
James Almer (HE12025-06-03):
The first sentence was unnecessary. No need to be this aggressive.
“softworks” has been abusing many people in the last week but it is
Lynne that you decide to chide?
I missed it if he was aggressive to someone else befo
Le mar. 3 juin 2025 à 14:20, Andreas Rheinhardt
a écrit :
>
> Romain Beauxis:
> > Le mar. 3 juin 2025 à 12:12, Andreas Rheinhardt
> > a écrit :
> >>
> >> Romain Beauxis:
> >>> This is a redo of 574f634e49847e2225ee50013afebf0de03ef013 using a flat
> >>> memory storage for the extradata.
> >>>
> >
Romain Beauxis:
> Le mar. 3 juin 2025 à 12:12, Andreas Rheinhardt
> a écrit :
>>
>> Romain Beauxis:
>>> This is a redo of 574f634e49847e2225ee50013afebf0de03ef013 using a flat
>>> memory storage for the extradata.
>>>
>>> PR review comments addressed:
>>> * Use flat memory array
>>> * Rename struc
> -Original Message-
> From: ffmpeg-devel On Behalf Of softworkz .
> Sent: Dienstag, 3. Juni 2025 16:21
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
How many people do remember that Paul actually wanted to merge my patchset?
> -Original Message-
> From: ffmpeg-devel On Behalf Of Hendrik
> Leppkes
> Sent: Dienstag, 3. Juni 2025 20:02
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> On Tue, Jun 3, 2025 at 4:21 PM softworkz .
> wrote:
> >
> > M
Le mar. 3 juin 2025 à 12:12, Andreas Rheinhardt
a écrit :
>
> Romain Beauxis:
> > This is a redo of 574f634e49847e2225ee50013afebf0de03ef013 using a flat
> > memory storage for the extradata.
> >
> > PR review comments addressed:
> > * Use flat memory array
> > * Rename structure to follow convent
On Tue, Jun 3, 2025 at 10:59 AM Nicolas George wrote:
> Softworkz has been rude and insulting to me, they have been rude and
> insulting to people I respect.
>
> Are you asking me to suck it up and help them?
The way I see it, rudeness has been present on all sides of most of the
conflicts I hav
> -Original Message-
> From: ffmpeg-devel On Behalf Of Devlist
> Archive
> Sent: Dienstag, 3. Juni 2025 19:16
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> > Given the preceding conversations, it is pretty safe to a
Patches attached.
- Andreas
From 94466f8cd58e9a457cf7249d5907d99c80ba5d57 Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Tue, 3 Jun 2025 16:44:08 +0200
Subject: [PATCH 1/7] avutil/frame: Always return error upon error
(I don't know whether this can be triggered for a file with
nonnegati
On Tue, Jun 3, 2025 at 4:21 PM softworkz .
wrote:
>
> Making it explicit now in the form of the AVSubtitleFlowMode enum
> provides a number of benefits:
>
> - It finally provides an understandable explanation for why those two
> extra timing fields are needed
>
You say that, but I don't see tha
Devlist Archive (HE12025-06-03):
> Please can we stop keeping score and give everyone a chance to actually get
> some work done?
Softworkz has been rude and insulting to me, they have been rude and
insulting to people I respect.
Are you asking me to suck it up and help them?
> One subject that d
On NVIDIA, there's a global maximum limit of approximately 112 queues,
which means it takes ONLY 7 total programs using the maximum amount of
queues to cause the driver to error out/*segfault* during initialization.
Also, each queue takes about 30ms to allocate, which quickly adds up.
This reduce
We don't use them, and on NVIDIA, each queue takes around 30ms
to allocate, and the driver has a global limit of ONLY 112 queues.
---
libavutil/hwcontext_vulkan.c | 8
1 file changed, 8 deletions(-)
diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index aa0bfa3756
Romain Beauxis:
> This is a redo of 574f634e49847e2225ee50013afebf0de03ef013 using a flat
> memory storage for the extradata.
>
> PR review comments addressed:
> * Use flat memory array
> * Rename structure to follow convention
> * Add stddef.h header
>
> Bonus: libavcodec/vorbisdec.c diff is gre
Which code branch does the patchset being discussed live in?
Zach
On Tue, Jun 3, 2025 at 10:15 AM Devlist Archive wrote:
> > Given the preceding conversations, it is pretty safe to assume
> > that these comments are based on personal sentiments rather than
> > technical expertise.
>
> While the
> -Original Message-
> From: ffmpeg-devel On Behalf Of Lynne
> Sent: Dienstag, 3. Juni 2025 18:00
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> You don't get to say "oh, there were no more objections, so it was fine"
> or "the use is evid
> Given the preceding conversations, it is pretty safe to assume
> that these comments are based on personal sentiments rather than
> technical expertise.
While there may be truth to that, it isn't helpful to discount objections
without a chance to substantiate them. If the person objecting choos
> -Original Message-
> From: ffmpeg-devel On Behalf Of Nicolas
> George
> Sent: Dienstag, 3. Juni 2025 18:44
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> Lynne (HE12025-06-04):
> > You don't get to say "oh, there we
Please can we stop keeping score and give everyone a chance to actually get
some work done? I would love to see more objective discussions on this
topic. As others have mentioned, let's focus on why specific things are
needed so any objections can be understood and translated into code
modificati
Add implementation for changing the play rate for rtsp streams.
---
libavformat/avformat.h| 6 ++
libavformat/demux.h | 6 ++
libavformat/demux_utils.c | 6 ++
libavformat/rtsp.c| 1 +
libavformat/rtsp.h| 10 ++
libavformat/rtspdec.c | 21 +
Lynne (HE12025-06-04):
> You don't get to say "oh, there were no more objections, so it was fine" or
> "the use is evident" after the mess that your original patchsets were.
>
> You're still not using the native time fields, nor the packet buffers, which
> is a very hard NAK from me.
Indeed. And n
On Tue, 3 Jun 2025, Niklas Haas wrote:
On Mon, 02 Jun 2025 15:41:33 -0300 James Almer wrote:
GCC/Clang is smart enough to emit minss/maxss the same way as these functions.
The only theoretical benefit was in x86_32, where x87 floats are used, but the
penalty of making the clipping opaque to th
James Almer (HE12025-06-03):
> The first sentence was unnecessary. No need to be this aggressive.
“softworks” has been abusing many people in the last week but it is
Lynne that you decide to chide?
--
Nicolas George
___
ffmpeg-devel mailing list
ffmp
On Tue, 03 Jun 2025 18:22:30 +0200 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > On Mon, 02 Jun 2025 15:41:33 -0300 James Almer wrote:
> >> GCC/Clang is smart enough to emit minss/maxss the same way as these
> >> functions.
> >> The only theoretical benefit was in x86_32, where x87 floats are us
> -Original Message-
> From: ffmpeg-devel On Behalf Of softworkz .
> Sent: Dienstag, 3. Juni 2025 16:21
> To: FFmpeg development discussions and patches
> Subject: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
I am sorry in case this message was somewhat too brief for anybody.
Of co
Add implementation for changing the play rate for rtsp streams.
---
libavformat/avformat.h| 6 ++
libavformat/demux.h | 6 ++
libavformat/demux_utils.c | 6 ++
libavformat/rtsp.c| 1 +
libavformat/rtsp.h| 10 ++
libavformat/rtspdec.c | 21 +
Niklas Haas:
> On Mon, 02 Jun 2025 15:41:33 -0300 James Almer wrote:
>> GCC/Clang is smart enough to emit minss/maxss the same way as these
>> functions.
>> The only theoretical benefit was in x86_32, where x87 floats are used, but
>> the
>> penalty of making the clipping opaque to the compiler'
On Mon, 02 Jun 2025 15:41:33 -0300 James Almer wrote:
> GCC/Clang is smart enough to emit minss/maxss the same way as these functions.
> The only theoretical benefit was in x86_32, where x87 floats are used, but the
> penalty of making the clipping opaque to the compiler's scheduler plus moving
>
Add implementation for changing the play rate for rtsp streams.
---
libavformat/avformat.h| 6 ++
libavformat/demux.h | 6 ++
libavformat/demux_utils.c | 6 ++
libavformat/rtsp.c| 1 +
libavformat/rtsp.h| 10 ++
libavformat/rtspdec.c | 21 +
On Fri, 30 May 2025 09:58:48 +0300 Rémi Denis-Courmont wrote:
>
> That will harm performance on x87, whence fminf() and co are function calls
> rather than single instructions. What we actually should do is define
> separate macros for integer vs float vs double.
We have an open bug in swscale
Hi Lynne,
Hope all is well with you.
On Tue, Jun 3, 2025 at 12:00 PM Lynne wrote:
> You're still not using the native time fields, nor the packet buffers,
> which is a very hard NAK from me.
I know there's been alot of pushback on the use of the native time
fields, but have you actually read so
> -Original Message-
> From: ffmpeg-devel On Behalf Of Lynne
> Sent: Dienstag, 3. Juni 2025 18:00
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [RFC] Subtitle Filtering Ramp-Up
>
> You don't get to say "oh, there were no more objections, so it was fine"
If you do have an
Add implementation for changing the play rate for rtsp streams.
---
libavformat/avformat.h| 6 ++
libavformat/demux.h | 6 ++
libavformat/demux_utils.c | 6 ++
libavformat/rtsp.c| 1 +
libavformat/rtsp.h| 10 ++
libavformat/rtspdec.c | 21 +
The first sentence was unnecessary. No need to be this aggressive.
On 6/3/2025 1:00 PM, Lynne wrote:
You don't get to say "oh, there were no more objections, so it was fine"
or "the use is evident" after the mess that your original patchsets were.
You're still not using the native time fields,
You don't get to say "oh, there were no more objections, so it was fine"
or "the use is evident" after the mess that your original patchsets were.
You're still not using the native time fields, nor the packet buffers,
which is a very hard NAK from me.
On 03/06/2025 23:20, softworkz . wrote:
> -Original Message-
> From: ffmpeg-devel On Behalf Of Andreas
> Rheinhardt
> Sent: Dienstag, 3. Juni 2025 16:34
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH WIP 01/10] ffbuild/bin2c: Use zlib directly
> instead of gzip
>
> softworkz .:
> >
> >
> >> -Original M
softworkz .:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of Andreas
>> Rheinhardt
>> Sent: Montag, 2. Juni 2025 04:39
>> To: FFmpeg development discussions and patches
>> Subject: [FFmpeg-devel] [PATCH WIP 01/10] ffbuild/bin2c: Use zlib directly
>> instead of gzip
>>
>> Th
Hello everybody,
[just deleted a whole page of introduction text that was
essentially pointless]
Getting right to the point, I will give it once another try,
rework and resubmit an updated version of the subtitle filtering
patchset, including all improvements and fixes that have been
made in
Hi Remi
On Mon, Jun 02, 2025 at 06:38:54PM +0300, Rémi Denis-Courmont wrote:
[...]
> >And the "explicit license notice" you refer to is this:
> >
> >"All Librempeg modifications, and any new files not available in FFmpeg, are
> >licensed under GPL v2,
> > unless stated otherwise."
>
> So, which
Hi Derek
On Mon, Jun 02, 2025 at 06:08:17PM +0100, Derek Buitenhuis wrote:
> Hi,
>
> Dropping this grenade in here then unsubscribing.
>
> I see a lot of discussion on FEC, protocols, etc. for STF.
>
> But having those is almost pointless given avformat doesn't even check
> read and write calls
Servus Michael,
On Sat, May 31, 2025 at 12:51 AM Michael Niedermayer
wrote:
> > > > /* smooth top and left block borders with neighbours */
> > > > -if (((pxoff - p + k) < 0) || ((pxoff - p + k) >= maxpxo)
> > > > +if (((pxoff - p + 0) < 0) || ((pxoff - p + k
On Mon, 02 Jun 2025 13:54:27 +0200 Niklas Haas wrote:
> From: Niklas Haas
>
> The old logic failed to take into account files that ended on ablack
> region. The new logic matches the vf_blackdetect behavior.
Will push if there are no objections.
___
ff
53 matches
Mail list logo
