[FFmpeg-devel] [ANNOUNCEMENT] almpeg

[Michael Niedermayer]

Hi all

Id like to announce that ive setup a repository to merge pauls work of
the last 2 years.

* Currently ive merged everything up to first february 2025
* all fate tests pass
* Some filters and decoders where split in 2 versions
thats because either teh added chanegs are buggy, break API/cmd line 
interface
or plain the 2 versions are actively developed and too diverged

Note the license of this code is a bit wonky. The files have one
license and theres another one in LICENSE.md.
While I belives legally this allows one to choose either. I suggest
you check this with a lawyer.

g...@git.ffmpeg.org:almpeg

all ffmpeg developers should have write access to it (if you dont,
send me private mail/ping and expect 1-2 days to fix)

If you want to fix any mistakes in this, thats welcome!
currently gitlog mails are just sent to me, this can be changed if people want

Now, what is this good for ?
Once teh merges match the current date, we can either
* just merge it (with 0 conflicts)
* cherry pick from it easily (its closer to FFmpeg)
We can also for the cherry picking easily collaborate
using the almpeg repository and commit requested changes from
patch review to it

PS: today it seems a merge between master and almpeg has just 22 conflicts
a direct merge from pauls code with master has 1145 conflicts

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


signature.asc
Description: PGP signature
___
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 "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7 3/4] ogg/vorbis: implement header packet skip in chained ogg bitstreams.

[Michael Niedermayer]

Hi Romain

On Sat, May 24, 2025 at 01:08:06PM -0500, Romain Beauxis wrote:
[...]
> I'm gonna send an updated patchset. I've also added a FATE test for this
> sample, given it's importance during this review, it seems natural to
> include it.

yes, tests are important
thank you

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is a danger to trust the dream we wish for rather than
the science we have, -- Dr. Kenneth Brown


signature.asc
Description: PGP signature
___
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 "unsubscribe".

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[compn]

On Sun, 25 May 2025 23:29:45 +0100, Kieran Kunhya via ffmpeg-devel
wrote:

> Hi Michael,
> 
> Here is how this should be handled.

stop with this nonsense.

-compn
___
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 "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] avformat/matroska: Support JPEG2000 for demuxing

[Andreas Rheinhardt]

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. should we include a way to -vfw-codec-id
> manual for those systems? maybe is unimportant but it would be good to
> ask the ffv1 specification crowd about this change to mkv muxing. and
> maybe resend patch separately from jpeg2000 decoding subject. hiding an
> ffv1 change under jpeg2000 subj is weird.

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/51a600106bfa66f58a7f2c8e05fab091ab059ebd)?
Anyway, I cc'ed Dave Rice, the author of the aforementioned commit.

> 
> said another another way, this change would change the checksums of
> files if people tried to recreate their mkv. which is something that
> archivists do sometimes.

That's generally what happens when you update your FFmpeg, not only for
the Matroska muxer, but for any component that is under active
development. We don't give guarantees that the output stays the same
when using different git snapshots.
Specifically for Matroska, there have been multiple commits changing the
output of basically every Matroska file created by our muxer (often by
using fewer bytes to write length fields); see e.g. git log
tests/ref/fate/matroska-flac-extradata-update
(Btw: The second patch in this set shows that simply remuxing is
dangerous for FFV1 in VFW-mode.)

- Andreas

___
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 "unsubscribe".

Re: [FFmpeg-devel] [PATCH] fix(configure): fix detection on windows

[Coia Prant]

Thank you!
Can you merge it in x264?
I also send a merge request.

Martin Storsjö  于 2025年5月25日周日 22:50写道：

