Re: [FFmpeg-devel] [PATCH 41/57] avcodec/mpeg4videodec: Inline constants

[Michael Niedermayer]

On Wed, Jun 12, 2024 at 03:48:37PM +0200, Andreas Rheinhardt wrote:
> Partitioned macroblocks are always 8bit and not studio profile.

This is not true

Table 9-1 -- Tools for Version 1 Visual Object Types

data partitioning allows N-Bit object Type, theres a "x" there
Thing is we dont fully support N-bit so it may look like that but
studio profile != N-bit

some other of your patches also look like they remove N-bit related code

[...]

thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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 37/57] avcodec/mpegutils: Don't output wrong mb skip values

[Michael Niedermayer]

On Wed, Jun 12, 2024 at 03:48:33PM +0200, Andreas Rheinhardt wrote:
> The earlier code had two problems:
> 1. For reference frames that are not directly output (happens unless
> low_delay is set), the mb skip values referred to the next reference
> frame to be decoded.
> 2. For non-reference frames, every macroblock was always considered
> skipped.
> This makes the output (worse than) useless; that no one ever
> complained about this shows that this feature is not really used.
> It is therefore removed.

I used it for statistical purposes long ago, seeing how much blocks where
skiped and for that a +-1 frame difference is inconsequantal. Also
i understood that B frame are handled differently, its an internal
bitstream related number after all

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Some people wanted to paint the bikeshed green, some blue and some pink.
People argued and fought, when they finally agreed, only rust was left.


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 v3] area changed: scdet filter

[radu.taraibuta]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: joi, 13 iunie 2024 02:52
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH v3] area changed: scdet filter
> 
> 
> I honestly dont see the value of refcounting the global cbrt tables
> 
> either they can be static and initialized by a single AV_ONCE_INIT or just
> allocate and reinint for each filter.
> 

There is one cbrt_table for each bitdepth. Initializing all of them before 
knowing which one is used, would be a waste.
To allocate and initialize one table for each filter/client would be a waste 
too in a multiple clients scenario.

> > +
> > +void ff_scene_scrd_c(SCENE_SAD_PARAMS) {
> > +uint64_t scrdPlus = 0;
> > +uint64_t scrdMinus = 0;
> > +int x, y;
> > +double mean;
> > +uint8_t *table = cbrt_table[8];
> > +
> > +if (!table) {
> > +*sum = 0;
> > +return;
> > +}
> > +
> > +for (y = 0; y < height; y++) {
> > +for (x = 0; x < width; x++)
> > +if (src1[x] > src2[x])
> > +scrdMinus += table[src1[x] - src2[x]];
> > +else
> > +scrdPlus += table[src2[x] - src1[x]];
> > +src1 += stride1;
> > +src2 += stride2;
> > +}
> > +
> 
> > +mean = (sqrt(scrdPlus) + sqrt(scrdMinus)) / 2.0;
> > +*sum = 2.0 * mean * mean;
> 
> one sqrt less:
> 0.5*(scrdPlus + scrdMinus) + sqrt(scrdPlus * (double)scrdMinus)
> 

OK, will do in the next version.

> > +}
> > +
> > +void ff_scene_scrd2B_c(SCENE_SAD_PARAMS, int bitdepth) {
> > +uint64_t scrdPlus = 0;
> > +uint64_t scrdMinus = 0;
> > +const uint16_t *src1w = (const uint16_t*)src1;
> > +const uint16_t *src2w = (const uint16_t*)src2;
> > +int x, y;
> > +double mean;
> > +uint16_t *table = (uint16_t*)cbrt_table[bitdepth];
> > +
> > +if (!table) {
> > +*sum = 0;
> > +return;
> > +}
> > +
> > +stride1 /= 2;
> > +stride2 /= 2;
> > +
> > +for (y = 0; y < height; y++) {
> > +for (x = 0; x < width; x++)
> > +if (src1w[x] > src2w[x])
> > +scrdMinus += table[src1w[x] - src2w[x]];
> > +else
> > +scrdPlus += table[src2w[x] - src1w[x]];
> > +src1w += stride1;
> > +src2w += stride2;
> > +}
> > +
> > +mean = (sqrt(scrdPlus) + sqrt(scrdMinus)) / 2.0;
> > +*sum = 2.0 * mean * mean;
> > +}
> > +
> > +void ff_scene_scrd9_c(SCENE_SAD_PARAMS)
> > +{
> > +ff_scene_scrd2B_c(src1, stride1, src2, stride2, width, height,
> > +sum, 9); }
> > +
> > +void ff_scene_scrd10_c(SCENE_SAD_PARAMS)
> > +{
> > +ff_scene_scrd2B_c(src1, stride1, src2, stride2, width, height,
> > +sum, 10); }
> > +
> > +void ff_scene_scrd12_c(SCENE_SAD_PARAMS)
> > +{
> > +ff_scene_scrd2B_c(src1, stride1, src2, stride2, width, height,
> > +sum, 12); }
> > +
> > +void ff_scene_scrd14_c(SCENE_SAD_PARAMS)
> > +{
> > +ff_scene_scrd2B_c(src1, stride1, src2, stride2, width, height,
> > +sum, 14); }
> > +
> > +void ff_scene_scrd16_c(SCENE_SAD_PARAMS)
> > +{
> > +ff_scene_scrd2B_c(src1, stride1, src2, stride2, width, height,
> > +sum, 16); }
> 
> duplicating this 5 times just for a different LUT pointer is ugly
> 
> 

It's not pretty, but I did it to preserve the existing interface and keep logic 
together.
Any suggestion how else to do it?


___
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 33/57] avcodec/mpv_reconstruct_mb_template: Don't unnecessarily copy data

[Michael Niedermayer]

On Wed, Jun 12, 2024 at 03:48:29PM +0200, Andreas Rheinhardt wrote:
> There is no reason to use a temporary buffer as destination
> for the new macroblock before copying it into its proper place.
> 
> (History: 3994623df2efd2749631c3492184dd8d4ffa9d1b changed
> the precursor of ff_mpv_reconstruct_mb() to always decode
> to the first row of macroblocks for B pictures when
> a draw_horiz_band callback is set (they are exported to the caller
> via said callback and each row overwrites the previously decoded
> row; this was probably intended as a cache-optimization).
> Later b68ab2609c67d07b6f12ed65125d76bf9a054479 changed this
> to the current form in which a scratchpad buffer is used when
> decoding B-pictures without draw_horiz_band callback, followed
> by copying the block from the scratchpad buffer to the actual
> destination. I do not know what the aim of this was. When thinking
> of it as a cache optimization, it makes sense to not use it
> when the aforementioned draw_horiz_band optimization is in effect,
> because then the destination row can be presumed to be hot
> already. But then it makes no sense to restrict this optimization
> to B-frames.)

IIRC
The B frames where directly placed in GPU memory, which is slow to read
from, so building up MC + IDCT (which could read depending on caches)
was avoided by a a scratchpad but its really long ago so i might remember
this only partly

thx

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- 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 25/57] avcodec/me_cmp, motion_est: Sanitize permissible cmp_funcs

[Michael Niedermayer]

On Wed, Jun 12, 2024 at 03:48:21PM +0200, Andreas Rheinhardt wrote:
> Several of the potential choices of comparison functions
> need an initialized MpegEncContext (initialized for encoding,
> not only ff_mpv_common_init()) or they crash when called.
> Modify ff_set_cmp() to check for this.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---

I dont think they always crashed, so to me marking these as
unsupported now feels a bit strange. But it shows we where lacking
testing

thx

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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 12/57] avcodec/mpegutils: Don't use MB_TYPE_L[01] for mpegvideo

[Michael Niedermayer]

On Wed, Jun 12, 2024 at 03:48:08PM +0200, Andreas Rheinhardt wrote:
> MB_TYPE_L[01] is based upon H.264 terminology (it stands for
> list); yet the mpegvideo based decoders don't have lists
> of reference frames, they have at most one forward and one
> backward reference. So use terminology based upon this.
> 
> This also has a second advantage: MB_TYPE_L[01] is actually
> an OR of two flags (which are set independently for H.264,
> but aren't for mpegvideo). Switching to different flags
> makes the flags fit into an int16_t, which will be useful
> in future commits.
> 
> The only downside to this is a very small amount of code
> in error_resilience.c and mpegutils.c (the only code shared
> between the H.264 decoder and mpegvideo).

Cant you just call the flags differently but leave them nummerically
the same, if you dont like L0L1 terminology ?

Having each codec be different does not seem to me to be a good thing
It adds burden to every bit of common code. It may be thats error_resilience
ATM, but there are other things people may want to add, like an universal
encoder for all the block based transform + MC formats

thx

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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 12/57] avcodec/mpegutils: Don't use MB_TYPE_L[01] for mpegvideo

[Andreas Rheinhardt]

Michael Niedermayer:
> On Wed, Jun 12, 2024 at 03:48:08PM +0200, Andreas Rheinhardt wrote:
>> MB_TYPE_L[01] is based upon H.264 terminology (it stands for
>> list); yet the mpegvideo based decoders don't have lists
>> of reference frames, they have at most one forward and one
>> backward reference. So use terminology based upon this.
>>
>> This also has a second advantage: MB_TYPE_L[01] is actually
>> an OR of two flags (which are set independently for H.264,
>> but aren't for mpegvideo). Switching to different flags
>> makes the flags fit into an int16_t, which will be useful
>> in future commits.
>>
>> The only downside to this is a very small amount of code
>> in error_resilience.c and mpegutils.c (the only code shared
>> between the H.264 decoder and mpegvideo).
> 
> Cant you just call the flags differently but leave them nummerically
> the same, if you dont like L0L1 terminology ?
> 
> Having each codec be different does not seem to me to be a good thing
> It adds burden to every bit of common code. It may be thats error_resilience
> ATM, but there are other things people may want to add, like an universal
> encoder for all the block based transform + MC formats

1. The terminology is only one part of this: Using the same flags
currently adds a burden to the mpegvideo-decoders, because their
mb_types don't fit into an int16_t, so that they can't use symbols
tables. See the following patches for this.
2. Furthermore, it is not "each codec" that has its own system of
defines; it is only H.264 vs. the rest. And even these two systems are
mostly the same.
3. If you create a universal encoder, then you'd be better off to use
your own MB_TYPE_ defines for it and not to reuse this system here. In
fact, mpegvideoenc does not really use it (it uses its
CANDIDATE_MB_TYPE_* system).
4. And I don't think that a "universal" encoder is even a desirable
idea. An in-tree H.264 encoder would be very complex and all encoders
would benefit if it were not tied to the other encoders. Apart from
that, x264 is a thing.

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 33/57] avcodec/mpv_reconstruct_mb_template: Don't unnecessarily copy data

[Andreas Rheinhardt]

Michael Niedermayer:
> On Wed, Jun 12, 2024 at 03:48:29PM +0200, Andreas Rheinhardt wrote:
>> There is no reason to use a temporary buffer as destination
>> for the new macroblock before copying it into its proper place.
>>
>> (History: 3994623df2efd2749631c3492184dd8d4ffa9d1b changed
>> the precursor of ff_mpv_reconstruct_mb() to always decode
>> to the first row of macroblocks for B pictures when
>> a draw_horiz_band callback is set (they are exported to the caller
>> via said callback and each row overwrites the previously decoded
>> row; this was probably intended as a cache-optimization).
>> Later b68ab2609c67d07b6f12ed65125d76bf9a054479 changed this
>> to the current form in which a scratchpad buffer is used when
>> decoding B-pictures without draw_horiz_band callback, followed
>> by copying the block from the scratchpad buffer to the actual
>> destination. I do not know what the aim of this was. When thinking
>> of it as a cache optimization, it makes sense to not use it
>> when the aforementioned draw_horiz_band optimization is in effect,
>> because then the destination row can be presumed to be hot
>> already. But then it makes no sense to restrict this optimization
>> to B-frames.)
> 
> IIRC
> The B frames where directly placed in GPU memory, which is slow to read
> from, so building up MC + IDCT (which could read depending on caches)
> was avoided by a a scratchpad but its really long ago so i might remember
> this only partly
> 

The code here is not executed for hardware acceleration at all. For the
ordinary case, this copy incurs overhead; furthermore it increases
complexity (and for these reasons no other codec has similar code). So
I'd like to remove it (with an amended commit message that says that
this was done due to concerns about reading from GPU memory). Do you
object to this?

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 25/57] avcodec/me_cmp, motion_est: Sanitize permissible cmp_funcs

[Andreas Rheinhardt]

Michael Niedermayer:
> On Wed, Jun 12, 2024 at 03:48:21PM +0200, Andreas Rheinhardt wrote:
>> Several of the potential choices of comparison functions
>> need an initialized MpegEncContext (initialized for encoding,
>> not only ff_mpv_common_init()) or they crash when called.
>> Modify ff_set_cmp() to check for this.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
> 
> I dont think they always crashed, so to me marking these as
> unsupported now feels a bit strange. But it shows we where lacking
> testing

Why don't you just try:
for codec in svq1 snow; do for cmp in dct psnr bit rd dctmax 14; do
./ffmpeg_g -hide_banner -filter_complex nullsrc -c:v "$codec" -cmp
"$cmp" -f null -; done; done
yourself?

- Andreas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] web: move 6.0 to olddownload

[Michael Niedermayer]

I see no users on https://trac.ffmpeg.org/wiki/Downstreams

Signed-off-by: Michael Niedermayer 
---
 src/download| 36 
 src/olddownload | 36 
 2 files changed, 36 insertions(+), 36 deletions(-)

diff --git a/src/download b/src/download
index 2e6a455..3ebf773 100644
--- a/src/download
+++ b/src/download
@@ -377,42 +377,6 @@ libpostproc57.  3.100
  

 
-  FFmpeg 6.0.1 "Von Neumann"
-
-  
-6.0.1 was released on 2023-11-10. It is the latest stable FFmpeg release
-from the 6.0 release branch, which was cut from master on 2023-02-19.
-  
-  It includes the following library versions:
-  
-  
-libavutil  58.  2.100
-libavcodec 60.  3.100
-libavformat60.  3.100
-libavdevice60.  1.100
-libavfilter 9.  3.100
-libswscale  7.  1.100
-libswresample   4. 10.100
-libpostproc57.  1.100
-  
-
-  Download 
xz tarball
-  PGP 
signature
- 
-
-  Download 
bzip2 tarball
-  PGP 
signature
- 
-
-  Download 
gzip tarball
-  PGP 
signature
- 
-
-  https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/n6.0.1";>Changelog
-  https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/6.0:/RELEASE_NOTES";>Release
 Notes
- 
-   
-
   FFmpeg 5.1.4 "Riemann"
 
   
