Re: [FFmpeg-devel] [PATCH] avcodec: add farbfeld encoder

[Andreas Rheinhardt]

Rémi Denis-Courmont:
> 
> 
> Le 4 juin 2024 00:56:21 GMT+03:00, Andreas Rheinhardt 
>  a écrit :
>> Rémi Denis-Courmont:
>>> Le maanantaina 3. kesäkuuta 2024, 22.29.13 EEST marcus a écrit :
> Bogus cast / aliasing violation.

 I thought qualifiers don't affect aliasing rules in C. Am I wrong?
>>>
>>> If they didn't, the compiler wouldn't warn about incompatible pointer type 
>>> conversions in the absence of the explict cast.
>>>
>>
>> Wrong: The conversion uint8_t*const*->const uint8_t * const* is safe
> 
> Nope. The pointer types have the same representation and in practice neither 
> LLVM IR nor GIMPLE can differentiate them, but they are not compatible 
> according to spec (C11 §6.7.6.1).
> 
> You can convert `const uint8_t **` to `const uint8_t *const *`, for sure (C11 
> §6.3.2.3), but that's not the same conversion

"Similarly, pointers to qualified or unqualified versions of compatible
types shall have the same representation and alignment requirements."
(C11 6.2.5 28) This implies that the cast uint8_t*const*->const uint8_t
* const* obeys the alignment requirement from 6.3.2.3 7.
(It does not imply that the cast is a no-op; these two types may have
different object representations, although I don't think that this has
ever happened for any practical implementation.)

When av_image_copy_to_buffer() dereferences this pointer, it will read
from the array of pointers via an lvalue expression of type const
uint8_t* and this is legal because the effective type is uint8_t* and
reading via a qualified type is fine ("An object shall have its stored
value accessed only by an lvalue expression that has one of the
following types: [...] a qualified version of a type compatible with the
effective type of the object" 6.5 7) Given that const uint8_t* and
uint8_t* have the same size, the same is true when accessing via
pointer+offset.

- 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] [RFC] STF 2025

[Vittorio Giovara]

On Tue, Jun 4, 2024 at 8:55 AM Paul B Mahol  wrote:

> On Tue, Jun 4, 2024 at 8:53 AM Vittorio Giovara <
> vittorio.giov...@gmail.com>
> wrote:
>
> > On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> >
> > > > Reposting my question/comment here since Thilo hasn't had a chance to
> > > > respond, but shouldn't these kinds of requests go through the GA? If
> > > > anybody can do whatever they want with the ffmpeg name, then what's
> the
> > > > point of voting and following the established process?
> > >
> > > Probably? I'm not actually sure what the process is for getting an
> FFmpeg
> > > booth at a conference. Is there a documented process somewhere for how
> > this
> > > should be done? If not this might be a good opportunity to create one.
> > >
> >
> > Agreed, do you have a draft you could share as a base of discussion? Once
> > defined, we could have the GA vote on it
> >
> >
> > > It might also make for a good topic of discussion at VDD. For how much
> > > drama there was about NAB on the list I was surprised there was zero
> > > discussion about it at FOSDEM.
> > >
> >
> > There were probably more important topics to discuss and the lingering
> hope
> > that the problematic points would have been handled better than by
> calling
> > people trolls
> >
> >
> > > Regarding the "or you" part, I wasn't involved in securing sponsorship
> > for
> > > NAB or IBC. I did volunteer to help with NAB because I happen to live
> in
> > > Vegas and I enjoy spending time with other ffmpeg developers. I'm happy
> > to
> > > help at NAB next year as well should it happen again.
> > >
> >
> > Noted, it should have said "or anybody willing to host/help a booth"
> >
> > I have no plans to attend IBC and no involvement with the FFmpeg booth at
> > > IBC. I am merely trying to correct the perception that NAB was
> > > cost-problematic, since no money was paid by the project for NAB.
> > >
> >
> > I don't think anybody is suggesting that booths are cost-problematic, but
> > rather they are lacking in process (one shouldn't allowed use ffmpeg name
> > "just because") and in scope (aka "the why" and what kind of results are
> > expected by investing time in said booth)
> >
>
> Said by prominent LibAV developer.
>

reported to CC :)
-- 
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] FFmpeg 7.0 blocking issues

[Vittorio Giovara]

On Tue, Jun 4, 2024 at 3:16 AM Michael Niedermayer 
wrote:

> > Breakages are expected when you remove API.
>
> Are Breakages also expected when you do not remove API ?
>

If a tree falls in a forest and no one is around to hear it, does it make a
sound?
-- 
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] [PATCH] avcodec: add farbfeld encoder

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Rémi Denis-Courmont:
>>
>>
>> Le 4 juin 2024 00:56:21 GMT+03:00, Andreas Rheinhardt 
>>  a écrit :
>>> Rémi Denis-Courmont:
 Le maanantaina 3. kesäkuuta 2024, 22.29.13 EEST marcus a écrit :
>> Bogus cast / aliasing violation.
>
> I thought qualifiers don't affect aliasing rules in C. Am I wrong?

 If they didn't, the compiler wouldn't warn about incompatible pointer type 
 conversions in the absence of the explict cast.

>>>
>>> Wrong: The conversion uint8_t*const*->const uint8_t * const* is safe
>>
>> Nope. The pointer types have the same representation and in practice neither 
>> LLVM IR nor GIMPLE can differentiate them, but they are not compatible 
>> according to spec (C11 §6.7.6.1).
>>
>> You can convert `const uint8_t **` to `const uint8_t *const *`, for sure 
>> (C11 §6.3.2.3), but that's not the same conversion
> 
> "Similarly, pointers to qualified or unqualified versions of compatible
> types shall have the same representation and alignment requirements."
> (C11 6.2.5 28) This implies that the cast uint8_t*const*->const uint8_t
> * const* obeys the alignment requirement from 6.3.2.3 7.
> (It does not imply that the cast is a no-op; these two types may have
> different object representations, although I don't think that this has
> ever happened for any practical implementation.)
> 
> When av_image_copy_to_buffer() dereferences this pointer, it will read
> from the array of pointers via an lvalue expression of type const
> uint8_t* and this is legal because the effective type is uint8_t* and
> reading via a qualified type is fine ("An object shall have its stored
> value accessed only by an lvalue expression that has one of the
> following types: [...] a qualified version of a type compatible with the
> effective type of the object" 6.5 7) Given that const uint8_t* and
> uint8_t* have the same size, the same is true when accessing via
> pointer+offset.
> 

Wait, the second part is wrong: const uint8_t* and uint8_t* are not
qualified versions of a common type. So there is a effective type
problem, but ABI-wise it is fine by 6.2.5 28. I regard this as a defect
of the spec (just like the fact that the conversion uint8_t**->const
uint8_t*const* is not performed automatically) and not a real issue.

- 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] FFmpeg 7.0 blocking issues

[Anton Khirnov]

Quoting Michael Niedermayer (2024-06-04 03:16:11)
> > The real question is
> > why so many projects wait until the old API is gone to migrate. What we
> > removed in 7.0 has had its replacement in place for a couple years, since
> > 5.1.
> 
> Because few need or want to migrate to a new API every year.

IME smaller and more frequent changes are both easier to manage and have
a lower risk of bugs than a massive all-breaking API migration once in
five years.

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

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

Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues

[Andrew Sayers]

On Mon, Jun 03, 2024 at 11:32:37PM +0200, Michael Niedermayer wrote:
> On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
[...]
> > Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
> > Debian. The list is available at [1]. So if you want ffmpeg X to be in
> > Debian Y or Ubuntu Z, X needs to be released at least half a year before
> > Y or Z freeze.
> 
> Is there something that ffmpeg can do to reduce this breakage ?
> (i know its a bit of a lame question as its API brekages but i mean
> can the policy we have about deprecating API/ABI be amended in some way
> to make this easier ?

A quick look through Sebastian's list suggests two main groups of issues:

* channel layout migration
* things that didn't have attribute_deprecated before being removed

There are probably ways to reduce migration issues (e.g. Anton's point about
frequent small changes), but the quick win is to use attribute_deprecated more.

To be clear - attribute_deprecated is already used a lot.  If those messages
were being ignored, we would expect to see more bugs reported for those things.
The fact that channel layout is the only deprecated functionality to get this
far suggests that attribute_deprecated is a good way to notify people about
all but the largest changes.

> Also am i correct that it should be easier if a X.1 with same API/ABI that is
> released 6 month after X.0 is targetet for the release ? Thats in fact kind
> of what i would have preferred anyway as the .1 likely has also fewer bugs
> 
> And last but not least, someone needs to write down when .0 and .1 releases 
> should
> be made so I dont forget it :)

Whatever decision is made about this, it would be good to update the
attribute_deprecated macro to point to a URL that lays out the policy.
Something like:

#define attribute_deprecated __attribute__((deprecated("see  for 
details")))
___
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 7.0 blocking issues

[Sebastian Ramacher]

On 2024-06-03 23:32:37 +0200, Michael Niedermayer wrote:
> On Sun, Jun 02, 2024 at 03:49:42PM +0200, Sebastian Ramacher wrote:
> > On 2024-03-03 09:55:15 +0100, Sebastian Ramacher wrote:
> > > On 2024-03-02 20:39:08 -0500, Sean McGovern wrote:
> > > > On Sat, Mar 2, 2024, 18:19 Michael Niedermayer 
> > > > wrote:
> > > > 
> > > > > On Sun, Mar 03, 2024 at 12:06:14AM +0100, Sebastian Ramacher wrote:
> > > > > > On 2024-03-02 23:55:38 +0100, Michael Niedermayer wrote:
> > > > > > > On Tue, Jan 23, 2024 at 08:22:41PM +0100, Michael Niedermayer 
> > > > > > > wrote:
> > > > > > > > Hi all
> > > > > > > >
> > > > > > > > As it was a little difficult for me to not loose track of what 
> > > > > > > > is
> > > > > > > > blocking a release. I suggest that for all release blocking 
> > > > > > > > issues
> > > > > > > > open a ticket and set Blocking to 7.0
> > > > > > > > that way this:
> > > > > > > > https://trac.ffmpeg.org/query?blocking=~7.0
> > > > > > > >
> > > > > > > > or for the ones not closed:
> > > > > > > >
> > > > > https://trac.ffmpeg.org/query?status=new&status=open&status=reopened&blocking=~7.0
> > > > > > > >
> > > > > > > > will list all blocking issues
> > > > > > > >
> > > > > > > > Ive added one, for testing that, i intend to add more if i see
> > > > > something
> > > > > > > >
> > > > > > > > What is blocking? (IMHO)
> > > > > > > > * regressions (unless its non possible to fix before release)
> > > > > > > > * crashes
> > > > > > > > * security issues
> > > > > > > > * data loss
> > > > > > > > * privacy issues
> > > > > > > > * anything the commuity agrees should be in the release
> > > > > > >
> > > > > > > We still have 3 blocking issues on trac
> > > > > > >
> > > > > > > do people want me to wait or ignore them and branch ?
> > > > > > > Iam not sure when the exact deadline is but if we keep waiting
> > > > > > > we will not get into ubuntu 24.04 LTS
> > > > > >
> > > > > > 24.04 is past feature freeze, so it's too late for that.
> > > > >
> > > > > we should aim earlier in the future then.
> > > > >
> > > > >
> > > > 
> > > > LTS is only every 2 years, yes?
> > > 
> > > Yes
> > > 
> > > > How do we make sure this doesn't happen in 2026? How much of a gap is 
> > > > there
> > > > between feature freeze and release?
> > > 
> > > Not involved in Ubuntu, so that's from past experience: feature
> > > freeze is usually about two months before the release.
> > > 
> > > So here's the catch: Debian's timeline also needs to be taken into
> > > account. If the ffmpeg release does not involve the removal of deprecated 
> > > API and
> > > a SONAME bump, then the time from ffmpeg to release to upload to Debian
> > > unstable and then import in Ubuntu is short. In this case, I am sure
> > > that I could convince Ubuntu maintainers to import it even during
> > > feature freeze.
> > > 
> > > But with SONAME bumps and changes in the API, it takes a lot more time
> > > to work through the high number of ffmpeg reverse dependencies. In that
> > > case, plan a release at least 6 months before an Ubuntu LTS release.
> > 
> > 
> > 
> > > 
> > > We usually have to rely on upstream maintainers to adopt to the
> > > changes and that take times. Many moons ago Anton helped with providing
> > > patches, but for the last couple of API changes it took some months from
> > > "dear maintainer, here is ffmpeg X for testing, please fix the build of
> > > your package" to actually doing all uploads and rebuilds. For example,
> > > the transition to ffmpeg 6.0 was started in July 2023 and was done in
> > > December 2023.
> > 
> > Just as a FYI: ffmpeg 7.0 breaks close to 70 reverse dependencies in
> > Debian. The list is available at [1]. So if you want ffmpeg X to be in
> > Debian Y or Ubuntu Z, X needs to be released at least half a year before
> > Y or Z freeze.
> 
> Is there something that ffmpeg can do to reduce this breakage ?
> (i know its a bit of a lame question as its API brekages but i mean
> can the policy we have about deprecating API/ABI be amended in some way
> to make this easier ?

Maintainers and developers of reverse dependencies repeatedly ask for
upgrade guides that go beyond "use this function instead". I just did a
quick check through the documentation of 7.0 (doxygen and APIchanges)
for the changes of the channel layout handling. This is what I can find:

2022-03-15 - cdba98bb80 - lavc 59.24.100 - avcodec.h codec_par.h
  Update AVCodecParameters for the new channel layout API: add ch_layout,
  deprecate channels/channel_layout.

  Update AVCodecContext for the new channel layout API: add ch_layout,
  deprecate channels/channel_layout.

  Update AVCodec for the new channel layout API: add ch_layouts,
  deprecate channel_layouts.

2022-03-15 - cdba98bb80 - lavu 57.24.100 - channel_layout.h frame.h opt.h
  Add new channel layout API based on the AVChannelLayout struct.
  Add support for Ambisonic audio.
  Deprecate previous channel layout API based on uint64 bitmasks.

  Add AV_OPT_TYPE_CHLAYOUT 

Re: [FFmpeg-devel] [PATCH v4 1/1] avcodec: add external enc libvvenc for H266/VVC

[Anton Khirnov]

Quoting Christian Bartnik (2024-05-28 18:26:29)
> +static const AVOption options[] = {
> +{ "passlogfile",  "Filename for 2 pass stats", OFFSET(stats), 
> AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, VE},
> +{ "stats","Filename for 2 pass stats", OFFSET(stats), 
> AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, VE},

These option names conflict with ffmpeg CLI options.

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

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

Re: [FFmpeg-devel] FFmpeg 7.0 blocking issues

[Sebastian Ramacher]

On 2024-06-04 09:31:38 +0300, Rémi Denis-Courmont wrote:
> 
> 
> Le 4 juin 2024 00:41:03 GMT+03:00, James Almer  a écrit :
> >Well, no. Breakages are expected when you remove API. The real question is 
> >why so many projects wait until the old API is gone to migrate. What we 
> >removed in 7.0 has had its replacement in place for a couple years, since 
> >5.1.
> 
> Because nobody cares to fix it until it breaks.
> 
> Before that it takes a long time for the breakage to be visible since most 
> down-stream projects get FFmpeg as a pinned vendored release and/or from 
> stable Linux distros.
> 
> And then you have projects that are dead or in a never-ending release cycle 
> due to their own reasons (VLC...), holding back any stable release source 
> update.

vlc is in a state where it cannot keep up with the changes in its
dependencies from a packagers viewpoint. If there weren't changes in the
git repository, I would almost say that the project is dead. The last
changes I made to the vlc package in Debian are all disabling features
(libplacebo, hardware decoding, ...). The recent changes in ffmpeg may
put the final nail into the coffin and we need to start looking at its
removal [1].

Best
Sebastian

[1] I don't usually like to threaten removal, but there is a limit of
what volunteer package maintainers can handle.
-- 
Sebastian Ramacher
___
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] [RFC] STF 2025

[Paul B Mahol]

On Tue, Jun 4, 2024 at 9:09 AM Vittorio Giovara 
wrote:

> On Tue, Jun 4, 2024 at 8:55 AM Paul B Mahol  wrote:
>
> > On Tue, Jun 4, 2024 at 8:53 AM Vittorio Giovara <
> > vittorio.giov...@gmail.com>
> > wrote:
> >
> > > On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel <
> > > ffmpeg-devel@ffmpeg.org> wrote:
> > >
> > > > > Reposting my question/comment here since Thilo hasn't had a chance
> to
> > > > > respond, but shouldn't these kinds of requests go through the GA?
> If
> > > > > anybody can do whatever they want with the ffmpeg name, then what's
> > the
> > > > > point of voting and following the established process?
> > > >
> > > > Probably? I'm not actually sure what the process is for getting an
> > FFmpeg
> > > > booth at a conference. Is there a documented process somewhere for
> how
> > > this
> > > > should be done? If not this might be a good opportunity to create
> one.
> > > >
> > >
> > > Agreed, do you have a draft you could share as a base of discussion?
> Once
> > > defined, we could have the GA vote on it
> > >
> > >
> > > > It might also make for a good topic of discussion at VDD. For how
> much
> > > > drama there was about NAB on the list I was surprised there was zero
> > > > discussion about it at FOSDEM.
> > > >
> > >
> > > There were probably more important topics to discuss and the lingering
> > hope
> > > that the problematic points would have been handled better than by
> > calling
> > > people trolls
> > >
> > >
> > > > Regarding the "or you" part, I wasn't involved in securing
> sponsorship
> > > for
> > > > NAB or IBC. I did volunteer to help with NAB because I happen to live
> > in
> > > > Vegas and I enjoy spending time with other ffmpeg developers. I'm
> happy
> > > to
> > > > help at NAB next year as well should it happen again.
> > > >
> > >
> > > Noted, it should have said "or anybody willing to host/help a booth"
> > >
> > > I have no plans to attend IBC and no involvement with the FFmpeg booth
> at
> > > > IBC. I am merely trying to correct the perception that NAB was
> > > > cost-problematic, since no money was paid by the project for NAB.
> > > >
> > >
> > > I don't think anybody is suggesting that booths are cost-problematic,
> but
> > > rather they are lacking in process (one shouldn't allowed use ffmpeg
> name
> > > "just because") and in scope (aka "the why" and what kind of results
> are
> > > expected by investing time in said booth)
> > >
> >
> > Said by prominent LibAV developer.
> >
>
> reported to CC :)
>

CC is fully controlled by prominent LibAV developers.


> --
> 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".
>
___
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] avcodec: add farbfeld encoder

[Paul B Mahol]

Encoder without decoder?
___
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 1/6] lavf/tls_mbedtls: handle more error codes for

[sfan5]

Am 03.06.24 um 22:08 schrieb Jan Ekström:

On Wed, May 29, 2024 at 2:05 PM sfan5  wrote:
Did an initial tired look at the set, and in general it looks alright
and the wrapper still builds with Fedora's mbedtls 2.28.8.

(Of course then it fails to link due to unchecked usage of
`mbedtls_x509_crt_{init,free,parse_file}` in tls_mbedtls, as well as
`mbedtls_mpi_copy` in rtmpdh. But this breakage is unrelated to this
patch, as current master does exactly the same)

I'd just probably move the MBEDTLS_ERR_X509_CERT_VERIFY_FAILED logging
diff into the first commit that adds error codes (also probably
"messages" in the commit message there?), as adding that error's
logging really doesn't have anything to do with the verify=0 + TLS 1.3
workaround.

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


I will move that change to the first commit for v3 as discussed on IRC.
___
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 v3 1/6] lavf/tls_mbedtls: handle more error codes for

[sfan5]

From 7024782ebac9471194761fba9f60834ed7769efd Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Mon, 13 May 2024 20:22:44 +0200
Subject: [PATCH v3 1/6] lavf/tls_mbedtls: handle more error codes for
 human-readable messages

Signed-off-by: sfan5 
---
 libavformat/tls_mbedtls.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c
index 1a182e735e..02f08fddbb 100644
--- a/libavformat/tls_mbedtls.c
+++ b/libavformat/tls_mbedtls.c
@@ -138,6 +138,9 @@ static void handle_handshake_error(URLContext *h, int ret)
 case MBEDTLS_ERR_SSL_HANDSHAKE_FAILURE:
 av_log(h, AV_LOG_ERROR, "TLS handshake failed.\n");
 break;
+case MBEDTLS_ERR_SSL_BAD_PROTOCOL_VERSION:
+av_log(h, AV_LOG_ERROR, "TLS protocol version mismatch.\n");
+break;
 #endif
 case MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE:
 av_log(h, AV_LOG_ERROR, "A fatal alert message was received from the peer, has the peer a correct certificate?\n");
@@ -145,9 +148,15 @@ static void handle_handshake_error(URLContext *h, int ret)
 case MBEDTLS_ERR_SSL_CA_CHAIN_REQUIRED:
 av_log(h, AV_LOG_ERROR, "No CA chain is set, but required to operate. Was the CA correctly set?\n");
 break;
+case MBEDTLS_ERR_SSL_INTERNAL_ERROR:
+av_log(h, AV_LOG_ERROR, "Internal error encountered.\n");
+break;
 case MBEDTLS_ERR_NET_CONN_RESET:
 av_log(h, AV_LOG_ERROR, "TLS handshake was aborted by peer.\n");
 break;
+case MBEDTLS_ERR_X509_CERT_VERIFY_FAILED:
+av_log(h, AV_LOG_ERROR, "Certificate verification failed.\n");
+break;
 default:
 av_log(h, AV_LOG_ERROR, "mbedtls_ssl_handshake returned -0x%x\n", -ret);
 break;
-- 
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] [PATCH v3 5/6] lavf/tls_mbedtls: handle session ticket error code as

[sfan5]

From c8d7f937f5d8f1cf001aec510d4f6f28c5d9fc59 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Mon, 13 May 2024 20:29:10 +0200
Subject: [PATCH v3 5/6] lavf/tls_mbedtls: handle session ticket error code as
 no-op

When TLSv1.3 and session tickets are enabled mbedtls_ssl_read()
will return an error code to inform about a received session ticket.
This can simply be handled like EAGAIN instead of errornously
aborting the connection.

ref: https://github.com/Mbed-TLS/mbedtls/issues/8749
Signed-off-by: sfan5 
---
 libavformat/tls_mbedtls.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c
index f65f2f4020..91e93fb862 100644
--- a/libavformat/tls_mbedtls.c
+++ b/libavformat/tls_mbedtls.c
@@ -328,6 +328,9 @@ static int handle_tls_error(URLContext *h, const char* func_name, int ret)
 switch (ret) {
 case MBEDTLS_ERR_SSL_WANT_READ:
 case MBEDTLS_ERR_SSL_WANT_WRITE:
+#ifdef MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET
+case MBEDTLS_ERR_SSL_RECEIVED_NEW_SESSION_TICKET:
+#endif
 return AVERROR(EAGAIN);
 case MBEDTLS_ERR_NET_SEND_FAILED:
 case MBEDTLS_ERR_NET_RECV_FAILED:
-- 
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] [PATCH v3 2/6] lavf/tls_mbedtls: add missing call to psa_crypto_init

[sfan5]

From 8b2cab9a0ad225fc2b13850ff1bafb45d3d8ebaa Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Mon, 13 May 2024 20:24:43 +0200
Subject: [PATCH v3 2/6] lavf/tls_mbedtls: add missing call to psa_crypto_init

This is mandatory depending on configuration or at least with mbedTLS 3.6.0.

Signed-off-by: sfan5 
---
 libavformat/tls_mbedtls.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c
index 02f08fddbb..0d14e9f814 100644
--- a/libavformat/tls_mbedtls.c
+++ b/libavformat/tls_mbedtls.c
@@ -26,6 +26,9 @@
 #include 
 #include 
 #include 
+#ifdef MBEDTLS_PSA_CRYPTO_C
+#include 
+#endif
 
 #include "avformat.h"
 #include "internal.h"
@@ -187,6 +190,13 @@ static int tls_open(URLContext *h, const char *uri, int flags, AVDictionary **op
 if ((ret = ff_tls_open_underlying(shr, h, uri, options)) < 0)
 goto fail;
 
+#ifdef MBEDTLS_PSA_CRYPTO_C
+if ((ret = psa_crypto_init()) != PSA_SUCCESS) {
+av_log(h, AV_LOG_ERROR, "psa_crypto_init returned %d\n", ret);
+goto fail;
+}
+#endif
+
 mbedtls_ssl_init(&tls_ctx->ssl_context);
 mbedtls_ssl_config_init(&tls_ctx->ssl_config);
 mbedtls_entropy_init(&tls_ctx->entropy_context);
-- 
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] [PATCH v3 6/6] lavf/tls_mbedtls: add workaround for TLSv1.3 vs.

[sfan5]

From 9df718654e45eb02c1f2b3f29b4554a6a90900ef Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Fri, 17 May 2024 10:06:42 +0200
Subject: [PATCH v3 6/6] lavf/tls_mbedtls: add workaround for TLSv1.3 vs.
 verify=0

As of mbedTLS 3.6.0 TLSv1.3 is enabled by default and certificate verification
is now mandatory. Our default configuration does not do verification, so
downgrade to 1.2 in these situations to avoid breaking it.

ref: https://github.com/Mbed-TLS/mbedtls/issues/7075
Signed-off-by: sfan5 
---
 libavformat/tls_mbedtls.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c
index 91e93fb862..567b95b129 100644
--- a/libavformat/tls_mbedtls.c
+++ b/libavformat/tls_mbedtls.c
@@ -269,6 +269,14 @@ static int tls_open(URLContext *h, const char *uri, int flags, AVDictionary **op
 goto fail;
 }
 
+#ifdef MBEDTLS_SSL_PROTO_TLS1_3
+// mbedTLS does not allow disabling certificate verification with TLSv1.3 (yes, really).
+if (!shr->verify) {
+av_log(h, AV_LOG_INFO, "Forcing TLSv1.2 because certificate verification is disabled\n");
+mbedtls_ssl_conf_max_tls_version(&tls_ctx->ssl_config, MBEDTLS_SSL_VERSION_TLS1_2);
+}
+#endif
+
 // not VERIFY_REQUIRED because we manually check after handshake
 mbedtls_ssl_conf_authmode(&tls_ctx->ssl_config,
   shr->verify ? MBEDTLS_SSL_VERIFY_OPTIONAL : MBEDTLS_SSL_VERIFY_NONE);
-- 
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] [PATCH v3 3/6] lavf/tls_mbedtls: hook up debug message callback

[sfan5]

From 9e5993cf104cdc1b7c4eabe173f9ab3e8f0cfeca Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Mon, 13 May 2024 20:26:16 +0200
Subject: [PATCH v3 3/6] lavf/tls_mbedtls: hook up debug message callback

Unfortunately this won't work out-of-the-box because mbedTLS
only provides a global (not per-context) debug toggle.

Signed-off-by: sfan5 
---
 libavformat/tls_mbedtls.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c
index 0d14e9f814..ba94ab3a70 100644
--- a/libavformat/tls_mbedtls.c
+++ b/libavformat/tls_mbedtls.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef MBEDTLS_PSA_CRYPTO_C
 #include 
 #endif
@@ -36,6 +37,7 @@
 #include "tls.h"
 #include "libavutil/mem.h"
 #include "libavutil/parseutils.h"
+#include "libavutil/avstring.h"
 
 typedef struct TLSContext {
 const AVClass *class;
@@ -112,6 +114,13 @@ static int mbedtls_recv(void *ctx, unsigned char *buf, size_t len)
 return handle_transport_error(h, "ffurl_read", MBEDTLS_ERR_SSL_WANT_READ, ret);
 }
 
+static void mbedtls_debug(void *ctx, int lvl, const char *file, int line, const char *msg)
+{
+URLContext *h = (URLContext*) ctx;
+int av_lvl = lvl >= 4 ? AV_LOG_TRACE : AV_LOG_DEBUG;
+av_log(h, av_lvl, "%s:%d: %s", av_basename(file), line, msg);
+}
+
 static void handle_pk_parse_error(URLContext *h, int ret)
 {
 switch (ret) {
@@ -204,6 +213,14 @@ static int tls_open(URLContext *h, const char *uri, int flags, AVDictionary **op
 mbedtls_x509_crt_init(&tls_ctx->ca_cert);
 mbedtls_pk_init(&tls_ctx->priv_key);
 
+if (av_log_get_level() >= AV_LOG_DEBUG) {
+mbedtls_ssl_conf_dbg(&tls_ctx->ssl_config, mbedtls_debug, shr->tcp);
+/*
+ * Note: we can't call mbedtls_debug_set_threshold() here because
+ * it's global state. The user is thus expected to manage this.
+ */
+}
+
 // load trusted CA
 if (shr->ca_file) {
 if ((ret = mbedtls_x509_crt_parse_file(&tls_ctx->ca_cert, shr->ca_file)) != 0) {
-- 
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] [PATCH v3 4/6] lavf/tls_mbedtls: fix handling of certification

[sfan5]

From 2cfdd92e8b323a41b65e3d6be2fc9c7641bb26c0 Mon Sep 17 00:00:00 2001
From: sfan5 
Date: Mon, 13 May 2024 20:27:17 +0200
Subject: [PATCH v3 4/6] lavf/tls_mbedtls: fix handling of certification
 validation failures

We manually check the verification status after the handshake has completed
using mbedtls_ssl_get_verify_result(). However with VERIFY_REQUIRED
mbedtls_ssl_handshake() already returns an error, so this code is never reached.
Fix that by using VERIFY_OPTIONAL, which performs the verification but
does not abort the handshake.

Signed-off-by: sfan5 
---
 libavformat/tls_mbedtls.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/tls_mbedtls.c b/libavformat/tls_mbedtls.c
index ba94ab3a70..f65f2f4020 100644
--- a/libavformat/tls_mbedtls.c
+++ b/libavformat/tls_mbedtls.c
@@ -269,8 +269,9 @@ static int tls_open(URLContext *h, const char *uri, int flags, AVDictionary **op
 goto fail;
 }
 
+// not VERIFY_REQUIRED because we manually check after handshake
 mbedtls_ssl_conf_authmode(&tls_ctx->ssl_config,
-  shr->verify ? MBEDTLS_SSL_VERIFY_REQUIRED : MBEDTLS_SSL_VERIFY_NONE);
+  shr->verify ? MBEDTLS_SSL_VERIFY_OPTIONAL : MBEDTLS_SSL_VERIFY_NONE);
 mbedtls_ssl_conf_rng(&tls_ctx->ssl_config, mbedtls_ctr_drbg_random, &tls_ctx->ctr_drbg_context);
 mbedtls_ssl_conf_ca_chain(&tls_ctx->ssl_config, &tls_ctx->ca_cert, NULL);
 
-- 
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] [RFC] STF 2025

[Vittorio Giovara]

On Tue, Jun 4, 2024 at 12:09 PM Paul B Mahol  wrote:

> On Tue, Jun 4, 2024 at 9:09 AM Vittorio Giovara <
> vittorio.giov...@gmail.com>
> wrote:
>
> > On Tue, Jun 4, 2024 at 8:55 AM Paul B Mahol  wrote:
> >
> > > On Tue, Jun 4, 2024 at 8:53 AM Vittorio Giovara <
> > > vittorio.giov...@gmail.com>
> > > wrote:
> > >
> > > > On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel <
> > > > ffmpeg-devel@ffmpeg.org> wrote:
> > > >
> > > > > > Reposting my question/comment here since Thilo hasn't had a
> chance
> > to
> > > > > > respond, but shouldn't these kinds of requests go through the GA?
> > If
> > > > > > anybody can do whatever they want with the ffmpeg name, then
> what's
> > > the
> > > > > > point of voting and following the established process?
> > > > >
> > > > > Probably? I'm not actually sure what the process is for getting an
> > > FFmpeg
> > > > > booth at a conference. Is there a documented process somewhere for
> > how
> > > > this
> > > > > should be done? If not this might be a good opportunity to create
> > one.
> > > > >
> > > >
> > > > Agreed, do you have a draft you could share as a base of discussion?
> > Once
> > > > defined, we could have the GA vote on it
> > > >
> > > >
> > > > > It might also make for a good topic of discussion at VDD. For how
> > much
> > > > > drama there was about NAB on the list I was surprised there was
> zero
> > > > > discussion about it at FOSDEM.
> > > > >
> > > >
> > > > There were probably more important topics to discuss and the
> lingering
> > > hope
> > > > that the problematic points would have been handled better than by
> > > calling
> > > > people trolls
> > > >
> > > >
> > > > > Regarding the "or you" part, I wasn't involved in securing
> > sponsorship
> > > > for
> > > > > NAB or IBC. I did volunteer to help with NAB because I happen to
> live
> > > in
> > > > > Vegas and I enjoy spending time with other ffmpeg developers. I'm
> > happy
> > > > to
> > > > > help at NAB next year as well should it happen again.
> > > > >
> > > >
> > > > Noted, it should have said "or anybody willing to host/help a booth"
> > > >
> > > > I have no plans to attend IBC and no involvement with the FFmpeg
> booth
> > at
> > > > > IBC. I am merely trying to correct the perception that NAB was
> > > > > cost-problematic, since no money was paid by the project for NAB.
> > > > >
> > > >
> > > > I don't think anybody is suggesting that booths are cost-problematic,
> > but
> > > > rather they are lacking in process (one shouldn't allowed use ffmpeg
> > name
> > > > "just because") and in scope (aka "the why" and what kind of results
> > are
> > > > expected by investing time in said booth)
> > > >
> > >
> > > Said by prominent LibAV developer.
> > >
> >
> > reported to CC :)
> >
>
> CC is fully controlled by prominent LibAV developers.
>

Not only is this factually incorrect, it's also unrelated to the topic at
hand. No worries, this infringement is being reported to the CC as well,
but please try to make an effort at doing better at least.
Thank you
-- 
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] [RFC] STF 2025

