Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Vittorio Giovara]

On Sat, May 4, 2024 at 4:35 PM Michael Niedermayer 
wrote:

> > - secure funding for larger projects
>
> what project you want to get funding for ?
> A wide range of things are funded, and last i asked when STF money was
> available
> i couldnt even find enough people willing to submit a project to reach
> 150k €
>
> hint hint: there is 2025 and we need maintaince projects to submit to STF
> in 2025
>

move the infrastructure and review process to github/gitlab/gitea/forgeio
-- 
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 v3] avformat/framecrcenc: compute the checksum for side data

[James Almer]

On 5/4/2024 10:45 PM, Michael Niedermayer wrote:

On Sat, May 04, 2024 at 06:02:25PM -0300, James Almer wrote:



On 5/4/2024 5:58 PM, Michael Niedermayer wrote:

On Sat, May 04, 2024 at 12:16:00PM -0300, James Almer wrote:

On 5/4/2024 5:34 AM, Marton Balint wrote:



On Thu, 2 May 2024, James Almer wrote:


On 5/2/2024 6:23 PM, Marton Balint wrote:



   On Wed, 1 May 2024, Michael Niedermayer wrote:


   This allows detecting issues in side data related code, same as what
   framecrc does for before already for packet data itself.

   This basically reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e57.


   Can you at least add an option which allows disabling dumping the side
   data? Changing the format of framecrc output again and again is
not very


The framehash/framemd5 muxer is versioned, which is what you should
use if you want parseable output.


Okay, but then the question is that why framecrc is using different code
and options?


Originally it was framecrc (using AVAdler) and framemd5 (using AVMD5). The
latter was renamed/aliased to framehash and made to use the AVHash API,
which supports all lavu hashing algorithms, and is versioned.
If anyone cared, framecrc could be also made into an alias of framehash that
defaults to adler32 output, but it would result in a massive change to
reference files, if anything because AVHash initializes adler32 with a 1
whereas framecrc does it with a 0.


normally starting adler32 at 0 is bad as one could prefix by a 0 byte with
no checksum change, but given we also show the size that spcific case isnt
an issue

can we make the initial value for adler32 configureable so as to improve long
term stability of checksums ? (or add a adler32_1 to AVHash)


av_hash_init() already initializes adler32 with a 1. No need to do anything
there. It's the framecrc muxer that uses adler32 with 0 as init value.


i was thinking about av_hash_init() supporting a 0 init to avoid changing every
checksum. Which would
increase git repository size
and make long term comparissions harder because framecrc would not be comparable
at all. not just some extra fields that occasionally appear


Adding AVOptions is not backwards compatible, as it would only work on 
AVHashContext from the introductory commit onwards, so the only 
alternative is probably a new init function that takes an input seed 
argument. Just not an uint32_t, as that's not extensible. It would need 
to be an uint8_t array.

___
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] avformat/framecrcenc: compute the checksum for side data

[Michael Niedermayer]

On Sat, May 04, 2024 at 06:02:25PM -0300, James Almer wrote:
> 
> 
> On 5/4/2024 5:58 PM, Michael Niedermayer wrote:
> > On Sat, May 04, 2024 at 12:16:00PM -0300, James Almer wrote:
> > > On 5/4/2024 5:34 AM, Marton Balint wrote:
> > > > 
> > > > 
> > > > On Thu, 2 May 2024, James Almer wrote:
> > > > 
> > > > > On 5/2/2024 6:23 PM, Marton Balint wrote:
> > > > > > 
> > > > > > 
> > > > > >   On Wed, 1 May 2024, Michael Niedermayer wrote:
> > > > > > 
> > > > > > >   This allows detecting issues in side data related code, same as 
> > > > > > > what
> > > > > > >   framecrc does for before already for packet data itself.
> > > > > > > 
> > > > > > >   This basically reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e57.
> > > > > > 
> > > > > >   Can you at least add an option which allows disabling dumping the 
> > > > > > side
> > > > > >   data? Changing the format of framecrc output again and again is
> > > > > > not very
> > > > > 
> > > > > The framehash/framemd5 muxer is versioned, which is what you should
> > > > > use if you want parseable output.
> > > > 
> > > > Okay, but then the question is that why framecrc is using different code
> > > > and options?
> > > 
> > > Originally it was framecrc (using AVAdler) and framemd5 (using AVMD5). The
> > > latter was renamed/aliased to framehash and made to use the AVHash API,
> > > which supports all lavu hashing algorithms, and is versioned.
> > > If anyone cared, framecrc could be also made into an alias of framehash 
> > > that
> > > defaults to adler32 output, but it would result in a massive change to
> > > reference files, if anything because AVHash initializes adler32 with a 1
> > > whereas framecrc does it with a 0.
> > 
> > normally starting adler32 at 0 is bad as one could prefix by a 0 byte with
> > no checksum change, but given we also show the size that spcific case isnt
> > an issue
> > 
> > can we make the initial value for adler32 configureable so as to improve 
> > long
> > term stability of checksums ? (or add a adler32_1 to AVHash)
> 
> av_hash_init() already initializes adler32 with a 1. No need to do anything
> there. It's the framecrc muxer that uses adler32 with 0 as init value.

i was thinking about av_hash_init() supporting a 0 init to avoid changing every
checksum. Which would
increase git repository size
and make long term comparissions harder because framecrc would not be comparable
at all. not just some extra fields that occasionally appear

thx

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

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


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/amrwbdec: assert mode to be valid in decode_fixed_vector()

[Michael Niedermayer]

On Sun, Apr 28, 2024 at 11:30:51PM +0200, Michael Niedermayer wrote:
> Inspired-by: CID1473499 Uninitialized scalar variable
> 
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/amrwbdec.c | 3 +++
>  1 file changed, 3 insertions(+)

will apply

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/5] tools/opt_common: Check for malloc failure

[Michael Niedermayer]

On Sun, Apr 28, 2024 at 11:30:48PM +0200, Michael Niedermayer wrote:
> Fixes: CID1539100 Negative loop bound
> 
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer 
> ---
>  fftools/opt_common.c | 14 --
>  1 file changed, 8 insertions(+), 6 deletions(-)

will apply

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

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


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 6/6] avformat/mxfdec: Check body_offset

[Michael Niedermayer]

On Mon, Apr 29, 2024 at 10:25:33PM +0200, Tomas Härdin wrote:
> fre 2024-04-26 klockan 05:08 +0200 skrev Michael Niedermayer:
> > Fixes: signed integer overflow: 538976288 - -9223372036315799520
> > cannot be represented in type 'long'
> > Fixes: 68060/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-
> > 5523457266745344
> > 
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/mxfdec.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 233d614f783..e65cec74c23 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -791,6 +791,9 @@ static int mxf_read_partition_pack(void *arg,
> > AVIOContext *pb, int tag, int size
> >  partition->index_sid = avio_rb32(pb);
> >  partition->body_offset = avio_rb64(pb);
> >  partition->body_sid = avio_rb32(pb);
> > +    if (partition->body_offset < 0)
> > +    return AVERROR_INVALIDDATA;
> 
> The spec says BodyOffset is UInt64, so this means we drop support for
> files >= 2^63 bytes. This is probably fine though. Supporting such
> large files would be a pain in more places than here.
> 
> MXF is sometimes used to archive scanned copies of film, but even raw
> 16k rgb48 essence @ 120 Hz takes over 1000 days of footage to hit the
> 2^63 limit..
> 
> I took a look at the body_offset logic and it looks like it should be
> correct when we force them to be non-negative.
> 
> TL;DR: looks OK

will apply
will also apply 2,3,5 of this set

thanks

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

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


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 2/2] tools/target_enc_fuzzer: Only read pix_fmts if its set

[Michael Niedermayer]

Fixes: null pointer dereference
Fixes: rawvideo encoder

Signed-off-by: Michael Niedermayer 
---
 tools/target_enc_fuzzer.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tools/target_enc_fuzzer.c b/tools/target_enc_fuzzer.c
index 1749f6905bd..0345595ada7 100644
--- a/tools/target_enc_fuzzer.c
+++ b/tools/target_enc_fuzzer.c
@@ -130,10 +130,12 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 
 flags64 = bytestream2_get_le64();
 
-int npixfmts = 0;
-while (c->p.pix_fmts[npixfmts++] != AV_PIX_FMT_NONE)
-;
-ctx->pix_fmt = c->p.pix_fmts[bytestream2_get_byte() % npixfmts];
+if (c->p.pix_fmts) {
+int npixfmts = 0;
+while (c->p.pix_fmts[npixfmts++] != AV_PIX_FMT_NONE)
+;
+ctx->pix_fmt = c->p.pix_fmts[bytestream2_get_byte() % 
npixfmts];
+}
 
 switch (c->p.id) {
 case AV_CODEC_ID_FFV1:{
-- 
2.43.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 1/2] tools/target_enc_fuzzer: replace assert by clean exit

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 tools/target_enc_fuzzer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/target_enc_fuzzer.c b/tools/target_enc_fuzzer.c
index 4357d376365..1749f6905bd 100644
--- a/tools/target_enc_fuzzer.c
+++ b/tools/target_enc_fuzzer.c
@@ -89,7 +89,8 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
 av_log_set_level(AV_LOG_PANIC);
 }
 
-av_assert0(c->p.type == AVMEDIA_TYPE_VIDEO);
+if (c->p.type != AVMEDIA_TYPE_VIDEO)
+return 0;
 
 maxpixels = maxpixels_per_frame * maxiteration;
 
-- 
2.43.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] 5 year plan & Inovation

[Zhao Zhili]

> 在 2024年5月5日，上午5:51，epira...@gmail.com 写道：
> 
> 
> 
>> On 4 May 2024, at 23:25, Andrew Sayers wrote:
>> 
>>> On Sat, May 04, 2024 at 09:28:03PM +0200, Michael Niedermayer wrote:
>>> Hi
>>> 
 On Fri, May 03, 2024 at 03:45:20PM +, Cosmin Stejerean via 
 ffmpeg-devel wrote:
>>> [...]
 What doesn't exist (yet) is a way to keep people on the exact email based 
 workflow
 we currently have, and have bi-directional sync with something like github 
 or gitlab.
 Such a thing could probably be built, but it might be worth first trying 
 to see if those
 that insist on sticking with the CLI can use one of the existing CLI based 
 workflows.
>>> 
>>> Such a thing could be quite useful to many more projects than just ffmpeg.
>>> There are many older projects that use ML based workflows.
>>> 
>>> I imagine STF might be willing to fund such a thing if it is technically
>>> feasable. As the goal of STF is about maintainance. And bridging the gap
>>> between old ML and new browser based workflows allowing developers who
>>> prefer to work through their web browser to do so.
>>> 
>>> also, we need to find maintaince related projects worth minimum 150k €
>>> for 2025 for STF.
>>> We cant do many of the things we do in 2024 for STF again as they where
>>> one time things and STF doesnt like sponsoring adding new features.
>>> 
>>> thx
>> 
>> It seems like the strongest argument for sticking with the ML is from
>> experienced maintainers who don't want to jeopardise their existing
>> workflow; while the strongest argument for switching is from people
>> itching to try out new workflows.

It’s not “try out new workflows”, but current workflow is inefficient and 
unbearable for some of us.

>> So how about this for a plan...
>> 
>> Make a repo on SourceHut, not necessarily for FFmpeg itself but for
>> automated review tools (running fate tests, checking C11 compliance
>> etc.).  Their CI/CD system automatically runs those tests on every
>> patch, then we manually forward genuine issues to the ML.  That would
>> let experimenters show off new things, and would let maintainers
>> think through what their workflow would look like in a mixed
>> environment.  Then when we've got enough evidence to make a long-term
>> plan, we can wind the repo down without too much fuss.
> 
> I hardly see how SourceHut would improve much of any of the actual
> struggles we talked about in this thread tbh…
> 
> FWIW what most people are desiring is better review workflow/tooling
> than a mail client can not offer (easily) and making it easier for
> people to contribute by simply pushing a branch to their fork
> which is for better or worse what a lot of people are familiar with
> from GitHub.
> 
> Both of which is nothing SourceHut offers, to my knowledge.
> 
> So rather than spend efforts on something that only marginally improves
> upon what is currently used it would IMHO be way more useful to evaluate
> something like GitLab or Gitea/Forgejo.

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

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

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

[FFmpeg-devel] [PATCH 2/2] avcodec/fmvc: remove dead assignment

[Michael Niedermayer]

Fixes: CID1529220 Unused value

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer 
---
 libavcodec/fmvc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavcodec/fmvc.c b/libavcodec/fmvc.c
index 30f7aaf6bc3..b51b18a9eec 100644
--- a/libavcodec/fmvc.c
+++ b/libavcodec/fmvc.c
@@ -101,7 +101,6 @@ static int decode_type2(GetByteContext *gb, PutByteContext 
*pb)
 continue;
 }
 }
-repeat = 0;
 }
 repeat = 1;
 }
-- 
2.43.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 1/2] avcodec/flac_parser: Assert that we do not overrun the link_penalty array

[Michael Niedermayer]

Fixes: CID1454676 Out-of-bounds read

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer 
---
 libavcodec/flac_parser.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/flac_parser.c b/libavcodec/flac_parser.c
index 47904d515a6..d9c47801f83 100644
--- a/libavcodec/flac_parser.c
+++ b/libavcodec/flac_parser.c
@@ -518,6 +518,8 @@ static int check_header_mismatch(FLACParseContext  *fpc,
 for (i = 0; i < FLAC_MAX_SEQUENTIAL_HEADERS && curr != child; i++)
 curr = curr->next;
 
+av_assert0(i < FLAC_MAX_SEQUENTIAL_HEADERS);
+
 if (header->link_penalty[i] < FLAC_HEADER_CRC_FAIL_PENALTY ||
 header->link_penalty[i] == FLAC_HEADER_NOT_PENALIZED_YET) {
 FLACHeaderMarker *start, *end;
-- 
2.43.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] 5 year plan & Inovation

[epirat07]

On 4 May 2024, at 23:25, Andrew Sayers wrote:

> On Sat, May 04, 2024 at 09:28:03PM +0200, Michael Niedermayer wrote:
>> Hi
>>
>> On Fri, May 03, 2024 at 03:45:20PM +, Cosmin Stejerean via ffmpeg-devel 
>> wrote:
>> [...]
>>> What doesn't exist (yet) is a way to keep people on the exact email based 
>>> workflow
>>> we currently have, and have bi-directional sync with something like github 
>>> or gitlab.
>>> Such a thing could probably be built, but it might be worth first trying to 
>>> see if those
>>> that insist on sticking with the CLI can use one of the existing CLI based 
>>> workflows.
>>
>> Such a thing could be quite useful to many more projects than just ffmpeg.
>> There are many older projects that use ML based workflows.
>>
>> I imagine STF might be willing to fund such a thing if it is technically
>> feasable. As the goal of STF is about maintainance. And bridging the gap
>> between old ML and new browser based workflows allowing developers who
>> prefer to work through their web browser to do so.
>>
>> also, we need to find maintaince related projects worth minimum 150k €
>> for 2025 for STF.
>> We cant do many of the things we do in 2024 for STF again as they where
>> one time things and STF doesnt like sponsoring adding new features.
>>
>> thx
>
> It seems like the strongest argument for sticking with the ML is from
> experienced maintainers who don't want to jeopardise their existing
> workflow; while the strongest argument for switching is from people
> itching to try out new workflows.  So how about this for a plan...
>
> Make a repo on SourceHut, not necessarily for FFmpeg itself but for
> automated review tools (running fate tests, checking C11 compliance
> etc.).  Their CI/CD system automatically runs those tests on every
> patch, then we manually forward genuine issues to the ML.  That would
> let experimenters show off new things, and would let maintainers
> think through what their workflow would look like in a mixed
> environment.  Then when we've got enough evidence to make a long-term
> plan, we can wind the repo down without too much fuss.

I hardly see how SourceHut would improve much of any of the actual
struggles we talked about in this thread tbh…

FWIW what most people are desiring is better review workflow/tooling
than a mail client can not offer (easily) and making it easier for
people to contribute by simply pushing a branch to their fork
which is for better or worse what a lot of people are familiar with
from GitHub.

Both of which is nothing SourceHut offers, to my knowledge.

So rather than spend efforts on something that only marginally improves
upon what is currently used it would IMHO be way more useful to evaluate
something like GitLab or Gitea/Forgejo.

> ___
> 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] 5 year plan & Inovation

[Andrew Sayers]

On Sat, May 04, 2024 at 09:28:03PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Fri, May 03, 2024 at 03:45:20PM +, Cosmin Stejerean via ffmpeg-devel 
> wrote:
> [...]
> > What doesn't exist (yet) is a way to keep people on the exact email based 
> > workflow 
> > we currently have, and have bi-directional sync with something like github 
> > or gitlab.
> > Such a thing could probably be built, but it might be worth first trying to 
> > see if those
> > that insist on sticking with the CLI can use one of the existing CLI based 
> > workflows.
> 
> Such a thing could be quite useful to many more projects than just ffmpeg.
> There are many older projects that use ML based workflows.
> 
> I imagine STF might be willing to fund such a thing if it is technically
> feasable. As the goal of STF is about maintainance. And bridging the gap
> between old ML and new browser based workflows allowing developers who
> prefer to work through their web browser to do so.
> 
> also, we need to find maintaince related projects worth minimum 150k €
> for 2025 for STF.
> We cant do many of the things we do in 2024 for STF again as they where
> one time things and STF doesnt like sponsoring adding new features.
> 
> thx

It seems like the strongest argument for sticking with the ML is from
experienced maintainers who don't want to jeopardise their existing
workflow; while the strongest argument for switching is from people
itching to try out new workflows.  So how about this for a plan...

Make a repo on SourceHut, not necessarily for FFmpeg itself but for
automated review tools (running fate tests, checking C11 compliance
etc.).  Their CI/CD system automatically runs those tests on every
patch, then we manually forward genuine issues to the ML.  That would
let experimenters show off new things, and would let maintainers
think through what their workflow would look like in a mixed
environment.  Then when we've got enough evidence to make a long-term
plan, we can wind the repo down without too much fuss.
___
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] avformat/framecrcenc: compute the checksum for side data

[James Almer]

On 5/4/2024 5:58 PM, Michael Niedermayer wrote:

On Sat, May 04, 2024 at 12:16:00PM -0300, James Almer wrote:

On 5/4/2024 5:34 AM, Marton Balint wrote:



On Thu, 2 May 2024, James Almer wrote:


On 5/2/2024 6:23 PM, Marton Balint wrote:



  On Wed, 1 May 2024, Michael Niedermayer wrote:


  This allows detecting issues in side data related code, same as what
  framecrc does for before already for packet data itself.

  This basically reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e57.


  Can you at least add an option which allows disabling dumping the side
  data? Changing the format of framecrc output again and again is
not very


The framehash/framemd5 muxer is versioned, which is what you should
use if you want parseable output.


Okay, but then the question is that why framecrc is using different code
and options?


Originally it was framecrc (using AVAdler) and framemd5 (using AVMD5). The
latter was renamed/aliased to framehash and made to use the AVHash API,
which supports all lavu hashing algorithms, and is versioned.
If anyone cared, framecrc could be also made into an alias of framehash that
defaults to adler32 output, but it would result in a massive change to
reference files, if anything because AVHash initializes adler32 with a 1
whereas framecrc does it with a 0.


normally starting adler32 at 0 is bad as one could prefix by a 0 byte with
no checksum change, but given we also show the size that spcific case isnt
an issue

can we make the initial value for adler32 configureable so as to improve long
term stability of checksums ? (or add a adler32_1 to AVHash)


av_hash_init() already initializes adler32 with a 1. No need to do 
anything there. It's the framecrc muxer that uses adler32 with 0 as init 
value.




thx

[...]


___
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] avformat/framecrcenc: compute the checksum for side data

[Michael Niedermayer]

On Sat, May 04, 2024 at 12:16:00PM -0300, James Almer wrote:
> On 5/4/2024 5:34 AM, Marton Balint wrote:
> > 
> > 
> > On Thu, 2 May 2024, James Almer wrote:
> > 
> > > On 5/2/2024 6:23 PM, Marton Balint wrote:
> > > > 
> > > > 
> > > >  On Wed, 1 May 2024, Michael Niedermayer wrote:
> > > > 
> > > > >  This allows detecting issues in side data related code, same as what
> > > > >  framecrc does for before already for packet data itself.
> > > > > 
> > > > >  This basically reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e57.
> > > > 
> > > >  Can you at least add an option which allows disabling dumping the side
> > > >  data? Changing the format of framecrc output again and again is
> > > > not very
> > > 
> > > The framehash/framemd5 muxer is versioned, which is what you should
> > > use if you want parseable output.
> > 
> > Okay, but then the question is that why framecrc is using different code
> > and options?
> 
> Originally it was framecrc (using AVAdler) and framemd5 (using AVMD5). The
> latter was renamed/aliased to framehash and made to use the AVHash API,
> which supports all lavu hashing algorithms, and is versioned.
> If anyone cared, framecrc could be also made into an alias of framehash that
> defaults to adler32 output, but it would result in a massive change to
> reference files, if anything because AVHash initializes adler32 with a 1
> whereas framecrc does it with a 0.

normally starting adler32 at 0 is bad as one could prefix by a 0 byte with
no checksum change, but given we also show the size that spcific case isnt
an issue

can we make the initial value for adler32 configureable so as to improve long
term stability of checksums ? (or add a adler32_1 to AVHash)

thx

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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] 5 year plan & Inovation

[Michael Niedermayer]

On Sat, Apr 27, 2024 at 12:39:14PM -0400, Vittorio Giovara wrote:
> On Sat, Apr 27, 2024 at 6:24 AM Michael Niedermayer 
> wrote:
> 
> > On Thu, Apr 25, 2024 at 08:15:27AM -0700, Vittorio Giovara wrote:
> > > On Wed, Apr 24, 2024 at 3:00 PM Michael Niedermayer <
> > mich...@niedermayer.cc>
> > > wrote:
> > >
> > > > > Microsoft expanded into new fields with Xbox and Azure, yes. But
> > Windows
> > > > is still an OS, and Office is still a (un)productivity suite.
> > > > >
> > > > > Accordingly, maybe you can innovate with a new project within the
> > same
> > > > legal entity as FFmpeg (be it SPI, FFlabs or whatever).
> > > > >
> > > > > But FFmpeg as a software project is not a suitable venue for radical
> > new
> > > > innovation.
> > > >
> > > > Microsofts OS does not limit what can be installed to whats in MS main
> > > > repository, FFmpeg does
> > > >
> > > > Microsoft windows from a user POV includes internet explorer IIRC. Its
> > not
> > > > a seperate
> > > > product from just the legal entity. It was not in the first OS from
> > > > microsoft
> > > >
> > > > microsofts first OS MS-DOS 1.0 ? looks slightly different than the
> > current
> > > > latest OS.
> > > > There was radical innovation, if one likes MS or hate them.
> > > >
> > > >
> > > > >
> > > > > >You can do the same with apple, google, or others.
> > > > >
> > > > > Sure but you can't do the same with iPhone or Google Search.
> > > >
> > > > of course you can, googles search inovated. Theres a image search a
> > audio
> > > > search
> > > > news, travel, shoping.
> > > > These did not exist in the initial google search. And while i dont
> > know, i
> > > > suspect
> > > > google search is very good at finding google products.
> > > > Google didnt became that big by simply "not being evil"
> > > >
> > > > But lets not assume, lets try, if i search for maps i get
> > > > Google Maps as first entry.
> > > >
> > > > or finance, 2nd entry is https://www.google.com/finance/
> > > >
> > > >
> > > > And the iphone uses apples operating system and their app store, with
> > > > many apple apps. Check the first iphone and compare it to the latest
> > > > there is huge inovation with what you can do with all the software
> > > > that comes preinstalled and also what you can install later.
> > > > Thats in stark contrast to
> > > > "FFmpeg as a software project is not a suitable venue for radical new
> > > > innovation"
> > > > when did you last use siri with your iphone ? siri was added in
> > > > iphone 4s IIUC. Thats a big change.
> > > >
> > > > I can ultimately only repeat my oppinion. FFmpeg will innovate or
> > FFmpeg
> > > > will stagnate and eventually be replaced by some other project that
> > doesnt
> > > > have an opposition to innovation.
> > > >
> > > > IMHO we need to find out what direction (of innovation or lack thereof)
> > > > people want. This RFC thread is kind of the first step.
> > > > 2nd step would be a vote.
> > >
> > >
> > > You are kinda comparing apples and oranges, a platform like an OS or a
> >
> > The examples i showed cover a wide range of software (An OS, A office
> > suite,
> > A web browser, an AI assitent, a search engine, web apps, and more)
> > and hardware like a phone, services like cloud
> >
> > For all of them its true that radical innovation was essential for success.
> >
> > our multimedia framework is not a special case relative to above
> >
> >
> > > network or a crypto exchange or a browser based on ffmpeg.exe, and not
> > > because it's impossible but
> >
> > These sound like really bad ideas unrealated to innovation.
> >
> >
> > > because it's the wrong tool for the job -
> >
> > IMHO, this is missing the point a bit
> >
> > A phone originally was a tool to call and talk to someone, to be reachable
> > by
> > voice communication.
> > Its not a tool to write letters, until it was
> > Its not a tool to browse the internet until it was
> > Its not an assitent you could ask something until it was
> > ...
> >
> > A internet browser originally was a tool to display static text and images
> > maybe some ftp and gopher sprinkled into it.
> > its not a tool to do video chat with , until it was
> > its not a tool to write mails in, until it was
> > its not a tool to submit your patches to git, until it was, ohh wait, i
> > have a deja vue feeling here
> >
> > (and you can continue this list with software, hardware and services from
> > other
> >  successfull companies, there is radical innovation everywhere)
> >
> > our repository is also not just the ffmpeg tool, there are libraries and
> > theres
> > ffmpeg, ffprobe, ffplay
> >
> > FFmpeg is a whole multimedia framework and there are many things we could
> > innovate
> > on.
> >
> > Also, i agree its important to listen to what the users want. But often
> > what they
> > ask for and what actually would help them most, can be different.
> >
> 
> This is many words to say that you're missing the point. Let me try in
> social media format
> 

