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
36 matches
Mail list logo
