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](sao_10bit.o)', assuming: macOS
ld: warning: no platform load command found in
On Mon, May 26, 2025 at 06:36:58PM +0200, Michael Niedermayer wrote:
> Hi
>
> On Sun, May 25, 2025 at 09:22:52PM +0200, Michael Niedermayer wrote:
> > Hi all
> >
> > Id like to announce that ive setup a repository to merge pauls work of
> > the last 2 years.
> >
> > * Currently ive merged everyt
compn:
> maybe i'd change commit message from
> avformat/matroskaenc: Use native id instead of VfW for FFV1
> to
> avformat/matroskaenc: Use native id V_FFV1 instead of V_MS/VFW/FOURCC/FFV1
This would be too long; and inexact: the codec id stored in VFW is
"V_MS/VFW/FOURCC" (the actual codec is t
Patches attached.
- Andreas
From d06296ccf36da8132b567d75d161ff6a0127368a Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Tue, 27 May 2025 15:38:17 +0200
Subject: [PATCH 1/7] avcodec/asvenc: Fix crash with unaligned
pointers/linesizes
This happens on systems where get_pixels really need
On Mon, 26 May 2025 01:50:42 +0200, Andreas Rheinhardt wrote:
> Why should the FFV1 specification crowd object to us writing FFV1 files
> in the way they have been intended to be written since February 2017
> (since
> https://github.com/ietf-wg-cellar/matroska-specification/commit/51a600106bfa66f5
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](sao_10bit.o)', assuming: macOS
ld: warning: no platform load command found in
'libavcodec/libavcodec.a[1009](hpeldsp.o)',
From: softworkz
This commit simplifies and consolidates all the rules around
ptx and resource file compression.
Signed-off-by: softworkz
---
ffbuild/common.mak | 41 +
1 file changed, 17 insertions(+), 24 deletions(-)
diff --git a/ffbuild/common.mak b/f
From: softworkz
When there's a chain of implicit rules, make treats files generated
inside that chain as intermediate files. Those intermediate files are
removed after completion of make. When make is run again, it normally
determines the need for a rebuild by comparing the timestamps of the
orig
V2
==
* Fix MSVC build
(use the universal command pattern)
V3
==
* Skip dependency generation by clearing CC_DEPS instead
(as suggested by Ramiro - thanks!)
V4
==
* Always keep .ptx files (as suggested by Timo - thanks) Tested all
scenarios:
* .ptx.c and .ptx.gz still get de
This patches integrates so called double bufferring when we are loading
2 batch elements at a time and then processing them in parallel. On the
moden arm processors especially Apple Silicon it gives a visible
benefit, for subsampled pixel processing it is especially nice because
it allows to read e
On Mon, 26 May 2025, Coia Prant wrote:
Can u backport it to released branch?
Please don't top-post here.
Sure, that can probably be reasonable; I can try to backport it to a few
release branches within a day or two.
// Martin
___
ffmpeg-devel ma
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Ramiro Polla
> Sent: Dienstag, 27. Mai 2025 21:59
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up
> and move fftools/resources-specific code
On Tue, May 27, 2025 at 9:20 PM softworkz .
wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Ramiro Polla
> > Sent: Dienstag, 27. Mai 2025 14:36
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Marvin Scholz
> Sent: Dienstag, 27. Mai 2025 11:28
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] When to add 'Reviewed-by: xxx' in commit
> messages
>
>
>
> On 3 May 2025, at
On May 27, 2025 9:12:47 AM PDT, Ramiro Polla wrote:
> Hi Jacob,
>
> Thanks. I hadn't thought about gzip implementations that don't support -V.
>
> What about the following?
> echo | gzip -c > /dev/null 2>&1 && enable gzip
That should also work afaik. busybox does support -c.
Jacob
_
Hi,
if there are no more objections, I will apply the following patches below in
2-3h.
Please let me know when you need more time or you have any concerns.
[2/3] ffbuild: correctly silence and tag new css/html steps
[3/3] fftools/resources: add missing extensions to .gitignore
[1/5] fftools/
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Ramiro Polla
> Sent: Dienstag, 27. Mai 2025 14:36
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean up
> and move fftools/resources-specific code
Signed-off-by: Ethan Halsall
---
libavfilter/vf_mcdeint.c | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_mcdeint.c b/libavfilter/vf_mcdeint.c
index 82048b51d0..11ad19f5cd 100644
--- a/libavfilter/vf_mcdeint.c
+++ b/libavfilter
Hi Timo,
On Tue, May 27, 2025 at 3:19 PM Timo Rothenpieler wrote:
> On 27.05.2025 03:33, Ramiro Polla wrote:
> > We currently test at build-time whether zlib supports decoding gzip.
> > This is not needed for the build to succeed, since only the gzip
> > command is necessary to perform compressio
I've found quite a few ways to optimize existing ffmpeg's rgb to yuv
subsampled conversion. In this patch stack I'll try to
improve the perofrmance.
This particular set of changes is a small improvement to all the
existing functions and macro. The biggest performance gain is
coming from post loadi
Hi Jacob,
On Tue, May 27, 2025 at 8:55 AM Jacob Lifshay wrote:
> On Mon, May 26, 2025 at 6:34 PM Ramiro Polla wrote:
> > -[ -x "$(command -v gzip)" ] && enable gzip
> > +gzip -V > /dev/null 2>&1 && enable gzip
>
> idk if you intend it to build with busybox gzip, but busybox gzip
> doesn't suppor
On 25.05.25 04:08, Nuo Mi wrote:
On Thu, May 22, 2025 at 4:35 PM Gabriel Hege wrote:
On 17.05.25 04:26, Nuo Mi wrote:
On Fri, May 16, 2025 at 7:05 PM Gabriel Hege wrote:
This is a resubmission with a corrected commit message.
The default behavior for VVenC (since v1.10.0) is to create a
On Tue, 27 May 2025 16:29:20 +0800 Kieran Kunhya via ffmpeg-devel
wrote:
> >
> > - adding vzeroupper: ~12%
> >
>
> This seems quite suspicious.
> Can you explain what you are doing here?
I added a vzeroupper call whenever the code transitions from AVX to SSE. For
example:
Conversion pass for yu
Hi,
> On May 25, 2025, at 7:50 PM, Andreas Rheinhardt
> wrote:
>
> compn:
>> On Sun, 25 May 2025 05:50:54 +0200, Andreas Rheinhardt wrote:
>>
>>> Patches attached.
>>>
>>> - Andreas
>>
>> looks ok but i wonder if anyone is using the vfw ffv1 mkv in the
>> archiving universe on purpose. shoul
On 27.05.2025 03:33, Ramiro Polla wrote:
We currently test at build-time whether zlib supports decoding gzip.
This is not needed for the build to succeed, since only the gzip
command is necessary to perform compression at build-time.
Presumably this check will help the user by not enabling compr
On Tue, May 27, 2025 at 6:02 AM softworkz .
wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Ramiro
> > Polla
> > Sent: Dienstag, 27. Mai 2025 05:29
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH 4/5] ffbuild/common.mak: clean
Andreas Rheinhardt:
> Patches attached.
>
> - Andreas
>
Will apply and backport the first two patches of this patchset unless
there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffm
Add hardware-accelerated stack filters for CUDA that provide equivalent
functionality to the software stack filters but with GPU acceleration.
Features:
- Support for hstack, vstack, and xstack operations
- Compatible pixel formats such as:
yuv420p, nv12, yuv444p, p010le, p016le, yuv444p16le, rg
On Tue, May 27, 2025 at 02:35:06AM +, softworkz wrote:
> From: softworkz
>
> ..and resources
>
> Signed-off-by: softworkz
> ---
> MAINTAINERS: Add myself for graph printing
>
> ..and resources
>
> Signed-off-by: softworkz softwo...@hotmail.com
>
> Published-As:
> htt
A note on this change: I found some .vtt files while using yt-dlp that follow
a draft version of the WebVTT standard (probably
https://www.w3.org/2013/07/webvtt.html) that use "Region:" for regions instead
of "REGION", and that was causing the conversion to .srt to fail completely.
An example of t
The parser will now strictly check if WebVTT files start with the correct
"WEBVTT" marker. Before, files were not checked if they truly started
with it.
It will also now ignore all non-cue blocks, instead of only a hardcoded
list. This is closer to the specification that calls for no action
if unk
Thanks for pointing that out.
Submitted v2
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20250527092731.51819-1-f1k2fa...@gmail.com/
Changes in v2:
- Fixed documentation copy-paste error in hstack_cuda section
- Corrected filter reference from @ref{vstack} to @ref{hstack}
- Fixed typo "origna
From: Niklas Haas
See docs/swscale-v2.txt for an in-depth introduction to the new approach.
This commit merely introduces the ops definitions and boilerplate functions.
The subsequent commits will flesh out the underlying implementation.
---
libswscale/Makefile | 1 +
libswscale/ops.c| 52
On 3 May 2025, at 11:32, softworkz . wrote:
> Hello everybody,
>
> I have an organizational question that I cannot quite figure out how to do it
> right:
>
> Whether and when to add 'Reviewed-by: xxx' to a commit message?
>
Personally I try add this when someone reviewed and gave a LGTM
for t
From: Niklas Haas
Provides a generic fast path for any operation list that can be decomposed
into a series of memcpy and memset operations.
25% faster than the x86 backend for yuv444p -> yuva444p
33% faster than the x86 backend for gray -> yuvj444p
---
libswscale/Makefile | 1 +
libswscal
>
> - adding vzeroupper: ~12%
>
This seems quite suspicious.
Can you explain what you are doing here?
Kieran
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or
Changes since v2:
- refactored x86 loop to reduce per-line overhead and simplify the code;
eliminate SSE instructions from the process function entirely and also
reduce the number of allocated registers by one
- remove alignment macro from SwsOpExec and align usage instead
- chenge pixel_bits_
From: Niklas Haas
This covers most 8-bit and 16-bit ops, and some 32-bit ops. It also covers all
floating point operations. While this is not yet 100% coverage, it's good
enough for the vast majority of formats out there.
Of special note is the packed shuffle fast path, which uses pshufb at vect
On Tue, 27 May 2025, Niklas Haas wrote:
From: Niklas Haas
Because of the lack of an external ABI on low-level kernels, we cannot
directly test internal functions. Instead, we construct a minimal op chain
consisting of a read, the op to be tested, and a write.
The bigger complication arises fr
On Tue, 27 May 2025, Niklas Haas wrote:
From: Niklas Haas
We split the standard macro into its body (implementation) and declaration,
and use a macro argument in place of the raw `memcmp` call, with the major
difference that we now take the number of pixels to compare instead of the
number of
From: Niklas Haas
Sometimes, when measuring very small functions, rdtsc is not accurate enough
to get a reliable measurement. This increases the number of runs inside the
inner loop from 4 to 32, which should help a lot. Less important when using
the more precise linux-perf API, but still useful.
From: Niklas Haas
Reset an SwsFormat to its fully unset/invalid state.
---
libswscale/format.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/libswscale/format.h b/libswscale/format.h
index 3b6d745159..be92038f4f 100644
--- a/libswscale/format.h
+++ b/libswscale/format.h
@@
From: Niklas Haas
\o/
---
libswscale/graph.c | 84 --
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git a/libswscale/graph.c b/libswscale/graph.c
index dc7784aa49..24930e7627 100644
--- a/libswscale/graph.c
+++ b/libswscale/graph.c
@@ -34,6
From: Niklas Haas
This patch adds format handling code for the new operations. This entails
fully decoding a format to standardized RGB, and the inverse.
Handling it this way means we can always guarantee that a conversion path
exists from A to B without having to explicitly cover logic for each
From: Niklas Haas
This can turn any compatible sequence of operations into a single packed
shuffle, including packed swizzling, grayscale->RGB conversion, endianness
swapping, RGB bit depth conversions, rgb24->rgb0 alpha clearing and more.
---
libswscale/ops_internal.h | 28 +++
libswsc
From: Niklas Haas
This will serve as a reference for the SIMD backends to come. That said,
with auto-vectorization enabled, the performance of this is not atrocious.
It easily beats the old C code and sometimes even the old SIMD.
In theory, we can dramatically speed it up by using GCC vectors in
From: Niklas Haas
This handles the low-level execution of an op list, and integration into
the SwsGraph infrastructure. To handle frames with insufficient padding in
the stride (or a width smaller than one block size), we use a fallback loop
that pads the last column of pixels using `memcpy` into
From: Niklas Haas
See doc/swscale-v2.txt for design details.
---
libswscale/Makefile| 1 +
libswscale/ops_chain.c | 283 +
libswscale/ops_chain.h | 134 +++
3 files changed, 418 insertions(+)
create mode 100644 libswscale/ops_chain.c
From: Niklas Haas
Because of the lack of an external ABI on low-level kernels, we cannot
directly test internal functions. Instead, we construct a minimal op chain
consisting of a read, the op to be tested, and a write.
The bigger complication arises from the fact that the backend may generate
a
From: Niklas Haas
This is responsible for taking a "naive" ops list and optimizing it
as much as possible. Also includes a small analyzer that generates component
metadata for use by the optimizer.
---
libswscale/Makefile| 1 +
libswscale/ops.h | 12 +
libswscale/ops_optimiz
From: Niklas Haas
This adds an internal API for ops backends, which are responsible for
compiling op lists into executable functions.
---
libswscale/ops.c | 62 ++
libswscale/ops_internal.h | 108 ++
2 files changed, 170 insertion
From: Niklas Haas
Give users and developers a way to opt in to the new format conversion code,
and more code from the swscale rewrite in general, even while development is
still ongoing.
---
doc/APIchanges | 3 +++
doc/scaler.texi | 4
libswscale/options.c | 1 +
libswscale/swsca
From: Niklas Haas
We split the standard macro into its body (implementation) and declaration,
and use a macro argument in place of the raw `memcmp` call, with the major
difference that we now take the number of pixels to compare instead of the
number of bytes (to match the signature of float_near
From: Niklas Haas
---
libswscale/format.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libswscale/format.c b/libswscale/format.c
index e4c1348b90..b77081dd7a 100644
--- a/libswscale/format.c
+++ b/libswscale/format.c
@@ -24,14 +24,14 @@
#include "form
54 matches
Mail list logo