> 

Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Michael Niedermayer]

Hi

On Fri, May 03, 2024 at 03:45:20PM +, Cosmin Stejerean via ffmpeg-devel 
wrote:
[...]
> What doesn't exist (yet) is a way to keep people on the exact email based 
> workflow 
> we currently have, and have bi-directional sync with something like github or 
> gitlab.
> Such a thing could probably be built, but it might be worth first trying to 
> see if those
> that insist on sticking with the CLI can use one of the existing CLI based 
> workflows.

Such a thing could be quite useful to many more projects than just ffmpeg.
There are many older projects that use ML based workflows.

I imagine STF might be willing to fund such a thing if it is technically
feasable. As the goal of STF is about maintainance. And bridging the gap
between old ML and new browser based workflows allowing developers who
prefer to work through their web browser to do so.

also, we need to find maintaince related projects worth minimum 150k €
for 2025 for STF.
We cant do many of the things we do in 2024 for STF again as they where
one time things and STF doesnt like sponsoring adding new features.

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Vittorio Giovara]

On Sat, May 4, 2024 at 3:09 PM Michael Niedermayer 
wrote:

> On Sat, May 04, 2024 at 02:04:16PM -0400, Vittorio Giovara wrote:
> > On Sat, May 4, 2024 at 9:06 AM Ondřej Fiala  wrote:
> >
> > > On Sat May 4, 2024 at 3:11 AM CEST, flow gg wrote:
> > > > I have tried git-send-email, but it failed. You can say that I am
> stupid,
> > > > but I would say that this is because of various reasons such as my
> area
> > > and
> > > > the network. It is really not what I can solve.
> > > > Maybe I will spend a lot of energy trying it in the future, but this
> is
> > > > because I have submitted thousands of lines of code. I don't want to
> give
> > > > up. If it is from the beginning, it will cause abandonment.
> > > >
> > > > Maybe I am younger here in FFMPEG. I have a lot of good young people
> > > around
> > > > me. They all use github/lab by default, and there will be the same
> > > problem
> > > > as me, resulting in abandonment.
> > > I feel it's worth pointing out that SourceHut and mailing list-based
> > > workflows
> > > are becoming popular in some young-dev circles. I am in my twenties for
> > > reference.
> > >
> > > With that said, I did not realize how problematic setting up git
> send-email
> > > can be with some providers when I wrote what you're replying to. The
> > > replies
> > > quite surprised me honestly because when I first set up git
> send-email, I
> > > was using completely average providers and it was all pretty
> effortless,
> > > I just adjusted git's config and it worked perfectly.
> > >
> > > > I don't really care about the quality between these tools. I think
> people
> > > > are important. I only want to use it, and I can facilitate the real
> > > > reviewer of Review.
> > > >
> > > > I don't know if I can say my personal feelings here, but I will say:
> > > >
> > > > I feel despised by this passage, which makes me uncomfortable. If you
> > > are a
> > > > reviewer, maybe I have no chance to contribute, but anyway, I have
> made
> > > > some contributions.
> > > >
> > > > > How can anyone use git, but not git send-email? Any decent email
> > > provider
> > > > > has support for external clients over SMTP. And I believe you *can*
> > >
> > > > > actually dictate that people don't attach patches -- if you have
> > > control
> > > > > over the mailing list software, you can set up a filter that
> rejects
> > > such
> > > > > emails and auto-replies with instructions on how to send them
> properly.
> > > > I think I should have the right to contribute
> > > Likewise.
> > >
> > > Regarding the part about rejecting patches as attachments, I was
> > > specifically
> > > reacting to Rémi claiming that he can't dictate that people don't use
> them,
> > > which technically he can. I never said it's a good idea, though it
> might
> > > have
> > > sounded that way. Sorry about that.
> > >
> > > As I said multiple times, I feel like contributing over email is a lot
> > > about
> > > having good tooling. For example, the email client I use treats all
> parts
> > > of
> > > a multipart message the same, so it has no issues replying to text
> > > attachments
> > > instead of the message body. As such, there is no difference between
> > > attached
> > > patches and patches in the message body with such a client.
> > >
> >
> > Is it me or has this thread and topic run its course?
> > We understand your preference is email and it is duly noted, the
> > overwhelming majority of the community still seem to prefer
> github/gitlab.
> > Any further discussion at this point looks off topic, there are better
> > venues for discussing the technical merits of email vs github/gitlab.
>
> Is it me or are the top 3 people who objected to gitlab on vaccation,
> banned
> and busy ?
> Maybe we should wait for them to have an oppertunity to comment. One of
> them
> happens to be an experienced gitlab admin
>

If one is banned, then they lose the chance to express their opinion in the
community, it's the whole point of being in a community! You act civil and
your opinions are heard, you troll and you get banned, pretty simple to me.
If we ban people and then wait for them to be unbanned before we take
decisions defeats the whole point of being banned, and instead brings in
pointless filibustering. Maybe they should behave better and not get banned
instead?

For the other two, I think at least one is ok to use command line tools to
my knowledge and that is good enough to at least experiment with a move.
Hopefully we won't stall the move because 3 people vs 238 community members
said so, or do you think we need a vote by the GA on this?

At any rate, my point was that the discussion on github vs email here is
done, nothing can be added to sway either side that wasn't already said.
Since we're starting to see the negative effects of this discussion (our
inability to effectively ban people, making people feel gatekept, and so
on) I'd say it'd be more beneficial to move the agree to disagree
discussion elsewhere, in my 

Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Michael Niedermayer]

On Sat, May 04, 2024 at 02:04:16PM -0400, Vittorio Giovara wrote:
> On Sat, May 4, 2024 at 9:06 AM Ondřej Fiala  wrote:
> 
> > On Sat May 4, 2024 at 3:11 AM CEST, flow gg wrote:
> > > I have tried git-send-email, but it failed. You can say that I am stupid,
> > > but I would say that this is because of various reasons such as my area
> > and
> > > the network. It is really not what I can solve.
> > > Maybe I will spend a lot of energy trying it in the future, but this is
> > > because I have submitted thousands of lines of code. I don't want to give
> > > up. If it is from the beginning, it will cause abandonment.
> > >
> > > Maybe I am younger here in FFMPEG. I have a lot of good young people
> > around
> > > me. They all use github/lab by default, and there will be the same
> > problem
> > > as me, resulting in abandonment.
> > I feel it's worth pointing out that SourceHut and mailing list-based
> > workflows
> > are becoming popular in some young-dev circles. I am in my twenties for
> > reference.
> >
> > With that said, I did not realize how problematic setting up git send-email
> > can be with some providers when I wrote what you're replying to. The
> > replies
> > quite surprised me honestly because when I first set up git send-email, I
> > was using completely average providers and it was all pretty effortless,
> > I just adjusted git's config and it worked perfectly.
> >
> > > I don't really care about the quality between these tools. I think people
> > > are important. I only want to use it, and I can facilitate the real
> > > reviewer of Review.
> > >
> > > I don't know if I can say my personal feelings here, but I will say:
> > >
> > > I feel despised by this passage, which makes me uncomfortable. If you
> > are a
> > > reviewer, maybe I have no chance to contribute, but anyway, I have made
> > > some contributions.
> > >
> > > > How can anyone use git, but not git send-email? Any decent email
> > provider
> > > > has support for external clients over SMTP. And I believe you *can*
> >
> > > > actually dictate that people don't attach patches -- if you have
> > control
> > > > over the mailing list software, you can set up a filter that rejects
> > such
> > > > emails and auto-replies with instructions on how to send them properly.
> > > I think I should have the right to contribute
> > Likewise.
> >
> > Regarding the part about rejecting patches as attachments, I was
> > specifically
> > reacting to Rémi claiming that he can't dictate that people don't use them,
> > which technically he can. I never said it's a good idea, though it might
> > have
> > sounded that way. Sorry about that.
> >
> > As I said multiple times, I feel like contributing over email is a lot
> > about
> > having good tooling. For example, the email client I use treats all parts
> > of
> > a multipart message the same, so it has no issues replying to text
> > attachments
> > instead of the message body. As such, there is no difference between
> > attached
> > patches and patches in the message body with such a client.
> >
> 
> Is it me or has this thread and topic run its course?
> We understand your preference is email and it is duly noted, the
> overwhelming majority of the community still seem to prefer github/gitlab.
> Any further discussion at this point looks off topic, there are better
> venues for discussing the technical merits of email vs github/gitlab.

Is it me or are the top 3 people who objected to gitlab on vaccation, banned
and busy ?
Maybe we should wait for them to have an oppertunity to comment. One of them
happens to be an experienced gitlab admin

thx

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

Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.


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] 5 year plan & Inovation

[Michael Niedermayer]

On Sat, May 04, 2024 at 09:11:12AM +0800, flow gg wrote:
> I saw about comparing emails and gitlab/hub .., I did not comprehensively
> understand their advantages and disadvantages, but I want to say that I
> support it to change to gitlab/hub
> 
> Simple reason:
> 
> If you need to use git-send-email, I may not be able to submit any code
> If you do not need to use git-send-email, it is troublesome for the
> reviewer and the contributor
> 
> In detail:
> 
> I have tried git-send-email, but it failed. You can say that I am stupid,
> but I would say that this is because of various reasons such as my area and
> the network. It is really not what I can solve.
> Maybe I will spend a lot of energy trying it in the future, but this is
> because I have submitted thousands of lines of code. I don't want to give
> up. If it is from the beginning, it will cause abandonment.

if anyone needs to install get-send-email see:
https://git-send-email.io/

if you cannot use get-send-email. (misconfigured corporate firewalls?, north 
korea?)
you can create patches using git format-patch
to turn the last 2 commits into patches
git format-patch -2

then attach the created files to your mail or 2 mails, or just copy and paste 
them
inline into mails. Make sure your mail client doesnt do word wraping or
other whitespace "cleanup"

Thats all there is to it. get-send-email is recommanded (because its very
easy normally) but git will work perfectly fine without it


> 
> Maybe I am younger here in FFMPEG. I have a lot of good young people around
> me. They all use github/lab by default, and there will be the same problem
> as me, resulting in abandonment.

if our guides about how to submit patches are bad, our guides need to be
fixed.

thx

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


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 4/5] avcodec/dovi_rpuenc: Initialize bl_compat_id

[Michael Niedermayer]

On Sat, May 04, 2024 at 12:21:03AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: CID1596607 Uninitialized scalar variable
> > 
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/dovi_rpuenc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
> > index 7e0292533bd..c5e452957b5 100644
> > --- a/libavcodec/dovi_rpuenc.c
> > +++ b/libavcodec/dovi_rpuenc.c
> > @@ -57,7 +57,7 @@ int ff_dovi_configure(DOVIContext *s, AVCodecContext 
> > *avctx)
> >  AVDOVIDecoderConfigurationRecord *cfg;
> >  const AVDOVIRpuDataHeader *hdr = NULL;
> >  const AVFrameSideData *sd;
> > -int dv_profile, dv_level, bl_compat_id;
> > +int dv_profile, dv_level, bl_compat_id = -1;
> >  size_t cfg_size;
> >  uint64_t pps;
> >  
> 
[...]
> default case is never taken); but if you do this, then you can also
> remove the other "bl_compat_id = -1" assignments (which conveys that
> everything is treated as invalid unless we found it to have a valid
> compatibility id).

will apply with the other bl_compat_id = -1 removed

thx

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 02/10] lavc/vp8dsp: R-V V put_bilin_h

[Rémi Denis-Courmont]

Le lauantaina 4. toukokuuta 2024, 21.02.25 EEST Rémi Denis-Courmont a écrit :
> Le lauantaina 4. toukokuuta 2024, 17.48.31 EEST u...@foxmail.com a écrit :
> > From: sunyuechi 
> > 
> > C908:
> > vp8_put_bilin4_h_c: 373.5
> > vp8_put_bilin4_h_rvv_i32: 158.7
> > vp8_put_bilin8_h_c: 1437.7
> > vp8_put_bilin8_h_rvv_i32: 318.7
> > vp8_put_bilin16_h_c: 2845.7
> > vp8_put_bilin16_h_rvv_i32: 374.7
> > ---
> > 
> >  libavcodec/riscv/vp8dsp_init.c | 11 +++
> >  libavcodec/riscv/vp8dsp_rvv.S  | 54 ++
> >  2 files changed, 65 insertions(+)
> > 
> > diff --git a/libavcodec/riscv/vp8dsp_init.c
> > b/libavcodec/riscv/vp8dsp_init.c index c364de3dc9..32cb4893a4 100644
> > --- a/libavcodec/riscv/vp8dsp_init.c
> > +++ b/libavcodec/riscv/vp8dsp_init.c
> > @@ -34,6 +34,10 @@ VP8_EPEL(16, rvv);
> > 
> >  VP8_EPEL(8,  rvv);
> >  VP8_EPEL(4,  rvv);
> > 
> > +VP8_BILIN(16, rvv);
> > +VP8_BILIN(8,  rvv);
> > +VP8_BILIN(4,  rvv);
> > +
> > 
> >  av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
> >  {
> >  #if HAVE_RVV
> > 
> > @@ -47,6 +51,13 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
> > 
> >  c->put_vp8_bilinear_pixels_tab[0][0][0] =
> >  ff_put_vp8_pixels16_rvv;
> >  c->put_vp8_bilinear_pixels_tab[1][0][0] = ff_put_vp8_pixels8_rvv;
> >  c->put_vp8_bilinear_pixels_tab[2][0][0] = ff_put_vp8_pixels4_rvv;
> > 
> > +
> > +c->put_vp8_bilinear_pixels_tab[0][0][1] =
> > ff_put_vp8_bilin16_h_rvv; +   
> > c->put_vp8_bilinear_pixels_tab[0][0][2] =
> > ff_put_vp8_bilin16_h_rvv; +c->put_vp8_bilinear_pixels_tab[1][0][1]
> > = ff_put_vp8_bilin8_h_rvv; +   
> > c->put_vp8_bilinear_pixels_tab[1][0][2]
> > = ff_put_vp8_bilin8_h_rvv; +   
> > c->put_vp8_bilinear_pixels_tab[2][0][1]
> > = ff_put_vp8_bilin4_h_rvv; +   
> > c->put_vp8_bilinear_pixels_tab[2][0][2]
> > = ff_put_vp8_bilin4_h_rvv; }
> > 
> >  #endif
> >  }
> > 
> > diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
> > index 063ab7110c..c8d265e516 100644
> > --- a/libavcodec/riscv/vp8dsp_rvv.S
> > +++ b/libavcodec/riscv/vp8dsp_rvv.S
> > @@ -98,3 +98,57 @@ func ff_put_vp8_pixels4_rvv, zve32x
> > 
> >  vsetivli  zero, 4, e8, mf4, ta, ma
> >  put_vp8_pixels
> >  
> >  endfunc
> > 
> > +
> > +.macro bilin_h_load dst len
> > +.ifc \len,4
> > +vsetivlizero, 5, e8, mf2, ta, ma
> > +.elseif \len == 8
> > +vsetivlizero, 9, e8, m1, ta, ma
> > +.else
> > +vsetivlizero, 17, e8, m2, ta, ma
> > +.endif
> 
> It might be worth defining a pseudo-instruction macro in asm.S that would
> statically compute the minimal LMUL from just the AVL and SEW. Then we don't
> to repeat these if blocks times and again, we can just do:
> 
> vsetvlstatic \len + 1, e8
> 
> or something like that

On second thought, concealing the LMUL from the programmer is perhaps not the 
smartest idea, since it heavily constrains register allocation.

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



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

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

Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation

[Vittorio Giovara]

On Sat, May 4, 2024 at 9:06 AM Ondřej Fiala  wrote:

> On Sat May 4, 2024 at 3:11 AM CEST, flow gg wrote:
> > I have tried git-send-email, but it failed. You can say that I am stupid,
> > but I would say that this is because of various reasons such as my area
> and
> > the network. It is really not what I can solve.
> > Maybe I will spend a lot of energy trying it in the future, but this is
> > because I have submitted thousands of lines of code. I don't want to give
> > up. If it is from the beginning, it will cause abandonment.
> >
> > Maybe I am younger here in FFMPEG. I have a lot of good young people
> around
> > me. They all use github/lab by default, and there will be the same
> problem
> > as me, resulting in abandonment.
> I feel it's worth pointing out that SourceHut and mailing list-based
> workflows
> are becoming popular in some young-dev circles. I am in my twenties for
> reference.
>
> With that said, I did not realize how problematic setting up git send-email
> can be with some providers when I wrote what you're replying to. The
> replies
> quite surprised me honestly because when I first set up git send-email, I
> was using completely average providers and it was all pretty effortless,
> I just adjusted git's config and it worked perfectly.
>
> > I don't really care about the quality between these tools. I think people
> > are important. I only want to use it, and I can facilitate the real
> > reviewer of Review.
> >
> > I don't know if I can say my personal feelings here, but I will say:
> >
> > I feel despised by this passage, which makes me uncomfortable. If you
> are a
> > reviewer, maybe I have no chance to contribute, but anyway, I have made
> > some contributions.
> >
> > > How can anyone use git, but not git send-email? Any decent email
> provider
> > > has support for external clients over SMTP. And I believe you *can*
>
> > > actually dictate that people don't attach patches -- if you have
> control
> > > over the mailing list software, you can set up a filter that rejects
> such
> > > emails and auto-replies with instructions on how to send them properly.
> > I think I should have the right to contribute
> Likewise.
>
> Regarding the part about rejecting patches as attachments, I was
> specifically
> reacting to Rémi claiming that he can't dictate that people don't use them,
> which technically he can. I never said it's a good idea, though it might
> have
> sounded that way. Sorry about that.
>
> As I said multiple times, I feel like contributing over email is a lot
> about
> having good tooling. For example, the email client I use treats all parts
> of
> a multipart message the same, so it has no issues replying to text
> attachments
> instead of the message body. As such, there is no difference between
> attached
> patches and patches in the message body with such a client.
>

Is it me or has this thread and topic run its course?
We understand your preference is email and it is duly noted, the
overwhelming majority of the community still seem to prefer github/gitlab.
Any further discussion at this point looks off topic, there are better
venues for discussing the technical merits of email vs github/gitlab.
-- 
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 02/10] lavc/vp8dsp: R-V V put_bilin_h

[Rémi Denis-Courmont]

Le lauantaina 4. toukokuuta 2024, 17.48.31 EEST u...@foxmail.com a écrit :
> From: sunyuechi 
> 
> C908:
> vp8_put_bilin4_h_c: 373.5
> vp8_put_bilin4_h_rvv_i32: 158.7
> vp8_put_bilin8_h_c: 1437.7
> vp8_put_bilin8_h_rvv_i32: 318.7
> vp8_put_bilin16_h_c: 2845.7
> vp8_put_bilin16_h_rvv_i32: 374.7
> ---
>  libavcodec/riscv/vp8dsp_init.c | 11 +++
>  libavcodec/riscv/vp8dsp_rvv.S  | 54 ++
>  2 files changed, 65 insertions(+)
> 
> diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
> index c364de3dc9..32cb4893a4 100644
> --- a/libavcodec/riscv/vp8dsp_init.c
> +++ b/libavcodec/riscv/vp8dsp_init.c
> @@ -34,6 +34,10 @@ VP8_EPEL(16, rvv);
>  VP8_EPEL(8,  rvv);
>  VP8_EPEL(4,  rvv);
> 
> +VP8_BILIN(16, rvv);
> +VP8_BILIN(8,  rvv);
> +VP8_BILIN(4,  rvv);
> +
>  av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
>  {
>  #if HAVE_RVV
> @@ -47,6 +51,13 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
>  c->put_vp8_bilinear_pixels_tab[0][0][0] = ff_put_vp8_pixels16_rvv;
>  c->put_vp8_bilinear_pixels_tab[1][0][0] = ff_put_vp8_pixels8_rvv;
>  c->put_vp8_bilinear_pixels_tab[2][0][0] = ff_put_vp8_pixels4_rvv;
> +
> +c->put_vp8_bilinear_pixels_tab[0][0][1] = ff_put_vp8_bilin16_h_rvv;
> +c->put_vp8_bilinear_pixels_tab[0][0][2] =
> ff_put_vp8_bilin16_h_rvv; +c->put_vp8_bilinear_pixels_tab[1][0][1]
> = ff_put_vp8_bilin8_h_rvv; +c->put_vp8_bilinear_pixels_tab[1][0][2]
> = ff_put_vp8_bilin8_h_rvv; +c->put_vp8_bilinear_pixels_tab[2][0][1]
> = ff_put_vp8_bilin4_h_rvv; +c->put_vp8_bilinear_pixels_tab[2][0][2]
> = ff_put_vp8_bilin4_h_rvv; }
>  #endif
>  }
> diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
> index 063ab7110c..c8d265e516 100644
> --- a/libavcodec/riscv/vp8dsp_rvv.S
> +++ b/libavcodec/riscv/vp8dsp_rvv.S
> @@ -98,3 +98,57 @@ func ff_put_vp8_pixels4_rvv, zve32x
>  vsetivli  zero, 4, e8, mf4, ta, ma
>  put_vp8_pixels
>  endfunc
> +
> +.macro bilin_h_load dst len
> +.ifc \len,4
> +vsetivlizero, 5, e8, mf2, ta, ma
> +.elseif \len == 8
> +vsetivlizero, 9, e8, m1, ta, ma
> +.else
> +vsetivlizero, 17, e8, m2, ta, ma
> +.endif

It might be worth defining a pseudo-instruction macro in asm.S that would 
statically compute the minimal LMUL from just the AVL and SEW. Then we don't 
to repeat these if blocks times and again, we can just do:

vsetvlstatic \len + 1, e8

or something like that

> +
> +vle8.v  \dst, (a2)
> +vslide1down.vx  v2, \dst, t5
> +
> +.ifc \len,4
> +vsetivlizero, 4, e8, mf4, ta, ma
> +.elseif \len == 8
> +vsetivlizero, 8, e8, mf2, ta, ma
> +.else
> +vsetivlizero, 16, e8, m1, ta, ma
> +.endif
> +
> +vwmulu.vx   v28, \dst, t1
> +vwmaccu.vx  v28, a5, v2
> +vwaddu.wx   v24, v28, t4
> +vnsra.wi\dst, v24, 3
> +.endm
> +
> +.macro put_vp8_bilin_h len
> +li  t1, 8
> +li  t4, 4
> +li  t5, 1
> +sub t1, t1, a5
> +1:
> +addia4, a4, -1
> +bilin_h_loadv0, \len
> +vse8.v  v0, (a0)
> +add a2, a2, a3
> +add a0, a0, a1
> +bneza4, 1b
> +
> +ret
> +.endm

FWIW, it should be possible to include func and endfunc in the macro too.

> +
> +func ff_put_vp8_bilin16_h_rvv, zve32x
> +put_vp8_bilin_h 16
> +endfunc
> +
> +func ff_put_vp8_bilin8_h_rvv, zve32x
> +put_vp8_bilin_h 8
> +endfunc
> +
> +func ff_put_vp8_bilin4_h_rvv, zve32x
> +put_vp8_bilin_h 4
> +endfunc


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



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

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

Re: [FFmpeg-devel] [PATCH 01/10] lavc/vp8dsp: R-V V put_vp8_pixels

[Rémi Denis-Courmont]