[Paul B Mahol]

On Tue, Jun 4, 2024 at 12:59 PM Vittorio Giovara 
wrote:

> On Tue, Jun 4, 2024 at 12:09 PM Paul B Mahol  wrote:
>
> > On Tue, Jun 4, 2024 at 9:09 AM Vittorio Giovara <
> > vittorio.giov...@gmail.com>
> > wrote:
> >
> > > On Tue, Jun 4, 2024 at 8:55 AM Paul B Mahol  wrote:
> > >
> > > > On Tue, Jun 4, 2024 at 8:53 AM Vittorio Giovara <
> > > > vittorio.giov...@gmail.com>
> > > > wrote:
> > > >
> > > > > On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel <
> > > > > ffmpeg-devel@ffmpeg.org> wrote:
> > > > >
> > > > > > > Reposting my question/comment here since Thilo hasn't had a
> > chance
> > > to
> > > > > > > respond, but shouldn't these kinds of requests go through the
> GA?
> > > If
> > > > > > > anybody can do whatever they want with the ffmpeg name, then
> > what's
> > > > the
> > > > > > > point of voting and following the established process?
> > > > > >
> > > > > > Probably? I'm not actually sure what the process is for getting
> an
> > > > FFmpeg
> > > > > > booth at a conference. Is there a documented process somewhere
> for
> > > how
> > > > > this
> > > > > > should be done? If not this might be a good opportunity to create
> > > one.
> > > > > >
> > > > >
> > > > > Agreed, do you have a draft you could share as a base of
> discussion?
> > > Once
> > > > > defined, we could have the GA vote on it
> > > > >
> > > > >
> > > > > > It might also make for a good topic of discussion at VDD. For how
> > > much
> > > > > > drama there was about NAB on the list I was surprised there was
> > zero
> > > > > > discussion about it at FOSDEM.
> > > > > >
> > > > >
> > > > > There were probably more important topics to discuss and the
> > lingering
> > > > hope
> > > > > that the problematic points would have been handled better than by
> > > > calling
> > > > > people trolls
> > > > >
> > > > >
> > > > > > Regarding the "or you" part, I wasn't involved in securing
> > > sponsorship
> > > > > for
> > > > > > NAB or IBC. I did volunteer to help with NAB because I happen to
> > live
> > > > in
> > > > > > Vegas and I enjoy spending time with other ffmpeg developers. I'm
> > > happy
> > > > > to
> > > > > > help at NAB next year as well should it happen again.
> > > > > >
> > > > >
> > > > > Noted, it should have said "or anybody willing to host/help a
> booth"
> > > > >
> > > > > I have no plans to attend IBC and no involvement with the FFmpeg
> > booth
> > > at
> > > > > > IBC. I am merely trying to correct the perception that NAB was
> > > > > > cost-problematic, since no money was paid by the project for NAB.
> > > > > >
> > > > >
> > > > > I don't think anybody is suggesting that booths are
> cost-problematic,
> > > but
> > > > > rather they are lacking in process (one shouldn't allowed use
> ffmpeg
> > > name
> > > > > "just because") and in scope (aka "the why" and what kind of
> results
> > > are
> > > > > expected by investing time in said booth)
> > > > >
> > > >
> > > > Said by prominent LibAV developer.
> > > >
> > >
> > > reported to CC :)
> > >
> >
> > CC is fully controlled by prominent LibAV developers.
> >
>
> Not only is this factually incorrect, it's also unrelated to the topic at
> hand. No worries, this infringement is being reported to the CC as well,
> but please try to make an effort at doing better at least.
> Thank you
>

Do not trust LibAV developers even when they are giving you gifts.


> --
> 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".
>
___
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 v2 1/5] avcodec/vvcdec: refact, remove emulated_edge_dmvr and emulated_edge_bilinear to simplify code

[Nuo Mi]

---
 libavcodec/vvc/inter.c | 146 +
 1 file changed, 46 insertions(+), 100 deletions(-)

diff --git a/libavcodec/vvc/inter.c b/libavcodec/vvc/inter.c
index e1011b4fa1..0843c99eb6 100644
--- a/libavcodec/vvc/inter.c
+++ b/libavcodec/vvc/inter.c
@@ -44,112 +44,59 @@ static void subpic_width_height(int *pic_width, int 
*pic_height,
 *pic_height = pps->subpic_height[subpic_idx] >> sps->vshift[is_chroma];
 }
 
