Re: [FFmpeg-devel] [PATCH v3 00/17] avformat/dvdvideodec: bugfixes and menu chapter markers

[Marth64]

Pushed.
___
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 v3 10/10] ffv1enc: add a Vulkan encoder

[Lynne via ffmpeg-devel]

On 11/15/24 05:50, Lynne wrote:

This commit implements a standard, compliant, version 3 and version 4
FFv1 encoder, entirely in Vulkan. The encoder is written in standard
GLSL and requires a Vulkan 1.3 supporting GPU with the BDA extension.

The encoder can use any amount of slices, but nominally, should use
32x32 slices (1024 in total) to maximize parallelism.

All features are supported, as well as all pixel formats.
This includes:
  - Rice
  - Range coding with a custom quantization table
  - PCM encoding

CRC calculation is also massively parallelized on the GPU.

Encoding of unaligned dimensions on subsampled data requires
version 4, or requires oversizing the image to 64-pixel alignment
and cropping out the padding via container flags.
---
  configure  |1 +
  libavcodec/Makefile|1 +
  libavcodec/allcodecs.c |1 +
  libavcodec/ffv1enc.c   |2 +-
  libavcodec/ffv1enc_vulkan.c| 1598 
  libavcodec/vulkan/Makefile |8 +
  libavcodec/vulkan/common.comp  |  182 +++
  libavcodec/vulkan/ffv1_common.comp |   75 ++
  libavcodec/vulkan/ffv1_enc.comp|   67 +
  libavcodec/vulkan/ffv1_enc_ac.comp |   83 ++
  libavcodec/vulkan/ffv1_enc_common.comp |  101 ++
  libavcodec/vulkan/ffv1_enc_rct.comp|   85 ++
  libavcodec/vulkan/ffv1_enc_rgb.comp|   83 ++
  libavcodec/vulkan/ffv1_enc_setup.comp  |  153 +++
  libavcodec/vulkan/ffv1_enc_vlc.comp|  112 ++
  libavcodec/vulkan/ffv1_reset.comp  |   55 +
  libavcodec/vulkan/ffv1_vlc.comp|  122 ++
  libavcodec/vulkan/rangecoder.comp  |  190 +++
  18 files changed, 2918 insertions(+), 1 deletion(-)
  create mode 100644 libavcodec/ffv1enc_vulkan.c
  create mode 100644 libavcodec/vulkan/common.comp
  create mode 100644 libavcodec/vulkan/ffv1_common.comp
  create mode 100644 libavcodec/vulkan/ffv1_enc.comp
  create mode 100644 libavcodec/vulkan/ffv1_enc_ac.comp
  create mode 100644 libavcodec/vulkan/ffv1_enc_common.comp
  create mode 100644 libavcodec/vulkan/ffv1_enc_rct.comp
  create mode 100644 libavcodec/vulkan/ffv1_enc_rgb.comp
  create mode 100644 libavcodec/vulkan/ffv1_enc_setup.comp
  create mode 100644 libavcodec/vulkan/ffv1_enc_vlc.comp
  create mode 100644 libavcodec/vulkan/ffv1_reset.comp
  create mode 100644 libavcodec/vulkan/ffv1_vlc.comp
  create mode 100644 libavcodec/vulkan/rangecoder.comp



I'll push the patchset tomorrow if there are no more comments to fix.

We should definitely add FATE tests for such implementations.
___
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] Add support for LJ92 compressed MLV files, attempt 02

[South East]

Fuzzing has discovered one crash bug so far.  It's not related to my
changes.

The crash has some potential to be exploitable so I've emailed
 ffmpeg-secur...@ffmpeg.org.  Email includes a sample and repro
instructions.

On Sat, 9 Nov 2024 at 01:08, South East <8billion.peo...@gmail.com> wrote:
>
> On Sat, 9 Nov 2024 at 00:37, Michael Niedermayer  
> wrote:
> >
> > On Mon, Nov 04, 2024 at 06:14:07AM +, South East wrote:
> > > Hi all - what do I need to do to progress this?
> >
> > iam a bit overloaded with work ATM, but bayer or interlacing combined with
> > jpeg gives me memories of segfaults. So maybe you can run this through some 
> > fuzzer
> > with some samples that trigger the code pathes
> > to check it a bit
>
> Thanks.  I have experience with AFL so this is practical for me.  The
> likely output is
> a collection of samples that will improve code coverage, focussing on MLV and
> DNG files.
>
> Does ffmpeg use AFL for testing already?  I would expect to make local code
> modifications to ffmpeg in order to improve speed of fuzzing (see e.g.
> __AFL_LOOP).
> Would you want those changes?  It should be obvious they do something because
> of improved code coverage, perhaps that is enough.
>
> I would expect testing with ffplay (with an ASAN enabled build) would be an
>  acceptable scope (there is no encoder for MLV).  Is that assumption correct?
>
> I would guess we are only interested in new problems when the patches are
> applied, i.e., if I discover old flaws, that shouldn't have any
> bearing on whether
> my patches are accepted.
>
> Beyond that, what would you consider evidence of adequate testing?
___
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 for libx265 memory leak

[Timo Rothenpieler via ffmpeg-devel]

On 16.11.2024 19:46, Tom Vaughan wrote:

Any further details you or others could provide to help the x265 dev team 
resolve the issue would be appreciated.

Can you share your steps to reproduce this issue? What parameters were changed? 
Max CTU size?

Is this documentation inadequate? 
https://x265.readthedocs.io/en/master/api.html#build-considerations


Well, it documents that it'll initialize global variables, but that 
doesn't make it better.

FFmpeg doesn't check that. Nor sure if it even can?
So depending on what the user does, it could just crash if the CTU size 
mismatches between parallel encodes.


So the libx265.c wrapper at least would need to check the already 
initialized global CTU state, and cleanly error out if it mismatches.

Or plain not allow more than exactly one x265 encode.


On 11/11/24, 10:46 PM, "ffmpeg-devel on behalf of Damiano Galassi" 
mailto:ffmpeg-devel-boun...@ffmpeg.org> on behalf of 
dam...@gmail.com > wrote:


On Tue, Nov 12, 2024 at 3:38 AM Zhao Zhili mailto:quinkbl...@foxmail.com>> wrote:




cleanup() release library static allocations, and I don’t see lock or
reference count
within x265_cleanup(). So call cleanup() will break other x265 encoder
instance,
right?





x265 already crashes when trying to run two encodes with different settings
in
the same process, because it's storing some instance specific data in
global variables
that are overwritten when starting a new encode.


So at least with this patch it won't leaks the global data,
but the root issue needs to be fixed in x265.
___
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".


___
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] root access voting

[Michael Niedermayer]

Hi Anton

On Sat, Nov 16, 2024 at 03:16:16AM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2024-11-06 15:48:19)
[...]
> > About git access
> > We have a documented and public process since a very long time.
> > people need to be in MAINTAINERS to get git write.
> 
> 1) That is not true. E.g. I had git push access without being in
>MAINTAINERS.

You added yourself to MAINTAINERS in 2010
ubitux removed several people from MAINTAINERS including you in 2016
And you added yourself back in 2022

on teh gitosis side, you received access in 2010 and no furher change happened
that i can find

I dont think the intend of the removial in 2016 was to have peoples
accounts closed.
for reference: 8f4a2d48344df4bf8bd3ba50fb37361dc0f9bc4f


> 2) Where is it documented and

I guess on the ML and IRC whenever someone asked me how to get git access.
As i was since very long administrating the accounts. These questions would
end with me eventually.

This process is the result of myself wanting to follow a fair process.
And avoiding being accused of favoring or disfavoring anyone.
A process thats not biased toward or against anyone. And a decentralized
process.
And at the time our patch review process worked quite well so simply
using a patch to MAINTAINERS to give everyone a chance to say "no" but at
the same time also put a cost on that, namely that someone saying "no"
should then also be willing to take over maintaince of the area someone
else wants to maintain. And that it has to be in public and with peoples
full names. Someone objecting should be willing to stand up to that in
public.

I did think and do think that this is a good and fair process.

Ill try to document it properly, iam not sure why it seems not
documented outside ML/IRC. I really thought this was documented already
in a more central place


> how is it public? I do not see any public
>log of people who gained git push access.

really MAINTAINERS should be that.
Of course if i miss someone being added and the person doesnt complain
like marth64 most recently. Then a long time can pass with someone not
having git access.


> 3) Why should that be the criterion and who decided it?

I choose this process long ago, I decided it because i did want a fair
process and not just give access to people depending on my preferrance.


will reply to the rest seperately

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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] [PATCH 1/3] doc/developer: Document relationship between git accounts and MAINTAINERS

[Michael Niedermayer]

This should have been documented long ago and i thought it was

Signed-off-by: Michael Niedermayer 
---
 doc/developer.texi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/doc/developer.texi b/doc/developer.texi
index ff181abb582..78053a4623a 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -927,6 +927,25 @@ In case you need finer control over how valgrind is 
invoked, use the
 @code{--target-exec='valgrind } option in
 your configure line instead.
 
+@anchor{Maintenance}
+@chapter Maintenance process
+
+@anchor{MAINTAINERS}
+@section MAINTAINERS
+
+The developers maintaining each part of the codebase are listed in 
@file{MAINTAINERS}.
+Being listed in @file{MAINTAINERS}, gives one the right to have git write 
access to
+the specific repository.
+
+@anchor{Becoming a maintainer}
+@section Becoming a maintainer
+
+People add themselves to @file{MAINTAINERS} by sending a patch like any other 
code
+change. These get reviewed by the community like any other patch. It is 
expected
+that, if someone has an objection to a new maintainer, she is willing to object
+in public with her full name and is willing to take over maintainership for 
the area.
+
+
 @anchor{Release process}
 @chapter Release process
 
-- 
2.47.0

___
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 v2] lavc/x86/videodsp: Drop MMX usage

[Ronald S. Bultje]

Hi,

On Sat, Nov 16, 2024 at 1:00 PM Frank Plowman  wrote:

> Remove the MMX versions of these functions and modify the SSE
> implementations to avoid using MMX registers.
>
> Signed-off-by: Frank Plowman 
> ---
>  libavcodec/x86/videodsp.asm| 61 ++-
>  libavcodec/x86/videodsp_init.c | 88 +-
>  2 files changed, 59 insertions(+), 90 deletions(-)
>

Still LGTM from my side.

Ronald
___
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 2/3] avutil/mem_internal: define DECLARE_ALIGNED as C11's _Alignas

[Scott Theisen]

On 11/16/24 01:56, Rémi Denis-Courmont wrote:

Le perjantaina 15. marraskuuta 2024, 22.09.25 EET Scott Theisen a écrit :

On 11/15/24 08:47, Rémi Denis-Courmont wrote:

Le 15 novembre 2024 12:56:23 GMT+02:00, Zhao Zhili

 a écrit :

From: Zhao Zhili 

_Alignas is portable than compiler's specific __attribute__. It do
have a limitation, that _Alignas don't support specify aligment on
the declarations of struct (it works for specify alignment on struct
fields),
which only used by avcodec/cavs, and is removed now.

IIRC, _Alignas() is deprecated by C23. Can't we use the proper c11/c23
alignas() instead?

_Alignas is an alternative spelling of alignas in C23 (
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf page 53).

I think you are missing the point here. It is all in the small prints:

"These alternative keywords are obsolescent features and should not be used
for new code and development." (C23 §6.4.1 footnote 75)


OK, I missed that.  Should the `#include ` be guarded by 
`#if __STDC_VERSION__ < 202311L` then?

___
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] [RFC] infrastructure documentation

[compn]

Hello,

to continue vdd meeting ideas here on mailing list where everyone can
comment:

Please comment on what you want documented. and if you think it should
be a public document or just available to devs with git write access
etc.

could someone post the link to the videolan infrastructure document?
is it public? that would be helpful. as doc/infra.txt isnt all that
professional looking.

Here is a list of things people want documented. gathered from previous
emails and memories:

1. Complete list of infrastructure
2. where servers are hosted
3. who has what access (physical and remote/software).
4. Who owns avcodec.org? Who runs these DNS servers? Who has access?
Who has contacts?
5. info on backup storage of mailing lists, servers, git repos etc
6. document the release tarball checksum patch in docs/website


thanks
-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".

[FFmpeg-devel] [PATCH 2/3] doc/developer: Document how disagreements should be handled

[Michael Niedermayer]

I think this would work better than TC or nothing process.

Signed-off-by: Michael Niedermayer 
---
 doc/developer.texi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/developer.texi b/doc/developer.texi
index 78053a4623a..2af71ed749a 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -937,6 +937,9 @@ The developers maintaining each part of the codebase are 
listed in @file{MAINTAI
 Being listed in @file{MAINTAINERS}, gives one the right to have git write 
access to
 the specific repository.
 
+In actively maintained areas, the maintainer has the last word in case of a 
technical disagreement.
+In all other cases, the technical committee has the last word in case of a 
technical disagreement.
+
 @anchor{Becoming a maintainer}
 @section Becoming a maintainer
 
-- 
2.47.0

___
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] lavc/x86/videodsp: Drop MMX usage

[Frank Plowman]