diff --git a/src/olddownload b/src/olddownload
index 187848e..a6b2ff2 100644
--- a/src/olddownload
+++ b/src/olddownload
@@ -6,6 +6,42 @@
   maintaining an old release.
 
 
+  FFmpeg 6.0.1 "Von Neumann"
+
+  
+6.0.1 was released on 2023-11-10. It is the latest stable FFmpeg release
+from the 6.0 release branch, which was cut from master on 2023-02-19.
+  
+  It includes the following library versions:
+  
+  
+libavutil  58.  2.100
+libavcodec 60.  3.100
+libavformat60.  3.100
+libavdevice60.  1.100
+libavfilter 9.  3.100
+libswscale  7.  1.100
+libswresample   4. 10.100
+libpostproc57.  1.100
+  
+
+  Download 
xz tarball
+  PGP 
signature
+ 
+
+  Download 
bzip2 tarball
+  PGP 
signature
+ 
+
+  Download 
gzip tarball
+  PGP 
signature
+ 
+
+  https://git.ffmpeg.org/gitweb/ffmpeg.git/shortlog/n6.0.1";>Changelog
+  https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/refs/heads/release/6.0:/RELEASE_NOTES";>Release
 Notes
+ 
+   
+
   FFmpeg 5.0.3 "Lorentz"
 
   
-- 
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 v3] area changed: scdet filter

[Tobias Rapp]

On 12/06/2024 21:51, radu.taraib...@gmail.com wrote:

[...]


diff --git a/doc/filters.texi b/doc/filters.texi
index bfa8ccec8b..53814e003b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21797,6 +21797,22 @@ Default value is @code{10.}.
 @item sc_pass, s
 Set the flag to pass scene change frames to the next filter. Default 
value is @code{0}
 You can enable it if you want to get snapshot of scene change frames 
only.

+
+@item mode
+Set the scene change detection method. Default value is @code{-1}
+Available values are:
+
+@table @samp
+@item -1
+Legacy mode for sum of absolute linear differences. Compare frame 
with previous only and no delay.

+
+@item 0
+Sum of absolute linear differences. Compare frame with both previous 
and next which introduces a 1 frame delay.

+
+@item 1
+Sum of mean of cubic root differences. Compare frame with both 
previous and next which introduces a 1 frame delay.

+
+@end table
 @end table

 @anchor{selectivecolor}


Out of curiosity: How do these three modes roughly compare (CPU) 
performance wise?


I'd prefer if mode "-1" could be used for the default case, and the 
three modes get explicit values 0/1/2. Regarding naming I think that the 
"Legacy" mode still has its usecases in the future. Naming it something 
like "simple" would not imply that it is deprecated in general, but 
rather that it has lower precision (and is possibly faster).


Best regards,
Tobias

___
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] area changed: scdet filter

[radu.taraibuta]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Tobias
> Rapp
> Sent: joi, 13 iunie 2024 12:52
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3] area changed: scdet filter
> 
> On 12/06/2024 21:51, radu.taraib...@gmail.com wrote:
> 
> [...]
> 
> > diff --git a/doc/filters.texi b/doc/filters.texi index
> > bfa8ccec8b..53814e003b 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -21797,6 +21797,22 @@ Default value is @code{10.}.
> >  @item sc_pass, s
> >  Set the flag to pass scene change frames to the next filter. Default
> > value is @code{0}
> >  You can enable it if you want to get snapshot of scene change frames
> > only.
> > +
> > +@item mode
> > +Set the scene change detection method. Default value is @code{-1}
> > +Available values are:
> > +
> > +@table @samp
> > +@item -1
> > +Legacy mode for sum of absolute linear differences. Compare frame
> > with previous only and no delay.
> > +
> > +@item 0
> > +Sum of absolute linear differences. Compare frame with both previous
> > and next which introduces a 1 frame delay.
> > +
> > +@item 1
> > +Sum of mean of cubic root differences. Compare frame with both
> > previous and next which introduces a 1 frame delay.
> > +
> > +@end table
> >  @end table
> >
> >  @anchor{selectivecolor}
> 
> Out of curiosity: How do these three modes roughly compare (CPU)
> performance wise?

Mode -1 is virtually equal with mode 0 (no frame clone speedup of mode 0 is 
mostly theoretical). Mode 1 is roughly 40% slower, depending on input, it could 
benefit from ASM.

> I'd prefer if mode "-1" could be used for the default case, and the three 
> modes
> get explicit values 0/1/2. 

So you want four possible values for mode where the default -1 is the same as 
one of the others?

>Regarding naming I think that the "Legacy" mode still
> has its usecases in the future. Naming it something like "simple" would not
> imply that it is deprecated in general, but rather that it has lower precision
> (and is possibly faster).
> 
OK, I will rename "Legacy" mode so it doesn't look deprecated to somebody that 
can't allow 1 frame delay. Otherwise it shouldn't be used.


___
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 12/57] avcodec/mpegutils: Don't use MB_TYPE_L[01] for mpegvideo

[Michael Niedermayer]

On Thu, Jun 13, 2024 at 10:49:15AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Wed, Jun 12, 2024 at 03:48:08PM +0200, Andreas Rheinhardt wrote:
> >> MB_TYPE_L[01] is based upon H.264 terminology (it stands for
> >> list); yet the mpegvideo based decoders don't have lists
> >> of reference frames, they have at most one forward and one
> >> backward reference. So use terminology based upon this.
> >>
> >> This also has a second advantage: MB_TYPE_L[01] is actually
> >> an OR of two flags (which are set independently for H.264,
> >> but aren't for mpegvideo). Switching to different flags
> >> makes the flags fit into an int16_t, which will be useful
> >> in future commits.
> >>
> >> The only downside to this is a very small amount of code
> >> in error_resilience.c and mpegutils.c (the only code shared
> >> between the H.264 decoder and mpegvideo).
> > 
> > Cant you just call the flags differently but leave them nummerically
> > the same, if you dont like L0L1 terminology ?
> > 
> > Having each codec be different does not seem to me to be a good thing
> > It adds burden to every bit of common code. It may be thats error_resilience
> > ATM, but there are other things people may want to add, like an universal
> > encoder for all the block based transform + MC formats
> 
> 1. The terminology is only one part of this: Using the same flags
> currently adds a burden to the mpegvideo-decoders, because their
> mb_types don't fit into an int16_t, so that they can't use symbols
> tables. See the following patches for this.
> 2. Furthermore, it is not "each codec" that has its own system of
> defines; it is only H.264 vs. the rest. And even these two systems are
> mostly the same.
> 3. If you create a universal encoder, then you'd be better off to use
> your own MB_TYPE_ defines for it and not to reuse this system here. In
> fact, mpegvideoenc does not really use it (it uses its
> CANDIDATE_MB_TYPE_* system).
> 4. And I don't think that a "universal" encoder is even a desirable
> idea. An in-tree H.264 encoder would be very complex and all encoders
> would benefit if it were not tied to the other encoders. Apart from
> that, x264 is a thing.

iam not talking about h.264, I do think though that extending the concept
of our mpegvideo encoder which happily encodes from mjpeg, h.261, RV10, RV20
mpeg-1, mpeg-2, mpeg-4, h.263 to WMV1 and WMV2
to some more generic universal encoder that covers the more modern formats
does make sense and is desirable

That said, i guess it doesnt matter if you change the flags, you are probably
correct that they wont be too usefull as they are either ...

thx

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

You can kill me, but you cannot change the truth.


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] tests/checkasm: Remove check on linux perf fd in uninit

[Zhao Zhili]

> On Jun 13, 2024, at 10:04, Shiqi Zhu  wrote:
> 
> On Thu, 13 Jun 2024 at 01:36, Zhao Zhili  > wrote:
>> 
>> From: Zhao Zhili 
>> 
>> The check should be >= 0, not > 0. The check itself is redundant
>> since uninit only being called after init is success.
>> ---
>> tests/checkasm/checkasm.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>> 
>> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
>> index 28237b4d25..bbcc90f91f 100644
>> --- a/tests/checkasm/checkasm.c
>> +++ b/tests/checkasm/checkasm.c
>> @@ -814,8 +814,7 @@ static int bench_init(void)
>> static void bench_uninit(void)
>> {
>> #if CONFIG_LINUX_PERF
>> -if (state.sysfd > 0)
>> -close(state.sysfd);
>> +close(state.sysfd);
> 
> Is this better?
> 
> if (state.sysfd >= 0) {
>close(state.sysfd);
>state.sysfd = -1;
> }

I don’t think there is a requirement on reentrancy in this case.

> 
>> #endif
>> }
>> 
>> --
>> 2.42.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 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] FFmpeg 5.1.5 and 4.3.7

[Michael Niedermayer]

Hi all

I intend to make 5.1.5 and 4.3.7 releases "soon"(1) for debian

If you want something backported, now is your last chance to backport it

thx

(1) i still have more things to backport and somethings i need to fix in
my local setup, so it will take me a few days probably

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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 v2] movenc: Add an option for hiding fragments at the end

[Martin Storsjö]

On Wed, 5 Jun 2024, Martin Storsjö wrote:


This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)

This results in a file where the mdat atom contains (and hides)
all the moof atoms that were part of the fragmented file structure
initially.
---
v2: Made the flag implicitly set FF_MOV_FLAG_FRAGMENT (as it makes
no sense without it).

Updated the description of the flag to "Write a fragmented file that
is converted to non-fragmented at the end".

Kept the flag named "hide_fragments", but I'm also pondering if we
maybe should go for a name like "hybrid_fragmented" or so, as a
better description of _what_ it produces, as opposed to _how_ it
does things. (One could also consider "hybrid_mp4", but even if mp4
is the main thing, the same also goes for mov and a bunch of other
related formats.)


I'd otherwise want to push this, but I'm not entirely satisfied with the 
option name quite yet. I'm pondering if we should call it 
"hybrid_fragmented" - any opinions, Dennis or Timo?


// 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] aarch64: Use cntvct_el0 as timer register on Android

[Martin Storsjö]

On Fri, 7 Jun 2024, Martin Storsjö wrote:


The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.
---
cntvct_el0 has significantly better resolution than
av_gettime_relative (while the unscaled nanosecond output of
clock_gettime is much higher resolution).

In one tested case, the cntvct_el0 timer has a frequency of 25 MHz
(readable via the register cntfrq_el0).
---
libavutil/aarch64/timer.h | 9 +
1 file changed, 9 insertions(+)

diff --git a/libavutil/aarch64/timer.h b/libavutil/aarch64/timer.h
index fadc9568f8..966f17081a 100644
--- a/libavutil/aarch64/timer.h
+++ b/libavutil/aarch64/timer.h
@@ -33,7 +33,16 @@ static inline uint64_t read_time(void)
uint64_t cycle_counter;
__asm__ volatile(
"isb   \t\n"
+#if defined(__ANDROID__)
+// cntvct_el0 has lower resolution than pmccntr_el0, but is usually
+// accessible from user space by default.
+"mrs %0, cntvct_el0"
+#else
+// pmccntr_el0 has higher resolution, but is usually not accessible
+// from user space by default (but access can be enabled with a custom
+// kernel module).
"mrs %0, pmccntr_el0   "
+#endif
: "=r"(cycle_counter) :: "memory" );


Zhao, does this implementation seem useful to you? Does it give you better 
(more accurate, less noisy?) benchmarking numbers on Android, than the 
fallback based on clock_gettime?


// 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 v3] area changed: scdet filter

[Tobias Rapp]

On 13/06/2024 13:21, radu.taraib...@gmail.com wrote:


-Original Message-
From: ffmpeg-devel  On Behalf Of Tobias
Rapp
Sent: joi, 13 iunie 2024 12:52
To:ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v3] area changed: scdet filter

On 12/06/2024 21:51,radu.taraib...@gmail.com  wrote:

[...]


diff --git a/doc/filters.texi b/doc/filters.texi index
bfa8ccec8b..53814e003b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -21797,6 +21797,22 @@ Default value is @code{10.}.
  @item sc_pass, s
  Set the flag to pass scene change frames to the next filter. Default
value is @code{0}
  You can enable it if you want to get snapshot of scene change frames
only.
+
+@item mode
+Set the scene change detection method. Default value is @code{-1}
+Available values are:
+
+@table @samp
+@item -1
+Legacy mode for sum of absolute linear differences. Compare frame
with previous only and no delay.
+
+@item 0
+Sum of absolute linear differences. Compare frame with both previous
and next which introduces a 1 frame delay.
+
+@item 1
+Sum of mean of cubic root differences. Compare frame with both
previous and next which introduces a 1 frame delay.
+
+@end table
  @end table

  @anchor{selectivecolor}

Out of curiosity: How do these three modes roughly compare (CPU)
performance wise?

Mode -1 is virtually equal with mode 0 (no frame clone speedup of mode 0 is 
mostly theoretical). Mode 1 is roughly 40% slower, depending on input, it could 
benefit from ASM.


I'd prefer if mode "-1" could be used for the default case, and the three modes
get explicit values 0/1/2.

So you want four possible values for mode where the default -1 is the same as 
one of the others?


Yes. This pattern is also used for the "shaping" option of the ass 
filter, for example.It allows users to make it explicit that the filter 
should choose a default (which may vary between versions).



Regarding naming I think that the "Legacy" mode still
has its usecases in the future. Naming it something like "simple" would not
imply that it is deprecated in general, but rather that it has lower precision
(and is possibly faster).


OK, I will rename "Legacy" mode so it doesn't look deprecated to somebody that 
can't allow 1 frame delay. Otherwise it shouldn't be used.


Thanks.

Regards, Tobias
___
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] doc/developer: point to git examples for gmail instead

[Michael Niedermayer]

This was suggested by kasper93 on IRC

Do people prefer this or the previous ?
should we have both links instead ?

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