-static int emulated_edge(const VVCLocalContext *lc, uint8_t *dst, const 
uint8_t **src, ptrdiff_t *src_stride, const VVCFrame *src_frame,
-int x_off, int y_off, const int block_w, const int block_h, const int 
is_chroma)
+static void emulated_edge(const VVCLocalContext *lc, uint8_t *dst,
+const uint8_t **src, ptrdiff_t *src_stride, const VVCFrame *src_frame,
+int x_sb, int y_sb, int x_off, int y_off, const int block_w, const int 
block_h,
+const int is_chroma, const int extra_before, const int extra_after)
 {
 const VVCFrameContext *fc = lc->fc;
 const VVCSPS *sps = src_frame->sps;
 const VVCPPS *pps = src_frame->pps;
 const int subpic_idx  = lc->sc->sh.r->curr_subpic_idx;
-const int extra_before= is_chroma ? CHROMA_EXTRA_BEFORE : 
LUMA_EXTRA_BEFORE;
-const int extra_after = is_chroma ? CHROMA_EXTRA_AFTER : 
LUMA_EXTRA_AFTER;
-const int extra   = is_chroma ? CHROMA_EXTRA : LUMA_EXTRA;
-int pic_width, pic_height;
-
-subpic_offset(&x_off, &y_off, sps, pps, subpic_idx, is_chroma);
-subpic_width_height(&pic_width, &pic_height, sps, pps, subpic_idx, 
is_chroma);
-
-if (x_off < extra_before || y_off < extra_before ||
-x_off >= pic_width - block_w - extra_after ||
-y_off >= pic_height - block_h - extra_after) {
-const ptrdiff_t edge_emu_stride = EDGE_EMU_BUFFER_STRIDE << 
fc->ps.sps->pixel_shift;
-int offset = extra_before * *src_stride  + (extra_before << 
fc->ps.sps->pixel_shift);
-int buf_offset = extra_before * edge_emu_stride + (extra_before << 
fc->ps.sps->pixel_shift);
-
-fc->vdsp.emulated_edge_mc(dst, *src - offset, edge_emu_stride, 
*src_stride,
-block_w + extra, block_h + extra, x_off - extra_before, y_off - 
extra_before,
-pic_width, pic_height);
-
-*src = dst + buf_offset;
-*src_stride = edge_emu_stride;
-return 1;
-}
-return 0;
-}
-
-static void emulated_edge_dmvr(const VVCLocalContext *lc, uint8_t *dst, const 
uint8_t **src, ptrdiff_t *src_stride,
-int x_sb, int y_sb, int x_off,  int y_off, const int block_w, const int 
block_h, const int is_chroma)
-{
-const VVCFrameContext *fc = lc->fc;
-const VVCSPS *sps = fc->ps.sps;
-const VVCPPS *pps = fc->ps.pps;
-const int subpic_idx  = lc->sc->sh.r->curr_subpic_idx;
-const int extra_before= is_chroma ? CHROMA_EXTRA_BEFORE : 
LUMA_EXTRA_BEFORE;
-const int extra_after = is_chroma ? CHROMA_EXTRA_AFTER : 
LUMA_EXTRA_AFTER;
-const int extra   = is_chroma ? CHROMA_EXTRA : LUMA_EXTRA;
+const int extra   = extra_before + extra_after;
+const int dmvr_clip   = x_sb != x_off || y_sb != y_off;
 int pic_width, pic_height;
 
 subpic_offset(&x_off, &y_off, sps, pps, subpic_idx, is_chroma);
 subpic_offset(&x_sb, &y_sb, sps, pps, subpic_idx, is_chroma);
 subpic_width_height(&pic_width, &pic_height, sps, pps, subpic_idx, 
is_chroma);
+if (dmvr_clip) {
+const int start_x = FFMIN(FFMAX(x_sb - extra_before, 0), pic_width  - 
1);
+const int start_y = FFMIN(FFMAX(y_sb - extra_before, 0), pic_height - 
1);
+pic_width  = FFMAX(FFMIN(pic_width, x_sb + block_w + extra_after) - 
start_x, 1);
+pic_height = FFMAX(FFMIN(pic_height, y_sb + block_h + extra_after) - 
start_y, 1);
+x_off -= start_x;
+y_off -= start_y;
+}
 
-if (x_off < extra_before || y_off < extra_before ||
+if (dmvr_clip || x_off < extra_before || y_off < extra_before ||
 x_off >= pic_width - block_w - extra_after ||
-y_off >= pic_height - block_h - extra_after||
-(x_off != x_sb || y_off !=  y_sb)) {
+y_off >= pic_height - block_h - extra_after) {
 const int ps= fc->ps.sps->pixel_shift;
 const ptrdiff_t edge_emu_stride = EDGE_EMU_BUFFER_STRIDE << ps;
-const int offset= extra_before * *src_stride + 
(extra_before << ps);
+const int offset= extra_before * *src_stride + 
(extra_before << ps);
 const int buf_offset= extra_before * edge_emu_stride + 
(extra_before << ps);
 
-const int start_x   = FFMIN(FFMAX(x_sb - extra_before, 0), 
pic_width  - 1);
-const int start_y   = FFMIN(FFMAX(y_sb - extra_before, 0), 
pic_height - 1);
-const int width = FFMAX(FFMIN(pic_width, x_sb + 
block_w + extra_after) - start_x, 1);

[FFmpeg-devel] [PATCH v2 2/5] avcodec/vvcdec: misc, move src offset inside emulated_edge

[Nuo Mi]

---
 libavcodec/vvc/inter.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/libavcodec/vvc/inter.c b/libavcodec/vvc/inter.c
index 0843c99eb6..07b55c4bac 100644
--- a/libavcodec/vvc/inter.c
+++ b/libavcodec/vvc/inter.c
@@ -57,6 +57,8 @@ static void emulated_edge(const VVCLocalContext *lc, uint8_t 
*dst,
 const int dmvr_clip   = x_sb != x_off || y_sb != y_off;
 int pic_width, pic_height;
 
+*src  += y_off * *src_stride + (x_off * (1 << fc->ps.sps->pixel_shift));
+
 subpic_offset(&x_off, &y_off, sps, pps, subpic_idx, is_chroma);
 subpic_offset(&x_sb, &y_sb, sps, pps, subpic_idx, is_chroma);
 subpic_width_height(&pic_width, &pic_height, sps, pps, subpic_idx, 
is_chroma);
@@ -170,7 +172,6 @@ static void mc(VVCLocalContext *lc, int16_t *dst, const 
VVCFrame *ref, const Mv
 
 x_off += mv->x >> (4 + hs);
 y_off += mv->y >> (4 + vs);
-src  += y_off * src_stride + (x_off * (1 << fc->ps.sps->pixel_shift));
 
 MC_EMULATED_EDGE(lc->edge_emu_buffer, &src, &src_stride, x_off, y_off);
 fc->vvcdsp.inter.put[is_chroma][idx][!!my][!!mx](dst, src, src_stride, 
block_h, hf, vf, block_w);
@@ -199,7 +200,6 @@ static void mc_uni(VVCLocalContext *lc, uint8_t *dst, const 
ptrdiff_t dst_stride
 
 x_off += mv->x >> (4 + hs);
 y_off += mv->y >> (4 + vs);
-src  += y_off * src_stride + (x_off * (1 << fc->ps.sps->pixel_shift));
 
 MC_EMULATED_EDGE(lc->edge_emu_buffer, &src, &src_stride, x_off, y_off);
 if (derive_weight_uni(&denom, &wx, &ox, lc, mvf, c_idx)) {
@@ -236,7 +236,7 @@ static void mc_bi(VVCLocalContext *lc, uint8_t *dst, const 
ptrdiff_t dst_stride,
 const int oy= y_off + (mv->y >> (4 + vs));
 const VVCFrame *ref = refs[i];
 ptrdiff_t src_stride= ref->frame->linesize[c_idx];
-const uint8_t *src  = ref->frame->data[c_idx] + oy * src_stride + 
(ox * (1 << fc->ps.sps->pixel_shift));
+const uint8_t *src  = ref->frame->data[c_idx];
 const int8_t *hf= INTER_FILTER(hpel_if_idx, mx);
 const int8_t *vf= INTER_FILTER(hpel_if_idx, my);
 
@@ -306,7 +306,6 @@ static void scaled_ref_pos_and_step(const VVCLocalContext 
*lc, const VVCRefPic *
 static void emulated_edge_scaled(VVCLocalContext *lc, const uint8_t **src, 
ptrdiff_t *src_stride, int *src_height,
 const VVCFrame *ref, const int x, const int y, const int dx, const int dy, 
const int w, const int h, const int is_chroma)
 {
-const VVCFrameContext *fc = lc->fc;
 const int x_off   = SCALED_INT(x);
 const int y_off   = SCALED_INT(y);
 const int x_end   = SCALED_INT(x + w * dx);
@@ -316,8 +315,6 @@ static void emulated_edge_scaled(VVCLocalContext *lc, const 
uint8_t **src, ptrdi
 const int block_w = x_end - x_off + (x_end == x_last);
 const int block_h = *src_height = y_end - y_off + (y_end == 
y_last);
 
-*src  += y_off * *src_stride + (x_off * (1 << fc->ps.sps->pixel_shift));
-
 MC_EMULATED_EDGE(lc->edge_emu_buffer, src, src_stride, x_off, y_off);
 }
 
@@ -414,7 +411,6 @@ static void luma_prof_uni(VVCLocalContext *lc, uint8_t 
*dst, const ptrdiff_t dst
 
 x_off += mv->x >> 4;
 y_off += mv->y >> 4;
-src   += y_off * src_stride + (x_off * (1 << fc->ps.sps->pixel_shift));
 
 MC_EMULATED_EDGE(lc->edge_emu_buffer, &src, &src_stride, x_off, y_off);
 if (cb_prof_flag) {
@@ -444,8 +440,8 @@ static void luma_prof(VVCLocalContext *lc, int16_t *dst, 
const VVCFrame *ref,
 const int idx = av_log2(block_w) - 1;
 const int is_chroma   = 0;
 uint16_t *prof_tmp= lc->tmp2 + PROF_TEMP_OFFSET;
-ptrdiff_t src_stride  = ref->frame->linesize[0];
-const uint8_t *src= ref->frame->data[0] + oy * src_stride + (ox * 
(1 << fc->ps.sps->pixel_shift));
+ptrdiff_t src_stride  = ref->frame->linesize[LUMA];
+const uint8_t *src= ref->frame->data[LUMA];
 const int8_t *hf  = 
ff_vvc_inter_luma_filters[VVC_INTER_LUMA_FILTER_TYPE_AFFINE][mx];
 const int8_t *vf  = 
ff_vvc_inter_luma_filters[VVC_INTER_LUMA_FILTER_TYPE_AFFINE][my];
 
@@ -704,7 +700,7 @@ static void dmvr_mv_refine(VVCLocalContext *lc, MvField 
*mvf, MvField *orig_mv,
 const int oy= y_off + (mv->y >> 4) - sr_range;
 const VVCFrame *ref = refs[i];
 ptrdiff_t src_stride= ref->frame->linesize[LUMA];
-const uint8_t *src  = ref->frame->data[LUMA] + oy * src_stride + 
(ox * (1 << fc->ps.sps->pixel_shift));
+const uint8_t *src  = ref->frame->data[LUMA];
 MC_EMULATED_EDGE_BILINEAR(lc->edge_emu_buffer, &src, &src_stride, ox, 
oy);
 fc->vvcdsp.inter.dmvr[!!my][!!mx](tmp[i], src, src_stride, pred_h, mx, 
my, pred_w);
 }
-- 
2.34.1

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

To unsubscribe,

[FFmpeg-devel] [PATCH v2 3/5] avcodec/vvcdec: refact out emulated_edge_no_wrap

[Nuo Mi]

prepare for refrence wraparound
---
 libavcodec/vvc/inter.c | 91 --
 1 file changed, 61 insertions(+), 30 deletions(-)

diff --git a/libavcodec/vvc/inter.c b/libavcodec/vvc/inter.c
index 07b55c4bac..aacd5d8da0 100644
--- a/libavcodec/vvc/inter.c
+++ b/libavcodec/vvc/inter.c
@@ -30,46 +30,53 @@
 #define PROF_TEMP_OFFSET (MAX_PB_SIZE + 32)
 static const int bcw_w_lut[] = {4, 5, 3, 10, -2};
 
-static void subpic_offset(int *x_off, int *y_off,
-const VVCSPS *sps, const VVCPPS *pps, const int subpic_idx, const int 
is_chroma)
+typedef struct VVCRect {
+int l;  // left
+int t;  // top
+int r;  // right
+int b;  // bottom
+} VVCRect;
+
+static void subpic_get_rect(VVCRect *r, const VVCFrame *src_frame, const int 
subpic_idx, const int is_chroma)
 {
-*x_off -= pps->subpic_x[subpic_idx] >> sps->hshift[is_chroma];
-*y_off -= pps->subpic_y[subpic_idx] >> sps->vshift[is_chroma];
+const VVCSPS *sps = src_frame->sps;
+const VVCPPS *pps = src_frame->pps;
+const int hs  = sps->hshift[is_chroma];
+const int vs  = sps->vshift[is_chroma];
+
+r->l = pps->subpic_x[subpic_idx] >> hs;
+r->t = pps->subpic_y[subpic_idx] >> vs;
+r->r = r->l + (pps->subpic_width[subpic_idx]  >> hs);
+r->b = r->t + (pps->subpic_height[subpic_idx] >> vs);
 }
 
-static void subpic_width_height(int *pic_width, int *pic_height,
-const VVCSPS *sps, const VVCPPS *pps, const int subpic_idx, const int 
is_chroma)
+// clip to subblock and subpicture process in 8.5.6.3.2 Luma sample 
interpolation filtering process
+static void clip_to_subpic(int *x_off, int *y_off, int *pic_width, int 
*pic_height, const VVCRect *subpic, const VVCRect *sb, const int dmvr_clip)
 {
-*pic_width  = pps->subpic_width[subpic_idx]  >> sps->hshift[is_chroma];
-*pic_height = pps->subpic_height[subpic_idx] >> sps->vshift[is_chroma];
+const int l = dmvr_clip ? FFMIN(FFMAX(subpic->l, sb->l), subpic->r - 1) : 
subpic->l;
+const int t = dmvr_clip ? FFMIN(FFMAX(subpic->t, sb->t), subpic->b - 1) : 
subpic->t;
+const int r = dmvr_clip ? FFMAX(FFMIN(subpic->r, sb->r), subpic->l + 1) : 
subpic->r;
+const int b = dmvr_clip ? FFMAX(FFMIN(subpic->b, sb->b), subpic->t + 1) : 
subpic->b;
+
+*x_off -= l;
+*y_off -= t;
+*pic_width  = r - l;
+*pic_height = b - t;
 }
 
-static void emulated_edge(const VVCLocalContext *lc, uint8_t *dst,
-const uint8_t **src, ptrdiff_t *src_stride, const VVCFrame *src_frame,
-int x_sb, int y_sb, int x_off, int y_off, const int block_w, const int 
block_h,
-const int is_chroma, const int extra_before, const int extra_after)
+static void emulated_edge_no_wrap(const VVCLocalContext *lc, uint8_t *dst,
+const uint8_t **src, ptrdiff_t *src_stride,
+int x_off, int y_off, const int block_w, const int block_h,
+const int extra_before, const int extra_after,
+const VVCRect *subpic, const VVCRect *sb, const int dmvr_clip)
 {
 const VVCFrameContext *fc = lc->fc;
-const VVCSPS *sps = src_frame->sps;
-const VVCPPS *pps = src_frame->pps;
-const int subpic_idx  = lc->sc->sh.r->curr_subpic_idx;
 const int extra   = extra_before + extra_after;
-const int dmvr_clip   = x_sb != x_off || y_sb != y_off;
 int pic_width, pic_height;
 
 *src  += y_off * *src_stride + (x_off * (1 << fc->ps.sps->pixel_shift));
 
-subpic_offset(&x_off, &y_off, sps, pps, subpic_idx, is_chroma);
-subpic_offset(&x_sb, &y_sb, sps, pps, subpic_idx, is_chroma);
-subpic_width_height(&pic_width, &pic_height, sps, pps, subpic_idx, 
is_chroma);
-if (dmvr_clip) {
-const int start_x = FFMIN(FFMAX(x_sb - extra_before, 0), pic_width  - 
1);
-const int start_y = FFMIN(FFMAX(y_sb - extra_before, 0), pic_height - 
1);
-pic_width  = FFMAX(FFMIN(pic_width, x_sb + block_w + extra_after) - 
start_x, 1);
-pic_height = FFMAX(FFMIN(pic_height, y_sb + block_h + extra_after) - 
start_y, 1);
-x_off -= start_x;
-y_off -= start_y;
-}
+clip_to_subpic(&x_off, &y_off, &pic_width, &pic_height, subpic, sb, 
dmvr_clip);
 
 if (dmvr_clip || x_off < extra_before || y_off < extra_before ||
 x_off >= pic_width - block_w - extra_after ||
@@ -88,16 +95,32 @@ static void emulated_edge(const VVCLocalContext *lc, 
uint8_t *dst,
 }
 }
 
+static void emulated_edge(const VVCLocalContext *lc, uint8_t *dst,
+const uint8_t **src, ptrdiff_t *src_stride, const VVCFrame *src_frame,
+int x_sb, int y_sb, int x_off, int y_off, int block_w, int block_h, const 
int wrap_enabled,
+const int is_chroma, const int extra_before, const int extra_after)
+{
+const int subpic_idx   = lc->sc->sh.r->curr_subpic_idx;
+const int dmvr_clip= x_sb != x_off || y_sb != y_off;
+VVCRect sb = { x_sb - extra_before, y_sb - extra_before, 
x_sb + block_w + 

[FFmpeg-devel] [PATCH v2 4/5] avcodec/vvcdec: misc, reindent inter.c

[Nuo Mi]

---
 libavcodec/vvc/inter.c | 278 -
 1 file changed, 139 insertions(+), 139 deletions(-)

diff --git a/libavcodec/vvc/inter.c b/libavcodec/vvc/inter.c
index aacd5d8da0..09575eb2b4 100644
--- a/libavcodec/vvc/inter.c
+++ b/libavcodec/vvc/inter.c
@@ -127,14 +127,14 @@ static void emulated_edge(const VVCLocalContext *lc, 
uint8_t *dst,
 static int derive_weight_uni(int *denom, int *wx, int *ox,
 const VVCLocalContext *lc, const MvField *mvf, const int c_idx)
 {
-const VVCFrameContext *fc   = lc->fc;
-const VVCPPS *pps   = fc->ps.pps;
-const VVCSH *sh = &lc->sc->sh;
-const int weight_flag   = (IS_P(sh->r) && 
pps->r->pps_weighted_pred_flag) ||
+const VVCFrameContext *fc = lc->fc;
+const VVCPPS *pps = fc->ps.pps;
+const VVCSH *sh   = &lc->sc->sh;
+const int weight_flag = (IS_P(sh->r) && 
pps->r->pps_weighted_pred_flag) ||
   (IS_B(sh->r) && 
pps->r->pps_weighted_bipred_flag);
 if (weight_flag) {
-const int lx= mvf->pred_flag - PF_L0;
-const PredWeightTable *w= pps->r->pps_wp_info_in_ph_flag ? 
&fc->ps.ph.pwt : &sh->pwt;
+const int lx = mvf->pred_flag - PF_L0;
+const PredWeightTable *w = pps->r->pps_wp_info_in_ph_flag ? 
&fc->ps.ph.pwt : &sh->pwt;
 
 *denom = w->log2_denom[c_idx > 0];
 *wx = w->weight[lx][c_idx][mvf->ref_idx[lx]];
@@ -147,11 +147,11 @@ static int derive_weight_uni(int *denom, int *wx, int *ox,
 static int derive_weight(int *denom, int *w0, int *w1, int *o0, int *o1,
 const VVCLocalContext *lc, const MvField *mvf, const int c_idx, const int 
dmvr_flag)
 {
-const VVCFrameContext *fc   = lc->fc;
-const VVCPPS *pps   = fc->ps.pps;
-const VVCSH *sh = &lc->sc->sh;
-const int bcw_idx   = mvf->bcw_idx;
-const int weight_flag   = (IS_P(sh->r) && 
pps->r->pps_weighted_pred_flag) ||
+const VVCFrameContext *fc = lc->fc;
+const VVCPPS *pps = fc->ps.pps;
+const VVCSH *sh   = &lc->sc->sh;
+const int bcw_idx = mvf->bcw_idx;
+const int weight_flag = (IS_P(sh->r) && 
pps->r->pps_weighted_pred_flag) ||
   (IS_B(sh->r) && 
pps->r->pps_weighted_bipred_flag && !dmvr_flag);
 if ((!weight_flag && !bcw_idx) || (bcw_idx && lc->cu->ciip_flag))
 return 0;
@@ -162,7 +162,7 @@ static int derive_weight(int *denom, int *w0, int *w1, int 
*o0, int *o1,
 *w0 = 8 - *w1;
 *o0 = *o1 = 0;
 } else {
-const VVCPPS *pps = fc->ps.pps;
+const VVCPPS *pps= fc->ps.pps;
 const PredWeightTable *w = pps->r->pps_wp_info_in_ph_flag ? 
&fc->ps.ph.pwt : &sh->pwt;
 
 *denom = w->log2_denom[c_idx > 0];
@@ -179,20 +179,20 @@ static int derive_weight(int *denom, int *w0, int *w1, 
int *o0, int *o1,
 static void mc(VVCLocalContext *lc, int16_t *dst, const VVCFrame *ref, const 
Mv *mv,
 int x_off, int y_off, const int block_w, const int block_h, const int 
c_idx)
 {
-const VVCFrameContext *fc   = lc->fc;
-const PredictionUnit *pu= &lc->cu->pu;
-const uint8_t *src  = ref->frame->data[c_idx];
-ptrdiff_t src_stride= ref->frame->linesize[c_idx];
-const int is_chroma = !!c_idx;
-const int hs= fc->ps.sps->hshift[c_idx];
-const int vs= fc->ps.sps->vshift[c_idx];
-const int idx   = av_log2(block_w) - 1;
-const intptr_t mx   = av_mod_uintp2(mv->x, 4 + hs) << (is_chroma - 
hs);
-const intptr_t my   = av_mod_uintp2(mv->y, 4 + vs) << (is_chroma - 
vs);
-const int hpel_if_idx   = (is_chroma || pu->merge_gpm_flag) ? 0 : 
pu->mi.hpel_if_idx;
-const int8_t *hf= INTER_FILTER(hpel_if_idx, mx);
-const int8_t *vf= INTER_FILTER(hpel_if_idx, my);
-const int wrap_enabled  = 
fc->ps.pps->r->pps_ref_wraparound_enabled_flag;
+const VVCFrameContext *fc = lc->fc;
+const PredictionUnit *pu  = &lc->cu->pu;
+const uint8_t *src= ref->frame->data[c_idx];
+ptrdiff_t src_stride  = ref->frame->linesize[c_idx];
+const int is_chroma   = !!c_idx;
+const int hs  = fc->ps.sps->hshift[c_idx];
+const int vs  = fc->ps.sps->vshift[c_idx];
+const int idx = av_log2(block_w) - 1;
+const intptr_t mx = av_mod_uintp2(mv->x, 4 + hs) << (is_chroma - 
hs);
+const intptr_t my = av_mod_uintp2(mv->y, 4 + vs) << (is_chroma - 
vs);
+const int hpel_if_idx = (is_chroma || pu->merge_gpm_flag) ? 0 : 
pu->mi.hpel_if_idx;
+const int8_t *hf  = INTER_FILTER(hpel_if_idx, mx);
+const int8_t *vf  = INTER_FILTER(hpel_if_idx, my);
+const int wrap_enabled= fc->ps.pps->r->pps_ref_wraparound_enabled_flag;
 
 x_off += mv->x >> (4 + hs);
 y_off += mv->y >> (4 + v

[FFmpeg-devel] [PATCH v2 5/5] avcodec/vvcdec: support mv wraparound

[Nuo Mi]

A 360 video specific tool
see https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9503377

passed files:
DMVR_A_Huawei_3.bit
WRAP_D_InterDigital_4.bit
WRAP_A_InterDigital_4.bit
WRAP_B_InterDigital_4.bit
WRAP_C_InterDigital_4.bit
ERP_A_MediaTek_3.bit
---
 libavcodec/vvc/inter.c  | 81 -
 tests/ref/fate/vvc-conformance-WRAP_A_4 | 16 ++---
 2 files changed, 87 insertions(+), 10 deletions(-)

diff --git a/libavcodec/vvc/inter.c b/libavcodec/vvc/inter.c
index 09575eb2b4..98cb43322f 100644
--- a/libavcodec/vvc/inter.c
+++ b/libavcodec/vvc/inter.c
@@ -95,20 +95,97 @@ static void emulated_edge_no_wrap(const VVCLocalContext 
*lc, uint8_t *dst,
 }
 }
 
+static void emulated_half(const VVCLocalContext *lc, uint8_t *dst, const 
ptrdiff_t dst_stride,
+const uint8_t *src, const ptrdiff_t src_stride, const int ps,
+int x_off, int y_off, const int block_w, const int block_h,
+const VVCRect *subpic,const VVCRect *half_sb, const int dmvr_clip)
+{
+const VVCFrameContext *fc = lc->fc;
+int pic_width, pic_height;
+
+src += y_off * src_stride + x_off * (1 << ps);
+
+clip_to_subpic(&x_off, &y_off, &pic_width, &pic_height, subpic, half_sb, 
dmvr_clip);
+
+fc->vdsp.emulated_edge_mc(dst, src, dst_stride, src_stride,
+block_w, block_h, x_off, y_off, pic_width, pic_height);
+}
+
+static void sb_set_lr(VVCRect *sb, const int l, const int r)
+{
+sb->l = l;
+sb->r = r;
+}
+
+static void sb_wrap(VVCRect *sb, const int wrap)
+{
+sb_set_lr(sb, sb->l + wrap, sb->r + wrap);
+}
+
 static void emulated_edge(const VVCLocalContext *lc, uint8_t *dst,
 const uint8_t **src, ptrdiff_t *src_stride, const VVCFrame *src_frame,
 int x_sb, int y_sb, int x_off, int y_off, int block_w, int block_h, const 
int wrap_enabled,
 const int is_chroma, const int extra_before, const int extra_after)
 {
+const VVCSPS *sps  = src_frame->sps;
+const VVCPPS *pps  = src_frame->pps;
+const int ps   = sps->pixel_shift;
 const int subpic_idx   = lc->sc->sh.r->curr_subpic_idx;
+const int extra= extra_before + extra_after;
 const int dmvr_clip= x_sb != x_off || y_sb != y_off;
+const int dmvr_left= FFMAX(x_off, x_sb) - extra_before;
+const int dmvr_right   = FFMIN(x_off, x_sb) + block_w + extra_after;
+const int left = x_off - extra_before;
+const int top  = y_off - extra_before;
+const int pic_width= pps->width >> sps->hshift[is_chroma];
+const int wrap = pps->ref_wraparound_offset << 
(sps->min_cb_log2_size_y - sps->hshift[is_chroma]);
+const ptrdiff_t dst_stride = EDGE_EMU_BUFFER_STRIDE << ps;
 VVCRect sb = { x_sb - extra_before, y_sb - extra_before, 
x_sb + block_w + extra_after, y_sb + block_h + extra_after };
 VVCRect subpic;
 
 subpic_get_rect(&subpic, src_frame, subpic_idx, is_chroma);
 
-return emulated_edge_no_wrap(lc, dst, src, src_stride,
-x_off, y_off, block_w, block_h, extra_before, extra_after, &subpic, 
&sb, dmvr_clip);
+if (!wrap_enabled || (dmvr_left >= 0 && dmvr_right <= pic_width)) {
+return emulated_edge_no_wrap(lc, dst, src, src_stride,
+x_off, y_off, block_w, block_h, extra_before, extra_after, 
&subpic, &sb, dmvr_clip);
+}
+if (dmvr_right <= 0) {
+sb_wrap(&sb, wrap);
+return emulated_edge_no_wrap(lc, dst, src, src_stride,
+x_off + wrap, y_off, block_w, block_h, extra_before, extra_after, 
&subpic, &sb, dmvr_clip);
+}
+if (dmvr_left >= pic_width) {
+sb_wrap(&sb, -wrap);
+return emulated_edge_no_wrap(lc, dst, src, src_stride,
+x_off - wrap, y_off, block_w, block_h, extra_before, extra_after, 
&subpic, &sb, dmvr_clip);
+}
+
+block_w += extra;
+block_h += extra;
+
+// half block are wrapped
+if (dmvr_left < 0 ) {
+const int w = -left;
+VVCRect half_sb = { sb.l + wrap, sb.t, 0 + wrap, sb.b };
+emulated_half(lc, dst, dst_stride, *src, *src_stride, ps,
+left + wrap, top, w, block_h, &subpic, &half_sb, dmvr_clip);
+
+sb_set_lr(&half_sb, 0, sb.r);
+emulated_half(lc, dst +  (w << ps), dst_stride, *src, *src_stride, ps,
+0, top, block_w - w, block_h, &subpic, &half_sb, dmvr_clip);
+} else {
+const int w = pic_width - left;
+VVCRect half_sb = { sb.l, sb.t, pic_width, sb.b };
+emulated_half(lc, dst, dst_stride, *src, *src_stride, ps,
+left, top, w, block_h, &subpic, &half_sb, dmvr_clip);
+
+sb_set_lr(&half_sb, pic_width - wrap, sb.r - wrap);
+emulated_half(lc, dst +  (w << ps), dst_stride, *src, *src_stride, ps,
+pic_width - wrap , top, block_w - w, block_h, &subpic, &half_sb, 
dmvr_clip);
+}
+
+*src = dst + extra_before * dst_stride + (extra_before << ps);
+*src_stride = dst_

Re: [FFmpeg-devel] [PATCH 5/5] avcodec/vvcdec: support mv wraparound

[Nuo Mi]

On Tue, Jun 4, 2024 at 8:41 AM Michael Niedermayer 
wrote:

> On Mon, Jun 03, 2024 at 08:51:16PM +0800, Nuo Mi wrote:
> > A 360 video specific tool
> > see https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=9503377
> >
> > passed files:
> > DMVR_A_Huawei_3.bit
> > WRAP_D_InterDigital_4.bit
> > WRAP_A_InterDigital_4.bit
> > WRAP_B_InterDigital_4.bit
> > WRAP_C_InterDigital_4.bit
> > ERP_A_MediaTek_3.bit
> > ---
> >  libavcodec/vvc/inter.c | 81 --
> >  1 file changed, 79 insertions(+), 2 deletions(-)
>
> seems to break fate-vvc-conformance-WRAP_A_4, maybe the fate checksums
> need to be updated ?
>
Hi Michael,
Sorry for missing the fate test
Yes, we need to update the reference. v2 will fix it

thank you.

>
> TESTvvc-conformance-WRAP_A_4
> --- ./tests/ref/fate/vvc-conformance-WRAP_A_4   2024-06-03
> 22:55:42.173081332 +0200
> +++ tests/data/fate/vvc-conformance-WRAP_A_42024-06-04
> 02:39:44.835650168 +0200
> @@ -4,11 +4,11 @@
>  #dimensions 0: 1680x832
>  #sar 0: 0/1
>  0,  0,  0,1,  4193280, 0xbd70f1b3
> -0,  1,  1,1,  4193280, 0x64e160d5
> -0,  2,  2,1,  4193280, 0xd20722ea
> -0,  3,  3,1,  4193280, 0xa1d00055
> -0,  4,  4,1,  4193280, 0xe3dcb9cd
> -0,  5,  5,1,  4193280, 0xcf97b6cf
> -0,  6,  6,1,  4193280, 0xd87b73d0
> -0,  7,  7,1,  4193280, 0x0f8ee2bc
> -0,  8,  8,1,  4193280, 0x76607ca4
> +0,  1,  1,1,  4193280, 0x491104c9
> +0,  2,  2,1,  4193280, 0xf600c2c1
> +0,  3,  3,1,  4193280, 0x1e3c8e2b
> +0,  4,  4,1,  4193280, 0xad275e45
> +0,  5,  5,1,  4193280, 0xcd6103d7
> +0,  6,  6,1,  4193280, 0x0ec8cfbd
> +0,  7,  7,1,  4193280, 0x2f664486
> +0,  8,  8,1,  4193280, 0x543eb3fc
> Test vvc-conformance-WRAP_A_4 failed. Look at
> tests/data/fate/vvc-conformance-WRAP_A_4.err for details.
> make: *** [tests/Makefile:311: fate-vvc-conformance-WRAP_A_4] Error 1
>
> 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.
> ___
> 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] lavc/vvc: Reallocate pixel buffers if pixel shift changes

[Nuo Mi]

On Mon, Jun 3, 2024 at 9:06 PM Frank Plowman  wrote:

> Allocations in the following lines depend on the pixel shift, and so
> these buffers must be reallocated if the pixel shift changes.  Patch
> fixes segmentation faults in fuzzed bitstreams.
>
> Signed-off-by: Frank Plowman 
> ---
>  libavcodec/vvc/dec.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
> index e53ad4e607..f5603306f3 100644
> --- a/libavcodec/vvc/dec.c
> +++ b/libavcodec/vvc/dec.c
> @@ -214,7 +214,8 @@ static void pixel_buffer_nz_tl_init(TabList *l,
> VVCFrameContext *fc)
>  const int c_end  = chroma_idc ? VVC_MAX_SAMPLE_ARRAYS : 1;
>  const int changed= fc->tab.sz.chroma_format_idc != chroma_idc ||
>  fc->tab.sz.width != width || fc->tab.sz.height != height ||
> -fc->tab.sz.ctu_width != ctu_width || fc->tab.sz.ctu_height !=
> ctu_height;
> +fc->tab.sz.ctu_width != ctu_width || fc->tab.sz.ctu_height !=
> ctu_height ||
> +fc->tab.sz.pixel_shift != ps;
>
> Applied.

Thank you, Frank.

>  tl_init(l, 0, changed);
>
> --
> 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 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] [RFC] STF 2025

[Vittorio Giovara]

On Tue, Jun 4, 2024 at 2:02 PM Paul B Mahol  wrote:

> On Tue, Jun 4, 2024 at 12:59 PM Vittorio Giovara <
> vittorio.giov...@gmail.com>
> wrote:
>
> > On Tue, Jun 4, 2024 at 12:09 PM Paul B Mahol  wrote:
> >
> > > On Tue, Jun 4, 2024 at 9:09 AM Vittorio Giovara <
> > > vittorio.giov...@gmail.com>
> > > wrote:
> > >
> > > > On Tue, Jun 4, 2024 at 8:55 AM Paul B Mahol 
> wrote:
> > > >
> > > > > On Tue, Jun 4, 2024 at 8:53 AM Vittorio Giovara <
> > > > > vittorio.giov...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel
> <
> > > > > > ffmpeg-devel@ffmpeg.org> wrote:
> > > > > >
> > > > > > > > Reposting my question/comment here since Thilo hasn't had a
> > > chance
> > > > to
> > > > > > > > respond, but shouldn't these kinds of requests go through the
> > GA?
> > > > If
> > > > > > > > anybody can do whatever they want with the ffmpeg name, then
> > > what's
> > > > > the
> > > > > > > > point of voting and following the established process?
> > > > > > >
> > > > > > > Probably? I'm not actually sure what the process is for getting
> > an
> > > > > FFmpeg
> > > > > > > booth at a conference. Is there a documented process somewhere
> > for
> > > > how
> > > > > > this
> > > > > > > should be done? If not this might be a good opportunity to
> create
> > > > one.
> > > > > > >
> > > > > >
> > > > > > Agreed, do you have a draft you could share as a base of
> > discussion?
> > > > Once
> > > > > > defined, we could have the GA vote on it
> > > > > >
> > > > > >
> > > > > > > It might also make for a good topic of discussion at VDD. For
> how
> > > > much
> > > > > > > drama there was about NAB on the list I was surprised there was
> > > zero
> > > > > > > discussion about it at FOSDEM.
> > > > > > >
> > > > > >
> > > > > > There were probably more important topics to discuss and the
> > > lingering
> > > > > hope
> > > > > > that the problematic points would have been handled better than
> by
> > > > > calling
> > > > > > people trolls
> > > > > >
> > > > > >
> > > > > > > Regarding the "or you" part, I wasn't involved in securing
> > > > sponsorship
> > > > > > for
> > > > > > > NAB or IBC. I did volunteer to help with NAB because I happen
> to
> > > live
> > > > > in
> > > > > > > Vegas and I enjoy spending time with other ffmpeg developers.
> I'm
> > > > happy
> > > > > > to
> > > > > > > help at NAB next year as well should it happen again.
> > > > > > >
> > > > > >
> > > > > > Noted, it should have said "or anybody willing to host/help a
> > booth"
> > > > > >
> > > > > > I have no plans to attend IBC and no involvement with the FFmpeg
> > > booth
> > > > at
> > > > > > > IBC. I am merely trying to correct the perception that NAB was
> > > > > > > cost-problematic, since no money was paid by the project for
> NAB.
> > > > > > >
> > > > > >
> > > > > > I don't think anybody is suggesting that booths are
> > cost-problematic,
> > > > but
> > > > > > rather they are lacking in process (one shouldn't allowed use
> > ffmpeg
> > > > name
> > > > > > "just because") and in scope (aka "the why" and what kind of
> > results
> > > > are
> > > > > > expected by investing time in said booth)
> > > > > >
> > > > >
> > > > > Said by prominent LibAV developer.
> > > > >
> > > >
> > > > reported to CC :)
> > > >
> > >
> > > CC is fully controlled by prominent LibAV developers.
> > >
> >
> > Not only is this factually incorrect, it's also unrelated to the topic at
> > hand. No worries, this infringement is being reported to the CC as well,
> > but please try to make an effort at doing better at least.
> > Thank you
> >
>
> Do not trust LibAV developers even when they are giving you gifts.
>

I'm not giving you anything, please can you stop? I don't want to flood the
CC with emails, but I'll do so if that helps stifle this kind of behavior.
Please disconnect, grow up, be nicer to your fellow community members, and
just do better.
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] [PATCH] libavcodec/libxvid: code cleanup (replace magic numbers)

[Ramiro Polla]

On Thu, May 30, 2024 at 11:24 PM Sean McGovern  wrote:
> On Thu, May 30, 2024 at 5:20 PM Ramiro Polla  wrote:
> >
> > ---
> >  libavcodec/libxvid.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/libxvid.c b/libavcodec/libxvid.c
> > index b9ac39429d..a490f16b3f 100644
> > --- a/libavcodec/libxvid.c
> > +++ b/libavcodec/libxvid.c
> > @@ -422,13 +422,13 @@ static av_cold int xvid_encode_init(AVCodecContext 
> > *avctx)
> >
> >  /* Decide how we should decide blocks */
> >  switch (avctx->mb_decision) {
> > -case 2:
> > +case FF_MB_DECISION_RD:
> >  x->vop_flags |=  XVID_VOP_MODEDECISION_RD;
> >  x->me_flags  |=  XVID_ME_HALFPELREFINE8_RD|
> >   XVID_ME_QUARTERPELREFINE8_RD |
> >   XVID_ME_EXTSEARCH_RD |
> >   XVID_ME_CHECKPREDICTION_RD;
> > -case 1:
> > +case FF_MB_DECISION_BITS:
> >  if (!(x->vop_flags & XVID_VOP_MODEDECISION_RD))
> >  x->vop_flags |= XVID_VOP_FAST_MODEDECISION_RD;
> >  x->me_flags |= XVID_ME_HALFPELREFINE16_RD |
> > --
> > 2.30.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".
>
> This gets a +1 from me.

I'll apply tomorrow.
___
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/2] ffplay: add -scaling_quality option for SDL

[Ramiro Polla]

On Thu, May 30, 2024 at 11:36 PM Ramiro Polla  wrote:
>
> ---
>  doc/ffplay.texi  | 2 ++
>  fftools/ffplay.c | 6 +-
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/doc/ffplay.texi b/doc/ffplay.texi
> index 93f77eeece..60f883e159 100644
> --- a/doc/ffplay.texi
> +++ b/doc/ffplay.texi
> @@ -72,6 +72,8 @@ as 100.
>  Force format.
>  @item -window_title @var{title}
>  Set window title (default is the input filename).
> +@item -scaling_quality @var{value}
> +Set SDL_HINT_RENDER_SCALE_QUALITY value (default is "linear").
>  @item -left @var{title}
>  Set the x position for the left of the window (default is a centered window).
>  @item -top @var{title}
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index b9d11eecee..75d2bec777 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -351,6 +351,7 @@ static int filter_nbthreads = 0;
>  static int enable_vulkan = 0;
>  static char *vulkan_params = NULL;
>  static const char *hwaccel = NULL;
> +static const char *scaling_quality = NULL;
>
>  /* current context */
>  static int is_full_screen;
> @@ -3683,6 +3684,7 @@ static const OptionDef options[] = {
>  { "framedrop",  OPT_TYPE_BOOL,   OPT_EXPERT, { &framedrop }, 
> "drop frames when cpu is too slow", "" },
>  { "infbuf", OPT_TYPE_BOOL,   OPT_EXPERT, { &infinite_buffer 
> }, "don't limit the input buffer size (useful with realtime streams)", "" },
>  { "window_title",   OPT_TYPE_STRING,  0, { &window_title }, 
> "set window title", "window title" },
> +{ "scaling_quality",OPT_TYPE_STRING, OPT_EXPERT, { &scaling_quality 
> }, "set SDL_HINT_RENDER_SCALE_QUALITY value (default=linear)", "value" },
>  { "left",   OPT_TYPE_INT,OPT_EXPERT, { &screen_left }, 
> "set the x position for the left of the window", "x pos" },
>  { "top",OPT_TYPE_INT,OPT_EXPERT, { &screen_top }, 
> "set the y position for the top of the window", "y pos" },
>  { "vf", OPT_TYPE_FUNC, OPT_FUNC_ARG | OPT_EXPERT, { 
> .func_arg = opt_add_vfilter }, "set video filters", "filter_graph" },
> @@ -3831,7 +3833,9 @@ int main(int argc, char **argv)
>  }
>  }
>  window = SDL_CreateWindow(program_name, SDL_WINDOWPOS_UNDEFINED, 
> SDL_WINDOWPOS_UNDEFINED, default_width, default_height, flags);
> -SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear");
> +if (!scaling_quality)
> +scaling_quality = "linear";
> +SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, scaling_quality);
>  if (!window) {
>  av_log(NULL, AV_LOG_FATAL, "Failed to create window: %s", 
> SDL_GetError());
>  do_exit(NULL);
> --
> 2.39.2
>

Can anyone comment on this? I had a few doubts on this patch:
- does the option name properly convey its functionality?
- is the documentation too terse?
- should we include the accepted values in the documentation, even
though they are sdl-specific?
___
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] avcodec/mpegvideo_enc: give magic number a name

[Ramiro Polla]

---
 libavcodec/mpegvideo_enc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 73a9082265..82bab43e14 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -562,7 +562,7 @@ av_cold int ff_mpv_encode_init(AVCodecContext *avctx)
 
 if ((s->mpv_flags & FF_MPV_FLAG_QP_RD) &&
 avctx->mb_decision != FF_MB_DECISION_RD) {
-av_log(avctx, AV_LOG_ERROR, "QP RD needs mbd=2\n");
+av_log(avctx, AV_LOG_ERROR, "QP RD needs mbd=rd\n");
 return AVERROR(EINVAL);
 }
 
-- 
2.30.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] [PATCH] libswscale/x86/yuv_2_rgb: fix some comments

[Ramiro Polla]

---
 libswscale/x86/yuv_2_rgb.asm | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libswscale/x86/yuv_2_rgb.asm b/libswscale/x86/yuv_2_rgb.asm
index e3470fd9ad..a1f9134e08 100644
--- a/libswscale/x86/yuv_2_rgb.asm
+++ b/libswscale/x86/yuv_2_rgb.asm
@@ -195,15 +195,15 @@ cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters
 mova m5, m7
 paddsw m3, m0 ; B1 B3 B5 B7 ...
 paddsw m5, m1 ; R1 R3 R5 R7 ...
-paddsw m7, m2 ; G1 G3 G4 G7 ...
+paddsw m7, m2 ; G1 G3 G5 G7 ...
 paddsw m0, m6 ; B0 B2 B4 B6 ...
 paddsw m1, m6 ; R0 R2 R4 R6 ...
 paddsw m2, m6 ; G0 G2 G4 G6 ...
 
 %if %3 == 24 ; PACK RGB24
 %define depth 3
-packuswb m0, m3 ; R0 R2 R4 R6 ... R1 R3 R5 R7 ...
-packuswb m1, m5 ; B0 B2 B4 B6 ... B1 B3 B5 B7 ...
+packuswb m0, m3 ; B0 B2 B4 B6 ... B1 B3 B5 B7 ...
+packuswb m1, m5 ; R0 R2 R4 R6 ... R1 R3 R5 R7 ...
 packuswb m2, m7 ; G0 G2 G4 G6 ... G1 G3 G5 G7 ...
 mova m3, m_red
 mova m6, m_blue
@@ -248,7 +248,7 @@ cglobal %1_420_%2%3, GPR_num, GPR_num, reg_num, parameters
 psrlq m5, 32
 movd [imageq + 20], m2 ; -- -- G7 B7
 movd [imageq + 18], m5 ; R6 G6 B6 R7
-%endif ; mmsize = 8
+%endif ; cpuflag
 %else ; mmsize == 16
 pshufb m3, [rgb24_shuf1] ; r0  g0  r6  g6  r12 g12 r2  g2  r8  g8  r14 g14 
r4  g4  r10 g10
 pshufb m6, [rgb24_shuf2] ; b10 r11 b0  r1  b6  r7  b12 r13 b2  r3  b8  r9  
b14 r15 b4  r5
-- 
2.30.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] [PATCH 3/5] avutil/aarch64: Skip define AV_READ_TIME for apple

[Zhao Zhili]

From: Zhao Zhili 

It will fallback to mach_absolute_time inside libavutil/timer.h
---
 libavutil/aarch64/timer.h | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/libavutil/aarch64/timer.h b/libavutil/aarch64/timer.h
index 8b28fd354c..fadc9568f8 100644
--- a/libavutil/aarch64/timer.h
+++ b/libavutil/aarch64/timer.h
@@ -24,13 +24,7 @@
 #include 
 #include "config.h"
 
-#if defined(__APPLE__)
-
-#include 
-
-#define AV_READ_TIME mach_absolute_time
-
-#elif HAVE_INLINE_ASM
+#if HAVE_INLINE_ASM && !defined(__APPLE__)
 
 #define AV_READ_TIME read_time
 
-- 
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] [PATCH 1/5] checkasm/sw_rgb: test rgb24 to yuv

[Zhao Zhili]

From: Zhao Zhili 

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

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index 7cd815e5be..cc9b957461 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -24,6 +24,8 @@
 #include "libavutil/mem_internal.h"
 
 #include "libswscale/rgb2rgb.h"
+#include "libswscale/swscale.h"
+#include "libswscale/swscale_internal.h"
 
 #include "checkasm.h"
 
@@ -179,8 +181,89 @@ static void check_interleave_bytes(void)
 }
 }
 
+#define MAX_LINE_SIZE 1920
+
+static void check_rgb_to_y(struct SwsContext *ctx)
+{
+static const int input_sizes[] = {8, 128, 1280, 1080, MAX_LINE_SIZE};
+
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
+
+declare_func(void, uint8_t *dst, const uint8_t *src,
+ const uint8_t *unused1, const uint8_t *unused2, int width,
+ uint32_t *rgb2yuv, void *opq);
+
+randomize_buffers(src, MAX_LINE_SIZE * 3);
+
+for (int i = 0; i < FF_ARRAY_ELEMS(input_sizes); i++) {
+int w = input_sizes[i];
+
+if (check_func(ctx->lumToYV12, "rgb24_to_y_%d", w)) {
+memset(dst0_y, 0xFA, MAX_LINE_SIZE * 2);
+memset(dst1_y, 0xFA, MAX_LINE_SIZE * 2);
+
+call_ref(dst0_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, 
NULL);
+call_new(dst1_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, 
NULL);
+
+if (memcmp(dst0_y, dst1_y, w * 2))
+fail();
+
+bench_new(dst1_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, 
NULL);
+}
+}
+}
+
+static void check_rgb_to_uv(struct SwsContext *ctx)
+{
+static const int input_sizes[] = {8, 128, 1280, 1080, MAX_LINE_SIZE};
+
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, dst0_u, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst0_v, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_u, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_v, [MAX_LINE_SIZE * 2]);
+
+declare_func(void, uint8_t *dstU, uint8_t *dstV,
+ const uint8_t *src1, const uint8_t *src2, const uint8_t *src3,
+ int width, uint32_t *pal, void *opq);
+
+randomize_buffers(src, MAX_LINE_SIZE * 3);
+
+for (int i = 0; i < 2; i++) {
+ctx->chrSrcHSubSample = i ? 1 : 0;
+ctx->srcFormat = AV_PIX_FMT_RGB24;
+ctx->dstFormat = i ? AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUV444P;
+ff_sws_init_scale(ctx);
+
+for (int j = 0; j < FF_ARRAY_ELEMS(input_sizes); j++) {
+int w = input_sizes[j] >> i;
+
+if (check_func(ctx->chrToYV12, "rgb24_to_uv%s_%d", i ? "_half" : 
"", w)) {
+memset(dst0_u, 0xFF, MAX_LINE_SIZE * 2);
+memset(dst0_v, 0xFF, MAX_LINE_SIZE * 2);
+memset(dst1_u, 0xFF, MAX_LINE_SIZE * 2);
+memset(dst1_v, 0xFF, MAX_LINE_SIZE * 2);
+
+call_ref(dst0_u, dst0_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+call_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+
+if (memcmp(dst0_u, dst1_u, w * 2) || memcmp(dst0_v, dst1_v, w 
* 2))
+fail();
+
+bench_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+}
+}
+}
+}
+
 void checkasm_check_sw_rgb(void)
 {
+struct SwsContext *ctx;
+int *inv_table, *table;
+int in_full, out_full, brightness, contrast, saturation;
+
 ff_sws_rgb2rgb_init();
 
 check_shuffle_bytes(shuffle_bytes_2103, "shuffle_bytes_2103");
@@ -203,4 +286,24 @@ void checkasm_check_sw_rgb(void)
 
 check_interleave_bytes();
 report("interleave_bytes");
+
+ctx = sws_getContext(MAX_LINE_SIZE, MAX_LINE_SIZE, AV_PIX_FMT_RGB24,
+ MAX_LINE_SIZE, MAX_LINE_SIZE, AV_PIX_FMT_YUV420P,
+ SWS_ACCURATE_RND | SWS_BITEXACT, NULL, NULL, NULL);
+if (!ctx)
+fail();
+
+sws_getColorspaceDetails(ctx, &inv_table, &in_full,
+ &table, &out_full,
+ &brightness, &contrast, &saturation);
+sws_setColorspaceDetails(ctx, inv_table, in_full,
+ table, out_full,
+ brightness, contrast, saturation);
+check_rgb_to_y(ctx);
+report("rgb_to_y");
+
+check_rgb_to_uv(ctx);
+report("rgb_to_uv");
+
+sws_freeContext(ctx);
 }
-- 
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] [PATCH 5/5] avutil/aarch64: Fallback to clock_gettime as timer on Android

[Zhao Zhili]

From: Zhao Zhili 

The inline asm doesn't work on Android.
---
 libavutil/aarch64/timer.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/aarch64/timer.h b/libavutil/aarch64/timer.h
index fadc9568f8..13a58b48e4 100644
--- a/libavutil/aarch64/timer.h
+++ b/libavutil/aarch64/timer.h
@@ -24,7 +24,7 @@
 #include 
 #include "config.h"
 
-#if HAVE_INLINE_ASM && !defined(__APPLE__)
+#if HAVE_INLINE_ASM && !defined(__APPLE__) && !defined(__ANDROID__)
 
 #define AV_READ_TIME read_time
 
-- 
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] [PATCH 4/5] avutil/timer: Add clock_gettime as a fallback of AV_READ_TIME

[Zhao Zhili]

From: Zhao Zhili 

---
 libavutil/timer.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavutil/timer.h b/libavutil/timer.h
index 2cd299eca3..74c4d84e69 100644
--- a/libavutil/timer.h
+++ b/libavutil/timer.h
@@ -46,6 +46,8 @@
 #include "macos_kperf.h"
 #elif HAVE_MACH_ABSOLUTE_TIME
 #include 
+#elif HAVE_CLOCK_GETTIME
+#include 
 #endif
 
 #include "common.h"
@@ -70,6 +72,9 @@
 #   define AV_READ_TIME gethrtime
 #   elif HAVE_MACH_ABSOLUTE_TIME
 #   define AV_READ_TIME mach_absolute_time
+#   elif HAVE_CLOCK_GETTIME && defined(CLOCK_MONOTONIC)
+#   include "libavutil/time.h"
+#   define AV_READ_TIME av_gettime_relative
 #   endif
 #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] [PATCH 2/5] swscale/aarch64: Add rgb24 to yuv implementation

[Zhao Zhili]

From: Zhao Zhili 

Test on Apple M1:

rgb24_to_uv_1080_c: 7.2
rgb24_to_uv_1080_neon: 5.5
rgb24_to_uv_1280_c: 8.2
rgb24_to_uv_1280_neon: 6.2
rgb24_to_uv_1920_c: 12.5
rgb24_to_uv_1920_neon: 9.5

rgb24_to_uv_half_540_c: 6.5
rgb24_to_uv_half_540_neon: 3.0
rgb24_to_uv_half_640_c: 7.5
rgb24_to_uv_half_640_neon: 3.2
rgb24_to_uv_half_960_c: 12.5
rgb24_to_uv_half_960_neon: 6.0

rgb24_to_y_1080_c: 4.5
rgb24_to_y_1080_neon: 3.5
rgb24_to_y_1280_c: 5.2
rgb24_to_y_1280_neon: 4.2
rgb24_to_y_1920_c: 8.0
rgb24_to_y_1920_neon: 6.0

Signed-off-by: Zhao Zhili 
---
 libswscale/aarch64/Makefile  |   1 +
 libswscale/aarch64/input.S   | 229 +++
 libswscale/aarch64/swscale.c |  25 
 3 files changed, 255 insertions(+)
 create mode 100644 libswscale/aarch64/input.S

diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
index da1d909561..adfd90a1b6 100644
--- a/libswscale/aarch64/Makefile
+++ b/libswscale/aarch64/Makefile
@@ -3,6 +3,7 @@ OBJS+= aarch64/rgb2rgb.o\
aarch64/swscale_unscaled.o   \
 
 NEON-OBJS   += aarch64/hscale.o \
+   aarch64/input.o  \
aarch64/output.o \
aarch64/rgb2rgb_neon.o   \
aarch64/yuv2rgb_neon.o   \
diff --git a/libswscale/aarch64/input.S b/libswscale/aarch64/input.S
new file mode 100644
index 00..ee0d223c6e
--- /dev/null
+++ b/libswscale/aarch64/input.S
@@ -0,0 +1,229 @@
+/*
+ * Copyright (c) 2024 Zhao Zhili 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/aarch64/asm.S"
+
+.macro rgb24_to_yuv_load_rgb, src
+ld3 { v16.16b, v17.16b, v18.16b }, [\src]
+ushll   v19.8h, v16.8b, #0 // v19: r
+ushll   v20.8h, v17.8b, #0 // v20: g
+ushll   v21.8h, v18.8b, #0 // v21: b
+ushll2  v22.8h, v16.16b, #0// v22: r
+ushll2  v23.8h, v17.16b, #0// v23: g
+ushll2  v24.8h, v18.16b, #0// v24: b
+.endm
+
+.macro rgb24_to_yuv_product, r, g, b, dst1, dst2, dst, coef0, coef1, coef2, 
right_shift
+mov \dst1\().16b, v6.16b// dst1 = 
const_offset
+mov \dst2\().16b, v6.16b// dst2 = 
const_offset
+smlal   \dst1\().4s, \coef0\().4h, \r\().4h // dst1 += rx 
* r
+smlal2  \dst2\().4s, \coef0\().8h, \r\().8h // dst2 += rx 
* r
+smlal   \dst1\().4s, \coef1\().4h, \g\().4h // dst1 += gx 
* g
+smlal2  \dst2\().4s, \coef1\().8h, \g\().8h // dst2 += gx 
* g
+smlal   \dst1\().4s, \coef2\().4h, \b\().4h // dst1 += bx 
* b
+smlal2  \dst2\().4s, \coef2\().8h, \b\().8h // dst2 += bx 
* b
+sqshrn  \dst\().4h, \dst1\().4s, \right_shift   // 
dst_lower_half = dst1 >> right_shift
+sqshrn2 \dst\().8h, \dst2\().4s, \right_shift   // 
dst_higher_half = dst2 >> right_shift
+.endm
+
+function ff_rgb24ToY_neon, export=1
+cmp w4, #0  // check width > 0
+b.le4f
+
+ldp w10, w11, [x5], #8   // w10: ry, w11: gy
+dup v0.8h, w10
+dup v1.8h, w11
+ldr w12, [x5]   // w12: by
+dup v2.8h, w12
+
+mov w9, #256// w9 = 1 << (RGB2YUV_SHIFT - 
7)
+movkw9, #8, lsl #16 // w9 += 32 << (RGB2YUV_SHIFT 
- 1)
+dup v6.4s, w9   // w9: const_offset
+
+mov x2, #0  // w2: i
+and w3, w4, #0xFFF0 // w3 = width / 16 * 16
+cbz w3, 3f
+1:
+rgb24_to_yuv_load_rgb x1
+rgb24_to_yuv_product v19, v20, v21, v25, v26, v16, v0, v1, v2, #9
+rgb24_to_yuv_product v22, v23, v24, v27, v28, v17, v0, v1, v2, #9
+stp q16, q17, [x0], #32 // store to dst
+
+add w2, w2, #16 // i += 16
+add x1, x1, #48 // src 

Re: [FFmpeg-devel] [PATCH 1/5] checkasm/sw_rgb: test rgb24 to yuv

[James Almer]

On 6/4/2024 10:55 AM, Zhao Zhili wrote:

From: Zhao Zhili 

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

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index 7cd815e5be..cc9b957461 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -24,6 +24,8 @@
  #include "libavutil/mem_internal.h"
  
  #include "libswscale/rgb2rgb.h"

+#include "libswscale/swscale.h"
+#include "libswscale/swscale_internal.h"
  
  #include "checkasm.h"
  
@@ -179,8 +181,89 @@ static void check_interleave_bytes(void)

  }
  }
  
+#define MAX_LINE_SIZE 1920

+
+static void check_rgb_to_y(struct SwsContext *ctx)
+{
+static const int input_sizes[] = {8, 128, 1280, 1080, MAX_LINE_SIZE};
+
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
+
+declare_func(void, uint8_t *dst, const uint8_t *src,
+ const uint8_t *unused1, const uint8_t *unused2, int width,
+ uint32_t *rgb2yuv, void *opq);
+
+randomize_buffers(src, MAX_LINE_SIZE * 3);
+
+for (int i = 0; i < FF_ARRAY_ELEMS(input_sizes); i++) {
+int w = input_sizes[i];
+
+if (check_func(ctx->lumToYV12, "rgb24_to_y_%d", w)) {
+memset(dst0_y, 0xFA, MAX_LINE_SIZE * 2);
+memset(dst1_y, 0xFA, MAX_LINE_SIZE * 2);
+
+call_ref(dst0_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, 
NULL);
+call_new(dst1_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, 
NULL);
+
+if (memcmp(dst0_y, dst1_y, w * 2))
+fail();
+
+bench_new(dst1_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, 
NULL);
+}
+}
+}
+
+static void check_rgb_to_uv(struct SwsContext *ctx)
+{
+static const int input_sizes[] = {8, 128, 1280, 1080, MAX_LINE_SIZE};
+
+LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
+LOCAL_ALIGNED_32(uint8_t, dst0_u, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst0_v, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_u, [MAX_LINE_SIZE * 2]);
+LOCAL_ALIGNED_32(uint8_t, dst1_v, [MAX_LINE_SIZE * 2]);
+
+declare_func(void, uint8_t *dstU, uint8_t *dstV,
+ const uint8_t *src1, const uint8_t *src2, const uint8_t *src3,
+ int width, uint32_t *pal, void *opq);
+
+randomize_buffers(src, MAX_LINE_SIZE * 3);
+
+for (int i = 0; i < 2; i++) {
+ctx->chrSrcHSubSample = i ? 1 : 0;
+ctx->srcFormat = AV_PIX_FMT_RGB24;
+ctx->dstFormat = i ? AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUV444P;
+ff_sws_init_scale(ctx);
+
+for (int j = 0; j < FF_ARRAY_ELEMS(input_sizes); j++) {
+int w = input_sizes[j] >> i;
+
+if (check_func(ctx->chrToYV12, "rgb24_to_uv%s_%d", i ? "_half" : 
"", w)) {
+memset(dst0_u, 0xFF, MAX_LINE_SIZE * 2);
+memset(dst0_v, 0xFF, MAX_LINE_SIZE * 2);
+memset(dst1_u, 0xFF, MAX_LINE_SIZE * 2);
+memset(dst1_v, 0xFF, MAX_LINE_SIZE * 2);
+
+call_ref(dst0_u, dst0_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+call_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+
+if (memcmp(dst0_u, dst1_u, w * 2) || memcmp(dst0_v, dst1_v, w 
* 2))
+fail();
+
+bench_new(dst1_u, dst1_v, NULL, src, src, w, 
ctx->input_rgb2yuv_table, NULL);
+}
+}
+}
+}
+
  void checkasm_check_sw_rgb(void)
  {
+struct SwsContext *ctx;
+int *inv_table, *table;
+int in_full, out_full, brightness, contrast, saturation;
+
  ff_sws_rgb2rgb_init();
  
  check_shuffle_bytes(shuffle_bytes_2103, "shuffle_bytes_2103");

@@ -203,4 +286,24 @@ void checkasm_check_sw_rgb(void)
  
  check_interleave_bytes();

  report("interleave_bytes");
+
+ctx = sws_getContext(MAX_LINE_SIZE, MAX_LINE_SIZE, AV_PIX_FMT_RGB24,
+ MAX_LINE_SIZE, MAX_LINE_SIZE, AV_PIX_FMT_YUV420P,
+ SWS_ACCURATE_RND | SWS_BITEXACT, NULL, NULL, NULL);
+if (!ctx)
+fail();
+
+sws_getColorspaceDetails(ctx, &inv_table, &in_full,
+ &table, &out_full,
+ &brightness, &contrast, &saturation);
+sws_setColorspaceDetails(ctx, inv_table, in_full,
+ table, out_full,
+ brightness, contrast, saturation);


Isn't this pointless? It looks like you're setting the context with 
values taken from the same context.



+check_rgb_to_y(ctx);
+report("rgb_to_y");
+
+check_rgb_to_uv(ctx);
+report("rgb_to_uv");
+
+sws_freeContext(ctx);
  }

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

To unsubscr

Re: [FFmpeg-devel] [PATCH 1/5] checkasm/sw_rgb: test rgb24 to yuv

[Zhao Zhili]

> On Jun 4, 2024, at 21:58, James Almer  wrote:
> 
> On 6/4/2024 10:55 AM, Zhao Zhili wrote:
>> From: Zhao Zhili 
>> ---
>>  tests/checkasm/sw_rgb.c | 103 
>>  1 file changed, 103 insertions(+)
>> diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
>> index 7cd815e5be..cc9b957461 100644
>> --- a/tests/checkasm/sw_rgb.c
>> +++ b/tests/checkasm/sw_rgb.c
>> @@ -24,6 +24,8 @@
>>  #include "libavutil/mem_internal.h"
>>#include "libswscale/rgb2rgb.h"
>> +#include "libswscale/swscale.h"
>> +#include "libswscale/swscale_internal.h"
>>#include "checkasm.h"
>>  @@ -179,8 +181,89 @@ static void check_interleave_bytes(void)
>>  }
>>  }
>>  +#define MAX_LINE_SIZE 1920
>> +
>> +static void check_rgb_to_y(struct SwsContext *ctx)
>> +{
>> +static const int input_sizes[] = {8, 128, 1280, 1080, MAX_LINE_SIZE};
>> +
>> +LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
>> +LOCAL_ALIGNED_32(uint8_t, dst0_y, [MAX_LINE_SIZE * 2]);
>> +LOCAL_ALIGNED_32(uint8_t, dst1_y, [MAX_LINE_SIZE * 2]);
>> +
>> +declare_func(void, uint8_t *dst, const uint8_t *src,
>> + const uint8_t *unused1, const uint8_t *unused2, int width,
>> + uint32_t *rgb2yuv, void *opq);
>> +
>> +randomize_buffers(src, MAX_LINE_SIZE * 3);
>> +
>> +for (int i = 0; i < FF_ARRAY_ELEMS(input_sizes); i++) {
>> +int w = input_sizes[i];
>> +
>> +if (check_func(ctx->lumToYV12, "rgb24_to_y_%d", w)) {
>> +memset(dst0_y, 0xFA, MAX_LINE_SIZE * 2);
>> +memset(dst1_y, 0xFA, MAX_LINE_SIZE * 2);
>> +
>> +call_ref(dst0_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, 
>> NULL);
>> +call_new(dst1_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, 
>> NULL);
>> +
>> +if (memcmp(dst0_y, dst1_y, w * 2))
>> +fail();
>> +
>> +bench_new(dst1_y, src, NULL, NULL, w, ctx->input_rgb2yuv_table, 
>> NULL);
>> +}
>> +}
>> +}
>> +
>> +static void check_rgb_to_uv(struct SwsContext *ctx)
>> +{
>> +static const int input_sizes[] = {8, 128, 1280, 1080, MAX_LINE_SIZE};
>> +
>> +LOCAL_ALIGNED_32(uint8_t, src, [MAX_LINE_SIZE * 3]);
>> +LOCAL_ALIGNED_32(uint8_t, dst0_u, [MAX_LINE_SIZE * 2]);
>> +LOCAL_ALIGNED_32(uint8_t, dst0_v, [MAX_LINE_SIZE * 2]);
>> +LOCAL_ALIGNED_32(uint8_t, dst1_u, [MAX_LINE_SIZE * 2]);
>> +LOCAL_ALIGNED_32(uint8_t, dst1_v, [MAX_LINE_SIZE * 2]);
>> +
>> +declare_func(void, uint8_t *dstU, uint8_t *dstV,
>> + const uint8_t *src1, const uint8_t *src2, const uint8_t 
>> *src3,
>> + int width, uint32_t *pal, void *opq);
>> +
>> +randomize_buffers(src, MAX_LINE_SIZE * 3);
>> +
>> +for (int i = 0; i < 2; i++) {
>> +ctx->chrSrcHSubSample = i ? 1 : 0;
>> +ctx->srcFormat = AV_PIX_FMT_RGB24;
>> +ctx->dstFormat = i ? AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUV444P;
>> +ff_sws_init_scale(ctx);
>> +
>> +for (int j = 0; j < FF_ARRAY_ELEMS(input_sizes); j++) {
>> +int w = input_sizes[j] >> i;
>> +
>> +if (check_func(ctx->chrToYV12, "rgb24_to_uv%s_%d", i ? "_half" 
>> : "", w)) {
>> +memset(dst0_u, 0xFF, MAX_LINE_SIZE * 2);
>> +memset(dst0_v, 0xFF, MAX_LINE_SIZE * 2);
>> +memset(dst1_u, 0xFF, MAX_LINE_SIZE * 2);
>> +memset(dst1_v, 0xFF, MAX_LINE_SIZE * 2);
>> +
>> +call_ref(dst0_u, dst0_v, NULL, src, src, w, 
>> ctx->input_rgb2yuv_table, NULL);
>> +call_new(dst1_u, dst1_v, NULL, src, src, w, 
>> ctx->input_rgb2yuv_table, NULL);
>> +
>> +if (memcmp(dst0_u, dst1_u, w * 2) || memcmp(dst0_v, dst1_v, 
>> w * 2))
>> +fail();
>> +
>> +bench_new(dst1_u, dst1_v, NULL, src, src, w, 
>> ctx->input_rgb2yuv_table, NULL);
>> +}
>> +}
>> +}
>> +}
>> +
>>  void checkasm_check_sw_rgb(void)
>>  {
>> +struct SwsContext *ctx;
>> +int *inv_table, *table;
>> +int in_full, out_full, brightness, contrast, saturation;
>> +
>>  ff_sws_rgb2rgb_init();
>>check_shuffle_bytes(shuffle_bytes_2103, "shuffle_bytes_2103");
>> @@ -203,4 +286,24 @@ void checkasm_check_sw_rgb(void)
>>check_interleave_bytes();
>>  report("interleave_bytes");
>> +
>> +ctx = sws_getContext(MAX_LINE_SIZE, MAX_LINE_SIZE, AV_PIX_FMT_RGB24,
>> + MAX_LINE_SIZE, MAX_LINE_SIZE, AV_PIX_FMT_YUV420P,
>> + SWS_ACCURATE_RND | SWS_BITEXACT, NULL, NULL, NULL);
>> +if (!ctx)
>> +fail();
>> +
>> +sws_getColorspaceDetails(ctx, &inv_table, &in_full,
>> + &table, &out_full,
>> + &brightness, &contrast, &saturation);
>> +sws_setColorspaceDetails(ctx, inv_table, in_full,
>> + table, out_full,
>> + brightness, contrast, saturation);
>

Re: [FFmpeg-devel] [PATCH v4 1/1] avcodec: add external enc libvvenc for H266/VVC

[Christian]

> On 4. Jun 2024, at 11:21, Anton Khirnov  wrote:
> 
> Quoting Christian Bartnik (2024-05-28 18:26:29)
>> +static const AVOption options[] = {
>> +{ "passlogfile",  "Filename for 2 pass stats", OFFSET(stats), 
>> AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, VE},
>> +{ "stats","Filename for 2 pass stats", OFFSET(stats), 
>> AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, VE},
> 
> These option names conflict with ffmpeg CLI options.

I´m aware of this and I´m using exactly the same approach as libx264 does. 

passlogfile is overwriting the CLI option to make the generated passfile 
filename from the CLI availalbe to the codec.

In the review of my latest version of my patch I was told to use the 
'passlogfile' option.

Please let me know how I should pass the passlogfile filename from the CLI to 
the codec implementation.

> 
> -- 
> Anton Khirnov
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
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] bsf: Fix memory leak by adding vp9_raw_reorder_frame_free()

[Jiasheng Jiang]

Add vp9_raw_reorder_frame_free() before "ctx->next_frame = NULL;" to avoid 
memory leak.

Fixes: 887a7817b6 ("lavc: move bitstream filters into bsf/ subdir")
Signed-off-by: Jiasheng Jiang 
---
 libavcodec/bsf/vp9_raw_reorder.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/bsf/vp9_raw_reorder.c b/libavcodec/bsf/vp9_raw_reorder.c
index d36093316c..88cf68fb50 100644
--- a/libavcodec/bsf/vp9_raw_reorder.c
+++ b/libavcodec/bsf/vp9_raw_reorder.c
@@ -372,6 +372,7 @@ static int vp9_raw_reorder_filter(AVBSFContext *bsf, 
AVPacket *out)
 if (err < 0) {
 av_log(bsf, AV_LOG_ERROR, "Failed to create output "
"for transient frame.\n");
+vp9_raw_reorder_frame_free(&frame);
 ctx->next_frame = NULL;
 return AVERROR_INVALIDDATA;
 }
-- 
2.25.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 v6 0/4] doc: Explain what "context" means

[Andrew Sayers]

I'm making a list of little documentation patches to submit as a set once this
patchset is done.  I've put Sw{r,s}Context on the list, and will think about
their relationship to other opaque AVOptions-enabled structs as part of that.
I don't see anything in that discussion that affects this patchset,
so let's park that discussion for now.

One thing we haven't talked about before, but is worth stating explicitly -
smart people tend to conflate "I can't think of anything complex about X"
with "there are no complex things about X", so this document needs to sell
people on the complexity of each problem before laying out the solution.
The AVOptions section is a particularly good example, tackling the implicit
question "can't you just use `getopt`?" first then moving on to describe how
it solves that problem.  Some parts of the document function as responses to 
questions an FFmpeg developer would never think to ask, because why would you 
even think to compare AVOptions with getopt?

This version emphasises how AVOptions should only be set during configuration.
It avoids the words "reflection" and "introspection" altogether, because IMHO
they imply an API that can be used in any stage of a struct's lifetime.

Aside: this is the latest in a series of issues where it initially seemed like
I was adding unnecessary terminology in places where it was confusing,
but turned out to be a symptom of a fundamental misunderstanding on my part.
If there's any such language remaining in this version, we should probably
look for those misunderstandings first and worry about language second.

___
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 v6 1/4] doc: Explain what "context" means

[Andrew Sayers]

Derived from explanations kindly provided by Stefano Sabatini and others:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325903.html
---
 doc/context.md | 430 +
 1 file changed, 430 insertions(+)
 create mode 100644 doc/context.md

diff --git a/doc/context.md b/doc/context.md
new file mode 100644
index 00..bd8cb58696
--- /dev/null
+++ b/doc/context.md
@@ -0,0 +1,430 @@
+@page Context Introduction to contexts
+
+@tableofcontents
+
+FFmpeg uses the term “context” to refer to an idiom
+you have probably used before:
+
+```c
+// C structs often share context between functions:
+
+FILE *my_file; // my_file stores information about a filehandle
+
+printf(my_file, "hello "); // my_file provides context to this function,
+printf(my_file, "world!"); // and also to this function
+```
+
+```python
+# Python classes provide context for the methods they contain:
+
+class MyClass:
+def print(self,message):
+if self.prev_message != message:
+self.prev_message = message
+print(message)
+```
+
+
+```c
+// Many JavaScript callbacks accept an optional context argument:
+
+const my_object = {};
+
+my_array.forEach(function_1, my_object);
+my_array.forEach(function_2, my_object);
+```
+
+Be careful comparing FFmpeg contexts to things you're already familiar with -
+FFmpeg may sometimes happen to reuse words you recognise, but mean something
+completely different.  For example, the AVClass struct has nothing to do with
+[object-oriented 
classes](https://en.wikipedia.org/wiki/Class_(computer_programming)).
+
+If you've used contexts in other C projects, you may want to read
+@ref Context_comparison before the rest of the document.
+
+@section Context_general “Context” as a general concept
+
+@par
+A context is any data structure used by several functions
+(or several instances of the same function) that all operate on the same 
entity.
+
+In the broadest sense, “context” is just a way to think about code.
+You can even use it to think about code written by people who have never
+heard the term, or who would disagree with you about what it means.
+Consider the following snippet:
+
+```c
+struct DualWriter {
+int fd1, fd2;
+};
+
+ssize_t write_to_two_files(
+struct DualWriter *my_writer,
+uint8_t *buf,
+int buf_size
+) {
+
+ssize_t bytes_written_1 = write(my_writer->fd1, buf, buf_size);
+ssize_t bytes_written_2 = write(my_writer->fd2, buf, buf_size);
+
+if ( bytes_written_1 != bytes_written_2 ) {
+// ... handle this edge case ...
+}
+
+return bytes_written_1;
+
+}
+
+int main() {
+
+struct DualWriter my_writer;
+my_writer.fd1 = open("file1", 0644, "wb");
+my_writer.fd2 = open("file2", 0644, "wb");
+
+write_to_two_files(&my_writer, "hello ", sizeof("hello "));
+write_to_two_files(&my_writer, "world!", sizeof("world!"));
+
+close( my_writer.fd1 );
+close( my_writer.fd2 );
+
+}
+```
+
+The term “context” doesn't appear anywhere in the snippet.  But `DualWriter`
+is passed to several instances of `write_to_two_files()` that operate on
+the same entity, so it fits the definition of a context.
+
+When reading code that isn't explicitly described in terms of contexts,
+remember that your interpretation may differ from other people's.
+For example, FFmpeg's avio_alloc_context() accepts a set of callback functions
+and an `opaque` argument - even though this function guarantees to *return*
+a context, it does not require `opaque` to *provide* context for the callback
+functions.  So you could choose to pass a struct like `DualWriter` as the
+`opaque` argument, or you could pass callbacks that use `stdin` and `stdout`
+and just pass a `NULL` argument for `opaque`.
+
+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.
+
+The next section will discuss what specific conventions FFmpeg developers mean
+when they describe parts of their code as using “contexts”.
+
+@section Context_ffmpeg FFmpeg contexts
+
+This section discusses specific context-related conventions used in FFmpeg.
+Some of these are used in other projects, others are unique to this project.
+
+@subsection Context_indicating Indicating context: “Context”, “ctx” etc.
+
+```c
+// Context struct names usually end with `Context`:
+struct AVSomeContext {
+  ...
+};
+
+// Functions are usually named after their context,
+// context parameters usually come first and are often called `ctx`:
+void av_some_function(AVSomeContext *ctx, ...);

[FFmpeg-devel] [PATCH v6 2/4] lavu: Clarify relationship between AVClass, AVOption and context

[Andrew Sayers]

---
 libavutil/log.h | 16 +---
 libavutil/opt.h | 26 +-
 2 files changed, 34 insertions(+), 8 deletions(-)

diff --git a/libavutil/log.h b/libavutil/log.h
index ab7ceabe22..88b35897c6 100644
--- a/libavutil/log.h
+++ b/libavutil/log.h
@@ -59,9 +59,19 @@ typedef enum {
 struct AVOptionRanges;
 
 /**
- * Describe the class of an AVClass context structure. That is an
- * arbitrary struct of which the first field is a pointer to an
- * AVClass struct (e.g. AVCodecContext, AVFormatContext etc.).
+ * Generic Logging facilities and configuration options
+ *
+ * Logging and AVOptions functions expect to be passed structs
+ * whose first member is a pointer-to-@ref AVClass.
+ *
+ * Structs that only use logging facilities are often referred to as
+ * "AVClass context structures", while those that provide configuration
+ * options are called "AVOptions-enabled structs".
+ *
+ * @see
+ * * @ref lavu_log
+ * * @ref avoptions
+ * * @ref Context
  */
 typedef struct AVClass {
 /**
diff --git a/libavutil/opt.h b/libavutil/opt.h
index 07e27a9208..cdee8f7d28 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -39,9 +39,16 @@
  * @defgroup avoptions AVOptions
  * @ingroup lavu_data
  * @{
- * AVOptions provide a generic system to declare options on arbitrary structs
- * ("objects"). An option can have a help text, a type and a range of possible
- * values. Options may then be enumerated, read and written to.
+ *
+ * Inspection and configuration for AVClass context structures
+ *
+ * Provides a generic API to declare and manage options on any struct
+ * whose first member is a pointer-to-@ref AVClass.  Structs with private
+ * contexts can use that AVClass to return further @ref AVClass "AVClass"es
+ * that allow access to options in the private structs.
+ *
+ * Each option can have a help text, a type and a range of possible values.
+ * Options may be enumerated, read and written to.
  *
  * There are two modes of access to members of AVOption and its child structs.
  * One is called 'native access', and refers to access from the code that
@@ -53,11 +60,20 @@
  * question is allowed to access the field. This allows us to extend the
  * semantics of those fields without breaking API compatibility.
  *
+ * Note that AVOptions is not reentrant, and that many FFmpeg functions access
+ * options from separate threads.  Unless otherwise indicated, it is best to
+ * avoid modifying options once a struct has been initialized.
+ *
+ * @see
+ * * @ref lavu_log
+ * * @ref Context
+ *
  * @section avoptions_scope Scope of AVOptions
  *
  * AVOptions is designed to support any set of multimedia configuration options
- * that can be defined at compile-time.  Although it is mainly used to expose
- * FFmpeg options, you are welcome to adapt it to your own use case.
+ * that can be defined at compile-time and set at object creation time.  
Although
+ * it is mainly used to expose FFmpeg options, you are welcome to adapt it
+ * to your own use case.
  *
  * No single approach can ever fully solve the problem of configuration,
  * but please submit a patch if you believe you have found a problem
-- 
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] [PATCH v6 3/4] all: Link to "context" from all public contexts with documentation

[Andrew Sayers]

The goal of putting these links in "@see" blocks is to provide hooks
for future developers to add links to other useful parts of the codebase.
---
 libavcodec/avcodec.h | 3 +++
 libavcodec/bsf.h | 3 +++
 libavcodec/d3d11va.h | 3 +++
 libavcodec/mediacodec.h  | 2 ++
 libavcodec/qsv.h | 3 +++
 libavcodec/vdpau.h   | 3 +++
 libavcodec/videotoolbox.h| 3 +++
 libavfilter/avfilter.h   | 7 ++-
 libavformat/avformat.h   | 3 +++
 libavformat/avio.h   | 3 +++
 libavutil/audio_fifo.h   | 3 +++
 libavutil/hwcontext.h| 6 ++
 libavutil/hwcontext_cuda.h   | 3 +++
 libavutil/hwcontext_d3d11va.h| 6 ++
 libavutil/hwcontext_d3d12va.h| 6 ++
 libavutil/hwcontext_drm.h| 3 +++
 libavutil/hwcontext_dxva2.h  | 6 ++
 libavutil/hwcontext_mediacodec.h | 3 +++
 libavutil/hwcontext_opencl.h | 6 ++
 libavutil/hwcontext_qsv.h| 6 ++
 libavutil/hwcontext_vaapi.h  | 6 ++
 libavutil/hwcontext_vdpau.h  | 3 +++
 libavutil/hwcontext_vulkan.h | 6 ++
 libavutil/lfg.h  | 3 +++
 24 files changed, 98 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 2da63c87ea..abc00ab394 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -441,6 +441,9 @@ typedef struct RcOverride{
  * The AVOption/command line parameter names differ in some cases from the C
  * structure field names for historic reasons or brevity.
  * sizeof(AVCodecContext) must not be used outside libav*.
+ *
+ * @see
+ * - @ref Context
  */
 typedef struct AVCodecContext {
 /**
diff --git a/libavcodec/bsf.h b/libavcodec/bsf.h
index a09c69f242..ee5fdd48d2 100644
--- a/libavcodec/bsf.h
+++ b/libavcodec/bsf.h
@@ -64,6 +64,9 @@
  * The fields in the struct will only be changed (by the caller or by the
  * filter) as described in their documentation, and are to be considered
  * immutable otherwise.
+ *
+ * @see
+ * - @ref Context
  */
 typedef struct AVBSFContext {
 /**
diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
index 27f40e5519..686974b083 100644
--- a/libavcodec/d3d11va.h
+++ b/libavcodec/d3d11va.h
@@ -52,6 +52,9 @@
  * The application must make it available as AVCodecContext.hwaccel_context.
  *
  * Use av_d3d11va_alloc_context() exclusively to allocate an AVD3D11VAContext.
+ *
+ * @see
+ * - @ref Context
  */
 typedef struct AVD3D11VAContext {
 /**
diff --git a/libavcodec/mediacodec.h b/libavcodec/mediacodec.h
index 4e9b56a618..43f049a609 100644
--- a/libavcodec/mediacodec.h
+++ b/libavcodec/mediacodec.h
@@ -29,6 +29,8 @@
  * This structure holds a reference to a android/view/Surface object that will
  * be used as output by the decoder.
  *
+ * @see
+ * - @ref Context
  */
 typedef struct AVMediaCodecContext {
 
diff --git a/libavcodec/qsv.h b/libavcodec/qsv.h
index c156b08d07..8ab93af6b6 100644
--- a/libavcodec/qsv.h
+++ b/libavcodec/qsv.h
@@ -32,6 +32,9 @@
  * - decoding: hwaccel_context must be set on return from the get_format()
  * callback
  * - encoding: hwaccel_context must be set before avcodec_open2()
+ *
+ * @see
+ * - @ref Context
  */
 typedef struct AVQSVContext {
 /**
diff --git a/libavcodec/vdpau.h b/libavcodec/vdpau.h
index 8021c25761..934c96b88c 100644
--- a/libavcodec/vdpau.h
+++ b/libavcodec/vdpau.h
@@ -74,6 +74,9 @@ typedef int (*AVVDPAU_Render2)(struct AVCodecContext *, 
struct AVFrame *,
  *
  * The size of this structure is not a part of the public ABI and must not
  * be used outside of libavcodec.
+ *
+ * @see
+ * - @ref Context
  */
 typedef struct AVVDPAUContext {
 /**
diff --git a/libavcodec/videotoolbox.h b/libavcodec/videotoolbox.h
index d68d76e400..81d90d63b6 100644
--- a/libavcodec/videotoolbox.h
+++ b/libavcodec/videotoolbox.h
@@ -53,6 +53,9 @@
  * between the caller and libavcodec for initializing Videotoolbox decoding.
  * Its size is not a part of the public ABI, it must be allocated with
  * av_videotoolbox_alloc_context() and freed with av_free().
+ *
+ * @see
+ * - @ref Context
  */
 typedef struct AVVideotoolboxContext {
 /**
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index a34e61f23c..25ccd80433 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -403,7 +403,12 @@ unsigned avfilter_filter_pad_count(const AVFilter *filter, 
int is_output);
  */
 #define AVFILTER_THREAD_SLICE (1 << 0)
 
-/** An instance of a filter */
+/**
+ * An instance of a filter
+ *
+ * @see
+ * - @ref Context
+ */
 struct AVFilterContext {
 const AVClass *av_class;///< needed for av_log() and filters 
common options
 
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 8afdcd9fd0..18f20f0bb0 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1253,6 +1253,9 @@ enum AVDurationEstimationMethod {
  * can be found in libavformat/options_table.h.
  * The AVOption/command line par

[FFmpeg-devel] [PATCH v6 4/4] all: Rewrite documentation for contexts

[Andrew Sayers]

Make their documentation more readable and similar to each other,
(hopefully) without changing the meaning.
---
 libavcodec/aac/aacdec.h  |  2 +-
 libavcodec/aacenc.h  |  2 +-
 libavcodec/ac3enc.h  |  2 +-
 libavcodec/amfenc.h  |  2 +-
 libavcodec/atrac.h   |  2 +-
 libavcodec/avcodec.h |  3 ++-
 libavcodec/bsf.h |  2 +-
 libavcodec/cbs.h |  2 +-
 libavcodec/d3d11va.h |  3 +--
 libavcodec/mediacodec.h  |  4 ++--
 libavcodec/pthread_frame.c   |  4 ++--
 libavcodec/qsv.h |  6 --
 libavcodec/sbr.h |  2 +-
 libavcodec/vdpau.h   |  5 +++--
 libavcodec/videotoolbox.h|  5 +++--
 libavfilter/avfilter.h   |  2 +-
 libavformat/avformat.h   |  3 ++-
 libavformat/avio.h   |  3 ++-
 libavutil/audio_fifo.h   |  2 +-
 libavutil/hwcontext.h| 21 -
 libavutil/hwcontext_cuda.h   |  2 +-
 libavutil/hwcontext_d3d11va.h|  4 ++--
 libavutil/hwcontext_d3d12va.h|  6 +++---
 libavutil/hwcontext_drm.h|  2 +-
 libavutil/hwcontext_dxva2.h  |  4 ++--
 libavutil/hwcontext_mediacodec.h |  2 +-
 libavutil/hwcontext_opencl.h |  4 ++--
 libavutil/hwcontext_qsv.h|  4 ++--
 libavutil/hwcontext_vaapi.h  |  4 ++--
 libavutil/hwcontext_vdpau.h  |  2 +-
 libavutil/hwcontext_vulkan.h |  5 +++--
 libavutil/lfg.h  |  3 ++-
 32 files changed, 65 insertions(+), 54 deletions(-)

diff --git a/libavcodec/aac/aacdec.h b/libavcodec/aac/aacdec.h
index ee21a94007..f0d613afd9 100644
--- a/libavcodec/aac/aacdec.h
+++ b/libavcodec/aac/aacdec.h
@@ -441,7 +441,7 @@ typedef struct AACDecDSP {
 } AACDecDSP;
 
 /**
- * main AAC decoding context
+ * Context for decoding AAC
  */
 struct AACDecContext {
 const struct AVClass  *class;
diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
index d07960620e..3e710c7fac 100644
--- a/libavcodec/aacenc.h
+++ b/libavcodec/aacenc.h
@@ -207,7 +207,7 @@ typedef struct AACPCEInfo {
 } AACPCEInfo;
 
 /**
- * AAC encoder context
+ * Context for encoding AAC
  */
 typedef struct AACEncContext {
 AVClass *av_class;
diff --git a/libavcodec/ac3enc.h b/libavcodec/ac3enc.h
index 5e98ad188b..e5abe0a856 100644
--- a/libavcodec/ac3enc.h
+++ b/libavcodec/ac3enc.h
@@ -153,7 +153,7 @@ typedef struct AC3Block {
 struct PutBitContext;
 
 /**
- * AC-3 encoder private context.
+ * Private context for encoding AC-3
  */
 typedef struct AC3EncodeContext {
 AVClass *av_class;  ///< AVClass used for AVOption
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
index 2dbd378ef8..184897beeb 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -43,7 +43,7 @@ typedef struct AmfTraceWriter {
 } AmfTraceWriter;
 
 /**
-* AMF encoder context
+* Context for encoding AMF
 */
 
 typedef struct AmfContext {
diff --git a/libavcodec/atrac.h b/libavcodec/atrac.h
index 05208bbee6..e760f0384d 100644
--- a/libavcodec/atrac.h
+++ b/libavcodec/atrac.h
@@ -39,7 +39,7 @@ typedef struct AtracGainInfo {
 } AtracGainInfo;
 
 /**
- *  Gain compensation context structure.
+ *  Context for gain compensation
  */
 typedef struct AtracGCContext {
 float   gain_tab1[16];  ///< gain compensation level table
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index abc00ab394..2fed4757ed 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -430,7 +430,8 @@ typedef struct RcOverride{
 #define AV_GET_ENCODE_BUFFER_FLAG_REF (1 << 0)
 
 /**
- * main external API structure.
+ * Context for an encode or decode session
+ *
  * New fields can be added to the end with minor version bumps.
  * Removal, reordering and changes to existing fields require a major
  * version bump.
diff --git a/libavcodec/bsf.h b/libavcodec/bsf.h
index ee5fdd48d2..fadcfc5d47 100644
--- a/libavcodec/bsf.h
+++ b/libavcodec/bsf.h
@@ -56,7 +56,7 @@
  */
 
 /**
- * The bitstream filter state.
+ * Context for bitstream filtering
  *
  * This struct must be allocated with av_bsf_alloc() and freed with
  * av_bsf_free().
diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index d479b1ac2d..c074dd11ec 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -214,7 +214,7 @@ typedef void (*CBSTraceWriteCallback)(void *trace_context,
   int64_t value);
 
 /**
- * Context structure for coded bitstream operations.
+ * Context for coded bitstream operations
  */
 typedef struct CodedBitstreamContext {
 /**
diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
index 686974b083..5ffee2b3be 100644
--- a/libavcodec/d3d11va.h
+++ b/libavcodec/d3d11va.h
@@ -46,8 +46,7 @@
  */
 
 /**
- * This structure is used to provides the necessary configurations and data
- * to the Direct3D11 FFmpeg HWAccel implementation.
+ * Context for the Direct3D11 FFmpeg HWAccel implementation
  *
  * The application must make it available as AVCodec

Re: [FFmpeg-devel] [RFC] STF 2025

[Andrew Sayers]

On Fri, May 17, 2024 at 03:49:58PM +0200, Michael Niedermayer wrote:
> Hi all
> 
> Before this is forgotten again, better start some dicsussion too early than 
> too late

Unless there's a better place to put these, I plan to reply to this message
whenever I notice someone bring up something that seems relevant.
Hopefully it will be a good reference if and when the time comes.

Sebastian Ramacher recently said this in another thread[1]:

> Maintainers and developers of reverse dependencies repeatedly ask for
> upgrade guides that go beyond "use this function instead"

This strikes me as an excellent bit of boring-but-important STF work.
The bug reports in that e-mail make it relatively easy to quantify impact -
measure the number of breakages in each revision, make a chart of numbers
over time, agree a target number for next time.

[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2024-June/328852.html
___
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] [RFC] STF 2025

[Cosmin Stejerean via ffmpeg-devel]

> On Jun 3, 2024, at 11:53 PM, Vittorio Giovara  
> wrote:
> 
> On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
> 
>>> Reposting my question/comment here since Thilo hasn't had a chance to
>>> respond, but shouldn't these kinds of requests go through the GA? If
>>> anybody can do whatever they want with the ffmpeg name, then what's the
>>> point of voting and following the established process?
>> 
>> Probably? I'm not actually sure what the process is for getting an FFmpeg
>> booth at a conference. Is there a documented process somewhere for how this
>> should be done? If not this might be a good opportunity to create one.
>> 
> 
> Agreed, do you have a draft you could share as a base of discussion? Once
> defined, we could have the GA vote on it
> 

If you really want to work on a proposal I'm happy to collaborate with you 
offline to draft something and then propose it to the GA.

> 
>> It might also make for a good topic of discussion at VDD. For how much
>> drama there was about NAB on the list I was surprised there was zero
>> discussion about it at FOSDEM.
>> 
> 
> There were probably more important topics to discuss and the lingering hope
> that the problematic points would have been handled better than by calling
> people trolls
> 

Perhaps. Shall we set something up at VDD? I think in person discussion can go 
a long way to avoid the kind of miscommunication that can happen over email.

> 
> I don't think anybody is suggesting that booths are cost-problematic, but
> rather they are lacking in process (one shouldn't allowed use ffmpeg name
> "just because") and in scope (aka "the why" and what kind of results are
> expected by investing time in said booth)

My part of this thread started by responding to "IBC is probably not as 
(cost-)problematic as NAB, w.r.t. setting up the booth or transportation".

- Cosmin
___
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] x86/aacencdsp: add SSE2 and AVX versions of quantize_bands

[James Almer]

On 6/4/2024 3:37 AM, Rémi Denis-Courmont wrote:



Le 4 juin 2024 04:23:43 GMT+03:00, James Almer  a écrit :

quant_bands_signed_sse2: 417.0
quant_bands_signed_avx: 202.0


What about unsigned?


Pretty much the same. Will add them before pushing.
___
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] [RFC] STF 2025

[Paul B Mahol]

On Tue, Jun 4, 2024 at 2:53 PM Vittorio Giovara 
wrote:

> On Tue, Jun 4, 2024 at 2:02 PM Paul B Mahol  wrote:
>
> > On Tue, Jun 4, 2024 at 12:59 PM Vittorio Giovara <
> > vittorio.giov...@gmail.com>
> > wrote:
> >
> > > On Tue, Jun 4, 2024 at 12:09 PM Paul B Mahol  wrote:
> > >
> > > > On Tue, Jun 4, 2024 at 9:09 AM Vittorio Giovara <
> > > > vittorio.giov...@gmail.com>
> > > > wrote:
> > > >
> > > > > On Tue, Jun 4, 2024 at 8:55 AM Paul B Mahol 
> > wrote:
> > > > >
> > > > > > On Tue, Jun 4, 2024 at 8:53 AM Vittorio Giovara <
> > > > > > vittorio.giov...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via
> ffmpeg-devel
> > <
> > > > > > > ffmpeg-devel@ffmpeg.org> wrote:
> > > > > > >
> > > > > > > > > Reposting my question/comment here since Thilo hasn't had a
> > > > chance
> > > > > to
> > > > > > > > > respond, but shouldn't these kinds of requests go through
> the
> > > GA?
> > > > > If
> > > > > > > > > anybody can do whatever they want with the ffmpeg name,
> then
> > > > what's
> > > > > > the
> > > > > > > > > point of voting and following the established process?
> > > > > > > >
> > > > > > > > Probably? I'm not actually sure what the process is for
> getting
> > > an
> > > > > > FFmpeg
> > > > > > > > booth at a conference. Is there a documented process
> somewhere
> > > for
> > > > > how
> > > > > > > this
> > > > > > > > should be done? If not this might be a good opportunity to
> > create
> > > > > one.
> > > > > > > >
> > > > > > >
> > > > > > > Agreed, do you have a draft you could share as a base of
> > > discussion?
> > > > > Once
> > > > > > > defined, we could have the GA vote on it
> > > > > > >
> > > > > > >
> > > > > > > > It might also make for a good topic of discussion at VDD. For
> > how
> > > > > much
> > > > > > > > drama there was about NAB on the list I was surprised there
> was
> > > > zero
> > > > > > > > discussion about it at FOSDEM.
> > > > > > > >
> > > > > > >
> > > > > > > There were probably more important topics to discuss and the
> > > > lingering
> > > > > > hope
> > > > > > > that the problematic points would have been handled better than
> > by
> > > > > > calling
> > > > > > > people trolls
> > > > > > >
> > > > > > >
> > > > > > > > Regarding the "or you" part, I wasn't involved in securing
> > > > > sponsorship
> > > > > > > for
> > > > > > > > NAB or IBC. I did volunteer to help with NAB because I happen
> > to
> > > > live
> > > > > > in
> > > > > > > > Vegas and I enjoy spending time with other ffmpeg developers.
> > I'm
> > > > > happy
> > > > > > > to
> > > > > > > > help at NAB next year as well should it happen again.
> > > > > > > >
> > > > > > >
> > > > > > > Noted, it should have said "or anybody willing to host/help a
> > > booth"
> > > > > > >
> > > > > > > I have no plans to attend IBC and no involvement with the
> FFmpeg
> > > > booth
> > > > > at
> > > > > > > > IBC. I am merely trying to correct the perception that NAB
> was
> > > > > > > > cost-problematic, since no money was paid by the project for
> > NAB.
> > > > > > > >
> > > > > > >
> > > > > > > I don't think anybody is suggesting that booths are
> > > cost-problematic,
> > > > > but
> > > > > > > rather they are lacking in process (one shouldn't allowed use
> > > ffmpeg
> > > > > name
> > > > > > > "just because") and in scope (aka "the why" and what kind of
> > > results
> > > > > are
> > > > > > > expected by investing time in said booth)
> > > > > > >
> > > > > >
> > > > > > Said by prominent LibAV developer.
> > > > > >
> > > > >
> > > > > reported to CC :)
> > > > >
> > > >
> > > > CC is fully controlled by prominent LibAV developers.
> > > >
> > >
> > > Not only is this factually incorrect, it's also unrelated to the topic
> at
> > > hand. No worries, this infringement is being reported to the CC as
> well,
> > > but please try to make an effort at doing better at least.
> > > Thank you
> > >
> >
> > Do not trust LibAV developers even when they are giving you gifts.
> >
>
> I'm not giving you anything, please can you stop? I don't want to flood the
> CC with emails, but I'll do so if that helps stifle this kind of behavior.
> Please disconnect, grow up, be nicer to your fellow community members, and
> just do better.
>

Thank you for your arrogant continuous behavior that match nicely with your
latest code contributions.

If you stop responding with mails on all FFmpeg mailing lists from now to
indefinite time in future nothing of value would be lost.



> 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".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or 

[FFmpeg-devel] [PATCH] avfilter/trim: flag trim filter as metadata only

[Gyan Doshi]

Similar to select filter for video - it can only pass through or drop frames
---
 libavfilter/trim.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavfilter/trim.c b/libavfilter/trim.c
index 4c1a2b4f48..4afc4c74bb 100644
--- a/libavfilter/trim.c
+++ b/libavfilter/trim.c
@@ -364,6 +364,7 @@ const AVFilter ff_vf_trim = {
 .activate= activate,
 .priv_size   = sizeof(TrimContext),
 .priv_class  = &trim_class,
+.flags   = AVFILTER_FLAG_METADATA_ONLY,
 FILTER_INPUTS(trim_inputs),
 FILTER_OUTPUTS(ff_video_default_filterpad),
 };
-- 
2.44.0

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

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

Re: [FFmpeg-devel] [RFC] STF 2025

[Vittorio Giovara]

On Tue, Jun 4, 2024 at 7:39 PM Paul B Mahol  wrote:

> On Tue, Jun 4, 2024 at 2:53 PM Vittorio Giovara <
> vittorio.giov...@gmail.com>
> wrote:
>
> > On Tue, Jun 4, 2024 at 2:02 PM Paul B Mahol  wrote:
> >
> > > On Tue, Jun 4, 2024 at 12:59 PM Vittorio Giovara <
> > > vittorio.giov...@gmail.com>
> > > wrote:
> > >
> > > > On Tue, Jun 4, 2024 at 12:09 PM Paul B Mahol 
> wrote:
> > > >
> > > > > On Tue, Jun 4, 2024 at 9:09 AM Vittorio Giovara <
> > > > > vittorio.giov...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > On Tue, Jun 4, 2024 at 8:55 AM Paul B Mahol 
> > > wrote:
> > > > > >
> > > > > > > On Tue, Jun 4, 2024 at 8:53 AM Vittorio Giovara <
> > > > > > > vittorio.giov...@gmail.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via
> > ffmpeg-devel
> > > <
> > > > > > > > ffmpeg-devel@ffmpeg.org> wrote:
> > > > > > > >
> > > > > > > > > > Reposting my question/comment here since Thilo hasn't
> had a
> > > > > chance
> > > > > > to
> > > > > > > > > > respond, but shouldn't these kinds of requests go through
> > the
> > > > GA?
> > > > > > If
> > > > > > > > > > anybody can do whatever they want with the ffmpeg name,
> > then
> > > > > what's
> > > > > > > the
> > > > > > > > > > point of voting and following the established process?
> > > > > > > > >
> > > > > > > > > Probably? I'm not actually sure what the process is for
> > getting
> > > > an
> > > > > > > FFmpeg
> > > > > > > > > booth at a conference. Is there a documented process
> > somewhere
> > > > for
> > > > > > how
> > > > > > > > this
> > > > > > > > > should be done? If not this might be a good opportunity to
> > > create
> > > > > > one.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Agreed, do you have a draft you could share as a base of
> > > > discussion?
> > > > > > Once
> > > > > > > > defined, we could have the GA vote on it
> > > > > > > >
> > > > > > > >
> > > > > > > > > It might also make for a good topic of discussion at VDD.
> For
> > > how
> > > > > > much
> > > > > > > > > drama there was about NAB on the list I was surprised there
> > was
> > > > > zero
> > > > > > > > > discussion about it at FOSDEM.
> > > > > > > > >
> > > > > > > >
> > > > > > > > There were probably more important topics to discuss and the
> > > > > lingering
> > > > > > > hope
> > > > > > > > that the problematic points would have been handled better
> than
> > > by
> > > > > > > calling
> > > > > > > > people trolls
> > > > > > > >
> > > > > > > >
> > > > > > > > > Regarding the "or you" part, I wasn't involved in securing
> > > > > > sponsorship
> > > > > > > > for
> > > > > > > > > NAB or IBC. I did volunteer to help with NAB because I
> happen
> > > to
> > > > > live
> > > > > > > in
> > > > > > > > > Vegas and I enjoy spending time with other ffmpeg
> developers.
> > > I'm
> > > > > > happy
> > > > > > > > to
> > > > > > > > > help at NAB next year as well should it happen again.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Noted, it should have said "or anybody willing to host/help a
> > > > booth"
> > > > > > > >
> > > > > > > > I have no plans to attend IBC and no involvement with the
> > FFmpeg
> > > > > booth
> > > > > > at
> > > > > > > > > IBC. I am merely trying to correct the perception that NAB
> > was
> > > > > > > > > cost-problematic, since no money was paid by the project
> for
> > > NAB.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don't think anybody is suggesting that booths are
> > > > cost-problematic,
> > > > > > but
> > > > > > > > rather they are lacking in process (one shouldn't allowed use
> > > > ffmpeg
> > > > > > name
> > > > > > > > "just because") and in scope (aka "the why" and what kind of
> > > > results
> > > > > > are
> > > > > > > > expected by investing time in said booth)
> > > > > > > >
> > > > > > >
> > > > > > > Said by prominent LibAV developer.
> > > > > > >
> > > > > >
> > > > > > reported to CC :)
> > > > > >
> > > > >
> > > > > CC is fully controlled by prominent LibAV developers.
> > > > >
> > > >
> > > > Not only is this factually incorrect, it's also unrelated to the
> topic
> > at
> > > > hand. No worries, this infringement is being reported to the CC as
> > well,
> > > > but please try to make an effort at doing better at least.
> > > > Thank you
> > > >
> > >
> > > Do not trust LibAV developers even when they are giving you gifts.
> > >
> >
> > I'm not giving you anything, please can you stop? I don't want to flood
> the
> > CC with emails, but I'll do so if that helps stifle this kind of
> behavior.
> > Please disconnect, grow up, be nicer to your fellow community members,
> and
> > just do better.
> >
>
> Thank you for your arrogant continuous behavior that match nicely with your
> latest code contributions.
>

I don't think I'm being arrogant when I ask you to stop abusive behavior.
Imagine if people responded with "Typical librempeg developer answer" to
all of your email, how would you feel about it?


> If you stop resp

Re: [FFmpeg-devel] [RFC] STF 2025

[Vittorio Giovara]

On Tue, Jun 4, 2024 at 5:47 PM Cosmin Stejerean via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

>
>
> > On Jun 3, 2024, at 11:53 PM, Vittorio Giovara <
> vittorio.giov...@gmail.com> wrote:
> >
> > On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> >
> >>> Reposting my question/comment here since Thilo hasn't had a chance to
> >>> respond, but shouldn't these kinds of requests go through the GA? If
> >>> anybody can do whatever they want with the ffmpeg name, then what's the
> >>> point of voting and following the established process?
> >>
> >> Probably? I'm not actually sure what the process is for getting an
> FFmpeg
> >> booth at a conference. Is there a documented process somewhere for how
> this
> >> should be done? If not this might be a good opportunity to create one.
> >>
> >
> > Agreed, do you have a draft you could share as a base of discussion? Once
> > defined, we could have the GA vote on it
> >
>
> If you really want to work on a proposal I'm happy to collaborate with you
> offline to draft something and then propose it to the GA.
>

Sure I'm happy to work on this with you! Let's talk offline about it

>> It might also make for a good topic of discussion at VDD. For how much
> >> drama there was about NAB on the list I was surprised there was zero
> >> discussion about it at FOSDEM.
> >>
> >
> > There were probably more important topics to discuss and the lingering
> hope
> > that the problematic points would have been handled better than by
> calling
> > people trolls
> >
>
> Perhaps. Shall we set something up at VDD? I think in person discussion
> can go a long way to avoid the kind of miscommunication that can happen
> over email.
>

I'd say we should try and lay down the basic rules for booths and ffmpeg
representations in general, get the approval from GA and see if they can be
applied to IBC. Then we can set up some time at vdd as retro if successful
or think of something else if the drama continues maybe.

Thanks for helping with this complicated situation.
-- 
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] [PATCH 01/10, v3] avutil: add hwcontext_amf.

[Mark Thompson]

On 30/05/2024 14:08, Dmitrii Ovchinnikov wrote:
> Adds hwcontext_amf, which allows to use shared AMF
> context for the encoder, decoder and AMF-based filters,
> without copy to the host memory.
> It will also allow you to use some optimisations in
> the interaction of components (for example, SAV) and make a more
> manageable and optimal setup for using GPU devices with AMF
> in the case of a fully AMF pipeline.
> It will be a significant performance uplift when full AMF pipeline
> with filters is used.
> 
> We also plan to add Compression artefact removal filter in near feature.
> v2: cleanup header files
> v3: an unnecessary class has been removed.
> ---
>  libavutil/Makefile |   4 +
>  libavutil/hwcontext.c  |   4 +
>  libavutil/hwcontext.h  |   1 +
>  libavutil/hwcontext_amf.c  | 585 +
>  libavutil/hwcontext_amf.h  |  64 
>  libavutil/hwcontext_amf_internal.h |  44 +++
>  libavutil/hwcontext_internal.h |   1 +
>  libavutil/pixdesc.c|   4 +
>  libavutil/pixfmt.h |   5 +
>  9 files changed, 712 insertions(+)
>  create mode 100644 libavutil/hwcontext_amf.c
>  create mode 100644 libavutil/hwcontext_amf.h
>  create mode 100644 libavutil/hwcontext_amf_internal.h
> 
> ...
> +
> +static void amf_dummy_free(void *opaque, uint8_t *data)
> +{
> +
> +}
> +
> +static AVBufferRef *amf_pool_alloc(void *opaque, size_t size)
> +{
> +AVHWFramesContext *hwfc = (AVHWFramesContext *)opaque;
> +AVBufferRef *buf;
> +
> +buf = av_buffer_create(NULL, NULL, amf_dummy_free, hwfc, 
> AV_BUFFER_FLAG_READONLY);
> +if (!buf) {
> +av_log(hwfc, AV_LOG_ERROR, "Failed to create buffer for AMF 
> context.\n");
> +return NULL;
> +}
> +return buf;
> +}

You're still allocating nothing here?

I think what this means is that you don't actually want to implement frames 
context creation at all because it doesn't do anything.

If it is not possible to make an AMFSurface as anything other than an output 
from an AMF component then this would make sense, the decoder can allocate the 
internals.

Look at the DRM hwcontext for an example that works like this - the DRM objects 
can only be made as outputs from devices or by mapping, so there is no frame 
context implementation.

> +
> ...
> diff --git a/libavutil/hwcontext_amf.h b/libavutil/hwcontext_amf.h
> new file mode 100644
> index 00..ef2118dd4e
> --- /dev/null
> +++ b/libavutil/hwcontext_amf.h
> @@ -0,0 +1,64 @@
> +/*
> + * 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
> + */
> +
> +
> +#ifndef AVUTIL_HWCONTEXT_AMF_H
> +#define AVUTIL_HWCONTEXT_AMF_H
> +
> +#include "pixfmt.h"
> +#include "hwcontext.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * This struct is allocated as AVHWDeviceContext.hwctx
> + */
> +typedef struct AVAMFDeviceContext {
> +HMODULElibrary;

What is this type?  (It looks like a Windows type, but I thought this was 
cross-platform.)

> +AMFFactory *factory;
> +AMFDebug   *debug;
> +AMFTrace   *trace;
> +void   *trace_writer;

Are all of these objects necessary to operation of the AMF device?  Please 
remove elements which are not necessary and add them to the private context if 
they are otherwise useful.

> +
> +int64_tversion; ///< version of AMF runtime

Why is the version necessary to expose in the public API?  Is it not possible 
to call the QueryVersion function after starting?

> +AMFContext *context;
> +intmem_type;
Is mem_type really necessary to expose in the piblic API?  Can the user not 
determine this by some API call?

> +} AVAMFDeviceContext;
> +
> +enum AMF_SURFACE_FORMAT av_amf_av_to_amf_format(enum AVPixelFormat fmt);
> +enum AVPixelFormat av_amf_to_av_format(enum AMF_SURFACE_FORMAT fmt);
> +

All of the following functions should not be public symbols.  You want to 
implement the hwcontext functions so that these all work without needing 
special implementation for AMF, they should not be individually callable 
because that is not useful.

> +int av_amf_context_create(AVAMFDeviceContext * context,
> + 

[FFmpeg-devel] [PATCHv2 1/4] lavc/vc1dsp: R-V V vc1_inv_trans_8x8

[Rémi Denis-Courmont]

T-Head C908 (cycles):
vc1dsp.vc1_inv_trans_8x8_c:   871.7
vc1dsp.vc1_inv_trans_8x8_rvv_i32: 286.7

---
Changes since version 1:
- Use fixed-point rounding instead of adding 4 or 64 explicitly.

---
 libavcodec/riscv/vc1dsp_init.c |   2 +
 libavcodec/riscv/vc1dsp_rvv.S  | 110 +
 2 files changed, 112 insertions(+)

diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
index e4838fb347..b8a1015ce5 100644
--- a/libavcodec/riscv/vc1dsp_init.c
+++ b/libavcodec/riscv/vc1dsp_init.c
@@ -26,6 +26,7 @@
 #include "libavcodec/vc1.h"
 
 void ff_vc1_inv_trans_8x8_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
+void ff_vc1_inv_trans_8x8_rvv(int16_t block[64]);
 void ff_vc1_inv_trans_4x8_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
 void ff_vc1_inv_trans_8x4_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
 void ff_vc1_inv_trans_4x4_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
@@ -53,6 +54,7 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
 # if HAVE_RVV
 if (flags & AV_CPU_FLAG_RVV_I32) {
 if (ff_rv_vlen_least(128)) {
+dsp->vc1_inv_trans_8x8 = ff_vc1_inv_trans_8x8_rvv;
 dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
 dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
 dsp->avg_vc1_mspel_pixels_tab[0][0] = ff_avg_pixels16x16_rvv;
diff --git a/libavcodec/riscv/vc1dsp_rvv.S b/libavcodec/riscv/vc1dsp_rvv.S
index 8b3a830a4a..e15783d113 100644
--- a/libavcodec/riscv/vc1dsp_rvv.S
+++ b/libavcodec/riscv/vc1dsp_rvv.S
@@ -113,6 +113,116 @@ func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
 ret
 endfunc
 
+.variant_cc ff_vc1_inv_trans_8_rvv
+func ff_vc1_inv_trans_8_rvv, zve32x
+li  t4, 12
+vsll.vi v18, v6, 4
+li  t2, 6
+vmul.vx v8, v0, t4
+li  t5, 15
+vmul.vx v10, v4, t4
+li  t3, 9
+# t[2..5] = [6 9 12 15]
+vsll.vi v12, v2, 4
+vmul.vx v14, v6, t2
+vmul.vx v16, v2, t2
+vadd.vv v26, v12, v14 # t3
+vadd.vv v24, v8, v10  # t1
+vsub.vv v25, v8, v10  # t2
+vsub.vv v27, v16, v18 # t4
+vadd.vv v28, v24, v26 # t5
+vsub.vv v31, v24, v26 # t8
+vadd.vv v29, v25, v27 # t6
+vsub.vv v30, v25, v27 # t7
+vsll.vi v20, v1, 4
+vmul.vx v21, v3, t5
+vmul.vx v22, v5, t3
+vsll.vi v23, v7, 2
+vadd.vv v20, v20, v21
+vadd.vv v22, v22, v23
+vsll.vi v21, v3, 2
+vadd.vv v16, v20, v22 # t1
+vmul.vx v20, v1, t5
+vsll.vi v22, v5, 4
+vmul.vx v23, v7, t3
+vsub.vv v20, v20, v21
+vadd.vv v22, v22, v23
+vsll.vi v21, v3, 4
+vsub.vv v17, v20, v22 # t2
+vmul.vx v20, v1, t3
+vsll.vi v22, v5, 2
+vmul.vx v23, v7, t5
+vsub.vv v20, v20, v21
+vadd.vv v22, v22, v23
+vmul.vx v21, v3, t3
+vadd.vv v18, v20, v22 # t3
+vsll.vi v20, v1, 2
+vmul.vx v22, v5, t5
+vsll.vi v23, v7, 4
+vsub.vv v20, v20, v21
+vsub.vv v22, v22, v23
+vadd.vv v0, v28, v16
+vadd.vv v19, v20, v22 # t4
+vadd.vv v1, v29, v17
+vadd.vv v2, v30, v18
+vadd.vv v3, v31, v19
+vsub.vv v4, v31, v19
+vsub.vv v5, v30, v18
+vsub.vv v6, v29, v17
+vsub.vv v7, v28, v16
+jr  t0
+endfunc
+
+func ff_vc1_inv_trans_8x8_rvv, zve32x
+csrwivxrm, 0
+vsetivli zero, 8, e16, m1, ta, ma
+addi a1, a0, 1 * 8 * 2
+vle16.v  v0, (a0)
+addi a2, a0, 2 * 8 * 2
+vle16.v  v1, (a1)
+addi a3, a0, 3 * 8 * 2
+vle16.v  v2, (a2)
+addi a4, a0, 4 * 8 * 2
+vle16.v  v3, (a3)
+addi a5, a0, 5 * 8 * 2
+vle16.v  v4, (a4)
+addi a6, a0, 6 * 8 * 2
+vle16.v  v5, (a5)
+addi a7, a0, 7 * 8 * 2
+vle16.v  v6, (a6)
+vle16.v  v7, (a7)
+jal  t0, ff_vc1_inv_trans_8_rvv
+.irp n,0,1,2,3,4,5,6,7
+vssra.vi v\n, v\n, 3
+.endr
+vsseg8e16.v v0, (a0)
+.irp n,0,1,2,3,4,5,6,7
+vle16.v  v\n, (a\n)
+.endr
+jal  t0, ff_vc1_inv_trans_8_rvv
+vadd.vi  v4, v4, 1
+vadd.vi  v5, v5, 1
+vssra.vi v4, v4, 7
+vssra.vi v5, v5, 7
+vse16.v  v4, (a4)
+vadd.vi  v6, v6, 1
+vse16.v  v5, (a5)
+vadd.vi  v7, v7, 1
+vssra.vi v6, v6, 7
+vssra.vi v7, v7, 7
+vse16.v  v6, (a6)
+vssra.vi v0, v0, 7
+vse16.v  v7, (a7)
+vssra.vi v1, v1, 7
+vse16.v  v0, (a0)
+vssra.vi v2, v2, 7
+vse16.v  v1, (a1)
+vssra.vi v3, v3, 7
+vse16.v  v2, (a2)
+vse16.v  v3, (a3)
+ret
+endfunc
+
 .macro mspel_op op pos n1 n2
 add   t1, \pos, a2
 v\op\()e8.v   v\n1, (

[FFmpeg-devel] [PATCHv2 2/4] lavc/vc1dsp: R-V V vc1_inv_trans_8x4

[Rémi Denis-Courmont]

T-Head C908 (cycles):
vc1dsp.vc1_inv_trans_8x4_c:   626.2
vc1dsp.vc1_inv_trans_8x4_rvv_i32: 215.2

---
Changes since version 1:
- Properly set VXRM (callee-clobbered).

---
 libavcodec/riscv/vc1dsp_init.c |  2 +
 libavcodec/riscv/vc1dsp_rvv.S  | 73 ++
 2 files changed, 75 insertions(+)

diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
index b8a1015ce5..e63870ad44 100644
--- a/libavcodec/riscv/vc1dsp_init.c
+++ b/libavcodec/riscv/vc1dsp_init.c
@@ -29,6 +29,7 @@ void ff_vc1_inv_trans_8x8_dc_rvv(uint8_t *dest, ptrdiff_t 
stride, int16_t *block
 void ff_vc1_inv_trans_8x8_rvv(int16_t block[64]);
 void ff_vc1_inv_trans_4x8_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
 void ff_vc1_inv_trans_8x4_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
+void ff_vc1_inv_trans_8x4_rvv(uint8_t *dest, ptrdiff_t stride, int16_t *block);
 void ff_vc1_inv_trans_4x4_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
 void ff_put_pixels16x16_rvi(uint8_t *dst, const uint8_t *src, ptrdiff_t 
line_size, int rnd);
 void ff_put_pixels8x8_rvi(uint8_t *dst, const uint8_t *src, ptrdiff_t 
line_size, int rnd);
@@ -55,6 +56,7 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
 if (flags & AV_CPU_FLAG_RVV_I32) {
 if (ff_rv_vlen_least(128)) {
 dsp->vc1_inv_trans_8x8 = ff_vc1_inv_trans_8x8_rvv;
+dsp->vc1_inv_trans_8x4 = ff_vc1_inv_trans_8x4_rvv;
 dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
 dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
 dsp->avg_vc1_mspel_pixels_tab[0][0] = ff_avg_pixels16x16_rvv;
diff --git a/libavcodec/riscv/vc1dsp_rvv.S b/libavcodec/riscv/vc1dsp_rvv.S
index e15783d113..d003185ade 100644
--- a/libavcodec/riscv/vc1dsp_rvv.S
+++ b/libavcodec/riscv/vc1dsp_rvv.S
@@ -173,6 +173,31 @@ func ff_vc1_inv_trans_8_rvv, zve32x
 jr  t0
 endfunc
 
+.variant_cc ff_vc1_inv_trans_4_rvv
+func ff_vc1_inv_trans_4_rvv, zve32x
+li  t3, 17
+vmul.vx v8, v0, t3
+li  t4, 22
+vmul.vx v10, v2, t3
+li  t2, 10
+vmul.vx v14, v1, t4
+vadd.vv v24, v8, v10  # t1
+vsub.vv v25, v8, v10  # t2
+vmul.vx v16, v3, t2
+vmul.vx v18, v3, t4
+vmul.vx v20, v1, t2
+vadd.vv v26, v14, v16 # t3
+vsub.vv v27, v18, v20 # t4
+vadd.vv v0, v24, v26
+vsub.vv v1, v25, v27
+vadd.vv v2, v25, v27
+vsub.vv v3, v24, v26
+.irpn,0,1,2,3
+vssra.vx v\n, v\n, t1 # + 4 >> 3 or + 64 >> 7
+.endr
+jr  t0
+endfunc
+
 func ff_vc1_inv_trans_8x8_rvv, zve32x
 csrwivxrm, 0
 vsetivli zero, 8, e16, m1, ta, ma
@@ -223,6 +248,54 @@ func ff_vc1_inv_trans_8x8_rvv, zve32x
 ret
 endfunc
 
+func ff_vc1_inv_trans_8x4_rvv, zve32x
+csrwi   vxrm, 0
+vsetivlizero, 4, e16, mf2, ta, ma
+vlseg8e16.v v0, (a2)
+jal t0, ff_vc1_inv_trans_8_rvv
+vsseg8e16.v v0, (a2)
+addia3, a2, 1 * 8 * 2
+vsetivlizero, 8, e16, m1, ta, ma
+vle16.v v0, (a2)
+addia4, a2, 2 * 8 * 2
+vle16.v v1, (a3)
+addia5, a2, 3 * 8 * 2
+vle16.v v2, (a4)
+vle16.v v3, (a5)
+.irpn,0,1,2,3
+# shift 4 vectors of 8 elems after transpose instead of 8 of 4
+vssra.viv\n, v\n, 3
+.endr
+li  t1, 7
+jal t0, ff_vc1_inv_trans_4_rvv
+add a3, a1, a0
+vle8.v  v8, (a0)
+add a4, a1, a3
+vle8.v  v9, (a3)
+add a5, a1, a4
+vle8.v  v10, (a4)
+vle8.v  v11, (a5)
+vsetvli zero, zero, e8, mf2, ta, ma
+vwaddu.wv   v0, v0, v8
+vwaddu.wv   v1, v1, v9
+vwaddu.wv   v2, v2, v10
+vwaddu.wv   v3, v3, v11
+vsetvli zero, zero, e16, m1, ta, ma
+.irpn,0,1,2,3
+vmax.vx v\n, v\n, zero
+.endr
+vsetvli zero, zero, e8, mf2, ta, ma
+vnclipu.wi  v8, v0, 0
+vnclipu.wi  v9, v1, 0
+vse8.v  v8, (a0)
+vnclipu.wi  v10, v2, 0
+vse8.v  v9, (a3)
+vnclipu.wi  v11, v3, 0
+vse8.v  v10, (a4)
+vse8.v  v11, (a5)
+ret
+endfunc
+
 .macro mspel_op op pos n1 n2
 add   t1, \pos, a2
 v\op\()e8.v   v\n1, (\pos)
-- 
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] [PATCHv2 3/4] lavc/vc1dsp: R-V V vc1_inv_trans_4x8

[Rémi Denis-Courmont]

T-Head C908 (cycles):
vc1dsp.vc1_inv_trans_4x8_c: 653.2
vc1dsp.vc1_inv_trans_4x8_rvv_i32: 234.0
---
 libavcodec/riscv/vc1dsp_init.c |  2 +
 libavcodec/riscv/vc1dsp_rvv.S  | 77 ++
 2 files changed, 79 insertions(+)

diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
index e63870ad44..cf9d42f377 100644
--- a/libavcodec/riscv/vc1dsp_init.c
+++ b/libavcodec/riscv/vc1dsp_init.c
@@ -28,6 +28,7 @@
 void ff_vc1_inv_trans_8x8_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
 void ff_vc1_inv_trans_8x8_rvv(int16_t block[64]);
 void ff_vc1_inv_trans_4x8_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
+void ff_vc1_inv_trans_4x8_rvv(uint8_t *dest, ptrdiff_t stride, int16_t *block);
 void ff_vc1_inv_trans_8x4_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
 void ff_vc1_inv_trans_8x4_rvv(uint8_t *dest, ptrdiff_t stride, int16_t *block);
 void ff_vc1_inv_trans_4x4_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
@@ -57,6 +58,7 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
 if (ff_rv_vlen_least(128)) {
 dsp->vc1_inv_trans_8x8 = ff_vc1_inv_trans_8x8_rvv;
 dsp->vc1_inv_trans_8x4 = ff_vc1_inv_trans_8x4_rvv;
+dsp->vc1_inv_trans_4x8 = ff_vc1_inv_trans_4x8_rvv;
 dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
 dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
 dsp->avg_vc1_mspel_pixels_tab[0][0] = ff_avg_pixels16x16_rvv;
diff --git a/libavcodec/riscv/vc1dsp_rvv.S b/libavcodec/riscv/vc1dsp_rvv.S
index d003185ade..e22950d25d 100644
--- a/libavcodec/riscv/vc1dsp_rvv.S
+++ b/libavcodec/riscv/vc1dsp_rvv.S
@@ -296,6 +296,83 @@ func ff_vc1_inv_trans_8x4_rvv, zve32x
 ret
 endfunc
 
+func ff_vc1_inv_trans_4x8_rvv, zve32x
+li   a3, 8 * 2
+csrwivxrm, 0
+vsetivli zero, 8, e16, m1, ta, ma
+vlsseg4e16.v v0, (a2), a3
+li   t1, 3
+jal  t0, ff_vc1_inv_trans_4_rvv
+addi t1, a2, 1 * 8 * 2
+vse16.v  v0, (a2)
+addi t2, a2, 2 * 8 * 2
+vse16.v  v1, (t1)
+addi t3, a2, 3 * 8 * 2
+vse16.v  v2, (t2)
+vse16.v  v3, (t3)
+vsetivli zero, 4, e16, mf2, ta, ma
+vlseg8e16.v  v0, (a2)
+jal  t0, ff_vc1_inv_trans_8_rvv
+vadd.vi  v4, v4, 1
+add  t0, a1, a0
+vadd.vi  v5, v5, 1
+vadd.vi  v6, v6, 1
+add  t1, a1, t0
+vadd.vi  v7, v7, 1
+vssra.vi v0, v0, 7
+add  t2, a1, t1
+vssra.vi v1, v1, 7
+vssra.vi v2, v2, 7
+add  t3, a1, t2
+vssra.vi v3, v3, 7
+vssra.vi v4, v4, 7
+add  t4, a1, t3
+vssra.vi v5, v5, 7
+vssra.vi v6, v6, 7
+add  t5, a1, t4
+vssra.vi v7, v7, 7
+vle8.v   v8, (a0)
+add  t6, a1, t5
+vle8.v   v9, (t0)
+vle8.v   v10, (t1)
+vle8.v   v11, (t2)
+vle8.v   v12, (t3)
+vle8.v   v13, (t4)
+vle8.v   v14, (t5)
+vle8.v   v15, (t6)
+vsetvli  zero, zero, e8, mf4, ta, ma
+vwaddu.wvv0, v0, v8
+vwaddu.wvv1, v1, v9
+vwaddu.wvv2, v2, v10
+vwaddu.wvv3, v3, v11
+vwaddu.wvv4, v4, v12
+vwaddu.wvv5, v5, v13
+vwaddu.wvv6, v6, v14
+vwaddu.wvv7, v7, v15
+vsetvli  zero, zero, e16, mf2, ta, ma
+.irpn,0,1,2,3,4,5,6,7
+vmax.vx  v\n, v\n, zero
+.endr
+vsetvli  zero, zero, e8, mf4, ta, ma
+vnclipu.wi   v8, v0, 0
+vnclipu.wi   v9, v1, 0
+vse8.v   v8, (a0)
+vnclipu.wi   v10, v2, 0
+vse8.v   v9, (t0)
+vnclipu.wi   v11, v3, 0
+vse8.v   v10, (t1)
+vnclipu.wi   v12, v4, 0
+vse8.v   v11, (t2)
+vnclipu.wi   v13, v5, 0
+vse8.v   v12, (t3)
+vnclipu.wi   v14, v6, 0
+vse8.v   v13, (t4)
+vnclipu.wi   v15, v7, 0
+vse8.v   v14, (t5)
+vse8.v   v15, (t6)
+ret
+endfunc
+
 .macro mspel_op op pos n1 n2
 add   t1, \pos, a2
 v\op\()e8.v   v\n1, (\pos)
-- 
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] [PATCHv2 4/4] lavc/vc1dsp: R-V V vc1_inv_trans_4x4

[Rémi Denis-Courmont]

T-Head C908 (cycles):
vc1dsp.vc1_inv_trans_4x4_c: 310.7
vc1dsp.vc1_inv_trans_4x4_rvv_i32: 120.0

We could use 1 `vlseg4e64.v` instead of 4 `vle16.v`, but that seems to
be about 7% slower.
---
 libavcodec/riscv/vc1dsp_init.c |  2 ++
 libavcodec/riscv/vc1dsp_rvv.S  | 47 ++
 2 files changed, 49 insertions(+)

diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
index cf9d42f377..de9002f395 100644
--- a/libavcodec/riscv/vc1dsp_init.c
+++ b/libavcodec/riscv/vc1dsp_init.c
@@ -32,6 +32,7 @@ void ff_vc1_inv_trans_4x8_rvv(uint8_t *dest, ptrdiff_t 
stride, int16_t *block);
 void ff_vc1_inv_trans_8x4_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
 void ff_vc1_inv_trans_8x4_rvv(uint8_t *dest, ptrdiff_t stride, int16_t *block);
 void ff_vc1_inv_trans_4x4_dc_rvv(uint8_t *dest, ptrdiff_t stride, int16_t 
*block);
+void ff_vc1_inv_trans_4x4_rvv(uint8_t *dest, ptrdiff_t stride, int16_t *block);
 void ff_put_pixels16x16_rvi(uint8_t *dst, const uint8_t *src, ptrdiff_t 
line_size, int rnd);
 void ff_put_pixels8x8_rvi(uint8_t *dst, const uint8_t *src, ptrdiff_t 
line_size, int rnd);
 void ff_avg_pixels16x16_rvv(uint8_t *dst, const uint8_t *src, ptrdiff_t 
line_size, int rnd);
@@ -59,6 +60,7 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
 dsp->vc1_inv_trans_8x8 = ff_vc1_inv_trans_8x8_rvv;
 dsp->vc1_inv_trans_8x4 = ff_vc1_inv_trans_8x4_rvv;
 dsp->vc1_inv_trans_4x8 = ff_vc1_inv_trans_4x8_rvv;
+dsp->vc1_inv_trans_4x4 = ff_vc1_inv_trans_4x4_rvv;
 dsp->vc1_inv_trans_4x8_dc = ff_vc1_inv_trans_4x8_dc_rvv;
 dsp->vc1_inv_trans_4x4_dc = ff_vc1_inv_trans_4x4_dc_rvv;
 dsp->avg_vc1_mspel_pixels_tab[0][0] = ff_avg_pixels16x16_rvv;
diff --git a/libavcodec/riscv/vc1dsp_rvv.S b/libavcodec/riscv/vc1dsp_rvv.S
index e22950d25d..03c942cba2 100644
--- a/libavcodec/riscv/vc1dsp_rvv.S
+++ b/libavcodec/riscv/vc1dsp_rvv.S
@@ -113,6 +113,8 @@ func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
 ret
 endfunc
 
+#include "../../riscv-tests/debug.S"
+
 .variant_cc ff_vc1_inv_trans_8_rvv
 func ff_vc1_inv_trans_8_rvv, zve32x
 li  t4, 12
@@ -373,6 +375,51 @@ func ff_vc1_inv_trans_4x8_rvv, zve32x
 ret
 endfunc
 
+func ff_vc1_inv_trans_4x4_rvv, zve32x
+li   a3, 8 * 2
+csrwivxrm, 0
+vsetivli zero, 4, e16, mf2, ta, ma
+vlsseg4e16.v v0, (a2), a3
+li   t1, 3
+jal  t0, ff_vc1_inv_trans_4_rvv
+vsseg4e16.v  v0, (a2)
+addi t1, a2, 1 * 4 * 2
+vle16.v  v0, (a2)
+addi t2, a2, 2 * 4 * 2
+vle16.v  v1, (t1)
+addi t3, a2, 3 * 4 * 2
+vle16.v  v2, (t2)
+vle16.v  v3, (t3)
+li   t1, 7
+jal  t0, ff_vc1_inv_trans_4_rvv
+add  t1, a1, a0
+vle8.v   v8, (a0)
+add  t2, a1, t1
+vle8.v   v9, (t1)
+add  t3, a1, t2
+vle8.v   v10, (t2)
+vle8.v   v11, (t3)
+vsetvli  zero, zero, e8, mf4, ta, ma
+vwaddu.wvv0, v0, v8
+vwaddu.wvv1, v1, v9
+vwaddu.wvv2, v2, v10
+vwaddu.wvv3, v3, v11
+vsetvli  zero, zero, e16, mf2, ta, ma
+.irpn,0,1,2,3
+vmax.vx  v\n, v\n, zero
+.endr
+vsetvli  zero, zero, e8, mf4, ta, ma
+vnclipu.wi   v8, v0, 0
+vnclipu.wi   v9, v1, 0
+vse8.v   v8, (a0)
+vnclipu.wi   v10, v2, 0
+vse8.v   v9, (t1)
+vnclipu.wi   v11, v3, 0
+vse8.v   v10, (t2)
+vse8.v   v11, (t3)
+ret
+endfunc
+
 .macro mspel_op op pos n1 n2
 add   t1, \pos, a2
 v\op\()e8.v   v\n1, (\pos)
-- 
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] [PATCH] swscale/x86/input: add AVX2 optimized RGB24 to YUV functions

[James Almer]

rgb24_to_uv_8_c: 39.3
rgb24_to_uv_8_sse2: 14.3
rgb24_to_uv_8_ssse3: 13.3
rgb24_to_uv_8_avx: 12.8
rgb24_to_uv_8_avx2: 14.3
rgb24_to_uv_128_c: 582.8
rgb24_to_uv_128_sse2: 127.3
rgb24_to_uv_128_ssse3: 107.3
rgb24_to_uv_128_avx: 111.3
rgb24_to_uv_128_avx2: 62.3
rgb24_to_uv_1080_c: 4981.3
rgb24_to_uv_1080_sse2: 1048.3
rgb24_to_uv_1080_ssse3: 876.8
rgb24_to_uv_1080_avx: 887.8
rgb24_to_uv_1080_avx2: 492.3
rgb24_to_uv_1280_c: 5906.8
rgb24_to_uv_1280_sse2: 1263.3
rgb24_to_uv_1280_ssse3: 1048.3
rgb24_to_uv_1280_avx: 1045.8
rgb24_to_uv_1280_avx2: 579.8
rgb24_to_uv_1920_c: 8665.3
rgb24_to_uv_1920_sse2: 1888.8
rgb24_to_uv_1920_ssse3: 1571.8
rgb24_to_uv_1920_avx: 1558.8
rgb24_to_uv_1920_avx2: 869.3
rgb24_to_y_8_c: 20.3
rgb24_to_y_8_sse2: 11.8
rgb24_to_y_8_ssse3: 10.3
rgb24_to_y_8_avx: 10.3
rgb24_to_y_8_avx2: 10.8
rgb24_to_y_128_c: 284.8
rgb24_to_y_128_sse2: 83.3
rgb24_to_y_128_ssse3: 66.8
rgb24_to_y_128_avx: 64.8
rgb24_to_y_128_avx2: 39.3
rgb24_to_y_1080_c: 2451.3
rgb24_to_y_1080_sse2: 696.3
rgb24_to_y_1080_ssse3: 516.8
rgb24_to_y_1080_avx: 518.8
rgb24_to_y_1080_avx2: 301.8
rgb24_to_y_1280_c: 2892.8
rgb24_to_y_1280_sse2: 816.8
rgb24_to_y_1280_ssse3: 623.3
rgb24_to_y_1280_avx: 616.3
rgb24_to_y_1280_avx2: 350.8
rgb24_to_y_1920_c: 4338.8
rgb24_to_y_1920_sse2: 1210.8
rgb24_to_y_1920_ssse3: 928.3
rgb24_to_y_1920_avx: 920.3
rgb24_to_y_1920_avx2: 534.8

Signed-off-by: James Almer 
---
 libswscale/x86/input.asm | 49 
 libswscale/x86/swscale.c |  7 ++
 2 files changed, 51 insertions(+), 5 deletions(-)

diff --git a/libswscale/x86/input.asm b/libswscale/x86/input.asm
index a197183f1f..e79fe11405 100644
--- a/libswscale/x86/input.asm
+++ b/libswscale/x86/input.asm
@@ -23,7 +23,7 @@
 
 %include "libavutil/x86/x86util.asm"
 
-SECTION_RODATA
+SECTION_RODATA 32
 
 %define RY 0x20DE
 %define GY 0x4087
@@ -90,8 +90,12 @@ rgb_UVrnd:   times 4 dd 0x400100   ; 128.5 << 15
 ; rgba_Vcoeff_ag:  times 4 dw 0,  GV
 
 shuf_rgb_12x4:   db 0, 0x80, 1, 0x80,  2, 0x80,  3, 0x80, \
+6, 0x80, 7, 0x80,  8, 0x80,  9, 0x80, \
+0, 0x80, 1, 0x80,  2, 0x80,  3, 0x80, \
 6, 0x80, 7, 0x80,  8, 0x80,  9, 0x80
 shuf_rgb_3x56:   db 2, 0x80, 3, 0x80,  4, 0x80,  5, 0x80, \
+8, 0x80, 9, 0x80, 10, 0x80, 11, 0x80, \
+2, 0x80, 3, 0x80,  4, 0x80,  5, 0x80, \
 8, 0x80, 9, 0x80, 10, 0x80, 11, 0x80
 pd_65535f: times 8 dd 65535.0
 pb_pack_shuffle16le:db  0,  1,  4,  5, \
@@ -134,8 +138,13 @@ SECTION .text
 %macro RGB24_TO_Y_FN 2-3
 cglobal %2 %+ 24ToY, 6, 6, %1, dst, src, u1, u2, w, table
 %if ARCH_X86_64
+%if mmsize == 32
+vbroadcasti128 m8, [%2_Ycoeff_12x4]
+vbroadcasti128 m9, [%2_Ycoeff_3x56]
+%else
 mova   m8, [%2_Ycoeff_12x4]
 mova   m9, [%2_Ycoeff_3x56]
+%endif
 %define coeff1 m8
 %define coeff2 m9
 %else ; x86-32
@@ -165,11 +174,19 @@ cglobal %2 %+ 24ToY, 6, 6, %1, dst, src, u1, u2, w, table
 %if notcpuflag(ssse3)
 pxor   m7, m7
 %endif ; !cpuflag(ssse3)
+%if mmsize == 32
+vbroadcasti128 m4, [rgb_Yrnd]
+%else
 mova   m4, [rgb_Yrnd]
+%endif
 .loop:
 %if cpuflag(ssse3)
-movu   m0, [srcq+0]   ; (byte) { Bx, Gx, Rx }[0-3]
-movu   m2, [srcq+12]  ; (byte) { Bx, Gx, Rx }[4-7]
+movu  xm0, [srcq+0]   ; (byte) { Bx, Gx, Rx }[0-3]
+movu  xm2, [srcq+12]  ; (byte) { Bx, Gx, Rx }[4-7]
+%if mmsize == 32
+vinserti128m0, m0, [srcq+24], 1
+vinserti128m2, m2, [srcq+36], 1
+%endif
 pshufb m1, m0, shuf_rgb2  ; (word) { R0, B1, G1, R1, R2, B3, 
G3, R3 }
 pshufb m0, shuf_rgb1  ; (word) { B0, G0, R0, B1, B2, G2, 
R2, B3 }
 pshufb m3, m2, shuf_rgb2  ; (word) { R4, B5, G5, R5, R6, B7, 
G7, R7 }
@@ -216,10 +233,17 @@ cglobal %2 %+ 24ToY, 6, 6, %1, dst, src, u1, u2, w, table
 %macro RGB24_TO_UV_FN 2-3
 cglobal %2 %+ 24ToUV, 7, 7, %1, dstU, dstV, u1, src, u2, w, table
 %if ARCH_X86_64
+%if mmsize == 32
+vbroadcasti128  m8, [%2_Ucoeff_12x4]
+vbroadcasti128  m9, [%2_Ucoeff_3x56]
+vbroadcasti128 m10, [%2_Vcoeff_12x4]
+vbroadcasti128 m11, [%2_Vcoeff_3x56]
+%else
 mova   m8, [%2_Ucoeff_12x4]
 mova   m9, [%2_Ucoeff_3x56]
 mova  m10, [%2_Vcoeff_12x4]
 mova  m11, [%2_Vcoeff_3x56]
+%endif
 %define coeffU1 m8
 %define coeffU2 m9
 %define coeffV1 m10
@@ -253,14 +277,22 @@ cglobal %2 %+ 24ToUV, 7, 7, %1, dstU, dstV, u1, src, u2, 
w, table
 add dstUq, wq
 add dstVq, wq
 negwq
+%if mmsize == 32
+vbroadcasti128 m6, [rgb_UVrnd]
+%else
 mova   m6, [rgb_UVrnd]
+%endif
 %if notcpuflag(ssse3)
 pxor   m7, m7
 %endif
 .loop:
 %if cpuflag(ssse3)
-movu   m0, [srcq+0]   ; (byte) { Bx, Gx, Rx }[0-3]
-movu   m4, [srcq+12]  ; (byte) { Bx, Gx, Rx }[4-7]
+movu  x

Re: [FFmpeg-devel] [PATCH] avfilter/trim: flag trim filter as metadata only

[Stefano Sabatini]

On date Tuesday 2024-06-04 23:41:05 +0530, Gyan Doshi wrote:
> Similar to select filter for video - it can only pass through or drop frames
> ---
>  libavfilter/trim.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavfilter/trim.c b/libavfilter/trim.c
> index 4c1a2b4f48..4afc4c74bb 100644
> --- a/libavfilter/trim.c
> +++ b/libavfilter/trim.c
> @@ -364,6 +364,7 @@ const AVFilter ff_vf_trim = {
>  .activate= activate,
>  .priv_size   = sizeof(TrimContext),
>  .priv_class  = &trim_class,
> +.flags   = AVFILTER_FLAG_METADATA_ONLY,
>  FILTER_INPUTS(trim_inputs),
>  FILTER_OUTPUTS(ff_video_default_filterpad),
>  };
> -- 
> 2.44.0

Should be good.
___
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 02/10, v3] avcodec: add amfdec.

[Mark Thompson]

On 30/05/2024 14:08, Dmitrii Ovchinnikov wrote:
> From: Evgeny Pavlov 
> 
> Added AMF based h264, hevc, av1 decoders.
> Co-authored-by: Dmitrii Ovchinnikov 
> v2: added encoder reinitialisation
> v3: use AMF_SURFACE_UNKNOWN to int decoder(ctx->output_format before)
> ---
>  libavcodec/Makefile|   7 +-
>  libavcodec/allcodecs.c |   3 +
>  libavcodec/amfdec.c| 696 +
>  libavcodec/amfdec.h|  63 
>  4 files changed, 767 insertions(+), 2 deletions(-)
>  create mode 100644 libavcodec/amfdec.c
>  create mode 100644 libavcodec/amfdec.h
> 
> ...
> +
> +const enum AVPixelFormat amf_dec_pix_fmts[] = {
> +AV_PIX_FMT_YUV420P,
> +AV_PIX_FMT_NV12,
> +AV_PIX_FMT_BGRA,
> +AV_PIX_FMT_ARGB,
> +AV_PIX_FMT_RGBA,
> +AV_PIX_FMT_GRAY8,
> +AV_PIX_FMT_BGR0,
> +AV_PIX_FMT_YUYV422,
> +AV_PIX_FMT_P010,
> +AV_PIX_FMT_P012,
> +AV_PIX_FMT_YUV420P10,
> +AV_PIX_FMT_YUV420P12,
> +AV_PIX_FMT_YUV420P16,
> +#if CONFIG_D3D11VA
> +AV_PIX_FMT_D3D11,
> +#endif
> +#if CONFIG_DXVA2
> +AV_PIX_FMT_DXVA2_VLD,
> +#endif
> +AV_PIX_FMT_AMF_SURFACE,
> +AV_PIX_FMT_NONE
> +};

What is this set of formats doing?  Most of them are ignored becase get_format 
below only ever offers two choices.

> +
> +static const AVCodecHWConfigInternal *const amf_hw_configs[] = {
> +&(const AVCodecHWConfigInternal) {
> +.public = {
> +.pix_fmt = AV_PIX_FMT_AMF_SURFACE,
> +.methods = AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX |

See below, I don't think it makes sense to have HW_FRAMES_CTX in this decoder.

> +   AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX,
> +.device_type = AV_HWDEVICE_TYPE_AMF,
> +},
> +.hwaccel = NULL,
> +},
> +NULL
> +};
> +
> ...
> +
> +static int amf_init_decoder(AVCodecContext *avctx)
> +{
> +AMFDecoderContext *ctx = avctx->priv_data;
> +AVAMFDeviceContext * internal = ctx->amf_device_ctx;
> +const wchar_t   *codec_id = NULL;
> +AMF_RESULT  res;
> +AMFBuffer   *buffer;
> +amf_int64   color_profile;
> +int pool_size = 36;
> +
> +ctx->drain = 0;
> +ctx->resolution_changed = 0;
> +
> +switch (avctx->codec->id) {
> +case AV_CODEC_ID_H264:
> +codec_id = AMFVideoDecoderUVD_H264_AVC;
> +break;
> +case AV_CODEC_ID_HEVC: {
> +if (avctx->profile == AV_PROFILE_HEVC_MAIN_10)

You won't know profile here?  It is an output field, the decoder has to set it 
once it determines it from the stream.

> +codec_id = AMFVideoDecoderHW_H265_MAIN10;
> +else
> +codec_id = AMFVideoDecoderHW_H265_HEVC;
> +} break;
> +case AV_CODEC_ID_AV1:
> +if (avctx->profile == AV_PROFILE_AV1_PROFESSIONAL)
> +codec_id = AMFVideoDecoderHW_AV1_12BIT;
> +else
> +codec_id = AMFVideoDecoderHW_AV1;
> +break;
> +default:
> +break;
> +}
> +AMF_RETURN_IF_FALSE(ctx, codec_id != NULL, AVERROR(EINVAL), "Codec %d is 
> not supported\n", avctx->codec->id);
> +
> +...> +
> +static int amf_decode_init(AVCodecContext *avctx)
> +{
> +AMFDecoderContext *ctx = avctx->priv_data;
> +int ret;
> +ctx->local_context = 0;
> +ctx->in_pkt = av_packet_alloc();
> +if (!ctx->in_pkt)
> +return AVERROR(ENOMEM);
> +
> +if (avctx->hw_frames_ctx){

This will never be set at init time because the user sets it in the get_format 
callback (see documentation for the field).

Even ignoring that, I don't see how this would make sense ayway?  The AMF 
frames context is a dummy shell containing nothing, so the 
AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX can't do anything useful.

(How are you testing this path?)

> +AVHWFramesContext *frames_ctx = 
> (AVHWFramesContext*)avctx->hw_frames_ctx->data;
> +if (frames_ctx->device_ctx->type == AV_HWDEVICE_TYPE_AMF) {
> +ctx->amf_device_ctx =  frames_ctx->device_ctx->hwctx;
> +}
> +}
> +else if  (avctx->hw_device_ctx && !avctx->hw_frames_ctx) {
> +AVHWDeviceContext   *hwdev_ctx;
> +AVHWFramesContext *hwframes_ctx;
> +hwdev_ctx = (AVHWDeviceContext*)avctx->hw_device_ctx->data;
> +if (hwdev_ctx->type == AV_HWDEVICE_TYPE_AMF)
> +{
> +ctx->amf_device_ctx =  hwdev_ctx->hwctx;
> +}
> +
> +avctx->hw_frames_ctx = av_hwframe_ctx_alloc(avctx->hw_device_ctx);
> +
> +if (!avctx->hw_frames_ctx) {
> +av_log(avctx, AV_LOG_ERROR, "av_hwframe_ctx_alloc failed\n");
> +return AVERROR(ENOMEM);
> +}
> +
> +hwframes_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
> +hwframes_ctx->width = FFALIGN(avctx->coded_width,  32);
> +hwframes_ctx->height= FFALIGN(avc

Re: [FFmpeg-devel] [PATCH] swscale/x86/input: add AVX2 optimized RGB24 to YUV functions

[Andreas Rheinhardt]

James Almer:
> rgb24_to_uv_8_c: 39.3
> rgb24_to_uv_8_sse2: 14.3
> rgb24_to_uv_8_ssse3: 13.3
> rgb24_to_uv_8_avx: 12.8
> rgb24_to_uv_8_avx2: 14.3

Worse than avx and ssse3

> rgb24_to_uv_128_c: 582.8
> rgb24_to_uv_128_sse2: 127.3
> rgb24_to_uv_128_ssse3: 107.3
> rgb24_to_uv_128_avx: 111.3

Worse than ssse3

> rgb24_to_uv_128_avx2: 62.3
> rgb24_to_uv_1080_c: 4981.3
> rgb24_to_uv_1080_sse2: 1048.3
> rgb24_to_uv_1080_ssse3: 876.8
> rgb24_to_uv_1080_avx: 887.8

Worse than ssse3

> rgb24_to_uv_1080_avx2: 492.3
> rgb24_to_uv_1280_c: 5906.8
> rgb24_to_uv_1280_sse2: 1263.3
> rgb24_to_uv_1280_ssse3: 1048.3
> rgb24_to_uv_1280_avx: 1045.8

Not really better than ssse3

> rgb24_to_uv_1280_avx2: 579.8
> rgb24_to_uv_1920_c: 8665.3
> rgb24_to_uv_1920_sse2: 1888.8
> rgb24_to_uv_1920_ssse3: 1571.8
> rgb24_to_uv_1920_avx: 1558.8

Not really better than ssse3

> rgb24_to_uv_1920_avx2: 869.3
> rgb24_to_y_8_c: 20.3
> rgb24_to_y_8_sse2: 11.8
> rgb24_to_y_8_ssse3: 10.3
> rgb24_to_y_8_avx: 10.3

Not better than ssse3

> rgb24_to_y_8_avx2: 10.8

Worse than ssse3

> rgb24_to_y_128_c: 284.8
> rgb24_to_y_128_sse2: 83.3
> rgb24_to_y_128_ssse3: 66.8
> rgb24_to_y_128_avx: 64.8

Not really better than ssse3

> rgb24_to_y_128_avx2: 39.3
> rgb24_to_y_1080_c: 2451.3
> rgb24_to_y_1080_sse2: 696.3
> rgb24_to_y_1080_ssse3: 516.8
> rgb24_to_y_1080_avx: 518.8

Worse than ssse3

> rgb24_to_y_1080_avx2: 301.8
> rgb24_to_y_1280_c: 2892.8
> rgb24_to_y_1280_sse2: 816.8
> rgb24_to_y_1280_ssse3: 623.3
> rgb24_to_y_1280_avx: 616.3

Not really better than ssse3

> rgb24_to_y_1280_avx2: 350.8
> rgb24_to_y_1920_c: 4338.8
> rgb24_to_y_1920_sse2: 1210.8
> rgb24_to_y_1920_ssse3: 928.3
> rgb24_to_y_1920_avx: 920.3

Not really better than ssse3

> rgb24_to_y_1920_avx2: 534.8
> 
> Signed-off-by: James Almer 
> ---
>  libswscale/x86/input.asm | 49 
>  libswscale/x86/swscale.c |  7 ++
>  2 files changed, 51 insertions(+), 5 deletions(-)
> 
> diff --git a/libswscale/x86/input.asm b/libswscale/x86/input.asm
> index a197183f1f..e79fe11405 100644
> --- a/libswscale/x86/input.asm
> +++ b/libswscale/x86/input.asm
> @@ -23,7 +23,7 @@
>  
>  %include "libavutil/x86/x86util.asm"
>  
> -SECTION_RODATA
> +SECTION_RODATA 32
>  
>  %define RY 0x20DE
>  %define GY 0x4087
> @@ -90,8 +90,12 @@ rgb_UVrnd:   times 4 dd 0x400100   ; 128.5 << 15
>  ; rgba_Vcoeff_ag:  times 4 dw 0,  GV
>  
>  shuf_rgb_12x4:   db 0, 0x80, 1, 0x80,  2, 0x80,  3, 0x80, \
> +6, 0x80, 7, 0x80,  8, 0x80,  9, 0x80, \
> +0, 0x80, 1, 0x80,  2, 0x80,  3, 0x80, \
>  6, 0x80, 7, 0x80,  8, 0x80,  9, 0x80
>  shuf_rgb_3x56:   db 2, 0x80, 3, 0x80,  4, 0x80,  5, 0x80, \
> +8, 0x80, 9, 0x80, 10, 0x80, 11, 0x80, \
> +2, 0x80, 3, 0x80,  4, 0x80,  5, 0x80, \
>  8, 0x80, 9, 0x80, 10, 0x80, 11, 0x80
>  pd_65535f: times 8 dd 65535.0
>  pb_pack_shuffle16le:db  0,  1,  4,  5, \
> @@ -134,8 +138,13 @@ SECTION .text
>  %macro RGB24_TO_Y_FN 2-3
>  cglobal %2 %+ 24ToY, 6, 6, %1, dst, src, u1, u2, w, table
>  %if ARCH_X86_64
> +%if mmsize == 32
> +vbroadcasti128 m8, [%2_Ycoeff_12x4]
> +vbroadcasti128 m9, [%2_Ycoeff_3x56]
> +%else
>  mova   m8, [%2_Ycoeff_12x4]
>  mova   m9, [%2_Ycoeff_3x56]
> +%endif
>  %define coeff1 m8
>  %define coeff2 m9
>  %else ; x86-32
> @@ -165,11 +174,19 @@ cglobal %2 %+ 24ToY, 6, 6, %1, dst, src, u1, u2, w, 
> table
>  %if notcpuflag(ssse3)
>  pxor   m7, m7
>  %endif ; !cpuflag(ssse3)
> +%if mmsize == 32
> +vbroadcasti128 m4, [rgb_Yrnd]
> +%else
>  mova   m4, [rgb_Yrnd]
> +%endif
>  .loop:
>  %if cpuflag(ssse3)
> -movu   m0, [srcq+0]   ; (byte) { Bx, Gx, Rx }[0-3]
> -movu   m2, [srcq+12]  ; (byte) { Bx, Gx, Rx }[4-7]
> +movu  xm0, [srcq+0]   ; (byte) { Bx, Gx, Rx }[0-3]
> +movu  xm2, [srcq+12]  ; (byte) { Bx, Gx, Rx }[4-7]
> +%if mmsize == 32
> +vinserti128m0, m0, [srcq+24], 1
> +vinserti128m2, m2, [srcq+36], 1
> +%endif
>  pshufb m1, m0, shuf_rgb2  ; (word) { R0, B1, G1, R1, R2, B3, 
> G3, R3 }
>  pshufb m0, shuf_rgb1  ; (word) { B0, G0, R0, B1, B2, G2, 
> R2, B3 }
>  pshufb m3, m2, shuf_rgb2  ; (word) { R4, B5, G5, R5, R6, B7, 
> G7, R7 }
> @@ -216,10 +233,17 @@ cglobal %2 %+ 24ToY, 6, 6, %1, dst, src, u1, u2, w, 
> table
>  %macro RGB24_TO_UV_FN 2-3
>  cglobal %2 %+ 24ToUV, 7, 7, %1, dstU, dstV, u1, src, u2, w, table
>  %if ARCH_X86_64
> +%if mmsize == 32
> +vbroadcasti128  m8, [%2_Ucoeff_12x4]
> +vbroadcasti128  m9, [%2_Ucoeff_3x56]
> +vbroadcasti128 m10, [%2_Vcoeff_12x4]
> +vbroadcasti128 m11, [%2_Vcoeff_3x56]
> +%else
>  mova   m8, [%2_Ucoeff_12x4]
>  mova   m9, [%2_Ucoeff_3x56]
>  mova  m10, [%2_Vcoeff_12x4]
>  mova  m11, [%2_Vcoeff_3x56]
> +%endif
>  %def

Re: [FFmpeg-devel] [PATCH] swscale/x86/input: add AVX2 optimized RGB24 to YUV functions

[James Almer]

On 6/4/2024 4:25 PM, Andreas Rheinhardt wrote:

James Almer:

rgb24_to_uv_8_c: 39.3
rgb24_to_uv_8_sse2: 14.3
rgb24_to_uv_8_ssse3: 13.3
rgb24_to_uv_8_avx: 12.8
rgb24_to_uv_8_avx2: 14.3


Worse than avx and ssse3


Can't be disabled for small sizes.




rgb24_to_uv_128_c: 582.8
rgb24_to_uv_128_sse2: 127.3
rgb24_to_uv_128_ssse3: 107.3
rgb24_to_uv_128_avx: 111.3


Worse than ssse3


I know, but it's not related to this patch.
Same for all the comments below.
___
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] swscale/x86/input: add AVX2 optimized RGB24 to YUV functions

[Andreas Rheinhardt]

James Almer:
> On 6/4/2024 4:25 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> rgb24_to_uv_8_c: 39.3
>>> rgb24_to_uv_8_sse2: 14.3
>>> rgb24_to_uv_8_ssse3: 13.3
>>> rgb24_to_uv_8_avx: 12.8
>>> rgb24_to_uv_8_avx2: 14.3
>>
>> Worse than avx and ssse3
> 
> Can't be disabled for small sizes.
> 

Why can't this be disabled?

>>
>>> rgb24_to_uv_128_c: 582.8
>>> rgb24_to_uv_128_sse2: 127.3
>>> rgb24_to_uv_128_ssse3: 107.3
>>> rgb24_to_uv_128_avx: 111.3
>>
>> Worse than ssse3
> 
> I know, but it's not related to this patch.
> Same for all the comments below.

___
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] swscale/x86/input: add AVX2 optimized RGB24 to YUV functions

[James Almer]

On 6/4/2024 4:32 PM, Andreas Rheinhardt wrote:

James Almer:

On 6/4/2024 4:25 PM, Andreas Rheinhardt wrote:

James Almer:

rgb24_to_uv_8_c: 39.3
rgb24_to_uv_8_sse2: 14.3
rgb24_to_uv_8_ssse3: 13.3
rgb24_to_uv_8_avx: 12.8
rgb24_to_uv_8_avx2: 14.3


Worse than avx and ssse3


Can't be disabled for small sizes.



Why can't this be disabled?


The function pointer is for all sizes. And adding a check + jmp in the 
assembly is not going to be better. Also, this being for 8 pixel wide 
buffers, it's not going to be anyone's bottleneck.







rgb24_to_uv_128_c: 582.8
rgb24_to_uv_128_sse2: 127.3
rgb24_to_uv_128_ssse3: 107.3
rgb24_to_uv_128_avx: 111.3


Worse than ssse3


I know, but it's not related to this patch.
Same for all the comments below.


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

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

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

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

[FFmpeg-devel] [PATCH 1/1] sws/input: add R-V V rgb24ToY

[Rémi Denis-Courmont]

T-Head C908:
rgb24_to_y_8_c:2.0
rgb24_to_y_8_rvv_i32:  3.0
rgb24_to_y_128_c: 26.2
rgb24_to_y_128_rvv_i32:   10.5
rgb24_to_y_1080_c:   235.7
rgb24_to_y_1080_rvv_i32: 102.0
rgb24_to_y_1280_c:   260.0
rgb24_to_y_1280_rvv_i32: 100.2
rgb24_to_y_1920_c:   405.7
rgb24_to_y_1920_rvv_i32: 166.7

SpacemiT X60:
rgb24_to_y_8_c:1.7
rgb24_to_y_8_rvv_i32:  2.5
rgb24_to_y_128_c: 23.2
rgb24_to_y_128_rvv_i32:5.0
rgb24_to_y_1080_c:   195.0
rgb24_to_y_1080_rvv_i32:  38.0
rgb24_to_y_1280_c:   231.0
rgb24_to_y_1280_rvv_i32:  45.0
rgb24_to_y_1920_c:   346.2
rgb24_to_y_1920_rvv_i32:  67.2
---
 libswscale/riscv/Makefile |  6 +++--
 libswscale/riscv/input.S  | 51 +++
 libswscale/riscv/swscale.c| 40 +++
 libswscale/swscale.c  |  2 ++
 libswscale/swscale_internal.h |  1 +
 5 files changed, 98 insertions(+), 2 deletions(-)
 create mode 100644 libswscale/riscv/input.S
 create mode 100644 libswscale/riscv/swscale.c

diff --git a/libswscale/riscv/Makefile b/libswscale/riscv/Makefile
index 48afaf62aa..d1b0eae367 100644
--- a/libswscale/riscv/Makefile
+++ b/libswscale/riscv/Makefile
@@ -1,3 +1,5 @@
-OBJS += riscv/rgb2rgb.o
+OBJS += riscv/rgb2rgb.o \
+riscv/swscale.o
 RV-OBJS += riscv/rgb2rgb_rvb.o
-RVV-OBJS += riscv/rgb2rgb_rvv.o
+RVV-OBJS += riscv/input.o \
+riscv/rgb2rgb_rvv.o
diff --git a/libswscale/riscv/input.S b/libswscale/riscv/input.S
new file mode 100644
index 00..c2dca8fe29
--- /dev/null
+++ b/libswscale/riscv/input.S
@@ -0,0 +1,51 @@
+/*
+ * Copyright © 2024 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/riscv/asm.S"
+
+func ff_rgb24ToY_rvv, zve32x
+csrwi   vxrm, 0
+lw  t1, 0(a5) # RY
+lw  t2, 4(a5) # GY
+lw  t3, 8(a5) # BY
+li  t4, 32 << (15 - 1)
+1:
+vsetvlit0, a4, e32, m8, ta, ma
+vlseg3e8.v v0, (a1)
+suba4, a4, t0
+vzext.vf4  v8, v0
+sh1add t5, t0, t0 # t1 = 3 * t0
+vzext.vf4  v16, v2
+vzext.vf4  v24, v4
+adda1, t5, a1
+vmul.vxv8, v8, t1
+vmul.vxv16, v16, t2
+vmul.vxv24, v24, t3
+vadd.vvv8, v8, v16
+vadd.vxv24, v24, t4
+vadd.vvv8, v8, v24
+vsetvlizero, zero, e16, m4, ta, ma
+vnclipu.wi v0, v8, 15 - 6
+vse16.vv0, (a0)
+sh1add a0, t0, a0
+bnez   a4, 1b
+
+ret
+endfunc
diff --git a/libswscale/riscv/swscale.c b/libswscale/riscv/swscale.c
new file mode 100644
index 00..71f01a8a5a
--- /dev/null
+++ b/libswscale/riscv/swscale.c
@@ -0,0 +1,40 @@
+/*
+ * 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.h"
+#include "libavutil/attributes.h"
+#include "libavutil/riscv/cpu.h"
+#include "libswscale/swscale_internal.h"
+
+void ff_rgb24ToY_rvv(uint8_t *dst, const uint8_t *src, const uint8_t *,
+ const uint8_t *, int width, uint32_t *coeffs, void *);
+
+av_cold void ff_sws_init_swscale_riscv(SwsContext *c)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+switch (c->srcFormat) {
+case AV_PIX_FMT_RGB24:
+c->lumToYV12 = ff_rgb24ToY_rvv;
+break;
+}
+}
+#endif
+}
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 279542

[FFmpeg-devel] [PATCHv2 1/1] sws/input: add R-V V rgb24ToY

[Rémi Denis-Courmont]

T-Head C908:
rgb24_to_y_8_c:2.0
rgb24_to_y_8_rvv_i32:  2.7
rgb24_to_y_128_c: 26.2
rgb24_to_y_128_rvv_i32:9.2
rgb24_to_y_1080_c:   219.5
rgb24_to_y_1080_rvv_i32:  76.2
rgb24_to_y_1280_c:   276.2
rgb24_to_y_1280_rvv_i32:  89.7
rgb24_to_y_1920_c:   389.7
rgb24_to_y_1920_rvv_i32: 134.2

SpacemiT X60:
rgb24_to_y_8_c:1.7
rgb24_to_y_8_rvv_i32:  2.2
rgb24_to_y_128_c: 23.2
rgb24_to_y_128_rvv_i32:4.2
rgb24_to_y_1080_c:   195.0
rgb24_to_y_1080_rvv_i32:  34.0
rgb24_to_y_1280_c:   231.0
rgb24_to_y_1280_rvv_i32:  40.0
rgb24_to_y_1920_c:   346.2
rgb24_to_y_1920_rvv_i32:  60.0

---
Changes since version 1:
- Use fused multiply-adds.

---
 libswscale/riscv/Makefile |  6 +++--
 libswscale/riscv/input.S  | 49 +++
 libswscale/riscv/swscale.c| 40 
 libswscale/swscale.c  |  2 ++
 libswscale/swscale_internal.h |  1 +
 5 files changed, 96 insertions(+), 2 deletions(-)
 create mode 100644 libswscale/riscv/input.S
 create mode 100644 libswscale/riscv/swscale.c

diff --git a/libswscale/riscv/Makefile b/libswscale/riscv/Makefile
index 48afaf62aa..d1b0eae367 100644
--- a/libswscale/riscv/Makefile
+++ b/libswscale/riscv/Makefile
@@ -1,3 +1,5 @@
-OBJS += riscv/rgb2rgb.o
+OBJS += riscv/rgb2rgb.o \
+riscv/swscale.o
 RV-OBJS += riscv/rgb2rgb_rvb.o
-RVV-OBJS += riscv/rgb2rgb_rvv.o
+RVV-OBJS += riscv/input.o \
+riscv/rgb2rgb_rvv.o
diff --git a/libswscale/riscv/input.S b/libswscale/riscv/input.S
new file mode 100644
index 00..0355cfe4ab
--- /dev/null
+++ b/libswscale/riscv/input.S
@@ -0,0 +1,49 @@
+/*
+ * Copyright © 2024 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/riscv/asm.S"
+
+func ff_rgb24ToY_rvv, zve32x
+csrwi   vxrm, 0
+lw  t1, 0(a5) # RY
+lw  t2, 4(a5) # GY
+lw  t3, 8(a5) # BY
+li  t4, 32 << (15 - 1)
+1:
+vsetvlit0, a4, e32, m8, ta, ma
+vlseg3e8.v v0, (a1)
+suba4, a4, t0
+vzext.vf4  v8, v0
+sh1add t5, t0, t0 # t1 = 3 * t0
+vzext.vf4  v16, v2
+vzext.vf4  v24, v4
+adda1, t5, a1
+vmul.vxv8, v8, t1
+vmacc.vx   v8, t2, v16
+vmacc.vx   v8, t3, v24
+vadd.vxv8, v8, t4
+vsetvlizero, zero, e16, m4, ta, ma
+vnclipu.wi v0, v8, 15 - 6
+vse16.vv0, (a0)
+sh1add a0, t0, a0
+bnez   a4, 1b
+
+ret
+endfunc
diff --git a/libswscale/riscv/swscale.c b/libswscale/riscv/swscale.c
new file mode 100644
index 00..71f01a8a5a
--- /dev/null
+++ b/libswscale/riscv/swscale.c
@@ -0,0 +1,40 @@
+/*
+ * 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.h"
+#include "libavutil/attributes.h"
+#include "libavutil/riscv/cpu.h"
+#include "libswscale/swscale_internal.h"
+
+void ff_rgb24ToY_rvv(uint8_t *dst, const uint8_t *src, const uint8_t *,
+ const uint8_t *, int width, uint32_t *coeffs, void *);
+
+av_cold void ff_sws_init_swscale_riscv(SwsContext *c)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+switch (c->srcFormat) {
+case AV_PIX_FMT_RGB24:
+c->lumToYV12 = ff_rgb24ToY_rvv;
+break;
+}
+}
+#endif
+}
diff --git a/libswscale/swscale.c b/libswscale/swscale.c
index 2795429b6c..973

Re: [FFmpeg-devel] [PATCH 5/5] avutil/aarch64: Fallback to clock_gettime as timer on Android

[Martin Storsjö]

On Tue, 4 Jun 2024, Zhao Zhili wrote:


From: Zhao Zhili 

The inline asm doesn't work on Android.


Using pmccntr_el0 doen't work, no, but instead of falling back to 
clock_gettime, you may want to use cntvct_el0 instead of pmccntr_el0. IIRC 
that works on Android, at least it worked a number of years ago. It has 
less precision than pmccntr_el0, but maybe is better than clock_gettime?


I.e., use similar inline assembly as before, but with cntvct_el0 instead 
of pmccntr_el0.


// 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] [RFC] STF 2025

[Michael Niedermayer]

On Tue, Jun 04, 2024 at 08:24:57PM +0200, Vittorio Giovara wrote:
> On Tue, Jun 4, 2024 at 5:47 PM Cosmin Stejerean via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
> 
> >
> >
> > > On Jun 3, 2024, at 11:53 PM, Vittorio Giovara <
> > vittorio.giov...@gmail.com> wrote:
> > >
> > > On Tue, Jun 4, 2024 at 3:01 AM Cosmin Stejerean via ffmpeg-devel <
> > > ffmpeg-devel@ffmpeg.org> wrote:
> > >
> > >>> Reposting my question/comment here since Thilo hasn't had a chance to
> > >>> respond, but shouldn't these kinds of requests go through the GA? If
> > >>> anybody can do whatever they want with the ffmpeg name, then what's the
> > >>> point of voting and following the established process?
> > >>
> > >> Probably? I'm not actually sure what the process is for getting an
> > FFmpeg
> > >> booth at a conference. Is there a documented process somewhere for how
> > this
> > >> should be done? If not this might be a good opportunity to create one.
> > >>
> > >
> > > Agreed, do you have a draft you could share as a base of discussion? Once
> > > defined, we could have the GA vote on it
> > >
> >
> > If you really want to work on a proposal I'm happy to collaborate with you
> > offline to draft something and then propose it to the GA.
> >
> 
> Sure I'm happy to work on this with you! Let's talk offline about it

Why should discussions about a FFmpeg booth be offline ?

thx

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

No great genius has ever existed without some touch of madness. -- 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] [RFC] STF 2025

[Vittorio Giovara]

On Tue, Jun 4, 2024 at 11:22 PM Michael Niedermayer 
wrote:

> > Sure I'm happy to work on this with you! Let's talk offline about it
>
> Why should discussions about a FFmpeg booth be offline ?
>

That's a great question, CC-ing Thilo about it.
-- 
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".

[FFmpeg-devel] New CC member: Steven Liu

[Ronald S. Bultje]

Hi all,

Anton resigned from the CC [1], leaving an empty spot. The remaining
members of the CC agreed it would be best to fill the spot with the next
runner-up from the last CC Elections. The last CC election results [2] had
Steven Liu as next runner-up, so we've asked him to fill Anton's spot for
the remainder of our term, and he accepted. Thanks & welcome, Steven!

Ronald

[1] https://ffmpeg.org//pipermail/ffmpeg-devel/2024-April/325638.html
[2]
https://vote.ffmpeg.org/cgi-bin/civs/results.pl?num_winners=6&id=E_332f7f39709b8211&algorithm=cschulze
___
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 2/2] lavc/dxvenc: migrate DXT1 encoder to lavu hashtable

[Michael Niedermayer]

On Mon, Jun 03, 2024 at 10:39:04PM -0700, Connor Worley wrote:
> Offers a modest performance gain due to the switch from naive linear
> probling to robin hood.
> 
> Signed-off-by: Connor Worley 
> ---
>  libavcodec/dxvenc.c | 119 
>  1 file changed, 32 insertions(+), 87 deletions(-)

this seems to break fate

TESTdxv3enc-dxt1
--- ./tests/ref/fate/dxv3enc-dxt1   2024-06-03 22:55:42.109080592 +0200
+++ tests/data/fate/dxv3enc-dxt12024-06-05 01:45:58.899051887 +0200
@@ -3,4 +3,4 @@
 #codec_id 0: dxv
 #dimensions 0: 1920x1080
 #sar 0: 1/1
-0,  0,  0,1,76521, 0xed387a5e
+0,  0,  0,1,76517, 0xd60c1020
Test dxv3enc-dxt1 failed. Look at tests/data/fate/dxv3enc-dxt1.err for details.
make: *** [tests/Makefile:311: fate-dxv3enc-dxt1] Error 1

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

Never trust a computer, one day, it may think you are the virus. -- Compn


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] avcodec/mpegvideo_enc: give magic number a name

[Michael Niedermayer]

On Tue, Jun 04, 2024 at 03:05:35PM +0200, Ramiro Polla wrote:
> ---
>  libavcodec/mpegvideo_enc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM

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] [PATCH] Add extra const to FF_PFNGLSHADERSOURCEPROC.

[Billy O'Neal (VC AIR) via ffmpeg-devel]

Makes sense. I'm validating that a patch with the #ifdef succeeds and will 
attempt to add it as a reply if that works. I apologize for my misunderstanding 
of the situation, and the horrible Outlook signature. (And in advance if my git 
format-patch use afterwards accidentally makes a new thread rather than 
attaching it to this one)

Thanks again for the feedback and consideration,

Billy O'Neal
Visual C++ - vcpkg

I believed that

void f(GLuint shader, GLsizei count, const char**string, const GLint *length);

was compatible with

void f(GLuint shader, GLsizei count, const char* const*string, const GLint 
*length);

based largely on that assignment succeeding everywhere, but I was mistaken. See 
C11 6.7.6.3 "Function declarators (including prototypes)"/15:

> Moreover, the parameter type lists, if both are present, shall agree in the 
> number of
> parameters and in use of the ellipsis terminator; corresponding parameters 
> shall have
> compatible types.

OK, so this reduces to "is const char** compatible with const char* const *"

6.7.6.1 "Pointer declarators"/2:

>For two pointer types to be compatible, both shall be identically qualified 
>and both shall
>be pointers to compatible types.

Validation build running: https://github.com/microsoft/vcpkg/pull/39132/


From: ffmpeg-devel  on behalf of Andreas 
Rheinhardt 
Sent: Monday, June 3, 2024 3:08 PM
To: ffmpeg-devel@ffmpeg.org 
Subject: Re: [FFmpeg-devel] [PATCH] Add extra const to FF_PFNGLSHADERSOURCEPROC.

Billy O'Neal (VC AIR) via ffmpeg-devel:
> Assigning the non-const version to the const version is valid (at least, 
> builds on other platforms succeeded).
>

It is not valid: "If a converted pointer is used to call a function
whose type is not compatible with the referenced type, the behavior is
undefined." (C11 6.3.2.3 (8))
It will mostly work, because there is no problem from an ABI point of
view. But it is nevertheless undefined behaviour (and recent version's
of Clang's undefined behavior sanitizer actually check for such mismatches).

> Would you still like Apple guards? (I'm hesitating only because most 
> upstreams ask for minimal preprocessor use)
>
> Thanks for the consideration!
>
> 
> From: ffmpeg-devel  on behalf of Andreas 
> Rheinhardt 
> Sent: Friday, May 31, 2024 5:30:49 PM
> To: ffmpeg-devel@ffmpeg.org 
> Subject: Re: [FFmpeg-devel] [PATCH] Add extra const to 
> FF_PFNGLSHADERSOURCEPROC.
>
> [You don't often get email from andreas.rheinha...@outlook.com. Learn why 
> this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Billy O'Neal (VC AIR) via ffmpeg-devel:
>> Resolves the following compiler error on macOS 14.5:
>>
>> ```console
>> /Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/System/Library/Frameworks/OpenGL.framework/Headers/gl3.h:1891:21:
>>  note: 'glShaderSource' has been explicitly marked deprecated here
>> GLAPI void APIENTRY glShaderSource (GLuint shader, GLsizei count, const 
>> GLchar* const *string, const GLint *length) OPENGL_DEPRECATED(10.5, 10.14);
>> ^
>> src/libavdevice/opengl_enc.c:482:27: error: incompatible function pointer 
>> types assigning to 'FF_PFNGLSHADERSOURCEPROC' (aka 'void (*)(unsigned int, 
>> int, const char **, const int *)') from 'void (GLuint, GLsizei, const GLchar 
>> *const *, const GLint *)' (aka 'void (unsigned int, int, const char *const 
>> *, const int *)') [-Wincompatible-function-pointer-types]
>> procs->glShaderSource = glShaderSource;
>>   ^ ~~
>> ```
>>
>> Signed-off-by: Billy Robert O'Neal III 
>> ---
>>  libavdevice/opengl_enc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c
>> index 6f7a30ff9e..691bee22ad 100644
>> --- a/libavdevice/opengl_enc.c
>> +++ b/libavdevice/opengl_enc.c
>> @@ -117,7 +117,7 @@ typedef void   (APIENTRY *FF_PFNGLATTACHSHADERPROC) 
>> (GLuint program, GLuint shad
>>  typedef GLuint (APIENTRY *FF_PFNGLCREATESHADERPROC) (GLenum type);
>>  typedef void   (APIENTRY *FF_PFNGLDELETESHADERPROC) (GLuint shader);
>>  typedef void   (APIENTRY *FF_PFNGLCOMPILESHADERPROC) (GLuint shader);
>> -typedef void   (APIENTRY *FF_PFNGLSHADERSOURCEPROC) (GLuint shader, GLsizei 
>> count, const char* *string, const GLint *length);
>> +typedef void   (APIENTRY *FF_PFNGLSHADERSOURCEPROC) (GLuint shader, GLsizei 
>> count, const char* const *string, const GLint *length);
>>  typedef void   (APIENTRY *FF_PFNGLGETSHADERIVPROC) (GLuint shader, GLenum 
>> pname, GLint *params);
>>  typedef void   (APIENTRY *FF_PFNGLGETSHADERINFOLOGPROC) (GLuint shader, 
>> GLsizei bufSize, GLsizei *length, char *infoLog);
>>
>
> It seems that the extra const is apple-only, so this patch should be
> restricted to it.
>

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

To unsub

[FFmpeg-devel] [PATCH 4/4] lavc: bump minor and add APIchanges entry for new USAC profile

[Lynne via ffmpeg-devel]

---
 doc/APIchanges   | 3 +++
 libavcodec/version.h | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index e36a01336c..d9bec790a3 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
 
 API changes, most recent first:
 
+2024-06-05 - xx - lavc 61.7.100 - avcodec.h, defs.h
+  Add FF_PROFILE_AAC_USAC and AV_PROFILE_AAC_USAC.
+
 2024-06-02 - xx - lavu 59.21.100 - channel_layout.h
   Add AV_CHAN_SIDE_SURROUND_RIGHT and AV_CH_SIDE_SURROUND_LEFT.
   Add AV_CHAN_SIDE_SURROUND_RIGHT and AV_CH_SIDE_SURROUND_RIGHT.
diff --git a/libavcodec/version.h b/libavcodec/version.h
index da54f87887..7acb261bb3 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #include "version_major.h"
 
-#define LIBAVCODEC_VERSION_MINOR   6
+#define LIBAVCODEC_VERSION_MINOR   7
 #define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
-- 
2.43.0.381.gb435a96ce8
___
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/4] mpeg4audio: rename AOT_USAC_NOSBR to AOT_USAC

[Lynne via ffmpeg-devel]

The issue is that AOT 45 isn't defined anywhere, and looking at the git
blame, it seems to have sprung up through a reordering of the enum,
and adding a hole.

The spec does not define an explicit AOT for SBR and no SBR, and only
uses AOT 42 (previously AOT_USAC_NOSBR), so just rename AOT_USAC to
it and replace its use everywhere.
---
 libavcodec/aac/aacdec.c | 7 ++-
 libavcodec/mpeg4audio.h | 3 +--
 2 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/libavcodec/aac/aacdec.c b/libavcodec/aac/aacdec.c
index 2b8322fc68..24d2bdde4c 100644
--- a/libavcodec/aac/aacdec.c
+++ b/libavcodec/aac/aacdec.c
@@ -1046,7 +1046,6 @@ static int decode_audio_specific_config_gb(AACDecContext 
*ac,
 return ret;
 break;
 #if CONFIG_AAC_DECODER
-case AOT_USAC_NOSBR: /* fallthrough */
 case AOT_USAC:
 if ((ret = ff_aac_usac_config_decode(ac, avctx, gb,
  oc, m4ac->chan_config)) < 0)
@@ -1571,8 +1570,7 @@ int ff_aac_decode_tns(AACDecContext *ac, 
TemporalNoiseShaping *tns,
   GetBitContext *gb, const IndividualChannelStream *ics)
 {
 int tns_max_order = INT32_MAX;
-const int is_usac = ac->oc[1].m4ac.object_type == AOT_USAC ||
-ac->oc[1].m4ac.object_type == AOT_USAC_NOSBR;
+const int is_usac = ac->oc[1].m4ac.object_type == AOT_USAC;
 int w, filt, i, coef_len, coef_res, coef_compress;
 const int is8 = ics->window_sequence[0] == EIGHT_SHORT_SEQUENCE;
 
@@ -2421,8 +2419,7 @@ static int aac_decode_frame_int(AVCodecContext *avctx, 
AVFrame *frame,
 
 ac->tags_mapped = 0;
 
-if ((ac->oc[1].m4ac.object_type == AOT_USAC) ||
-(ac->oc[1].m4ac.object_type == AOT_USAC_NOSBR)) {
+if (ac->oc[1].m4ac.object_type == AOT_USAC) {
 if (ac->is_fixed) {
 avpriv_report_missing_feature(ac->avctx,
   "AAC USAC fixed-point decoding");
diff --git a/libavcodec/mpeg4audio.h b/libavcodec/mpeg4audio.h
index 56615ef321..5daba7824b 100644
--- a/libavcodec/mpeg4audio.h
+++ b/libavcodec/mpeg4audio.h
@@ -108,10 +108,9 @@ enum AudioObjectType {
 AOT_ER_AAC_ELD,///< N   Error Resilient 
Enhanced Low Delay
 AOT_SMR_SIMPLE,///< N   Symbolic Music 
Representation Simple
 AOT_SMR_MAIN,  ///< N   Symbolic Music 
Representation Main
-AOT_USAC_NOSBR,///< N   Unified Speech and 
Audio Coding (no SBR)
+AOT_USAC,  ///< Y   Unified Speech and 
Audio Coding
 AOT_SAOC,  ///< N   Spatial Audio 
Object Coding
 AOT_LD_SURROUND,   ///< N   Low Delay MPEG 
Surround
-AOT_USAC,  ///< N   Unified Speech and 
Audio Coding
 };
 
 #define MAX_PCE_SIZE 320 ///https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 3/4] aac: define a new profile for USAC

[Lynne via ffmpeg-devel]

This allows users to determine whether a stream is USAC or not.
---
 libavcodec/aac/aacdec_usac.c | 4 
 libavcodec/avcodec.h | 1 +
 libavcodec/defs.h| 1 +
 libavcodec/profiles.c| 1 +
 libavcodec/profiles.h| 1 +
 5 files changed, 8 insertions(+)

diff --git a/libavcodec/aac/aacdec_usac.c b/libavcodec/aac/aacdec_usac.c
index 7b36b49d63..5c3bb8d4ac 100644
--- a/libavcodec/aac/aacdec_usac.c
+++ b/libavcodec/aac/aacdec_usac.c
@@ -494,6 +494,8 @@ int ff_aac_usac_config_decode(AACDecContext *ac, 
AVCodecContext *avctx,
 }
 }
 
+ac->avctx->profile = AV_PROFILE_AAC_USAC;
+
 ret = ff_aac_usac_reset_state(ac, oc);
 if (ret < 0)
 return ret;
@@ -1533,6 +1535,8 @@ int ff_aac_usac_decode_frame(AVCodecContext *avctx, 
AACDecContext *ac,
 ff_aac_output_configure(ac, ac->oc[1].layout_map, 
ac->oc[1].layout_map_tags,
 ac->oc[1].status, 0);
 
+ac->avctx->profile = AV_PROFILE_AAC_USAC;
+
 indep_flag = get_bits1(gb);
 
 nb_ch_el = 0;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 2da63c87ea..257e04fe2d 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1652,6 +1652,7 @@ typedef struct AVCodecContext {
 #define FF_PROFILE_AAC_HE_V2 28
 #define FF_PROFILE_AAC_LD   22
 #define FF_PROFILE_AAC_ELD  38
+#define FF_PROFILE_AAC_USAC 41
 #define FF_PROFILE_MPEG2_AAC_LOW 128
 #define FF_PROFILE_MPEG2_AAC_HE  131
 
diff --git a/libavcodec/defs.h b/libavcodec/defs.h
index 00d840ec19..7ddfdcad0b 100644
--- a/libavcodec/defs.h
+++ b/libavcodec/defs.h
@@ -73,6 +73,7 @@
 #define AV_PROFILE_AAC_HE_V2   28
 #define AV_PROFILE_AAC_LD  22
 #define AV_PROFILE_AAC_ELD 38
+#define AV_PROFILE_AAC_USAC41
 #define AV_PROFILE_MPEG2_AAC_LOW  128
 #define AV_PROFILE_MPEG2_AAC_HE   131
 
diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
index 052b77926e..44bdf6f85b 100644
--- a/libavcodec/profiles.c
+++ b/libavcodec/profiles.c
@@ -33,6 +33,7 @@ const AVProfile ff_aac_profiles[] = {
 { AV_PROFILE_AAC_MAIN,  "Main" },
 { AV_PROFILE_AAC_SSR,   "SSR"  },
 { AV_PROFILE_AAC_LTP,   "LTP"  },
+{ AV_PROFILE_AAC_USAC,  "xHE-AAC" },
 { AV_PROFILE_UNKNOWN },
 };
 
diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
index 842201718b..33b7ffc17a 100644
--- a/libavcodec/profiles.h
+++ b/libavcodec/profiles.h
@@ -35,6 +35,7 @@
 FF_AVCTX_PROFILE_OPTION("aac_he_v2", NULL, AUDIO, 
AV_PROFILE_AAC_HE_V2)\
 FF_AVCTX_PROFILE_OPTION("aac_ld",NULL, AUDIO, AV_PROFILE_AAC_LD)\
 FF_AVCTX_PROFILE_OPTION("aac_eld",   NULL, AUDIO, AV_PROFILE_AAC_ELD)\
+FF_AVCTX_PROFILE_OPTION("aac_xhe",   NULL, AUDIO, AV_PROFILE_AAC_USAC)\
 FF_AVCTX_PROFILE_OPTION("mpeg2_aac_low", NULL, AUDIO, 
AV_PROFILE_MPEG2_AAC_LOW)\
 FF_AVCTX_PROFILE_OPTION("mpeg2_aac_he",  NULL, AUDIO, 
AV_PROFILE_MPEG2_AAC_HE)\
 
-- 
2.43.0.381.gb435a96ce8
___
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/4] mpeg4audio: explicitly define each AOT

[Lynne via ffmpeg-devel]

This makes it far easier to figure out which AOT belongs to which
profile.
Also, explicitly highlight the holes.
---
 libavcodec/mpeg4audio.h | 82 +
 1 file changed, 42 insertions(+), 40 deletions(-)

diff --git a/libavcodec/mpeg4audio.h b/libavcodec/mpeg4audio.h
index 5daba7824b..0819e48a42 100644
--- a/libavcodec/mpeg4audio.h
+++ b/libavcodec/mpeg4audio.h
@@ -68,49 +68,51 @@ int avpriv_mpeg4audio_get_config2(MPEG4AudioConfig *c, 
const uint8_t *buf,
   int size, int sync_extension, void *logctx);
 
 enum AudioObjectType {
-AOT_NULL,
+AOT_NULL = 0,
// Support?Name
-AOT_AAC_MAIN,  ///< Y   Main
-AOT_AAC_LC,///< Y   Low Complexity
-AOT_AAC_SSR,   ///< N (code in SoC repo)Scalable Sample 
Rate
-AOT_AAC_LTP,   ///< Y   Long Term 
Prediction
-AOT_SBR,   ///< Y   Spectral Band 
Replication
-AOT_AAC_SCALABLE,  ///< N   Scalable
-AOT_TWINVQ,///< N   Twin Vector 
Quantizer
-AOT_CELP,  ///< N   Code Excited 
Linear Prediction
-AOT_HVXC,  ///< N   Harmonic Vector 
eXcitation Coding
+AOT_AAC_MAIN =  1, ///< Y   Main
+AOT_AAC_LC   =  2, ///< Y   Low Complexity
+AOT_AAC_SSR  =  3, ///< N (code in SoC repo)Scalable Sample 
Rate
+AOT_AAC_LTP  =  4, ///< Y   Long Term 
Prediction
+AOT_SBR  =  5, ///< Y   Spectral Band 
Replication
+AOT_AAC_SCALABLE =  6, ///< N   Scalable
+AOT_TWINVQ   =  7, ///< N   Twin Vector 
Quantizer
+AOT_CELP =  8, ///< N   Code Excited 
Linear Prediction
+AOT_HVXC =  9, ///< N   Harmonic Vector 
eXcitation Coding
+
 AOT_TTSI = 12, ///< N   Text-To-Speech 
Interface
-AOT_MAINSYNTH, ///< N   Main Synthesis
-AOT_WAVESYNTH, ///< N   Wavetable Synthesis
-AOT_MIDI,  ///< N   General MIDI
-AOT_SAFX,  ///< N   Algorithmic 
Synthesis and Audio Effects
-AOT_ER_AAC_LC, ///< N   Error Resilient 
Low Complexity
+AOT_MAINSYNTH= 13, ///< N   Main Synthesis
+AOT_WAVESYNTH= 14, ///< N   Wavetable Synthesis
+AOT_MIDI = 15, ///< N   General MIDI
+AOT_SAFX = 16, ///< N   Algorithmic 
Synthesis and Audio Effects
+AOT_ER_AAC_LC= 17, ///< N   Error Resilient 
Low Complexity
+
 AOT_ER_AAC_LTP   = 19, ///< N   Error Resilient 
Long Term Prediction
-AOT_ER_AAC_SCALABLE,   ///< N   Error Resilient 
Scalable
-AOT_ER_TWINVQ, ///< N   Error Resilient 
Twin Vector Quantizer
-AOT_ER_BSAC,   ///< N   Error Resilient 
Bit-Sliced Arithmetic Coding
-AOT_ER_AAC_LD, ///< N   Error Resilient 
Low Delay
-AOT_ER_CELP,   ///< N   Error Resilient 
Code Excited Linear Prediction
-AOT_ER_HVXC,   ///< N   Error Resilient 
Harmonic Vector eXcitation Coding
-AOT_ER_HILN,   ///< N   Error Resilient 
Harmonic and Individual Lines plus Noise
-AOT_ER_PARAM,  ///< N   Error Resilient 
Parametric
-AOT_SSC,   ///< N   SinuSoidal Coding
-AOT_PS,///< N   Parametric Stereo
-AOT_SURROUND,  ///< N   MPEG Surround
-AOT_ESCAPE,///< Y   Escape Value
-AOT_L1,///< Y   Layer 1
-AOT_L2,///< Y   Layer 2
-AOT_L3,///< Y   Layer 3
-AOT_DST,   ///< N   Direct Stream 
Transfer
-AOT_ALS,   ///< Y   Audio LosslesS
-AOT_SLS,   ///< N   Scalable LosslesS
-AOT_SLS_NON_CORE,  ///< N   Scalable LosslesS 
(non core)
-AOT_ER_AAC_ELD,///< N   Error Resilient 
Enhanced Low Delay
-AOT_SMR_SIMPLE,  

Re: [FFmpeg-devel] [PATCH] Add extra const to FF_PFNGLSHADERSOURCEPROC.

[Billy O'Neal (VC AIR) via ffmpeg-devel]

Resolves the following compiler error on macOS 14.5:

```console
/Library/Developer/CommandLineTools/SDKs/MacOSX14.4.sdk/System/Library/Frameworks/OpenGL.framework/Headers/gl3.h:1891:21:
 note: 'glShaderSource' has been explicitly marked deprecated here
GLAPI void APIENTRY glShaderSource (GLuint shader, GLsizei count, const GLchar* 
const *string, const GLint *length) OPENGL_DEPRECATED(10.5, 10.14);
^
src/libavdevice/opengl_enc.c:482:27: error: incompatible function pointer types 
assigning to 'FF_PFNGLSHADERSOURCEPROC' (aka 'void (*)(unsigned int, int, const 
char **, const int *)') from 'void (GLuint, GLsizei, const GLchar *const *, 
const GLint *)' (aka 'void (unsigned int, int, const char *const *, const int 
*)') [-Wincompatible-function-pointer-types]
procs->glShaderSource = glShaderSource;
  ^ ~~
```

Signed-off-by: Billy Robert O'Neal III 
---
 libavdevice/opengl_enc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c
index 6f7a30ff9e..7805b641d1 100644
--- a/libavdevice/opengl_enc.c
+++ b/libavdevice/opengl_enc.c
@@ -117,7 +117,11 @@ typedef void   (APIENTRY *FF_PFNGLATTACHSHADERPROC) 
(GLuint program, GLuint shad
 typedef GLuint (APIENTRY *FF_PFNGLCREATESHADERPROC) (GLenum type);
 typedef void   (APIENTRY *FF_PFNGLDELETESHADERPROC) (GLuint shader);
 typedef void   (APIENTRY *FF_PFNGLCOMPILESHADERPROC) (GLuint shader);
+#if defined(__APPLE__)
+typedef void   (APIENTRY *FF_PFNGLSHADERSOURCEPROC) (GLuint shader, GLsizei 
count, const char* const *string, const GLint *length);
+#else
 typedef void   (APIENTRY *FF_PFNGLSHADERSOURCEPROC) (GLuint shader, GLsizei 
count, const char* *string, const GLint *length);
+#endif
 typedef void   (APIENTRY *FF_PFNGLGETSHADERIVPROC) (GLuint shader, GLenum 
pname, GLint *params);
 typedef void   (APIENTRY *FF_PFNGLGETSHADERINFOLOGPROC) (GLuint shader, 
GLsizei bufSize, GLsizei *length, char *infoLog);
 
-- 
2.45.2.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 3/4] aac: define a new profile for USAC

[Andreas Rheinhardt]

Lynne via ffmpeg-devel:
> This allows users to determine whether a stream is USAC or not.
> ---
>  libavcodec/aac/aacdec_usac.c | 4 
>  libavcodec/avcodec.h | 1 +
>  libavcodec/defs.h| 1 +
>  libavcodec/profiles.c| 1 +
>  libavcodec/profiles.h| 1 +
>  5 files changed, 8 insertions(+)
> 
> diff --git a/libavcodec/aac/aacdec_usac.c b/libavcodec/aac/aacdec_usac.c
> index 7b36b49d63..5c3bb8d4ac 100644
> --- a/libavcodec/aac/aacdec_usac.c
> +++ b/libavcodec/aac/aacdec_usac.c
> @@ -494,6 +494,8 @@ int ff_aac_usac_config_decode(AACDecContext *ac, 
> AVCodecContext *avctx,
>  }
>  }
>  
> +ac->avctx->profile = AV_PROFILE_AAC_USAC;
> +
>  ret = ff_aac_usac_reset_state(ac, oc);
>  if (ret < 0)
>  return ret;
> @@ -1533,6 +1535,8 @@ int ff_aac_usac_decode_frame(AVCodecContext *avctx, 
> AACDecContext *ac,
>  ff_aac_output_configure(ac, ac->oc[1].layout_map, 
> ac->oc[1].layout_map_tags,
>  ac->oc[1].status, 0);
>  
> +ac->avctx->profile = AV_PROFILE_AAC_USAC;
> +
>  indep_flag = get_bits1(gb);
>  
>  nb_ch_el = 0;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 2da63c87ea..257e04fe2d 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1652,6 +1652,7 @@ typedef struct AVCodecContext {
>  #define FF_PROFILE_AAC_HE_V2 28
>  #define FF_PROFILE_AAC_LD   22
>  #define FF_PROFILE_AAC_ELD  38
> +#define FF_PROFILE_AAC_USAC 41

Don't add new deprecated defines.

>  #define FF_PROFILE_MPEG2_AAC_LOW 128
>  #define FF_PROFILE_MPEG2_AAC_HE  131
>  
> diff --git a/libavcodec/defs.h b/libavcodec/defs.h
> index 00d840ec19..7ddfdcad0b 100644
> --- a/libavcodec/defs.h
> +++ b/libavcodec/defs.h
> @@ -73,6 +73,7 @@
>  #define AV_PROFILE_AAC_HE_V2   28
>  #define AV_PROFILE_AAC_LD  22
>  #define AV_PROFILE_AAC_ELD 38
> +#define AV_PROFILE_AAC_USAC41
>  #define AV_PROFILE_MPEG2_AAC_LOW  128
>  #define AV_PROFILE_MPEG2_AAC_HE   131
>  
> diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
> index 052b77926e..44bdf6f85b 100644
> --- a/libavcodec/profiles.c
> +++ b/libavcodec/profiles.c
> @@ -33,6 +33,7 @@ const AVProfile ff_aac_profiles[] = {
>  { AV_PROFILE_AAC_MAIN,  "Main" },
>  { AV_PROFILE_AAC_SSR,   "SSR"  },
>  { AV_PROFILE_AAC_LTP,   "LTP"  },
> +{ AV_PROFILE_AAC_USAC,  "xHE-AAC" },
>  { AV_PROFILE_UNKNOWN },
>  };
>  
> diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
> index 842201718b..33b7ffc17a 100644
> --- a/libavcodec/profiles.h
> +++ b/libavcodec/profiles.h
> @@ -35,6 +35,7 @@
>  FF_AVCTX_PROFILE_OPTION("aac_he_v2", NULL, AUDIO, 
> AV_PROFILE_AAC_HE_V2)\
>  FF_AVCTX_PROFILE_OPTION("aac_ld",NULL, AUDIO, AV_PROFILE_AAC_LD)\
>  FF_AVCTX_PROFILE_OPTION("aac_eld",   NULL, AUDIO, 
> AV_PROFILE_AAC_ELD)\
> +FF_AVCTX_PROFILE_OPTION("aac_xhe",   NULL, AUDIO, 
> AV_PROFILE_AAC_USAC)\
>  FF_AVCTX_PROFILE_OPTION("mpeg2_aac_low", NULL, AUDIO, 
> AV_PROFILE_MPEG2_AAC_LOW)\
>  FF_AVCTX_PROFILE_OPTION("mpeg2_aac_he",  NULL, AUDIO, 
> AV_PROFILE_MPEG2_AAC_HE)\
>  

___
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/5] swscale/aarch64: Add rgb24 to yuv implementation

[Rémi Denis-Courmont]

Le 4 juin 2024 16:55:01 GMT+03:00, Zhao Zhili  a écrit :
>From: Zhao Zhili 
>
>Test on Apple M1:
>
>rgb24_to_uv_1080_c: 7.2
>rgb24_to_uv_1080_neon: 5.5
>rgb24_to_uv_1280_c: 8.2
>rgb24_to_uv_1280_neon: 6.2
>rgb24_to_uv_1920_c: 12.5
>rgb24_to_uv_1920_neon: 9.5
>
>rgb24_to_uv_half_540_c: 6.5
>rgb24_to_uv_half_540_neon: 3.0
>rgb24_to_uv_half_640_c: 7.5
>rgb24_to_uv_half_640_neon: 3.2
>rgb24_to_uv_half_960_c: 12.5
>rgb24_to_uv_half_960_neon: 6.0
>
>rgb24_to_y_1080_c: 4.5
>rgb24_to_y_1080_neon: 3.5
>rgb24_to_y_1280_c: 5.2
>rgb24_to_y_1280_neon: 4.2
>rgb24_to_y_1920_c: 8.0
>rgb24_to_y_1920_neon: 6.0
>
>Signed-off-by: Zhao Zhili 
>---
> libswscale/aarch64/Makefile  |   1 +
> libswscale/aarch64/input.S   | 229 +++
> libswscale/aarch64/swscale.c |  25 
> 3 files changed, 255 insertions(+)
> create mode 100644 libswscale/aarch64/input.S
>
>diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
>index da1d909561..adfd90a1b6 100644
>--- a/libswscale/aarch64/Makefile
>+++ b/libswscale/aarch64/Makefile
>@@ -3,6 +3,7 @@ OBJS+= aarch64/rgb2rgb.o\
>aarch64/swscale_unscaled.o   \
> 
> NEON-OBJS   += aarch64/hscale.o \
>+   aarch64/input.o  \
>aarch64/output.o \
>aarch64/rgb2rgb_neon.o   \
>aarch64/yuv2rgb_neon.o   \
>diff --git a/libswscale/aarch64/input.S b/libswscale/aarch64/input.S
>new file mode 100644
>index 00..ee0d223c6e
>--- /dev/null
>+++ b/libswscale/aarch64/input.S
>@@ -0,0 +1,229 @@
>+/*
>+ * Copyright (c) 2024 Zhao Zhili 
>+ *
>+ * This file is part of FFmpeg.
>+ *
>+ * FFmpeg is free software; you can redistribute it and/or
>+ * modify it under the terms of the GNU Lesser General Public
>+ * License as published by the Free Software Foundation; either
>+ * version 2.1 of the License, or (at your option) any later version.
>+ *
>+ * FFmpeg is distributed in the hope that it will be useful,
>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>+ * Lesser General Public License for more details.
>+ *
>+ * You should have received a copy of the GNU Lesser General Public
>+ * License along with FFmpeg; if not, write to the Free Software
>+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
>USA
>+ */
>+
>+#include "libavutil/aarch64/asm.S"
>+
>+.macro rgb24_to_yuv_load_rgb, src
>+ld3 { v16.16b, v17.16b, v18.16b }, [\src]
>+ushll   v19.8h, v16.8b, #0 // v19: r
>+ushll   v20.8h, v17.8b, #0 // v20: g
>+ushll   v21.8h, v18.8b, #0 // v21: b
>+ushll2  v22.8h, v16.16b, #0// v22: r
>+ushll2  v23.8h, v17.16b, #0// v23: g
>+ushll2  v24.8h, v18.16b, #0// v24: b
>+.endm
>+
>+.macro rgb24_to_yuv_product, r, g, b, dst1, dst2, dst, coef0, coef1, coef2, 
>right_shift
>+mov \dst1\().16b, v6.16b// dst1 = 
>const_offset
>+mov \dst2\().16b, v6.16b// dst2 = 
>const_offset
>+smlal   \dst1\().4s, \coef0\().4h, \r\().4h // dst1 += rx 
>* r
>+smlal2  \dst2\().4s, \coef0\().8h, \r\().8h // dst2 += rx 
>* r
>+smlal   \dst1\().4s, \coef1\().4h, \g\().4h // dst1 += gx 
>* g
>+smlal2  \dst2\().4s, \coef1\().8h, \g\().8h // dst2 += gx 
>* g
>+smlal   \dst1\().4s, \coef2\().4h, \b\().4h // dst1 += bx 
>* b
>+smlal2  \dst2\().4s, \coef2\().8h, \b\().8h // dst2 += bx 
>* b
>+sqshrn  \dst\().4h, \dst1\().4s, \right_shift   // 
>dst_lower_half = dst1 >> right_shift
>+sqshrn2 \dst\().8h, \dst2\().4s, \right_shift   // 
>dst_higher_half = dst2 >> right_shift
>+.endm
>+
>+function ff_rgb24ToY_neon, export=1
>+cmp w4, #0  // check width > 0
>+b.le4f
>+
>+ldp w10, w11, [x5], #8   // w10: ry, w11: gy

I don't think it affects anything on your OoO execution hardware, but you're 
using the result of this load right off the bat in the next instruction. Ditto 
below. This may hurt perfs on not-so-fancy CPUs.

>+dup v0.8h, w10
>+dup v1.8h, w11
>+ldr w12, [x5]   // w12: by
>+dup v2.8h, w12
>+
>+mov w9, #256// w9 = 1 << (RGB2YUV_SHIFT - 
>7)
>+movkw9, #8, lsl #16 // w9 += 32 << (RGB2YUV_SHIFT 
>- 1)
>+dup v6.4s, w9   // w9: const_offset
>+
>+mov x2, #0  // w2: i
>+and w3, w4, #0xFFF0 // w3 = width / 16 * 16
>+  

Re: [FFmpeg-devel] [PATCH 2/5] swscale/aarch64: Add rgb24 to yuv implementation

[Zhao Zhili]

> On Jun 5, 2024, at 14:29, Rémi Denis-Courmont  wrote:
> 
> 
> 
> Le 4 juin 2024 16:55:01 GMT+03:00, Zhao Zhili  > a écrit :
>> From: Zhao Zhili 
>> 
>> Test on Apple M1:
>> 
>> rgb24_to_uv_1080_c: 7.2
>> rgb24_to_uv_1080_neon: 5.5
>> rgb24_to_uv_1280_c: 8.2
>> rgb24_to_uv_1280_neon: 6.2
>> rgb24_to_uv_1920_c: 12.5
>> rgb24_to_uv_1920_neon: 9.5
>> 
>> rgb24_to_uv_half_540_c: 6.5
>> rgb24_to_uv_half_540_neon: 3.0
>> rgb24_to_uv_half_640_c: 7.5
>> rgb24_to_uv_half_640_neon: 3.2
>> rgb24_to_uv_half_960_c: 12.5
>> rgb24_to_uv_half_960_neon: 6.0
>> 
>> rgb24_to_y_1080_c: 4.5
>> rgb24_to_y_1080_neon: 3.5
>> rgb24_to_y_1280_c: 5.2
>> rgb24_to_y_1280_neon: 4.2
>> rgb24_to_y_1920_c: 8.0
>> rgb24_to_y_1920_neon: 6.0
>> 
>> Signed-off-by: Zhao Zhili 
>> ---
>> libswscale/aarch64/Makefile  |   1 +
>> libswscale/aarch64/input.S   | 229 +++
>> libswscale/aarch64/swscale.c |  25 
>> 3 files changed, 255 insertions(+)
>> create mode 100644 libswscale/aarch64/input.S
>> 
>> diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
>> index da1d909561..adfd90a1b6 100644
>> --- a/libswscale/aarch64/Makefile
>> +++ b/libswscale/aarch64/Makefile
>> @@ -3,6 +3,7 @@ OBJS+= aarch64/rgb2rgb.o\
>>   aarch64/swscale_unscaled.o   \
>> 
>> NEON-OBJS   += aarch64/hscale.o \
>> +   aarch64/input.o  \
>>   aarch64/output.o \
>>   aarch64/rgb2rgb_neon.o   \
>>   aarch64/yuv2rgb_neon.o   \
>> diff --git a/libswscale/aarch64/input.S b/libswscale/aarch64/input.S
>> new file mode 100644
>> index 00..ee0d223c6e
>> --- /dev/null
>> +++ b/libswscale/aarch64/input.S
>> @@ -0,0 +1,229 @@
>> +/*
>> + * Copyright (c) 2024 Zhao Zhili 
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
>> USA
>> + */
>> +
>> +#include "libavutil/aarch64/asm.S"
>> +
>> +.macro rgb24_to_yuv_load_rgb, src
>> +ld3 { v16.16b, v17.16b, v18.16b }, [\src]
>> +ushll   v19.8h, v16.8b, #0 // v19: r
>> +ushll   v20.8h, v17.8b, #0 // v20: g
>> +ushll   v21.8h, v18.8b, #0 // v21: b
>> +ushll2  v22.8h, v16.16b, #0// v22: r
>> +ushll2  v23.8h, v17.16b, #0// v23: g
>> +ushll2  v24.8h, v18.16b, #0// v24: b
>> +.endm
>> +
>> +.macro rgb24_to_yuv_product, r, g, b, dst1, dst2, dst, coef0, coef1, coef2, 
>> right_shift
>> +mov \dst1\().16b, v6.16b// dst1 = 
>> const_offset
>> +mov \dst2\().16b, v6.16b// dst2 = 
>> const_offset
>> +smlal   \dst1\().4s, \coef0\().4h, \r\().4h // dst1 += 
>> rx * r
>> +smlal2  \dst2\().4s, \coef0\().8h, \r\().8h // dst2 += 
>> rx * r
>> +smlal   \dst1\().4s, \coef1\().4h, \g\().4h // dst1 += 
>> gx * g
>> +smlal2  \dst2\().4s, \coef1\().8h, \g\().8h // dst2 += 
>> gx * g
>> +smlal   \dst1\().4s, \coef2\().4h, \b\().4h // dst1 += 
>> bx * b
>> +smlal2  \dst2\().4s, \coef2\().8h, \b\().8h // dst2 += 
>> bx * b
>> +sqshrn  \dst\().4h, \dst1\().4s, \right_shift   // 
>> dst_lower_half = dst1 >> right_shift
>> +sqshrn2 \dst\().8h, \dst2\().4s, \right_shift   // 
>> dst_higher_half = dst2 >> right_shift
>> +.endm
>> +
>> +function ff_rgb24ToY_neon, export=1
>> +cmp w4, #0  // check width > 0
>> +b.le4f
>> +
>> +ldp w10, w11, [x5], #8   // w10: ry, w11: gy
> 
> I don't think it affects anything on your OoO execution hardware, but you're 
> using the result of this load right off the bat in the next instruction. 
> Ditto below. This may hurt perfs on not-so-fancy CPUs.

Will do.

> 
>> +dup v0.8h, w10
>> +dup v1.8h, w11
>> +ldr w12, [x5]   // w12: by
>> +dup v2.8h, w12
>> +
>> +mov w9, #256