Le lauantaina 4. toukokuuta 2024, 17.48.30 EEST u...@foxmail.com a écrit :
> From: sunyuechi 
> 
> C908:
> vp8_put_pixels4_c: 87.5
> vp8_put_pixels4_rvv_i32: 42.7
> vp8_put_pixels8_c: 284.5
> vp8_put_pixels8_rvv_i32: 77.7
> vp8_put_pixels16_c: 1087.7
> vp8_put_pixels16_rvv_i32: 108.0
> ---
>  libavcodec/riscv/vp8dsp.h  | 75 ++
>  libavcodec/riscv/vp8dsp_init.c | 22 ++
>  libavcodec/riscv/vp8dsp_rvv.S  | 27 
>  libavcodec/vp8dsp.c|  2 +
>  libavcodec/vp8dsp.h|  1 +
>  5 files changed, 127 insertions(+)
>  create mode 100644 libavcodec/riscv/vp8dsp.h
> 
> diff --git a/libavcodec/riscv/vp8dsp.h b/libavcodec/riscv/vp8dsp.h
> new file mode 100644
> index 00..971c5c0a96
> --- /dev/null
> +++ b/libavcodec/riscv/vp8dsp.h
> @@ -0,0 +1,75 @@
> +/*
> + * 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 AVCODEC_RISCV_VP8DSP_H
> +#define AVCODEC_RISCV_VP8DSP_H
> +
> +#include "libavcodec/vp8dsp.h"
> +
> +#define VP8_LF_Y(hv, inner, opt)   
>  \ +void ff_vp8_##hv##_loop_filter16##inner##_##opt(uint8_t *dst,  
>  \ +ptrdiff_t
> stride,\ +int
> flim_E, int flim_I,  \ +   
> int hev_thresh) +
> +#define VP8_LF_UV(hv, inner, opt)  
>  \ +void ff_vp8_##hv##_loop_filter8uv##inner##_##opt(uint8_t *dstU,
>  \ + uint8_t *dstV,
>  \ + ptrdiff_t
> stride,   \ + int
> flim_E, int flim_I, \ +
> int hev_thresh) +
> +#define VP8_LF_SIMPLE(hv, opt)  \
> +void ff_vp8_##hv##_loop_filter16_simple_##opt(uint8_t *dst, \
> +  ptrdiff_t stride, \
> +  int flim)
> +
> +#define VP8_LF_HV(inner, opt)   \
> +VP8_LF_Y(h,  inner, opt);   \
> +VP8_LF_Y(v,  inner, opt);   \
> +VP8_LF_UV(h, inner, opt);   \
> +VP8_LF_UV(v, inner, opt)
> +
> +#define VP8_LF(opt) \
> +VP8_LF_HV(,   opt); \
> +VP8_LF_HV(_inner, opt); \
> +VP8_LF_SIMPLE(h, opt);  \
> +VP8_LF_SIMPLE(v, opt)
> +
> +#define VP8_MC(n, opt)  \
> +void ff_put_vp8_##n##_##opt(uint8_t *dst, ptrdiff_t dststride,  \
> +const uint8_t *src, ptrdiff_t srcstride,\
> +int h, int x, int y)
> +
> +#define VP8_EPEL(w, opt)\
> +VP8_MC(pixels ## w, opt);   \
> +VP8_MC(epel ## w ## _h4, opt);  \
> +VP8_MC(epel ## w ## _h6, opt);  \
> +VP8_MC(epel ## w ## _v4, opt);  \
> +VP8_MC(epel ## w ## _h4v4, opt);\
> +VP8_MC(epel ## w ## _h6v4, opt);\
> +VP8_MC(epel ## w ## _v6, opt);  \
> +VP8_MC(epel ## w ## _h4v6, opt);\
> +VP8_MC(epel ## w ## _h6v6, opt)
> +
> +#define VP8_BILIN(w, opt)   \
> +VP8_MC(bilin ## w ## _h, opt);  \
> +VP8_MC(bilin ## w ## _v, opt);  \
> +VP8_MC(bilin ## w ## _hv, opt)
> +
> +#endif /* AVCODEC_RISCV_VP8DSP_H */
> diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
> index af57aabb71..c364de3dc9 100644
> --- a/libavcodec/riscv/vp8dsp_init.c
> +++ b/libavcodec/riscv/vp8dsp_init.c
> @@ -24,11 +24,33 @@
>  #include "libavutil/cpu.h"
>  #include "libavutil/riscv/cpu.h"
>  #include "libavcodec/vp8dsp.h"
> +#include "vp8dsp.h"
> 
>  void ff_vp8_idct_dc_add_rvv(uint8_t *dst, int16_t block[16], ptrdiff_t
> stride); void ff_vp8_idct_dc_add4y_rvv(uint8_t *dst, int16_t block[4][16],
> ptrdiff_t 

Re: [FFmpeg-devel] [PATCH] lavc/vc1dsp: R-V V mspel_pixels

[Rémi Denis-Courmont]

Le lauantaina 4. toukokuuta 2024, 13.01.05 EEST u...@foxmail.com a écrit :
> From: sunyuechi 
> 
> vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_c: 869.7
> vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_rvv_i32: 148.7
> vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_c: 220.5
> vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_rvv_i64: 56.2
> vc1dsp.put_vc1_mspel_pixels_tab[0][0]_c: 523.7
> vc1dsp.put_vc1_mspel_pixels_tab[0][0]_rvv_i32: 82.0
> vc1dsp.put_vc1_mspel_pixels_tab[1][0]_c: 138.5
> vc1dsp.put_vc1_mspel_pixels_tab[1][0]_rvv_i64: 23.7
> ---
>  libavcodec/riscv/vc1dsp_init.c |  8 +
>  libavcodec/riscv/vc1dsp_rvv.S  | 66 ++
>  2 files changed, 74 insertions(+)
> 
> diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
> index e47b644f80..610c43a1a3 100644
> --- a/libavcodec/riscv/vc1dsp_init.c
> +++ b/libavcodec/riscv/vc1dsp_init.c
> @@ -29,6 +29,10 @@ void ff_vc1_inv_trans_8x8_dc_rvv(uint8_t *dest, ptrdiff_t
> stride, int16_t *block 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); +void ff_put_pixels16x16_rvv(uint8_t *dst, const uint8_t *src,
> ptrdiff_t line_size, int rnd); +void ff_put_pixels8x8_rvv(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); +void ff_avg_pixels8x8_rvv(uint8_t *dst, const uint8_t
> *src, ptrdiff_t line_size, int rnd);
> 
>  av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
>  {
> @@ -38,9 +42,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
>  if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
>  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->put_vc1_mspel_pixels_tab[0][0] = ff_put_pixels16x16_rvv;
> +dsp->avg_vc1_mspel_pixels_tab[0][0] = ff_avg_pixels16x16_rvv;
>  if (flags & AV_CPU_FLAG_RVV_I64) {
>  dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
>  dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
> +dsp->put_vc1_mspel_pixels_tab[1][0] = ff_put_pixels8x8_rvv;
> +dsp->avg_vc1_mspel_pixels_tab[1][0] = ff_avg_pixels8x8_rvv;
>  }
>  }
>  #endif
> diff --git a/libavcodec/riscv/vc1dsp_rvv.S b/libavcodec/riscv/vc1dsp_rvv.S
> index 4a00945ead..48244f91aa 100644
> --- a/libavcodec/riscv/vc1dsp_rvv.S
> +++ b/libavcodec/riscv/vc1dsp_rvv.S
> @@ -111,3 +111,69 @@ func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
>  vsse32.v  v0, (a0), a1
>  ret
>  endfunc
> +
> +func ff_put_pixels16x16_rvv, zve32x
> +vsetivli  zero, 16, e8, m1, ta, ma
> +.irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
> +vle8.vv\n, (a1)
> +add   a1, a1, a2
> +.endr
> +vle8.vv31, (a1)

Is it not faster to compute the address ahead of time, e.g.:

add t1, a2, a1
vle8.v vN, (a1)
sh1add a1, a2, a1
vle8.v vN+1, (t1)

...and so on? Even on a reordering core, you can't eliminate stall on data 
dependency if there is nothing else to be done.

(Ditto below and in other patches.)

> +.irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
> +vse8.vv\n, (a0)
> +add   a0, a0, a2
> +.endr
> +vse8.vv31, (a0)
> +
> +ret
> +endfunc
> +
> +func ff_put_pixels8x8_rvv, zve64x
> +vsetivli  zero, 8, e8, mf2, ta, ma
> +vlse64.v  v8, (a1), a2
> +vsse64.v  v8, (a0), a2

Copying 64-bit quantities should not need RVV at all. Maybe the C version 
needs to be improved instead, but if that is not possible, then an RVI version 
may be more portable and work just as well.

> +
> +ret
> +endfunc
> +
> +func ff_avg_pixels16x16_rvv, zve32x
> +csrwi vxrm, 0
> +vsetivli  zero, 16, e8, m1, ta, ma
> +lit0, 128
> +
> +.irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
> +vle8.vv\n, (a1)
> +add   a1, a1, a2
> +.endr
> +vle8.vv31, (a1)
> +.irp n 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
> +vle8.vv\n, (a0)
> +add   a0, a0, a2
> +.endr
> +vle8.vv15, (a0)
> +vsetvli   zero, t0, e8, m8, ta, ma
> +vaaddu.vv v0, v0, v16
> +vaaddu.vv v8, v8, v24
> +vsetivli  zero, 16, e8, m1, ta, ma
> +.irp n  15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
> +vse8.vv\n, (a0)
> +sub   a0, a0, a2
> +.endr
> +vse8.vv0, (a0)
> +
> +ret
> +endfunc
> +
> +func ff_avg_pixels8x8_rvv, zve64x

Re: [FFmpeg-devel] [PATCH v3] avformat/framecrcenc: compute the checksum for side data

[Marton Balint]

On Sat, 4 May 2024, James Almer wrote:


On 5/4/2024 5:34 AM, Marton Balint wrote:



 On Thu, 2 May 2024, James Almer wrote:


 On 5/2/2024 6:23 PM, Marton Balint wrote:



  On Wed, 1 May 2024, Michael Niedermayer wrote:


  This allows detecting issues in side data related code, same as what
  framecrc does for before already for packet data itself.

  This basically reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e57.


  Can you at least add an option which allows disabling dumping the side
  data? Changing the format of framecrc output again and again is not
 very 


 The framehash/framemd5 muxer is versioned, which is what you should use
 if you want parseable output.


 Okay, but then the question is that why framecrc is using different code
 and options?


Originally it was framecrc (using AVAdler) and framemd5 (using AVMD5). The 
latter was renamed/aliased to framehash and made to use the AVHash API, which 
supports all lavu hashing algorithms, and is versioned.
If anyone cared, framecrc could be also made into an alias of framehash that 
defaults to adler32 output, but it would result in a massive change to 
reference files, if anything because AVHash initializes adler32 with a 1 
whereas framecrc does it with a 0.


If we are changing the output format, we might as well change this as 
well...


Framehash also has side data hashing, so making framecrc output 
arch-indenpendent but not framehash would be a bit inconsistent.


Regards,
Marton
___
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] G729 encoding

[Stefano Sabatini]

On date Monday 2024-04-29 09:37:34 +, Marco Garbin wrote:
> Hi to all,
> when will be available the g729 encoding features ?

As soon as someone is going to implement and submit it.
As a start, you might create a ticket to track its status.

Also, you might consider sponsoring a developer/company to provide this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] fftools/ffprobe: Avoid overflow when calculating DAR

[Stefano Sabatini]

On date Friday 2024-05-03 17:36:23 +0100, Derek Buitenhuis wrote:
> Both the codecpar's width and height, and the SAR num and den are
> ints, which can overflow. Cast to int64_t, which is what av_reduce
> takes.
> 
> Without this, occasionally, display_aspect_ratio can be negative in
> ffprobe's -show_stream output.
> 
> Signed-off-by: Derek Buitenhuis 
> ---
>  fftools/ffprobe.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index 0d4cd0b048..5b40dad527 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@ -3324,8 +3324,8 @@ static int show_stream(WriterContext *w, 
> AVFormatContext *fmt_ctx, int stream_id
>  if (sar.num) {
>  print_q("sample_aspect_ratio", sar, ':');
>  av_reduce(, ,
> -  par->width  * sar.num,
> -  par->height * sar.den,
> +  (int64_t) par->width  * sar.num,
> +  (int64_t) par->height * sar.den,
>1024*1024);
>  print_q("display_aspect_ratio", dar, ':');
>  } else {

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

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

Re: [FFmpeg-devel] [REFUND-REQUEST] Vulkan F2F travel

[Stefano Sabatini]

On date Saturday 2024-04-27 14:16:36 +0200, Lynne wrote:
> Hi,
> 
> I'm requesting a reimbursement for attending the Khronos F2F
> event in Brussels on 2024-04-26, where I gave a talk about the
> current status of Vulkan Video integration into FFmpeg:
>  - Currently implemented decoding features
>  - What we would like to be improved (stability, speed and testing from all 
> vendors)
>  - Currently implemented WIP encoding features
>  - What we would need to implement in order to match nvenc in terms of 
> quality on most vendors
> 
> Also, I collaborated on future extensions to the standard,
> and discussed AV1 issues recently found in the specifications
> and how we could fix them.
> 
> 95 GBP: Eurostar to Bruxelle-Midi
> 95 GBP: Eurostar from Bruxelle-Midi
> Total: 190 GBP

Looks good to me, thanks and sorry for the delay.
___
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 2/2] avcodec: add external dec libvvdec for H266/VVC

[Andreas Rheinhardt]

Christian:
> +FFCodec ff_libvvdec_decoder = {
> +.p.name = "libvvdec",
> +CODEC_LONG_NAME("H.266 / VVC Decoder VVdeC"),
> +.p.type = AVMEDIA_TYPE_VIDEO,
> +.p.id    = AV_CODEC_ID_VVC,

We prefer patches that actually compile.

> +.p.capabilities = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_OTHER_THREADS,
> +.p.profiles = NULL_IF_CONFIG_SMALL(ff_vvc_profiles),
> +.p.priv_class   = _libvvdec,

___
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] avformat/framecrcenc: compute the checksum for side data

[James Almer]

On 5/4/2024 5:34 AM, Marton Balint wrote:



On Thu, 2 May 2024, James Almer wrote:


On 5/2/2024 6:23 PM, Marton Balint wrote:



 On Wed, 1 May 2024, Michael Niedermayer wrote:


 This allows detecting issues in side data related code, same as what
 framecrc does for before already for packet data itself.

 This basically reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e57.


 Can you at least add an option which allows disabling dumping the side
 data? Changing the format of framecrc output again and again is not 
very 


The framehash/framemd5 muxer is versioned, which is what you should 
use if you want parseable output.


Okay, but then the question is that why framecrc is using different code 
and options?


Originally it was framecrc (using AVAdler) and framemd5 (using AVMD5). 
The latter was renamed/aliased to framehash and made to use the AVHash 
API, which supports all lavu hashing algorithms, and is versioned.
If anyone cared, framecrc could be also made into an alias of framehash 
that defaults to adler32 output, but it would result in a massive change 
to reference files, if anything because AVHash initializes adler32 with 
a 1 whereas framecrc does it with a 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 v2 2/2] avcodec: add external dec libvvdec for H266/VVC

[Christian]

Add external decoder VVdeC for H266/VVC decoding.
Register new decoder libvvdec.
Add vvc_parse_extradata to support parse/probe of vvcC stream input.
Add vvc_paramset that implements the parser of vvcC configuration boxes.
Add libvvdec to wrap the vvdec interface.
Enable decoder by adding --enable-libvvdec in configure step.

Co-authored-by: Christian Bartnik chris1031...@gmail.com 

Signed-off-by: Christian Bartnik mailto:chris1031...@gmail.com>>
---
configure  |   5 +
libavcodec/Makefile|   1 +
libavcodec/allcodecs.c |   1 +
libavcodec/libvvdec.c  | 617 +
4 files changed, 624 insertions(+)
create mode 100644 libavcodec/libvvdec.c

diff --git a/configure b/configure
index cb312d9c73..a7a9da3276 100755
--- a/configure
+++ b/configure
@@ -294,6 +294,7 @@ External library support:
   native implementation exists [no]
  --enable-libvpx  enable VP8 and VP9 de/encoding via libvpx [no]
  --enable-libvvencenable H.266/VVC encoding via vvenc [no]
+  --enable-libvvdecenable H.266/VVC decoding via vvdec [no]
  --enable-libwebp enable WebP encoding via libwebp [no]
  --enable-libx264 enable H.264 encoding via x264 [no]
  --enable-libx265 enable HEVC encoding via x265 [no]
@@ -1968,6 +1969,7 @@ EXTERNAL_LIBRARY_LIST="
libvorbis
libvpx
libvvenc
+libvvdec
libwebp
libxevd
libxeve
@@ -3551,6 +3553,8 @@ libvpx_vp8_encoder_deps="libvpx"
libvpx_vp9_decoder_deps="libvpx"
libvpx_vp9_encoder_deps="libvpx"
libvvenc_encoder_deps="libvvenc"
+libvvdec_decoder_deps="libvvdec"
+libvvdec_decoder_select="vvc_mp4toannexb_bsf"
libwebp_encoder_deps="libwebp"
libwebp_anim_encoder_deps="libwebp"
libx262_encoder_deps="libx262"
@@ -7014,6 +7018,7 @@ enabled libvpx&& {
fi
}
enabled libvvenc  && require_pkg_config libvvenc "libvvenc >= 1.6.1" 
"vvenc/vvenc.h" vvenc_get_version
+enabled libvvdec  && require_pkg_config libvvdec "libvvdec >= 1.6.0" 
"vvdec/vvdec.h" vvdec_get_version