On 15/11/2024 20:55, Andreas Rheinhardt wrote:
> Frank Plowman:
>> Remove the MMX versions of these functions and modify the SSE
>> implementations to avoid using MMX registers.
>>
>> Signed-off-by: Frank Plowman 
>> ---
>> This wasn't wholly straightforward as the existing SSE implementation did
>> not only use SSE but rather a blend of SSE and MMX.  I would appreciate
>> some review, as I am not particularly familiar with x86 assembly.  Of
>> particular interest are the changes to {READ,WRITE}_NUM_BYTES.  The new
>> implementation does not make economic use of the XMM registers like the
>> old one did, but it still does not exhaust them -- was this more of a
>> concern when this was originally written?
>> ---
>>  libavcodec/x86/videodsp.asm| 63 ++
>>  libavcodec/x86/videodsp_init.c | 99 +-
>>  2 files changed, 65 insertions(+), 97 deletions(-)
>>
>> diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm
>> index 3cc07878d3..20dcd3e2b9 100644
>> --- a/libavcodec/x86/videodsp.asm
>> +++ b/libavcodec/x86/videodsp.asm
>> @@ -123,54 +123,43 @@ hvar_fn
>>  ; - if (%2 & 8)  fills 8 bytes into xmm$next
>>  ; - if (%2 & 4)  fills 4 bytes into xmm$next
>>  ; - if (%2 & 3)  fills 1, 2 or 4 bytes in eax
>> -; on mmx, - fills mm0-7 for consecutive sets of 8 pixels
>> -; - if (%2 & 4)  fills 4 bytes into mm$next
>> -; - if (%2 & 3)  fills 1, 2 or 4 bytes in eax
>>  ; writing data out is in the same way
>>  %macro READ_NUM_BYTES 2
>>  %assign %%off 0 ; offset in source buffer
>> -%assign %%mmx_idx 0 ; mmx register index
>>  %assign %%xmm_idx 0 ; xmm register index
>>  
>>  %rep %2/mmsize
>> -%if mmsize == 16
>>  movu   xmm %+ %%xmm_idx, [srcq+%%off]
>>  %assign %%xmm_idx %%xmm_idx+1
>> -%else ; mmx
>> -movumm %+ %%mmx_idx, [srcq+%%off]
>> -%assign %%mmx_idx %%mmx_idx+1
>> -%endif
>>  %assign %%off %%off+mmsize
>>  %endrep ; %2/mmsize
>>  
>> -%if mmsize == 16
>>  %if (%2-%%off) >= 8
>>  %if %2 > 16 && (%2-%%off) > 8
>>  movu   xmm %+ %%xmm_idx, [srcq+%2-16]
>>  %assign %%xmm_idx %%xmm_idx+1
>>  %assign %%off %2
>>  %else
>> -movqmm %+ %%mmx_idx, [srcq+%%off]
>> -%assign %%mmx_idx %%mmx_idx+1
>> +movq   xmm %+ %%xmm_idx, [srcq+%%off]
>> +%assign %%xmm_idx %%xmm_idx+1
>>  %assign %%off %%off+8
>>  %endif
>>  %endif ; (%2-%%off) >= 8
>> -%endif
>>  
>>  %if (%2-%%off) >= 4
>>  %if %2 > 8 && (%2-%%off) > 4
>> -movqmm %+ %%mmx_idx, [srcq+%2-8]
>> +movq   xmm %+ %%xmm_idx, [srcq+%2-8]
>>  %assign %%off %2
>>  %else
>> -movdmm %+ %%mmx_idx, [srcq+%%off]
>> +movd   xmm %+ %%xmm_idx, [srcq+%%off]
>>  %assign %%off %%off+4
>>  %endif
>> -%assign %%mmx_idx %%mmx_idx+1
>> +%assign %%xmm_idx %%xmm_idx+1
>>  %endif ; (%2-%%off) >= 4
>>  
>>  %if (%2-%%off) >= 1
>>  %if %2 >= 4
>> -movd mm %+ %%mmx_idx, [srcq+%2-4]
>> +movd xmm %+ %%xmm_idx, [srcq+%2-4]
>>  %elif (%2-%%off) == 1
>>  movvalb, [srcq+%2-1]
>>  %elif (%2-%%off) == 2
>> @@ -185,48 +174,40 @@ hvar_fn
>>  
>>  %macro WRITE_NUM_BYTES 2
>>  %assign %%off 0 ; offset in destination buffer
>> -%assign %%mmx_idx 0 ; mmx register index
>>  %assign %%xmm_idx 0 ; xmm register index
>>  
>>  %rep %2/mmsize
>> -%if mmsize == 16
>>  movu   [dstq+%%off], xmm %+ %%xmm_idx
>>  %assign %%xmm_idx %%xmm_idx+1
>> -%else ; mmx
>> -movu   [dstq+%%off], mm %+ %%mmx_idx
>> -%assign %%mmx_idx %%mmx_idx+1
>> -%endif
>>  %assign %%off %%off+mmsize
>>  %endrep ; %2/mmsize
>>  
>> -%if mmsize == 16
>>  %if (%2-%%off) >= 8
>>  %if %2 > 16 && (%2-%%off) > 8
>>  movu   [dstq+%2-16], xmm %+ %%xmm_idx
>>  %assign %%xmm_idx %%xmm_idx+1
>>  %assign %%off %2
>>  %else
>> -movq   [dstq+%%off], mm %+ %%mmx_idx
>> -%assign %%mmx_idx %%mmx_idx+1
>> +movq   [dstq+%%off], xmm %+ %%xmm_idx
>> +%assign %%xmm_idx %%xmm_idx+1
>>  %assign %%off %%off+8
>>  %endif
>>  %endif ; (%2-%%off) >= 8
>> -%endif
>>  
>>  %if (%2-%%off) >= 4
>>  %if %2 > 8 && (%2-%%off) > 4
>> -movq[dstq+%2-8], mm %+ %%mmx_idx
>> +movq[dstq+%2-8], xmm %+ %%xmm_idx
>>  %assign %%off %2
>>  %else
>> -movd   [dstq+%%off], mm %+ %%mmx_idx
>> +movd   [dstq+%%off], xmm %+ %%xmm_idx
>>  %assign %%off %%off+4
>>  %endif
>> -%assign %%mmx_idx %%mmx_idx+1
>> +%assign %%xmm_idx %%xmm_idx+1
>>  %endif ; (%2-%%off) >= 4
>>  
>>  %if (%2-%%off) >= 1
>>  %if %2 >= 4
>> -movd[dstq+%2-4], mm %+ %%mmx_idx
>> +movd[dstq+%2-4], xmm %+ %%xmm_idx
>>  %elif (%2-%%off) == 1
>>  mov [dstq+%2-1], valb
>>  %elif (%2-%%off) == 2
>> @@ -318,11 +299,8 @@ cglobal emu_edge_vfix %+ %%n, 1, 5, 1, dst, src, 
>> start_y, end_y, bh
>>  %endrep ; 1+%2-%1
>>  %endmacro ; VERTICAL_EXTEND
>>  
>> -INIT_MMX mmx
>> -VERTICAL_EXTEND 1, 15
>> -
>> -INIT_XMM sse
>> -VERTICAL_EXTEND 16, 22
>> +INIT_XMM sse2
>> +VERTICAL_EXTEND 1, 22
>>  
>>  ; left/right (horizontal) fast extend functions
>>  ; these are essentially identical to the v

[FFmpeg-devel] [PATCH v2] lavc/x86/videodsp: Drop MMX usage

[Frank Plowman]

Remove the MMX versions of these functions and modify the SSE
implementations to avoid using MMX registers.

Signed-off-by: Frank Plowman 
---
 libavcodec/x86/videodsp.asm| 61 ++-
 libavcodec/x86/videodsp_init.c | 88 +-
 2 files changed, 59 insertions(+), 90 deletions(-)

diff --git a/libavcodec/x86/videodsp.asm b/libavcodec/x86/videodsp.asm
index 3cc07878d3..81ae2ec10c 100644
--- a/libavcodec/x86/videodsp.asm
+++ b/libavcodec/x86/videodsp.asm
@@ -123,54 +123,43 @@ hvar_fn
 ; - if (%2 & 8)  fills 8 bytes into xmm$next
 ; - if (%2 & 4)  fills 4 bytes into xmm$next
 ; - if (%2 & 3)  fills 1, 2 or 4 bytes in eax
-; on mmx, - fills mm0-7 for consecutive sets of 8 pixels
-; - if (%2 & 4)  fills 4 bytes into mm$next
-; - if (%2 & 3)  fills 1, 2 or 4 bytes in eax
 ; writing data out is in the same way
 %macro READ_NUM_BYTES 2
 %assign %%off 0 ; offset in source buffer
-%assign %%mmx_idx 0 ; mmx register index
 %assign %%xmm_idx 0 ; xmm register index
 
 %rep %2/mmsize
-%if mmsize == 16
 movu   xmm %+ %%xmm_idx, [srcq+%%off]
 %assign %%xmm_idx %%xmm_idx+1
-%else ; mmx
-movumm %+ %%mmx_idx, [srcq+%%off]
-%assign %%mmx_idx %%mmx_idx+1
-%endif
 %assign %%off %%off+mmsize
 %endrep ; %2/mmsize
 
-%if mmsize == 16
 %if (%2-%%off) >= 8
 %if %2 > 16 && (%2-%%off) > 8
 movu   xmm %+ %%xmm_idx, [srcq+%2-16]
 %assign %%xmm_idx %%xmm_idx+1
 %assign %%off %2
 %else
-movqmm %+ %%mmx_idx, [srcq+%%off]
-%assign %%mmx_idx %%mmx_idx+1
+movq   xmm %+ %%xmm_idx, [srcq+%%off]
+%assign %%xmm_idx %%xmm_idx+1
 %assign %%off %%off+8
 %endif
 %endif ; (%2-%%off) >= 8
-%endif
 
 %if (%2-%%off) >= 4
 %if %2 > 8 && (%2-%%off) > 4
-movqmm %+ %%mmx_idx, [srcq+%2-8]
+movq   xmm %+ %%xmm_idx, [srcq+%2-8]
 %assign %%off %2
 %else
-movdmm %+ %%mmx_idx, [srcq+%%off]
+movd   xmm %+ %%xmm_idx, [srcq+%%off]
 %assign %%off %%off+4
 %endif
-%assign %%mmx_idx %%mmx_idx+1
+%assign %%xmm_idx %%xmm_idx+1
 %endif ; (%2-%%off) >= 4
 
 %if (%2-%%off) >= 1
 %if %2 >= 4
-movd mm %+ %%mmx_idx, [srcq+%2-4]
+movd xmm %+ %%xmm_idx, [srcq+%2-4]
 %elif (%2-%%off) == 1
 movvalb, [srcq+%2-1]
 %elif (%2-%%off) == 2
@@ -185,48 +174,40 @@ hvar_fn
 
 %macro WRITE_NUM_BYTES 2
 %assign %%off 0 ; offset in destination buffer
-%assign %%mmx_idx 0 ; mmx register index
 %assign %%xmm_idx 0 ; xmm register index
 
 %rep %2/mmsize
-%if mmsize == 16
 movu   [dstq+%%off], xmm %+ %%xmm_idx
 %assign %%xmm_idx %%xmm_idx+1
-%else ; mmx
-movu   [dstq+%%off], mm %+ %%mmx_idx
-%assign %%mmx_idx %%mmx_idx+1
-%endif
 %assign %%off %%off+mmsize
 %endrep ; %2/mmsize
 
-%if mmsize == 16
 %if (%2-%%off) >= 8
 %if %2 > 16 && (%2-%%off) > 8
 movu   [dstq+%2-16], xmm %+ %%xmm_idx
 %assign %%xmm_idx %%xmm_idx+1
 %assign %%off %2
 %else
-movq   [dstq+%%off], mm %+ %%mmx_idx
-%assign %%mmx_idx %%mmx_idx+1
+movq   [dstq+%%off], xmm %+ %%xmm_idx
+%assign %%xmm_idx %%xmm_idx+1
 %assign %%off %%off+8
 %endif
 %endif ; (%2-%%off) >= 8
-%endif
 
 %if (%2-%%off) >= 4
 %if %2 > 8 && (%2-%%off) > 4
-movq[dstq+%2-8], mm %+ %%mmx_idx
+movq[dstq+%2-8], xmm %+ %%xmm_idx
 %assign %%off %2
 %else
-movd   [dstq+%%off], mm %+ %%mmx_idx
+movd   [dstq+%%off], xmm %+ %%xmm_idx
 %assign %%off %%off+4
 %endif
-%assign %%mmx_idx %%mmx_idx+1
+%assign %%xmm_idx %%xmm_idx+1
 %endif ; (%2-%%off) >= 4
 
 %if (%2-%%off) >= 1
 %if %2 >= 4
-movd[dstq+%2-4], mm %+ %%mmx_idx
+movd[dstq+%2-4], xmm %+ %%xmm_idx
 %elif (%2-%%off) == 1
 mov [dstq+%2-1], valb
 %elif (%2-%%off) == 2
@@ -318,11 +299,8 @@ cglobal emu_edge_vfix %+ %%n, 1, 5, 1, dst, src, start_y, 
end_y, bh
 %endrep ; 1+%2-%1
 %endmacro ; VERTICAL_EXTEND
 
-INIT_MMX mmx
-VERTICAL_EXTEND 1, 15
-
-INIT_XMM sse
-VERTICAL_EXTEND 16, 22
+INIT_XMM sse2
+VERTICAL_EXTEND 1, 22
 
 ; left/right (horizontal) fast extend functions
 ; these are essentially identical to the vertical extend ones above,
@@ -337,11 +315,7 @@ VERTICAL_EXTEND 16, 22
 imul   vald, 0x01010101
 %if %1 >= 8
 movd m0, vald
-%if mmsize == 16
 pshufd   m0, m0, q
-%else
-punpckldqm0, m0
-%endif ; mmsize == 16
 %endif ; %1 > 16
 %endif ; avx2
 %endmacro ; READ_V_PIXEL
@@ -356,7 +330,6 @@ VERTICAL_EXTEND 16, 22
 %assign %%off %%off+mmsize
 %endrep ; %1/mmsize
 
-%if mmsize == 16
 %if %1-%%off >= 8
 %if %1 > 16 && %1-%%off > 8
 movu [%2+%1-16], m0
@@ -366,7 +339,6 @@ VERTICAL_EXTEND 16, 22
 %assign %%off %%off+8
 %endif
 %endif ; %1-%%off >= 8
-%endif ; mmsize == 16
 
 %if %1-%%off >= 4
 %if %1 > 8 && %1-%%off > 4
@@ -415,11 +387,8 @@ cglobal emu_edge_hfix %+ %%n, 4, 5, 1, dst, dst_stride, 
start_x, bh, val
 %endrep ; 1+(%2-%1)/2
 %endmacro ; H_EXTEND
 
-INIT_MMX mmx
-H_EXTEND 2, 14
-
 INIT_XMM sse2
-H_EXTEND 16, 22
+H_EXTEND 2, 22
 
 %if HAVE_AVX2_EXTERNAL
 INIT_XMM avx2
diff --git a/libavcodec/x86/videodsp_init.c b/l

Re: [FFmpeg-devel] Patch for libx265 memory leak

[Tom Vaughan]

Any further details you or others could provide to help the x265 dev team 
resolve the issue would be appreciated.

Can you share your steps to reproduce this issue? What parameters were changed? 
Max CTU size?

Is this documentation inadequate? 
https://x265.readthedocs.io/en/master/api.html#build-considerations

On 11/11/24, 10:46 PM, "ffmpeg-devel on behalf of Damiano Galassi" 
mailto:ffmpeg-devel-boun...@ffmpeg.org> on 
behalf of dam...@gmail.com > wrote:


On Tue, Nov 12, 2024 at 3:38 AM Zhao Zhili mailto:quinkbl...@foxmail.com>> wrote:


>
> cleanup() release library static allocations, and I don’t see lock or
> reference count
> within x265_cleanup(). So call cleanup() will break other x265 encoder
> instance,
> right?




x265 already crashes when trying to run two encodes with different settings
in
the same process, because it's storing some instance specific data in
global variables
that are overwritten when starting a new encode.


So at least with this patch it won't leaks the global data,
but the root issue needs to be fixed in x265.
___
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] root access voting

[Michael Niedermayer]

On Sat, Nov 16, 2024 at 03:16:16AM +0100, Anton Khirnov wrote:
[...]
> > > Furthermore you object to this being discussed, deny the issue even
> > > exists, and in at least one case you wanted to ban someone for raising
> > > it. Those are all tactics authoritarian governments use to suppress
> > > opposition.
> > >
> > > > What we need is a open dialoge, a calm discussion about what the 
> > > > underlaying
> > > > issues are (if there are any). And to work towards correcting them.
> > >
> > > How can we have a discussion that includes you when you refuse to
> > > acknowledge there is something to discuss?
> > 
> > I fail to understand these last two paragraphs or what they refer to
> 
> This has been a recurring pattern over several years now:
> * there is a dev meeting
> * some people raise the point that our infrastructure situation is
>   highly opaque
> * you reply to it saying that everything is perfectly clear

id like to add some points here, from my perspective

* People accuse and attack me
* Iam trying to help and fix the issues, but i only partly understand
  what is missing
* Some improvments happen to infra documentation
* I think, problem solved
* Other people stay silent

What is outstanding now is, that we will add more details about the
server hosting, security there and i also asked for a picture. This
should happen next week

And as you now made me realize that the git/MAINTAINER relation
does not seem as documented at the correct place. Ill document that
and post a patch (that should happen within the next 24h)

Thx

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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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] lavu/get_video_buffer: also align data pointers (v2)

[Pavel Koshevoy]

On Sat, Nov 16, 2024 at 9:25 AM Pavel Koshevoy  wrote:

