> -Original Message-
> From: ffmpeg-devel On Behalf Of
> James Almer
> Sent: Donnerstag, 29. Mai 2025 05:07
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg_filter: make
> FilterGraphPriv private again
>
> As the name implies, it's a struct meant to be
As the names imply, they are structs meant to be internal and private to the
filter handling code. If a field is required in other modules, then it can
be moved to the public facing structs, which is done in this commit.
Signed-off-by: James Almer
---
fftools/ffmpeg.h | 17 ++
fftools
As the name implies, it's a struct meant to be internal and private to the
filter handling code. If a field is required in other modules, then it can
be moved to the public facing struct, which is done in this commit.
Signed-off-by: James Almer
---
fftools/ffmpeg.h | 4 +++
fftools/ff
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> softworkz .
> Sent: Mittwoch, 28. Mai 2025 17:25
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: [FFmpeg-devel] The "bad" Patch
[..]
That nobody has responded is not much surprising, but don't worr
Hi,
just FYI - I have published my code for the broker service that is queuing
the DevOps builds for Patchwork checks.
It's available on git.ffmpeg.org in a new repo: patchwork_jobs_devops
Web access:
https://git.ffmpeg.org/gitweb/patchwork_jobs_devops.git/tree/refs/heads/main
Best regards
sw
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Martin Storsjö
> Sent: Mittwoch, 28. Mai 2025 12:17
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
>
> On Wed, 28 May 2025, softworkz . wrote
I successfully used this patch series to encode DXV files for a couple
live events this past weekend and did not encounter any decoding
issues with Resolume's first-party Arena software. These DXVs included
inputs that cause Resolume Arena to drop frames when encoded with
ffmpeg master. Again reque
On Wednesday, May 28th, 2025 at 11:17 AM, Michael Niedermayer
wrote:
> Hi
>
> If someone has spare time, there are some public open issues on:
> https://issues.oss-fuzz.com/issues?q=status:open componentid:1638179
> title:ffmpeg
>
> check if they have pending fixes on the ML first and if so h
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marton Balint
> Sent: Mittwoch, 28. Mai 2025 20:28
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
>
>
>
> On Wed, 28 May 2025, softworkz . wrote:
>
> > Please
On Wed, 28 May 2025, softworkz . wrote:
Please note:
I have no intentions towards getting this merged.
It's a valid opinion when you think that "ffmpeg shouldn't
launch a browser" or similar - but that's not the topic.
This is merely a technical question.
"ffmpeg should not launch a brows
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> softworkz .
> Sent: Mittwoch, 28. Mai 2025 20:01
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On
> -Original Message-
> From: ffmpeg-devel On Behalf Of Rémi
> Denis-Courmont
> Sent: Mittwoch, 28. Mai 2025 19:34
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] The "bad" Patch
>
> Hi,
>
> Whatever glibc does or doesn't do is kinda ir
Hi,
Whatever glibc does or doesn't do is kinda irrelevant. FFmpeg is supposed to be
portable and that makes `system()` a non-starter given how bad it *can* be.
With that said, and with my CC hat on, if you would consider a portably safer
alternative, I can only say that considering what strong
Hello everybody,
it's about 14 days ago, on Thursday, 2025-05-15, when I had applied
my "Execution Graph Printing" patchset after 12 revisions and 3
reminder e-mails sent to the ML.
The patch 15/15 had a controversial reception from other FFmpeg
developers, ranging from friendly concerns up to a
From: softworkz
---
fftools/Makefile| 1 +
fftools/graph/_system.c | 213
fftools/graph/_system.h | 27
fftools/graph/_system_support.h | 199 +
fftools/graph/filelauncher.c| 3 +-
5 files
From: softworkz
---
doc/ffmpeg.texi | 4 +
fftools/Makefile | 1 +
fftools/ffmpeg.c | 2 +-
fftools/ffmpeg.h | 1 +
fftools/ffmpeg_filter.c | 2 +-
fftools/ffmpeg_opt.c | 4 +
fftools/graph/filelauncher.c | 200 +++
This is the "bad" patch from the graphprint patchset. It is largely
unchanged, except:
* The method to determine the temp folder has been revised
* Only xdg-open is called for Linux
(no alternate aliases)
* An additional check is added for illustration
(but not actually necessary)
A seco
I have had some work done on captions over on CasparCG, and the dev there
has informed me that Softworkz's Subtitle Filtering or something like it is
a framework that would make solving the embed/extract problem easier for
sidecar and mxf files. The whole set of terminology practice used in this
p
Hi
If someone has spare time, there are some public open issues on:
https://issues.oss-fuzz.com/issues?q=status:open%20componentid:1638179%20title:ffmpeg
check if they have pending fixes on the ML first and if so help review
if no pending fix, please submit a fix.
(its easy to check as fixes shou
Dmitrii Ovchinnikov :
> Certain components require ID3D11/ID3D12 textures to be created with
> additional BindFlags or MiscFlags. FFmpeg currently provides no
> mechanism to configure these flags externally, leaving no way to
> satisfy such components without patching the library.
>
> This patch ad
Certain components require ID3D11/ID3D12 textures to be created with
additional BindFlags or MiscFlags. FFmpeg currently provides no
mechanism to configure these flags externally, leaving no way to
satisfy such components without patching the library.
This patch adds private device options that ca
Certain components require ID3D11/ID3D12 textures to be created with
additional BindFlags or MiscFlags. FFmpeg currently provides no
mechanism to configure these flags externally, leaving no way to
satisfy such components without patching the library.
This patch adds private device options that ca
On Wed, 28 May 2025, Zhao Zhili wrote:
> Why this depending on the codec? Could you provide a case that takes
> several seconds?
I encountered the problem with an RTP live stream using H.264 in
intra-refresh mode. I think the delay is related to seek_frame_generic
trying to find keyframes in t
> On May 23, 2025, at 12:01, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> ---
> libavformat/movenc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 844a371808..5a9e34993f 100644
> --- a/libavformat/movenc.c
> +++ b/l
> On May 22, 2025, at 17:37, Zhao Zhili wrote:
>
> From: Zhao Zhili
>
> The follow cmd output corrupted file before the patch:
>
> ffmpeg -f lavfi -i color=blue,trim=duration=0.04 \
> -f lavfi -i anullsrc,atrim=duration=2 \
> -movflags +empty_moov+hybrid_fragmented \
> -fr
Hi all,
Just a gentle reminder regarding my patch submission:
*[PATCH v2] **avfilter: add CUDA stack filters (hstack_cuda, vstack_cuda,
xstack_cuda)*
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20250527092731.51819-1-f1k2fa...@gmail.com/
This version addresses the feedback from the initial
> On May 28, 2025, at 20:08, Kaarle Ritvanen via ffmpeg-devel
> wrote:
>
> when AVFMTCTX_UNSEEKABLE is set. Depending on the codec, the execution
> of this function may take several seconds. This is an optimization for
Why this depending on the codec? Could you provide a case that takes seve
On Wed, 28 May 2025, softworkz . wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Martin Storsjö
Sent: Mittwoch, 28. Mai 2025 10:29
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
On Wed, 28 May 2025, softworkz .
for live RTP streams. Some external applications, such as Qt Multimedia,
depend on this flag being set correctly.
Signed-off-by: Kaarle Ritvanen
---
libavformat/rtsp.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 5ea47
when AVFMTCTX_UNSEEKABLE is set. Depending on the codec, the execution
of this function may take several seconds. This is an optimization for
the case where the stream is already known unseekable.
Signed-off-by: Kaarle Ritvanen
---
libavformat/seek.c | 3 +++
1 file changed, 3 insertions(+)
dif
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Martin Storsjö
> Sent: Mittwoch, 28. Mai 2025 10:40
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
>
> On Wed, 28 May 2025, softworkz . wrote:
On Wed, 28 May 2025, softworkz . wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Martin Storsjö
Sent: Mittwoch, 28. Mai 2025 10:27
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
As we are talking about Mac
Fang Yibo:
> Re: [FFmpeg-devel,v2,0/2] avfilter: add PCM dumping between filters for audio
> debugging
>
> From: Yibo Fang
> Subject: [FFmpeg-devel,v2,0/2] avfilter: add PCM dumping between filters for
> audio debugging
> Date: Wed, 23 Apr 2025 10:57:00 +0800
> Message-Id:
>
> This series add
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Martin Storsjö
> Sent: Mittwoch, 28. Mai 2025 11:02
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
>
> On Wed, 28 May 2025, softworkz . wrote
On Wed, 28 May 2025, softworkz . wrote:
I haven't looked into in detail it myself, but it is a known issue
since
some of the ffmepg multithreading work a couple years ago. It does
happen
occasionally in all build configurations, more or less often.
Yup. I thought about patching it in the build
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> softworkz .
> Sent: Mittwoch, 28. Mai 2025 11:09
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
[..]
> > > Can you spot any difference to my c
On 28 May 2025, at 10:49, softworkz . wrote:
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Martin Storsjö
>> Sent: Mittwoch, 28. Mai 2025 10:27
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] Building for Mac x86 with GC
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marvin Scholz
> Sent: Mittwoch, 28. Mai 2025 10:57
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
>
>
>
> On 28 May 2025, at 10:49, softwork
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Martin Storsjö
> Sent: Mittwoch, 28. Mai 2025 10:27
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
As we are talking about Mac builds - have
On Wed May 28, 2025 at 1:34 AM PDT, softworkz . wrote:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Martin Storsjö
>> Sent: Mittwoch, 28. Mai 2025 10:29
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] Building for Mac
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Martin Storsjö
> Sent: Mittwoch, 28. Mai 2025 10:27
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
>
> On Wed, 28 May 2025, softworkz . wrote
On Wed May 28, 2025 at 1:12 AM PDT, softworkz . wrote:
>
>
>> -Original Message-
>> From: ffmpeg-devel On Behalf Of
>> Christopher Snowhill
>> Sent: Mittwoch, 28. Mai 2025 09:40
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] Building fo
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Martin Storsjö
> Sent: Mittwoch, 28. Mai 2025 10:29
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
>
> On Wed, 28 May 2025, softworkz . wrote:
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Christopher Snowhill
> Sent: Mittwoch, 28. Mai 2025 09:40
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
>
> On Tue May 27, 2025 at 10:54 PM P
On Wed, 28 May 2025, softworkz . wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Christopher Snowhill
Sent: Mittwoch, 28. Mai 2025 09:40
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
On Tue May 27, 2025 at 10:
On Wed, 28 May 2025, softworkz . wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Martin Storsjö
Sent: Mittwoch, 28. Mai 2025 07:55
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
These warnings appeared since th
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Martin Storsjö
> Sent: Mittwoch, 28. Mai 2025 07:55
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Building for Mac x86 with GCC & NASM
>
> On Tue, 27 May 2025, softworkz . wrote
Yibo Fang (HE12025-05-26):
>
> From: Yibo Fang
> Subject: [FFmpeg-devel,v3,0/2] avfilter: add PCM dumping between filters for
> audio debugging
> Date: Wed, 23 Apr 2025 10:57:00 +0800
> Message-Id:
>
> This series adds a debugging feature that lets developers dump raw
> PCM audio between filte
On Tue May 27, 2025 at 10:54 PM PDT, Martin Storsjö wrote:
> On Tue, 27 May 2025, softworkz . wrote:
>
>> Hi,
>>
>> I have an issue with the CI builds for Mac in a way that it prints
>> tons of lines like this:
>>
>> ld: warning: no platform load command found in
>> 'libavcodec/libavcodec.a[1008](
> On May 27, 2025, at 11:07, Zhao Zhili
> wrote:
>
>
>
>> On May 27, 2025, at 02:48, Kieran Kunhya via ffmpeg-devel
>> wrote:
>>
>> On Mon, May 26, 2025 at 8:13 PM Zhao Zhili
>> wrote:
>>>
>>>
>>>
On May 22, 2025, at 13:06, Zhao Zhili
wrote:
From: Zhao Zhili
>>
50 matches
Mail list logo