> On Fri, 23 May 2025, Coia Prant wrote:
>
> > On Windows Arm64
> > `uname -m` returned `x86_64` instead of `aarch64`
> > Link: https://github.com/msys2/msys2-runtime/issues/171
> >
> > On x86 32-bit toolchain msys2 environment
> > `uname -m` returned `x86_64` instead of `i686` or `x86`
> >
> > So check MSYSTEM_CARCH on windows (for arm64 and i686)
> >
> > This problem also in VideoLAN/x264
> > Link: https://code.videolan.org/videolan/x264/-/merge_requests/177
> >
> > Signed-off-by: Coia Prant 
> > ---
> > configure | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/configure b/configure
> > index 2e69b3c..ed30b6b 100755
> > --- a/configure
> > +++ b/configure
> > @@ -4157,6 +4157,8 @@ if test "$target_os_default" = aix; then
> > arch_default=$(uname -p)
> > strip_default="strip -X32_64"
> > nm_default="nm -g -X32_64"
> > +elif test "$MSYSTEM_CARCH" != ""; then
> > +arch_default="$MSYSTEM_CARCH"
> > else
> > arch_default=$(uname -m)
> > fi
> > --
> > 2.49.0.windows.1
>
> This approach seems reasonable to me.
>
> (On i686 vs x86_64, it hasn't been an issue, since they all map into "x86"
> within ffmpeg, and configure then checks the bitness, but for arm64 it's
> indeed an issue.)
>
> I can push the patch soon if nobody minds it.
>
> // Martin
>
>
___
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 "unsubscribe".

Re: [FFmpeg-devel] [PATCH v5 4/4] lavc: implement a Vulkan-based VC-2 encoder Implements a Vulkan based dirac encoder. Supports Haar and Legall wavelets and should work with all wavelet depths.

[Michael Niedermayer]

On Fri, May 23, 2025 at 11:23:48PM +0300, IndecisiveTurtle wrote:
> From: IndecisiveTurtle 
> 
> Performance wise, encoding a 3440x1440 1-minute video is performed in about 
> 2.4 minutes with the cpu encoder running on my Ryzen 5 4600H, while it takes 
> about 1.3 minutes on my NVIDIA GTX 1650
> 
> Haar shader has a subgroup optimized variant that applies when configured 
> wavelet depth allows it
> ---
>  configure|   1 +
>  libavcodec/Makefile  |   3 +
>  libavcodec/allcodecs.c   |   1 +
>  libavcodec/vc2enc.c  |   2 +-
>  libavcodec/vc2enc_vulkan.c   | 777 +++
>  libavcodec/vulkan/vc2_dwt_haar.comp  |  82 ++
>  libavcodec/vulkan/vc2_dwt_haar_subgroup.comp |  75 ++
>  libavcodec/vulkan/vc2_dwt_hor_legall.comp|  82 ++
>  libavcodec/vulkan/vc2_dwt_upload.comp|  96 +++
>  libavcodec/vulkan/vc2_dwt_ver_legall.comp|  78 ++
>  libavcodec/vulkan/vc2_encode.comp| 173 +
>  libavcodec/vulkan/vc2_slice_sizes.comp   | 170 
>  12 files changed, 1539 insertions(+), 1 deletion(-)
>  create mode 100644 libavcodec/vc2enc_vulkan.c
>  create mode 100644 libavcodec/vulkan/vc2_dwt_haar.comp
>  create mode 100644 libavcodec/vulkan/vc2_dwt_haar_subgroup.comp
>  create mode 100644 libavcodec/vulkan/vc2_dwt_hor_legall.comp
>  create mode 100644 libavcodec/vulkan/vc2_dwt_upload.comp
>  create mode 100644 libavcodec/vulkan/vc2_dwt_ver_legall.comp
>  create mode 100644 libavcodec/vulkan/vc2_encode.comp
>  create mode 100644 libavcodec/vulkan/vc2_slice_sizes.comp

changes fate results:

--- ./tests/ref/vsynth/vsynth1-vc2-420p 2025-05-23 14:14:31.58136 +0200
+++ tests/data/fate/vsynth1-vc2-420p2025-05-26 00:35:09.596187444 +0200
@@ -1,4 +1,4 @@
-74df65b15463f098587d8c09d87286a1 *tests/data/fate/vsynth1-vc2-420p.mov
-1155415 tests/data/fate/vsynth1-vc2-420p.mov
+bea01eb2c6212e8828802fdb28dc7eaf *tests/data/fate/vsynth1-vc2-420p.mov
+1045964 tests/data/fate/vsynth1-vc2-420p.mov
 387696707c79cf1a6c9aeff4024226b9 *tests/data/fate/vsynth1-vc2-420p.out.rawvideo
 stddev:0.00 PSNR:999.99 MAXDIFF:0 bytes:  7603200/   760320
