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

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 repli

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.

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 >

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

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

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

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 int

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 unimpor

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

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/f

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

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

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

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 co

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

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-autove

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

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

[FFmpeg-devel] [ANNOUNCEMENT] almpeg

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/c

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

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 x8

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

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

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

> -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. t

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

> -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. to