diff --git a/doc/developer.texi b/doc/developer.texi
index 41b21938ef8..f3ad4e08fa7 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -641,7 +641,7 @@ likely was wrong.
 @subheading How to setup git send-email?
 
 Please see @url{https://git-send-email.io/}.
-For gmail additionally see 
@url{https://shallowsky.com/blog/tech/email/gmail-app-passwds.html}.
+For gmail additionally see 
@url{https://git-scm.com/docs/git-send-email#_examples}.
 
 @subheading Sending patches from email clients
 Using @code{git send-email} might not be desirable for everyone. The
-- 
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 v2] movenc: Add an option for hiding fragments at the end

[Timo Rothenpieler]

On 13/06/2024 14:50, Martin Storsjö wrote:

On Wed, 5 Jun 2024, Martin Storsjö wrote:


This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)

This results in a file where the mdat atom contains (and hides)
all the moof atoms that were part of the fragmented file structure
initially.
---
v2: Made the flag implicitly set FF_MOV_FLAG_FRAGMENT (as it makes
no sense without it).

Updated the description of the flag to "Write a fragmented file that
is converted to non-fragmented at the end".

Kept the flag named "hide_fragments", but I'm also pondering if we
maybe should go for a name like "hybrid_fragmented" or so, as a
better description of _what_ it produces, as opposed to _how_ it
does things. (One could also consider "hybrid_mp4", but even if mp4
is the main thing, the same also goes for mov and a bunch of other
related formats.)


I'd otherwise want to push this, but I'm not entirely satisfied with the 
option name quite yet. I'm pondering if we should call it 
"hybrid_fragmented" - any opinions, Dennis or Timo?


It's at least in line with what OBS dubbed the same feature, so would 
allow consistent Search-Results.

So it seems like a good compromise to me.
___
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] movenc: Add an option for hiding fragments at the end

[Gyan Doshi]

On 2024-06-13 06:20 pm, Martin Storsjö wrote:

On Wed, 5 Jun 2024, Martin Storsjö wrote:


This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)

This results in a file where the mdat atom contains (and hides)
all the moof atoms that were part of the fragmented file structure
initially.
---
v2: Made the flag implicitly set FF_MOV_FLAG_FRAGMENT (as it makes
no sense without it).

Updated the description of the flag to "Write a fragmented file that
is converted to non-fragmented at the end".

Kept the flag named "hide_fragments", but I'm also pondering if we
maybe should go for a name like "hybrid_fragmented" or so, as a
better description of _what_ it produces, as opposed to _how_ it
does things. (One could also consider "hybrid_mp4", but even if mp4
is the main thing, the same also goes for mov and a bunch of other
related formats.)


I'd otherwise want to push this, but I'm not entirely satisfied with 
the option name quite yet. I'm pondering if we should call it 
"hybrid_fragmented" - any opinions, Dennis or Timo?


How about `resilient_mode` or `recoverable`?
I agree that the how is secondary.

Regards,
Gyan

___
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] area changed: scdet filter

[radu.taraibuta]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Tobias
> Rapp
> Sent: joi, 13 iunie 2024 16:18
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3] area changed: scdet filter
> 
> On 13/06/2024 13:21, radu.taraib...@gmail.com wrote:
> 
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> >> Tobias Rapp
> >> Sent: joi, 13 iunie 2024 12:52
> >> To:ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH v3] area changed: scdet filter
> >>
> >> On 12/06/2024 21:51,radu.taraib...@gmail.com  wrote:
> >>
> >> [...]
> >>
> >>> diff --git a/doc/filters.texi b/doc/filters.texi index
> >>> bfa8ccec8b..53814e003b 100644
> >>> --- a/doc/filters.texi
> >>> +++ b/doc/filters.texi
> >>> @@ -21797,6 +21797,22 @@ Default value is @code{10.}.
> >>>   @item sc_pass, s
> >>>   Set the flag to pass scene change frames to the next filter.
> >>> Default value is @code{0}
> >>>   You can enable it if you want to get snapshot of scene change
> >>> frames only.
> >>> +
> >>> +@item mode
> >>> +Set the scene change detection method. Default value is @code{-1}
> >>> +Available values are:
> >>> +
> >>> +@table @samp
> >>> +@item -1
> >>> +Legacy mode for sum of absolute linear differences. Compare frame
> >>> with previous only and no delay.
> >>> +
> >>> +@item 0
> >>> +Sum of absolute linear differences. Compare frame with both
> >>> +previous
> >>> and next which introduces a 1 frame delay.
> >>> +
> >>> +@item 1
> >>> +Sum of mean of cubic root differences. Compare frame with both
> >>> previous and next which introduces a 1 frame delay.
> >>> +
> >>> +@end table
> >>>   @end table
> >>>
> >>>   @anchor{selectivecolor}
> >> Out of curiosity: How do these three modes roughly compare (CPU)
> >> performance wise?
> > Mode -1 is virtually equal with mode 0 (no frame clone speedup of mode 0
is
> mostly theoretical). Mode 1 is roughly 40% slower, depending on input, it
> could benefit from ASM.
> >
> >> I'd prefer if mode "-1" could be used for the default case, and the
> >> three modes get explicit values 0/1/2.
> > So you want four possible values for mode where the default -1 is the
same as
> one of the others?
> 
> Yes. This pattern is also used for the "shaping" option of the ass filter,
for
> example.It allows users to make it explicit that the filter should choose
a
> default (which may vary between versions).

Scdet filter doesn't choose a mode. The default has to be current "Legacy"
for backward compatibility.
I will renumber modes to 0/1/2 to avoid confusion with an "auto" (-1)
option.

> >> Regarding naming I think that the "Legacy" mode still has its
> >> usecases in the future. Naming it something like "simple" would not
> >> imply that it is deprecated in general, but rather that it has lower
> >> precision (and is possibly faster).
> >>
> > OK, I will rename "Legacy" mode so it doesn't look deprecated to
somebody
> that can't allow 1 frame delay. Otherwise it shouldn't be used.
> 
> Thanks.
> 
> Regards, Tobias
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
> with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v6 1/4] doc: Explain what "context" means

[Andrew Sayers]

On Wed, Jun 12, 2024 at 10:52:00PM +0200, Stefano Sabatini wrote:
> On date Tuesday 2024-06-04 15:47:21 +0100, Andrew Sayers wrote:
[...]
> My impression is that this is growing out of scope for a
> reference. The doxy is a reference, therefore it should be clean and
> terse, and we should avoid adding too much information, enough
> information should be right enough. In fact, a reference is different
> from a tutorial, and much different from a C tutorial. Also this is
> not a treatise comparing different languages and frameworks, as this
> would confuse beginners and would annoy experienced developers.
> 
> I propose to cut this patch to provide the minimal information you can
> expect in a reference, but not more than that. Addition can be added
> later, but I think we should try to avoid any unnecessary content, in
> the spirit of keeping this a reference. More extensive discussions
> might be done in a separate place (the wiki, a blog post etc.), but in
> the spirit of a keeping this a reference they should not be put here.

I would agree if we had a tradition of linking to the wiki or regular blog
posts, but even proposing internal links has generated pushback in this thread,
so that feels like making the perfect the enemy of the good.  Let's get this
committed, see how people react, then look for improvements.

In fact, once this is available in the trunk version of the website,
we should ask for feedback from the libav-user ML and #ffmpeg IRC channel.
Then we can expand/move/remove stuff based on feedback.

> 
> > +
> > +@section Context_general “Context” as a general concept
[...]
> I'd skip all this part, as we assume the reader is already familiar
> with C language and with data encapsulation through struct, if he is
> not this is not the right place where to teach about C language
> fundamentals.

I disagree, for a reason I've been looking for an excuse to mention :)

Let's assume 90% of people who use FFmpeg already know something in the doc.
You could say that part of the doc is useless to 90% of the audience.
Or you could say that 90% of FFmpeg users are not our audience.

Looking at it the second way means you need to spend more time on "routing" -
linking to the document in ways that (only) attract your target audience,
making a table of contents with headings that aid skip-readers, etc.
But once you've routed people around the bits they don't care about,
it's fine to have documentation that's only needed by a minority.

Also, less interesting but equally important - context is not a C language
fundamental, it's more like an emergent property of large C projects.  A
developer that came here without knowing e.g. what a struct is could read
any of the online tutorials that explain the concept better than we could.
I'd be happy to link to a good tutorial about contexts if we found one,
but we have to meet people where they are, and this is the best solution
I've been able to find.

> 
> > +
> > +When reading code that *is* explicitly described in terms of contexts,
> > +remember that the term's meaning is guaranteed by *the project's 
> > community*,
> > +not *the language it's written in*.  That means guarantees may be more 
> > flexible
> > +and change more over time.  For example, programming languages that use
> > +[encapsulation](https://en.wikipedia.org/wiki/Encapsulation_(computer_programming))
> > +will simply refuse to compile code that violates its rules about access,
> > +while communities can put up with special cases if they improve code 
> > quality.
> > +
> 
> This looks a bit vague so I'd rather drop this.

This probably looks vague to you because you're part of the 90% of people this
paragraph isn't for.  All programming languages provide some guarantees, and
leave others up to the community to enforce (or not).  Over time, people stop
seeing the language guarantees at all, and assume the only alternative is
anarchy.  For example, if you got involved in a large JavaScript project,
you might be horrified to see almost all structs are the same type ("Object"),
and are implemented as dictionaries that are expected to have certain keys.
But in practice, this stuff gets enforced at the community level well enough.
Similarly, a JS programmer might be horrified to learn FFmpeg needs a whole
major version bump just to add a key to a struct.  This paragraph is there to
nudge people who have stopped seeing things we need them to look out for.

If you'd like to maintain an official FFmpeg blog, I'd be happy to expand the
paragraph above into a medium-sized post, then just link it from the doc.
But that post would be too subjective to be a wiki page - JavaScript is
evolving in a more strongly-typed direction, so it would only make sense to
future readers if they could say "oh yeah this was written in 2024, JS was
still like that back then".  This paragraph is an achievable compromise -
covers enough ground to give people a way to think about the code, short enough
for people who don't ca

Re: [FFmpeg-devel] [PATCH] web: move 6.0 to olddownload

[James Almer]

On 6/13/2024 7:10 AM, Michael Niedermayer wrote:

I see no users on https://trac.ffmpeg.org/wiki/Downstreams


Ubuntu 23.10 (non LTS) ships it, but it EOLs in one month, so wait until 
mid July to push this.

___
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] lavfi: add perlin noise generator

[Andrew Sayers]

Some documentation nitpicks.  Nothing jumped out about the code, but I don't
know the algorithm well enough to spot anything deep.

> From 9932cfc19500acbd0685eb2cc8fd88e9af3f5dbd Mon Sep 17 00:00:00 2001
> From: Stefano Sabatini 
> Date: Mon, 27 May 2024 11:19:08 +0200
> Subject: [PATCH] lavfi: add Perlin noise generator
> 
> ---
>  Changelog |   1 +
>  doc/filters.texi  | 100 +
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/perlin.c  | 224 ++
>  libavfilter/perlin.h  | 101 +
>  libavfilter/vsrc_perlin.c | 169 
>  7 files changed, 597 insertions(+)
>  create mode 100644 libavfilter/perlin.c
>  create mode 100644 libavfilter/perlin.h
>  create mode 100644 libavfilter/vsrc_perlin.c
> 
> diff --git a/Changelog b/Changelog
> index 03d6b29ad8..b8dcf452ac 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -12,6 +12,7 @@ version :
>  - qsv_params option added for QSV encoders
>  - VVC decoder compatible with DVB test content
>  - xHE-AAC decoder
> +- perlin source
>  
>  
>  version 7.0:
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 347103c04f..7af299b2a2 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -17290,6 +17290,9 @@ The command accepts the same syntax of the 
> corresponding option.
>  If the specified expression is not valid, it is kept at its current
>  value.
>  
> +@anchor{lutrgb}
> +@anchor{lutyuv}
> +@anchor{lut}
>  @section lut, lutrgb, lutyuv
>  
>  Compute a look-up table for binding each pixel component input value
> @@ -29281,6 +29284,103 @@ ffplay -f lavfi 
> life=s=300x200:mold=10:r=60:ratio=0.1:death_color=#C83232:life_c
>  @end example
>  @end itemize
>  
> +@section perlin
> +Generate Perlin noise.
> +
> +Perlin noise is a kind of noise with local continuity in space. This
> +can be used to generate patterns with continuity in space and time,
> +e.g. to simulate smoke, fluids, or terrain.
> +
> +In case more than one octave is specified through the @option{octaves}
> +option, Perlin noise is generated as a sum of components, each one
> +with doubled frequency. In this case the @option{persistence} option
> +specify the ratio of the amplitude with respect to the previous
> +component. More octave components enable to specify more high
> +frequency details in the generated noise (e.g. small size variations
> +due to bolders in a generated terrain).

Typo: s/bolders/boulders/

> +
> +@subsection Options
> +@table @option
> +
> +@item size, s
> +Specify the size (width and height) of the buffered video frames. For the
> +syntax of this option, check the
> +@ref{video size syntax,,"Video size" section in the ffmpeg-utils 
> manual,ffmpeg-utils}.
> +
> +@item rate, r
> +Specify the frame rate expected for the video stream, expressed as a
> +number of frames per second.
> +
> +@item octaves
> +Specify the total number of components making up the noise, each one
> +with doubled frequency.
> +
> +@item persistence
> +Set the ratio used to compute the amplitude of the next octave
> +component with respect to the previous component amplitude.
> +
> +@item xscale
> +@item yscale
> +Define a scale factor used to multiple the x, y coordinates. This can
> +be useful to define an effect with a pattern stretched along the x or
> +y axis.
> +
> +@item tscale
> +Define a scale factor used to multiple the time coordinate. This can
> +be useful to change the time variation speed.
> +
> +@item random_mode
> +Set random mode used to compute initial pattern.
> +
> +Supported values are:
> +@table @option
> +@item random
> +Compute and use random seed.
> +
> +@item ken
> +Use the predefined initial pattern defined by Ken Perlin in the
> +original article, can be useful to compare the output with other
> +sources.
> +
> +@item seed
> +Use the value specified by @option{random_seed} option.
> +@end table

Nit: "Define a...", "Use the..." etc. is redundant - remove them to
optimise for reading time.

> +
> +@item random_seed, seed
> +Use this value to compute the initial pattern, it is only considered
> +when @option{random_mode} is set to @var{random_seed}.
> +@end table

Nit: the reader needs to read the second clause before the first makes sense.
Consider something like:

When @option{random_mode} is set to @var{random_seed},
this value computes the initial pattern.

> +
> +@subsection Examples
> +@itemize
> +@item
> +Generate single component:
> +@example
> +perlin
> +@end example
> +
> +@item
> +Use Perlin noise with 7 components, each one with a halved contribute

s/contribute/contribution/

> +to total amplitude:
> +@example
> +perlin=octaves=7:persistence=0.5
> +@end example
> +
> +@item
> +Chain Perlin noise with the @ref{lutyuv} to generate a black&white
> +effect:
> +@example
> +perlin:octaves=7:tscale=0.3,lutyuv=y='if(lt(val\,128)\,255\,0)'
> +@end example
> +
> +@item
> +Stretch noise along the y axis, and convert

Re: [FFmpeg-devel] [PATCH] web: move 6.0 to olddownload

[Andrew Sayers]

On Thu, Jun 13, 2024 at 12:10:21PM +0200, Michael Niedermayer wrote:
> I see no users on https://trac.ffmpeg.org/wiki/Downstreams