enabled libwebp   && {
enabled libwebp_encoder  && require_pkg_config libwebp "libwebp >= 
0.2.0" webp/encode.h WebPGetEncoderVersion
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 54d85f6aaa..851b62179d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1156,6 +1156,7 @@ OBJS-$(CONFIG_LIBVPX_VP8_ENCODER)   += libvpxenc.o
OBJS-$(CONFIG_LIBVPX_VP9_DECODER) += libvpxdec.o
OBJS-$(CONFIG_LIBVPX_VP9_ENCODER) += libvpxenc.o
OBJS-$(CONFIG_LIBVVENC_ENCODER)   += libvvenc.o
+OBJS-$(CONFIG_LIBVVDEC_DECODER)   += libvvdec.o
OBJS-$(CONFIG_LIBWEBP_ENCODER)+= libwebpenc_common.o libwebpenc.o
OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER)   += libwebpenc_common.o 
libwebpenc_animencoder.o
OBJS-$(CONFIG_LIBX262_ENCODER)+= libx264.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index bb2c3ce017..9e0ad00b23 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -802,6 +802,7 @@ extern const FFCodec ff_libvpx_vp8_decoder;
extern FFCodec ff_libvpx_vp9_encoder;
extern const FFCodec ff_libvpx_vp9_decoder;
extern const FFCodec ff_libvvenc_encoder;
+extern const FFCodec ff_libvvdec_decoder;
/* preferred over libwebp */
extern const FFCodec ff_libwebp_anim_encoder;
extern const FFCodec ff_libwebp_encoder;
diff --git a/libavcodec/libvvdec.c b/libavcodec/libvvdec.c
new file mode 100644
index 00..7f94a81b37
--- /dev/null
+++ b/libavcodec/libvvdec.c
@@ -0,0 +1,617 @@
+/*
+ * H.266 decoding using the VVdeC library
+ *
+ * Copyright (C) 2022, Thomas Siedel
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config_components.h"
+
+#include 
+
+#include "libavutil/common.h"
+#include "libavutil/avutil.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/frame.h"
+#include "libavutil/mastering_display_metadata.h"
+#include "libavutil/log.h"
+
+#include "avcodec.h"
+#include "codec_internal.h"
+#include "decode.h"
+#include "internal.h"
+#include "profiles.h"
+
+#include "cbs_h266.h"
+
+typedef struct VVdeCContext {
+AVClass  *av_class;
+vvdecDecoder 

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

[Christian]

Add external encoder VVenC for H266/VVC encoding.
Register new encoder libvvenc.
Add libvvenc to wrap the vvenc interface.
libvvenc implements encoder option: preset,qp,period,subjopt,
vvenc-params,levelidc,tier.
Enable encoder by adding --enable-libvvenc in configure step.

Co-authored-by: Christian Bartnik chris1031...@gmail.com 

Signed-off-by: Christian Bartnik mailto:chris1031...@gmail.com>>
---
configure  |   4 +
libavcodec/Makefile|   1 +
libavcodec/allcodecs.c |   1 +
libavcodec/libvvenc.c  | 501 +
4 files changed, 507 insertions(+)
create mode 100644 libavcodec/libvvenc.c

diff --git a/configure b/configure
index ed74583a6f..cb312d9c73 100755
--- a/configure
+++ b/configure
@@ -293,6 +293,7 @@ External library support:
  --enable-libvorbis   enable Vorbis en/decoding via libvorbis,
   native implementation exists [no]
  --enable-libvpx  enable VP8 and VP9 de/encoding via libvpx [no]
+  --enable-libvvencenable H.266/VVC encoding via vvenc [no]
  --enable-libwebp enable WebP encoding via libwebp [no]
  --enable-libx264 enable H.264 encoding via x264 [no]
  --enable-libx265 enable HEVC encoding via x265 [no]
@@ -1966,6 +1967,7 @@ EXTERNAL_LIBRARY_LIST="
libvmaf
libvorbis
libvpx
+libvvenc
libwebp
libxevd
libxeve
@@ -3548,6 +3550,7 @@ libvpx_vp8_decoder_deps="libvpx"
libvpx_vp8_encoder_deps="libvpx"
libvpx_vp9_decoder_deps="libvpx"
libvpx_vp9_encoder_deps="libvpx"
+libvvenc_encoder_deps="libvvenc"
libwebp_encoder_deps="libwebp"
libwebp_anim_encoder_deps="libwebp"
libx262_encoder_deps="libx262"
@@ -7010,6 +7013,7 @@ enabled libvpx&& {
die "libvpx enabled but no supported decoders found"
fi
}
+enabled libvvenc  && require_pkg_config libvvenc "libvvenc >= 1.6.1" 
"vvenc/vvenc.h" vvenc_get_version

enabled libwebp   && {
enabled libwebp_encoder  && require_pkg_config libwebp "libwebp >= 
0.2.0" webp/encode.h WebPGetEncoderVersion
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index cff6347bdb..54d85f6aaa 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1155,6 +1155,7 @@ OBJS-$(CONFIG_LIBVPX_VP8_DECODER)   += libvpxdec.o
OBJS-$(CONFIG_LIBVPX_VP8_ENCODER) += libvpxenc.o
OBJS-$(CONFIG_LIBVPX_VP9_DECODER) += libvpxdec.o
OBJS-$(CONFIG_LIBVPX_VP9_ENCODER) += libvpxenc.o
+OBJS-$(CONFIG_LIBVVENC_ENCODER)   += libvvenc.o
OBJS-$(CONFIG_LIBWEBP_ENCODER)+= libwebpenc_common.o libwebpenc.o
OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER)   += libwebpenc_common.o 
libwebpenc_animencoder.o
OBJS-$(CONFIG_LIBX262_ENCODER)+= libx264.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f4705651fb..bb2c3ce017 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -801,6 +801,7 @@ extern const FFCodec ff_libvpx_vp8_encoder;
extern const FFCodec ff_libvpx_vp8_decoder;
extern FFCodec ff_libvpx_vp9_encoder;
extern const FFCodec ff_libvpx_vp9_decoder;
+extern const FFCodec ff_libvvenc_encoder;
/* preferred over libwebp */
extern const FFCodec ff_libwebp_anim_encoder;
extern const FFCodec ff_libwebp_encoder;
diff --git a/libavcodec/libvvenc.c b/libavcodec/libvvenc.c
new file mode 100644
index 00..c459273f44
--- /dev/null
+++ b/libavcodec/libvvenc.c
@@ -0,0 +1,501 @@
+/*
+ * H.266 encoding using the VVenC library
+ *
+ * Copyright (C) 2022, Thomas Siedel
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config_components.h"
+
+#include 
+#include 
+#include 
+
+#include "avcodec.h"
+#include "codec_internal.h"
+#include "encode.h"
+#include "internal.h"
+#include "packet_internal.h"
+#include "profiles.h"
+
+#include "libavutil/avutil.h"
+#include "libavutil/mem.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "libavutil/common.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/frame.h"
+#include "libavutil/log.h"
+
+typedef struct VVenCOptions {
+int preset; // preset 0: faster  4: slower
+int qp; // quantization parameter 0-63
+int subjectiveOptimization; // perceptually motivated QP 

Re: [FFmpeg-devel] [PATCH 01/10] lavc/vp9dsp: R-V V ipred vert

[flow gg]

the github link: https://github.com/hleft/FFmpeg/tree/vp9

 于2024年5月4日周六 23:03写道：

> From: sunyuechi 
>
> C908:
> vp9_vert_8x8_8bpp_c: 22.0
> vp9_vert_8x8_8bpp_rvv_i64: 18.5
> vp9_vert_16x16_8bpp_c: 71.2
> vp9_vert_16x16_8bpp_rvv_i32: 50.7
> vp9_vert_32x32_8bpp_c: 300.2
> vp9_vert_32x32_8bpp_rvv_i32: 136.7
> ---
>  libavcodec/riscv/vp9_intra_rvv.S | 35 
>  libavcodec/riscv/vp9dsp.h|  6 ++
>  libavcodec/riscv/vp9dsp_init.c   |  3 +++
>  3 files changed, 44 insertions(+)
>
> diff --git a/libavcodec/riscv/vp9_intra_rvv.S
> b/libavcodec/riscv/vp9_intra_rvv.S
> index db9774c263..b5f0f9d3c3 100644
> --- a/libavcodec/riscv/vp9_intra_rvv.S
> +++ b/libavcodec/riscv/vp9_intra_rvv.S
> @@ -113,3 +113,38 @@ func_dc dc_left  8   left 3  0  zve64x
>  func_dc dc_top   32  top  5  1  zve32x
>  func_dc dc_top   16  top  4  1  zve32x
>  func_dc dc_top   8   top  3  0  zve64x
> +
> +func ff_v_32x32_rvv, zve32x
> +vsetivli zero, 8, e8, mf2, ta, ma
> +vle32.v  v8, (a3)
> +
> +.rept 31
> +vse32.v  v8, (a0)
> +add  a0, a0, a1
> +.endr
> +vse32.v  v8, (a0)
> +
> +ret
> +endfunc
> +
> +func ff_v_16x16_rvv, zve32x
> +vsetivli zero, 4, e8, mf4, ta, ma
> +vle32.v  v8, (a3)
> +
> +.rept 15
> +vse32.v  v8, (a0)
> +add  a0, a0, a1
> +.endr
> +vse32.v  v8, (a0)
> +
> +ret
> +endfunc
> +
> +func ff_v_8x8_rvv, zve64x
> +ld   t0, (a3)
> +vsetivli zero, 8, e64, m4, ta, ma
> +vmv.v.x  v8, t0
> +vsse64.v v8, (a0), a1
> +
> +ret
> +endfunc
> diff --git a/libavcodec/riscv/vp9dsp.h b/libavcodec/riscv/vp9dsp.h
> index 25047ed507..113397ce86 100644
> --- a/libavcodec/riscv/vp9dsp.h
> +++ b/libavcodec/riscv/vp9dsp.h
> @@ -60,6 +60,12 @@ void ff_dc_129_16x16_rvv(uint8_t *dst, ptrdiff_t
> stride, const uint8_t *l,
>   const uint8_t *a);
>  void ff_dc_129_8x8_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
> const uint8_t *a);
> +void ff_v_32x32_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
> +const uint8_t *a);
> +void ff_v_16x16_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
> +const uint8_t *a);
> +void ff_v_8x8_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
> +  const uint8_t *a);
>
>  #define VP9_8TAP_RISCV_RVV_FUNC(SIZE, type, type_idx)
>  \
>  void ff_put_8tap_##type##_##SIZE##h_rvv(uint8_t *dst, ptrdiff_t
> dststride,   \
> diff --git a/libavcodec/riscv/vp9dsp_init.c
> b/libavcodec/riscv/vp9dsp_init.c
> index 69ab39004c..9c550d40b5 100644
> --- a/libavcodec/riscv/vp9dsp_init.c
> +++ b/libavcodec/riscv/vp9dsp_init.c
> @@ -36,6 +36,7 @@ static av_cold void
> vp9dsp_intrapred_init_rvv(VP9DSPContext *dsp, int bpp)
>  dsp->intra_pred[TX_8X8][DC_128_PRED] = ff_dc_128_8x8_rvv;
>  dsp->intra_pred[TX_8X8][DC_129_PRED] = ff_dc_129_8x8_rvv;
>  dsp->intra_pred[TX_8X8][TOP_DC_PRED] = ff_dc_top_8x8_rvv;
> +dsp->intra_pred[TX_8X8][VERT_PRED] = ff_v_8x8_rvv;
>  }
>
>  if (bpp == 8 && flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb()
> >= 16) {
> @@ -51,6 +52,8 @@ static av_cold void
> vp9dsp_intrapred_init_rvv(VP9DSPContext *dsp, int bpp)
>  dsp->intra_pred[TX_16X16][DC_129_PRED] = ff_dc_129_16x16_rvv;
>  dsp->intra_pred[TX_32X32][TOP_DC_PRED] = ff_dc_top_32x32_rvv;
>  dsp->intra_pred[TX_16X16][TOP_DC_PRED] = ff_dc_top_16x16_rvv;
> +dsp->intra_pred[TX_32X32][VERT_PRED] = ff_v_32x32_rvv;
> +dsp->intra_pred[TX_16X16][VERT_PRED] = ff_v_16x16_rvv;
>  }
>  #endif
>  }
> --
> 2.45.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 10/10] lavc/vp9dsp: R-V V mc tap hv

[uk7b]

From: sunyuechi 

C908:
vp9_avg_8tap_smooth_4hv_8bpp_c: 32.2
vp9_avg_8tap_smooth_4hv_8bpp_rvv_i64: 15.2
vp9_avg_8tap_smooth_8hv_8bpp_c: 98.5
vp9_avg_8tap_smooth_8hv_8bpp_rvv_i64: 23.5
vp9_avg_8tap_smooth_16hv_8bpp_c: 355.5
vp9_avg_8tap_smooth_16hv_8bpp_rvv_i64: 46.2
vp9_avg_8tap_smooth_32hv_8bpp_c: 1270.7
vp9_avg_8tap_smooth_32hv_8bpp_rvv_i64: 133.2
vp9_avg_8tap_smooth_64hv_8bpp_c: 4936.5
vp9_avg_8tap_smooth_64hv_8bpp_rvv_i64: 521.7
vp9_put_8tap_smooth_4hv_8bpp_c: 30.2
vp9_put_8tap_smooth_4hv_8bpp_rvv_i64: 14.2
vp9_put_8tap_smooth_8hv_8bpp_c: 91.5
vp9_put_8tap_smooth_8hv_8bpp_rvv_i64: 22.7
vp9_put_8tap_smooth_16hv_8bpp_c: 330.0
vp9_put_8tap_smooth_16hv_8bpp_rvv_i64: 45.0
vp9_put_8tap_smooth_32hv_8bpp_c: 1296.5
vp9_put_8tap_smooth_32hv_8bpp_rvv_i64: 131.0
vp9_put_8tap_smooth_64hv_8bpp_c: 4497.7
vp9_put_8tap_smooth_64hv_8bpp_rvv_i64: 513.2
---
 libavcodec/riscv/vp9_mc_rvv.S  | 79 ++
 libavcodec/riscv/vp9dsp_init.c |  3 +-
 2 files changed, 81 insertions(+), 1 deletion(-)

diff --git a/libavcodec/riscv/vp9_mc_rvv.S b/libavcodec/riscv/vp9_mc_rvv.S
index c8a42c7159..6ad7ea2433 100644
--- a/libavcodec/riscv/vp9_mc_rvv.S
+++ b/libavcodec/riscv/vp9_mc_rvv.S
@@ -446,12 +446,90 @@ endconst
 ret
 .endm
 
+.macro epel_hv_once len name do
+sub a2, a2, a3
+sub a2, a2, a3
+sub a2, a2, a3
+.irp n 0 2 4 6 8 10 12 14
+epel_load_inc   v\n \len put \name h 1 t
+.endr
+addia4, a4, -1
+1:
+addia4, a4, -1
+epel_load   v30 \len \do \name v 0 s
+vse8.v  v30, (a0)
+vmv.v.v v0, v2
+vmv.v.v v2, v4
+vmv.v.v v4, v6
+vmv.v.v v6, v8
+vmv.v.v v8, v10
+vmv.v.v v10, v12
+vmv.v.v v12, v14
+epel_load   v14 \len put \name h 1 t
+add a2, a2, a3
+add a0, a0, a1
+bneza4, 1b
+epel_load   v30 \len \do \name v 0 s
+vse8.v  v30, (a0)
+.endm
+
+.macro epel_hv do name len
+addisp, sp, -64
+.irp n 0,1,2,3,4,5,6,7
+sd  s\n, \n\()<<3(sp)
+.endr
+.ifc \len,64
+addisp, sp, -48
+.irp n 0,1,2,3,4,5
+sd  a\n, \n\()<<3(sp)
+.endr
+.endif
+.ifc \do,avg
+csrwi   vxrm, 0
+.endif
+epel_filter \name h t
+epel_filter \name v s
+.ifc \len,4
+vsetivlizero, 4, e8, mf4, ta, ma
+.elseif \len == 8
+vsetivlizero, 8, e8, mf2, ta, ma
+.elseif \len == 16
+vsetivlizero, 16, e8, m1, ta, ma
+.else
+li  a6, 32
+vsetvli zero, a6, e8, m2, ta, ma
+.endif
+epel_hv_once\len \name \do
+.ifc \len,64
+.irp n 0,1,2,3,4,5
+ld  a\n, \n\()<<3(sp)
+.endr
+addisp, sp, 48
+addia0, a0, 32
+addia2, a2, 32
+epel_filter \name h t
+epel_hv_once\len \name \do
+.endif
+.irp n 0,1,2,3,4,5,6,7
+ld  s\n, \n\()<<3(sp)
+.endr
+addisp, sp, 64
+
+ret
+.endm
+
 .macro gen_epel len do name type
 func ff_\do\()_8tap_\name\()_\len\()\type\()_rvv, zve32x
 epel \len \do \name \type
 endfunc
 .endm
 
+.macro gen_epelhv len name do
+func ff_\do\()_8tap_\name\()_\len\()hv_rvv, zve32x
+epel_hv \do \name \len
+endfunc
+.endm
+
 .irp len 64, 32, 16, 8, 4
 func ff_avg\len\()_rvv, zve32x
 copy_avg \len avg
@@ -481,6 +559,7 @@ endfunc
 .irp type h v
 gen_epel \len \do \name \type
 .endr
+gen_epelhv \len \name \do
 .endr
 .endr
 .endr
diff --git a/libavcodec/riscv/vp9dsp_init.c b/libavcodec/riscv/vp9dsp_init.c
index ff7d445f6a..0c75ef38dc 100644
--- a/libavcodec/riscv/vp9dsp_init.c
+++ b/libavcodec/riscv/vp9dsp_init.c
@@ -126,7 +126,8 @@ static av_cold void vp9dsp_mc_init_rvv(VP9DSPContext *dsp, 
int bpp)
 
 #define init_subpel3(idx, type) \
 init_subpel2(idx, 1, 0, h, type);   \
-init_subpel2(idx, 0, 1, v, type)
+init_subpel2(idx, 0, 1, v, type);   \
+init_subpel2(idx, 1, 1, hv, type)
 
 init_subpel3(0, put);
 init_subpel3(1, avg);
-- 
2.45.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 09/10] lavc/vp9dsp: R-V V mc bilin hv

[uk7b]

From: sunyuechi 

C908:
vp9_avg_bilin_4hv_8bpp_c: 10.7
vp9_avg_bilin_4hv_8bpp_rvv_i64: 4.5
vp9_avg_bilin_8hv_8bpp_c: 38.7
vp9_avg_bilin_8hv_8bpp_rvv_i64: 8.2
vp9_avg_bilin_16hv_8bpp_c: 147.2
vp9_avg_bilin_16hv_8bpp_rvv_i64: 32.2
vp9_avg_bilin_32hv_8bpp_c: 590.7
vp9_avg_bilin_32hv_8bpp_rvv_i64: 47.5
vp9_avg_bilin_64hv_8bpp_c: 2323.7
vp9_avg_bilin_64hv_8bpp_rvv_i64: 153.5
vp9_put_bilin_4hv_8bpp_c: 10.0
vp9_put_bilin_4hv_8bpp_rvv_i64: 3.7
vp9_put_bilin_8hv_8bpp_c: 35.2
vp9_put_bilin_8hv_8bpp_rvv_i64: 7.2
vp9_put_bilin_16hv_8bpp_c: 133.7
vp9_put_bilin_16hv_8bpp_rvv_i64: 14.2
vp9_put_bilin_32hv_8bpp_c: 521.7
vp9_put_bilin_32hv_8bpp_rvv_i64: 43.0
vp9_put_bilin_64hv_8bpp_c: 2098.0
vp9_put_bilin_64hv_8bpp_rvv_i64: 144.5
---
 libavcodec/riscv/vp9_mc_rvv.S | 37 +++
 1 file changed, 37 insertions(+)

diff --git a/libavcodec/riscv/vp9_mc_rvv.S b/libavcodec/riscv/vp9_mc_rvv.S
index 151d7702ec..c8a42c7159 100644
--- a/libavcodec/riscv/vp9_mc_rvv.S
+++ b/libavcodec/riscv/vp9_mc_rvv.S
@@ -160,6 +160,37 @@
 ret
 .endm
 
+.macro bilin_hv len type
+.ifc \type,avg
+csrwi   vxrm, 0
+.endif
+neg t1, a5
+neg t2, a6
+li  t4, 8
+li  t5, 1
+bilin_h_loadv24, \len, put
+add a2, a2, a3
+1:
+addia4, a4, -1
+bilin_h_loadv4, \len, put
+vwmulu.vx   v16, v4, a6
+vwmaccsu.vx v16, t2, v24
+vwadd.wxv16, v16, t4
+vnsra.wiv16, v16, 4
+vadd.vv v0, v16, v24
+.ifc \type,avg
+vle8.v  v16, (a0)
+vaaddu.vv   v0, v0, v16
+.endif
+vse8.v  v0, (a0)
+vmv.v.v v24, v4
+add a2, a2, a3
+add a0, a0, a1
+bneza4, 1b
+
+ret
+.endm
+
 .irp len 64, 32, 16
 func ff_copy\len\()_rvv, zve32x
 copy_avg \len copy
@@ -438,6 +469,12 @@ endfunc
 func ff_avg_bilin_\len\()v_rvv, zve32x
 bilin_v \len avg
 endfunc
+func ff_put_bilin_\len\()hv_rvv, zve32x
+bilin_hv \len put
+endfunc
+func ff_avg_bilin_\len\()hv_rvv, zve32x
+bilin_hv \len avg
+endfunc
 
 .irp name regular sharp smooth
 .irp do put avg
-- 
2.45.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 08/10] lavc/vp9dsp: R-V V mc tap v

[uk7b]

From: sunyuechi 

C908:
vp9_avg_8tap_smooth_4v_8bpp_c: 13.7
vp9_avg_8tap_smooth_4v_8bpp_rvv_i64: 5.0
vp9_avg_8tap_smooth_8v_8bpp_c: 49.7
vp9_avg_8tap_smooth_8v_8bpp_rvv_i64: 9.2
vp9_avg_8tap_smooth_16v_8bpp_c: 191.5
vp9_avg_8tap_smooth_16v_8bpp_rvv_i64: 21.2
vp9_avg_8tap_smooth_32v_8bpp_c: 770.5
vp9_avg_8tap_smooth_32v_8bpp_rvv_i64: 66.0
vp9_avg_8tap_smooth_64v_8bpp_c: 3068.0
vp9_avg_8tap_smooth_64v_8bpp_rvv_i64: 262.5
vp9_put_8tap_smooth_4v_8bpp_c: 12.0
vp9_put_8tap_smooth_4v_8bpp_rvv_i64: 4.5
vp9_put_8tap_smooth_8v_8bpp_c: 43.7
vp9_put_8tap_smooth_8v_8bpp_rvv_i64: 8.5
vp9_put_8tap_smooth_16v_8bpp_c: 168.7
vp9_put_8tap_smooth_16v_8bpp_rvv_i64: 20.0
vp9_put_8tap_smooth_32v_8bpp_c: 681.5
vp9_put_8tap_smooth_32v_8bpp_rvv_i64: 63.7
vp9_put_8tap_smooth_64v_8bpp_c: 2692.7
vp9_put_8tap_smooth_64v_8bpp_rvv_i64: 253.5
---
 libavcodec/riscv/vp9_mc_rvv.S  | 32 +++-
 libavcodec/riscv/vp9dsp_init.c |  3 ++-
 2 files changed, 33 insertions(+), 2 deletions(-)

diff --git a/libavcodec/riscv/vp9_mc_rvv.S b/libavcodec/riscv/vp9_mc_rvv.S
index 58b00889ce..151d7702ec 100644
--- a/libavcodec/riscv/vp9_mc_rvv.S
+++ b/libavcodec/riscv/vp9_mc_rvv.S
@@ -222,7 +222,11 @@ endconst
 .macro epel_filter name type regtype
 lla \regtype\()2, subpel_filters_\name
 li  \regtype\()1, 8
+.ifc \type,v
+mul \regtype\()0, a6, \regtype\()1
+.elseif \type == h
 mul \regtype\()0, a5, \regtype\()1
+.endif
 add \regtype\()0, \regtype\()0, \regtype\()2
 .irp n 1,2,3,4,5,6
 lb  \regtype\n, \n(\regtype\()0)
@@ -239,6 +243,19 @@ endconst
 li  a5, 64
 .ifc \from_mem, 1
 vle8.v  v22, (a2)
+.ifc \type,v
+sub a2, a2, a3
+vle8.v  v20, (a2)
+add a2, a2, a3
+add a2, a2, a3
+vle8.v  v24, (a2)
+add a2, a2, a3
+vle8.v  v26, (a2)
+add a2, a2, a3
+vle8.v  v28, (a2)
+add a2, a2, a3
+vle8.v  v30, (a2)
+.elseif \type == h
 addia2, a2, -1
 vle8.v  v20, (a2)
 addia2, a2, 2
@@ -249,6 +266,7 @@ endconst
 vle8.v  v28, (a2)
 addia2, a2, 1
 vle8.v  v30, (a2)
+.endif
 
 .ifc \name,smooth
 vwmulu.vx   v16, v24, \regtype\()4
@@ -267,11 +285,23 @@ endconst
 vwmaccsu.vx v16, s7, v30
 .endif
 
+.ifc \type,v
+.rept 6
+sub a2, a2, a3
+.endr
+vle8.v  v28, (a2)
+sub a2, a2, a3
+vle8.v  v26, (a2)
+.rept 3
+add a2, a2, a3
+.endr
+.elseif \type == h
 addia2, a2, -6
 vle8.v  v28, (a2)
 addia2, a2, -1
 vle8.v  v26, (a2)
 addia2, a2, 3
+.endif
 
 .ifc \name,smooth
 vwmaccsu.vx v16, \regtype\()1, v28
@@ -411,7 +441,7 @@ endfunc
 
 .irp name regular sharp smooth
 .irp do put avg
-.irp type h
+.irp type h v
 gen_epel \len \do \name \type
 .endr
 .endr
diff --git a/libavcodec/riscv/vp9dsp_init.c b/libavcodec/riscv/vp9dsp_init.c
index 97f02e601d..ff7d445f6a 100644
--- a/libavcodec/riscv/vp9dsp_init.c
+++ b/libavcodec/riscv/vp9dsp_init.c
@@ -125,7 +125,8 @@ static av_cold void vp9dsp_mc_init_rvv(VP9DSPContext *dsp, 
int bpp)
 init_subpel1(4, idx, idxh, idxv,  4, dir, type)
 
 #define init_subpel3(idx, type) \
-init_subpel2(idx, 1, 0, h, type)
+init_subpel2(idx, 1, 0, h, type);   \
+init_subpel2(idx, 0, 1, v, type)
 
 init_subpel3(0, put);
 init_subpel3(1, avg);
-- 
2.45.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 07/10] lavc/vp9dsp: R-V V mc bilin v

[uk7b]

From: sunyuechi 

C908:
vp9_avg_bilin_4v_8bpp_c: 5.5
vp9_avg_bilin_4v_8bpp_rvv_i64: 2.2
vp9_avg_bilin_8v_8bpp_c: 20.7
vp9_avg_bilin_8v_8bpp_rvv_i64: 4.2
vp9_avg_bilin_16v_8bpp_c: 82.2
vp9_avg_bilin_16v_8bpp_rvv_i64: 9.0
vp9_avg_bilin_32v_8bpp_c: 342.5
vp9_avg_bilin_32v_8bpp_rvv_i64: 27.0
vp9_avg_bilin_64v_8bpp_c: 1319.2
vp9_avg_bilin_64v_8bpp_rvv_i64: 93.2
vp9_put_bilin_4v_8bpp_c: 4.7
vp9_put_bilin_4v_8bpp_rvv_i64: 1.7
vp9_put_bilin_8v_8bpp_c: 17.7
vp9_put_bilin_8v_8bpp_rvv_i64: 3.2
vp9_put_bilin_16v_8bpp_c: 69.2
vp9_put_bilin_16v_8bpp_rvv_i64: 7.5
vp9_put_bilin_32v_8bpp_c: 274.2
vp9_put_bilin_32v_8bpp_rvv_i64: 23.2
vp9_put_bilin_64v_8bpp_c: 1109.5
vp9_put_bilin_64v_8bpp_rvv_i64: 82.2
---
 libavcodec/riscv/vp9_mc_rvv.S | 49 +++
 1 file changed, 49 insertions(+)

diff --git a/libavcodec/riscv/vp9_mc_rvv.S b/libavcodec/riscv/vp9_mc_rvv.S
index 289c377a42..58b00889ce 100644
--- a/libavcodec/riscv/vp9_mc_rvv.S
+++ b/libavcodec/riscv/vp9_mc_rvv.S
@@ -117,6 +117,49 @@
 ret
 .endm
 
+.macro bilin_v len type
+.ifc \type,avg
+csrwi   vxrm, 0
+.endif
+.ifc \len,4
+vsetivlizero, 4, e8, mf4, ta, ma
+.elseif \len == 8
+vsetivlizero, 8, e8, mf2, ta, ma
+.elseif \len == 16
+vsetivlizero, 16, e8, m1, ta, ma
+.elseif \len == 32
+li  t0, 32
+vsetvli zero, t0, e8, m2, ta, ma
+.elseif \len == 64
+li  t0, 64
+vsetvli zero, t0, e8, m4, ta, ma
+.endif
+li  t4, 8
+neg t1, a6
+1:
+add t2, a2, a3
+addia4, a4, -1
+vle8.v  v0, (a2)
+vle8.v  v8, (t2)
+.ifc \type,avg
+vle8.v  v16, (a0)
+.endif
+vwmulu.vx   v24, v8, a6
+vwmaccsu.vx v24, t1, v0
+vwadd.wxv24, v24, t4
+vnsra.wiv24, v24, 4
+vadd.vv v0, v24, v0
+.ifc \type,avg
+vaaddu.vv   v0, v0, v16
+.endif
+vse8.v  v0, (a0)
+add a2, a2, a3
+add a0, a0, a1
+bneza4, 1b
+
+ret
+.endm
+
 .irp len 64, 32, 16
 func ff_copy\len\()_rvv, zve32x
 copy_avg \len copy
@@ -359,6 +402,12 @@ endfunc
 func ff_avg_bilin_\len\()h_rvv, zve32x
 bilin_h \len avg
 endfunc
+func ff_put_bilin_\len\()v_rvv, zve32x
+bilin_v \len put
+endfunc
+func ff_avg_bilin_\len\()v_rvv, zve32x
+bilin_v \len avg
+endfunc
 
 .irp name regular sharp smooth
 .irp do put avg
-- 
2.45.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 04/10] lavc/vp9dsp: R-V mc copy_avg

[uk7b]

From: sunyuechi 

C908:
vp9_avg4_8bpp_c: 1.2
vp9_avg4_8bpp_rvv_i64: 1.0
vp9_avg8_8bpp_c: 3.7
vp9_avg8_8bpp_rvv_i64: 1.5
vp9_avg16_8bpp_c: 14.7
vp9_avg16_8bpp_rvv_i64: 3.5
vp9_avg32_8bpp_c: 57.7
vp9_avg32_8bpp_rvv_i64: 10.0
vp9_avg64_8bpp_c: 229.0
vp9_avg64_8bpp_rvv_i64: 31.7
vp9_put4_8bpp_c: 0.7
vp9_put4_8bpp_rvi: 0.2
vp9_put8_8bpp_c: 2.5
vp9_put8_8bpp_rvi: 0.5
vp9_put16_8bpp_c: 16.5
vp9_put16_8bpp_rvv_i64: 1.7
vp9_put32_8bpp_c: 37.2
vp9_put32_8bpp_rvv_i64: 5.7
vp9_put64_8bpp_c: 91.2
vp9_put64_8bpp_rvv_i64: 19.7
---
 libavcodec/riscv/Makefile  |  4 ++-
 libavcodec/riscv/vp9_mc_rvi.S  | 43 +++
 libavcodec/riscv/vp9_mc_rvv.S  | 64 ++
 libavcodec/riscv/vp9dsp_init.c | 47 +
 4 files changed, 157 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/riscv/vp9_mc_rvi.S
 create mode 100644 libavcodec/riscv/vp9_mc_rvv.S

diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index 050c08ee61..43b5c21cf4 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -63,6 +63,8 @@ RVV-OBJS-$(CONFIG_VC1DSP) += riscv/vc1dsp_rvv.o
 OBJS-$(CONFIG_VP8DSP) += riscv/vp8dsp_init.o
 RVV-OBJS-$(CONFIG_VP8DSP) += riscv/vp8dsp_rvv.o
 OBJS-$(CONFIG_VP9_DECODER) += riscv/vp9dsp_init.o
-RVV-OBJS-$(CONFIG_VP9_DECODER) += riscv/vp9_intra_rvv.o
+RV-OBJS-$(CONFIG_VP9_DECODER) += riscv/vp9_mc_rvi.o
+RVV-OBJS-$(CONFIG_VP9_DECODER) += riscv/vp9_intra_rvv.o \
+  riscv/vp9_mc_rvv.o
 OBJS-$(CONFIG_VORBIS_DECODER) += riscv/vorbisdsp_init.o
 RVV-OBJS-$(CONFIG_VORBIS_DECODER) += riscv/vorbisdsp_rvv.o
diff --git a/libavcodec/riscv/vp9_mc_rvi.S b/libavcodec/riscv/vp9_mc_rvi.S
new file mode 100644
index 00..03d8dbbbae
--- /dev/null
+++ b/libavcodec/riscv/vp9_mc_rvi.S
@@ -0,0 +1,43 @@
+/*
+ * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/riscv/asm.S"
+
+func ff_copy8_rvi
+1:
+addi a4, a4, -1
+ld   t4, (a2)
+sd   t4, (a0)
+add  a2, a2, a3
+add  a0, a0, a1
+bnez a4, 1b
+ret
+endfunc
+
+func ff_copy4_rvi
+1:
+addi a4, a4, -1
+lw   t4, (a2)
+sw   t4, (a0)
+add  a2, a2, a3
+add  a0, a0, a1
+bnez a4, 1b
+ret
+endfunc
diff --git a/libavcodec/riscv/vp9_mc_rvv.S b/libavcodec/riscv/vp9_mc_rvv.S
new file mode 100644
index 00..ba9ec3431f
--- /dev/null
+++ b/libavcodec/riscv/vp9_mc_rvv.S
@@ -0,0 +1,64 @@
+/*
+ * Copyright (c) 2024 Institue of Software Chinese Academy of Sciences (ISCAS).
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/riscv/asm.S"
+
+.macro copy_avg len type
+.ifc \type,avg
+csrwi   vxrm, 0
+.endif
+.ifc \len,64
+li  t5, 64
+vsetvli t0, t5, e8, m4, ta, ma
+.elseif \len == 32
+li  t5, 32
+vsetvli t0, t5, e8, m2, ta, ma
+.elseif \len == 16
+vsetivlit0, 16, e8, m1, ta, ma
+.elseif \len == 8
+vsetivlit0, 8, e8, mf2, ta, ma
+.elseif \len == 4
+vsetivlit0, 4, e8, mf4, ta, ma
+.endif
+1:
+addia4, a4, -1
+vle8.v  v8, (a2)
+.ifc \type,avg
+vle8.v  v16, (a0)
+vaaddu.vv   v8, v8, v16
+.endif
+vse8.v  v8, (a0)
+add

[FFmpeg-devel] [PATCH 06/10] lavc/vp9dsp: R-V V mc tap h

[uk7b]

From: sunyuechi 

C908:
vp9_avg_8tap_smooth_4h_8bpp_c: 12.7
vp9_avg_8tap_smooth_4h_8bpp_rvv_i64: 5.0
vp9_avg_8tap_smooth_8h_8bpp_c: 48.5
vp9_avg_8tap_smooth_8h_8bpp_rvv_i64: 9.2
vp9_avg_8tap_smooth_16h_8bpp_c: 191.7
vp9_avg_8tap_smooth_16h_8bpp_rvv_i64: 21.0
vp9_avg_8tap_smooth_32h_8bpp_c: 780.0
vp9_avg_8tap_smooth_32h_8bpp_rvv_i64: 66.5
vp9_avg_8tap_smooth_64h_8bpp_c: 3123.7
vp9_avg_8tap_smooth_64h_8bpp_rvv_i64: 264.2
vp9_put_8tap_smooth_4h_8bpp_c: 11.0
vp9_put_8tap_smooth_4h_8bpp_rvv_i64: 4.2
vp9_put_8tap_smooth_8h_8bpp_c: 42.0
vp9_put_8tap_smooth_8h_8bpp_rvv_i64: 8.2
vp9_put_8tap_smooth_16h_8bpp_c: 165.5
vp9_put_8tap_smooth_16h_8bpp_rvv_i64: 19.7
vp9_put_8tap_smooth_32h_8bpp_c: 659.0
vp9_put_8tap_smooth_32h_8bpp_rvv_i64: 64.0
vp9_put_8tap_smooth_64h_8bpp_c: 2682.0
vp9_put_8tap_smooth_64h_8bpp_rvv_i64: 272.2
---
 libavcodec/riscv/vp9_mc_rvv.S  | 233 +
 libavcodec/riscv/vp9dsp_init.c |   8 +-
 2 files changed, 240 insertions(+), 1 deletion(-)

diff --git a/libavcodec/riscv/vp9_mc_rvv.S b/libavcodec/riscv/vp9_mc_rvv.S
index a97807633e..289c377a42 100644
--- a/libavcodec/riscv/vp9_mc_rvv.S
+++ b/libavcodec/riscv/vp9_mc_rvv.S
@@ -123,6 +123,231 @@ func ff_copy\len\()_rvv, zve32x
 endfunc
 .endr
 
+const subpel_filters_regular
+.byte  0,  0,   0, 128,   0,   0,  0,  0
+.byte  0,  1,  -5, 126,   8,  -3,  1,  0
+.byte -1,  3, -10, 122,  18,  -6,  2,  0
+.byte -1,  4, -13, 118,  27,  -9,  3, -1
+.byte -1,  4, -16, 112,  37, -11,  4, -1
+.byte -1,  5, -18, 105,  48, -14,  4, -1
+.byte -1,  5, -19,  97,  58, -16,  5, -1
+.byte -1,  6, -19,  88,  68, -18,  5, -1
+.byte -1,  6, -19,  78,  78, -19,  6, -1
+.byte -1,  5, -18,  68,  88, -19,  6, -1
+.byte -1,  5, -16,  58,  97, -19,  5, -1
+.byte -1,  4, -14,  48, 105, -18,  5, -1
+.byte -1,  4, -11,  37, 112, -16,  4, -1
+.byte -1,  3,  -9,  27, 118, -13,  4, -1
+.byte  0,  2,  -6,  18, 122, -10,  3, -1
+.byte  0,  1,  -3,   8, 126,  -5,  1,  0
+subpel_filters_sharp:
+.byte  0,  0,   0, 128,   0,   0,  0,  0
+.byte -1,  3,  -7, 127,   8,  -3,  1,  0
+.byte -2,  5, -13, 125,  17,  -6,  3, -1
+.byte -3,  7, -17, 121,  27, -10,  5, -2
+.byte -4,  9, -20, 115,  37, -13,  6, -2
+.byte -4, 10, -23, 108,  48, -16,  8, -3
+.byte -4, 10, -24, 100,  59, -19,  9, -3
+.byte -4, 11, -24,  90,  70, -21, 10, -4
+.byte -4, 11, -23,  80,  80, -23, 11, -4
+.byte -4, 10, -21,  70,  90, -24, 11, -4
+.byte -3,  9, -19,  59, 100, -24, 10, -4
+.byte -3,  8, -16,  48, 108, -23, 10, -4
+.byte -2,  6, -13,  37, 115, -20,  9, -4
+.byte -2,  5, -10,  27, 121, -17,  7, -3
+.byte -1,  3,  -6,  17, 125, -13,  5, -2
+.byte  0,  1,  -3,   8, 127,  -7,  3, -1
+subpel_filters_smooth:
+.byte  0,  0,   0, 128,   0,   0,  0,  0
+.byte -3, -1,  32,  64,  38,   1, -3,  0
+.byte -2, -2,  29,  63,  41,   2, -3,  0
+.byte -2, -2,  26,  63,  43,   4, -4,  0
+.byte -2, -3,  24,  62,  46,   5, -4,  0
+.byte -2, -3,  21,  60,  49,   7, -4,  0
+.byte -1, -4,  18,  59,  51,   9, -4,  0
+.byte -1, -4,  16,  57,  53,  12, -4, -1
+.byte -1, -4,  14,  55,  55,  14, -4, -1
+.byte -1, -4,  12,  53,  57,  16, -4, -1
+.byte  0, -4,   9,  51,  59,  18, -4, -1
+.byte  0, -4,   7,  49,  60,  21, -3, -2
+.byte  0, -4,   5,  46,  62,  24, -3, -2
+.byte  0, -4,   4,  43,  63,  26, -2, -2
+.byte  0, -3,   2,  41,  63,  29, -2, -2
+.byte  0, -3,   1,  38,  64,  32, -1, -3
+endconst
+
+.macro epel_filter name type regtype
+lla \regtype\()2, subpel_filters_\name
+li  \regtype\()1, 8
+mul \regtype\()0, a5, \regtype\()1
+add \regtype\()0, \regtype\()0, \regtype\()2
+.irp n 1,2,3,4,5,6
+lb  \regtype\n, \n(\regtype\()0)
+.endr
+.ifc \regtype,t
+lb  a7, 7(\regtype\()0)
+.elseif \regtype == s
+lb  s7, 7(\regtype\()0)
+.endif
+lb  \regtype\()0, 0(\regtype\()0)
+.endm
+
+.macro epel_load dst len do name type from_mem regtype
+li  a5, 64
+.ifc \from_mem, 1
+vle8.v  v22, (a2)
+addia2, a2, -1
+vle8.v  v20, (a2)
+addia2, a2, 2
+vle8.v  v24, (a2)
+addia2, a2, 1
+vle8.v  v26, (a2)
+addia2, a2, 1
+vle8.v  v28, (a2)
+addia2, a2, 1
+vle8.v  v30, (a2)
+
+.ifc \name,smooth
+vwmulu.vx   v16, v24, \regtype\()4
+vwmaccu.vx  v16, \regtype\()2, v20
+vwmaccu.vx  v16, \regtype\()5, v26
+vwmaccsu.vx v16, \regtype\()6, 

[FFmpeg-devel] [PATCH 05/10] lavc/vp9dsp: R-V V mc bilin h

[uk7b]

From: sunyuechi 

C908:
vp9_avg_bilin_4h_8bpp_c: 5.5
vp9_avg_bilin_4h_8bpp_rvv_i64: 2.5
vp9_avg_bilin_8h_8bpp_c: 19.7
vp9_avg_bilin_8h_8bpp_rvv_i64: 5.0
vp9_avg_bilin_16h_8bpp_c: 78.2
vp9_avg_bilin_16h_8bpp_rvv_i64: 10.0
vp9_avg_bilin_32h_8bpp_c: 325.2
vp9_avg_bilin_32h_8bpp_rvv_i64: 28.5
vp9_avg_bilin_64h_8bpp_c: 1266.2
vp9_avg_bilin_64h_8bpp_rvv_i64: 115.0
vp9_put_bilin_4h_8bpp_c: 4.5
vp9_put_bilin_4h_8bpp_rvv_i64: 2.2
vp9_put_bilin_8h_8bpp_c: 16.7
vp9_put_bilin_8h_8bpp_rvv_i64: 4.2
vp9_put_bilin_16h_8bpp_c: 65.2
vp9_put_bilin_16h_8bpp_rvv_i64: 8.7
vp9_put_bilin_32h_8bpp_c: 273.5
vp9_put_bilin_32h_8bpp_rvv_i64: 26.7
vp9_put_bilin_64h_8bpp_c: 1041.0
vp9_put_bilin_64h_8bpp_rvv_i64: 87.2
---
 libavcodec/riscv/vp9_mc_rvv.S  | 73 ++
 libavcodec/riscv/vp9dsp_init.c | 17 
 2 files changed, 90 insertions(+)

diff --git a/libavcodec/riscv/vp9_mc_rvv.S b/libavcodec/riscv/vp9_mc_rvv.S
index ba9ec3431f..a97807633e 100644
--- a/libavcodec/riscv/vp9_mc_rvv.S
+++ b/libavcodec/riscv/vp9_mc_rvv.S
@@ -51,6 +51,72 @@
 ret
 .endm
 
+.macro bilin_h_load dst len type
+.ifc \len,4
+vsetivlizero, 5, e8, mf2, ta, ma
+.elseif \len == 8
+vsetivlizero, 9, e8, m1, ta, ma
+.elseif \len == 16
+vsetivlizero, 17, e8, m2, ta, ma
+.elseif \len == 32
+li  t0, 33
+vsetvli zero, t0, e8, m4, ta, ma
+.elseif \len == 64
+li  t0, 65
+vsetvli zero, t0, e8, m8, ta, ma
+.endif
+
+vle8.v  v8, (a2)
+vslide1down.vx  v0, v8, t5
+
+.ifc \len,4
+vsetivlizero, 4, e8, mf4, ta, ma
+.elseif \len == 8
+vsetivlizero, 8, e8, mf2, ta, ma
+.elseif \len == 16
+vsetivlizero, 16, e8, m1, ta, ma
+.elseif \len == 32
+li  t0, 32
+vsetvli zero, t0, e8, m2, ta, ma
+.elseif \len == 64
+li  t0, 64
+vsetvli zero, t0, e8, m4, ta, ma
+.endif
+
+vwmulu.vx   v16, v0, a5
+vwmaccsu.vx v16, t1, v8
+vwadd.wxv16, v16, t4
+vnsra.wiv16, v16, 4
+vadd.vv \dst, v16, v8
+
+.ifc \type,put
+vadd.vv \dst, v16, v8
+.elseif \type == avg
+vadd.vv v16, v16, v8
+vle8.v  \dst, (a0)
+vaaddu.vv   \dst, \dst, v16
+.endif
+
+.endm
+
+.macro bilin_h len type
+.ifc \type,avg
+csrwi   vxrm, 0
+.endif
+li  t4, 8
+li  t5, 1
+neg t1, a5
+1:
+addia4, a4, -1
+bilin_h_loadv0, \len, \type
+vse8.v  v0, (a0)
+add a2, a2, a3
+add a0, a0, a1
+bneza4, 1b
+
+ret
+.endm
+
 .irp len 64, 32, 16
 func ff_copy\len\()_rvv, zve32x
 copy_avg \len copy
@@ -61,4 +127,11 @@ endfunc
 func ff_avg\len\()_rvv, zve32x
 copy_avg \len avg
 endfunc
+
+func ff_put_bilin_\len\()h_rvv, zve32x
+bilin_h \len put
+endfunc
+func ff_avg_bilin_\len\()h_rvv, zve32x
+bilin_h \len avg
+endfunc
 .endr
diff --git a/libavcodec/riscv/vp9dsp_init.c b/libavcodec/riscv/vp9dsp_init.c
index da33e15e97..248501f5d2 100644
--- a/libavcodec/riscv/vp9dsp_init.c
+++ b/libavcodec/riscv/vp9dsp_init.c
@@ -106,6 +106,23 @@ static av_cold void vp9dsp_mc_init_rvv(VP9DSPContext *dsp, 
int bpp)
 #undef init_copy_avg
 #undef init_avg
 #undef init_fpel
+
+#define init_subpel1(idx1, idx2, idxh, idxv, sz, dir, type)  \
+dsp->mc[idx1][FILTER_BILINEAR][idx2][idxh][idxv] =   \
+ff_##type##_bilin_##sz##dir##_rvv;
+
+#define init_subpel2(idx, idxh, idxv, dir, type)  \
+init_subpel1(0, idx, idxh, idxv, 64, dir, type);  \
+init_subpel1(1, idx, idxh, idxv, 32, dir, type);  \
+init_subpel1(2, idx, idxh, idxv, 16, dir, type);  \
+init_subpel1(3, idx, idxh, idxv,  8, dir, type);  \
+init_subpel1(4, idx, idxh, idxv,  4, dir, type)
+
+#define init_subpel3(idx, type) \
+init_subpel2(idx, 1, 0, h, type)
+
+init_subpel3(0, put);
+init_subpel3(1, avg);
 }
 #endif
 #endif
-- 
2.45.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 03/10] lavc/vp9dsp: R-V V ipred tm

[uk7b]

From: sunyuechi 

C908:
vp9_tm_4x4_8bpp_c: 116.5
vp9_tm_4x4_8bpp_rvv_i32: 43.5
vp9_tm_8x8_8bpp_c: 416.2
vp9_tm_8x8_8bpp_rvv_i32: 86.0
vp9_tm_16x16_8bpp_c: 1665.5
vp9_tm_16x16_8bpp_rvv_i32: 187.2
vp9_tm_32x32_8bpp_c: 6974.2
vp9_tm_32x32_8bpp_rvv_i32: 625.7
---
 libavcodec/riscv/vp9_intra_rvv.S | 143 +++
 libavcodec/riscv/vp9dsp.h|   8 ++
 libavcodec/riscv/vp9dsp_init.c   |   4 +
 3 files changed, 155 insertions(+)

diff --git a/libavcodec/riscv/vp9_intra_rvv.S b/libavcodec/riscv/vp9_intra_rvv.S
index 1b270215fb..c6ddd541e4 100644
--- a/libavcodec/riscv/vp9_intra_rvv.S
+++ b/libavcodec/riscv/vp9_intra_rvv.S
@@ -204,3 +204,146 @@ func ff_h_8x8_rvv, zve32x
 
 ret
 endfunc
+
+.macro tm_sum dst, top, offset
+lbu  t3, \offset(a2)
+sub  t3, t3, a4
+vadd.vx  \dst, \top, t3
+.endm
+
+func ff_tm_32x32_rvv, zve32x
+lbu  a4, -1(a3)
+li   t5, 32
+
+.macro tm_sum32 n1,n2,n3,n4,n5,n6,n7,n8
+
+vsetvli  zero, t5, e16, m4, ta, ma
+vle8.v   v8, (a3)
+vzext.vf2v28, v8
+
+tm_sum   v0, v28, \n1
+tm_sum   v4, v28, \n2
+tm_sum   v8, v28, \n3
+tm_sum   v12, v28, \n4
+tm_sum   v16, v28, \n5
+tm_sum   v20, v28, \n6
+tm_sum   v24, v28, \n7
+tm_sum   v28, v28, \n8
+
+.irp n 0, 4, 8, 12, 16, 20, 24, 28
+vmax.vx  v\n, v\n, zero
+.endr
+
+vsetvli  zero, zero, e8, m2, ta, ma
+.irp n 0, 4, 8, 12, 16, 20, 24, 28
+vnclipu.wi   v\n, v\n, 0
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+
+.endm
+
+tm_sum32 31, 30, 29, 28, 27, 26, 25, 24
+tm_sum32 23, 22, 21, 20, 19, 18, 17, 16
+tm_sum32 15, 14, 13, 12, 11, 10, 9, 8
+tm_sum32 7, 6, 5, 4, 3, 2, 1, 0
+
+ret
+endfunc
+
+func ff_tm_16x16_rvv, zve32x
+vsetivli  zero, 16, e16, m2, ta, ma
+vle8.vv8, (a3)
+vzext.vf2 v30, v8
+lbu   a4, -1(a3)
+
+tm_sum   v0, v30, 15
+tm_sum   v2, v30, 14
+tm_sum   v4, v30, 13
+tm_sum   v6, v30, 12
+tm_sum   v8, v30, 11
+tm_sum   v10, v30, 10
+tm_sum   v12, v30, 9
+tm_sum   v14, v30, 8
+tm_sum   v16, v30, 7
+tm_sum   v18, v30, 6
+tm_sum   v20, v30, 5
+tm_sum   v22, v30, 4
+tm_sum   v24, v30, 3
+tm_sum   v26, v30, 2
+tm_sum   v28, v30, 1
+tm_sum   v30, v30, 0
+
+.irp n 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30
+vmax.vx  v\n, v\n, zero
+.endr
+
+vsetvli  zero, zero, e8, m1, ta, ma
+.irp n 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28
+vnclipu.wi   v\n, v\n, 0
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+vnclipu.wi   v30, v30, 0
+vse8.v   v30, (a0)
+
+ret
+endfunc
+
+func ff_tm_8x8_rvv, zve32x
+vsetivli zero, 8, e16, m1, ta, ma
+vle8.v   v8, (a3)
+vzext.vf2v28, v8
+lbu  a4, -1(a3)
+
+tm_sum   v16, v28, 7
+tm_sum   v17, v28, 6
+tm_sum   v18, v28, 5
+tm_sum   v19, v28, 4
+tm_sum   v20, v28, 3
+tm_sum   v21, v28, 2
+tm_sum   v22, v28, 1
+tm_sum   v23, v28, 0
+
+.irp n 16, 17, 18, 19, 20, 21, 22, 23
+vmax.vx  v\n, v\n, zero
+.endr
+
+vsetvli  zero, zero, e8, mf2, ta, ma
+.irp n 16, 17, 18, 19, 20, 21, 22
+vnclipu.wi   v\n, v\n, 0
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+vnclipu.wi   v24, v23, 0
+vse8.v   v24, (a0)
+
+ret
+endfunc
+
+func ff_tm_4x4_rvv, zve32x
+vsetivli zero, 4, e16, mf2, ta, ma
+vle8.v   v8, (a3)
+vzext.vf2v28, v8
+lbu  a4, -1(a3)
+
+tm_sum   v16, v28, 3
+tm_sum   v17, v28, 2
+tm_sum   v18, v28, 1
+tm_sum   v19, v28, 0
+
+.irp n 16, 17, 18, 19
+vmax.vx  v\n, v\n, zero
+.endr
+
+vsetvli  zero, zero, e8, mf4, ta, ma
+.irp n 16, 17, 18
+vnclipu.wi   v\n, v\n, 0
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+vnclipu.wi   v24, v19, 0
+vse8.v   v24, (a0)
+
+ret
+endfunc
diff --git a/libavcodec/riscv/vp9dsp.h b/libavcodec/riscv/vp9dsp.h
index d4c7652286..36e1a8795b 100644
--- a/libavcodec/riscv/vp9dsp.h
+++ b/libavcodec/riscv/vp9dsp.h
@@ -72,6 +72,14 @@ void ff_h_16x16_rvv(uint8_t *dst, ptrdiff_t stride, const 
uint8_t *l,
 const uint8_t *a);
 void ff_h_8x8_rvv(uint8_t *dst, 

[FFmpeg-devel] [PATCH 01/10] lavc/vp9dsp: R-V V ipred vert

[uk7b]

From: sunyuechi 

C908:
vp9_vert_8x8_8bpp_c: 22.0
vp9_vert_8x8_8bpp_rvv_i64: 18.5
vp9_vert_16x16_8bpp_c: 71.2
vp9_vert_16x16_8bpp_rvv_i32: 50.7
vp9_vert_32x32_8bpp_c: 300.2
vp9_vert_32x32_8bpp_rvv_i32: 136.7
---
 libavcodec/riscv/vp9_intra_rvv.S | 35 
 libavcodec/riscv/vp9dsp.h|  6 ++
 libavcodec/riscv/vp9dsp_init.c   |  3 +++
 3 files changed, 44 insertions(+)

diff --git a/libavcodec/riscv/vp9_intra_rvv.S b/libavcodec/riscv/vp9_intra_rvv.S
index db9774c263..b5f0f9d3c3 100644
--- a/libavcodec/riscv/vp9_intra_rvv.S
+++ b/libavcodec/riscv/vp9_intra_rvv.S
@@ -113,3 +113,38 @@ func_dc dc_left  8   left 3  0  zve64x
 func_dc dc_top   32  top  5  1  zve32x
 func_dc dc_top   16  top  4  1  zve32x
 func_dc dc_top   8   top  3  0  zve64x
+
+func ff_v_32x32_rvv, zve32x
+vsetivli zero, 8, e8, mf2, ta, ma
+vle32.v  v8, (a3)
+
+.rept 31
+vse32.v  v8, (a0)
+add  a0, a0, a1
+.endr
+vse32.v  v8, (a0)
+
+ret
+endfunc
+
+func ff_v_16x16_rvv, zve32x
+vsetivli zero, 4, e8, mf4, ta, ma
+vle32.v  v8, (a3)
+
+.rept 15
+vse32.v  v8, (a0)
+add  a0, a0, a1
+.endr
+vse32.v  v8, (a0)
+
+ret
+endfunc
+
+func ff_v_8x8_rvv, zve64x
+ld   t0, (a3)
+vsetivli zero, 8, e64, m4, ta, ma
+vmv.v.x  v8, t0
+vsse64.v v8, (a0), a1
+
+ret
+endfunc
diff --git a/libavcodec/riscv/vp9dsp.h b/libavcodec/riscv/vp9dsp.h
index 25047ed507..113397ce86 100644
--- a/libavcodec/riscv/vp9dsp.h
+++ b/libavcodec/riscv/vp9dsp.h
@@ -60,6 +60,12 @@ void ff_dc_129_16x16_rvv(uint8_t *dst, ptrdiff_t stride, 
const uint8_t *l,
  const uint8_t *a);
 void ff_dc_129_8x8_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
const uint8_t *a);
+void ff_v_32x32_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
+const uint8_t *a);
+void ff_v_16x16_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
+const uint8_t *a);
+void ff_v_8x8_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
+  const uint8_t *a);
 
 #define VP9_8TAP_RISCV_RVV_FUNC(SIZE, type, type_idx) \
 void ff_put_8tap_##type##_##SIZE##h_rvv(uint8_t *dst, ptrdiff_t dststride,   \
diff --git a/libavcodec/riscv/vp9dsp_init.c b/libavcodec/riscv/vp9dsp_init.c
index 69ab39004c..9c550d40b5 100644
--- a/libavcodec/riscv/vp9dsp_init.c
+++ b/libavcodec/riscv/vp9dsp_init.c
@@ -36,6 +36,7 @@ static av_cold void vp9dsp_intrapred_init_rvv(VP9DSPContext 
*dsp, int bpp)
 dsp->intra_pred[TX_8X8][DC_128_PRED] = ff_dc_128_8x8_rvv;
 dsp->intra_pred[TX_8X8][DC_129_PRED] = ff_dc_129_8x8_rvv;
 dsp->intra_pred[TX_8X8][TOP_DC_PRED] = ff_dc_top_8x8_rvv;
+dsp->intra_pred[TX_8X8][VERT_PRED] = ff_v_8x8_rvv;
 }
 
 if (bpp == 8 && flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 
16) {
@@ -51,6 +52,8 @@ static av_cold void vp9dsp_intrapred_init_rvv(VP9DSPContext 
*dsp, int bpp)
 dsp->intra_pred[TX_16X16][DC_129_PRED] = ff_dc_129_16x16_rvv;
 dsp->intra_pred[TX_32X32][TOP_DC_PRED] = ff_dc_top_32x32_rvv;
 dsp->intra_pred[TX_16X16][TOP_DC_PRED] = ff_dc_top_16x16_rvv;
+dsp->intra_pred[TX_32X32][VERT_PRED] = ff_v_32x32_rvv;
+dsp->intra_pred[TX_16X16][VERT_PRED] = ff_v_16x16_rvv;
 }
 #endif
 }
-- 
2.45.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 02/10] lavc/vp9dsp: R-V V ipred hor

[uk7b]

From: sunyuechi 

C908:
vp9_hor_8x8_8bpp_c: 74.7
vp9_hor_8x8_8bpp_rvv_i32: 35.7
vp9_hor_16x16_8bpp_c: 175.5
vp9_hor_16x16_8bpp_rvv_i32: 80.2
vp9_hor_32x32_8bpp_c: 510.2
vp9_hor_32x32_8bpp_rvv_i32: 264.0
---
 libavcodec/riscv/vp9_intra_rvv.S | 56 
 libavcodec/riscv/vp9dsp.h|  6 
 libavcodec/riscv/vp9dsp_init.c   |  3 ++
 3 files changed, 65 insertions(+)

diff --git a/libavcodec/riscv/vp9_intra_rvv.S b/libavcodec/riscv/vp9_intra_rvv.S
index b5f0f9d3c3..1b270215fb 100644
--- a/libavcodec/riscv/vp9_intra_rvv.S
+++ b/libavcodec/riscv/vp9_intra_rvv.S
@@ -148,3 +148,59 @@ func ff_v_8x8_rvv, zve64x
 
 ret
 endfunc
+
+func ff_h_32x32_rvv, zve32x
+li   t0, 32
+addi a2, a2, 31
+vsetvli  zero, t0, e8, m2, ta, ma
+
+.rept 2
+.irp n 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30
+lbu  t1, (a2)
+addi a2, a2, -1
+vmv.v.x  v\n, t1
+.endr
+.irp n 0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+.endr
+
+ret
+endfunc
+
+func ff_h_16x16_rvv, zve32x
+addi a2, a2, 15
+vsetivli zero, 16, e8, m1, ta, ma
+
+.irp n 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23
+lbu  t1, (a2)
+addi a2, a2, -1
+vmv.v.x  v\n, t1
+.endr
+.irp n 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+vse8.v   v23, (a0)
+
+ret
+endfunc
+
+func ff_h_8x8_rvv, zve32x
+addi a2, a2, 7
+vsetivli zero, 8, e8, mf2, ta, ma
+
+.irp n 8, 9, 10, 11, 12, 13, 14, 15
+lbu  t1, (a2)
+addi a2, a2, -1
+vmv.v.x  v\n, t1
+.endr
+.irp n 8, 9, 10, 11, 12, 13, 14
+vse8.v   v\n, (a0)
+add  a0, a0, a1
+.endr
+vse8.v   v15, (a0)
+
+ret
+endfunc
diff --git a/libavcodec/riscv/vp9dsp.h b/libavcodec/riscv/vp9dsp.h
index 113397ce86..d4c7652286 100644
--- a/libavcodec/riscv/vp9dsp.h
+++ b/libavcodec/riscv/vp9dsp.h
@@ -66,6 +66,12 @@ void ff_v_16x16_rvv(uint8_t *dst, ptrdiff_t stride, const 
uint8_t *l,
 const uint8_t *a);
 void ff_v_8x8_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
   const uint8_t *a);
+void ff_h_32x32_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
+const uint8_t *a);
+void ff_h_16x16_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
+const uint8_t *a);
+void ff_h_8x8_rvv(uint8_t *dst, ptrdiff_t stride, const uint8_t *l,
+  const uint8_t *a);
 
 #define VP9_8TAP_RISCV_RVV_FUNC(SIZE, type, type_idx) \
 void ff_put_8tap_##type##_##SIZE##h_rvv(uint8_t *dst, ptrdiff_t dststride,   \
diff --git a/libavcodec/riscv/vp9dsp_init.c b/libavcodec/riscv/vp9dsp_init.c
index 9c550d40b5..16aeeb260a 100644
--- a/libavcodec/riscv/vp9dsp_init.c
+++ b/libavcodec/riscv/vp9dsp_init.c
@@ -54,6 +54,9 @@ static av_cold void vp9dsp_intrapred_init_rvv(VP9DSPContext 
*dsp, int bpp)
 dsp->intra_pred[TX_16X16][TOP_DC_PRED] = ff_dc_top_16x16_rvv;
 dsp->intra_pred[TX_32X32][VERT_PRED] = ff_v_32x32_rvv;
 dsp->intra_pred[TX_16X16][VERT_PRED] = ff_v_16x16_rvv;
+dsp->intra_pred[TX_32X32][HOR_PRED] = ff_h_32x32_rvv;
+dsp->intra_pred[TX_16X16][HOR_PRED] = ff_h_16x16_rvv;
+dsp->intra_pred[TX_8X8][HOR_PRED] = ff_h_8x8_rvv;
 }
 #endif
 }
-- 
2.45.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 v2 0/2] Add support for H266/VVC encoding

[Christian]

This patchset is based on the latest patchset from Thomas Siedel
(thomas...@spin-digital.com ).
Since almost all changes from the patchset but libvvenc and libvvdec has been
merged this patch only implements the libvvenc and libvvdec wrapper
implementation.
As ffmpeg already has it´s own vvc decoder, feel free to cherry pick libvvenc
only.
The libvvenc patch only has been aligend to the current master without changing
the implementation.
The libvvdec patch has been cleaned up by removing the extradata parsing files
and using existing code from cbs_h266.

Christian Bartnik (2):
 avcodec: add external enc libvvenc for H266/VVC
 avcodec: add external dec libvvdec for H266/VVC

configure  |   9 +
libavcodec/Makefile|   2 +
libavcodec/allcodecs.c |   2 +
libavcodec/libvvdec.c  | 617 +
libavcodec/libvvenc.c  | 501 +
5 files changed, 1131 insertions(+)
create mode 100644 libavcodec/libvvdec.c
create mode 100644 libavcodec/libvvenc.c

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

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

Re: [FFmpeg-devel] [PATCH 01/10] lavc/vp8dsp: R-V V put_vp8_pixels

[flow gg]

I've reorganized it, and the github link is at :
https://github.com/hleft/FFmpeg/tree/vp8

 于2024年5月4日周六 22:49写道：

> From: sunyuechi 
>
> C908:
> vp8_put_pixels4_c: 87.5
> vp8_put_pixels4_rvv_i32: 42.7
> vp8_put_pixels8_c: 284.5
> vp8_put_pixels8_rvv_i32: 77.7
> vp8_put_pixels16_c: 1087.7
> vp8_put_pixels16_rvv_i32: 108.0
> ---
>  libavcodec/riscv/vp8dsp.h  | 75 ++
>  libavcodec/riscv/vp8dsp_init.c | 22 ++
>  libavcodec/riscv/vp8dsp_rvv.S  | 27 
>  libavcodec/vp8dsp.c|  2 +
>  libavcodec/vp8dsp.h|  1 +
>  5 files changed, 127 insertions(+)
>  create mode 100644 libavcodec/riscv/vp8dsp.h
>
> diff --git a/libavcodec/riscv/vp8dsp.h b/libavcodec/riscv/vp8dsp.h
> new file mode 100644
> index 00..971c5c0a96
> --- /dev/null
> +++ b/libavcodec/riscv/vp8dsp.h
> @@ -0,0 +1,75 @@
> +/*
> + * 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 AVCODEC_RISCV_VP8DSP_H
> +#define AVCODEC_RISCV_VP8DSP_H
> +
> +#include "libavcodec/vp8dsp.h"
> +
> +#define VP8_LF_Y(hv, inner, opt)
>\
> +void ff_vp8_##hv##_loop_filter16##inner##_##opt(uint8_t *dst,
> \
> +ptrdiff_t stride,
> \
> +int flim_E, int
> flim_I,  \
> +int hev_thresh)
> +
> +#define VP8_LF_UV(hv, inner, opt)
> \
> +void ff_vp8_##hv##_loop_filter8uv##inner##_##opt(uint8_t *dstU,
> \
> + uint8_t *dstV,
> \
> + ptrdiff_t stride,
>\
> + int flim_E, int
> flim_I, \
> + int hev_thresh)
> +
> +#define VP8_LF_SIMPLE(hv, opt)  \
> +void ff_vp8_##hv##_loop_filter16_simple_##opt(uint8_t *dst, \
> +  ptrdiff_t stride, \
> +  int flim)
> +
> +#define VP8_LF_HV(inner, opt)   \
> +VP8_LF_Y(h,  inner, opt);   \
> +VP8_LF_Y(v,  inner, opt);   \
> +VP8_LF_UV(h, inner, opt);   \
> +VP8_LF_UV(v, inner, opt)
> +
> +#define VP8_LF(opt) \
> +VP8_LF_HV(,   opt); \
> +VP8_LF_HV(_inner, opt); \
> +VP8_LF_SIMPLE(h, opt);  \
> +VP8_LF_SIMPLE(v, opt)
> +
> +#define VP8_MC(n, opt)  \
> +void ff_put_vp8_##n##_##opt(uint8_t *dst, ptrdiff_t dststride,  \
> +const uint8_t *src, ptrdiff_t srcstride,\
> +int h, int x, int y)
> +
> +#define VP8_EPEL(w, opt)\
> +VP8_MC(pixels ## w, opt);   \
> +VP8_MC(epel ## w ## _h4, opt);  \
> +VP8_MC(epel ## w ## _h6, opt);  \
> +VP8_MC(epel ## w ## _v4, opt);  \
> +VP8_MC(epel ## w ## _h4v4, opt);\
> +VP8_MC(epel ## w ## _h6v4, opt);\
> +VP8_MC(epel ## w ## _v6, opt);  \
> +VP8_MC(epel ## w ## _h4v6, opt);\
> +VP8_MC(epel ## w ## _h6v6, opt)
> +
> +#define VP8_BILIN(w, opt)   \
> +VP8_MC(bilin ## w ## _h, opt);  \
> +VP8_MC(bilin ## w ## _v, opt);  \
> +VP8_MC(bilin ## w ## _hv, opt)
> +
> +#endif /* AVCODEC_RISCV_VP8DSP_H */
> diff --git a/libavcodec/riscv/vp8dsp_init.c
> b/libavcodec/riscv/vp8dsp_init.c
> index af57aabb71..c364de3dc9 100644
> --- a/libavcodec/riscv/vp8dsp_init.c
> +++ b/libavcodec/riscv/vp8dsp_init.c
> @@ -24,11 +24,33 @@
>  #include "libavutil/cpu.h"
>  #include "libavutil/riscv/cpu.h"
>  #include "libavcodec/vp8dsp.h"
> +#include "vp8dsp.h"
>
>  void ff_vp8_idct_dc_add_rvv(uint8_t *dst, int16_t block[16], ptrdiff_t
> stride);
>  void ff_vp8_idct_dc_add4y_rvv(uint8_t *dst, int16_t block[4][16],
> ptrdiff_t stride);
>  void 