>
>
> On Sat, Nov 16, 2024 at 9:00 AM James Almer  wrote:
>
>> On 11/16/2024 12:57 PM, Pavel Koshevoy wrote:
>> > On Fri, Nov 15, 2024 at 9:25 PM Anton Khirnov 
>> wrote:
>> >
>> >> Quoting Pavel Koshevoy (2024-11-15 20:32:21)
>> >>> This avoids unpleasant surprises to av_frame_get_buffer callers
>> >>> that explicitly specified 64-byte alignment and didn't get
>> >>> AVFrame.data pointers that are 64-byte aligned.
>> >>>
>> >>> For example, see https://github.com/sekrit-twc/zimg/issues/212
>> >>>
>> >>> Although the zscale issue has already been resolved by other means
>> >>> it would still be prudent to improve the behavior of
>> av_frame_get_buffer
>> >>> to fix any unknown and future instances of similar issues.
>> >>> ---
>> >>>   libavutil/frame.c | 4 +++-
>> >>>   libavutil/frame.h | 7 ---
>> >>>   2 files changed, 7 insertions(+), 4 deletions(-)
>> >>
>> >> I think this warrants a micro bump and an APIchanges entry, so external
>> >> callers can reliably depend on this.
>> >>
>> >> Otherwise looks good.
>> >>
>> >> --
>> >> Anton Khirnov
>> >>
>> >
>> >
>> > Thank you, I've submitted a v3 of the patch with doc/APIchanges entry
>> added
>> > and LIBAVUTIL_VERSION_MICRO bumped to 101.
>> >
>> > BTW, I did not make any changes to get_audio_buffer which also accepts
>> > an explicit alignment parameter.  I think it probably needs the same
>> > changes.
>>
>> I'll amend the patch to include that change and push it.
>>
>
> Thank you.
>
>
>>
>> What's the reason you add align - 1 bytes to the total size instead of
>> simply align, for that matter?
>>
>>
> align - 1 is the most a pointer can be misaligned by,
> so that's the most padding we need to correct it.
>


... but I haven't considered that align can be 0, so that may be a problem.

Pavel.
___
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] [PATCH 3/3] avutil/frame: also align data pointers in av_frame_get_buffer()

[James Almer]

From: Pavel Koshevoy 

This avoids unpleasant surprises to av_frame_get_buffer callers
that explicitly specified 64-byte alignment and didn't get
AVFrame.data pointers that are 64-byte aligned.

For example, see https://github.com/sekrit-twc/zimg/issues/212

Although the zscale issue has already been resolved by other means
it would still be prudent to improve the behavior of av_frame_get_buffer
to fix any unknown and future instances of similar issues.

Co-authored-by: James Almer 
Signed-off-by: James Almer 
---
 doc/APIchanges  |  4 
 libavutil/frame.c   | 21 -
 libavutil/frame.h   |  7 ---
 libavutil/version.h |  2 +-
 4 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 15606cafac..d477904856 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,10 @@ The last version increases of all libraries were on 2024-03-07
 
 API changes, most recent first:
 
+2024-11-16 - xx - lavu 59.47.101 - frame.h
+  av_frame_get_buffer() now also aligns the data pointers according to
+  the requested alignment.
+
 2024-11-13 - xx - lavu 59.47.100 - channel_layout.h
   Add AV_CHAN_BINAURAL_LEFT, AV_CHAN_BINAURAL_RIGHT
   Add AV_CH_BINAURAL_LEFT, AV_CH_BINAURAL_RIGHT
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 093853b173..5fb47dbaa6 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -210,7 +210,7 @@ static int get_video_buffer(AVFrame *frame, int align)
  padded_height, linesizes)) < 0)
 return ret;
 