I don't have a strong opinion about the move itself, but can that page
be linked from the Old Releases section?  Something like:

 Older versions are available at the Old
-  Releases page.
+  Releases page.  Releases are usually moved there after the last
+  https://trac.ffmpeg.org/wiki/Downstreams";>downstream
+  drops support.

A hint like that would help drive people to maintain the list, making your life
easier in future.  I haven't formatted the above as a proper patch because I
assume you'd want to choose the wording, but can do if that would be better.
___
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/2] libavcodec/amfenc: Update AMF encoder options

[Araz Iusubov]

Encoder options have been updated to the current version of the AMF.

Signed-off-by: Araz Iusubov 
---
 libavcodec/amfenc_av1.c  | 108 +++--
 libavcodec/amfenc_h264.c | 146 +--
 libavcodec/amfenc_hevc.c | 143 +-
 3 files changed, 259 insertions(+), 138 deletions(-)

diff --git a/libavcodec/amfenc_av1.c b/libavcodec/amfenc_av1.c
index 9f18aac648..d40c71cb33 100644
--- a/libavcodec/amfenc_av1.c
+++ b/libavcodec/amfenc_av1.c
@@ -25,15 +25,16 @@
 #define OFFSET(x) offsetof(AmfContext, x)
 #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
 static const AVOption options[] = {
-{ "usage",  "Set the encoding usage",   
OFFSET(usage),  AV_OPT_TYPE_INT,   {.i64 = 
AMF_VIDEO_ENCODER_AV1_USAGE_TRANSCODING }, 
AMF_VIDEO_ENCODER_AV1_USAGE_TRANSCODING, 
AMF_VIDEO_ENCODER_AV1_USAGE_LOW_LATENCY, VE, .unit = "usage" },
-{ "transcoding","", 0, AV_OPT_TYPE_CONST, {.i64 = 
AMF_VIDEO_ENCODER_AV1_USAGE_TRANSCODING }, 0, 0, VE, .unit = "usage" },
-{ "lowlatency", "", 0, AV_OPT_TYPE_CONST, {.i64 = 
AMF_VIDEO_ENCODER_AV1_USAGE_LOW_LATENCY }, 0, 0, VE, .unit = "usage" },
 
-{ "profile","Set the profile (default main)",   
OFFSET(profile),AV_OPT_TYPE_INT,{.i64 = 
AMF_VIDEO_ENCODER_AV1_PROFILE_MAIN }, AMF_VIDEO_ENCODER_AV1_PROFILE_MAIN, 
AMF_VIDEO_ENCODER_AV1_PROFILE_MAIN, VE, .unit = "profile" },
+{ "usage",  "Set the encoding usage",   
OFFSET(usage),  AV_OPT_TYPE_INT,   {.i64 = -1 }, -1, 
AMF_VIDEO_ENCODER_AV1_USAGE_LOW_LATENCY, VE, .unit = "usage" },
+{ "transcoding","Generic Transcoding",  0, 
AV_OPT_TYPE_CONST, {.i64 = AMF_VIDEO_ENCODER_AV1_USAGE_TRANSCODING  
 }, 0, 0, VE, .unit = "usage" },
+{ "lowlatency", "Low latency usecase",  0, 
AV_OPT_TYPE_CONST, {.i64 = AMF_VIDEO_ENCODER_AV1_USAGE_LOW_LATENCY  
 }, 0, 0, VE, .unit = "usage" },
+
+{ "profile","Set the profile",   OFFSET(profile),  
  AV_OPT_TYPE_INT,{.i64 = -1 }, -1, 
AMF_VIDEO_ENCODER_AV1_PROFILE_MAIN, VE, .unit = "profile" },
 { "main",   "", 0, AV_OPT_TYPE_CONST,{.i64 = 
AMF_VIDEO_ENCODER_AV1_PROFILE_MAIN }, 0, 0, VE, .unit = "profile" },
 
-{ "level",  "Set the encoding level (default auto)",
OFFSET(level),  AV_OPT_TYPE_INT,{.i64 = 0 }, 0, 
AMF_VIDEO_ENCODER_AV1_LEVEL_7_3, VE, .unit = "level" },
-{ "auto",   "", 0, AV_OPT_TYPE_CONST, {.i64 = 0
   }, 0, 0, VE, .unit = "level" },
+{ "level",  "Set the encoding level (default auto)",
OFFSET(level),  AV_OPT_TYPE_INT,{.i64 = -1 }, -1, 
AMF_VIDEO_ENCODER_AV1_LEVEL_7_3, VE, .unit = "level" },
+{ "auto",   "", 0, AV_OPT_TYPE_CONST, {.i64 = -1   
   }, 0, 0, VE, .unit = "level" },
 { "2.0","", 0, AV_OPT_TYPE_CONST, {.i64 = 
AMF_VIDEO_ENCODER_AV1_LEVEL_2_0 }, 0, 0, VE, .unit = "level" },
 { "2.1","", 0, AV_OPT_TYPE_CONST, {.i64 = 
AMF_VIDEO_ENCODER_AV1_LEVEL_2_1 }, 0, 0, VE, .unit = "level" },
 { "2.2","", 0, AV_OPT_TYPE_CONST, {.i64 = 
AMF_VIDEO_ENCODER_AV1_LEVEL_2_2 }, 0, 0, VE, .unit = "level" },
@@ -59,11 +60,12 @@ static const AVOption options[] = {
 { "7.2","", 0, AV_OPT_TYPE_CONST, {.i64 = 
AMF_VIDEO_ENCODER_AV1_LEVEL_7_2 }, 0, 0, VE, .unit = "level" },
 { "7.3","", 0, AV_OPT_TYPE_CONST, {.i64 = 
AMF_VIDEO_ENCODER_AV1_LEVEL_7_3 }, 0, 0, VE, .unit = "level" },
 
-{ "quality","Set the encoding quality", 
OFFSET(quality),AV_OPT_TYPE_INT,   {.i64 = 
AMF_VIDEO_ENCODER_AV1_QUALITY_PRESET_SPEED }, 
AMF_VIDEO_ENCODER_AV1_QUALITY_PRESET_HIGH_QUALITY, 
AMF_VIDEO_ENCODER_AV1_QUALITY_PRESET_SPEED, VE, .unit = "quality" },
+{ "quality","Set the encoding quality preset", 
OFFSET(quality), AV_OPT_TYPE_INT, {.i64 = -1 }, -1, 
AMF_VIDEO_ENCODER_AV1_QUALITY_PRESET_SPEED, VE, .unit = "quality" },
+{ "preset", "Set the encoding quality preset", 
OFFSET(quality), AV_OPT_TYPE_INT, {.i64 = -1 }, -1, 
AMF_VIDEO_ENCODER_AV1_QUALITY_PRESET_SPEED, VE, .unit = "quality" },
+{ "high_quality",   "", 0, AV_OPT_TYPE_CONST, {.i64 = 
AMF_VIDEO_ENCODER_AV1_QUALITY_PRESET_HIGH_QUALITY  }, 0, 0, VE, .unit = 
"quality" },
+{ "quality","", 0, AV_OPT_TYPE_CONST, {.i64 = 
AMF_VIDEO_ENCODER_AV1_QUALITY_PRESET_QUALITY   }, 0, 0, VE, .unit = 
"quality" },
 { "balanced",   "", 0, AV_OPT_TYPE_CONST, {.i64 = 
AMF_VIDEO_ENCODER_AV1_QUALITY_PRESET_BALANCED   

Re: [FFmpeg-devel] [PATCH] configure: remove false positives with valgrind-memcheck

[Pierre-Anthony Lemieux]

On Sun, Jun 9, 2024 at 9:00 AM Pierre-Anthony Lemieux  wrote:
>
> On Sun, Jun 9, 2024 at 6:41 AM James Almer  wrote:
> >
> > On 6/9/2024 2:56 AM, Pierre-Anthony Lemieux wrote:
> > > On Sat, Jun 8, 2024 at 6:13 PM James Almer  wrote:
> > >>
> > >> On 6/8/2024 9:59 PM, p...@sandflow.com wrote:
> > >>> From: Pierre-Anthony Lemieux 
> > >>>
> > >>> If  `--toolchain=valgrind-memcheck` is selected, fate-lavf-asf fails on 
> > >>> a false positive.
> > >>
> > >> I can't reproduce this. Tried with both --disable-optimizations and
> > >> without it, on Ubuntu 22.04 x86_64.
> > >> How are you getting these false positives?
> > >
> > > Command and log at https://pastebin.com/3TKk0RF4
> >
> > But that command is missing all the extra args configure adds to the
> > invocation, before and after your patch.

Quick note to check if I have addressed your comment.

>
> Full story.
>
> Before the proposed patch, "./configure --toolchain=valgrind-memcheck;
> make fate-lavf-asf" results in "Conditional jump or move depends on
> uninitialised value(s)" being emitted on my system (gcc (Ubuntu
> 9.4.0-1ubuntu1~20.04.1) 9.4.0).
>
> The proposed patch only adds  "--expensive-definedness-checks=yes" to
> the "valgrind-memcheck" command line -- this was the result of a
> discussion on the mailing list.
>
> After the proposed patch, "./configure --toolchain=valgrind-memcheck;
> make fate-lavf-asf" does not result in any error being emitted.
>
> The pastebin is intended to isolate the issue/solution. On my system,
> adding/removing "--expensive-definedness-checks=yes" to the command
> line removes/triggers the issue.
>
> Let me know if you need additional information.
>
> Thanks for reviewing.
>
> >
> > >
> > >>
> > >>> ---
> > >>>configure | 2 +-
> > >>>1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/configure b/configure
> > >>> index 6c5b8aab9a..c708f2e38c 100755
> > >>> --- a/configure
> > >>> +++ b/configure
> > >>> @@ -4571,7 +4571,7 @@ case "$toolchain" in
> > >>>target_exec_args="--tool=massif --alloc-fn=av_malloc 
> > >>> --alloc-fn=av_mallocz --alloc-fn=av_calloc 
> > >>> --alloc-fn=av_fast_padded_malloc --alloc-fn=av_fast_malloc 
> > >>> --alloc-fn=av_realloc_f --alloc-fn=av_fast_realloc 
> > >>> --alloc-fn=av_realloc"
> > >>>;;
> > >>>valgrind-memcheck)
> > >>> -target_exec_args="--error-exitcode=1 
> > >>> --malloc-fill=0x2a --track-origins=yes --leak-check=full 
> > >>> --gen-suppressions=all 
> > >>> --suppressions=$source_path/tests/fate-valgrind.supp"
> > >>> +target_exec_args="--error-exitcode=1 
> > >>> --expensive-definedness-checks=yes --malloc-fill=0x2a 
> > >>> --track-origins=yes --leak-check=full --gen-suppressions=all 
> > >>> --suppressions=$source_path/tests/fate-valgrind.supp"
> > >>>;;
> > >>>esac
> > >>>;;
> > >> ___
> > >> 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".
___
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] remove DEC Alpha DSP & support code

[Sean McGovern]

On Tue, Jun 11, 2024, 10:15 Vittorio Giovara 
wrote:

> On Tue, Jun 11, 2024 at 3:49 PM Michael Niedermayer <
> mich...@niedermayer.cc>
> wrote:
>
> > On Tue, Jun 11, 2024 at 02:26:37PM +0300, Rémi Denis-Courmont wrote:
> > >
> > >
> > > Le 11 juin 2024 12:59:23 GMT+03:00, Michael Niedermayer <
> > mich...@niedermayer.cc> a écrit :
> > > >On Mon, Jun 10, 2024 at 08:52:08PM -0400, Sean McGovern wrote:
> > > >[...]
> > > >> Are there any real concerns about the Alpha removal itself?
> > > >> People still wanting to use FFmpeg for hardware that old can stick
> > > >> with 7.0 (and fork it if they like -- that's the beauty of FOSS).
> > > >
> > > >Loosing security support, sounds not viable, so if alpha is removed
> > > >the question what that would do to users (aka performance and does it
> > > >work/build after the patchset) is still an open question ...
> > >
> > > What supported distribution would people even be getting security
> > support from? None of the mainstream distributions support Alpha anymore.
> > So if (generic) you care about security support that architecture simply
> > isn't viable, regardless of FFmpeg.
> > >
> >
> > > Also if security really is the concern, then using the supported plain
> C
> > code of FFmpeg seems safer than using unmaintained SIMD optimisations.
> >
> > security wise, the risk for something like alpha is generic
> > architecture unspecific attacks. The probability of an attack specific to
> > alpha SIMD is
> > very low even if there is an issue in that code, which in itself isnt
> that
> > likely
> > because its unlikely anyone will design an attack specific for ffmpeg
> SIMD
> > on alpha
> >
>
> Is there anyone actively vouching for this old arch? it's not the first
> time that stuff gets removed and this won't be the last.
> We should really be more proactive at removing cruft rather than dying on
> hills about omgsecurity and omgusers (within reason of course).
> --
> Vittorio
> ___
> 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".
>

Ping.

-- Sean McGovern

>
___
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] web: move 6.0 to olddownload

[James Almer]

On 6/13/2024 11:49 AM, James Almer wrote:

On 6/13/2024 7:10 AM, Michael Niedermayer wrote:

I see no users on https://trac.ffmpeg.org/wiki/Downstreams


Ubuntu 23.10 (non LTS) ships it, but it EOLs in one month, so wait until 
mid July to push this.


What you can move there are 3.4 and 4.1, since Debian Buster EOLs this 
month.

___
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/2] libavcodec/amfenc: Update AMF release version

[Araz Iusubov]

---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 8101b4fce6..23b140dc78 100755
--- a/configure
+++ b/configure
@@ -7364,7 +7364,7 @@ fi
 
 enabled amf &&
 check_cpp_condition amf "AMF/core/Version.h" \
-"(AMF_VERSION_MAJOR << 48 | AMF_VERSION_MINOR << 32 | 
AMF_VERSION_RELEASE << 16 | AMF_VERSION_BUILD_NUM) >= 0x00010004001d"
+"(AMF_VERSION_MAJOR << 48 | AMF_VERSION_MINOR << 32 | 
AMF_VERSION_RELEASE << 16 | AMF_VERSION_BUILD_NUM) >= 0x000100040021"
 
 # Funny iconv installations are not unusual, so check it after all flags have 
been set
 if enabled libc_iconv; then
-- 
2.43.0.windows.1

___
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] sh4: remove architecture

[Sean McGovern]

On Fri, Jun 7, 2024, 17:18 Sean McGovern  wrote:

> On Fri, Jun 7, 2024 at 2:20 PM Rémi Denis-Courmont 
> wrote:
> >
> > Support for SuperH was dropped over a decade ago. There no longer is any
> > architecture-specific code to be found, so just remove the corresponding
> > test. Technically it is still possible to compile FFmpeg as the
> > "generic" (pure C) architecture.
> > ---
> >  configure | 4 
> >  libavcodec/sh4/README | 6 --
> >  2 files changed, 10 deletions(-)
> >  delete mode 100644 libavcodec/sh4/README
> >
> > diff --git a/configure b/configure
> > index 6c5b8aab9a..efead4075a 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2146,7 +2146,6 @@ ARCH_LIST="
> >  ppc64
> >  riscv
> >  s390
> > -sh4
> >  sparc
> >  sparc64
> >  tilegx
> > @@ -5249,9 +5248,6 @@ case "$arch" in
> >  s390|s390x)
> >  arch="s390"
> >  ;;
> > -sh4|sh)
> > -arch="sh4"
> > -;;
> >  sun4*|sparc*)
> >  arch="sparc"
> >  ;;
> > diff --git a/libavcodec/sh4/README b/libavcodec/sh4/README
> > deleted file mode 100644
> > index 8dd61fe875..00
> > --- a/libavcodec/sh4/README
> > +++ /dev/null
> > @@ -1,6 +0,0 @@
> > -SH4 optimizations have been removed in
> > -commit d6096a67422534918405abb46dafbbac4608cbc3
> > -The last revission with the optimizations is
> cbfc9046e1c7e295b74f252902ae6f255eef4e78
> > -
> > -If you want to maintain these (or other) SH4 optimizations in ffmpeg,
> then please
> > -contact ffmpeg-devel@ffmpeg.org
> > --
> > 2.45.1
> >
> > ___
> > 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".
>
> Sure, OK.
>

Also ping.

-- Sean McGovern

>
___
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] configure: remove false positives with valgrind-memcheck

[James Almer]

On 6/13/2024 2:00 PM, Pierre-Anthony Lemieux wrote:

On Sun, Jun 9, 2024 at 9:00 AM Pierre-Anthony Lemieux  wrote:


On Sun, Jun 9, 2024 at 6:41 AM James Almer  wrote:


On 6/9/2024 2:56 AM, Pierre-Anthony Lemieux wrote:

On Sat, Jun 8, 2024 at 6:13 PM James Almer  wrote:


On 6/8/2024 9:59 PM, p...@sandflow.com wrote:

From: Pierre-Anthony Lemieux 

If  `--toolchain=valgrind-memcheck` is selected, fate-lavf-asf fails on a false 
positive.


I can't reproduce this. Tried with both --disable-optimizations and
without it, on Ubuntu 22.04 x86_64.
How are you getting these false positives?


Command and log at https://pastebin.com/3TKk0RF4


But that command is missing all the extra args configure adds to the
invocation, before and after your patch.


Quick note to check if I have addressed your comment.



Full story.

Before the proposed patch, "./configure --toolchain=valgrind-memcheck;
make fate-lavf-asf" results in "Conditional jump or move depends on
uninitialised value(s)" being emitted on my system (gcc (Ubuntu
9.4.0-1ubuntu1~20.04.1) 9.4.0).

The proposed patch only adds  "--expensive-definedness-checks=yes" to
the "valgrind-memcheck" command line -- this was the result of a
discussion on the mailing list.

After the proposed patch, "./configure --toolchain=valgrind-memcheck;
make fate-lavf-asf" does not result in any error being emitted.

The pastebin is intended to isolate the issue/solution. On my system,
adding/removing "--expensive-definedness-checks=yes" to the command
line removes/triggers the issue.

Let me know if you need additional information.

Thanks for reviewing.


I still can't reproduce this issue. Valgrind does not complain about 
this test at all for me no matter what settings do i use.


The name --expensive-definedness-checks=yes implies that Valgrind will 
do extra work that will slow the process even more than it already is. 
I'd like someone else's opinion about it (Andreas maybe, since he 
suggested this change).











---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 6c5b8aab9a..c708f2e38c 100755
--- a/configure
+++ b/configure
@@ -4571,7 +4571,7 @@ case "$toolchain" in
target_exec_args="--tool=massif --alloc-fn=av_malloc 
--alloc-fn=av_mallocz --alloc-fn=av_calloc --alloc-fn=av_fast_padded_malloc 
--alloc-fn=av_fast_malloc --alloc-fn=av_realloc_f --alloc-fn=av_fast_realloc 
--alloc-fn=av_realloc"
;;
valgrind-memcheck)
-target_exec_args="--error-exitcode=1 --malloc-fill=0x2a 
--track-origins=yes --leak-check=full --gen-suppressions=all 
--suppressions=$source_path/tests/fate-valgrind.supp"
+target_exec_args="--error-exitcode=1 
--expensive-definedness-checks=yes --malloc-fill=0x2a --track-origins=yes 
--leak-check=full --gen-suppressions=all 
--suppressions=$source_path/tests/fate-valgrind.supp"
;;
esac
;;

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

___
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] avcodec/jpeg2000dec: fix tilepart processing

[Pierre-Anthony Lemieux]

LGTM. Will merge over the weekend unless I hear otherwise.

On Thu, Jun 6, 2024 at 5:25 PM Osamu Watanabe
 wrote:
>
> From: Osamu Watanabe <65328111+osamu...@users.noreply.github.com>
>
> Fix http://trac.ffmpeg.org/ticket/10121
>
> Signed-off-by: Osamu Watanabe 
> ---
>  libavcodec/jpeg2000dec.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index d15502a527..091931b1ff 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -1005,6 +1005,7 @@ static inline void select_header(Jpeg2000DecoderContext 
> *s, const Jpeg2000Tile *
>  {
>  s->g = tile->tile_part[*tp_index].header_tpg;
>  if (bytestream2_get_bytes_left(&s->g) == 0 && s->bit_index == 8) {
> +av_log(s->avctx, AV_LOG_WARNING, "Packet header bytes in PPM marker 
> segment is too short.\n");
>  if (*tp_index < FF_ARRAY_ELEMS(tile->tile_part) - 1) {
>  s->g = tile->tile_part[++(*tp_index)].tpg;
>  }
> @@ -1014,10 +1015,18 @@ static inline void 
> select_header(Jpeg2000DecoderContext *s, const Jpeg2000Tile *
>  static inline void select_stream(Jpeg2000DecoderContext *s, const 
> Jpeg2000Tile *tile,
>   int *tp_index, const Jpeg2000CodingStyle 
> *codsty)
>  {
> +int32_t is_endof_tp;
> +
>  s->g = tile->tile_part[*tp_index].tpg;
> -if (bytestream2_get_bytes_left(&s->g) == 0 && s->bit_index == 8) {
> +is_endof_tp = bytestream2_get_bytes_left(&s->g) == 0 && s->bit_index == 
> 8;
> +// Following while loop is necessary because a tilepart may include only 
> SOD marker.
> +// Such a tilepart has neither packet header nor compressed data.
> +while (is_endof_tp) {
>  if (*tp_index < FF_ARRAY_ELEMS(tile->tile_part) - 1) {
>  s->g = tile->tile_part[++(*tp_index)].tpg;
> +is_endof_tp = bytestream2_get_bytes_left(&s->g) == 0 && 
> s->bit_index == 8;
> +} else {
> +is_endof_tp = 0;
>  }
>  }
>  if (codsty->csty & JPEG2000_CSTY_SOP) {
> --
> 2.34.1
>
___
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] web/download: Refer to trac downstreams page

[Michael Niedermayer]

From: Andrew Sayers 

Signed-off-by: Michael Niedermayer 
---
 src/download | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/download b/src/download
index 3ebf773..acef214 100644
--- a/src/download
+++ b/src/download
@@ -642,7 +642,9 @@ libpostproc53.  3.100
   Old Releases
   
 Older versions are available at the Old
-  Releases page.
+  Releases page. Releases are usually moved there after the last
+  https://trac.ffmpeg.org/wiki/Downstreams";>downstream
+  drops support.
   
   
 
-- 
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".

[FFmpeg-devel] [PATCHv6 3/4] checkasm/h263dsp: test dct_unquantize_{intra, inter}

[Rémi Denis-Courmont]

---
 tests/checkasm/h263dsp.c | 50 +++-
 1 file changed, 49 insertions(+), 1 deletion(-)

diff --git a/tests/checkasm/h263dsp.c b/tests/checkasm/h263dsp.c
index 2d0957a90b..69b303a6cc 100644
--- a/tests/checkasm/h263dsp.c
+++ b/tests/checkasm/h263dsp.c
@@ -18,13 +18,58 @@
  * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
  */
 
+#include 
 #include 
 
 #include "checkasm.h"
 
-#include "libavcodec/h263dsp.h"
+#include "libavutil/avassert.h"
 #include "libavutil/mem.h"
 #include "libavutil/mem_internal.h"
+#include "libavcodec/h263dsp.h"
+#include "libavcodec/mpegvideodata.h"
+
+static uint_fast8_t mpeg_qscale_rnd(void)
+{
+int n = rnd(), q = (n >> 1) & 31;
+
+if (n & 1)
+return ff_mpeg2_non_linear_qscale[q];
+else
+return q << 1;
+}
+
+typedef void (*unquantizer)(int16_t *, size_t, int, int);
+
+static void check_dct_unquantize(unquantizer func, const char *name)
+{
+#define LEN 64
+LOCAL_ALIGNED_16(int16_t, block0, [LEN]);
+LOCAL_ALIGNED_16(int16_t, block1, [LEN]);
+size_t len = 1 + (rnd() & (LEN - 1));
+const int qscale = mpeg_qscale_rnd();
+const int qmul = qscale << 1;
+const int qadd = (rnd() & 1) ? (qscale - 1) | 1 : 0;
+
+declare_func(void, int16_t *, size_t, int, int);
+
+for (size_t i = 0; i < LEN; i++) {
+int r = rnd();
+
+block1[i] = block0[i] = (r & 1) ? (r >> 1) : 0;
+}
+
+if (check_func(func, "h263dsp.dct_unquantize_%s", name)) {
+av_assert0(len <= LEN);
+call_ref(block0, len, qmul, qadd);
+call_new(block1, len, qmul, qadd);
+
+if (memcmp(block0, block1, len * sizeof (int16_t)))
+fail();
+
+bench_new(block1, LEN, qmul, qadd);
+}
+}
 
 typedef void (*filter)(uint8_t *src, int stride, int qscale);
 
@@ -56,6 +101,9 @@ void checkasm_check_h263dsp(void)
 H263DSPContext ctx;
 
 ff_h263dsp_init(&ctx);
+check_dct_unquantize(ctx.h263_dct_unquantize_intra, "intra");
+check_dct_unquantize(ctx.h263_dct_unquantize_inter, "inter");
+report("dct_unquantize");
 check_loop_filter('h', ctx.h263_h_loop_filter);
 check_loop_filter('v', ctx.h263_v_loop_filter);
 report("loop_filter");
-- 
2.45.1

___
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] [PATCHv6 4/4] lavc/h263dsp: R-V V dct_unquantize_{intra, inter}

[Rémi Denis-Courmont]

T-Head C908:
h263dsp.dct_unquantize_inter_c:   3.7
h263dsp.dct_unquantize_inter_rvv_i32: 1.7
h263dsp.dct_unquantize_intra_c:   4.0
h263dsp.dct_unquantize_intra_rvv_i32: 1.5

SpacemiT X60:
h263dsp.dct_unquantize_inter_c:   3.5
h263dsp.dct_unquantize_inter_rvv_i32: 1.2
h263dsp.dct_unquantize_intra_c:   3.5
h263dsp.dct_unquantize_intra_rvv_i32: 1.2
---
 libavcodec/riscv/h263dsp_init.c | 15 ---
 libavcodec/riscv/h263dsp_rvv.S  | 25 +
 2 files changed, 37 insertions(+), 3 deletions(-)

diff --git a/libavcodec/riscv/h263dsp_init.c b/libavcodec/riscv/h263dsp_init.c
index 21b536366c..5fb12f360b 100644
--- a/libavcodec/riscv/h263dsp_init.c
+++ b/libavcodec/riscv/h263dsp_init.c
@@ -25,6 +25,8 @@
 #include "libavutil/riscv/cpu.h"
 #include "libavcodec/h263dsp.h"
 
+void ff_h263_dct_unquantize_intra_rvv(int16_t *, size_t len, int, int);
+void ff_h263_dct_unquantize_inter_rvv(int16_t *, size_t len, int, int);
 void ff_h263_h_loop_filter_rvv(uint8_t *src, int stride, int q);
 void ff_h263_v_loop_filter_rvv(uint8_t *src, int stride, int q);
 
@@ -33,9 +35,16 @@ av_cold void ff_h263dsp_init_riscv(H263DSPContext *c)
 #if HAVE_RVV
 int flags = av_get_cpu_flags();
 
-if ((flags & AV_CPU_FLAG_RVV_I32) && ff_rv_vlen_least(128)) {
-c->h263_h_loop_filter = ff_h263_h_loop_filter_rvv;
-c->h263_v_loop_filter = ff_h263_v_loop_filter_rvv;
+if (flags & AV_CPU_FLAG_RVV_I32) {
+if (ff_rv_vlen_least(128) || (flags & AV_CPU_FLAG_RVB_ADDR)) {
+c->h263_dct_unquantize_intra = ff_h263_dct_unquantize_intra_rvv;
+c->h263_dct_unquantize_inter = ff_h263_dct_unquantize_inter_rvv;
+}
+
+if (ff_rv_vlen_least(128)) {
+c->h263_h_loop_filter = ff_h263_h_loop_filter_rvv;
+c->h263_v_loop_filter = ff_h263_v_loop_filter_rvv;
+}
 }
 #endif
 }
diff --git a/libavcodec/riscv/h263dsp_rvv.S b/libavcodec/riscv/h263dsp_rvv.S
index 97503d527c..3d6be8f58f 100644
--- a/libavcodec/riscv/h263dsp_rvv.S
+++ b/libavcodec/riscv/h263dsp_rvv.S
@@ -20,6 +20,31 @@
 
 #include "libavutil/riscv/asm.S"
 
+func ff_h263_dct_unquantize_intra_rvv, zve32x
+addia1, a1, -1
+addia0, a0, 2
+# fall through
+endfunc
+
+func ff_h263_dct_unquantize_inter_rvv, zve32x
+1:
+vsetvli  t0, a1, e16, m8, ta, mu
+vle16.v  v8, (a0)
+sub  a1, a1, t0
+vmv.v.x  v16, a3
+vmslt.vi v0, v8, 0
+vneg.v   v16, v16, v0.t
+vmsne.vi v0, v8, 0
+vmadd.vx v8, a2, v16, v0.t
+vse16.v  v8, (a0)
+#if defined(__riscv_v_min_vlen) && __riscv_v_min_vlen < 128
+sh1add   a0, t0, a0
+bnez a1, 1b
+#endif
+
+ret
+endfunc
+
 .option push
 .option norelax
 func ff_h263_h_loop_filter_rvv, zve32x
-- 
2.45.1

___
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] movenc: Add an option for hiding fragments at the end

[Dennis Sädtler via ffmpeg-devel]

On 2024-06-13 14:50, Martin Storsjö wrote:

On Wed, 5 Jun 2024, Martin Storsjö wrote:


This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)

This results in a file where the mdat atom contains (and hides)
all the moof atoms that were part of the fragmented file structure
initially.
---
v2: Made the flag implicitly set FF_MOV_FLAG_FRAGMENT (as it makes
no sense without it).

Updated the description of the flag to "Write a fragmented file that
is converted to non-fragmented at the end".

Kept the flag named "hide_fragments", but I'm also pondering if we
maybe should go for a name like "hybrid_fragmented" or so, as a
better description of _what_ it produces, as opposed to _how_ it
does things. (One could also consider "hybrid_mp4", but even if mp4
is the main thing, the same also goes for mov and a bunch of other
related formats.)


I'd otherwise want to push this, but I'm not entirely satisfied with 
the option name quite yet. I'm pondering if we should call it 
"hybrid_fragmented" - any opinions, Dennis or Timo?


// Martin


That seems fine to me, but I might be biased considering that's what I 
called it :P


~Dennis
___
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] checkasm/lls: add missing random values to the test buffers

[James Almer]

On 6/12/2024 8:53 AM, James Almer wrote:

Fixes valgrind warnings after 18adaf9fe558587cb1b707c647af83015b69da48.

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

diff --git a/tests/checkasm/lls.c b/tests/checkasm/lls.c
index b1db21cd56..d2dbc53f41 100644
--- a/tests/checkasm/lls.c
+++ b/tests/checkasm/lls.c
@@ -24,7 +24,7 @@
  do {   \
  double bmg[2], stddev = 10.0;  \
 \
-for (size_t i = 0; i < MAX_VARS; i += 2) { \
+for (size_t i = 0; i < MAX_VARS_ALIGN; i += 2) { \
  av_bmg_get(&checkasm_lfg, bmg);\
  buf[i] = bmg[0] * stddev;  \
  buf[i + 1] = bmg[1] * stddev;  \


Applied.
___
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 v4] area changed: scdet filter

[radu.taraibuta]

Update as discussed


0001-area-changed-scdet-filter.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] FFmpeg 5.1.5 and 4.3.7

[Michael Niedermayer]

On Thu, Jun 13, 2024 at 12:14:54PM +0200, Michael Niedermayer wrote:
> Hi all
> 
> I intend to make 5.1.5 and 4.3.7 releases "soon"(1) for debian
> 
> If you want something backported, now is your last chance to backport it
> 
> thx
> 
> (1) i still have more things to backport and somethings i need to fix in
> my local setup, so it will take me a few days probably

i intend to do the 5.1.5 release tomorrow

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


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 v2] movenc: Add an option for hiding fragments at the end

[Martin Storsjö]

On Thu, 13 Jun 2024, Gyan Doshi wrote:


On 2024-06-13 06:20 pm, Martin Storsjö wrote:

On Wed, 5 Jun 2024, Martin Storsjö wrote:


This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)

This results in a file where the mdat atom contains (and hides)
all the moof atoms that were part of the fragmented file structure
initially.
---
v2: Made the flag implicitly set FF_MOV_FLAG_FRAGMENT (as it makes
no sense without it).

Updated the description of the flag to "Write a fragmented file that
is converted to non-fragmented at the end".

Kept the flag named "hide_fragments", but I'm also pondering if we
maybe should go for a name like "hybrid_fragmented" or so, as a
better description of _what_ it produces, as opposed to _how_ it
does things. (One could also consider "hybrid_mp4", but even if mp4
is the main thing, the same also goes for mov and a bunch of other
related formats.)


I'd otherwise want to push this, but I'm not entirely satisfied with 
the option name quite yet. I'm pondering if we should call it 
"hybrid_fragmented" - any opinions, Dennis or Timo?


How about `resilient_mode` or `recoverable`?
I agree that the how is secondary.


Those are good suggestions as well - but I think I prefer 
"hybrid_fragmented" still.


In theory, I guess one could implement resilient writing in a number of 
different ways, whereas the hybrid fragmented/non-fragmented only is one.


So with a couple other voices agreeing with the name "hybrid_fragmented", 
I'll post a new patch with the option in that form - hopefully you don't 
object to it.


// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 25/57] avcodec/me_cmp, motion_est: Sanitize permissible cmp_funcs

[Michael Niedermayer]

On Thu, Jun 13, 2024 at 11:37:13AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Wed, Jun 12, 2024 at 03:48:21PM +0200, Andreas Rheinhardt wrote:
> >> Several of the potential choices of comparison functions
> >> need an initialized MpegEncContext (initialized for encoding,
> >> not only ff_mpv_common_init()) or they crash when called.
> >> Modify ff_set_cmp() to check for this.
> >>
> >> Signed-off-by: Andreas Rheinhardt 
> >> ---
> > 
> > I dont think they always crashed, so to me marking these as
> > unsupported now feels a bit strange. But it shows we where lacking
> > testing
> 
> Why don't you just try:
> for codec in svq1 snow; do for cmp in dct psnr bit rd dctmax 14; do
> ./ffmpeg_g -hide_banner -filter_complex nullsrc -c:v "$codec" -cmp
> "$cmp" -f null -; done; done
> yourself?

I did misread your patch, i thought you where disabling them for all
cases. Yes svq1 & snow probably didnt work with them

thx

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

Into a blind darkness they enter who follow after the Ignorance,
they as if into a greater darkness enter who devote themselves
to the Knowledge alone. -- Isha Upanishad


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] remove DEC Alpha DSP & support code

[Vittorio Giovara]

On Thu, Jun 13, 2024 at 6:32 PM Sean McGovern  wrote:

> On Tue, Jun 11, 2024, 10:15 Vittorio Giovara 
> wrote:
>
> > On Tue, Jun 11, 2024 at 3:49 PM Michael Niedermayer <
> > mich...@niedermayer.cc>
> > wrote:
> >
> > > On Tue, Jun 11, 2024 at 02:26:37PM +0300, Rémi Denis-Courmont wrote:
> > > >
> > > >
> > > > Le 11 juin 2024 12:59:23 GMT+03:00, Michael Niedermayer <
> > > mich...@niedermayer.cc> a écrit :
> > > > >On Mon, Jun 10, 2024 at 08:52:08PM -0400, Sean McGovern wrote:
> > > > >[...]
> > > > >> Are there any real concerns about the Alpha removal itself?
> > > > >> People still wanting to use FFmpeg for hardware that old can stick
> > > > >> with 7.0 (and fork it if they like -- that's the beauty of FOSS).
> > > > >
> > > > >Loosing security support, sounds not viable, so if alpha is removed
> > > > >the question what that would do to users (aka performance and does
> it
> > > > >work/build after the patchset) is still an open question ...
> > > >
> > > > What supported distribution would people even be getting security
> > > support from? None of the mainstream distributions support Alpha
> anymore.
> > > So if (generic) you care about security support that architecture
> simply
> > > isn't viable, regardless of FFmpeg.
> > > >
> > >
> > > > Also if security really is the concern, then using the supported
> plain
> > C
> > > code of FFmpeg seems safer than using unmaintained SIMD optimisations.
> > >
> > > security wise, the risk for something like alpha is generic
> > > architecture unspecific attacks. The probability of an attack specific
> to
> > > alpha SIMD is
> > > very low even if there is an issue in that code, which in itself isnt
> > that
> > > likely
> > > because its unlikely anyone will design an attack specific for ffmpeg
> > SIMD
> > > on alpha
> > >
> >
> > Is there anyone actively vouching for this old arch? it's not the first
> > time that stuff gets removed and this won't be the last.
> > We should really be more proactive at removing cruft rather than dying on
> > hills about omgsecurity and omgusers (within reason of course).
> > --
> > Vittorio
> > ___
> > 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".
> >
>
> Ping.
>
> -- Sean McGovern
>

Pushed, thanks.
-- 
Vittorio
___
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] [PATCHv5 1/4] lavc/h263dsp: add DCT dequantisation functions

[Rémi Denis-Courmont]

Le torstaina 13. kesäkuuta 2024, 5.23.12 EEST Andreas Rheinhardt a écrit :
> Rémi Denis-Courmont:
> > Note that optimised implementations of these functions will be taken
> > into actual use only if MpegEncContext.dct_unquantize_h263_{inter,intra}
> > are *not* overloaded by existing optimisations.
> > 
> > ---
> > This adds the plus ones back, saving two branch instructions in C and
> > one in assembler (at the cost of two unconditional adds).
> 
> I don't see how this saves branch instructions:

You can compare versions 4 and 5. The C had the extra if() that you complained 
about and the assembler had an explicit extra branch.

That being said, if someone wants to microoptimise the C version of DSP 
function, there are much greater and much less debatable savings to be had 
elsewhere - for instance adding missing restrict keywords (I don't mean in 
this particular case).

The point of this patchset is not to optimise the C code, rather to enable 
checkasm and avoid copying the same scalar prologues in RVV and SSE2.

> It seems to me that your intra assembly simply ignores [that] len -1 is
> allowed to be 0.

> If you were to check for the case of nCoeffs == 0 in
> dct_unquantize_h263_intra_c (before the call!), you could write assembly
> with this restriction in mind.

If it really is a common case worth optimising for, then indeed it could be 
checked in the common C calling code. But that is not a call that I can 
credibly make, and is outside the scope of this MR. If someone has data to 
back that optimisation, they are welcome to submit it as a separate patch.

The assembler works fine with 0 length. The only assumption is that the length 
is the actual and unsigned length.

> It would also allow the compiler to avoid
> the branch in case it is known that nCoeffs == 63.

-- 
Rémi Denis-Courmont
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".

Re: [FFmpeg-devel] [PATCH 33/57] avcodec/mpv_reconstruct_mb_template: Don't unnecessarily copy data

[Michael Niedermayer]

On Thu, Jun 13, 2024 at 10:50:36AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Wed, Jun 12, 2024 at 03:48:29PM +0200, Andreas Rheinhardt wrote:
> >> There is no reason to use a temporary buffer as destination
> >> for the new macroblock before copying it into its proper place.
> >>
> >> (History: 3994623df2efd2749631c3492184dd8d4ffa9d1b changed
> >> the precursor of ff_mpv_reconstruct_mb() to always decode
> >> to the first row of macroblocks for B pictures when
> >> a draw_horiz_band callback is set (they are exported to the caller
> >> via said callback and each row overwrites the previously decoded
> >> row; this was probably intended as a cache-optimization).
> >> Later b68ab2609c67d07b6f12ed65125d76bf9a054479 changed this
> >> to the current form in which a scratchpad buffer is used when
> >> decoding B-pictures without draw_horiz_band callback, followed
> >> by copying the block from the scratchpad buffer to the actual
> >> destination. I do not know what the aim of this was. When thinking
> >> of it as a cache optimization, it makes sense to not use it
> >> when the aforementioned draw_horiz_band optimization is in effect,
> >> because then the destination row can be presumed to be hot
> >> already. But then it makes no sense to restrict this optimization
> >> to B-frames.)
> > 
> > IIRC
> > The B frames where directly placed in GPU memory, which is slow to read
> > from, so building up MC + IDCT (which could read depending on caches)
> > was avoided by a a scratchpad but its really long ago so i might remember
> > this only partly
> > 
> 
> The code here is not executed for hardware acceleration at all. For the
> ordinary case, this copy incurs overhead; furthermore it increases
> complexity (and for these reasons no other codec has similar code). So
> I'd like to remove it (with an amended commit message that says that
> this was done due to concerns about reading from GPU memory). Do you
> object to this?

i dont object, i was trying to explain why this was there. This predates
modern hw acceleration. The memory in AVFrame.data[] for a normal
pixel format can be mapped to GPU memory. FFmpeg itself probably did not
set it up this way but some applications did do this with get_buffer()
callbacks VERY long ago IIRC to avoid having to copy the image later
when the application belived the image would not be read from. (like a B frame
in MPEG-2 times)

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The day soldiers stop bringing you their problems is the day you have stopped 
leading them. They have either lost confidence that you can help or concluded 
you do not care. Either case is a failure of leadership. - Colin Powell


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] avutil: rename av_mod_uintp2 to av_zero_extend

[James Almer]

On 6/11/2024 5:26 PM, Andreas Rheinhardt wrote:

James Almer:

It's more descriptive of what it does.

Signed-off-by: James Almer 
---
  libavutil/common.h  | 16 +++-
  libavutil/version.h |  1 +
  libavutil/x86/intmath.h |  6 +++---
  3 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/libavutil/common.h b/libavutil/common.h
index 3e4c339893..acd041fb67 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -42,6 +42,7 @@
  #include "attributes.h"
  #include "error.h"
  #include "macros.h"
+#include "version.h"
  
  #ifdef HAVE_AV_CONFIG_H

  #   include "config.h"
@@ -122,9 +123,11 @@
  #ifndef av_clip_uintp2
  #   define av_clip_uintp2   av_clip_uintp2_c
  #endif
+#if FF_API_MOD_UINTP2
  #ifndef av_mod_uintp2
  #   define av_mod_uintp2av_mod_uintp2_c
  #endif
+#endif


For the record: This patch on its own will disable the x86 optimization
in this patch, only to be restored in #3.


  #ifndef av_sat_add32
  #   define av_sat_add32 av_sat_add32_c
  #endif
@@ -149,6 +152,9 @@
  #ifndef av_clipd
  #   define av_clipd av_clipd_c
  #endif
+#ifndef av_zero_extend
+#   define av_zero_extend   av_zero_extend_c
+#endif
  #ifndef av_popcount
  #   define av_popcount  av_popcount_c
  #endif
@@ -288,11 +294,19 @@ static av_always_inline av_const unsigned 
av_clip_uintp2_c(int a, int p)
   * @param  p bit position to clip at
   * @return clipped value
   */
-static av_always_inline av_const unsigned av_mod_uintp2_c(unsigned a, unsigned 
p)
+static av_always_inline av_const unsigned av_zero_extend_c(unsigned a, 
unsigned p)
  {
  return a & ((1U << p) - 1);
  }
  
+#if FF_API_MOD_UINTP2