[FFmpeg-devel] [PATCH 10/10] lavc/vp8dsp: R-V V loop_filter

[uk7b]

From: sunyuechi 

C908:
vp8_loop_filter8uv_v_c: 745.5
vp8_loop_filter8uv_v_rvv_i32: 467.2
vp8_loop_filter16y_h_c: 674.2
vp8_loop_filter16y_h_rvv_i32: 553.0
vp8_loop_filter16y_v_c: 732.7
vp8_loop_filter16y_v_rvv_i32: 324.5
---
 libavcodec/riscv/vp8dsp_init.c |  4 +++
 libavcodec/riscv/vp8dsp_rvv.S  | 63 ++
 2 files changed, 67 insertions(+)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index aa95021df5..597e6acec8 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -123,6 +123,10 @@ av_cold void ff_vp8dsp_init_riscv(VP8DSPContext *c)
 c->vp8_idct_dc_add4uv = ff_vp8_idct_dc_add4uv_rvv;
 }
 
+c->vp8_v_loop_filter16y = ff_vp8_v_loop_filter16_rvv;
+c->vp8_h_loop_filter16y = ff_vp8_h_loop_filter16_rvv;
+c->vp8_v_loop_filter8uv = ff_vp8_v_loop_filter8uv_rvv;
+
 c->vp8_v_loop_filter16y_inner = ff_vp8_v_loop_filter16_inner_rvv;
 c->vp8_h_loop_filter16y_inner = ff_vp8_h_loop_filter16_inner_rvv;
 c->vp8_v_loop_filter8uv_inner = ff_vp8_v_loop_filter8uv_inner_rvv;
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index f10e269d9d..af28ea5258 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -229,6 +229,39 @@ endfunc
 vsra.vi v24, v24, 1  // (f1 + 1) >> 1;
 vadd.vv v8, v18, v24
 vsub.vv v10, v20, v24