-total_size = 4*plane_padding;
+total_size = 4 * plane_padding + 4 * align;
 for (int i = 0; i < 4; i++) {
 if (sizes[i] > SIZE_MAX - total_size)
 return AVERROR(EINVAL);
@@ -230,6 +230,7 @@ static int get_video_buffer(AVFrame *frame, int align)
 for (int i = 1; i < 4; i++) {
 if (frame->data[i])
 frame->data[i] += i * plane_padding;
+frame->data[i] = (uint8_t *)FFALIGN((uintptr_t)frame->data[i], align);
 }
 
 frame->extended_data = frame->data;
@@ -244,6 +245,7 @@ static int get_audio_buffer(AVFrame *frame, int align)
 {
 int planar   = av_sample_fmt_is_planar(frame->format);
 int channels, planes;
+size_t size;
 int ret;
 
 channels = frame->ch_layout.nb_channels;
@@ -256,6 +258,9 @@ static int get_audio_buffer(AVFrame *frame, int align)
 return ret;
 }
 
+if (align <= 0)
+align = ALIGN;
+
 if (planes > AV_NUM_DATA_POINTERS) {
 frame->extended_data = av_calloc(planes,
   sizeof(*frame->extended_data));
@@ -270,21 +275,27 @@ static int get_audio_buffer(AVFrame *frame, int align)
 } else
 frame->extended_data = frame->data;
 
+if (frame->linesize[0] > SIZE_MAX - align)
+return AVERROR(EINVAL);
+size = frame->linesize[0] + (size_t)align;
+
 for (int i = 0; i < FFMIN(planes, AV_NUM_DATA_POINTERS); i++) {
-frame->buf[i] = av_buffer_alloc(frame->linesize[0]);
+frame->buf[i] = av_buffer_alloc(size);
 if (!frame->buf[i]) {
 av_frame_unref(frame);
 return AVERROR(ENOMEM);
 }
-frame->extended_data[i] = frame->data[i] = frame->buf[i]->data;
+frame->extended_data[i] = frame->data[i] =
+(uint8_t *)FFALIGN((uintptr_t)frame->buf[i]->data, align);
 }
 for (int i = 0; i < planes - AV_NUM_DATA_POINTERS; i++) {
-frame->extended_buf[i] = av_buffer_alloc(frame->linesize[0]);
+frame->extended_buf[i] = av_buffer_alloc(size);
 if (!frame->extended_buf[i]) {
 av_frame_unref(frame);
 return AVERROR(ENOMEM);
 }
-frame->extended_data[i + AV_NUM_DATA_POINTERS] = 
frame->extended_buf[i]->data;
+frame->extended_data[i + AV_NUM_DATA_POINTERS] =
+(uint8_t *)FFALIGN((uintptr_t)frame->extended_buf[i]->data, align);
 }
 return 0;
 
diff --git a/libavutil/frame.h b/libavutil/frame.h
index f7806566d5..c107f43bc0 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -887,9 +887,10 @@ void av_frame_move_ref(AVFrame *dst, AVFrame *src);
  *   cases.
  *
  * @param frame frame in which to store the new buffers.
- * @param align Required buffer size alignment. If equal to 0, alignment will 
be
- *  chosen automatically for the current CPU. It is highly
- *  recommended to pass 0 here unless you know what you are doing.
+ * @param align Required buffer size and data pointer alignment. If equal to 0,
+ *  alignment will be chosen automatically for the current CPU.
+ *  It is highly recommended to pass 0 here unless you know what
+ *  you are doing.
  *
  * @return 0 on success, a negative AVERROR on error.
  */
diff --git a/libavutil/version.h b/libavutil/version.h
index c1878a49ad..6a4abcf7f5 100644
--- a/libavutil/version.h
+++ b/libavutil/version.

[FFmpeg-devel] [PATCH 2/3] avutil/frame: fix setting plane_padding

[James Almer]

STRIDE_ALIGN is a lavc define and is not necessarely 32. And align may be <= 0 
at the
point plane_padding is being set.

Signed-off-by: James Almer 
---
 libavutil/frame.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index f42f310023..093853b173 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -174,7 +174,7 @@ static int get_video_buffer(AVFrame *frame, int align)
 {
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
 int ret, padded_height;
-int plane_padding = FFMAX(16 + 16/*STRIDE_ALIGN*/, align);
+int plane_padding;
 ptrdiff_t linesizes[4];
 size_t total_size, sizes[4];
 
@@ -184,10 +184,11 @@ static int get_video_buffer(AVFrame *frame, int align)
 if ((ret = av_image_check_size(frame->width, frame->height, 0, NULL)) < 0)
 return ret;
 
-if (!frame->linesize[0]) {
-if (align <= 0)
-align = ALIGN;
+if (align <= 0)
+align = ALIGN;
+plane_padding = FFMAX(ALIGN, align);
 
+if (!frame->linesize[0]) {
 for (int i = 1; i <= align; i += i) {
 ret = av_image_fill_linesizes(frame->linesize, frame->format,
   FFALIGN(frame->width, i));
-- 
2.47.0

___
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] [PATCH 1/3] avutil/frame: use size_t for total_size in get_video_buffer()

[James Almer]

Signed-off-by: James Almer 
---
 libavutil/frame.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index f0a0dba018..f42f310023 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -173,10 +173,10 @@ void av_frame_free(AVFrame **frame)
 static int get_video_buffer(AVFrame *frame, int align)
 {
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
-int ret, padded_height, total_size;
+int ret, padded_height;
 int plane_padding = FFMAX(16 + 16/*STRIDE_ALIGN*/, align);
 ptrdiff_t linesizes[4];
-size_t sizes[4];
+size_t total_size, sizes[4];
 
 if (!desc)
 return AVERROR(EINVAL);
@@ -211,7 +211,7 @@ static int get_video_buffer(AVFrame *frame, int align)
 
 total_size = 4*plane_padding;
 for (int i = 0; i < 4; i++) {
-if (sizes[i] > INT_MAX - total_size)
+if (sizes[i] > SIZE_MAX - total_size)
 return AVERROR(EINVAL);
 total_size += sizes[i];
 }
-- 
2.47.0

___
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] lavu/get_video_buffer: also align data pointers (v2)

[Pavel Koshevoy]

On Sat, Nov 16, 2024 at 9:00 AM James Almer  wrote:

> On 11/16/2024 12:57 PM, Pavel Koshevoy wrote:
> > On Fri, Nov 15, 2024 at 9:25 PM Anton Khirnov  wrote:
> >
> >> Quoting Pavel Koshevoy (2024-11-15 20:32:21)
> >>> This avoids unpleasant surprises to av_frame_get_buffer callers
> >>> that explicitly specified 64-byte alignment and didn't get
> >>> AVFrame.data pointers that are 64-byte aligned.
> >>>
> >>> For example, see https://github.com/sekrit-twc/zimg/issues/212
> >>>
> >>> Although the zscale issue has already been resolved by other means
> >>> it would still be prudent to improve the behavior of
> av_frame_get_buffer
> >>> to fix any unknown and future instances of similar issues.
> >>> ---
> >>>   libavutil/frame.c | 4 +++-
> >>>   libavutil/frame.h | 7 ---
> >>>   2 files changed, 7 insertions(+), 4 deletions(-)
> >>
> >> I think this warrants a micro bump and an APIchanges entry, so external
> >> callers can reliably depend on this.
> >>
> >> Otherwise looks good.
> >>
> >> --
> >> Anton Khirnov
> >>
> >
> >
> > Thank you, I've submitted a v3 of the patch with doc/APIchanges entry
> added
> > and LIBAVUTIL_VERSION_MICRO bumped to 101.
> >
> > BTW, I did not make any changes to get_audio_buffer which also accepts
> > an explicit alignment parameter.  I think it probably needs the same
> > changes.
>
> I'll amend the patch to include that change and push it.
>

Thank you.


>
> What's the reason you add align - 1 bytes to the total size instead of
> simply align, for that matter?
>
>
align - 1 is the most a pointer can be misaligned by,
so that's the most padding we need to correct it.

Thank you,
Pavel.
___
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] [PATCHv2 1/4] avcodec/mm: set audio pts proportionally to audio offset

[Peter Ross]

On Thu, Jun 27, 2024 at 08:08:14AM +1000, Peter Ross wrote:
> ---
>  libavformat/mm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/mm.c b/libavformat/mm.c
> index 23c025d852..a40b5c44bb 100644
> --- a/libavformat/mm.c
> +++ b/libavformat/mm.c
> @@ -180,7 +180,8 @@ static int read_packet(AVFormatContext *s,
>  if ((ret = av_get_packet(s->pb, pkt, length)) < 0)
>  return ret;
>  pkt->stream_index = 1;
> -pkt->pts = mm->audio_pts++;
> +pkt->pts = mm->audio_pts;
> +mm->audio_pts += length;
>  return 0;
>  
>  default :
> -- 
> 2.43.0

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-June/330307.html

will apply this patch set soon.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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 1/3] lavc/vvc_mc: R-V V put_pixels

[Rémi Denis-Courmont]

Le sunnuntaina 10. marraskuuta 2024, 13.34.31 EET u...@foxmail.com a écrit :
> From: sunyuechi 
> 
>   k230  
> banana_f3 put_chroma_pixels_8_4x4_c:  63.5 (
> 1.00x)59.2 ( 1.00x) put_chroma_pixels_8_4x4_rvv_i32:   
> 26.5 ( 2.39x)28.0 ( 2.12x) put_chroma_pixels_8_8x8_c:  
>   211.8 ( 1.00x)215.5 ( 1.00x)
> put_chroma_pixels_8_8x8_rvv_i32:54.3 ( 3.90x)   
> 48.8 ( 4.42x) put_chroma_pixels_8_16x16_c:   841.3
> ( 1.00x)830.0 ( 1.00x) put_chroma_pixels_8_16x16_rvv_i32:  
>   137.5 ( 6.12x)121.8 ( 6.82x) put_chroma_pixels_8_32x32_c:
>  3248.8 ( 1.00x)3288.2 ( 1.00x)
> put_chroma_pixels_8_32x32_rvv_i32: 350.5 ( 9.27x)   
> 288.5 (11.40x) put_chroma_pixels_8_64x64_c: 12998.3
> ( 1.00x)12976.2 ( 1.00x) put_chroma_pixels_8_64x64_rvv_i32:
>1100.5 (11.81x)924.0 (14.04x) put_chroma_pixels_8_128x128_c:
>   54284.0 ( 1.00x)52654.5 ( 1.00x)
> put_chroma_pixels_8_128x128_rvv_i32:  7192.8 ( 7.55x)   
> 2934.2 (17.94x) put_luma_pixels_8_4x4_c:   
> 63.5 ( 1.00x)69.5 ( 1.00x) put_luma_pixels_8_4x4_rvv_i32:  
>26.5 ( 2.39x)28.0 ( 2.48x) put_luma_pixels_8_8x8_c: 
>  211.5 ( 1.00x)225.8 ( 1.00x)
> put_luma_pixels_8_8x8_rvv_i32:  54.3 ( 3.90x)   
> 38.5 ( 5.86x) put_luma_pixels_8_16x16_c: 850.5
> ( 1.00x)830.0 ( 1.00x) put_luma_pixels_8_16x16_rvv_i32:
>   137.5 ( 6.18x)100.8 ( 8.24x) put_luma_pixels_8_32x32_c:  
>  3248.8 ( 1.00x)3257.2 ( 1.00x)
> put_luma_pixels_8_32x32_rvv_i32:   341.3 ( 9.52x)   
> 246.8 (13.20x) put_luma_pixels_8_64x64_c:   13007.5
> ( 1.00x)13038.8 ( 1.00x) put_luma_pixels_8_64x64_rvv_i32:  
>1119.0 (11.62x)684.2 (19.06x) put_luma_pixels_8_128x128_c:  
>   54219.3 ( 1.00x)52060.8 ( 1.00x)
> put_luma_pixels_8_128x128_rvv_i32:6813.5 ( 7.96x)   
> 2548.8 (20.43x) ---
>  libavcodec/riscv/h26x/asm.S| 169 +
>  libavcodec/riscv/h26x/h2656dsp.h   |  27 +
>  libavcodec/riscv/vvc/vvc_mc_rvv.S  | 120 ++--
>  libavcodec/riscv/vvc/vvcdsp_init.c |  23 
>  4 files changed, 227 insertions(+), 112 deletions(-)
>  create mode 100644 libavcodec/riscv/h26x/asm.S
>  create mode 100644 libavcodec/riscv/h26x/h2656dsp.h
> 
> diff --git a/libavcodec/riscv/h26x/asm.S b/libavcodec/riscv/h26x/asm.S
> new file mode 100644
> index 00..d37b459f66
> --- /dev/null
> +++ b/libavcodec/riscv/h26x/asm.S
> @@ -0,0 +1,169 @@
> +/*
> + * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences
> (ISCAS). + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA + */
> +
> +#include "libavutil/riscv/asm.S"
> +
> +.macro vsetvlstatic8 w, vlen
> +.if \w == 2 && \vlen == 128
> +vsetivlizero, \w, e8, mf8, ta, ma
> +.elseif \w <= 4 && \vlen == 128
> +vsetivlizero, \w, e8, mf4, ta, ma
> +.elseif \w <= 8 && \vlen == 128
> +vsetivlizero, \w, e8, mf2, ta, ma
> +.elseif \w <= 16 && \vlen == 128
> +vsetivlizero, \w, e8, m1, ta, ma
> +.elseif \w <= 32 && \vlen == 128
> +li  t0, \w
> +vsetvli zero, t0, e8, m2, ta, ma
> +.elseif \w <= 4 && \vlen == 256
> +vsetivlizero, \w, e8, mf8, ta, ma
> +.elseif \w <= 8 && \vlen == 256
> +vsetivlizero, \w, e8, mf4, ta, ma
> +.elseif \w <= 16 && \vlen == 256
> +vsetivlizero, \w, e8, mf2, ta, ma
> +.elseif \w <= 32 && \vlen == 256
> +li  t0, \w
> +vsetvli zero, t0, e8, m1, ta, ma
> +.elseif \w <= 64 && \vl

Re: [FFmpeg-devel] [PATCH 1/3] lavc/h264dsp: move RISC-V fn pointers to .data.rel.ro

[Martin Storsjö]

On Sat, 16 Nov 2024, Rémi Denis-Courmont wrote:


This should fix PIC builds.
---
libavcodec/riscv/h264dsp_rvv.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/riscv/h264dsp_rvv.S b/libavcodec/riscv/h264dsp_rvv.S
index 079896b17b..05d077f44e 100644
--- a/libavcodec/riscv/h264dsp_rvv.S
+++ b/libavcodec/riscv/h264dsp_rvv.S
@@ -160,7 +160,7 @@ h264_weight 8, 16

.global ff_h264_weight_funcs_8_rvv
.hidden ff_h264_weight_funcs_8_rvv
-const ff_h264_weight_funcs_8_rvv
+const ff_h264_weight_funcs_8_rvv, relocate=1
.irpw, 16, 8, 4, 2
#if __riscv_xlen == 32
.word   ff_h264_weight_pixels\w\()_8_rvv
--
2.45.2


LGTM

// 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 2/2] checkasm: add RISC-V vector width to arch info

[Martin Storsjö]

On Sat, 16 Nov 2024, Rémi Denis-Courmont wrote:


---
tests/checkasm/checkasm.c | 6 ++
1 file changed, 6 insertions(+)

diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index fb307af0ae..f30c53cec2 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -96,6 +96,8 @@

#if ARCH_AARCH64
#include "libavutil/aarch64/cpu.h"
+#elif ARCH_RISCV
+#include "libavutil/riscv/cpu.h"
#endif

#if ARCH_ARM && HAVE_ARMV5TE_EXTERNAL
@@ -993,6 +995,10 @@ int main(int argc, char *argv[])
if (have_sve(av_get_cpu_flags()))
snprintf(arch_info_buf, sizeof(arch_info_buf),
 "SVE %d bits, ", 8 * ff_aarch64_sve_length());
+#elif ARCH_RISCV && HAVE_RVV
+if (av_get_cpu_flags() & AV_CPU_FLAG_RVV_I32)
+snprintf(arch_info_buf, sizeof (arch_info_buf),
+ "%zu-bit vectors, ", 8 * ff_get_rv_vlenb());
#endif
fprintf(stderr, "checkasm: %susing random seed %u\n", arch_info_buf, seed);
av_lfg_init(&checkasm_lfg, seed);
--
2.45.2


These two patches LGTM.

// 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 3/3] lavc/vp8dsp: remove RISC-V table alignment

[Martin Storsjö]

On Sat, 16 Nov 2024, Rémi Denis-Courmont wrote:


These values are bytes and need not be aligned.
---
libavcodec/riscv/vp8dsp_rvv.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index a8b3e239ba..a0548fbf0a 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -365,7 +365,7 @@ func ff_put_vp8_bilin\len\()_hv_rvv, zve32x
endfunc
.endr

-const subpel_filters
+const subpel_filters, align=0
.byte 0,  -6, 123,  12,  -1, 0
.byte 2, -11, 108,  36,  -8, 1
.byte 0,  -9,  93,  50,  -6, 0
--
2.45.2


Patches 2-3 probably ok.

// 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 1/5] compat: add a fallback implementation of C23 stdckdint.h

[Andreas Rheinhardt]

James Almer:
> From: Justine Tunney 
> 
> Header contents taken from 
> https://github.com/jart/jtckdint/commit/62df1fc0966926299253b7af46c23e345545
> 
> Signed-off-by: James Almer 
> ---
>  compat/stdckdint/stdckdint.h | 663 +++
>  tests/ref/fate/source|   1 +
>  2 files changed, 664 insertions(+)
>  create mode 100644 compat/stdckdint/stdckdint.h
> 
> diff --git a/compat/stdckdint/stdckdint.h b/compat/stdckdint/stdckdint.h
> new file mode 100644
> index 00..2d36e8ad89
> --- /dev/null
> +++ b/compat/stdckdint/stdckdint.h
> @@ -0,0 +1,663 @@
> +/*
> + * Copyright 2023 Justine Alexandra Roberts Tunney
> + *
> + * Permission to use, copy, modify, and/or distribute this software for
> + * any purpose with or without fee is hereby granted, provided that the
> + * above copyright notice and this permission notice appear in all copies.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
> + * WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED
> + * WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
> + * AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
> + * DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
> + * PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
> + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
> + * PERFORMANCE OF THIS SOFTWARE.
> + */
> +
> +/**
> + * @fileoverview C23 Checked Arithmetic
> + *
> + * This header defines three type generic functions:
> + *
> + *   - `bool ckd_add(res, a, b)`
> + *   - `bool ckd_sub(res, a, b)`
> + *   - `bool ckd_mul(res, a, b)`
> + *
> + * Which allow integer arithmetic errors to be detected. There are many
> + * kinds of integer errors, e.g. overflow, truncation, etc. These funcs
> + * catch them all. Here's an example of how it works:
> + *
> + * uint32_t c;
> + * int32_t a = 0x7fff;
> + * int32_t b = 2;
> + * assert(!ckd_add(&c, a, b));
> + * assert(c == 0x8001u);
> + *
> + * Experienced C / C++ users should find this example counter-intuitive
> + * because the expression `0x7fff + 2` not only overflows it's also
> + * undefined behavior. However here we see it's specified, and does not
> + * result in an error. That's because C23 checked arithmetic is not the
> + * arithmetic you're used to. The new standard changes the mathematics.
> + *
> + * C23 checked arithmetic is defined as performing the arithmetic using
> + * infinite precision and then checking if the resulting value will fit
> + * in the output type. Our example above did not result in an error due
> + * to `0x8001` being a legal value for `uint32_t`.
> + *
> + * This implementation will use the GNU compiler builtins, when they're
> + * available, only if you don't use build flags like `-std=c11` because
> + * they define `__STRICT_ANSI__` and GCC extensions aren't really ANSI.
> + * Instead, you'll get a pretty good pure C11 and C++11 implementation.

Doesn't this imply that we will no longer get the compiler builtins?
That is very bad.

> + *
> + * @see https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3096.pdf
> + * @version 0.1 (2023-07-22)
> + */
> +
> +#ifndef JTCKDINT_H_
> +#define JTCKDINT_H_
> +
> +#ifdef __has_include
> +#define __ckd_has_include(x) __has_include(x)
> +#else
> +#define __ckd_has_include(x) 0
> +#endif
> +
> +#if __ckd_has_include()
> +#include 
> +#else
> +
> +#define __STDC_VERSION_STDCKDINT_H__ 202311L
> +
> +#if ((defined(__llvm__) ||  \
> +  (defined(__GNUC__) && __GNUC__ * 100 + __GNUC_MINOR__ >= 406)) && \
> + !defined(__STRICT_ANSI__))
> +#define __ckd_have_int128
> +#define __ckd_intmax __int128
> +#elif ((defined(__cplusplus) && __cplusplus >= 201103L) ||  \
> +   (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L))
> +#define __ckd_intmax long long
> +#else
> +#define __ckd_intmax long
> +#endif
> +
> +typedef signed __ckd_intmax __ckd_intmax_t;
> +typedef unsigned __ckd_intmax __ckd_uintmax_t;
> +
> +#ifdef __has_builtin
> +#define __ckd_has_builtin(x) __has_builtin(x)
> +#else
> +#define __ckd_has_builtin(x) 0
> +#endif
> +
> +#if (!defined(__STRICT_ANSI__) &&   \
> + ((defined(__GNUC__) && __GNUC__ >= 5 && !defined(__ICC)) ||\
> +  (__ckd_has_builtin(__builtin_add_overflow) && \
> +   __ckd_has_builtin(__builtin_sub_overflow) && \
> +   __ckd_has_builtin(__builtin_mul_overflow
> +#define ckd_add(res, x, y) __builtin_add_overflow((x), (y), (res))
> +#define ckd_sub(res, x, y) __builtin_sub_overflow((x), (y), (res))
> +#define ckd_mul(res, x, y) __builtin_mul_overflow((x), (y), (res))
> +
> +#elif (defined(__cplusplus) &&  \
> +   (__cplusplus >= 201103L ||   \
> +(defined(_MSC_VER) && __cplusplus >= 199711L && \
> +   

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: Support >8bit rice golomb

[Michael Niedermayer]

On Wed, Oct 16, 2024 at 07:36:30PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/ffv1.h| 2 +-
>  libavcodec/ffv1enc.c | 6 +++---
>  2 files changed, 4 insertions(+), 4 deletions(-)

will apply

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

Observe your enemies, for they first find out your faults. -- Antisthenes


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 2/2] checkasm/aacencdsp: initialize AAC tables

[James Almer]

On 11/16/2024 11:50 AM, Rémi Denis-Courmont wrote:

Le lauantaina 16. marraskuuta 2024, 16.39.29 EET James Almer a écrit :

This a large proportion of values to underflow or overflow out of the int
range. The C version then triggers Undefined Behaviour in that case by
negating INT_MIN, so I don't suppose that that's correct.


So is the C version broken, or this test's randomized values?


The C code ostensibly does not expect those values, but regardless I don't
know if they can be triggered or not.

So I don't know if it's a bug in this patch, a bug in the C code or both.


Well, it can't be in this patch because i'm just initializing the 
encoder tables needed by the tested DSP functions. So if something is 
faulty, is the values generated by randomize_float() in this test.


I'm not sure how to constrain them, that said.



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 2/2] checkasm/aacencdsp: initialize AAC tables

[Rémi Denis-Courmont]

Le lauantaina 16. marraskuuta 2024, 16.39.29 EET James Almer a écrit :
> > This a large proportion of values to underflow or overflow out of the int
> > range. The C version then triggers Undefined Behaviour in that case by
> > negating INT_MIN, so I don't suppose that that's correct.
> 
> So is the C version broken, or this test's randomized values?

The C code ostensibly does not expect those values, but regardless I don't 
know if they can be triggered or not.

So I don't know if it's a bug in this patch, a bug in the C code or both.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/



___
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] [PATCH v7 04/12] swscale: expose SwsContext publicly

[Niklas Haas]

From: Niklas Haas 

Following in the footsteps of the work in the previous commit, it's now
relatively straightforward to expose the options struct publicly as
SwsContext. This is a step towards making this more user friendly, as
well as following API conventions established elsewhere.

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas 
---
 libswscale/swscale.h  |  93 +++--
 libswscale/swscale_internal.h |  45 +
 libswscale/utils.c| 123 +++---
 3 files changed, 144 insertions(+), 117 deletions(-)

diff --git a/libswscale/swscale.h b/libswscale/swscale.h
index 50c705ae06..4baef532b6 100644
--- a/libswscale/swscale.h
+++ b/libswscale/swscale.h
@@ -42,8 +42,6 @@
 #include "version.h"
 #endif
 
-typedef struct SwsContext SwsContext;
-
 /**
  * @defgroup libsws libswscale
  * Color conversion and scaling library.
@@ -65,17 +63,98 @@ const char *swscale_configuration(void);
 const char *swscale_license(void);
 
 /**
- * Get the AVClass for swsContext. It can be used in combination with
+ * Get the AVClass for SwsContext. It can be used in combination with
  * AV_OPT_SEARCH_FAKE_OBJ for examining options.
  *
  * @see av_opt_find().
  */
 const AVClass *sws_get_class(void);
 
-/**
- * Allocate an empty SwsContext. This must be filled and passed to
- * sws_init_context(). For filling see AVOptions, options.c and
- * sws_setColorspaceDetails().
+/**
+ * Flags and quality settings *
+ **/
+
+typedef enum SwsDither {
+SWS_DITHER_NONE = 0, /* disable dithering */
+SWS_DITHER_AUTO, /* auto-select from preset */
+SWS_DITHER_BAYER,/* ordered dither matrix */
+SWS_DITHER_ED,   /* error diffusion */
+SWS_DITHER_A_DITHER, /* arithmetic addition */
+SWS_DITHER_X_DITHER, /* arithmetic xor */
+SWS_DITHER_NB,   /* not part of the ABI */
+} SwsDither;
+
+typedef enum SwsAlphaBlend {
+SWS_ALPHA_BLEND_NONE = 0,
+SWS_ALPHA_BLEND_UNIFORM,
+SWS_ALPHA_BLEND_CHECKERBOARD,
+SWS_ALPHA_BLEND_NB,  /* not part of the ABI */
+} SwsAlphaBlend;
+
+/***
+ * Context creation and management *
+ ***/
+
+/**
+ * Main external API structure. New fields can be added to the end with
+ * minor version bumps. Removal, reordering and changes to existing fields
+ * require a major version bump. sizeof(SwsContext) is not part of the ABI.
+ */
+typedef struct SwsContext {
+const AVClass *av_class;
+
+/**
+ * Private data of the user, can be used to carry app specific stuff.
+ */
+void *opaque;
+
+/**
+ * Bitmask of SWS_*.
+ */
+unsigned flags;
+
+/**
+ * Extra parameters for fine-tuning certain scalers.
+ */
+double scaler_params[2];
+
+/**
+ * How many threads to use for processing, or 0 for automatic selection.
+ */
+int threads;
+
+/**
+ * Dither mode.
+ */
+SwsDither dither;
+
+/**
+ * Alpha blending mode. See `SwsAlphaBlend` for details.
+ */
+SwsAlphaBlend alpha_blend;
+
+/**
+ * Use gamma correct scaling.
+ */
+int gamma_flag;
+
+/**
+ * Frame property overrides.
+ */
+int src_w, src_h;  ///< Width and height of the source frame
+int dst_w, dst_h;  ///< Width and height of the destination frame
+int src_format;///< Source pixel format
+int dst_format;///< Destination pixel format
+int src_range; ///< Source is full range
+int dst_range; ///< Destination is full range
+int src_v_chr_pos; ///< Source vertical chroma position in luma grid / 256
+int src_h_chr_pos; ///< Source horizontal chroma position
+int dst_v_chr_pos; ///< Destination vertical chroma position
+int dst_h_chr_pos; ///< Destination horizontal chroma position
+} SwsContext;
+
+/**
+ * Allocate an empty SwsContext and set its fields to default values.
  */
 SwsContext *sws_alloc_context(void);
 
diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index 643177d14d..5218ab0921 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -73,23 +73,6 @@ static inline SwsInternal *sws_internal(const SwsContext 
*sws)
 return (SwsInternal *) sws;
 }
 
-typedef enum SwsDither {
-SWS_DITHER_NONE = 0,
-SWS_DITHER_AUTO,
-SWS_DITHER_BAYER,
-SWS_DITHER_ED,
-SWS_DITHER_A_DITHER,
-SWS_DITHER_X_DITHER,
-SWS_DITHER_NB,
-} SwsDither;
-
-typedef enum SwsAlphaBlend {
-SWS_ALPHA_BLEND_NONE  = 0,
-SWS_ALPHA_BLEND_UNIFORM,
-SWS_ALPHA_BLEND_CHECKERBOARD,
-SWS_ALPHA_BLEND_NB,
-} SwsAlphaBlend;
-
 typedef struct Range {
 unsigned int start;
 unsigned int len;
@@ -329,32 +312,10 @@ struct SwsFilterDescriptor;
 
 /* This struct should be aligned on at least a 32-byte boundary. */
 struct SwsInternal {
-/* Currently active user-facing options. */
-struct {
-   

[FFmpeg-devel] [PATCH] lavc/h264idct: fix RISC-V group multiplier

[Rémi Denis-Courmont]

After the branch, the expected SEW/LMUL ratio is 1 byte/vector.
So we have to set the same ratio before branching (QEMU does not care,
but real hardware does).
---
 libavcodec/riscv/h264idct_rvv.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/riscv/h264idct_rvv.S b/libavcodec/riscv/h264idct_rvv.S
index fda1f37a3c..5adcfd295e 100644
--- a/libavcodec/riscv/h264idct_rvv.S
+++ b/libavcodec/riscv/h264idct_rvv.S
@@ -644,7 +644,7 @@ func ff_h264_idct4_add\type\()_\depth\()_rvv, zve32x
 sd  a4, 24(sp)
 ld  a0,  0(a0)   # dest[0]
 addia1, a1, 16 * 4   # &block_offset[16]
-vsetivlizero, 4, e8, mf4, ta, ma
+vsetivlizero, 4, e8, m1, ta, ma
 jal .Lidct4_add4_\depth\()_rvv
 
 ld  a4, 24(sp)   # nnzc
@@ -655,7 +655,7 @@ func ff_h264_idct4_add\type\()_\depth\()_rvv, zve32x
 ld  a0,  8(a0)   # dest[1]
 lla t0, ff_h264_scan8 + 32
 .ifc \type, 8_422
-vsetivlizero, 4, e8, mf4, ta, ma
+vsetivlizero, 4, e8, m1, ta, ma
 jal .Lidct4_add4_\depth\()_rvv
 
 ld  a4, 24(sp)   # nnzc
@@ -665,7 +665,7 @@ func ff_h264_idct4_add\type\()_\depth\()_rvv, zve32x
 addia1, t5, (-8 - 4) * 4 # &block_offset[24]
 ld  a0,  0(a0)   # dest[0]
 lla t0, ff_h264_scan8 + 24
-vsetivlizero, 4, e8, mf4, ta, ma
+vsetivlizero, 4, e8, m1, ta, ma
 jal .Lidct4_add4_\depth\()_rvv
 
 ld  a4, 24(sp)   # nnzc
@@ -679,7 +679,7 @@ func ff_h264_idct4_add\type\()_\depth\()_rvv, zve32x
 ld  ra,  8(sp)
 ld  s0,  0(sp)
 addisp, sp, 32
-vsetivlizero, 4, e8, mf4, ta, ma
+vsetivlizero, 4, e8, m1, ta, ma
 j   .Lidct4_add4_\depth\()_rvv
 endfunc
 .endm
-- 
2.45.2

___
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 2/2] checkasm/aacencdsp: initialize AAC tables

[James Almer]

On 11/16/2024 4:50 AM, Rémi Denis-Courmont wrote:

Le perjantaina 15. marraskuuta 2024, 22.41.20 EET James Almer a écrit :

Without this, the tables will be zero and the tests completely useless.

Signed-off-by: James Almer 
---
  tests/checkasm/aacencdsp.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/tests/checkasm/aacencdsp.c b/tests/checkasm/aacencdsp.c
index 5308a2ac03..d53a04c532 100644
--- a/tests/checkasm/aacencdsp.c
+++ b/tests/checkasm/aacencdsp.c
@@ -101,6 +101,7 @@ void checkasm_check_aacencdsp(void)
  {
  AACEncDSPContext s = { 0 };
  ff_aacenc_dsp_init(&s);
+ff_aac_float_common_init();

  test_abs_pow34(&s);
  test_quant_bands(&s);


This a large proportion of values to underflow or overflow out of the int range.
The C version then triggers Undefined Behaviour in that case by negating
INT_MIN, so I don't suppose that that's correct.


So is the C version broken, or this test's randomized values?



Also that breaks RISC-V which does the sign injection in float rather than
integer, so values larger than INT_MAX are clipped to INT_MAX rather than
INT_MIN.




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] lavu/get_video_buffer: also align data pointers (v2)

[Pavel Koshevoy]

On Fri, Nov 15, 2024 at 9:25 PM Anton Khirnov  wrote:

> Quoting Pavel Koshevoy (2024-11-15 20:32:21)
> > This avoids unpleasant surprises to av_frame_get_buffer callers
> > that explicitly specified 64-byte alignment and didn't get
> > AVFrame.data pointers that are 64-byte aligned.
> >
> > For example, see https://github.com/sekrit-twc/zimg/issues/212
> >
> > Although the zscale issue has already been resolved by other means
> > it would still be prudent to improve the behavior of av_frame_get_buffer
> > to fix any unknown and future instances of similar issues.
> > ---
> >  libavutil/frame.c | 4 +++-
> >  libavutil/frame.h | 7 ---
> >  2 files changed, 7 insertions(+), 4 deletions(-)
>
> I think this warrants a micro bump and an APIchanges entry, so external
> callers can reliably depend on this.
>
> Otherwise looks good.
>
> --
> Anton Khirnov
>


Thank you, I've submitted a v3 of the patch with doc/APIchanges entry added
and LIBAVUTIL_VERSION_MICRO bumped to 101.

BTW, I did not make any changes to get_audio_buffer which also accepts
an explicit alignment parameter.  I think it probably needs the same
changes.

Pavel.
___
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] lavu/get_video_buffer: also align data pointers (v2)

[James Almer]

On 11/16/2024 12:57 PM, Pavel Koshevoy wrote:

On Fri, Nov 15, 2024 at 9:25 PM Anton Khirnov  wrote:


Quoting Pavel Koshevoy (2024-11-15 20:32:21)

This avoids unpleasant surprises to av_frame_get_buffer callers
that explicitly specified 64-byte alignment and didn't get
AVFrame.data pointers that are 64-byte aligned.

For example, see https://github.com/sekrit-twc/zimg/issues/212

Although the zscale issue has already been resolved by other means
it would still be prudent to improve the behavior of av_frame_get_buffer
to fix any unknown and future instances of similar issues.
---
  libavutil/frame.c | 4 +++-
  libavutil/frame.h | 7 ---
  2 files changed, 7 insertions(+), 4 deletions(-)


I think this warrants a micro bump and an APIchanges entry, so external
callers can reliably depend on this.

Otherwise looks good.

--
Anton Khirnov




Thank you, I've submitted a v3 of the patch with doc/APIchanges entry added
and LIBAVUTIL_VERSION_MICRO bumped to 101.

BTW, I did not make any changes to get_audio_buffer which also accepts
an explicit alignment parameter.  I think it probably needs the same
changes.


I'll amend the patch to include that change and push it.

What's the reason you add align - 1 bytes to the total size instead of 
simply align, for that matter?




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

[FFmpeg-devel] [PATCH] lavu/get_video_buffer: also align data pointers (v3)

[Pavel Koshevoy]

This avoids unpleasant surprises to av_frame_get_buffer callers
that explicitly specified 64-byte alignment and didn't get
AVFrame.data pointers that are 64-byte aligned.

For example, see https://github.com/sekrit-twc/zimg/issues/212

Although the zscale issue has already been resolved by other means
it would still be prudent to improve the behavior of av_frame_get_buffer
to fix any unknown and future instances of similar issues.
---
 doc/APIchanges  | 4 
 libavutil/frame.c   | 4 +++-
 libavutil/frame.h   | 7 ---
 libavutil/version.h | 2 +-
 4 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 15606cafac..45528fad7d 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,10 @@ The last version increases of all libraries were on 2024-03-07
 
 API changes, most recent first:
 
+2024-11-16 - xx - lavu 59.47.101 - frame.h
+  Make get_video_buffer (called by av_frame_get_buffer) also align the
+  data pointers according to the specified alignment.
+
 2024-11-13 - xx - lavu 59.47.100 - channel_layout.h
   Add AV_CHAN_BINAURAL_LEFT, AV_CHAN_BINAURAL_RIGHT
   Add AV_CH_BINAURAL_LEFT, AV_CH_BINAURAL_RIGHT
diff --git a/libavutil/frame.c b/libavutil/frame.c
index f0a0dba018..7faf7aeae8 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -216,6 +216,7 @@ static int get_video_buffer(AVFrame *frame, int align)
 total_size += sizes[i];
 }
 
+total_size += align - 1;
 frame->buf[0] = av_buffer_alloc(total_size);
 if (!frame->buf[0]) {
 ret = AVERROR(ENOMEM);
@@ -223,7 +224,8 @@ static int get_video_buffer(AVFrame *frame, int align)
 }
 
 if ((ret = av_image_fill_pointers(frame->data, frame->format, 
padded_height,
-  frame->buf[0]->data, frame->linesize)) < 
0)
+  (uint8_t 
*)FFALIGN((uintptr_t)frame->buf[0]->data, align),
+  frame->linesize)) < 0)
 goto fail;
 
 for (int i = 1; i < 4; i++) {
diff --git a/libavutil/frame.h b/libavutil/frame.h
index f7806566d5..c107f43bc0 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -887,9 +887,10 @@ void av_frame_move_ref(AVFrame *dst, AVFrame *src);
  *   cases.
  *
  * @param frame frame in which to store the new buffers.
- * @param align Required buffer size alignment. If equal to 0, alignment will 
be
- *  chosen automatically for the current CPU. It is highly
- *  recommended to pass 0 here unless you know what you are doing.
+ * @param align Required buffer size and data pointer alignment. If equal to 0,
+ *  alignment will be chosen automatically for the current CPU.
+ *  It is highly recommended to pass 0 here unless you know what
+ *  you are doing.
  *
  * @return 0 on success, a negative AVERROR on error.
  */
diff --git a/libavutil/version.h b/libavutil/version.h
index c1878a49ad..6a4abcf7f5 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -80,7 +80,7 @@
 
 #define LIBAVUTIL_VERSION_MAJOR  59
 #define LIBAVUTIL_VERSION_MINOR  47
-#define LIBAVUTIL_VERSION_MICRO 100
+#define LIBAVUTIL_VERSION_MICRO 101
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
LIBAVUTIL_VERSION_MINOR, \
-- 
2.43.0

___
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] [PATCH] sws/range_convert: fix RISC-V chrFromJpeg