+attribute_deprecated
+static av_always_inline av_const unsigned av_mod_uintp2_c(unsigned a, unsigned 
p)
+{
+return av_zero_extend_c(a, p);
+}
+#endif
+
  /**
   * Add two signed 32-bit values with saturation.
   *
diff --git a/libavutil/version.h b/libavutil/version.h
index 9d08d56884..38456affb8 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -112,6 +112,7 @@
  #define FF_API_PALETTE_HAS_CHANGED  (LIBAVUTIL_VERSION_MAJOR < 60)
  #define FF_API_VULKAN_CONTIGUOUS_MEMORY (LIBAVUTIL_VERSION_MAJOR < 60)
  #define FF_API_H274_FILM_GRAIN_VCS  (LIBAVUTIL_VERSION_MAJOR < 60)
+#define FF_API_MOD_UINTP2   (LIBAVUTIL_VERSION_MAJOR < 60)
  
  /**

   * @}
diff --git a/libavutil/x86/intmath.h b/libavutil/x86/intmath.h
index 8a6b5ae261..821a06ab66 100644
--- a/libavutil/x86/intmath.h
+++ b/libavutil/x86/intmath.h
@@ -82,13 +82,13 @@ static av_always_inline av_const int ff_ctzll_x86(long long 
v)
  #if defined(__BMI2__)
  
  #if AV_GCC_VERSION_AT_LEAST(5,1)

-#define av_mod_uintp2 __builtin_ia32_bzhi_si
+#define av_zero_extend __builtin_ia32_bzhi_si
  #elif HAVE_INLINE_ASM
  /* GCC releases before 5.1.0 have a broken bzhi builtin, so for those we
   * implement it using inline assembly
   */
-#define av_mod_uintp2 av_mod_uintp2_bmi2
-static av_always_inline av_const unsigned av_mod_uintp2_bmi2(unsigned a, 
unsigned p)
+#define av_zero_extend av_zero_extend_bmi2
+static av_always_inline av_const unsigned av_zero_extend_bmi2(unsigned a, 
unsigned p)
  {
  if (av_builtin_constant_p(p))
  return a & ((1 << p) - 1);


Missing APIchanges and version bump.


Will add both and push the set soon.
___
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] web/download: Refer to trac downstreams page

[Andrew Sayers]

On Thu, Jun 13, 2024 at 09:39:34PM +0200, Michael Niedermayer wrote:
> From: Andrew Sayers 
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  src/download | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/download b/src/download
> index 3ebf773..acef214 100644
> --- a/src/download
> +++ b/src/download
> @@ -642,7 +642,9 @@ libpostproc53.  3.100
>Old Releases
>
>  Older versions are available at the Old
> -  Releases page.
> +  Releases page. Releases are usually moved there after the last
> +  https://trac.ffmpeg.org/wiki/Downstreams";>downstream
> +  drops support.
>
>
>  
> -- 
> 2.45.2

Thanks :)
___
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] rtp enc/dec update for vvc

[ftaft2000]

Signed-off-by: shiqifeng 
---
 .gitignore |   1 +
 configure  |   4 +
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libvvenc.c  | 566 +
 libavformat/Makefile   |   1 +
 libavformat/rtpdec.c   |   1 +
 libavformat/rtpdec_formats.h   |   1 +
 libavformat/rtpdec_vvc.c   | 349 
 libavformat/rtpenc.c   |   2 +
 libavformat/rtpenc_h264_hevc.c |  94 +-
 libavformat/sdp.c  | 182 +++
 12 files changed, 1197 insertions(+), 6 deletions(-)
 create mode 100644 libavcodec/libvvenc.c
 create mode 100644 libavformat/rtpdec_vvc.c

diff --git a/.gitignore b/.gitignore
index e810d11107..d7441a6cdc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,3 +41,4 @@
 /src
 /mapfile
 /tools/python/__pycache__/
+/build
\ No newline at end of file
diff --git a/configure b/configure
index 83284427df..d331688eb4 100755
--- a/configure
+++ b/configure
@@ -296,6 +296,7 @@ External library support:
   --enable-libwebp enable WebP encoding via libwebp [no]
   --enable-libx264 enable H.264 encoding via x264 [no]
   --enable-libx265 enable HEVC encoding via x265 [no]
+  --enable-libvvencenable H.266/VVC encoding via vvenc [no]
   --enable-libxeve enable EVC encoding via libxeve [no]
   --enable-libxevd enable EVC decoding via libxevd [no]
   --enable-libxavs enable AVS encoding via xavs [no]
@@ -1867,6 +1868,7 @@ EXTERNAL_LIBRARY_GPL_LIST="
 libvidstab
 libx264
 libx265
+libvvenc
 libxavs
 libxavs2
 libxvid
@@ -3569,6 +3571,7 @@ libx264rgb_encoder_deps="libx264"
 libx264rgb_encoder_select="libx264_encoder"
 libx265_encoder_deps="libx265"
 libx265_encoder_select="atsc_a53 dovi_rpuenc"
+libvvenc_encoder_deps="libvvenc"
 libxavs_encoder_deps="libxavs"
 libxavs2_encoder_deps="libxavs2"
 libxevd_decoder_deps="libxevd"
@@ -7041,6 +7044,7 @@ enabled libx264   && require_pkg_config 
libx264 x264 "stdint.h x264.h" x
  check_cpp_condition libx262 x264.h 
"X264_MPEG2"
 enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
  require_cpp_condition libx265 x265.h 
"X265_BUILD >= 89"
+enabled libvvenc  && require_pkg_config libvvenc "libvvenc >= 
1.6.1" "vvenc/vvenc.h" vvenc_get_version
 enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
 enabled libxavs2  && require_pkg_config libxavs2 "xavs2 >= 
1.3.0" "stdint.h xavs2.h" xavs2_api_get
 enabled libxevd   && require_pkg_config libxevd "xevd >= 
0.4.1" "xevd.h" xevd_decode

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 1a44352906..2e98e1c72f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1155,6 +1155,7 @@ OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER)   += 
libwebpenc_common.o libwebpenc_anim

 OBJS-$(CONFIG_LIBX262_ENCODER)+= libx264.o
 OBJS-$(CONFIG_LIBX264_ENCODER)+= libx264.o
 OBJS-$(CONFIG_LIBX265_ENCODER)+= libx265.o
+OBJS-$(CONFIG_LIBVVENC_ENCODER)   += libvvenc.o
 OBJS-$(CONFIG_LIBXAVS_ENCODER)+= libxavs.o
 OBJS-$(CONFIG_LIBXAVS2_ENCODER)   += libxavs2.o
 OBJS-$(CONFIG_LIBXEVD_DECODER)+= libxevd.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b102a8069e..7650abebe4 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -807,6 +807,7 @@ extern const FFCodec ff_libx262_encoder;
 extern const FFCodec ff_libx264_encoder;
 extern const FFCodec ff_libx264rgb_encoder;
 extern FFCodec ff_libx265_encoder;
+extern const FFCodec ff_libvvenc_encoder;
 extern const FFCodec ff_libxeve_encoder;
 extern const FFCodec ff_libxevd_decoder;
 extern const FFCodec ff_libxavs_encoder;
diff --git a/libavcodec/libvvenc.c b/libavcodec/libvvenc.c
new file mode 100644
index 00..78d4f55a2a
--- /dev/null
+++ b/libavcodec/libvvenc.c
@@ -0,0 +1,566 @@
+/*
+ * H.266 encoding using the VVenC library
+ *
+ * Copyright (C) 2022, Thomas Siedel
+ *
+ * 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 "config_

[FFmpeg-devel] [PATCH] rtp enc/dec update for vvc

[ftaft2000]

Signed-off-by: ftaft2000 
---
 .gitignore |   1 +
 configure  |   4 +
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libvvenc.c  | 566 +
 libavformat/Makefile   |   1 +
 libavformat/rtpdec.c   |   1 +
 libavformat/rtpdec_formats.h   |   1 +
 libavformat/rtpdec_vvc.c   | 349 
 libavformat/rtpenc.c   |   2 +
 libavformat/rtpenc_h264_hevc.c |  94 +-
 libavformat/sdp.c  | 182 +++
 12 files changed, 1197 insertions(+), 6 deletions(-)
 create mode 100644 libavcodec/libvvenc.c
 create mode 100644 libavformat/rtpdec_vvc.c

diff --git a/.gitignore b/.gitignore
index e810d11107..d7441a6cdc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,3 +41,4 @@
 /src
 /mapfile
 /tools/python/__pycache__/
+/build
\ No newline at end of file
diff --git a/configure b/configure
index 83284427df..d331688eb4 100755
--- a/configure
+++ b/configure
@@ -296,6 +296,7 @@ External library support:
   --enable-libwebp enable WebP encoding via libwebp [no]
   --enable-libx264 enable H.264 encoding via x264 [no]
   --enable-libx265 enable HEVC encoding via x265 [no]
+  --enable-libvvencenable H.266/VVC encoding via vvenc [no]
   --enable-libxeve enable EVC encoding via libxeve [no]
   --enable-libxevd enable EVC decoding via libxevd [no]
   --enable-libxavs enable AVS encoding via xavs [no]
@@ -1867,6 +1868,7 @@ EXTERNAL_LIBRARY_GPL_LIST="
 libvidstab
 libx264
 libx265
+libvvenc
 libxavs
 libxavs2
 libxvid
@@ -3569,6 +3571,7 @@ libx264rgb_encoder_deps="libx264"
 libx264rgb_encoder_select="libx264_encoder"
 libx265_encoder_deps="libx265"
 libx265_encoder_select="atsc_a53 dovi_rpuenc"
+libvvenc_encoder_deps="libvvenc"
 libxavs_encoder_deps="libxavs"
 libxavs2_encoder_deps="libxavs2"
 libxevd_decoder_deps="libxevd"
@@ -7041,6 +7044,7 @@ enabled libx264   && require_pkg_config 
libx264 x264 "stdint.h x264.h" x
  check_cpp_condition libx262 x264.h 
"X264_MPEG2"
 enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
  require_cpp_condition libx265 x265.h 
"X265_BUILD >= 89"
+enabled libvvenc  && require_pkg_config libvvenc "libvvenc >= 
1.6.1" "vvenc/vvenc.h" vvenc_get_version
 enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
 enabled libxavs2  && require_pkg_config libxavs2 "xavs2 >= 
1.3.0" "stdint.h xavs2.h" xavs2_api_get
 enabled libxevd   && require_pkg_config libxevd "xevd >= 
0.4.1" "xevd.h" xevd_decode

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 1a44352906..2e98e1c72f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1155,6 +1155,7 @@ OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER)   += 
libwebpenc_common.o libwebpenc_anim

 OBJS-$(CONFIG_LIBX262_ENCODER)+= libx264.o
 OBJS-$(CONFIG_LIBX264_ENCODER)+= libx264.o
 OBJS-$(CONFIG_LIBX265_ENCODER)+= libx265.o
+OBJS-$(CONFIG_LIBVVENC_ENCODER)   += libvvenc.o
 OBJS-$(CONFIG_LIBXAVS_ENCODER)+= libxavs.o
 OBJS-$(CONFIG_LIBXAVS2_ENCODER)   += libxavs2.o
 OBJS-$(CONFIG_LIBXEVD_DECODER)+= libxevd.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b102a8069e..7650abebe4 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -807,6 +807,7 @@ extern const FFCodec ff_libx262_encoder;
 extern const FFCodec ff_libx264_encoder;
 extern const FFCodec ff_libx264rgb_encoder;
 extern FFCodec ff_libx265_encoder;
+extern const FFCodec ff_libvvenc_encoder;
 extern const FFCodec ff_libxeve_encoder;
 extern const FFCodec ff_libxevd_decoder;
 extern const FFCodec ff_libxavs_encoder;
diff --git a/libavcodec/libvvenc.c b/libavcodec/libvvenc.c
new file mode 100644
index 00..78d4f55a2a
--- /dev/null
+++ b/libavcodec/libvvenc.c
@@ -0,0 +1,566 @@
+/*
+ * H.266 encoding using the VVenC library
+ *
+ * Copyright (C) 2022, Thomas Siedel
+ *
+ * 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 "config_

[FFmpeg-devel] [PATCH] rtp enc/dec update for vvc

[Robin shi]

Signed-off-by: ftaft2000 
---
  .gitignore |   1 +
  configure  |   4 +
  libavcodec/Makefile|   1 +
  libavcodec/allcodecs.c |   1 +
  libavcodec/libvvenc.c  | 566 +
  libavformat/Makefile   |   1 +
  libavformat/rtpdec.c   |   1 +
  libavformat/rtpdec_formats.h   |   1 +
  libavformat/rtpdec_vvc.c   | 349 
  libavformat/rtpenc.c   |   2 +
  libavformat/rtpenc_h264_hevc.c |  94 +-
  libavformat/sdp.c  | 182 +++
  12 files changed, 1197 insertions(+), 6 deletions(-)
  create mode 100644 libavcodec/libvvenc.c
  create mode 100644 libavformat/rtpdec_vvc.c

diff --git a/.gitignore b/.gitignore
index e810d11107..d7441a6cdc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,3 +41,4 @@
  /src
  /mapfile
  /tools/python/__pycache__/
+/build
\ No newline at end of file
diff --git a/configure b/configure
index 83284427df..d331688eb4 100755
--- a/configure
+++ b/configure
@@ -296,6 +296,7 @@ External library support:
--enable-libwebp enable WebP encoding via libwebp [no]
--enable-libx264 enable H.264 encoding via x264 [no]
--enable-libx265 enable HEVC encoding via x265 [no]
+  --enable-libvvencenable H.266/VVC encoding via vvenc [no]
--enable-libxeve enable EVC encoding via libxeve [no]
--enable-libxevd enable EVC decoding via libxevd [no]
--enable-libxavs enable AVS encoding via xavs [no]
@@ -1867,6 +1868,7 @@ EXTERNAL_LIBRARY_GPL_LIST="
  libvidstab
  libx264
  libx265
+libvvenc
  libxavs
  libxavs2
  libxvid
@@ -3569,6 +3571,7 @@ libx264rgb_encoder_deps="libx264"
  libx264rgb_encoder_select="libx264_encoder"
  libx265_encoder_deps="libx265"
  libx265_encoder_select="atsc_a53 dovi_rpuenc"
+libvvenc_encoder_deps="libvvenc"
  libxavs_encoder_deps="libxavs"
  libxavs2_encoder_deps="libxavs2"
  libxevd_decoder_deps="libxevd"
@@ -7041,6 +7044,7 @@ enabled libx264   && require_pkg_config
libx264 x264 "stdint.h x264.h" x
   check_cpp_condition libx262 x264.h
"X264_MPEG2"
  enabled libx265   && require_pkg_config libx265 x265 x265.h
x265_api_get &&
   require_cpp_condition libx265 x265.h
"X265_BUILD >= 89"
+enabled libvvenc  && require_pkg_config libvvenc "libvvenc >=
1.6.1" "vvenc/vvenc.h" vvenc_get_version
  enabled libxavs   && require libxavs "stdint.h xavs.h"
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
  enabled libxavs2  && require_pkg_config libxavs2 "xavs2 >=
1.3.0" "stdint.h xavs2.h" xavs2_api_get
  enabled libxevd   && require_pkg_config libxevd "xevd >=
0.4.1" "xevd.h" xevd_decode
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 1a44352906..2e98e1c72f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1155,6 +1155,7 @@ OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER)   +=
libwebpenc_common.o libwebpenc_anim
  OBJS-$(CONFIG_LIBX262_ENCODER)+= libx264.o
  OBJS-$(CONFIG_LIBX264_ENCODER)+= libx264.o
  OBJS-$(CONFIG_LIBX265_ENCODER)+= libx265.o
+OBJS-$(CONFIG_LIBVVENC_ENCODER)   += libvvenc.o
  OBJS-$(CONFIG_LIBXAVS_ENCODER)+= libxavs.o
  OBJS-$(CONFIG_LIBXAVS2_ENCODER)   += libxavs2.o
  OBJS-$(CONFIG_LIBXEVD_DECODER)+= libxevd.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b102a8069e..7650abebe4 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -807,6 +807,7 @@ extern const FFCodec ff_libx262_encoder;
  extern const FFCodec ff_libx264_encoder;
  extern const FFCodec ff_libx264rgb_encoder;
  extern FFCodec ff_libx265_encoder;
+extern const FFCodec ff_libvvenc_encoder;
  extern const FFCodec ff_libxeve_encoder;
  extern const FFCodec ff_libxevd_decoder;
  extern const FFCodec ff_libxavs_encoder;
diff --git a/libavcodec/libvvenc.c b/libavcodec/libvvenc.c
new file mode 100644
index 00..78d4f55a2a
--- /dev/null
+++ b/libavcodec/libvvenc.c
@@ -0,0 +1,566 @@
+/*
+ * H.266 encoding using the VVenC library
+ *
+ * Copyright (C) 2022, Thomas Siedel
+ *
+ * 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

[FFmpeg-devel] [PATCH] rtp enc/dec update for vvc

[Robin shi]

Signed-off-by: ftaft2000 
---
 .gitignore |   1 +
 configure  |   4 +
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libvvenc.c  | 566 +
 libavformat/Makefile   |   1 +
 libavformat/rtpdec.c   |   1 +
 libavformat/rtpdec_formats.h   |   1 +
 libavformat/rtpdec_vvc.c   | 349 
 libavformat/rtpenc.c   |   2 +
 libavformat/rtpenc_h264_hevc.c |  94 +-
 libavformat/sdp.c  | 182 +++
 12 files changed, 1197 insertions(+), 6 deletions(-)
 create mode 100644 libavcodec/libvvenc.c
 create mode 100644 libavformat/rtpdec_vvc.c

diff --git a/.gitignore b/.gitignore
index e810d11107..d7441a6cdc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,3 +41,4 @@
 /src
 /mapfile
 /tools/python/__pycache__/
+/build
\ No newline at end of file
diff --git a/configure b/configure
index 83284427df..d331688eb4 100755
--- a/configure
+++ b/configure
@@ -296,6 +296,7 @@ External library support:
   --enable-libwebp enable WebP encoding via libwebp [no]
   --enable-libx264 enable H.264 encoding via x264 [no]
   --enable-libx265 enable HEVC encoding via x265 [no]
+  --enable-libvvencenable H.266/VVC encoding via vvenc [no]
   --enable-libxeve enable EVC encoding via libxeve [no]
   --enable-libxevd enable EVC decoding via libxevd [no]
   --enable-libxavs enable AVS encoding via xavs [no]
@@ -1867,6 +1868,7 @@ EXTERNAL_LIBRARY_GPL_LIST="
 libvidstab
 libx264
 libx265
+libvvenc
 libxavs
 libxavs2
 libxvid
@@ -3569,6 +3571,7 @@ libx264rgb_encoder_deps="libx264"
 libx264rgb_encoder_select="libx264_encoder"
 libx265_encoder_deps="libx265"
 libx265_encoder_select="atsc_a53 dovi_rpuenc"
+libvvenc_encoder_deps="libvvenc"
 libxavs_encoder_deps="libxavs"
 libxavs2_encoder_deps="libxavs2"
 libxevd_decoder_deps="libxevd"
@@ -7041,6 +7044,7 @@ enabled libx264   && require_pkg_config libx264 
x264 "stdint.h x264.h" x
  check_cpp_condition libx262 x264.h "X264_MPEG2"
 enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
  require_cpp_condition libx265 x265.h "X265_BUILD 
>= 89"
+enabled libvvenc  && require_pkg_config libvvenc "libvvenc >= 1.6.1" 
"vvenc/vvenc.h" vvenc_get_version
 enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
 enabled libxavs2  && require_pkg_config libxavs2 "xavs2 >= 1.3.0" 
"stdint.h xavs2.h" xavs2_api_get
 enabled libxevd   && require_pkg_config libxevd "xevd >= 0.4.1" 
"xevd.h" xevd_decode
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 1a44352906..2e98e1c72f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1155,6 +1155,7 @@ OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER)   += 
libwebpenc_common.o libwebpenc_anim
 OBJS-$(CONFIG_LIBX262_ENCODER)+= libx264.o
 OBJS-$(CONFIG_LIBX264_ENCODER)+= libx264.o
 OBJS-$(CONFIG_LIBX265_ENCODER)+= libx265.o
+OBJS-$(CONFIG_LIBVVENC_ENCODER)   += libvvenc.o
 OBJS-$(CONFIG_LIBXAVS_ENCODER)+= libxavs.o
 OBJS-$(CONFIG_LIBXAVS2_ENCODER)   += libxavs2.o
 OBJS-$(CONFIG_LIBXEVD_DECODER)+= libxevd.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b102a8069e..7650abebe4 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -807,6 +807,7 @@ extern const FFCodec ff_libx262_encoder;
 extern const FFCodec ff_libx264_encoder;
 extern const FFCodec ff_libx264rgb_encoder;
 extern FFCodec ff_libx265_encoder;
+extern const FFCodec ff_libvvenc_encoder;
 extern const FFCodec ff_libxeve_encoder;
 extern const FFCodec ff_libxevd_decoder;
 extern const FFCodec ff_libxavs_encoder;
diff --git a/libavcodec/libvvenc.c b/libavcodec/libvvenc.c
new file mode 100644
index 00..78d4f55a2a
--- /dev/null
+++ b/libavcodec/libvvenc.c
@@ -0,0 +1,566 @@
+/*
+ * H.266 encoding using the VVenC library
+ *
+ * Copyright (C) 2022, Thomas Siedel
+ *
+ * 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
+ */