+.else
+li  t5, 27
+li  t3, 9
+li  a7, 18
+vwmul.vxv2, v11, t5
+vwmul.vxv6, v11, t3
+vwmul.vxv4, v11, a7
+
+.ifc \len,16
+vsetvli zero, zero, e16, m2, ta, ma
+.else
+vsetvli zero, zero, e16, m1, ta, ma
+.endif
+
+li  a7, 63
+vzext.vf2   v14, v15 // p2
+vzext.vf2   v24, v10 // q2
+vadd.vx v2, v2, a7
+vadd.vx v4, v4, a7
+vadd.vx v6, v6, a7
+vsra.vi v2, v2, 7// a0
+vsra.vi v12, v4, 7   // a1
+vsra.vi v6, v6, 7// a2
+vadd.vv v14, v14, v6 // p2 + a2
+vsub.vv v22, v24, v6 // q2 - a2
+vsub.vv v10, v20, v12// q1 - a1
+vadd.vv v4, v8, v2   // p0 + a0
+vsub.vv v6, v16, v2  // q0 - a0
+vadd.vv v8, v12, v18 // a1 + p1
+vmax.vx v4, v4, zero
+vmax.vx v6, v6, zero
+vmax.vx v14, v14, zero
+vmax.vx v16, v22, zero
 .endif
 
 vmax.vx v8, v8, zero
@@ -253,6 +286,17 @@ endfunc
 vsse8.v v6, (a6), \stride, v0.t
 vsse8.v v7, (t4), \stride, v0.t
 .endif
+.if !\inner
+vnclipu.wi  v14, v14, 0
+vnclipu.wi  v16, v16, 0
+.ifc \type,v
+vse8.v  v14, (t0), v0.t
+vse8.v  v16, (t6), v0.t
+.else
+vsse8.v v14, (t0), \stride, v0.t
+vsse8.v v16, (t6), \stride, v0.t
+.endif
+.endif
 .endif
 .endm
 
@@ -275,6 +319,25 @@ func ff_vp8_v_loop_filter8uv_inner_rvv, zve32x
 ret
 endfunc
 
+func ff_vp8_v_loop_filter16_rvv, zve32x
+vsetivlizero, 16, e8, m1, ta, ma
+filter 16 v 1 0 a0 a1 a2 a3 a4
+ret
+endfunc
+
+func ff_vp8_h_loop_filter16_rvv, zve32x
+vsetivlizero, 16, e8, m1, ta, ma
+filter 16 h 1 0 a0 a1 a2 a3 a4
+ret
+endfunc
+
+func ff_vp8_v_loop_filter8uv_rvv, zve32x
+vsetivlizero, 8, e8, mf2, ta, ma
+filter 8 v 1 0 a0 a2 a3 a4 a5
+filter 8 v 1 0 a1 a2 a3 a4 a5
+ret
+endfunc
+
 func ff_vp8_v_loop_filter16_simple_rvv, zve32x
 vsetivlizero, 16, e8, m1, ta, ma
 filter 16 v 0 0 a0 a1 a2 a3 a4
-- 
2.45.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 08/10] lavc/vp8dsp: R-V V loop_filter_simple

[uk7b]

From: sunyuechi 

C908:
vp8_loop_filter_simple_h_c: 416.0
vp8_loop_filter_simple_h_rvv_i32: 187.5
vp8_loop_filter_simple_v_c: 429.7
vp8_loop_filter_simple_v_rvv_i32: 104.0
---
 libavcodec/riscv/vp8dsp_init.c |   5 ++
 libavcodec/riscv/vp8dsp_rvv.S  | 105 +
 2 files changed, 110 insertions(+)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index 2dd583d079..46ca71ed04 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -38,6 +38,8 @@ VP8_BILIN(16, rvv);
 VP8_BILIN(8,  rvv);
 VP8_BILIN(4,  rvv);
 
+VP8_LF(rvv);
+
 av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
 {
 #if HAVE_RVV
@@ -120,6 +122,9 @@ av_cold void ff_vp8dsp_init_riscv(VP8DSPContext *c)
 if (flags & AV_CPU_FLAG_RVB_ADDR) {
 c->vp8_idct_dc_add4uv = ff_vp8_idct_dc_add4uv_rvv;
 }
+
+c->vp8_v_loop_filter_simple = ff_vp8_v_loop_filter16_simple_rvv;
+c->vp8_h_loop_filter_simple = ff_vp8_h_loop_filter16_simple_rvv;
 }
 #endif
 }
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index ba644f0f47..2eadfc5766 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -72,6 +72,111 @@ func ff_vp8_idct_dc_add4uv_rvv, zve32x
 ret
 endfunc
 
+.macro filter_fmin len a f1 p0f2 q0f1
+.ifc \len,16
+vsetvli zero, zero, e16, m2, ta, ma
+.else
+vsetvli zero, zero, e16, m1, ta, ma
+.endif
+vsext.vf2   \q0f1, \a
+vmin.vx \p0f2, \q0f1, a7
+vmin.vx \q0f1, \q0f1, t3
+vadd.vi \p0f2, \p0f2, 3
+vadd.vi \q0f1, \q0f1, 4
+vsra.vi \p0f2, \p0f2, 3
+vsra.vi \f1,   \q0f1, 3
+vadd.vv \p0f2, \p0f2, v8
+vsub.vv \q0f1, v16, \f1
+vmax.vx \p0f2, \p0f2, zero
+vmax.vx \q0f1, \q0f1, zero
+.endm
+
+.macro filter len type normal inner dst stride fE fI thresh
+.ifc \type,v
+sllia6, \stride, 1
+sub t2, \dst, a6
+add t4, \dst, \stride
+sub t1, \dst, \stride
+vle8.v  v1, (t2)
+vle8.v  v11, (t4)
+vle8.v  v17, (t1)
+vle8.v  v22, (\dst)
+.else
+addit1, \dst, -1
+addia6, \dst, -2
+addit4, \dst, 1
+vlse8.v v1, (a6), \stride
+vlse8.v v11, (t4), \stride
+vlse8.v v17, (t1), \stride
+vlse8.v v22, (\dst), \stride
+.endif
+vwsubu.vv   v12, v1, v11 // p1-q1
+vwsubu.vv   v24, v22, v17// q0-p0
+vnclip.wi   v23, v12, 0
+
+.ifc \len,16
+vsetvli zero, zero, e16, m2, ta, ma
+.else
+vsetvli zero, zero, e16, m1, ta, ma
+.endif
+
+// vp8_simple_limit(dst + i, stride, flim)
+li  a7, 2
+vneg.v  v18, v12
+vmax.vv v18, v18, v12
+vneg.v  v8, v24
+vmax.vv v8, v8, v24
+vsrl.vi v18, v18, 1
+vmacc.vxv18, a7, v8
+vmsleu.vx   v0, v18, \fE
+
+li  t5, 3
+li  a7, 124
+li  t3, 123
+vsext.vf2   v4, v23
+vzext.vf2   v8, v17  // p0
+vzext.vf2   v16, v22 // q0
+vmul.vx v30, v24, t5
+vadd.vv v12, v30, v4
+
+.ifc \len,16
+vsetvli zero, zero, e8, m1, ta, ma
+.else
+vsetvli zero, zero, e8, mf2, ta, ma
+.endif
+vnclip.wi   v11, v12, 0
+filter_fmin \len v11 v24 v4 v6
+
+.ifc \len,16
+vsetvli zero, zero, e8, m1, ta, ma
+.else
+vsetvli zero, zero, e8, mf2, ta, ma
+.endif
+vnclipu.wi  v4, v4, 0
+vnclipu.wi  v6, v6, 0
+
+.ifc \type,v
+vse8.v  v4, (t1), v0.t
+vse8.v  v6, (\dst), v0.t
+.else
+vsse8.v v4, (t1), \stride, v0.t
+vsse8.v v6, (\dst), \stride, v0.t
+.endif
+
+.endm
+
+func ff_vp8_v_loop_filter16_simple_rvv, zve32x
+vsetivlizero, 16, e8, m1, ta, ma
+filter 16 v 0 0 a0 a1 a2 a3 a4
+ret
+endfunc
+
+func ff_vp8_h_loop_filter16_simple_rvv, zve32x
+vsetivlizero, 16, e8, m1, ta, ma
+filter 16 h 0 0 a0 a1 a2 a3 a4
+ret
+endfunc
+
 .macro put_vp8_pixels
 1:
 addi  a4, a4, -1
-- 
2.45.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 07/10] lavc/vp8dsp: R-V V put_epel hv

[uk7b]

From: sunyuechi 

C908:
vp8_put_epel4_h4v4_c: 20.0
vp8_put_epel4_h4v4_rvv_i32: 11.0
vp8_put_epel4_h4v6_c: 25.2
vp8_put_epel4_h4v6_rvv_i32: 13.5
vp8_put_epel4_h6v4_c: 22.2
vp8_put_epel4_h6v4_rvv_i32: 14.5
vp8_put_epel4_h6v6_c: 29.0
vp8_put_epel4_h6v6_rvv_i32: 15.7
vp8_put_epel8_h4v4_c: 73.0
vp8_put_epel8_h4v4_rvv_i32: 22.2
vp8_put_epel8_h4v6_c: 90.5
vp8_put_epel8_h4v6_rvv_i32: 26.7
vp8_put_epel8_h6v4_c: 85.0
vp8_put_epel8_h6v4_rvv_i32: 27.2
vp8_put_epel8_h6v6_c: 104.7
vp8_put_epel8_h6v6_rvv_i32: 29.5
vp8_put_epel16_h4v4_c: 145.5
vp8_put_epel16_h4v4_rvv_i32: 26.5
vp8_put_epel16_h4v6_c: 190.7
vp8_put_epel16_h4v6_rvv_i32: 47.5
vp8_put_epel16_h6v4_c: 173.7
vp8_put_epel16_h6v4_rvv_i32: 33.2
vp8_put_epel16_h6v6_c: 222.2
vp8_put_epel16_h6v6_rvv_i32: 35.5
---
 libavcodec/riscv/vp8dsp_init.c |  13 
 libavcodec/riscv/vp8dsp_rvv.S  | 124 +++--
 2 files changed, 116 insertions(+), 21 deletions(-)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index 2f123b67fe..2dd583d079 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -92,6 +92,19 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
 c->put_vp8_epel_pixels_tab[0][1][0] = ff_put_vp8_epel16_v4_rvv;
 c->put_vp8_epel_pixels_tab[1][1][0] = ff_put_vp8_epel8_v4_rvv;
 c->put_vp8_epel_pixels_tab[2][1][0] = ff_put_vp8_epel4_v4_rvv;
+
+c->put_vp8_epel_pixels_tab[0][2][2] = ff_put_vp8_epel16_h6v6_rvv;
+c->put_vp8_epel_pixels_tab[1][2][2] = ff_put_vp8_epel8_h6v6_rvv;
+c->put_vp8_epel_pixels_tab[2][2][2] = ff_put_vp8_epel4_h6v6_rvv;
+c->put_vp8_epel_pixels_tab[0][2][1] = ff_put_vp8_epel16_h4v6_rvv;
+c->put_vp8_epel_pixels_tab[1][2][1] = ff_put_vp8_epel8_h4v6_rvv;
+c->put_vp8_epel_pixels_tab[2][2][1] = ff_put_vp8_epel4_h4v6_rvv;
+c->put_vp8_epel_pixels_tab[0][1][1] = ff_put_vp8_epel16_h4v4_rvv;
+c->put_vp8_epel_pixels_tab[1][1][1] = ff_put_vp8_epel8_h4v4_rvv;
+c->put_vp8_epel_pixels_tab[2][1][1] = ff_put_vp8_epel4_h4v4_rvv;
+c->put_vp8_epel_pixels_tab[0][1][2] = ff_put_vp8_epel16_h6v4_rvv;
+c->put_vp8_epel_pixels_tab[1][1][2] = ff_put_vp8_epel8_h6v4_rvv;
+c->put_vp8_epel_pixels_tab[2][1][2] = ff_put_vp8_epel4_h6v4_rvv;
 }
 #endif
 }
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index 440a965ddd..ba644f0f47 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -234,26 +234,26 @@ const subpel_filters
 .byte 0,  -1,  12, 123,  -6, 0
 endconst
 
-.macro epel_filter size type
-lla t2, subpel_filters
+.macro epel_filter size type regtype
+lla \regtype\()2, subpel_filters
 .ifc \type,v
-addit0, a6, -1
+addi\regtype\()0, a6, -1
 .elseif \type == h
-addit0, a5, -1
+addi\regtype\()0, a5, -1
 .endif
-li  t1, 6
-mul t0, t0, t1
-add t0, t0, t2
+li  \regtype\()1, 6
+mul \regtype\()0, \regtype\()0, \regtype\()1
+add \regtype\()0, \regtype\()0, \regtype\()2
 .irp n 1,2,3,4
-lb  t\n, \n(t0)
+lb  \regtype\n, \n(\regtype\()0)
 .endr
 .ifc \size,6
-lb  t5, 5(t0)
-lb  t0, (t0)
+lb  \regtype\()5, 5(\regtype\()0)
+lb  \regtype\()0, (\regtype\()0)
 .endif
 .endm
 
-.macro epel_load dst len size type
+.macro epel_load dst len size type from_mem regtype
 .ifc \type,v
 mv  a5, a3
 .else
@@ -267,19 +267,29 @@ endconst
 vle8.v  v26, (a7)
 add a7, a7, a5
 vle8.v  v28, (a7)
-vwmulu.vx   v16, v24, t2
-vwmulu.vx   v20, v26, t3
+vwmulu.vx   v16, v24, \regtype\()2
+vwmulu.vx   v20, v26, \regtype\()3
 .ifc \size,6
 sub t6, t6, a5
 add a7, a7, a5
 vle8.v  v24, (t6)
 vle8.v  v26, (a7)
-vwmaccu.vx  v16, t0, v24
-vwmaccu.vx  v16, t5, v26
+vwmaccu.vx  v16, \regtype\()0, v24
+vwmaccu.vx  v16, \regtype\()5, v26
+.endif
+vwmaccsu.vx v16, \regtype\()1, v22
+vwmaccsu.vx v16, \regtype\()4, v28
+.else
+vwmulu.vx   v16, v4 , \regtype\()2
+vwmulu.vx   v20, v6 , \regtype\()3
+.ifc \size,6
+vwmaccu.vx  v16, \regtype\()0, v0
+vwmaccu.vx  v16, \regtype\()5, v10
+.endif
+vwmaccsu.vx v16, \regtype\()1, v2
+vwmaccsu.vx v16, \regtype\()4, v8
 .endif
 li  t6, 64
-vwmaccsu.vx v16, t1, v22
-vwmaccsu.vx v16, t4, v28
 vwadd.wxv16, v16, t6
 
 .ifc \len,4
@@ -303,13 +313,13 @@ endconst
   

[FFmpeg-devel] [PATCH 09/10] lavc/vp8dsp: R-V V loop_filter_inner

[uk7b]

From: sunyuechi 

C908:
vp8_loop_filter8uv_inner_v_c: 738.2
vp8_loop_filter8uv_inner_v_rvv_i32: 455.2
vp8_loop_filter16y_inner_h_c: 685.0
vp8_loop_filter16y_inner_h_rvv_i32: 497.0
vp8_loop_filter16y_inner_v_c: 743.7
vp8_loop_filter16y_inner_v_rvv_i32: 295.7
---
 libavcodec/riscv/vp8dsp_init.c |   4 ++
 libavcodec/riscv/vp8dsp_rvv.S  | 110 +
 2 files changed, 114 insertions(+)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index 46ca71ed04..aa95021df5 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -123,6 +123,10 @@ av_cold void ff_vp8dsp_init_riscv(VP8DSPContext *c)
 c->vp8_idct_dc_add4uv = ff_vp8_idct_dc_add4uv_rvv;
 }
 