Test vsynth1-vc2-420p failed. Look at tests/data/fate/vsynth1-vc2-420p.err for 
details.


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


signature.asc
Description: PGP signature
___
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 "unsubscribe".

[FFmpeg-devel] libswscale.c : ff_xyz12Torgb48 expensive unaligned 16 byte accesses

[Chitra Dey Sarkar via ffmpeg-devel]

H
We have been profiling FFmpeg at Microsoft and have identified that 
ff_xyz12ToRgb48 has a high sample count ( profiled every 1ms )

It seems like ff_xyz12ToRgb48 has performance penalty for

  1.  Unaligned read and write access
  2.  Access to xyz2rgb_matrix
  3.  Multiplication

I would be interested in optimizing this code , wanted to check if there is an 
existing optimized version of this function, or any recommended approach to 
improve it(?
I can move the repeated access to xyz2rgb_matrix outside the inner loop and 
load a full cache line at once to extract the X, Y, and Z values more 
efficiently-but I wanted to start by getting some initial feedback or thoughts 
before proceeding further


File : FFmpeg/libswscale/swscale.c at a79720e10f30e9fd18bd78242ce96dde06461343 
* 
FFmpeg/FFmpeg

void ff_xyz12Torgb48(const SwsInternal *c, uint8_t *dst, int dst_stride,
 const uint8_t *src, int src_stride, int w, int h)
{
.. Unaligned read ...
   x = AV_RL16(src16 + xp + 0);
y = AV_RL16(src16 + xp + 1);
z = AV_RL16(src16 + xp + 2);


.. DRAM Access and multiply  ...

// convert from XYZlinear to sRGBlinear
r = c->xyz2rgb_matrix[0][0] * x +
c->xyz2rgb_matrix[0][1] * y +
c->xyz2rgb_matrix[0][2] * z >> 12;
g = c->xyz2rgb_matrix[1][0] * x +
c->xyz2rgb_matrix[1][1] * y +
c->xyz2rgb_matrix[1][2] * z >> 12;
b = c->xyz2rgb_matrix[2][0] * x +
c->xyz2rgb_matrix[2][1] * y +
c->xyz2rgb_matrix[2][2] * z >> 12;

.. RMW Access ...
AV_WL16(dst16 + xp + 0, c->rgbgamma[r] << 4);
AV_WL16(dst16 + xp + 1, c->rgbgamma[g] << 4);
AV_WL16(dst16 + xp + 2, c->rgbgamma[b] << 4);


Regards
Chitra
___
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 "unsubscribe".

Re: [FFmpeg-devel] libswscale.c : ff_xyz12Torgb48 expensive unaligned 16 byte accesses

[James Almer]

On 5/25/2025 9:44 PM, Chitra Dey Sarkar via ffmpeg-devel wrote:

H
We have been profiling FFmpeg at Microsoft and have identified that 
ff_xyz12ToRgb48 has a high sample count ( profiled every 1ms )

It seems like ff_xyz12ToRgb48 has performance penalty for

   1.  Unaligned read and write access
   2.  Access to xyz2rgb_matrix
   3.  Multiplication

I would be interested in optimizing this code , wanted to check if there is an 
existing optimized version of this function, or any recommended approach to 
improve it(?
I can move the repeated access to xyz2rgb_matrix outside the inner loop and 
load a full cache line at once to extract the X, Y, and Z values more 
efficiently-but I wanted to start by getting some initial feedback or thoughts 
before proceeding further


Niklas is currently working in a library rewrite, which may affect xyz 
scaling. But in any case, the obvious approach is a SIMD optimized 
implementation (SSE2, AVX2, etc) of this function.




OpenPGP_signature.asc
Description: OpenPGP digital signature
___
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 "unsubscribe".

Re: [FFmpeg-devel] [PATCH] fix(configure): fix detection on windows

[Martin Storsjö]

On Fri, 23 May 2025, Coia Prant wrote:


On Windows Arm64
`uname -m` returned `x86_64` instead of `aarch64`
Link: https://github.com/msys2/msys2-runtime/issues/171

On x86 32-bit toolchain msys2 environment
`uname -m` returned `x86_64` instead of `i686` or `x86`

So check MSYSTEM_CARCH on windows (for arm64 and i686)

This problem also in VideoLAN/x264
Link: https://code.videolan.org/videolan/x264/-/merge_requests/177

Signed-off-by: Coia Prant 
---
configure | 2 ++
1 file changed, 2 insertions(+)

diff --git a/configure b/configure
index 2e69b3c..ed30b6b 100755
--- a/configure
+++ b/configure
@@ -4157,6 +4157,8 @@ if test "$target_os_default" = aix; then
arch_default=$(uname -p)
strip_default="strip -X32_64"
nm_default="nm -g -X32_64"
+elif test "$MSYSTEM_CARCH" != ""; then
+arch_default="$MSYSTEM_CARCH"
else
arch_default=$(uname -m)
fi
--
2.49.0.windows.1


This approach seems reasonable to me.

(On i686 vs x86_64, it hasn't been an issue, since they all map into "x86" 
within ffmpeg, and configure then checks the bitness, but for arm64 it's 
indeed an issue.)


I can push the patch soon if nobody minds it.

// Martin

___
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 "unsubscribe".

Re: [FFmpeg-devel] gcc: Remove auto-vectorization limitation.

[Michael Niedermayer]

Hi Rémi

On Sat, May 24, 2025 at 07:10:57PM +0300, Rémi Denis-Courmont wrote:
> Le torstaina 22. toukokuuta 2025, 9.32.18 Itä-Euroopan kesäaika Jiawei a 
> écrit 
> :
> > > The RISC-V autovectorised output looks like it has a warning "Odd
> > > rotation angle" which is not present in the non-autovectorised output.
> > 
> > I found this occured when using '-ffast-math' in RISC-V, also occur in
> > -O3 -ffast-math -fno-tree-vectorize case(much slower due to the
> > -ffast-math)，supplementary more comparison results here:
> 

> Unfortunately, the FFmpeg code is written with x87 semantics in mind.

I dont remember ever writing code intentionally with x87 semantics. And i
have doubts other people did.

What i did in soem rare places do, was depend on IEEE 754 semantics
(that is when doing so lead to simpler and cleaner code)


> For
> instance, the FFmpeg math macros work nicely on x86, but they would work much 
> better with fabs/fmax/fmin/fabsf/fmaxf/fminf on other platforms. I tried to 
> fix 
> that with copious amount of _Generic(), but that lead to ICE...

ICE as the name says, is a internal compiler error and not the fault of
the code passed to the compiler


> 
> So we are stuck between a rock and a hard place where we need fast math for 
> good perfs, but we need to turn it off for correct results.

--ffast-math is not one option, its many

on the gcc here, it does this:
+  -fassociative-math   [enabled]
+  -fcx-limited-range   [enabled]
+  -ffinite-math-only   [enabled]
+  -fmath-errno [disabled]
+  -freciprocal-math[enabled]
+  -fsigned-zeros   [disabled]
+  -ftrapping-math  [disabled]
+  -funsafe-math-optimizations  [enabled]

So maybe some of this can be globally enabled.

But some things like fassociative-math are simply not "safe"
on general nummeric code. It also violates ISO C according to
the official gcc documentation

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact


signature.asc
Description: PGP signature
___
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 "unsubscribe".

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[Kieran Kunhya via ffmpeg-devel]

Hi Michael,

Here is how this should be handled.

"Hi Paul,

I'm sorry for aggressively trying to force SDR into the FFmpeg project
over a period of several weeks in spite of objections from you and the
community causing you to leave.
FFmpeg is now a better community* and we would love it if you could come back.

Regards,
Michael Niedermayer
"
* Narrator: It is not a better community

Regards,
Kieran Kunhya

On Sun, May 25, 2025 at 8:23 PM 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 everything up to first february 2025
> * all fate tests pass
> * Some filters and decoders where split in 2 versions
> thats because either teh added chanegs are buggy, break API/cmd line 
> interface
> or plain the 2 versions are actively developed and too diverged
>
> Note the license of this code is a bit wonky. The files have one
> license and theres another one in LICENSE.md.
> While I belives legally this allows one to choose either. I suggest
> you check this with a lawyer.
>
> g...@git.ffmpeg.org:almpeg
>
> all ffmpeg developers should have write access to it (if you dont,
> send me private mail/ping and expect 1-2 days to fix)
>
> If you want to fix any mistakes in this, thats welcome!
> currently gitlog mails are just sent to me, this can be changed if people want
>
> Now, what is this good for ?
> Once teh merges match the current date, we can either
> * just merge it (with 0 conflicts)
> * cherry pick from it easily (its closer to FFmpeg)
> We can also for the cherry picking easily collaborate
> using the almpeg repository and commit requested changes from
> patch review to it
>
> PS: today it seems a merge between master and almpeg has just 22 conflicts
> a direct merge from pauls code with master has 1145 conflicts
>
> thx
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many things microsoft did are stupid, but not doing something just because
> microsoft did it is even more stupid. If everything ms did were stupid they
> would be bankrupt already.
> ___
> 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 "unsubscribe".
___
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 "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] avformat/matroska: Support JPEG2000 for demuxing

[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. should we include a way to -vfw-codec-id
manual for those systems? maybe is unimportant but it would be good to
ask the ffv1 specification crowd about this change to mkv muxing. and
maybe resend patch separately from jpeg2000 decoding subject. hiding an
ffv1 change under jpeg2000 subj is weird.

said another another way, this change would change the checksums of
files if people tried to recreate their mkv. which is something that
archivists do sometimes.

e.g. old ffv1 mkv vfw codec_id
vs
new ffv1 mkv codec_id

-compn
___
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 "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/asvenc: Don't waste bits encoding non-visible part

[Martin Storsjö]

On Mon, 26 May 2025, Andreas Rheinhardt wrote:


ffmpeg | branch: master | Andreas Rheinhardt  | 
Thu May 22 15:57:13 2025 +0200| [0401ca714a2714743573e27c384ffa810fd31a92] | 
committer: Andreas Rheinhardt

avcodec/asvenc: Don't waste bits encoding non-visible part

Up until now, the encoder replicated all the border pixels
for incomplete 16x16 macroblocks. In case the available width
or height is <= 8, some of the luma blocks of the MB
do not correspond to actual input, so that we should encode
them using the least amount of bits. Zeroing the block coefficients
(as this commit does) achieves this, replicating the pixels
and performing an FDCT does not.

This commit also removes the frame copying code for insufficiently
aligned dimensions.

The vsynth3-asv[12] FATE tests use a 34x34 input file and are
therefore affected by this. As the ref updates show, the size
and checksum of the encoded changes, yet the decoded output
stays the same.

Signed-off-by: Andreas Rheinhardt 


http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=0401ca714a2714743573e27c384ffa810fd31a92

---

libavcodec/asvenc.c   | 131 ++
tests/ref/vsynth/vsynth3-asv1 |   4 +-
tests/ref/vsynth/vsynth3-asv2 |   4 +-
3 files changed, 84 insertions(+), 55 deletions(-)


As noted on irc, this broke the fate-vsynth3-asv1 and fate-vsynth3-asv2 
tests on arm.


The issue is not AV_COPY128 as Andreas wondered on irc; the reason is 
a->pdsp.get_pixels. We have a backtrace like this:


#0  0x00cfdd2a in ff_get_pixels_neon ()
at src/libavcodec/arm/pixblockdsp_neon.S:47
#1  0x0082ea54 in dct_get (mb_y=0, mb_x=0, frame=0xf6202f40, a=0x297f450)
at src/libavcodec/asvenc.c:222
#2  encode_frame (avctx=0x297f150, pkt=0xf6202ec0, pict=0xf6202f40,
got_packet=0xf7df4af0) at src/libavcodec/asvenc.c:304

The arguments to a->pdsp.get_pixels are this on entry:

(gdb) info registers r0 r1 r2
r0 0x297f4a0   43512992
r1 0x297caa0   43502240
r2 0x2234

After one iteration, it hits the bus error due to unaligned reads from the 
source, which was expected to stay aligned after incrementing by the 
stride.


// Martin

___
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 "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/graphprint: Now, make it a Killer-Feature!

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Rémi Denis-
> Courmont
> Sent: Samstag, 24. Mai 2025 17:55
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/graphprint: Now, make it a
> Killer-Feature!
> 
> Le perjantaina 16. toukokuuta 2025, 1.19.15 Itä-Euroopan kesäaika softworkz .
> a écrit :
> > of course I understand that.
> > But it isn't constructed from untrusted input.
> 
> You're being ridiculous. `system()` has a long history of causign bugs, many
> of them security related, and many not fixable.
> 
> If you were implementing a command line interface that needs to process
> trusted input like the shell would, you would want to use `wordexp()`.
> 
> As you merely need to spawn a child process, use the `posix_spawn`*`()`
> available, and `fork()` then `exec`*`()` elsewhere. 


glibc's system() implementation is using posix_spawn internally since 2.34 and
before that, it is using fork() and execve() to launch sh.


> We don't want to spawn a
> shell just to start a well-known executable (other than the shell itself).

And yet, exactly the latter is happening, because the code is
invoking a shell script (xdg-open) - it doesn't launch a browser
executable.
Sadly, this has been misunderstood by many - who commented 
without even looking at the code.

Sure - we could invoke the script as an executable - that would
give us a single advantage: we would then supply the html file
path as an argument rather than in a command string. This 
prevents injection attacks that try to escape to the shell,
but that's just one possible attack vector. Just because we 
supply it as an argument to the script doesn't mean it's 
safe. The xdg-open scripts can differ by platform and can have
their own vulnerabilities. And since xdg-open is redirecting
to a variety of applications - from which every single one can 
have its own vulnerabilities, there is not much safety we 
would have gained by that.

It all burns down to this: 

It is our responsibility to make sure that the path we are
passing over is safe. No matter how we are calling xdg-open.

That path is constructed programmatically, it doesn't depend
on user input. It is constructed from the temp folder path
combined with a file name that has a fixed format generated 
from the time of execution.

There has been one comment (can't find it anymore) that I would
call the single most valid comment made in this regard, which 
was about the way how the temp path is determined on Linux,
and that's where I agree that it isn't safe enough in the way
how it was done.


Best regards,
sw

___
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 "unsubscribe".

Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/graphprint: Now, make it a Killer-Feature!

[softworkz .]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Rémi Denis-
> Courmont
> Sent: Samstag, 24. Mai 2025 18:02
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] fftools/graphprint: Now, make it a
> Killer-Feature!
> 
> Le perjantaina 16. toukokuuta 2025, 3.54.21 Itä-Euroopan kesäaika Michael
> Niedermayer a écrit :
> > 1. lets all calm down, so far we have a civil and productive discussion
> >maybe we can simply find a solution everyone is happy with!
> >
> > 2. all security issues must be fixed if there are some
> 
> system() is security issue incarnate.
> 
> > 3. there should be a configure flag to enable/disable the browser opening
> > feature if it remains
> 
> I don't see the point in having a configure flag. Either the TC finds the
> feature
> should not exist at all, and it should not exist at all. Or else, the feature
> can stay as a disabled-by-default *run-time* flag and with the security issues
> fixed.
> 
> > 4. can system() be replaced by fork()+exec*() ? is that something people
> > would prefer ?
> 
> That is obviously far more adequate, though certain precautions are
> potentially necessary such as resetting signal handling.

Which is what system() does already.

The funny thing is, that if I would have copied glibc's implementation of
system() - nobody would have objected.


> > 5. this is a cool feature, i would use this if its available, that said
> >if i had to manually open a browser with a given URL that would work
> >for me too.
> 
> If the feature outputs at a stable URL, keeping a tab open with auto or manual
> refresh would work just as well, indeed, without the controversial feature.

The idea is that each ffmpeg execution opens a new tab, so that you can 
compare between them.


> > 7. as long as the discussion is nice and productive i think the TC is not
> > the best path forward. If things degenerate into some mess then pas it to
> > teh TC, yes
> 
> It's been 6 days, and I don't see how to resolve this other than with a TC
> decision.

It was reverted on the same day already.

Thanks
sw
___
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 "unsubscribe".