[FFmpeg-devel] [PATCH] rtp enc/dec update for vvc

[ftaft2000]

Signed-off-by: ftaft2000 
---
 .gitignore |   1 +
 configure  |   4 +
 libavcodec/Makefile|   1 +
 libavcodec/allcodecs.c |   1 +
 libavcodec/libvvenc.c  | 566 +
 libavformat/Makefile   |   1 +
 libavformat/rtpdec.c   |   1 +
 libavformat/rtpdec_formats.h   |   1 +
 libavformat/rtpdec_vvc.c   | 349 
 libavformat/rtpenc.c   |   2 +
 libavformat/rtpenc_h264_hevc.c |  94 +-
 libavformat/sdp.c  | 182 +++
 12 files changed, 1197 insertions(+), 6 deletions(-)
 create mode 100644 libavcodec/libvvenc.c
 create mode 100644 libavformat/rtpdec_vvc.c

diff --git a/.gitignore b/.gitignore
index e810d11107..d7441a6cdc 100644
--- a/.gitignore
+++ b/.gitignore
@@ -41,3 +41,4 @@
 /src
 /mapfile
 /tools/python/__pycache__/
+/build
\ No newline at end of file
diff --git a/configure b/configure
index 83284427df..d331688eb4 100755
--- a/configure
+++ b/configure
@@ -296,6 +296,7 @@ External library support:
   --enable-libwebp enable WebP encoding via libwebp [no]
   --enable-libx264 enable H.264 encoding via x264 [no]
   --enable-libx265 enable HEVC encoding via x265 [no]
+  --enable-libvvencenable H.266/VVC encoding via vvenc [no]
   --enable-libxeve enable EVC encoding via libxeve [no]
   --enable-libxevd enable EVC decoding via libxevd [no]
   --enable-libxavs enable AVS encoding via xavs [no]
@@ -1867,6 +1868,7 @@ EXTERNAL_LIBRARY_GPL_LIST="
 libvidstab
 libx264
 libx265
+libvvenc
 libxavs
 libxavs2
 libxvid
@@ -3569,6 +3571,7 @@ libx264rgb_encoder_deps="libx264"
 libx264rgb_encoder_select="libx264_encoder"
 libx265_encoder_deps="libx265"
 libx265_encoder_select="atsc_a53 dovi_rpuenc"
+libvvenc_encoder_deps="libvvenc"
 libxavs_encoder_deps="libxavs"
 libxavs2_encoder_deps="libxavs2"
 libxevd_decoder_deps="libxevd"
@@ -7041,6 +7044,7 @@ enabled libx264   && require_pkg_config 
libx264 x264 "stdint.h x264.h" x
  check_cpp_condition libx262 x264.h 
"X264_MPEG2"
 enabled libx265   && require_pkg_config libx265 x265 x265.h 
x265_api_get &&
  require_cpp_condition libx265 x265.h 
"X265_BUILD >= 89"
+enabled libvvenc  && require_pkg_config libvvenc "libvvenc >= 
1.6.1" "vvenc/vvenc.h" vvenc_get_version
 enabled libxavs   && require libxavs "stdint.h xavs.h" 
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
 enabled libxavs2  && require_pkg_config libxavs2 "xavs2 >= 
1.3.0" "stdint.h xavs2.h" xavs2_api_get
 enabled libxevd   && require_pkg_config libxevd "xevd >= 
0.4.1" "xevd.h" xevd_decode

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 1a44352906..2e98e1c72f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1155,6 +1155,7 @@ OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER)   += 
libwebpenc_common.o libwebpenc_anim

 OBJS-$(CONFIG_LIBX262_ENCODER)+= libx264.o
 OBJS-$(CONFIG_LIBX264_ENCODER)+= libx264.o
 OBJS-$(CONFIG_LIBX265_ENCODER)+= libx265.o
+OBJS-$(CONFIG_LIBVVENC_ENCODER)   += libvvenc.o
 OBJS-$(CONFIG_LIBXAVS_ENCODER)+= libxavs.o
 OBJS-$(CONFIG_LIBXAVS2_ENCODER)   += libxavs2.o
 OBJS-$(CONFIG_LIBXEVD_DECODER)+= libxevd.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b102a8069e..7650abebe4 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -807,6 +807,7 @@ extern const FFCodec ff_libx262_encoder;
 extern const FFCodec ff_libx264_encoder;
 extern const FFCodec ff_libx264rgb_encoder;
 extern FFCodec ff_libx265_encoder;
+extern const FFCodec ff_libvvenc_encoder;
 extern const FFCodec ff_libxeve_encoder;
 extern const FFCodec ff_libxevd_decoder;
 extern const FFCodec ff_libxavs_encoder;
diff --git a/libavcodec/libvvenc.c b/libavcodec/libvvenc.c
new file mode 100644
index 00..78d4f55a2a
--- /dev/null
+++ b/libavcodec/libvvenc.c
@@ -0,0 +1,566 @@
+/*
+ * H.266 encoding using the VVenC library
+ *
+ * Copyright (C) 2022, Thomas Siedel
+ *
+ * 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 "config_

Re: [FFmpeg-devel] [PATCH v2] movenc: Add an option for hiding fragments at the end

[Gyan Doshi]

On 2024-06-14 02:18 am, Martin Storsjö wrote:

On Thu, 13 Jun 2024, Gyan Doshi wrote:


On 2024-06-13 06:20 pm, Martin Storsjö wrote:

On Wed, 5 Jun 2024, Martin Storsjö wrote:


This allows ending up with a normal, non-fragmented file when
the file is finished, while keeping the file readable if writing
is aborted abruptly at any point. (Normally when writing a
mov/mp4 file, the unfinished file is completely useless unless it
is finished properly.)

This results in a file where the mdat atom contains (and hides)
all the moof atoms that were part of the fragmented file structure
initially.
---
v2: Made the flag implicitly set FF_MOV_FLAG_FRAGMENT (as it makes
no sense without it).

Updated the description of the flag to "Write a fragmented file that
is converted to non-fragmented at the end".

Kept the flag named "hide_fragments", but I'm also pondering if we
maybe should go for a name like "hybrid_fragmented" or so, as a
better description of _what_ it produces, as opposed to _how_ it
does things. (One could also consider "hybrid_mp4", but even if mp4
is the main thing, the same also goes for mov and a bunch of other
related formats.)


I'd otherwise want to push this, but I'm not entirely satisfied with 
the option name quite yet. I'm pondering if we should call it 
"hybrid_fragmented" - any opinions, Dennis or Timo?


How about `resilient_mode` or `recoverable`?
I agree that the how is secondary.


Those are good suggestions as well - but I think I prefer 
"hybrid_fragmented" still.


In theory, I guess one could implement resilient writing in a number 
of different ways, whereas the hybrid fragmented/non-fragmented only 
is one.


So with a couple other voices agreeing with the name 
"hybrid_fragmented", I'll post a new patch with the option in that 
form - hopefully you don't object to it.


The term hybrid is not applicable here. The fragmented state is 
transient during writing and contingent in the finished artifact 
depending on how the writing process concluded.
Hybrid implies both modes available e.g.. a hybrid vehicle can use both 
types of energy sources. The artifact here will be one _or_ the other.


Regards,
Gyan

___
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] remove DEC Alpha DSP & support code

[Rémi Denis-Courmont]

Le 11 juin 2024 17:15:11 GMT+03:00, Vittorio Giovara 
 a écrit :
>Is there anyone actively vouching for this old arch?

The architecture does not participate in the common libavutil CPU detection 
code, and therefore also can't get tested by checkasm. So nobody can credibly 
vouch for this.

FWIW, it seems that the original author has moved on from OSS, having notably 
stepped down from Debian.
___
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".