+c->vp8_v_loop_filter16y_inner = ff_vp8_v_loop_filter16_inner_rvv;
+c->vp8_h_loop_filter16y_inner = ff_vp8_h_loop_filter16_inner_rvv;
+c->vp8_v_loop_filter8uv_inner = ff_vp8_v_loop_filter8uv_inner_rvv;
+
 c->vp8_v_loop_filter_simple = ff_vp8_v_loop_filter16_simple_rvv;
 c->vp8_h_loop_filter_simple = ff_vp8_h_loop_filter16_simple_rvv;
 }
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index 2eadfc5766..f10e269d9d 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -72,6 +72,13 @@ func ff_vp8_idct_dc_add4uv_rvv, zve32x
 ret
 endfunc
 
+.macro filter_abs dst diff fI
+vneg.v  v8, \diff
+vmax.vv \dst, v8, \diff
+vmsleu.vx   v8, \dst, \fI
+vmand.mmv27, v27, v8
+.endm
+
 .macro filter_fmin len a f1 p0f2 q0f1
 .ifc \len,16
 vsetvli zero, zero, e16, m2, ta, ma
@@ -101,6 +108,16 @@ endfunc
 vle8.v  v11, (t4)
 vle8.v  v17, (t1)
 vle8.v  v22, (\dst)
+.if \normal
+sub t3, t2, a6
+sub t0, t1, a6
+add t6, \dst, a6
+add a7, t4, a6
+vle8.v  v2, (t3)
+vle8.v  v15, (t0)
+vle8.v  v10, (t6)
+vle8.v  v14, (a7)
+.endif
 .else
 addit1, \dst, -1
 addia6, \dst, -2
@@ -109,9 +126,28 @@ endfunc
 vlse8.v v11, (t4), \stride
 vlse8.v v17, (t1), \stride
 vlse8.v v22, (\dst), \stride
+.if \normal
+addit5, \dst, -4
+addit0, \dst, -3
+addit6, \dst, 2
+addia7, \dst, 3
+vlse8.v v2, (t5), \stride
+vlse8.v v15, (t0), \stride
+vlse8.v v10, (t6), \stride
+vlse8.v v14, (a7), \stride
+.endif
 .endif
 vwsubu.vv   v12, v1, v11 // p1-q1
 vwsubu.vv   v24, v22, v17// q0-p0
+
+.if \normal
+vwsubu.vv   v30, v1, v17
+vwsubu.vv   v20, v11, v22
+vwsubu.vv   v28, v1, v15
+vwsubu.vv   v4, v2, v15
+vwsubu.vv   v6, v10, v11
+vwsubu.vv   v2, v14, v10
+.endif
 vnclip.wi   v23, v12, 0
 
 .ifc \len,16
@@ -130,6 +166,26 @@ endfunc
 vmacc.vxv18, a7, v8
 vmsleu.vx   v0, v18, \fE
 
+.if \normal
+vneg.v  v18, v30
+vmax.vv v30, v18, v30
+vmsleu.vx   v27, v30, \fI
+filter_abs  v18 v28 \fI
+filter_abs  v18 v4 \fI
+filter_abs  v18 v6 \fI
+filter_abs  v18 v2 \fI
+filter_abs  v20 v20 \fI
+vmand.mmv27, v0, v27 // vp8_simple_limit && normal
+
+vmsgtu.vx   v20, v20, \thresh// hev
+vmsgtu.vx   v3, v30, \thresh
+vmor.mm v3, v3, v20  // v3 = hev: > thresh
+vzext.vf2   v18, v1  // v18 = p1
+vmand.mmv0, v27, v3  // v0 = normal && hev
+vzext.vf2   v20, v11 // v12 = q1
+vmnot.m v3, v3   // v3 = !hv
+.endif
+
 li  t5, 3
 li  a7, 124
 li  t3, 123
@@ -163,8 +219,62 @@ endfunc
 vsse8.v v6, (\dst), \stride, v0.t
 .endif
 
+.if \normal
+vmand.mmv0, v27, v3  // vp8_normal_limit & !hv
+
+.if \inner
+vnclip.wi   v30, v30, 0
+filter_fmin \len v30 v24 v4 v6
+vadd.vi v24, v24, 1
+vsra.vi v24, v24, 1  // (f1 + 1) >> 1;
+vadd.vv v8, v18, v24
+vsub.vv v10, v20, v24
+.endif
+
+vmax.vx v8, v8, zero
+vmax.vx v10, v10, zero
+.ifc \len,16
+vsetvli zero, zero, e8, m1, ta, ma
+.else
+vsetvli zero, zero, e8, mf2, ta, ma
+.endif
+vnclipu.wi  v4, v4, 0
+vnclipu.wi  v5, v6, 0
+

[FFmpeg-devel] [PATCH 06/10] lavc/vp8dsp: R-V V put_epel v

[uk7b]

From: sunyuechi 

C908:
vp8_put_epel4_v4_c: 11.0
vp8_put_epel4_v4_rvv_i32: 5.0
vp8_put_epel4_v6_c: 16.5
vp8_put_epel4_v6_rvv_i32: 6.2
vp8_put_epel8_v4_c: 43.7
vp8_put_epel8_v4_rvv_i32: 11.2
vp8_put_epel8_v6_c: 68.7
vp8_put_epel8_v6_rvv_i32: 13.2
vp8_put_epel16_v4_c: 92.5
vp8_put_epel16_v4_rvv_i32: 13.7
vp8_put_epel16_v6_c: 135.7
vp8_put_epel16_v6_rvv_i32: 16.5
---
 libavcodec/riscv/vp8dsp_init.c |  7 ++
 libavcodec/riscv/vp8dsp_rvv.S  | 46 +++---
 2 files changed, 39 insertions(+), 14 deletions(-)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index 6614d661f7..2f123b67fe 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -85,6 +85,13 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
 c->put_vp8_epel_pixels_tab[0][0][1] = ff_put_vp8_epel16_h4_rvv;
 c->put_vp8_epel_pixels_tab[1][0][1] = ff_put_vp8_epel8_h4_rvv;
 c->put_vp8_epel_pixels_tab[2][0][1] = ff_put_vp8_epel4_h4_rvv;
+
+c->put_vp8_epel_pixels_tab[0][2][0] = ff_put_vp8_epel16_v6_rvv;
+c->put_vp8_epel_pixels_tab[1][2][0] = ff_put_vp8_epel8_v6_rvv;
+c->put_vp8_epel_pixels_tab[2][2][0] = ff_put_vp8_epel4_v6_rvv;
+c->put_vp8_epel_pixels_tab[0][1][0] = ff_put_vp8_epel16_v4_rvv;
+c->put_vp8_epel_pixels_tab[1][1][0] = ff_put_vp8_epel8_v4_rvv;
+c->put_vp8_epel_pixels_tab[2][1][0] = ff_put_vp8_epel4_v4_rvv;
 }
 #endif
 }
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index 84e8ec61de..440a965ddd 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -234,9 +234,13 @@ const subpel_filters
 .byte 0,  -1,  12, 123,  -6, 0
 endconst
 
-.macro epel_filter size
+.macro epel_filter size type
 lla t2, subpel_filters
+.ifc \type,v
+addit0, a6, -1
+.elseif \type == h
 addit0, a5, -1
+.endif
 li  t1, 6
 mul t0, t0, t1
 add t0, t0, t2
@@ -249,19 +253,25 @@ endconst
 .endif
 .endm
 
-.macro epel_load dst len size
-addit6, a2, -1
-addia7, a2, 1
+.macro epel_load dst len size type
+.ifc \type,v
+mv  a5, a3
+.else
+li  a5, 1
+.endif
+sub t6, a2, a5
+add a7, a2, a5
+.if \from_mem
 vle8.v  v24, (a2)
 vle8.v  v22, (t6)
 vle8.v  v26, (a7)
-addia7, a7, 1
+add a7, a7, a5
 vle8.v  v28, (a7)
 vwmulu.vx   v16, v24, t2
 vwmulu.vx   v20, v26, t3
 .ifc \size,6
-addit6, t6, -1
-addia7, a7, 1
+sub t6, t6, a5
+add a7, a7, a5
 vle8.v  v24, (t6)
 vle8.v  v26, (a7)
 vwmaccu.vx  v16, t0, v24
@@ -293,13 +303,13 @@ endconst
 vnclipu.wi  \dst, v24, 0
 .endm
 
-.macro epel_load_inc dst len size
-epel_load   \dst \len \size
+.macro epel_load_inc dst len size type
+epel_load   \dst \len \size \type
 add a2, a2, a3
 .endm
 
-.macro epel len size
-epel_filter \size
+.macro epel len size type
+epel_filter \size \type
 
 .ifc \len,4
 vsetivlizero, 4, e8, mf4, ta, ma
@@ -311,7 +321,7 @@ endconst
 
 1:
 addia4, a4, -1
-epel_load_inc   v30 \len \size
+epel_load_inc   v30 \len \size \type
 vse8.v  v30, (a0)
 add a0, a0, a1
 bneza4, 1b
@@ -321,10 +331,18 @@ endconst
 
 .irp len 16,8,4
 func ff_put_vp8_epel\len\()_h6_rvv, zve32x
-epel \len 6
+epel \len 6 h
 endfunc
 
 func ff_put_vp8_epel\len\()_h4_rvv, zve32x
-epel \len 4
+epel \len 4 h
+endfunc
+
+func ff_put_vp8_epel\len\()_v6_rvv, zve32x
+epel \len 6 v
+endfunc
+
+func ff_put_vp8_epel\len\()_v4_rvv, zve32x
+epel \len 4 v
 endfunc
 .endr
-- 
2.45.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 05/10] lavc/vp8dsp: R-V V put_epel h

[uk7b]

From: sunyuechi 

C908:
vp8_put_epel4_h4_c: 10.7
vp8_put_epel4_h4_rvv_i32: 5.0
vp8_put_epel4_h6_c: 15.0
vp8_put_epel4_h6_rvv_i32: 6.2
vp8_put_epel8_h4_c: 43.2
vp8_put_epel8_h4_rvv_i32: 11.2
vp8_put_epel8_h6_c: 57.5
vp8_put_epel8_h6_rvv_i32: 13.5
vp8_put_epel16_h4_c: 92.5
vp8_put_epel16_h4_rvv_i32: 13.7
vp8_put_epel16_h6_c: 139.0
vp8_put_epel16_h6_rvv_i32: 16.5
---
 libavcodec/riscv/vp8dsp_init.c |   7 +++
 libavcodec/riscv/vp8dsp_rvv.S  | 105 +
 2 files changed, 112 insertions(+)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index 02dbda979e..6614d661f7 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -78,6 +78,13 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
 c->put_vp8_bilinear_pixels_tab[2][1][2] = ff_put_vp8_bilin4_hv_rvv;
 c->put_vp8_bilinear_pixels_tab[2][2][1] = ff_put_vp8_bilin4_hv_rvv;
 c->put_vp8_bilinear_pixels_tab[2][2][2] = ff_put_vp8_bilin4_hv_rvv;
+
+c->put_vp8_epel_pixels_tab[0][0][2] = ff_put_vp8_epel16_h6_rvv;
+c->put_vp8_epel_pixels_tab[1][0][2] = ff_put_vp8_epel8_h6_rvv;
+c->put_vp8_epel_pixels_tab[2][0][2] = ff_put_vp8_epel4_h6_rvv;
+c->put_vp8_epel_pixels_tab[0][0][1] = ff_put_vp8_epel16_h4_rvv;
+c->put_vp8_epel_pixels_tab[1][0][1] = ff_put_vp8_epel8_h4_rvv;
+c->put_vp8_epel_pixels_tab[2][0][1] = ff_put_vp8_epel4_h4_rvv;
 }
 #endif
 }
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index 9d4ffed255..84e8ec61de 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -223,3 +223,108 @@ endfunc
 func ff_put_vp8_bilin4_hv_rvv, zve32x
 put_vp8_bilin_hv 4
 endfunc
+
+const subpel_filters
+.byte 0,  -6, 123,  12,  -1, 0
+.byte 2, -11, 108,  36,  -8, 1
+.byte 0,  -9,  93,  50,  -6, 0
+.byte 3, -16,  77,  77, -16, 3
+.byte 0,  -6,  50,  93,  -9, 0
+.byte 1,  -8,  36, 108, -11, 2
+.byte 0,  -1,  12, 123,  -6, 0
+endconst
+
+.macro epel_filter size
+lla t2, subpel_filters
+addit0, a5, -1
+li  t1, 6
+mul t0, t0, t1
+add t0, t0, t2
+.irp n 1,2,3,4
+lb  t\n, \n(t0)
+.endr
+.ifc \size,6
+lb  t5, 5(t0)
+lb  t0, (t0)
+.endif
+.endm
+
+.macro epel_load dst len size
+addit6, a2, -1
+addia7, a2, 1
+vle8.v  v24, (a2)
+vle8.v  v22, (t6)
+vle8.v  v26, (a7)
+addia7, a7, 1
+vle8.v  v28, (a7)
+vwmulu.vx   v16, v24, t2
+vwmulu.vx   v20, v26, t3
+.ifc \size,6
+addit6, t6, -1
+addia7, a7, 1
+vle8.v  v24, (t6)
+vle8.v  v26, (a7)
+vwmaccu.vx  v16, t0, v24
+vwmaccu.vx  v16, t5, v26
+.endif
+li  t6, 64
+vwmaccsu.vx v16, t1, v22
+vwmaccsu.vx v16, t4, v28
+vwadd.wxv16, v16, t6
+
+.ifc \len,4
+vsetvli zero, zero, e16, mf2, ta, ma
+.elseif \len == 8
+vsetvli zero, zero, e16, m1, ta, ma
+.else
+vsetvli zero, zero, e16, m2, ta, ma
+.endif
+
+vwadd.vvv24, v16, v20
+vnsra.wiv24, v24, 7
+vmax.vx v24, v24, zero
+.ifc \len,4
+vsetvli zero, zero, e8, mf4, ta, ma
+.elseif \len == 8
+vsetvli zero, zero, e8, mf2, ta, ma
+.else
+vsetvli zero, zero, e8, m1, ta, ma
+.endif
+vnclipu.wi  \dst, v24, 0
+.endm
+
+.macro epel_load_inc dst len size
+epel_load   \dst \len \size
+add a2, a2, a3
+.endm
+
+.macro epel len size
+epel_filter \size
+
+.ifc \len,4
+vsetivlizero, 4, e8, mf4, ta, ma
+.elseif \len == 8
+vsetivlizero, 8, e8, mf2, ta, ma
+.else
+vsetivlizero, 16, e8, m1, ta, ma
+.endif
+
+1:
+addia4, a4, -1
+epel_load_inc   v30 \len \size
+vse8.v  v30, (a0)
+add a0, a0, a1
+bneza4, 1b
+
+ret
+.endm
+
+.irp len 16,8,4
+func ff_put_vp8_epel\len\()_h6_rvv, zve32x
+epel \len 6
+endfunc
+
+func ff_put_vp8_epel\len\()_h4_rvv, zve32x
+epel \len 4
+endfunc
+.endr
-- 
2.45.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 04/10] lavc/vp8dsp: R-V V put_bilin_hv

[uk7b]

From: sunyuechi 

C908:
vp8_put_bilin4_hv_c: 567.7
vp8_put_bilin4_hv_rvv_i32: 255.7
vp8_put_bilin8_hv_c: 2169.5
vp8_put_bilin8_hv_rvv_i32: 528.7
vp8_put_bilin16_hv_c: 4777.5
vp8_put_bilin16_hv_rvv_i32: 587.7
---
 libavcodec/riscv/vp8dsp_init.c | 13 +
 libavcodec/riscv/vp8dsp_rvv.S  | 35 ++
 2 files changed, 48 insertions(+)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index 10e1498d01..02dbda979e 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -65,6 +65,19 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
 c->put_vp8_bilinear_pixels_tab[1][2][0] = ff_put_vp8_bilin8_v_rvv;
 c->put_vp8_bilinear_pixels_tab[2][1][0] = ff_put_vp8_bilin4_v_rvv;
 c->put_vp8_bilinear_pixels_tab[2][2][0] = ff_put_vp8_bilin4_v_rvv;
+
+c->put_vp8_bilinear_pixels_tab[0][1][1] = ff_put_vp8_bilin16_hv_rvv;
+c->put_vp8_bilinear_pixels_tab[0][1][2] = ff_put_vp8_bilin16_hv_rvv;
+c->put_vp8_bilinear_pixels_tab[0][2][1] = ff_put_vp8_bilin16_hv_rvv;
+c->put_vp8_bilinear_pixels_tab[0][2][2] = ff_put_vp8_bilin16_hv_rvv;
+c->put_vp8_bilinear_pixels_tab[1][1][1] = ff_put_vp8_bilin8_hv_rvv;
+c->put_vp8_bilinear_pixels_tab[1][1][2] = ff_put_vp8_bilin8_hv_rvv;
+c->put_vp8_bilinear_pixels_tab[1][2][1] = ff_put_vp8_bilin8_hv_rvv;
+c->put_vp8_bilinear_pixels_tab[1][2][2] = ff_put_vp8_bilin8_hv_rvv;
+c->put_vp8_bilinear_pixels_tab[2][1][1] = ff_put_vp8_bilin4_hv_rvv;
+c->put_vp8_bilinear_pixels_tab[2][1][2] = ff_put_vp8_bilin4_hv_rvv;
+c->put_vp8_bilinear_pixels_tab[2][2][1] = ff_put_vp8_bilin4_hv_rvv;
+c->put_vp8_bilinear_pixels_tab[2][2][2] = ff_put_vp8_bilin4_hv_rvv;
 }
 #endif
 }
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index a58c197ba1..9d4ffed255 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -188,3 +188,38 @@ func ff_put_vp8_bilin4_v_rvv, zve32x
 vsetivlizero, 4, e8, mf4, ta, ma
 put_vp8_bilin_v
 endfunc
+
+.macro put_vp8_bilin_hv len
+li  t3, 8
+sub t1, t3, a5
+sub t2, t3, a6
+li  t4, 4
+li  t5, 1
+bilin_h_loadv4, \len
+add a2, a2, a3
+1:
+addia4, a4, -1
+vwmulu.vx   v20, v4, t2
+bilin_h_loadv4, \len
+vwmaccu.vx  v20, a6, v4
+vwaddu.wx   v24, v20, t4
+vnsra.wiv0, v24, 3
+vse8.v  v0, (a0)
+add a2, a2, a3
+add a0, a0, a1
+bneza4, 1b
+
+ret
+.endm
+
+func ff_put_vp8_bilin16_hv_rvv, zve32x
+put_vp8_bilin_hv 16
+endfunc
+
+func ff_put_vp8_bilin8_hv_rvv, zve32x
+put_vp8_bilin_hv 8
+endfunc
+
+func ff_put_vp8_bilin4_hv_rvv, zve32x
+put_vp8_bilin_hv 4
+endfunc
-- 
2.45.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 02/10] lavc/vp8dsp: R-V V put_bilin_h

[uk7b]

From: sunyuechi 

C908:
vp8_put_bilin4_h_c: 373.5
vp8_put_bilin4_h_rvv_i32: 158.7
vp8_put_bilin8_h_c: 1437.7
vp8_put_bilin8_h_rvv_i32: 318.7
vp8_put_bilin16_h_c: 2845.7
vp8_put_bilin16_h_rvv_i32: 374.7
---
 libavcodec/riscv/vp8dsp_init.c | 11 +++
 libavcodec/riscv/vp8dsp_rvv.S  | 54 ++
 2 files changed, 65 insertions(+)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index c364de3dc9..32cb4893a4 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -34,6 +34,10 @@ VP8_EPEL(16, rvv);
 VP8_EPEL(8,  rvv);
 VP8_EPEL(4,  rvv);
 
+VP8_BILIN(16, rvv);
+VP8_BILIN(8,  rvv);
+VP8_BILIN(4,  rvv);
+
 av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
 {
 #if HAVE_RVV
@@ -47,6 +51,13 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
 c->put_vp8_bilinear_pixels_tab[0][0][0] = ff_put_vp8_pixels16_rvv;
 c->put_vp8_bilinear_pixels_tab[1][0][0] = ff_put_vp8_pixels8_rvv;
 c->put_vp8_bilinear_pixels_tab[2][0][0] = ff_put_vp8_pixels4_rvv;
+
+c->put_vp8_bilinear_pixels_tab[0][0][1] = ff_put_vp8_bilin16_h_rvv;
+c->put_vp8_bilinear_pixels_tab[0][0][2] = ff_put_vp8_bilin16_h_rvv;
+c->put_vp8_bilinear_pixels_tab[1][0][1] = ff_put_vp8_bilin8_h_rvv;
+c->put_vp8_bilinear_pixels_tab[1][0][2] = ff_put_vp8_bilin8_h_rvv;
+c->put_vp8_bilinear_pixels_tab[2][0][1] = ff_put_vp8_bilin4_h_rvv;
+c->put_vp8_bilinear_pixels_tab[2][0][2] = ff_put_vp8_bilin4_h_rvv;
 }
 #endif
 }
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index 063ab7110c..c8d265e516 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -98,3 +98,57 @@ func ff_put_vp8_pixels4_rvv, zve32x
 vsetivli  zero, 4, e8, mf4, ta, ma
 put_vp8_pixels
 endfunc
+
+.macro bilin_h_load dst len
+.ifc \len,4
+vsetivlizero, 5, e8, mf2, ta, ma
+.elseif \len == 8
+vsetivlizero, 9, e8, m1, ta, ma
+.else
+vsetivlizero, 17, e8, m2, ta, ma
+.endif
+
+vle8.v  \dst, (a2)
+vslide1down.vx  v2, \dst, t5
+
+.ifc \len,4
+vsetivlizero, 4, e8, mf4, ta, ma
+.elseif \len == 8
+vsetivlizero, 8, e8, mf2, ta, ma
+.else
+vsetivlizero, 16, e8, m1, ta, ma
+.endif
+
+vwmulu.vx   v28, \dst, t1
+vwmaccu.vx  v28, a5, v2
+vwaddu.wx   v24, v28, t4
+vnsra.wi\dst, v24, 3
+.endm
+
+.macro put_vp8_bilin_h len
+li  t1, 8
+li  t4, 4
+li  t5, 1
+sub t1, t1, a5
+1:
+addia4, a4, -1
+bilin_h_loadv0, \len
+vse8.v  v0, (a0)
+add a2, a2, a3
+add a0, a0, a1
+bneza4, 1b
+
+ret
+.endm
+
+func ff_put_vp8_bilin16_h_rvv, zve32x
+put_vp8_bilin_h 16
+endfunc
+
+func ff_put_vp8_bilin8_h_rvv, zve32x
+put_vp8_bilin_h 8
+endfunc
+
+func ff_put_vp8_bilin4_h_rvv, zve32x
+put_vp8_bilin_h 4
+endfunc
-- 
2.45.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 01/10] lavc/vp8dsp: R-V V put_vp8_pixels

[uk7b]

From: sunyuechi 

C908:
vp8_put_pixels4_c: 87.5
vp8_put_pixels4_rvv_i32: 42.7
vp8_put_pixels8_c: 284.5
vp8_put_pixels8_rvv_i32: 77.7
vp8_put_pixels16_c: 1087.7
vp8_put_pixels16_rvv_i32: 108.0
---
 libavcodec/riscv/vp8dsp.h  | 75 ++
 libavcodec/riscv/vp8dsp_init.c | 22 ++
 libavcodec/riscv/vp8dsp_rvv.S  | 27 
 libavcodec/vp8dsp.c|  2 +
 libavcodec/vp8dsp.h|  1 +
 5 files changed, 127 insertions(+)
 create mode 100644 libavcodec/riscv/vp8dsp.h

diff --git a/libavcodec/riscv/vp8dsp.h b/libavcodec/riscv/vp8dsp.h
new file mode 100644
index 00..971c5c0a96
--- /dev/null
+++ b/libavcodec/riscv/vp8dsp.h
@@ -0,0 +1,75 @@
+/*
+ * 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 AVCODEC_RISCV_VP8DSP_H
+#define AVCODEC_RISCV_VP8DSP_H
+
+#include "libavcodec/vp8dsp.h"
+
+#define VP8_LF_Y(hv, inner, opt) \
+void ff_vp8_##hv##_loop_filter16##inner##_##opt(uint8_t *dst,\
+ptrdiff_t stride,\
+int flim_E, int flim_I,  \
+int hev_thresh)
+
+#define VP8_LF_UV(hv, inner, opt)\
+void ff_vp8_##hv##_loop_filter8uv##inner##_##opt(uint8_t *dstU,  \
+ uint8_t *dstV,  \
+ ptrdiff_t stride,   \
+ int flim_E, int flim_I, \
+ int hev_thresh)
+
+#define VP8_LF_SIMPLE(hv, opt)  \
+void ff_vp8_##hv##_loop_filter16_simple_##opt(uint8_t *dst, \
+  ptrdiff_t stride, \
+  int flim)
+
+#define VP8_LF_HV(inner, opt)   \
+VP8_LF_Y(h,  inner, opt);   \
+VP8_LF_Y(v,  inner, opt);   \
+VP8_LF_UV(h, inner, opt);   \
+VP8_LF_UV(v, inner, opt)
+
+#define VP8_LF(opt) \
+VP8_LF_HV(,   opt); \
+VP8_LF_HV(_inner, opt); \
+VP8_LF_SIMPLE(h, opt);  \
+VP8_LF_SIMPLE(v, opt)
+
+#define VP8_MC(n, opt)  \
+void ff_put_vp8_##n##_##opt(uint8_t *dst, ptrdiff_t dststride,  \
+const uint8_t *src, ptrdiff_t srcstride,\
+int h, int x, int y)
+
+#define VP8_EPEL(w, opt)\
+VP8_MC(pixels ## w, opt);   \
+VP8_MC(epel ## w ## _h4, opt);  \
+VP8_MC(epel ## w ## _h6, opt);  \
+VP8_MC(epel ## w ## _v4, opt);  \
+VP8_MC(epel ## w ## _h4v4, opt);\
+VP8_MC(epel ## w ## _h6v4, opt);\
+VP8_MC(epel ## w ## _v6, opt);  \
+VP8_MC(epel ## w ## _h4v6, opt);\
+VP8_MC(epel ## w ## _h6v6, opt)
+
+#define VP8_BILIN(w, opt)   \
+VP8_MC(bilin ## w ## _h, opt);  \
+VP8_MC(bilin ## w ## _v, opt);  \
+VP8_MC(bilin ## w ## _hv, opt)
+
+#endif /* AVCODEC_RISCV_VP8DSP_H */
diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index af57aabb71..c364de3dc9 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -24,11 +24,33 @@
 #include "libavutil/cpu.h"
 #include "libavutil/riscv/cpu.h"
 #include "libavcodec/vp8dsp.h"
