> On Feb 27, 2025, at 12:35, Pavel Koshevoy wrote:
>
> On Wed, Feb 26, 2025 at 8:03 PM Zhao Zhili <
> quinkblack-at-foxmail@ffmpeg.org> wrote:
>
>>
>>
>>> On Feb 24, 2025, at 00:47, Pavel Koshevoy wrote:
>>>
>>> On Fri, Feb 21, 2025 at 9:49 AM Pavel Koshevoy
>> wrote:
>>>
If the
On Wed, Feb 26, 2025 at 8:03 PM Zhao Zhili <
quinkblack-at-foxmail@ffmpeg.org> wrote:
>
>
> > On Feb 24, 2025, at 00:47, Pavel Koshevoy wrote:
> >
> > On Fri, Feb 21, 2025 at 9:49 AM Pavel Koshevoy
> wrote:
> >
> >> If there are no further constructive review comments today and tomorrow
> >>
On Wed, Feb 26, 2025 at 11:44 AM Pranav Kant via ffmpeg-devel
wrote:
>
> [...]
> --- a/libavutil/attributes_internal.h
> +++ b/libavutil/attributes_internal.h
> @@ -31,4 +31,19 @@
> #define FF_VISIBILITY_POP_HIDDEN
> #endif
>
> +/**
> + * Some globals defined in C files are used from hardcod
> On Feb 24, 2025, at 00:47, Pavel Koshevoy wrote:
>
> On Fri, Feb 21, 2025 at 9:49 AM Pavel Koshevoy wrote:
>
>> If there are no further constructive review comments today and tomorrow
>> then I will commit and push this change on Sunday (if I don't forget).
>>
>> Pavel.
>>
>
>
> Pushed
> It prevents the filter of running in case such option is missing,
> failing early, during init() instead of simply logging an error
> during runtime.
>
> It depends on this other change:
>
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/6c4d8098-bb57-4f7c-
> b86b-9221492b7...@gmail.com/
>
> Instead, rely on AV_OPT_TYPE_FLAG_ARRAY, which will automatically
> perform the parsing.
>
> Signed-off-by: Leandro Santiago
> ---
> libavfilter/vf_dnn_detect.c | 43 -
> 1 file changed, 4 insertions(+), 39 deletions(-)
>
> diff --git a/libavfilter/vf_dnn_d
On Wed, Feb 26, 2025 at 12:03:12AM -0300, James Almer wrote:
> On 2/25/2025 11:28 PM, Michael Niedermayer wrote:
> > Hi all
> >
> > As i backported the fixes for $subj, i noticed they depend on
> > ff_match_url_ext()
> > which is not avaiable before 6.1
> >
> > I will thus backport this too unles
Signed-off-by: Michael Niedermayer
---
doc/developer.texi | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/doc/developer.texi b/doc/developer.texi
index a1bfe180c9b..6a753f99da6 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -179,18 +179,17 @@ int field
On 2/25/2025 10:51 PM, Michael Niedermayer wrote:
Hi Marth64
On Tue, Feb 25, 2025 at 05:04:00PM -0600, Marth64 wrote:
Dear FFmpeg Community,
We’d like to share an update on the work of the Community Committee
(CC). Starting this week, we will hold a weekly internal panel to
discuss community m
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Mittwoch, 26. Februar 2025 01:39
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] avformat/hls: Revert "reduce default
> max reload to 3"
>
> Hi
On Wed, 26 Feb 2025, at 02:51, Michael Niedermayer wrote:
> 1. I agree we need discussions, transparency and maybe IRC or some other
>audio/video form of commuication can be tried. Such discussion should be
>public and open. And they must include admins and main authors.
Great, the mailing
On Sun, Feb 23, 2025 at 9:47 AM Pavel Koshevoy wrote:
>
>
> On Fri, Feb 21, 2025 at 9:49 AM Pavel Koshevoy
> wrote:
>
>> If there are no further constructive review comments today and tomorrow
>> then I will commit and push this change on Sunday (if I don't forget).
>>
>> Pavel.
>>
>
>
> Pushed
> While people who spent a significant time of their life working on FFmpeg
> may be great developers, their skillset might not be matching the one
> needed to handle a community.
>
> Cmon we've been over these points, let's not rehash the same drama over and
> over, and let the volunteers of the C
On 24.02.2025 21:51, Timo Rothenpieler wrote:
---
doc/APIchanges | 3 +++
libavutil/timecode.c | 24 +++-
libavutil/timecode.h | 17 +
libavutil/version.h | 2 +-
4 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/doc/APIchanges b/d
On 26.02.2025 03:42, Scott Theisen wrote:
On 2/25/25 13:43, Timo Rothenpieler wrote:
---
libavcodec/cuviddec.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 67076a1752..312742fb8c 100644
--- a
I added it to attributes_internal.h. The existing attribute in
attributes_internal.h (attribute_visibility_hidden) is also being used with
DECLARE_ALIGNED macros (see libavcodec/sbrdsp_template.c). My new macro is
similar in nature.
On Wed, Feb 26, 2025 at 11:44 AM Pranav Kant wrote:
> By defaul
By default, all globals in C/C++ compiled by clang are allocated
in non-large data sections. See [1] for background on code models.
For PIC (Position independent code), this is fine as long as binary is
small but as binary size increases, users maybe want to use medium/large
code models (-mcmodel=m
On 2/26/2025 1:57 PM, Andreas Rheinhardt wrote:
James Almer:
ff_decode_frame_props() injects global side data passed by the caller (Usually
coming from the container) but ignores the global side data the decoder
gathered from the bitstream itself.
This commit amends this.
Signed-off-by: James A
Hi,
On Wed, Feb 26, 2025 at 12:23 PM Tristan Matthews via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:
> On Friday, February 21st, 2025 at 5:15 AM, Chris Hodges <
> chris.hod...@axis.com> wrote:
>
> > Hi Tristan,
> >
> > On 12/13/24 14:44, Tristan Matthews via ffmpeg-devel wrote:
> >
> > > Nice
On Friday, February 21st, 2025 at 5:15 AM, Chris Hodges
wrote:
> Hi Tristan,
>
> On 12/13/24 14:44, Tristan Matthews via ffmpeg-devel wrote:
>
> > Nice, looking forward to testing the next iteration.
>
>
> Sorry for the long delay, I got sidetracked with other work.
>
> > On a related note,
On 2025-02-25 21:42:13, Scott Theisen wrote:
On 2/25/25 13:43, Timo Rothenpieler wrote:
---
libavcodec/cuviddec.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 67076a1752..312742fb8c 100644
--
James Almer:
> ff_decode_frame_props() injects global side data passed by the caller (Usually
> coming from the container) but ignores the global side data the decoder
> gathered from the bitstream itself.
> This commit amends this.
>
> Signed-off-by: James Almer
> ---
> libavcodec/decode.c | 9
It's no longer needed now that lavc handles this.
Signed-off-by: James Almer
---
fftools/ffmpeg_dec.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c
index 01a6933bcc..62edbb6c24 100644
--- a/fftools/ffmpeg_dec.c
+++ b/fftools/ffmpeg_dec.c
ff_decode_frame_props() injects global side data passed by the caller (Usually
coming from the container) but ignores the global side data the decoder
gathered from the bitstream itself.
This commit amends this.
Signed-off-by: James Almer
---
libavcodec/decode.c | 9 +
1 file changed, 9
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Nicolas George
> Sent: Mittwoch, 26. Februar 2025 15:08
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Kieran Kunhya
> Subject: Re: [FFmpeg-devel] I've written a filter in Rust
>
> Soft Works (HE12025-0
On 2/26/25 17:03, Zhao Zhili wrote:
Plugin interface can be abused, but at the same time, they can fulfill many
legitimate
user needs. Not everyone can write a program based on
libavcodec/libavformat/libavfilter,
and get the same function as fftools. They can write a filter plugin, and let
Pushed these two patches, along with the patch to remove the ARNR coder.
The patch to move the encoder into libavcodec/aac/ will be resent.
On 08/02/2025 05:12, Lynne wrote:
The LTP profile of AAC is... terrible.
It was an early 90's attempt at bridging the gap between speech
codecs and general
> On Feb 26, 2025, at 23:32, Rémi Denis-Courmont wrote:
>
> Hi,
>
> Le 26 février 2025 16:18:20 GMT+02:00, Zhao Zhili
> a écrit :
>>
>>
>>> On Feb 26, 2025, at 21:50, Tomas Härdin wrote:
>>>
>>> fre 2025-02-21 klockan 20:10 + skrev Soft Works:
From: Kieran Kunhya
>>
Hi,
Le 26 février 2025 16:18:20 GMT+02:00, Zhao Zhili
a écrit :
>
>
>> On Feb 26, 2025, at 21:50, Tomas Härdin wrote:
>>
>> fre 2025-02-21 klockan 20:10 + skrev Soft Works:
>>>
>>>
>>> From: Kieran Kunhya
>>> Sent: Freitag, 21. Februar 2025 20:27
>>> To: Soft Works
>>> Cc: FFmpeg devel
If there are no comments, I’ll merge it in a few days.
___
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 "unsubs
(I am replying to the messages in general, not inline, as I got lost with all
the subthreads).
My opinion on C++ vs Rust:
I've been using mostly C++ during my career (~15 years) and I confess I kind of
lost hope on its future. I no longer see any advantages of writing new code in
C++ just beca
Soft Works (HE12025-02-24):
> Accepted. I'll outfactor the writers first. It's a valid point of course;
> I just wasn't sure whether you would dislike me doing it.
I dislike the fact that it will be done on top of a pedestrian or clumsy
strings API, but I know precisely where to lay the blame for
tis 2025-02-18 klockan 15:43 +0100 skrev Tomas Härdin:
> Based on replies so far it seems no one is objecting to the following
> patches:
>
> * [PATCH 1/8] avformat/http: Return EIO for prematurely broken connection
> * [PATCH 2/8] libavcodec/wmadec: Return AVERROR_INVALIDDATA on decoding errors
>
mån 2025-02-24 klockan 16:51 +0200 skrev Rémi Denis-Courmont:
> Hi,
>
> Le 23 février 2025 23:30:03 GMT+02:00, "Tomas Härdin"
> a écrit :
> > lör 2025-02-22 klockan 14:57 +0200 skrev Rémi Denis-Courmont:
> > > Le perjantaina 21. helmikuuta 2025, 20.02.16 UTC+2 Tomas Härdin a
> > > écrit :
> > > >
On Fri, Feb 21, 2025 at 3:30 PM Soft Works <
softworkz-at-hotmail@ffmpeg.org> wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: Freitag, 21. Februar 2025 14:22
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
On Wed, Feb 26, 2025 at 2:51 AM Michael Niedermayer
wrote:
> Hi Marth64
>
> On Tue, Feb 25, 2025 at 05:04:00PM -0600, Marth64 wrote:
> > Dear FFmpeg Community,
> >
> > We’d like to share an update on the work of the Community Committee
> > (CC). Starting this week, we will hold a weekly internal
> On Feb 26, 2025, at 21:50, Tomas Härdin wrote:
>
> fre 2025-02-21 klockan 20:10 + skrev Soft Works:
>>
>>
>> From: Kieran Kunhya
>> Sent: Freitag, 21. Februar 2025 20:27
>> To: Soft Works
>> Cc: FFmpeg development discussions and patches
>>
>> Subject: Re: [FFmpeg-devel] I've written
It prevents the filter of running in case such option is missing,
failing early, during init() instead of simply logging an error
during runtime.
It depends on this other change:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/6c4d8098-bb57-4f7c-b86b-9221492b7...@gmail.com/
Signed-off-by: Lean
sön 2025-02-23 klockan 22:51 +0100 skrev Michael Niedermayer:
> Hi
>
> On Sun, Feb 23, 2025 at 10:30:03PM +0100, Tomas Härdin wrote:
> > lör 2025-02-22 klockan 14:57 +0200 skrev Rémi Denis-Courmont:
> > > Le perjantaina 21. helmikuuta 2025, 20.02.16 UTC+2 Tomas Härdin a écrit :
> > > > The above s
Soft Works (HE12025-02-21):
> Open means it's extensible for everybody, including vendors. I fail to see
> what's bad about it. Do we have a fight against everything commercial?
I am with Kieran and Tomas on this. This feature would make it
extensible for everybody, but considering that it is alre
Instead, rely on AV_OPT_TYPE_FLAG_ARRAY, which will automatically
perform the parsing.
Signed-off-by: Leandro Santiago
---
libavfilter/vf_dnn_detect.c | 43 -
1 file changed, 4 insertions(+), 39 deletions(-)
diff --git a/libavfilter/vf_dnn_detect.c b/libavfil
by first changing the RTSPSource to track the destination address
obtained from the source filter. For each RTSPStream, only add the source
filter from the sdp if sdp_ip string matches source-filter's destination
address.
Before issuing the setup request, change the lower_transport to
multicast if
fre 2025-02-21 klockan 20:10 + skrev Soft Works:
>
>
> From: Kieran Kunhya
> Sent: Freitag, 21. Februar 2025 20:27
> To: Soft Works
> Cc: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] I've written a filter in Rust
>
>
> On Fri, 21 Feb 2025, 15:02 Soft Works,
So, perhaps sdp_parse_line should not be void and should propagate an error
code up that should be returned by ff_sdp_parse.
On Wed, Feb 26, 2025, 8:16 AM Rashad Tatum wrote:
> In other parts of the ffmpeg code base where the return type is not void
> for the function, NULL is returned and then
I'll submit a separate patch for this issue
On Wed, Feb 26, 2025, 8:18 AM Rashad Tatum wrote:
> So, perhaps sdp_parse_line should not be void and should propagate an
> error code up that should be returned by ff_sdp_parse.
>
> On Wed, Feb 26, 2025, 8:16 AM Rashad Tatum wrote:
>
>> In other part
In other parts of the ffmpeg code base where the return type is not void
for the function, NULL is returned and then the caller typically returns
AVERROR.
Strangely, sdp_parse_line is void and it seems like ff_sdp_parse always
returns 0, despite the caller (sdp_read_header) attempting to handle an
As a side note, I think the failure of the rtsp_src memory allocation
should also log an error so that the user is aware of why the rtsp stream
failed to play. However, I think this change should be part of separate
patch series.
On Wed, Feb 26, 2025, 7:14 AM Rashad Tatum wrote:
> Ok. I'll move
Ok. I'll move this and the third patch to one commit/patch and also change
the condition when rtsp_src can't be allocated to also free dest_addr. Good
catch.
On Wed, Feb 26, 2025, 3:53 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:
> Rashad Tatum:
> > ---
> > libavformat/rtsp.c
Andreas Rheinhardt:
> Patches attached
>
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, visit link above,
Andreas Rheinhardt:
> Patches attached
>
>
Will apply this tomorrow unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or ema
Andreas Rheinhardt:
> Patch attached
>
>
Will apply this tomorrow unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
> On Feb 21, 2025, at 02:49, Krzysztof Pyrkosz via ffmpeg-devel
> wrote:
>
> ---
> libavcodec/aarch64/vvc/inter.S | 125 -
> 1 file changed, 122 insertions(+), 3 deletions(-)
>
The patchset LGTM.
___
ffmpeg-devel ma
Rashad Tatum:
> ---
> libavformat/rtsp.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index 0c65f8d1a4..ac17717195 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -478,6 +478,7 @@ static void sdp_parse_line(AVFormatContext
53 matches
Mail list logo