[Rémi Denis-Courmont]

---
 libswscale/riscv/range_rvv.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libswscale/riscv/range_rvv.S b/libswscale/riscv/range_rvv.S
index 24005170af..f2c20627c5 100644
--- a/libswscale/riscv/range_rvv.S
+++ b/libswscale/riscv/range_rvv.S
@@ -110,7 +110,7 @@ func ff_range_chr_from_jpeg_16_rvv, zve32x, zba
 vnsra.wi v4, v16, 11
 vse16.v  v0, (a0)
 sh1add   a0, t0, a0
-vse16.v  v0, (a1)
+vse16.v  v4, (a1)
 sh1add   a1, t0, a1
 bnez a2, 1b
 
-- 
2.45.2

___
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 v6 12/12] avfilter/vf_scale: switch to new swscale API

[Niklas Haas]

On Fri, 15 Nov 2024 00:49:06 +0100 Michael Niedermayer  
wrote:
> On Fri, Nov 15, 2024 at 12:11:34AM +0100, Niklas Haas wrote:
> > On Fri, 15 Nov 2024 00:00:10 +0100 Michael Niedermayer 
> >  wrote:
> > > On Tue, Nov 12, 2024 at 10:50:46AM +0100, Niklas Haas wrote:
> > > > From: Niklas Haas 
> > > >
> > > > Most logic from this filter has been co-opted into swscale itself,
> > > > allowing the resulting filter to be substantially simpler as it no
> > > > longer has to worry about context initialization, interlacing, etc.
> > > >
> > > > Sponsored-by: Sovereign Tech Fund
> > > > Signed-off-by: Niklas Haas 
> > > > ---
> > > >  libavfilter/vf_scale.c | 354 +
> > > >  1 file changed, 72 insertions(+), 282 deletions(-)
> > >
> > > ./ffmpeg -i foreman_cif.y4m  -vf scale=out_v_chr_pos=0:out_h_chr_pos=0 -f 
> > > null -
> > >
> > > [fc#-1 @ 0x55eec4ea3300] Error applying option 'out_v_chr_pos' to filter 
> > > 'scale': Option not found
> > > Error opening output file -.
> > > Error opening output files: Option not found
> >
> > I mean, this change is basically intentional. But I suppose I should add
> > backwards compatibility code to at least round it to the nearest similar 
> > value.
>
> yes, it should do something better than just failing with a message that 
> confuses the user
>
> also [fc#-1 @ 0x55b30de5f000] Error applying option 'in_v_chr_pos' to filter 
> 'scale': Option not found
> and others

Decided to keep it in place as a legacy option for now. Removing it seems like
a better fit for a later milestone, alongside other legacy stuff.

>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I know you won't believe me, but the highest form of Human Excellence is
> to question oneself and others. -- Socrates
> ___
> 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".

[FFmpeg-devel] [PATCH v7 09/12] swscale: introduce new, dynamic scaling API

[Niklas Haas]

From: Niklas Haas 

As part of a larger, ongoing effort to modernize and partially rewrite
libswscale, it was decided and generally agreed upon to introduce a new
public API for libswscale. This API is designed to be less stateful, more
explicitly defined, and considerably easier to use than the existing one.

Most of the API work has been already accomplished in the previous commits,
this commit merely introduces the ability to use sws_scale_frame()
dynamically, without prior sws_init_context() calls. Instead, the new API
takes frame properties from the frames themselves, and the implementation is
based on the new SwsGraph API, which we simply reinitialize as needed.

This high-level wrapper also recreates the logic that used to live inside
vf_scale for scaling interlaced frames, enabling it to be reused more easily
by end users.

Finally, this function is designed to simply copy refs directly when nothing
needs to be done, substantially improving throughput of the noop fast path.

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas 
---
 libswscale/graph.c|  23 +++-
 libswscale/swscale.c  | 196 --
 libswscale/swscale.h  |  89 +++
 libswscale/swscale_internal.h |   7 +-
 libswscale/utils.c|   4 +
 libswscale/x86/output.asm |   2 +-
 6 files changed, 291 insertions(+), 30 deletions(-)

diff --git a/libswscale/graph.c b/libswscale/graph.c
index ec1015653e..a680b45280 100644
--- a/libswscale/graph.c
+++ b/libswscale/graph.c
@@ -265,6 +265,21 @@ static void get_chroma_pos(SwsGraph *graph, int 
*h_chr_pos, int *v_chr_pos,
 *v_chr_pos = sub_y ? y_pos : -513;
 }
 
+static void legacy_chr_pos(SwsGraph *graph, int *chr_pos, int override, int 
*warned)
+{
+if (override == -513 || override == *chr_pos)
+return;
+
+if (!*warned) {
+av_log(NULL, AV_LOG_WARNING,
+   "Setting chroma position directly is deprecated, make sure "
+   "the frame is tagged with the correct chroma location.\n");
+*warned = 1;
+}
+
+*chr_pos = override;
+}
+
 static int init_pass(SwsGraph *graph, SwsContext *sws,
  SwsImg input, SwsImg output)
 {
@@ -409,7 +424,7 @@ static int init_passes(SwsGraph *graph)
 const SwsFormat *const src = &graph->src;
 const SwsFormat *const dst = &graph->dst;
 SwsContext *sws;
-int ret;
+int ret, warned = 0;
 
 const SwsImg input  = { .data = { &sws_input_sentinel  }, .fmt = 
src->format };
 const SwsImg output = { .data = { &sws_output_sentinel }, .fmt = 
dst->format };
@@ -447,6 +462,12 @@ static int init_passes(SwsGraph *graph)
 get_chroma_pos(graph, &sws->src_h_chr_pos, &sws->src_v_chr_pos, src);
 get_chroma_pos(graph, &sws->dst_h_chr_pos, &sws->dst_v_chr_pos, dst);
 
+/* Allow overriding chroma position with the legacy API */
+legacy_chr_pos(graph, &sws->src_h_chr_pos, ctx->src_h_chr_pos, &warned);
+legacy_chr_pos(graph, &sws->src_v_chr_pos, ctx->src_v_chr_pos, &warned);
+legacy_chr_pos(graph, &sws->dst_h_chr_pos, ctx->dst_h_chr_pos, &warned);
+legacy_chr_pos(graph, &sws->dst_v_chr_pos, ctx->dst_v_chr_pos, &warned);
+
 ret = sws_init_context(sws, NULL, NULL);
 if (ret < 0)
 return ret;
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 45172dcea4..d3dac44d04 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -1219,21 +1219,205 @@ int sws_receive_slice(SwsContext *sws, unsigned int 
slice_start,
   dst, c->frame_dst->linesize, slice_start, 
slice_height);
 }
 
+static void get_frame_pointers(const AVFrame *frame, uint8_t *data[4],
+   int linesize[4], int field)
+{
+for (int i = 0; i < 4; i++) {
+data[i] = frame->data[i];
+linesize[i] = frame->linesize[i];
+}
+
+if (!(frame->flags & AV_FRAME_FLAG_INTERLACED)) {
+av_assert1(!field);
+return;
+}
+
+if (field == FIELD_BOTTOM) {
+/* Odd rows, offset by one line */
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
+for (int i = 0; i < 4; i++) {
+data[i] += linesize[i];
+if (desc->flags & AV_PIX_FMT_FLAG_PAL)
+break;
+}
+}
+
+/* Take only every second line */
+for (int i = 0; i < 4; i++)
+linesize[i] <<= 1;
+}
+
+/* Subset of av_frame_ref() that only references (video) data buffers */
+static int frame_ref(AVFrame *dst, const AVFrame *src)
+{
+/* ref the buffers */
+for (int i = 0; i < FF_ARRAY_ELEMS(src->buf); i++) {
+if (!src->buf[i])
+continue;
+dst->buf[i] = av_buffer_ref(src->buf[i]);
+if (!dst->buf[i])
+return AVERROR(ENOMEM);
+}
+
+memcpy(dst->data, src->data, sizeof(src->data));
+memcpy(dst->linesize, src->linesize, sizeof(src->linesize));
+return 0;
+}
+
 int sws_scale_frame(SwsContext

[FFmpeg-devel] [PATCH v7 11/12] tests/swscale: add a benchmarking mode

[Niklas Haas]

From: Niklas Haas 

With the ability to set the thread count as well. This benchmark includes
the constant overhead of context initialization.

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas 
---
 libswscale/tests/swscale.c | 93 --
 1 file changed, 68 insertions(+), 25 deletions(-)

diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c
index c11a46024e..f5ad4b3132 100644
--- a/libswscale/tests/swscale.c
+++ b/libswscale/tests/swscale.c
@@ -31,21 +31,22 @@
 #include "libavutil/lfg.h"
 #include "libavutil/sfc64.h"
 #include "libavutil/frame.h"
+#include "libavutil/opt.h"
+#include "libavutil/time.h"
 #include "libavutil/pixfmt.h"
 #include "libavutil/avassert.h"
 #include "libavutil/macros.h"
 
 #include "libswscale/swscale.h"
 
-enum {
-WIDTH  = 96,
-HEIGHT = 96,
-};
-
 struct options {
 enum AVPixelFormat src_fmt;
 enum AVPixelFormat dst_fmt;
 double prob;
+int w, h;
+int threads;
+int iters;
+int bench;
 };
 
 struct mode {
@@ -53,9 +54,6 @@ struct mode {
 SwsDither dither;
 };
 
-const int dst_w[] = { WIDTH,  WIDTH  - WIDTH  / 3, WIDTH  + WIDTH  / 3 };
-const int dst_h[] = { HEIGHT, HEIGHT - HEIGHT / 3, HEIGHT + HEIGHT / 3 };
-
 const struct mode modes[] = {
 { SWS_FAST_BILINEAR },
 { SWS_BILINEAR },
@@ -114,7 +112,8 @@ static void get_mse(int mse[4], const AVFrame *a, const 
AVFrame *b, int comps)
 }
 }
 
-static int scale_legacy(AVFrame *dst, const AVFrame *src, struct mode mode)
+static int scale_legacy(AVFrame *dst, const AVFrame *src, struct mode mode,
+struct options opts)
 {
 SwsContext *sws_legacy;
 int ret;
@@ -131,23 +130,28 @@ static int scale_legacy(AVFrame *dst, const AVFrame *src, 
struct mode mode)
 sws_legacy->dst_format = dst->format;
 sws_legacy->flags  = mode.flags;
 sws_legacy->dither = mode.dither;
+sws_legacy->threads= opts.threads;
+
+if ((ret = sws_init_context(sws_legacy, NULL, NULL)) < 0)
+goto error;
 
-ret = sws_init_context(sws_legacy, NULL, NULL);
-if (!ret)
+for (int i = 0; i < opts.iters; i++)
 ret = sws_scale_frame(sws_legacy, dst, src);
 
+error:
 sws_freeContext(sws_legacy);
 return ret;
 }
 
 /* Runs a series of ref -> src -> dst -> out, and compares out vs ref */
 static int run_test(enum AVPixelFormat src_fmt, enum AVPixelFormat dst_fmt,
-int dst_w, int dst_h, struct mode mode, const AVFrame *ref,
-const int mse_ref[4])
+int dst_w, int dst_h, struct mode mode, struct options 
opts,
+const AVFrame *ref, const int mse_ref[4])
 {
 AVFrame *src = NULL, *dst = NULL, *out = NULL;
 int mse[4], mse_sws[4], ret = -1;
 const int comps = fmt_comps(src_fmt) & fmt_comps(dst_fmt);
+int64_t time, time_ref = 0;
 
 src = av_frame_alloc();
 dst = av_frame_alloc();
@@ -174,12 +178,20 @@ static int run_test(enum AVPixelFormat src_fmt, enum 
AVPixelFormat dst_fmt,
 
 sws[1]->flags  = mode.flags;
 sws[1]->dither = mode.dither;
-if (sws_scale_frame(sws[1], dst, src) < 0) {
-fprintf(stderr, "Failed %s ---> %s\n", 
av_get_pix_fmt_name(src->format),
-av_get_pix_fmt_name(dst->format));
-goto error;
+sws[1]->threads = opts.threads;
+
+time = av_gettime_relative();
+
+for (int i = 0; i < opts.iters; i++) {
+if (sws_scale_frame(sws[1], dst, src) < 0) {
+fprintf(stderr, "Failed %s ---> %s\n", 
av_get_pix_fmt_name(src->format),
+av_get_pix_fmt_name(dst->format));
+goto error;
+}
 }
 
+time = av_gettime_relative() - time;
+
 if (sws_scale_frame(sws[2], out, dst) < 0) {
 fprintf(stderr, "Failed %s ---> %s\n", 
av_get_pix_fmt_name(dst->format),
 av_get_pix_fmt_name(out->format));
@@ -196,11 +208,13 @@ static int run_test(enum AVPixelFormat src_fmt, enum 
AVPixelFormat dst_fmt,
 
 if (!mse_ref) {
 /* Compare against the legacy swscale API as a reference */
-if (scale_legacy(dst, src, mode) < 0) {
+time_ref = av_gettime_relative();
+if (scale_legacy(dst, src, mode, opts) < 0) {
 fprintf(stderr, "Failed ref %s ---> %s\n", 
av_get_pix_fmt_name(src->format),
 av_get_pix_fmt_name(dst->format));
 goto error;
 }
+time_ref = av_gettime_relative() - time_ref;
 
 if (sws_scale_frame(sws[2], out, dst) < 0)
 goto error;
@@ -221,6 +235,15 @@ static int run_test(enum AVPixelFormat src_fmt, enum 
AVPixelFormat dst_fmt,
 }
 }
 
+if (opts.bench && time_ref) {
+printf("  time=%"PRId64" us, ref=%"PRId64" us, speedup=%.3fx %s\n",
+time / opts.iters, time_ref / opts.iters,
+(double) time_ref / time,
+time <= time_ref ? "faster" : "\033[1;33mslower\033[0m");
+} else if (o

[FFmpeg-devel] [PATCH v7 07/12] swscale/internal: expose sws_init_single_context() internally

[Niklas Haas]

From: Niklas Haas 

Used by the graph API swscale wrapper, for now.

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas 
---
 libswscale/swscale_internal.h | 3 +++
 libswscale/utils.c| 4 ++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index 5218ab0921..7c9517975b 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -958,6 +958,9 @@ extern const int32_t ff_yuv2rgb_coeffs[11][4];
 
 extern const AVClass ff_sws_context_class;
 
+int sws_init_single_context(SwsContext *sws, SwsFilter *srcFilter,
+SwsFilter *dstFilter);
+
 /**
  * Set c->convert_unscaled to an unscaled converter if one exists for the
  * specific source and destination formats, bit depths, flags, etc.
diff --git a/libswscale/utils.c b/libswscale/utils.c
index a01138d11b..1b6f54fc30 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1312,8 +1312,8 @@ static enum AVPixelFormat alphaless_fmt(enum 
AVPixelFormat fmt)
 }
 }
 
-static av_cold int sws_init_single_context(SwsContext *sws, SwsFilter 
*srcFilter,
-   SwsFilter *dstFilter)
+av_cold int sws_init_single_context(SwsContext *sws, SwsFilter *srcFilter,
+SwsFilter *dstFilter)
 {
 int i;
 int usesVFilter, usesHFilter;
-- 
2.47.0

___
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] [PATCH v7 00/12] libswscale: new dynamic scaler API

[Niklas Haas]

Changes since v6:
- Rebased on top of current master
- Added backwards compatibility with legacy chroma position API
- Fixed mapping of alphablend and gamma flag options

___
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 v6 12/12] avfilter/vf_scale: switch to new swscale API

[Niklas Haas]

On Thu, 14 Nov 2024 23:47:54 +0100 Michael Niedermayer  
wrote:
> On Tue, Nov 12, 2024 at 10:50:46AM +0100, Niklas Haas wrote:
> > From: Niklas Haas 
> >
> > Most logic from this filter has been co-opted into swscale itself,
> > allowing the resulting filter to be substantially simpler as it no
> > longer has to worry about context initialization, interlacing, etc.
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Niklas Haas 
> > ---
> >  libavfilter/vf_scale.c | 354 +
> >  1 file changed, 72 insertions(+), 282 deletions(-)
>
> breaks:
> ./ffmpeg -i laraShadow_dl.flv  -alphablend checkerboard -qscale 2 -bitexact 
> -t 0.5 -y file-alphablend-yuv420.avi
>
> any video with some transparency should work
> after the patch the video is all black

Fixed; alphablend flag was not correctly passed through.

>
> thx
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> No great genius has ever existed without some touch of madness. -- Aristotle
> ___
> 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".

[FFmpeg-devel] [PATCH v7 05/12] swscale: eliminate redundant SwsInternal accesses

[Niklas Haas]

From: Niklas Haas 

This is a purely cosmetic commit aimed at replacing accesses to
SwsInternal.opts by direct access to SwsContext wherever convenient.

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas 
---
 libswscale/options.c  |   2 +-
 libswscale/swscale.c  |  93 ++--
 libswscale/utils.c| 233 +++---
 tests/checkasm/sw_gbrp.c  |  16 +-
 tests/checkasm/sw_range_convert.c |  16 +-
 tests/checkasm/sw_rgb.c   |  29 ++--
 tests/checkasm/sw_scale.c |  22 +--
 7 files changed, 203 insertions(+), 208 deletions(-)

diff --git a/libswscale/options.c b/libswscale/options.c
index 6248e5f4b5..5eef26de06 100644
--- a/libswscale/options.c
+++ b/libswscale/options.c
@@ -27,7 +27,7 @@ static const char *sws_context_to_name(void *ptr)
 return "swscaler";
 }
 
-#define OFFSET(x) offsetof(SwsInternal, opts.x)
+#define OFFSET(x) offsetof(SwsContext, x)
 #define DEFAULT 0
 #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 5b5a009f1b..45172dcea4 100644
--- a/libswscale/swscale.c
+++ b/libswscale/swscale.c
@@ -895,7 +895,7 @@ static int scale_cascaded(SwsInternal *c,
   uint8_t * const dstSlice[], const int dstStride[],
   int dstSliceY, int dstSliceH)
 {
-const int dstH0 = sws_internal(c->cascaded_context[0])->opts.dst_h;
+const int dstH0 = c->cascaded_context[0]->dst_h;
 int ret = scale_internal(c->cascaded_context[0],
  srcSlice, srcStride, srcSliceY, srcSliceH,
  c->cascaded_tmp[0], c->cascaded_tmpStride[0],
@@ -915,13 +915,13 @@ static int scale_internal(SwsContext *sws,
   int dstSliceY, int dstSliceH)
 {
 SwsInternal *c = sws_internal(sws);
-const int scale_dst = dstSliceY > 0 || dstSliceH < c->opts.dst_h;
+const int scale_dst = dstSliceY > 0 || dstSliceH < sws->dst_h;
 const int frame_start = scale_dst || !c->sliceDir;
 int i, ret;
 const uint8_t *src2[4];
 uint8_t *dst2[4];
-int macro_height_src = isBayer(c->opts.src_format) ? 2 : (1 << 
c->chrSrcVSubSample);
-int macro_height_dst = isBayer(c->opts.dst_format) ? 2 : (1 << 
c->chrDstVSubSample);
+int macro_height_src = isBayer(sws->src_format) ? 2 : (1 << 
c->chrSrcVSubSample);
+int macro_height_dst = isBayer(sws->dst_format) ? 2 : (1 << 
c->chrDstVSubSample);
 // copy strides, so they can safely be modified
 int srcStride2[4];
 int dstStride2[4];
@@ -933,25 +933,25 @@ static int scale_internal(SwsContext *sws,
 }
 
 if ((srcSliceY  & (macro_height_src - 1)) ||
-((srcSliceH & (macro_height_src - 1)) && srcSliceY + srcSliceH != 
c->opts.src_h) ||
-srcSliceY + srcSliceH > c->opts.src_h ||
-(isBayer(c->opts.src_format) && srcSliceH <= 1)) {
+((srcSliceH & (macro_height_src - 1)) && srcSliceY + srcSliceH != 
sws->src_h) ||
+srcSliceY + srcSliceH > sws->src_h ||
+(isBayer(sws->src_format) && srcSliceH <= 1)) {
 av_log(c, AV_LOG_ERROR, "Slice parameters %d, %d are invalid\n", 
srcSliceY, srcSliceH);
 return AVERROR(EINVAL);
 }
 
 if ((dstSliceY  & (macro_height_dst - 1)) ||
-((dstSliceH & (macro_height_dst - 1)) && dstSliceY + dstSliceH != 
c->opts.dst_h) ||
-dstSliceY + dstSliceH > c->opts.dst_h) {
+((dstSliceH & (macro_height_dst - 1)) && dstSliceY + dstSliceH != 
sws->dst_h) ||
+dstSliceY + dstSliceH > sws->dst_h) {
 av_log(c, AV_LOG_ERROR, "Slice parameters %d, %d are invalid\n", 
dstSliceY, dstSliceH);
 return AVERROR(EINVAL);
 }
 
-if (!check_image_pointers(srcSlice, c->opts.src_format, srcStride)) {
+if (!check_image_pointers(srcSlice, sws->src_format, srcStride)) {
 av_log(c, AV_LOG_ERROR, "bad src image pointers\n");
 return AVERROR(EINVAL);
 }
-if (!check_image_pointers((const uint8_t* const*)dstSlice, 
c->opts.dst_format, dstStride)) {
+if (!check_image_pointers((const uint8_t* const*)dstSlice, 
sws->dst_format, dstStride)) {
 av_log(c, AV_LOG_ERROR, "bad dst image pointers\n");
 return AVERROR(EINVAL);
 }
@@ -960,22 +960,19 @@ static int scale_internal(SwsContext *sws,
 if (srcSliceH == 0)
 return 0;
 
-if (c->opts.gamma_flag && c->cascaded_context[0])
+if (sws->gamma_flag && c->cascaded_context[0])
 return scale_gamma(c, srcSlice, srcStride, srcSliceY, srcSliceH,
dstSlice, dstStride, dstSliceY, dstSliceH);
 
-if (c->cascaded_context[0] && srcSliceY == 0 &&
-srcSliceH == sws_internal(c->cascaded_context[0])->opts.src_h)
-{
+if (c->cascaded_context[0] && srcSliceY == 0 && srcSliceH == 
c->cascaded_context[0]->src_h)
 return scale_cascaded(c, srcSlice, srcStride, srcSliceY, srcSliceH,
   ds

[FFmpeg-devel] [PATCH v7 08/12] swscale/graph: add new high-level scaler dispatch mechanism

[Niklas Haas]

From: Niklas Haas 

This interface has been designed from the ground up to serve as a new
framework for dispatching various scaling operations at a high level. This
will eventually replace the old ad-hoc system of using cascaded contexts,
as well as allowing us to plug in more dynamic scaling passes requiring
intermediate steps, such as colorspace conversions, etc.

The starter implementation merely piggybacks off the existing sws_init() and
sws_scale(), functions, though it does bring the immediate improvement of
splitting up cascaded functions and pre/post conversion functions into
separate filter passes, which allows them to e.g. be executed in parallel
even when the main scaler is required to be single threaded. Additionally,
a dedicated (multi-threaded) noop memcpy pass substantially improves
throughput of that fast path.

Follow-up commits will eventually expand this to move all of the scaling
decision logic into the graph init function, and also eliminate some of the
current special cases.

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas 
---
 libswscale/Makefile |   1 +
 libswscale/graph.c  | 602 
 libswscale/graph.h  | 122 +
 3 files changed, 725 insertions(+)
 create mode 100644 libswscale/graph.c
 create mode 100644 libswscale/graph.h

diff --git a/libswscale/Makefile b/libswscale/Makefile
index 757997b401..81f32f4dd7 100644
--- a/libswscale/Makefile
+++ b/libswscale/Makefile
@@ -9,6 +9,7 @@ OBJS = alphablend.o \
hscale.o \
hscale_fast_bilinear.o   \
gamma.o  \
+   graph.o  \
half2float.o \
input.o  \
options.o\
diff --git a/libswscale/graph.c b/libswscale/graph.c
new file mode 100644
index 00..ec1015653e
--- /dev/null
+++ b/libswscale/graph.c
@@ -0,0 +1,602 @@
+/*
+ * Copyright (C) 2024 Niklas Haas
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/error.h"
+#include "libavutil/macros.h"
+#include "libavutil/mem.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/slicethread.h"
+
+#include "libswscale/swscale.h"
+#include "libswscale/utils.h"
+
+#include "swscale_internal.h"
+#include "graph.h"
+
+/* slice_align should be a power of two, or 0 to disable slice threading */
+static SwsPass *pass_add(SwsGraph *graph, void *priv, int w, int h,
+ sws_filter_run_t run, SwsImg in, SwsImg out,
+ int slice_align)
+{
+SwsPass *pass = av_mallocz(sizeof(*pass));
+int ret;
+
+pass->graph  = graph;
+pass->run= run;
+pass->input  = in;
+pass->output = out;
+pass->priv   = priv;
+pass->width  = w;
+pass->height = h;
+
+if (!slice_align) {
+pass->slice_h = pass->height;
+pass->num_slices = 1;
+} else {
+pass->slice_h = (pass->height + graph->num_threads - 1) / 
graph->num_threads;
+pass->slice_h = FFALIGN(pass->slice_h, slice_align);
+pass->num_slices = (pass->height + pass->slice_h - 1) / pass->slice_h;
+}
+
+ret = av_dynarray_add_nofree(&graph->passes, &graph->num_passes, pass);
+if (ret < 0)
+av_freep(&pass);
+return pass;
+}
+
+/* Set output linesize before calling this */
+static int pass_alloc_output(SwsPass *pass)
+{
+const int aligned_h = pass->num_slices * pass->slice_h;
+const int *linesize = pass->output.linesize;
+
+size_t offset[4];
+size_t total_size = 0;
+for (int i = 0; i < 4; i++) {
+const size_t size = FFABS(linesize[i]) * aligned_h;
+offset[i] = total_size;
+total_size = FFALIGN(total_size + size, 16);
+}
+
+av_assert0(!pass->buf);
+pass->buf = av_malloc(total_size);
+if (!pass->buf)
+return AVERROR(ENOMEM);
+
+for (int i = 0; i < 4; i++) {
+uint8_t *base = pass->buf + offset[i];
+if (linesize[i] < 0)
+base -= linesize[i] *

[FFmpeg-devel] [PATCH v7 01/12] swscale/options: cosmetic changes

[Niklas Haas]

From: Niklas Haas 

Reorganize the list, fix whitespace, make indentation consistent, and
rename some descriptions for clarity, consistency or informativeness.

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas 
---
 libswscale/options.c | 86 ++--
 1 file changed, 44 insertions(+), 42 deletions(-)

diff --git a/libswscale/options.c b/libswscale/options.c
index 56b1d2235d..e64e289cf3 100644
--- a/libswscale/options.c
+++ b/libswscale/options.c
@@ -32,55 +32,57 @@ static const char *sws_context_to_name(void *ptr)
 #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 
 static const AVOption swscale_options[] = {
-{ "sws_flags",   "scaler flags",  OFFSET(flags), 
AV_OPT_TYPE_FLAGS,  { .i64  = SWS_BICUBIC}, 0,  UINT_MAX,
VE, .unit = "sws_flags" },
-{ "fast_bilinear",   "fast bilinear", 0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_FAST_BILINEAR  }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "bilinear","bilinear",  0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_BILINEAR   }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "bicubic", "bicubic",   0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_BICUBIC}, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "experimental","experimental",  0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_X  }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "neighbor","nearest neighbor",  0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_POINT  }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "area","averaging area",0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_AREA   }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "bicublin","luma bicubic, chroma bilinear", 0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_BICUBLIN   }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "gauss",   "Gaussian",  0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_GAUSS  }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "sinc","sinc",  0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_SINC   }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "lanczos", "Lanczos",   0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_LANCZOS}, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "spline",  "natural bicubic spline",0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_SPLINE }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "print_info",  "print info",0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_PRINT_INFO }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "accurate_rnd","accurate rounding", 0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_ACCURATE_RND   }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "full_chroma_int", "full chroma interpolation", 0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_FULL_CHR_H_INT }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "full_chroma_inp", "full chroma input", 0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_FULL_CHR_H_INP }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "bitexact","",  0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_BITEXACT   }, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
-{ "error_diffusion", "error diffusion dither",0, 
AV_OPT_TYPE_CONST,  { .i64  = SWS_ERROR_DIFFUSION}, INT_MIN, INT_MAX,
VE, .unit = "sws_flags" },
+{ "sws_flags",   "swscale flags", OFFSET(flags),  
AV_OPT_TYPE_FLAGS, { .i64 = SWS_BICUBIC}, .flags = VE, .unit = 
"sws_flags", .max = UINT_MAX },
+{ "fast_bilinear",   "fast bilinear", 0,  
AV_OPT_TYPE_CONST, { .i64 = SWS_FAST_BILINEAR  }, .flags = VE, .unit = 
"sws_flags" },
+{ "bilinear","bilinear",  0,  
AV_OPT_TYPE_CONST, { .i64 = SWS_BILINEAR   }, .flags = VE, .unit = 
"sws_flags" },
+{ "bicubic", "bicubic",   0,  
AV_OPT_TYPE_CONST, { .i64 = SWS_BICUBIC}, .flags = VE, .unit = 
"sws_flags" },
+{ "experimental","experimental",  0,  
AV_OPT_TYPE_CONST, { .i64 = SWS_X  }, .flags = VE, .unit = 
"sws_flags" },
+{ "neighbor","nearest neighbor",  0,  
AV_OPT_TYPE_CONST, { .i64 = SWS_POINT  }, .flags = VE, .unit = 
"sws_flags" },
+{ "area","averaging area", 

[FFmpeg-devel] [PATCH v7 02/12] swscale/internal: use static_assert for enforcing offsets

[Niklas Haas]

From: Niklas Haas 

Instead of sprinkling av_assert0 into random init functions.

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas 
---
 libswscale/swscale_internal.h | 11 +++
 libswscale/utils.c|  2 --
 libswscale/x86/swscale.c  |  4 
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index 0035168997..0ab4e67270 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -22,6 +22,7 @@
 #define SWSCALE_SWSCALE_INTERNAL_H
 
 #include 
+#include 
 
 #include "config.h"
 #include "swscale.h"
@@ -705,6 +706,16 @@ struct SwsInternal {
 };
 //FIXME check init (where 0)
 
+static_assert(offsetof(SwsInternal, redDither) + DITHER32_INT == 
offsetof(SwsInternal, dither32),
+  "dither32 must be at the same offset as redDither + 
DITHER32_INT");
+
+#if ARCH_X86_64
+/* x86 yuv2gbrp uses the SwsInternal for yuv coefficients
+   if struct offsets change the asm needs to be updated too */
+static_assert(offsetof(SwsInternal, yuv2rgb_y_offset) == 40292,
+  "yuv2rgb_y_offset must be updated in x86 asm");
+#endif
+
 SwsFunc ff_yuv2rgb_get_func_ptr(SwsInternal *c);
 int ff_yuv2rgb_c_init_tables(SwsInternal *c, const int inv_table[4],
  int fullRange, int brightness,
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 5c21f9de4a..f71c63c17f 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1228,8 +1228,6 @@ SwsContext *sws_alloc_context(void)
 {
 SwsInternal *c = av_mallocz(sizeof(SwsInternal));
 
-av_assert0(offsetof(SwsInternal, redDither) + DITHER32_INT == 
offsetof(SwsInternal, dither32));
-
 if (c) {
 c->av_class = &ff_sws_context_class;
 av_opt_set_defaults(c);
diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
index ceafdf4aef..40bfe4a2f6 100644
--- a/libswscale/x86/swscale.c
+++ b/libswscale/x86/swscale.c
@@ -791,10 +791,6 @@ switch(c->dstBpc){ \
 
 if(c->flags & SWS_FULL_CHR_H_INT) {
 
-/* yuv2gbrp uses the SwsInternal for yuv coefficients
-   if struct offsets change the asm needs to be updated too */
-av_assert0(offsetof(SwsInternal, yuv2rgb_y_offset) == 40292);
-
 #define YUV2ANYX_FUNC_CASE(fmt, name, opt)  \
 case fmt:   \
 c->yuv2anyX = ff_yuv2##name##_full_X_##opt; \
-- 
2.47.0

___
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] [PATCH v7 12/12] avfilter/vf_scale: switch to new swscale API

[Niklas Haas]

From: Niklas Haas 

Most logic from this filter has been co-opted into swscale itself,
allowing the resulting filter to be substantially simpler as it no
longer has to worry about context initialization, interlacing, etc.

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas 
---
 libavfilter/vf_scale.c | 351 +
 1 file changed, 77 insertions(+), 274 deletions(-)

diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index a89ebe8c47..5d1eda1a16 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -31,6 +31,7 @@
 #include "filters.h"
 #include "formats.h"
 #include "framesync.h"
+#include "libavutil/pixfmt.h"
 #include "scale_eval.h"
 #include "video.h"
 #include "libavutil/eval.h"
@@ -131,10 +132,7 @@ enum EvalMode {
 
 typedef struct ScaleContext {
 const AVClass *class;
-struct SwsContext *sws; ///< software scaler context
-struct SwsContext *isws[2]; ///< software scaler context for interlaced 
material
-// context used for forwarding options to sws
-struct SwsContext *sws_opts;
+SwsContext *sws;
 FFFrameSync fs;
 
 /**
@@ -149,8 +147,6 @@ typedef struct ScaleContext {
 
 int hsub, vsub; ///< chroma subsampling
 int slice_y;///< top of current output slice
-int input_is_pal;   ///< set to 1 if the input format is paletted
-int output_is_pal;  ///< set to 1 if the output format is paletted
 int interlaced;
 int uses_ref;
 
@@ -334,40 +330,24 @@ revert:
 static av_cold int preinit(AVFilterContext *ctx)
 {
 ScaleContext *scale = ctx->priv;
-int ret;
 
-scale->sws_opts = sws_alloc_context();
-if (!scale->sws_opts)
+scale->sws = sws_alloc_context();
+if (!scale->sws)
 return AVERROR(ENOMEM);
 
 // set threads=0, so we can later check whether the user modified it
-ret = av_opt_set_int(scale->sws_opts, "threads", 0, 0);
-if (ret < 0)
-return ret;
+scale->sws->threads = 0;
 
 ff_framesync_preinit(&scale->fs);
 
 return 0;
 }
 
-static const int sws_colorspaces[] = {
-AVCOL_SPC_UNSPECIFIED,
-AVCOL_SPC_RGB,
-AVCOL_SPC_BT709,
-AVCOL_SPC_BT470BG,
-AVCOL_SPC_SMPTE170M,
-AVCOL_SPC_FCC,
-AVCOL_SPC_SMPTE240M,
-AVCOL_SPC_BT2020_NCL,
--1
-};
-
 static int do_scale(FFFrameSync *fs);
 
 static av_cold int init(AVFilterContext *ctx)
 {
 ScaleContext *scale = ctx->priv;
-int64_t threads;
 int ret;
 
 if (ctx->filter == &ff_vf_scale2ref)
@@ -407,14 +387,13 @@ static av_cold int init(AVFilterContext *ctx)
 if (ret < 0)
 return ret;
 
-if (scale->in_color_matrix != -1 &&
-!ff_fmt_is_in(scale->in_color_matrix, sws_colorspaces)) {
+if (scale->in_color_matrix != -1 && 
!sws_test_colorspace(scale->in_color_matrix, 0)) {
 av_log(ctx, AV_LOG_ERROR, "Unsupported input color matrix '%s'\n",
av_color_space_name(scale->in_color_matrix));
 return AVERROR(EINVAL);
 }
 
-if (!ff_fmt_is_in(scale->out_color_matrix, sws_colorspaces)) {
+if (scale->out_color_matrix != -1 && 
!sws_test_colorspace(scale->out_color_matrix, 1)) {
 av_log(ctx, AV_LOG_ERROR, "Unsupported output color matrix '%s'\n",
av_color_space_name(scale->out_color_matrix));
 return AVERROR(EINVAL);
@@ -424,25 +403,23 @@ static av_cold int init(AVFilterContext *ctx)
scale->w_expr, scale->h_expr, (char 
*)av_x_if_null(scale->flags_str, ""), scale->interlaced);
 
 if (scale->flags_str && *scale->flags_str) {
-ret = av_opt_set(scale->sws_opts, "sws_flags", scale->flags_str, 0);
+ret = av_opt_set(scale->sws, "sws_flags", scale->flags_str, 0);
 if (ret < 0)
 return ret;
 }
 
 for (int i = 0; i < FF_ARRAY_ELEMS(scale->param); i++)
-if (scale->param[i] != DBL_MAX) {
-ret = av_opt_set_double(scale->sws_opts, i ? "param1" : "param0",
-scale->param[i], 0);
-if (ret < 0)
-return ret;
-}
+if (scale->param[i] != DBL_MAX)
+scale->sws->scaler_params[i] = scale->param[i];
+
+scale->sws->src_h_chr_pos = scale->in_h_chr_pos;
+scale->sws->src_v_chr_pos = scale->in_v_chr_pos;
+scale->sws->dst_h_chr_pos = scale->out_h_chr_pos;
+scale->sws->dst_v_chr_pos = scale->out_v_chr_pos;
 
 // use generic thread-count if the user did not set it explicitly
-ret = av_opt_get_int(scale->sws_opts, "threads", 0, &threads);
-if (ret < 0)
-return ret;
-if (!threads)
-av_opt_set_int(scale->sws_opts, "threads", 
ff_filter_get_nb_threads(ctx), 0);
+if (!scale->sws->threads)
+scale->sws->threads = ff_filter_get_nb_threads(ctx);
 
 if (ctx->filter != &ff_vf_scale2ref && scale->uses_ref) {
 AVFilterPad pad = {
@@ -464,11 +441,7 @@ static av_cold void uninit(AVFilterContext *ctx)
 av_expr_free(s

[FFmpeg-devel] [PATCH v7 06/12] swscale: organize and better document flags

[Niklas Haas]

From: Niklas Haas 

Group them into an enum rather than random #defines, and document their
behavior a bit more obviously.

Of particular note, I discovered that SWS_DIRECT_BGR is not referenced
anywhere else in the code base. As such, I have moved it to the deprecated
section, alongside SWS_ERROR_DIFFUSION.

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas 
---
 libswscale/swscale.h | 116 ---
 1 file changed, 66 insertions(+), 50 deletions(-)

diff --git a/libswscale/swscale.h b/libswscale/swscale.h
index 4baef532b6..3996411dc8 100644
--- a/libswscale/swscale.h
+++ b/libswscale/swscale.h
@@ -91,6 +91,71 @@ typedef enum SwsAlphaBlend {
 SWS_ALPHA_BLEND_NB,  /* not part of the ABI */
 } SwsAlphaBlend;
 
+typedef enum SwsFlags {
+/**
+ * Scaler selection options. Only one may be active at a time.
+ */
+SWS_FAST_BILINEAR = 1 <<  0, ///< fast bilinear filtering
+SWS_BILINEAR  = 1 <<  1, ///< bilinear filtering
+SWS_BICUBIC   = 1 <<  2, ///< 2-tap cubic B-spline
+SWS_X = 1 <<  3, ///< experimental
+SWS_POINT = 1 <<  4, ///< nearest neighbor
+SWS_AREA  = 1 <<  5, ///< area averaging
+SWS_BICUBLIN  = 1 <<  6, ///< bicubic luma, bilinear chroma
+SWS_GAUSS = 1 <<  7, ///< gaussian approximation
+SWS_SINC  = 1 <<  8, ///< unwindowed sinc
+SWS_LANCZOS   = 1 <<  9, ///< 3-tap sinc/sinc
+SWS_SPLINE= 1 << 10, ///< cubic Keys spline
+
+/**
+ * Emit verbose log of scaling parameters.
+ */
+SWS_PRINT_INFO= 1 << 12,
+
+/**
+ * Perform full chroma upsampling when upscaling to RGB.
+ *
+ * For example, when converting 50x50 yuv420p to 100x100 rgba, setting 
this flag
+ * will scale the chroma plane from 25x25 to 100x100 (4:4:4), and then 
convert
+ * the 100x100 yuv444p image to rgba in the final output step.
+ *
+ * Without this flag, the chroma plane is instead scaled to 50x100 (4:2:2),
+ * with a single chroma sample being re-used for both of the horizontally
+ * adjacent RGBA output pixels.
+ */
+SWS_FULL_CHR_H_INT = 1 << 13,
+
+/**
+ * Perform full chroma interpolation when downscaling RGB sources.
+ *
+ * For example, when converting a 100x100 rgba source to 50x50 yuv444p, 
setting
+ * this flag will generate a 100x100 (4:4:4) chroma plane, which is then
+ * downscaled to the required 50x50.
+ *
+ * Without this flag, the chroma plane is instead generated at 50x100 
(dropping
+ * every other pixel), before then being downscaled to the required 50x50
+ * resolution.
+ */
+SWS_FULL_CHR_H_INP = 1 << 14,
+
+/**
+ * Force bit-exact output. This will prevent the use of platform-specific
+ * optimizations that may lead to slight difference in rounding, in favor
+ * of always maintaining exact bit output compatibility with the reference
+ * C code.
+ *
+ * Note: It is recommended to set both of these flags simultaneously.
+ */
+SWS_ACCURATE_RND   = 1 << 18,
+SWS_BITEXACT   = 1 << 19,
+
+/**
+ * Deprecated flags.
+ */
+SWS_DIRECT_BGR  = 1 << 15, ///< This flag has no effect
+SWS_ERROR_DIFFUSION = 1 << 23, ///< Set `SwsContext.dither` instead
+} SwsFlags;
+
 /***
  * Context creation and management *
  ***/
@@ -109,7 +174,7 @@ typedef struct SwsContext {
 void *opaque;
 
 /**
- * Bitmask of SWS_*.
+ * Bitmask of SWS_*. See `SwsFlags` for details.
  */
 unsigned flags;
 
@@ -225,60 +290,11 @@ int sws_test_frame(const AVFrame *frame, int output);
  */
 int sws_is_noop(const AVFrame *dst, const AVFrame *src);
 
-/* values for the flags, the stuff on the command line is different */
-#define SWS_FAST_BILINEAR 1
-#define SWS_BILINEAR  2
-#define SWS_BICUBIC   4
-#define SWS_X 8
-#define SWS_POINT  0x10
-#define SWS_AREA   0x20
-#define SWS_BICUBLIN   0x40
-#define SWS_GAUSS  0x80
-#define SWS_SINC  0x100
-#define SWS_LANCZOS   0x200
-#define SWS_SPLINE0x400
-
 #define SWS_SRC_V_CHR_DROP_MASK 0x3
 #define SWS_SRC_V_CHR_DROP_SHIFT16
 
 #define SWS_PARAM_DEFAULT   123456
 
-#define SWS_PRINT_INFO  0x1000
-
-//the following 3 flags are not completely implemented
-
-/**
- * Perform full chroma upsampling when upscaling to RGB.
- *
- * For example, when converting 50x50 yuv420p to 100x100 rgba, setting this 
flag
- * will scale the chroma plane from 25x25 to 100x100 (4:4:4), and then convert
- * the 100x100 yuv444p image to rgba in the final output step.
- *
- * Without this flag, the chroma plane is instead scaled to 50x100 (4:2:2),
- * with a single chroma sample being re-used for both of the horizontally
- * adjacent RGBA output pixels.
- */
-#define SWS_FULL_CHR_H_INT0x2000
-

[FFmpeg-devel] [PATCH v7 10/12] tests/swscale: rewrite on top of new API

[Niklas Haas]

From: Niklas Haas 

This rewrite cleans up the code to use AVFrames and the new swscale API. The
log format has also been simplified and expanded to account for the new
options. (Not yet implemented)

The self testing code path has also been expanded to test the new swscale
implementation against the old one, to serve as an unchanging reference. This
does not accomplish much yet, but serves as a framework for future work.

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Niklas Haas 
---
 libswscale/tests/swscale.c | 665 -
 1 file changed, 284 insertions(+), 381 deletions(-)

diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c
index af8069f728..c11a46024e 100644
--- a/libswscale/tests/swscale.c
+++ b/libswscale/tests/swscale.c
@@ -1,4 +1,5 @@
 /*
+ * Copyright (C) 2024  Nikles Haas
  * Copyright (C) 2003-2011 Michael Niedermayer 
  *
  * This file is part of FFmpeg.
@@ -26,424 +27,307 @@
 
 #undef HAVE_AV_CONFIG_H
 #include "libavutil/cpu.h"
-#include "libavutil/imgutils.h"
-#include "libavutil/mem.h"
-#include "libavutil/avutil.h"
-#include "libavutil/crc.h"
-#include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/lfg.h"
 #include "libavutil/sfc64.h"
+#include "libavutil/frame.h"
+#include "libavutil/pixfmt.h"
+#include "libavutil/avassert.h"
+#include "libavutil/macros.h"
 
 #include "libswscale/swscale.h"
 
-/* HACK Duplicated from swscale_internal.h.
- * Should be removed when a cleaner pixel format system exists. */
-#define isGray(x)  \
-((x) == AV_PIX_FMT_GRAY8   || \
- (x) == AV_PIX_FMT_YA8 || \
- (x) == AV_PIX_FMT_GRAY16BE|| \
- (x) == AV_PIX_FMT_GRAY16LE|| \
- (x) == AV_PIX_FMT_YA16BE  || \
- (x) == AV_PIX_FMT_YA16LE)
-#define hasChroma(x)   \
-(!(isGray(x)|| \
-   (x) == AV_PIX_FMT_MONOBLACK || \
-   (x) == AV_PIX_FMT_MONOWHITE))
-
-static av_always_inline int isALPHA(enum AVPixelFormat pix_fmt)
-{
-const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
-return desc->flags & AV_PIX_FMT_FLAG_ALPHA;
-}
+enum {
+WIDTH  = 96,
+HEIGHT = 96,
+};
 
-static double prob = 1;
-FFSFC64 prng_state;
+struct options {
+enum AVPixelFormat src_fmt;
+enum AVPixelFormat dst_fmt;
+double prob;
+};
 
-static uint64_t getSSD(const uint8_t *src1, const uint8_t *src2,
-   int stride1, int stride2, int w, int h)
-{
-int x, y;
-uint64_t ssd = 0;
+struct mode {
+SwsFlags flags;
+SwsDither dither;
+};
 
-for (y = 0; y < h; y++) {
-for (x = 0; x < w; x++) {
-int d = src1[x + y * stride1] - src2[x + y * stride2];
-ssd += d * d;
-}
-}
-return ssd;
-}
+const int dst_w[] = { WIDTH,  WIDTH  - WIDTH  / 3, WIDTH  + WIDTH  / 3 };
+const int dst_h[] = { HEIGHT, HEIGHT - HEIGHT / 3, HEIGHT + HEIGHT / 3 };
+
+const struct mode modes[] = {
+{ SWS_FAST_BILINEAR },
+{ SWS_BILINEAR },
+{ SWS_BICUBIC },
+{ SWS_X | SWS_BITEXACT },
+{ SWS_POINT },
+{ SWS_AREA | SWS_ACCURATE_RND },
+{ SWS_BICUBIC | SWS_FULL_CHR_H_INT | SWS_FULL_CHR_H_INP },
+{0}, // test defaults
+};
 
-static uint64_t getSSD0(int ref, const uint8_t *src1, int stride1,
-int w, int h)
-{
-int x, y;
-uint64_t ssd = 0;
+static FFSFC64 prng_state;
+static SwsContext *sws[3]; /* reused between tests for efficiency */
 
-for (y = 0; y < h; y++) {
-for (x = 0; x < w; x++) {
-int d = src1[x + y * stride1] - ref;
-ssd += d * d;
-}
-}
-return ssd;
+static int fmt_comps(enum AVPixelFormat fmt)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
+int comps = desc->nb_components >= 3 ? 0b111 : 0b1;
+if (desc->flags & AV_PIX_FMT_FLAG_ALPHA)
+comps |= 0b1000;
+return comps;
 }
 
-struct Results {
-uint64_t ssdY;
-uint64_t ssdU;
-uint64_t ssdV;
-uint64_t ssdA;
-uint32_t crc;
-};
-
-// test by ref -> src -> dst -> out & compare out against ref
-// ref & out are YV12
-static int doTest(const uint8_t * const ref[4], int refStride[4], int w, int h,
-  enum AVPixelFormat srcFormat, enum AVPixelFormat dstFormat,
-  int srcW, int srcH, int dstW, int dstH, int flags,
-  struct Results *r)
+static void get_mse(int mse[4], const AVFrame *a, const AVFrame *b, int comps)
 {
-const AVPixFmtDescriptor *desc_yuva420p = 
av_pix_fmt_desc_get(AV_PIX_FMT_YUVA420P);
-const AVPixFmtDescriptor *desc_src  = av_pix_fmt_desc_get(srcFormat);
-const AVPixFmtDescriptor *desc_dst  = av_pix_fmt_desc_get(dstFormat);
-static enum AVPixelFormat cur_srcFormat;
-static int cur_srcW, cur_srcH;
-static const uint8_t *src[4];
-static int srcStride[4];
-uint8_t *dst[4] = { 0 };
-uint8_t *out[4] = { 0 };
-int dstStride[4] = {0};

[FFmpeg-devel] [PATCH 1/1] riscv/h264dsp: remove spurious instruction

[Rémi Denis-Courmont]

---
 libavcodec/riscv/h264dsp_rvv.S | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/riscv/h264dsp_rvv.S b/libavcodec/riscv/h264dsp_rvv.S
index 05d077f44e..44f6202602 100644
--- a/libavcodec/riscv/h264dsp_rvv.S
+++ b/libavcodec/riscv/h264dsp_rvv.S
@@ -288,7 +288,6 @@ func ff_h264_v_loop_filter_\type\()_8_rvv, zve32x
 vsetivli  zero, 4 * \inners, e8, \e8mul, ta, ma
 vle8.vv11, (a0)
 sub   t2, t3, a1
-vid.v v0
 vle8.vv10, (t3)
 add   t5, a0, a1
 vle8.vv9, (t2)
-- 
2.45.2

___
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] lavu/get_video_buffer: also align data pointers

[Anton Khirnov]

Quoting Pavel Koshevoy (2024-11-09 18:46:53)
> AVFrame.data pointers being aligned according to the explicitly specified
> align parameter
> is not going to break any caller.  It is a safe change, and I would think
> a welcome change for any users of av_frame_get_buffer.

I agree and am in favor of this patch.

-- 
Anton Khirnov
___
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 2/4] avformat/movenc: Fix ffv1 support

[Michael Niedermayer]

On Wed, Sep 25, 2024 at 12:24:09AM +0200, Michael Niedermayer wrote:
> Fixes: Ticket9975
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/movenc.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

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

Nations do behave wisely once they have exhausted all other alternatives. 
-- Abba Eban


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