+#include "vp8dsp.h"
 
 void ff_vp8_idct_dc_add_rvv(uint8_t *dst, int16_t block[16], ptrdiff_t stride);
 void ff_vp8_idct_dc_add4y_rvv(uint8_t *dst, int16_t block[4][16], ptrdiff_t 
stride);
 void ff_vp8_idct_dc_add4uv_rvv(uint8_t *dst, int16_t block[4][16], ptrdiff_t 
stride);
 
+VP8_EPEL(16, rvv);
+VP8_EPEL(8,  rvv);
+VP8_EPEL(4,  rvv);
+
+av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
+{
+#if HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if (flags & 

[FFmpeg-devel] [PATCH 03/10] lavc/vp8dsp: R-V V put_bilin_v

[uk7b]

From: sunyuechi 

C908:
vp8_put_bilin4_v_c: 383.5
vp8_put_bilin4_v_rvv_i32: 139.7
vp8_put_bilin8_v_c: 1455.7
vp8_put_bilin8_v_rvv_i32: 299.7
vp8_put_bilin16_v_c: 2863.7
vp8_put_bilin16_v_rvv_i32: 347.7
---
 libavcodec/riscv/vp8dsp_init.c |  7 +++
 libavcodec/riscv/vp8dsp_rvv.S  | 36 ++
 2 files changed, 43 insertions(+)

diff --git a/libavcodec/riscv/vp8dsp_init.c b/libavcodec/riscv/vp8dsp_init.c
index 32cb4893a4..10e1498d01 100644
--- a/libavcodec/riscv/vp8dsp_init.c
+++ b/libavcodec/riscv/vp8dsp_init.c
@@ -58,6 +58,13 @@ av_cold void ff_vp78dsp_init_riscv(VP8DSPContext *c)
 c->put_vp8_bilinear_pixels_tab[1][0][2] = ff_put_vp8_bilin8_h_rvv;
 c->put_vp8_bilinear_pixels_tab[2][0][1] = ff_put_vp8_bilin4_h_rvv;
 c->put_vp8_bilinear_pixels_tab[2][0][2] = ff_put_vp8_bilin4_h_rvv;
+
+c->put_vp8_bilinear_pixels_tab[0][1][0] = ff_put_vp8_bilin16_v_rvv;
+c->put_vp8_bilinear_pixels_tab[0][2][0] = ff_put_vp8_bilin16_v_rvv;
+c->put_vp8_bilinear_pixels_tab[1][1][0] = ff_put_vp8_bilin8_v_rvv;
+c->put_vp8_bilinear_pixels_tab[1][2][0] = ff_put_vp8_bilin8_v_rvv;
+c->put_vp8_bilinear_pixels_tab[2][1][0] = ff_put_vp8_bilin4_v_rvv;
+c->put_vp8_bilinear_pixels_tab[2][2][0] = ff_put_vp8_bilin4_v_rvv;
 }
 #endif
 }
diff --git a/libavcodec/riscv/vp8dsp_rvv.S b/libavcodec/riscv/vp8dsp_rvv.S
index c8d265e516..a58c197ba1 100644
--- a/libavcodec/riscv/vp8dsp_rvv.S
+++ b/libavcodec/riscv/vp8dsp_rvv.S
@@ -152,3 +152,39 @@ endfunc
 func ff_put_vp8_bilin4_h_rvv, zve32x
 put_vp8_bilin_h 4
 endfunc
+
+.macro put_vp8_bilin_v
+li  t1, 8
+li  t4, 4
+sub t1, t1, a6
+1:
+add t2, a2, a3
+addia4, a4, -1
+vle8.v  v0, (a2)
+vle8.v  v2, (t2)
+vwmulu.vx   v28, v0, t1
+vwmaccu.vx  v28, a6, v2
+vwaddu.wx   v24, v28, t4
+vnsra.wiv0, v24, 3
+vse8.v  v0, (a0)
+add a2, a2, a3
+add a0, a0, a1
+bneza4, 1b
+
+ret
+.endm
+
+func ff_put_vp8_bilin16_v_rvv, zve32x
+vsetivlizero, 16, e8, m1, ta, ma
+put_vp8_bilin_v
+endfunc
+
+func ff_put_vp8_bilin8_v_rvv, zve32x
+vsetivlizero, 8, e8, mf2, ta, ma
+put_vp8_bilin_v
+endfunc
+
+func ff_put_vp8_bilin4_v_rvv, zve32x
+vsetivlizero, 4, e8, mf4, ta, ma
+put_vp8_bilin_v
+endfunc
-- 
2.45.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] 5 year plan & Inovation

[Ondřej Fiala]

On Sat May 4, 2024 at 3:11 AM CEST, flow gg wrote:
> I have tried git-send-email, but it failed. You can say that I am stupid,
> but I would say that this is because of various reasons such as my area and
> the network. It is really not what I can solve.
> Maybe I will spend a lot of energy trying it in the future, but this is
> because I have submitted thousands of lines of code. I don't want to give
> up. If it is from the beginning, it will cause abandonment.
>
> Maybe I am younger here in FFMPEG. I have a lot of good young people around
> me. They all use github/lab by default, and there will be the same problem
> as me, resulting in abandonment.
I feel it's worth pointing out that SourceHut and mailing list-based workflows
are becoming popular in some young-dev circles. I am in my twenties for
reference.

With that said, I did not realize how problematic setting up git send-email
can be with some providers when I wrote what you're replying to. The replies
quite surprised me honestly because when I first set up git send-email, I
was using completely average providers and it was all pretty effortless,
I just adjusted git's config and it worked perfectly.

> I don't really care about the quality between these tools. I think people
> are important. I only want to use it, and I can facilitate the real
> reviewer of Review.
>
> I don't know if I can say my personal feelings here, but I will say:
>
> I feel despised by this passage, which makes me uncomfortable. If you are a
> reviewer, maybe I have no chance to contribute, but anyway, I have made
> some contributions.
>
> > How can anyone use git, but not git send-email? Any decent email provider   
> >
> > has support for external clients over SMTP. And I believe you *can* 
> >
> > actually dictate that people don't attach patches -- if you have control
> > over the mailing list software, you can set up a filter that rejects such
> > emails and auto-replies with instructions on how to send them properly.
> I think I should have the right to contribute
Likewise.

Regarding the part about rejecting patches as attachments, I was specifically
reacting to Rémi claiming that he can't dictate that people don't use them,
which technically he can. I never said it's a good idea, though it might have
sounded that way. Sorry about that.

As I said multiple times, I feel like contributing over email is a lot about
having good tooling. For example, the email client I use treats all parts of
a multipart message the same, so it has no issues replying to text attachments
instead of the message body. As such, there is no difference between attached
patches and patches in the message body with such a client.
___
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] 5 year plan & Inovation

[Ondřej Fiala]

On Fri May 3, 2024 at 7:45 PM CEST, Rémi Denis-Courmont wrote:
> Le perjantaina 3. toukokuuta 2024, 20.30.16 EEST Ondřej Fiala a écrit :
> > > You can't expect the whole community to accomodate your unwillingness to
> > > run a web browser or update a ridiculous underprovisioned computer
> > > system.
> > There is a huge difference between running a web browser and running
> > Firefox/Chrome that you're consistently ignoring. I absolutely don't
> > mind running Lynx... :)
>
> My point is that the requirement for *practical* *use* of an HTML5 web 
> browser 
> are lower than those for compiling, and running the test suite of, FFmpeg.
Performance-wise, you're probably right. I was talking more about
the technological complexity and the fact we have this oligopoly
of a handful of browsers by companies who can afford supporting
their development and you have to use one of them to be able to use
these platforms.

Here again you're saying "HTML5 browser", but the fact is that they don't
work on all HTML5-supporting browsers because of how complex the tech is.

As I said before, GH for example didn't work for me on a well-maintained
(but niche) Firefox fork even though the fork actually did have support
for an impressive amount of modern web technologies, including HTML5. It
just didn't happen to have support for all of it, because frankly that's
impossible unless you're a big company like Mozilla or Google, and so it
didn't work.

The article I linked in a separate reply is a good overview of the immense
technological complexity of modern web tech.

> Sure you can run Links, W3M or NCSA Mosaic with a lot lower requirements, and 
> Gitlab probably does not work under any of those. But the point is that 
> Chromium or Firefox are *not* really limitting factors here.
GitLab is blocking anything that doesn't run JS due to its use of Cloudflare,
and even back when it didn't, not a single portion of it worked without JS
because it uses it for everything.

As I wrote at the beginning of this thread, Gitea is the most accessible
of GitHub-like platforms. It worked well in Pale Moon IIRC and all the
non-interactive parts of the UI (viewing files, issues, pull requests, etc.)
seem to work without JS. I wouldn't expect to be able to submit an issue or
a pull request this way, but it's better than GitHub and much better than
GitLab. Also its UI is faster than GitLab and feels more reasonable.

Please consider it instead of GitLab if you need to transition away from
mailing lists.. I haven't seen any mentions of GitLab features missing
from Gitea, anyway.
___
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] checkasm: Fix h264chroma test name

[uk7b]

From: sunyuechi 

---
 tests/checkasm/h264chroma.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/tests/checkasm/h264chroma.c b/tests/checkasm/h264chroma.c
index 1aa28c2ee1..9579fceab7 100644
--- a/tests/checkasm/h264chroma.c
+++ b/tests/checkasm/h264chroma.c
@@ -53,23 +53,23 @@ static void check_chroma_mc(void)
 randomize_buffers(bit_depth);
 for (int size = 0; size < 4; size++) {
 
-#define CHECK_CHROMA_MC(name)  
   \
-do {   
   \
-if (check_func(h.name## _pixels_tab[size], #name "_mc%d_%d", 1 
<< size, bit_depth)) { \
-for (int x = 0; x < 2; x++) {  
   \
-for (int y = 0; y < 2; y++) {  
   \
-memcpy(dst0, src, 16 * 18 * SIZEOF_PIXEL); 
   \
-memcpy(dst1, src, 16 * 18 * SIZEOF_PIXEL); 
   \
-call_ref(dst0, src, 16 * SIZEOF_PIXEL, 16, x, y);  
   \
-call_new(dst1, src, 16 * SIZEOF_PIXEL, 16, x, y);  
   \
-if (memcmp(dst0, dst1, 16 * 16 * SIZEOF_PIXEL)) {  
   \
-fprintf(stderr, #name ": x:%i, y:%i\n", x, y); 
   \
-fail();
   \
-}  
   \
-bench_new(dst1, src, 16 * SIZEOF_PIXEL, 16, x, y); 
   \
-}  
   \
-}  
   \
-}  
   \
+#define CHECK_CHROMA_MC(name)  
   \
+do {   
   \
+if (check_func(h.name## _pixels_tab[size], #name "_mc%d_%d", 1 
<< (3-size), bit_depth)) { \
+for (int x = 0; x < 2; x++) {  
   \
+for (int y = 0; y < 2; y++) {  
   \
+memcpy(dst0, src, 16 * 18 * SIZEOF_PIXEL); 
   \
+memcpy(dst1, src, 16 * 18 * SIZEOF_PIXEL); 
   \
+call_ref(dst0, src, 16 * SIZEOF_PIXEL, 16, x, y);  
   \
+call_new(dst1, src, 16 * SIZEOF_PIXEL, 16, x, y);  
   \
+if (memcmp(dst0, dst1, 16 * 16 * SIZEOF_PIXEL)) {  
   \
+fprintf(stderr, #name ": x:%i, y:%i\n", x, y); 
   \
+fail();
   \
+}  
   \
+bench_new(dst1, src, 16 * SIZEOF_PIXEL, 16, x, y); 
   \
+}  
   \
+}  
   \
+}  
   \
 } while (0)
 
 CHECK_CHROMA_MC(put_h264_chroma);
-- 
2.45.0

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

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

Re: [FFmpeg-devel] [PATCH] lavc/vc1dsp: R-V V mspel_pixels

[flow gg]

Hi, it's me. I accidentally repeated it but it seems to be correct.

 于2024年5月4日周六 18:01写道：

> From: sunyuechi 
>
> vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_c: 869.7
> vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_rvv_i32: 148.7
> vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_c: 220.5
> vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_rvv_i64: 56.2
> vc1dsp.put_vc1_mspel_pixels_tab[0][0]_c: 523.7
> vc1dsp.put_vc1_mspel_pixels_tab[0][0]_rvv_i32: 82.0
> vc1dsp.put_vc1_mspel_pixels_tab[1][0]_c: 138.5
> vc1dsp.put_vc1_mspel_pixels_tab[1][0]_rvv_i64: 23.7
> ---
>  libavcodec/riscv/vc1dsp_init.c |  8 +
>  libavcodec/riscv/vc1dsp_rvv.S  | 66 ++
>  2 files changed, 74 insertions(+)
>
> diff --git a/libavcodec/riscv/vc1dsp_init.c
> b/libavcodec/riscv/vc1dsp_init.c
> index e47b644f80..610c43a1a3 100644
> --- a/libavcodec/riscv/vc1dsp_init.c
> +++ b/libavcodec/riscv/vc1dsp_init.c
> @@ -29,6 +29,10 @@ void ff_vc1_inv_trans_8x8_dc_rvv(uint8_t *dest,
> ptrdiff_t stride, int16_t *block
>  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);
> +void ff_put_pixels16x16_rvv(uint8_t *dst, const uint8_t *src, ptrdiff_t
> line_size, int rnd);
> +void ff_put_pixels8x8_rvv(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);
> +void ff_avg_pixels8x8_rvv(uint8_t *dst, const uint8_t *src, ptrdiff_t
> line_size, int rnd);
>
>  av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
>  {
> @@ -38,9 +42,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
>  if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
>  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->put_vc1_mspel_pixels_tab[0][0] = ff_put_pixels16x16_rvv;
> +dsp->avg_vc1_mspel_pixels_tab[0][0] = ff_avg_pixels16x16_rvv;
>  if (flags & AV_CPU_FLAG_RVV_I64) {
>  dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
>  dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
> +dsp->put_vc1_mspel_pixels_tab[1][0] = ff_put_pixels8x8_rvv;
> +dsp->avg_vc1_mspel_pixels_tab[1][0] = ff_avg_pixels8x8_rvv;
>  }
>  }
>  #endif
> diff --git a/libavcodec/riscv/vc1dsp_rvv.S b/libavcodec/riscv/vc1dsp_rvv.S
> index 4a00945ead..48244f91aa 100644
> --- a/libavcodec/riscv/vc1dsp_rvv.S
> +++ b/libavcodec/riscv/vc1dsp_rvv.S
> @@ -111,3 +111,69 @@ func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
>  vsse32.v  v0, (a0), a1
>  ret
>  endfunc
> +
> +func ff_put_pixels16x16_rvv, zve32x
> +vsetivli  zero, 16, e8, m1, ta, ma
> +.irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
> +vle8.vv\n, (a1)
> +add   a1, a1, a2
> +.endr
> +vle8.vv31, (a1)
> +.irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
> +vse8.vv\n, (a0)
> +add   a0, a0, a2
> +.endr
> +vse8.vv31, (a0)
> +
> +ret
> +endfunc
> +
> +func ff_put_pixels8x8_rvv, zve64x
> +vsetivli  zero, 8, e8, mf2, ta, ma
> +vlse64.v  v8, (a1), a2
> +vsse64.v  v8, (a0), a2
> +
> +ret
> +endfunc
> +
> +func ff_avg_pixels16x16_rvv, zve32x
> +csrwi vxrm, 0
> +vsetivli  zero, 16, e8, m1, ta, ma
> +lit0, 128
> +
> +.irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
> +vle8.vv\n, (a1)
> +add   a1, a1, a2
> +.endr
> +vle8.vv31, (a1)
> +.irp n 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
> +vle8.vv\n, (a0)
> +add   a0, a0, a2
> +.endr
> +vle8.vv15, (a0)
> +vsetvli   zero, t0, e8, m8, ta, ma
> +vaaddu.vv v0, v0, v16
> +vaaddu.vv v8, v8, v24
> +vsetivli  zero, 16, e8, m1, ta, ma
> +.irp n  15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
> +vse8.vv\n, (a0)
> +sub   a0, a0, a2
> +.endr
> +vse8.vv0, (a0)
> +
> +ret
> +endfunc
> +
> +func ff_avg_pixels8x8_rvv, zve64x
> +csrwi vxrm, 0
> +lit0, 64
> +vsetivli  zero, 8, e8, mf2, ta, ma
> +vlse64.v  v16, (a1), a2
> +vlse64.v  v8, (a0), a2
> +vsetvli   zero, t0, e8, m4, ta, ma
> +vaaddu.vv v16, v16, v8
> +vsetivli  zero, 8, e8, mf2, ta, ma
> +vsse64.v  v16, (a0), a2
> +
> +ret
> +endfunc
> --
> 2.45.0
>
> ___

[FFmpeg-devel] [PATCH] lavc/vc1dsp: R-V V mspel_pixels

[uk7b]

From: sunyuechi 

vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_c: 869.7
vc1dsp.avg_vc1_mspel_pixels_tab[0][0]_rvv_i32: 148.7
vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_c: 220.5
vc1dsp.avg_vc1_mspel_pixels_tab[1][0]_rvv_i64: 56.2
vc1dsp.put_vc1_mspel_pixels_tab[0][0]_c: 523.7
vc1dsp.put_vc1_mspel_pixels_tab[0][0]_rvv_i32: 82.0
vc1dsp.put_vc1_mspel_pixels_tab[1][0]_c: 138.5
vc1dsp.put_vc1_mspel_pixels_tab[1][0]_rvv_i64: 23.7
---
 libavcodec/riscv/vc1dsp_init.c |  8 +
 libavcodec/riscv/vc1dsp_rvv.S  | 66 ++
 2 files changed, 74 insertions(+)

diff --git a/libavcodec/riscv/vc1dsp_init.c b/libavcodec/riscv/vc1dsp_init.c
index e47b644f80..610c43a1a3 100644
--- a/libavcodec/riscv/vc1dsp_init.c
+++ b/libavcodec/riscv/vc1dsp_init.c
@@ -29,6 +29,10 @@ void ff_vc1_inv_trans_8x8_dc_rvv(uint8_t *dest, ptrdiff_t 
stride, int16_t *block
 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);
+void ff_put_pixels16x16_rvv(uint8_t *dst, const uint8_t *src, ptrdiff_t 
line_size, int rnd);
+void ff_put_pixels8x8_rvv(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);
+void ff_avg_pixels8x8_rvv(uint8_t *dst, const uint8_t *src, ptrdiff_t 
line_size, int rnd);
 
 av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
 {
@@ -38,9 +42,13 @@ av_cold void ff_vc1dsp_init_riscv(VC1DSPContext *dsp)
 if (flags & AV_CPU_FLAG_RVV_I32 && ff_get_rv_vlenb() >= 16) {
 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->put_vc1_mspel_pixels_tab[0][0] = ff_put_pixels16x16_rvv;
+dsp->avg_vc1_mspel_pixels_tab[0][0] = ff_avg_pixels16x16_rvv;
 if (flags & AV_CPU_FLAG_RVV_I64) {
 dsp->vc1_inv_trans_8x8_dc = ff_vc1_inv_trans_8x8_dc_rvv;
 dsp->vc1_inv_trans_8x4_dc = ff_vc1_inv_trans_8x4_dc_rvv;
+dsp->put_vc1_mspel_pixels_tab[1][0] = ff_put_pixels8x8_rvv;
+dsp->avg_vc1_mspel_pixels_tab[1][0] = ff_avg_pixels8x8_rvv;
 }
 }
 #endif
diff --git a/libavcodec/riscv/vc1dsp_rvv.S b/libavcodec/riscv/vc1dsp_rvv.S
index 4a00945ead..48244f91aa 100644
--- a/libavcodec/riscv/vc1dsp_rvv.S
+++ b/libavcodec/riscv/vc1dsp_rvv.S
@@ -111,3 +111,69 @@ func ff_vc1_inv_trans_4x4_dc_rvv, zve32x
 vsse32.v  v0, (a0), a1
 ret
 endfunc
+
+func ff_put_pixels16x16_rvv, zve32x
+vsetivli  zero, 16, e8, m1, ta, ma
+.irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
+vle8.vv\n, (a1)
+add   a1, a1, a2
+.endr
+vle8.vv31, (a1)
+.irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
+vse8.vv\n, (a0)
+add   a0, a0, a2
+.endr
+vse8.vv31, (a0)
+
+ret
+endfunc
+
+func ff_put_pixels8x8_rvv, zve64x
+vsetivli  zero, 8, e8, mf2, ta, ma
+vlse64.v  v8, (a1), a2
+vsse64.v  v8, (a0), a2
+
+ret
+endfunc
+
+func ff_avg_pixels16x16_rvv, zve32x
+csrwi vxrm, 0
+vsetivli  zero, 16, e8, m1, ta, ma
+lit0, 128
+
+.irp n 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30
+vle8.vv\n, (a1)
+add   a1, a1, a2
+.endr
+vle8.vv31, (a1)
+.irp n 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14
+vle8.vv\n, (a0)
+add   a0, a0, a2
+.endr
+vle8.vv15, (a0)
+vsetvli   zero, t0, e8, m8, ta, ma
+vaaddu.vv v0, v0, v16
+vaaddu.vv v8, v8, v24
+vsetivli  zero, 16, e8, m1, ta, ma
+.irp n  15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
+vse8.vv\n, (a0)
+sub   a0, a0, a2
+.endr
+vse8.vv0, (a0)
+
+ret
+endfunc
+
+func ff_avg_pixels8x8_rvv, zve64x
+csrwi vxrm, 0
+lit0, 64
+vsetivli  zero, 8, e8, mf2, ta, ma
+vlse64.v  v16, (a1), a2
+vlse64.v  v8, (a0), a2
+vsetvli   zero, t0, e8, m4, ta, ma
+vaaddu.vv v16, v16, v8
+vsetivli  zero, 8, e8, mf2, ta, ma
+vsse64.v  v16, (a0), a2
+
+ret
+endfunc
-- 
2.45.0

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

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

Re: [FFmpeg-devel] [PATCH 4/5] avcodec/dovi_rpuenc: Initialize bl_compat_id

[Andreas Rheinhardt]

Michael Niedermayer:
> On Sat, May 04, 2024 at 12:21:03AM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> Fixes: CID1596607 Uninitialized scalar variable
>>>
>>> Sponsored-by: Sovereign Tech Fund
>>> Signed-off-by: Michael Niedermayer 
>>> ---
>>>  libavcodec/dovi_rpuenc.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
>>> index 7e0292533bd..c5e452957b5 100644
>>> --- a/libavcodec/dovi_rpuenc.c
>>> +++ b/libavcodec/dovi_rpuenc.c
>>> @@ -57,7 +57,7 @@ int ff_dovi_configure(DOVIContext *s, AVCodecContext 
>>> *avctx)
>>>  AVDOVIDecoderConfigurationRecord *cfg;
>>>  const AVDOVIRpuDataHeader *hdr = NULL;
>>>  const AVFrameSideData *sd;
>>> -int dv_profile, dv_level, bl_compat_id;
>>> +int dv_profile, dv_level, bl_compat_id = -1;
>>>  size_t cfg_size;
>>>  uint64_t pps;
>>>  
>>
>> This is unnecessary, as the dv_profile switch is exhaustive (i.e. the
>> default case is never taken); but if you do this, then you can also
>> remove the other "bl_compat_id = -1" assignments (which conveys that
>> everything is treated as invalid unless we found it to have a valid
>> compatibility id).
> 
> i see
> case AV_CODEC_ID_H264: dv_profile = 9;  break;
> 
> the dv_profile switch only contains 0 4 7 5 10 8 no 9
> 
> what am i missing ?
> 

Ok, I was wrong. (Well, I could counter that ff_dovi_configure() is
currently not called for H.264 at all, but it would be a waste of time.)

- Andreas

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

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

Re: [FFmpeg-devel] [PATCH v3] avformat/framecrcenc: compute the checksum for side data

[Marton Balint]

On Thu, 2 May 2024, James Almer wrote:


On 5/2/2024 6:23 PM, Marton Balint wrote:



 On Wed, 1 May 2024, Michael Niedermayer wrote:


 This allows detecting issues in side data related code, same as what
 framecrc does for before already for packet data itself.

 This basically reverts c6ae560a18d67b9ddaa25a0338b7fb55e3312e57.


 Can you at least add an option which allows disabling dumping the side
 data? Changing the format of framecrc output again and again is not very 


The framehash/framemd5 muxer is versioned, which is what you should use if 
you want parseable output.


Okay, but then the question is that why framecrc is using different code 
and options?


Regards,
Marton
___
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".