Re: [FFmpeg-devel] [PATCH] bsf: use standard include paths

[Anton Khirnov]

Quoting James Almer (2024-04-10 03:23:46)
> On 4/9/2024 10:11 PM, Andrew Kelley wrote:
> > On 4/9/24 17:04, Lynne wrote:
> >> LGTM.
> >> That's how I wrote the AAC patchset as well.
> > 
> > Thank you for the review, Lynne.
> > 
> > What is the next step? I do not have commit access.
> 
> Applied it, thanks.

WTF?

Please revert immediately.

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

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

[FFmpeg-devel] [PATCH v2 2/2] lavfi/vaapi_vpp: Use dynamic frame pool in outlink if possible

[Xiang, Haihao]

From: Haihao Xiang 

This can avoid to exhaust the buffers within outlink when libva2 is
available.

For example:
$ ffmpeg -hwaccel_output_format vaapi -hwaccel vaapi -i input.mp4 \
-vf 'scale_vaapi=w=720:h=480' -c:v hevc_vaapi -f null -
...
[vf#0:0 @ 0x55acad91f400] Error while filtering: Cannot allocate memory
[vf#0:0 @ 0x55acad91f400] Task finished with error code: -12 (Cannot
allocate memory)
[vf#0:0 @ 0x55acad91f400] Terminating thread with return code -12
(Cannot allocate memory)

Signed-off-by: Haihao Xiang 
---
 libavfilter/vaapi_vpp.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
index ace1153a23..9ef7a289fb 100644
--- a/libavfilter/vaapi_vpp.c
+++ b/libavfilter/vaapi_vpp.c
@@ -204,7 +204,10 @@ int ff_vaapi_vpp_config_output(AVFilterLink *outlink)
 output_frames->width = ctx->output_width;
 output_frames->height= ctx->output_height;
 
-output_frames->initial_pool_size = 4;
+if (CONFIG_VAAPI_1)
+output_frames->initial_pool_size = 0;
+else
+output_frames->initial_pool_size = 4;
 
 err = ff_filter_init_hw_frames(avctx, outlink, 10);
 if (err < 0)
@@ -220,6 +223,8 @@ int ff_vaapi_vpp_config_output(AVFilterLink *outlink)
 va_frames = output_frames->hwctx;
 
 av_assert0(ctx->va_context == VA_INVALID_ID);
+av_assert0(output_frames->initial_pool_size ||
+   (va_frames->surface_ids == NULL && va_frames->nb_surfaces == 
0));
 vas = vaCreateContext(ctx->hwctx->display, ctx->va_config,
   ctx->output_width, ctx->output_height,
   VA_PROGRESSIVE,
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH v2 1/2] lavc/vaapi_decode: Use dynamic frame pool if possible

[Xiang, Haihao]

From: Haihao Xiang 

libva2 doesn't require a fixed surface-array any more, so we may use
dynamic frame pool for decoding when libva2 is available, which allows a
downstream element stores more frames from VAAPI decoders and fixes the
error below:

$ ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi \
-i input.mp4 -c:v hevc_vaapi -f null -
...
[h264 @ 0x557a075a1400] get_buffer() failed
[h264 @ 0x557a075a1400] thread_get_buffer() failed
[h264 @ 0x557a075a1400] decode_slice_header error
[h264 @ 0x557a075a1400] no frame!

Signed-off-by: Haihao Xiang 
---
 libavcodec/vaapi_decode.c | 36 
 1 file changed, 20 insertions(+), 16 deletions(-)

diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 5665639dd7..21b273cd0f 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -599,22 +599,26 @@ static int vaapi_decode_make_config(AVCodecContext *avctx,
 if (err < 0)
 goto fail;
 
-frames->initial_pool_size = 1;
-// Add per-codec number of surfaces used for storing reference frames.
-switch (avctx->codec_id) {
-case AV_CODEC_ID_H264:
-case AV_CODEC_ID_HEVC:
-case AV_CODEC_ID_AV1:
-frames->initial_pool_size += 16;
-break;
-case AV_CODEC_ID_VP9:
-frames->initial_pool_size += 8;
-break;
-case AV_CODEC_ID_VP8:
-frames->initial_pool_size += 3;
-break;
-default:
-frames->initial_pool_size += 2;
+if (CONFIG_VAAPI_1)
+frames->initial_pool_size = 0;
+else {
+frames->initial_pool_size = 1;
+// Add per-codec number of surfaces used for storing reference 
frames.
+switch (avctx->codec_id) {
+case AV_CODEC_ID_H264:
+case AV_CODEC_ID_HEVC:
+case AV_CODEC_ID_AV1:
+frames->initial_pool_size += 16;
+break;
+case AV_CODEC_ID_VP9:
+frames->initial_pool_size += 8;
+break;
+case AV_CODEC_ID_VP8:
+frames->initial_pool_size += 3;
+break;
+default:
+frames->initial_pool_size += 2;
+}
 }
 }
 
-- 
2.34.1

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

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

[FFmpeg-devel] I dont know asm too well =( but I have a tip: mem+sync and machine learning

[Jon Maser]

i got this idea from postresql, a very small sql database server

i see ffmpeg is broken down into optimized asm libraries for embedding
in c etc programs, and i know a few things about asm, ie, hardware
registers on cpu+, pump in data into a register, get data out, think
it goes down the system bus

but i was thinking someone could implement an upload to memory feature
when uploading/decoding (kinda like a buffer, maybe a queue? add
matrix field of vid, range of tiles, algorithm.. pop when done,
algorithm etc ,  ) video and audio using asm, and implement a sync
mechanism (basically a queue of registers from the matrice with data
you need to process for stuff like deinterlace or fast moving video )

dont know how av is synced, maybe you can implement a buffer and a
stream pointer system?

you can do (i surmise)

scale_cuda_register_with_image img, offset

or

upload to memory
scale_cuda register_with_image image, offset
upscale_cuda_register_with_image image,  offset
sync

you can also use machine learning, which deals with matrices and i
think hardware estimation of certain numbers

it can also work well in writing/reading files, but now that i think
of it c/dma allows you to upload data to the memory and access it
until its freed, but you can do stuff like stream data into pointers,
maybe that helps, would like

it wont give a major preformance gain, but im hoping for the best


hopefully that works, ffmpeg is good software! cant wait to hit usenet B)
___
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] Query from Reuters on XZ, open source, and Microsoft

[Romain Beauxis]

Le mar. 9 avr. 2024 à 18:46, Paul B Mahol  a écrit :

> On Tue, Apr 9, 2024 at 10:57 PM Romain Beauxis 
> wrote:
>
> > [Apologies for continuing the conversation, Rémi]
> >
> > Le mar. 9 avr. 2024 à 14:05, Tomas Härdin  a écrit :
> >
> > > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis:
> > > > On Wed, Apr 3, 2024, 11:39 Kieran Kunhya via ffmpeg-devel <
> > > > ffmpeg-devel@ffmpeg.org> wrote:
> > > >
> > > > > Hi Raphael,
> > > > >
> > > > > I was the author of the tweet and I gave a short talk about this
> > > > > topic at
> > > > > Demuxed at a video conference last year:
> > > > > https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s
> > > > >
> > > > > That said this is a community project and it would be best to
> > > > > continue the
> > > > > discussion on this mailing list unless agreed otherwise.
> > > > >
> > > >
> > > > Thank you for sharing your talk. It's indeed unfortunate that large
> > > > companies are not more generous with the projects they depend on
> > > > _heavily_
> > > >
> > > > I would like to offer a constructive feedback really not intended as
> > > > trolling. I believe that supporting a more modern development
> > > > workflow such
> > > > as the GitHub PR or gitlab MR would go very long way in helping
> > > > onboarding
> > > > new developers.
> > >
> > > Considering which company owns GitHub and which company was the target
> > > of Kieran's criticism, this seems ill-adviced
> > >
> >
> > Would you mind explaining what you mean exactly? I want to respond but
> I'm
> > not sure if I fully understand your point here.
> >
> >
> Kieran's criticism is trolling, as Kieran and rest of FFmpeg devs use
> regularly and passionately Various Big Corpo products all the time.
>
> Kieran's criticism is unfounded one. As I, originally 'volunteered' in that
> now 'famous' ticket about Certain Big Corpo bug report and kindly replied
> in friendly manner to bug reporter and give reporter free support, me still
> see no issues in that mine action.
>
> I strictly do make difference between collective and single specific
> person.
>


Thanks for the clarification, that's a level of nuance I did not grasp.

>
> > > Also as someone who had to maintain a Gitlab instance at uni for a
> > > couple of years, I agree with Rémi's points
> > >
> >
> > My initial contribution was motivated by the argument presented in the
> > original talk that bringing new blood is critical to the survival of the
> > project.
> >
>
> Projects go and die, and new ones rise up, all the time.
>
>
> >
> > If so, then I do believe that there must be a compromise to be made
> between
> > being easier to join for new developers and changing the existing
> workflow.
> > I'm also aware that changing the existing workflow has been discussed
> > before.
> >
> > I don't think that media is not cool anymore, as argued in the talk. I
> see
> > a _lot_ of interested developers in my other projects and all over the
> open
> > source landscape. That's why I believe that it's also important to
> consider
> > other reasons than the talk's argument.
> >
> > Being someone actually trying to contribute, with years of developers
> > experience and involvement in other communities, I was thinking that I
> may
> > be able to bring in more new context to the topic.
> >
> > If there's interest in continuing the discussion, could you or Rémi be
> > willing to explain what kind of burden gitlab would add?
> >
>
> Infrastructure maintenance, no volunteers for gitlab repo admin.
> Extra steps to setup account and X-factor authentication.
>
>
You have a little bit of a bias issue here I believe. :-)

If you restrict the contributors only to people who can do git send-email
and irc then, of course, you won't find many volunteers to maintain a
gitlab repo. And, of course, the majority of the people voicing their
opinion will be in favor of what they're already familiar with.

There's always a learning curve to adopting new tools. Matter of fact, I'm
old enough to remember myself complaining about git when it was taking over
SVN.. 


> >
> > Also, Rémi said this would make it harder to join the project, in which
> way
> > exactly?
> >
> > Otherwise, I'm happy to let this die and return to trying to get my patch
> > committed.. 
> >
> > Thanks,
> > -- Romain
> > ___
> > 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 

Re: [FFmpeg-devel] [PATCH v2 16/17] fftools/ffmpeg_filter: propagate codec yuv metadata to filters

[Michael Niedermayer]

On Mon, Apr 08, 2024 at 02:57:20PM +0200, Niklas Haas wrote:
> From: Niklas Haas 
> 
> To convert between color spaces/ranges, if needed by the codec
> properties.
> ---
>  fftools/ffmpeg_filter.c | 34 ++
>  1 file changed, 34 insertions(+)

I presume this is intended to change some cases
iam asking because it does
for example, this one
-i aletrek.mkv -t 1 -bitexact  /tmp/file-aletrek-palette.mkv
has the output file change slightly

https://trac.ffmpeg.org/attachment/ticket/5071/aletrek.mkv

also given fate does not change, it would make sense to add a testcase
to fate that does cover this

thx

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

What does censorship reveal? It reveals fear. -- Julian Assange


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] bsf: use standard include paths

[James Almer]

On 4/9/2024 10:11 PM, Andrew Kelley wrote:

On 4/9/24 17:04, Lynne wrote:

LGTM.
That's how I wrote the AAC patchset as well.


Thank you for the review, Lynne.

What is the next step? I do not have commit access.


Applied it, 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] [PATCH v2 14/17] fftools/ffmpeg_filter: simplify choose_pix_fmts

[Michael Niedermayer]

On Mon, Apr 08, 2024 at 02:57:18PM +0200, Niklas Haas wrote:
> From: Niklas Haas 
> 
> The only meaningful difference between choose_pix_fmts and the default
> code was the inclusion of an extra branch for `keep_pix_fmt` being true.
> 
> However, in this case, we either:
> 1. Force the specific `ofp->format` that we inherited from
>ofilter_bind_ost, or if no format was set:
> 2. Print an empty format list
> 
> Both of these goals can be accomplished by simply moving the decision
> logic to ofilter_bind_ost, to avoid setting any format list when
> keep_pix_fmt is enabled. This is arguably cleaner as it moves format
> selection logic to a single function. In the case of branch 1, nothing
> else needs to be done as we already force the format provided in
> ofp->format, if any is set. Add an assertion to verify this assumption
> just in case.
> 
> (Side note: The "choose_*" family of functions are arguably misnomers,
> as they should really be called "print_*" - their current behavior is to
> print the relevant format lists to the `vf/af_format` filter arguments)
> ---
>  fftools/ffmpeg_filter.c | 49 -
>  1 file changed, 9 insertions(+), 40 deletions(-)

breaks:
./ffmpeg -y -i fate-suite/lena.pnm -pix_fmt +yuv444p -vf scale -strict -1 
-bitexact -threads 2 -thread_type slice /tmp/file-2s-444.jpg

Press [q] to stop, [?] for help
Assertion !ost->keep_pix_fmt || (!ofp->format && !ofp->formats) failed at 
fftools/ffmpeg_filter.c:1314
Aborted (core dumped)


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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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] bsf: use standard include paths

[Andrew Kelley]

On 4/9/24 17:04, Lynne wrote:

LGTM.
That's how I wrote the AAC patchset as well.


Thank you for the review, Lynne.

What is the next step? I do not have commit access.
___
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] bsf: use standard include paths

[Lynne]

Apr 9, 2024, 23:24 by and...@ziglang.org:

> Removes the special -I flag specified in the avcodec/bsf/ subdirectory.
>
> This makes code copy-pastable to other parts of the ffmpeg codebase, as
> well as simplifying the build script.
>
> It also reduces ambiguity, since there are many instances of same-named
> header files existing in both libavformat/ and libavcodec/
> subdirectories.
> ---
>  libavcodec/bsf/Makefile   |  2 --
>  libavcodec/bsf/aac_adtstoasc.c| 16 
>  libavcodec/bsf/av1_frame_merge.c  |  8 
>  libavcodec/bsf/av1_frame_split.c  |  8 
>  libavcodec/bsf/av1_metadata.c | 10 +-
>  libavcodec/bsf/chomp.c|  4 ++--
>  libavcodec/bsf/dca_core.c |  8 
>  libavcodec/bsf/dts2pts.c  | 12 ++--
>  libavcodec/bsf/dump_extradata.c   |  4 ++--
>  libavcodec/bsf/dv_error_marker.c  |  4 ++--
>  libavcodec/bsf/eac3_core.c|  8 
>  libavcodec/bsf/evc_frame_merge.c  | 12 ++--
>  libavcodec/bsf/extract_extradata.c| 22 +++---
>  libavcodec/bsf/filter_units.c |  6 +++---
>  libavcodec/bsf/h264_metadata.c| 20 ++--
>  libavcodec/bsf/h264_mp4toannexb.c | 10 +-
>  libavcodec/bsf/h264_redundant_pps.c   | 16 
>  libavcodec/bsf/h265_metadata.c| 16 
>  libavcodec/bsf/h266_metadata.c| 12 ++--
>  libavcodec/bsf/hapqa_extract.c|  8 
>  libavcodec/bsf/hevc_mp4toannexb.c | 10 +-
>  libavcodec/bsf/imx_dump_header.c  |  6 +++---
>  libavcodec/bsf/media100_to_mjpegb.c   |  6 +++---
>  libavcodec/bsf/mjpeg2jpeg.c   |  8 
>  libavcodec/bsf/mjpega_dump_header.c   |  8 
>  libavcodec/bsf/movsub.c   |  4 ++--
>  libavcodec/bsf/mpeg2_metadata.c   | 12 ++--
>  libavcodec/bsf/mpeg4_unpack_bframes.c |  8 
>  libavcodec/bsf/noise.c|  4 ++--
>  libavcodec/bsf/null.c |  2 +-
>  libavcodec/bsf/opus_metadata.c|  4 ++--
>  libavcodec/bsf/pcm_rechunk.c  |  4 ++--
>  libavcodec/bsf/pgs_frame_merge.c  |  4 ++--
>  libavcodec/bsf/prores_metadata.c  |  4 ++--
>  libavcodec/bsf/remove_extradata.c | 14 +++---
>  libavcodec/bsf/setts.c|  4 ++--
>  libavcodec/bsf/showinfo.c |  4 ++--
>  libavcodec/bsf/trace_headers.c|  6 +++---
>  libavcodec/bsf/truehd_core.c  | 10 +-
>  libavcodec/bsf/vp9_metadata.c | 10 +-
>  libavcodec/bsf/vp9_raw_reorder.c  |  8 
>  libavcodec/bsf/vp9_superframe.c   |  6 +++---
>  libavcodec/bsf/vp9_superframe_split.c |  8 
>  libavcodec/bsf/vvc_mp4toannexb.c  | 10 +-
>  44 files changed, 184 insertions(+), 186 deletions(-)
>

LGTM.
That's how I wrote the AAC patchset as well.
___
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] Query from Reuters on XZ, open source, and Microsoft

[Paul B Mahol]

On Tue, Apr 9, 2024 at 10:57 PM Romain Beauxis 
wrote:

> [Apologies for continuing the conversation, Rémi]
>
> Le mar. 9 avr. 2024 à 14:05, Tomas Härdin  a écrit :
>
> > mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis:
> > > On Wed, Apr 3, 2024, 11:39 Kieran Kunhya via ffmpeg-devel <
> > > ffmpeg-devel@ffmpeg.org> wrote:
> > >
> > > > Hi Raphael,
> > > >
> > > > I was the author of the tweet and I gave a short talk about this
> > > > topic at
> > > > Demuxed at a video conference last year:
> > > > https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s
> > > >
> > > > That said this is a community project and it would be best to
> > > > continue the
> > > > discussion on this mailing list unless agreed otherwise.
> > > >
> > >
> > > Thank you for sharing your talk. It's indeed unfortunate that large
> > > companies are not more generous with the projects they depend on
> > > _heavily_
> > >
> > > I would like to offer a constructive feedback really not intended as
> > > trolling. I believe that supporting a more modern development
> > > workflow such
> > > as the GitHub PR or gitlab MR would go very long way in helping
> > > onboarding
> > > new developers.
> >
> > Considering which company owns GitHub and which company was the target
> > of Kieran's criticism, this seems ill-adviced
> >
>
> Would you mind explaining what you mean exactly? I want to respond but I'm
> not sure if I fully understand your point here.
>
>
Kieran's criticism is trolling, as Kieran and rest of FFmpeg devs use
regularly and passionately Various Big Corpo products all the time.

Kieran's criticism is unfounded one. As I, originally 'volunteered' in that
now 'famous' ticket about Certain Big Corpo bug report and kindly replied
in friendly manner to bug reporter and give reporter free support, me still
see no issues in that mine action.

I strictly do make difference between collective and single specific person.


>
> > Also as someone who had to maintain a Gitlab instance at uni for a
> > couple of years, I agree with Rémi's points
> >
>
> My initial contribution was motivated by the argument presented in the
> original talk that bringing new blood is critical to the survival of the
> project.
>

Projects go and die, and new ones rise up, all the time.


>
> If so, then I do believe that there must be a compromise to be made between
> being easier to join for new developers and changing the existing workflow.
> I'm also aware that changing the existing workflow has been discussed
> before.
>
> I don't think that media is not cool anymore, as argued in the talk. I see
> a _lot_ of interested developers in my other projects and all over the open
> source landscape. That's why I believe that it's also important to consider
> other reasons than the talk's argument.
>
> Being someone actually trying to contribute, with years of developers
> experience and involvement in other communities, I was thinking that I may
> be able to bring in more new context to the topic.
>
> If there's interest in continuing the discussion, could you or Rémi be
> willing to explain what kind of burden gitlab would add?
>

Infrastructure maintenance, no volunteers for gitlab repo admin.
Extra steps to setup account and X-factor authentication.


>
> Also, Rémi said this would make it harder to join the project, in which way
> exactly?
>
> Otherwise, I'm happy to let this die and return to trying to get my patch
> committed.. 
>
> Thanks,
> -- Romain
> ___
> 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 2/5] ffbuild/libversion.sh: add shebang

[Marth64]

Regardless -- it can be left as is . I digress from the topic.

Thank you,
___
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 2/5] ffbuild/libversion.sh: add shebang

[Marth64]

> so that seems like a terrible idea that would achieve
> the opposite result.

I respectfully disagree.

Neither approach is universal or POSIX specified.
So while I agree it can be left as-is since only
a basic Bourne shell is needed, I would not just
dismiss it/write it off as a terrible idea.

There are reasons why #!/usr/bin/env is colloquially preferred
to launch an interpreter in most shell script cases.
For example, there are systems where /bin/sh is NOT
a POSIX compliant shell. Alternatively, what if I have a different
or compliant `sh` in my PATH, but not necessarily in /bin?
This is not a scenario I made up, one can quickly research to see.

I will not bikeshed the topic further, we can go either way,
but I don't think it qualifies as a "terrible idea".
___
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 2/5] ffbuild/libversion.sh: add shebang

[Henrik Gramner via ffmpeg-devel]

On Tue, Apr 9, 2024 at 11:52 PM Marth64  wrote:
> > +#!/bin/sh
> Might I suggest `#!/usr/bin/env sh` instead for this case?
> I tend to prefer it from a portability and usability perspective,
> but I can imagine for sh it might not matter.

/bin/sh exists on virtually every *NIX system whereas /usr/bin/env is
not ubiquitous, so that seems like a terrible idea that would achieve
the opposite result.
___
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 2/5] ffbuild/libversion.sh: add shebang

[Marth64]

> +#!/bin/sh
Might I suggest `#!/usr/bin/env sh` instead for this case?
I tend to prefer it from a portability and usability perspective,
but I can imagine for sh it might not matter.

I am not close to the patch that you are working on.
But thought to throw this out there in case there is a
platform or user relying on unique behaviour here.

Thank you for your time,
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] bsf: use standard include paths

[Andrew Kelley]

Removes the special -I flag specified in the avcodec/bsf/ subdirectory.

This makes code copy-pastable to other parts of the ffmpeg codebase, as
well as simplifying the build script.

It also reduces ambiguity, since there are many instances of same-named
header files existing in both libavformat/ and libavcodec/
subdirectories.
---
 libavcodec/bsf/Makefile   |  2 --
 libavcodec/bsf/aac_adtstoasc.c| 16 
 libavcodec/bsf/av1_frame_merge.c  |  8 
 libavcodec/bsf/av1_frame_split.c  |  8 
 libavcodec/bsf/av1_metadata.c | 10 +-
 libavcodec/bsf/chomp.c|  4 ++--
 libavcodec/bsf/dca_core.c |  8 
 libavcodec/bsf/dts2pts.c  | 12 ++--
 libavcodec/bsf/dump_extradata.c   |  4 ++--
 libavcodec/bsf/dv_error_marker.c  |  4 ++--
 libavcodec/bsf/eac3_core.c|  8 
 libavcodec/bsf/evc_frame_merge.c  | 12 ++--
 libavcodec/bsf/extract_extradata.c| 22 +++---
 libavcodec/bsf/filter_units.c |  6 +++---
 libavcodec/bsf/h264_metadata.c| 20 ++--
 libavcodec/bsf/h264_mp4toannexb.c | 10 +-
 libavcodec/bsf/h264_redundant_pps.c   | 16 
 libavcodec/bsf/h265_metadata.c| 16 
 libavcodec/bsf/h266_metadata.c| 12 ++--
 libavcodec/bsf/hapqa_extract.c|  8 
 libavcodec/bsf/hevc_mp4toannexb.c | 10 +-
 libavcodec/bsf/imx_dump_header.c  |  6 +++---
 libavcodec/bsf/media100_to_mjpegb.c   |  6 +++---
 libavcodec/bsf/mjpeg2jpeg.c   |  8 
 libavcodec/bsf/mjpega_dump_header.c   |  8 
 libavcodec/bsf/movsub.c   |  4 ++--
 libavcodec/bsf/mpeg2_metadata.c   | 12 ++--
 libavcodec/bsf/mpeg4_unpack_bframes.c |  8 
 libavcodec/bsf/noise.c|  4 ++--
 libavcodec/bsf/null.c |  2 +-
 libavcodec/bsf/opus_metadata.c|  4 ++--
 libavcodec/bsf/pcm_rechunk.c  |  4 ++--
 libavcodec/bsf/pgs_frame_merge.c  |  4 ++--
 libavcodec/bsf/prores_metadata.c  |  4 ++--
 libavcodec/bsf/remove_extradata.c | 14 +++---
 libavcodec/bsf/setts.c|  4 ++--
 libavcodec/bsf/showinfo.c |  4 ++--
 libavcodec/bsf/trace_headers.c|  6 +++---
 libavcodec/bsf/truehd_core.c  | 10 +-
 libavcodec/bsf/vp9_metadata.c | 10 +-
 libavcodec/bsf/vp9_raw_reorder.c  |  8 
 libavcodec/bsf/vp9_superframe.c   |  6 +++---
 libavcodec/bsf/vp9_superframe_split.c |  8 
 libavcodec/bsf/vvc_mp4toannexb.c  | 10 +-
 44 files changed, 184 insertions(+), 186 deletions(-)

diff --git a/libavcodec/bsf/Makefile b/libavcodec/bsf/Makefile
index fb70ad0c21..e506ac61fd 100644
--- a/libavcodec/bsf/Makefile
+++ b/libavcodec/bsf/Makefile
@@ -45,5 +45,3 @@ OBJS-$(CONFIG_VP9_SUPERFRAME_BSF) += 
bsf/vp9_superframe.o
 OBJS-$(CONFIG_VP9_SUPERFRAME_SPLIT_BSF)   += bsf/vp9_superframe_split.o
 OBJS-$(CONFIG_VVC_METADATA_BSF)   += bsf/h266_metadata.o
 OBJS-$(CONFIG_VVC_MP4TOANNEXB_BSF)+= bsf/vvc_mp4toannexb.o
-
-libavcodec/bsf/%.o: CPPFLAGS += -I$(SRC_PATH)/libavcodec/
diff --git a/libavcodec/bsf/aac_adtstoasc.c b/libavcodec/bsf/aac_adtstoasc.c
index dd5e8b2a31..08373fc3b2 100644
--- a/libavcodec/bsf/aac_adtstoasc.c
+++ b/libavcodec/bsf/aac_adtstoasc.c
@@ -19,14 +19,14 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#include "adts_header.h"
-#include "adts_parser.h"
-#include "bsf.h"
-#include "bsf_internal.h"
-#include "put_bits.h"
-#include "get_bits.h"
-#include "mpeg4audio.h"
-#include "mpeg4audio_copy_pce.h"
+#include "libavcodec/adts_header.h"
+#include "libavcodec/adts_parser.h"
+#include "libavcodec/bsf.h"
+#include "libavcodec/bsf_internal.h"
+#include "libavcodec/put_bits.h"
+#include "libavcodec/get_bits.h"
+#include "libavcodec/mpeg4audio.h"
+#include "libavcodec/mpeg4audio_copy_pce.h"
 
 typedef struct AACBSFContext {
 int first_frame_done;
diff --git a/libavcodec/bsf/av1_frame_merge.c b/libavcodec/bsf/av1_frame_merge.c
index 4c54f2167e..12d53fba7c 100644
--- a/libavcodec/bsf/av1_frame_merge.c
+++ b/libavcodec/bsf/av1_frame_merge.c
@@ -18,10 +18,10 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#include "bsf.h"
-#include "bsf_internal.h"
-#include "cbs.h"
-#include "cbs_av1.h"
+#include "libavcodec/bsf.h"
+#include "libavcodec/bsf_internal.h"
+#include "libavcodec/cbs.h"
+#include "libavcodec/cbs_av1.h"
 
 typedef struct AV1FMergeContext {
 CodedBitstreamContext *input;
diff --git a/libavcodec/bsf/av1_frame_split.c b/libavcodec/bsf/av1_frame_split.c
index 5f6a40316c..953aa83fc2 100644
--- a/libavcodec/bsf/av1_frame_split.c
+++ b/libavcodec/bsf/av1_frame_split.c
@@ -32,10 +32,10 @@
 
 #include "libavutil/avassert.h"
 
-#include "bsf.h"
-#include "bsf_internal.h"
-#include 

Re: [FFmpeg-devel] [PATCH 4/5] avformat/mxfdec: Check index_edit_rate

[Marton Balint]

On Tue, 9 Apr 2024, Tomas Härdin wrote:


mån 2024-04-08 klockan 21:46 +0200 skrev Marton Balint:



On Mon, 8 Apr 2024, Tomas Härdin wrote:

> tor 2024-04-04 klockan 00:51 +0200 skrev Michael Niedermayer:
> > Fixes: Assertion b >=0 failed at libavutil/mathematics.c:62
> > Fixes: 67811/clusterfuzz-testcase-minimized-
> > ffmpeg_dem_MXF_fuzzer-
> > 5108429687422976
> > 
> > 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 04de4c1d5e3..233d614f783 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -1264,6 +1264,9 @@ static int
> > mxf_read_index_table_segment(void
> > *arg, AVIOContext *pb, int tag, int
> >  case 0x3F0B:
> >  segment->index_edit_rate.num = avio_rb32(pb);
> >  segment->index_edit_rate.den = avio_rb32(pb);
> > +    if (segment->index_edit_rate.num <= 0 ||
> > +    segment->index_edit_rate.den <= 0)
> > +    return AVERROR_INVALIDDATA;
> 
> mxf_compute_index_tables() has a check for index_edit_rate that you

> probably want to remove as well. It was introduced in c6fff3d, but
> the
> files it supposedly fixes aren't in FATE. We shouldn't encourage
> broken
> muxers.

I don't quite get what FATE has to do with it. And the samples
mentioned 
in the patch has valid index segment edit rates, only they are
different 
from the track edit rate, and the patch was intended to fix that

case.


Then why does it check against 0/0?


Probably to avoid divison by zero.

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] Query from Reuters on XZ, open source, and Microsoft

[Romain Beauxis]

[Apologies for continuing the conversation, Rémi]

Le mar. 9 avr. 2024 à 14:05, Tomas Härdin  a écrit :

> mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis:
> > On Wed, Apr 3, 2024, 11:39 Kieran Kunhya via ffmpeg-devel <
> > ffmpeg-devel@ffmpeg.org> wrote:
> >
> > > Hi Raphael,
> > >
> > > I was the author of the tweet and I gave a short talk about this
> > > topic at
> > > Demuxed at a video conference last year:
> > > https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s
> > >
> > > That said this is a community project and it would be best to
> > > continue the
> > > discussion on this mailing list unless agreed otherwise.
> > >
> >
> > Thank you for sharing your talk. It's indeed unfortunate that large
> > companies are not more generous with the projects they depend on
> > _heavily_
> >
> > I would like to offer a constructive feedback really not intended as
> > trolling. I believe that supporting a more modern development
> > workflow such
> > as the GitHub PR or gitlab MR would go very long way in helping
> > onboarding
> > new developers.
>
> Considering which company owns GitHub and which company was the target
> of Kieran's criticism, this seems ill-adviced
>

Would you mind explaining what you mean exactly? I want to respond but I'm
not sure if I fully understand your point here.


> Also as someone who had to maintain a Gitlab instance at uni for a
> couple of years, I agree with Rémi's points
>

My initial contribution was motivated by the argument presented in the
original talk that bringing new blood is critical to the survival of the
project.

If so, then I do believe that there must be a compromise to be made between
being easier to join for new developers and changing the existing workflow.
I'm also aware that changing the existing workflow has been discussed
before.

I don't think that media is not cool anymore, as argued in the talk. I see
a _lot_ of interested developers in my other projects and all over the open
source landscape. That's why I believe that it's also important to consider
other reasons than the talk's argument.

Being someone actually trying to contribute, with years of developers
experience and involvement in other communities, I was thinking that I may
be able to bring in more new context to the topic.

If there's interest in continuing the discussion, could you or Rémi be
willing to explain what kind of burden gitlab would add?

Also, Rémi said this would make it harder to join the project, in which way
exactly?

Otherwise, I'm happy to let this die and return to trying to get my patch
committed.. 

Thanks,
-- Romain
___
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] avformat/mxfdec: Check index_edit_rate

[Tomas Härdin]

mån 2024-04-08 klockan 21:46 +0200 skrev Marton Balint:
> 
> 
> On Mon, 8 Apr 2024, Tomas Härdin wrote:
> 
> > tor 2024-04-04 klockan 00:51 +0200 skrev Michael Niedermayer:
> > > Fixes: Assertion b >=0 failed at libavutil/mathematics.c:62
> > > Fixes: 67811/clusterfuzz-testcase-minimized-
> > > ffmpeg_dem_MXF_fuzzer-
> > > 5108429687422976
> > > 
> > > 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 04de4c1d5e3..233d614f783 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -1264,6 +1264,9 @@ static int
> > > mxf_read_index_table_segment(void
> > > *arg, AVIOContext *pb, int tag, int
> > >  case 0x3F0B:
> > >  segment->index_edit_rate.num = avio_rb32(pb);
> > >  segment->index_edit_rate.den = avio_rb32(pb);
> > > +    if (segment->index_edit_rate.num <= 0 ||
> > > +    segment->index_edit_rate.den <= 0)
> > > +    return AVERROR_INVALIDDATA;
> > 
> > mxf_compute_index_tables() has a check for index_edit_rate that you
> > probably want to remove as well. It was introduced in c6fff3d, but
> > the
> > files it supposedly fixes aren't in FATE. We shouldn't encourage
> > broken
> > muxers.
> 
> I don't quite get what FATE has to do with it. And the samples
> mentioned 
> in the patch has valid index segment edit rates, only they are
> different 
> from the track edit rate, and the patch was intended to fix that
> case.

Then why does it check against 0/0?

/Tomas
___
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] [EXT] Re: Query from Reuters on XZ, open source, and Microsoft

[Tomas Härdin]

mån 2024-04-08 klockan 16:40 +0200 skrev Nicolas George:
> Tomas Härdin (12024-04-08):
> > We could always start licensing the project under a less permissive
> > license like the GPL or the AGPL and then charge for exceptions.
> > This
> > tactic goes by the name of license trolling, and was successfully
> > used
> > by FFmbc for a while.
> 
> Why do you say that when you know perfectly well than some of the
> developers holding copyright on the core code of the project will
> never
> let you do it

Looks like someone is not aware of the license upgrade clause in the
(L)GPL


> > We also don't need to support every use case.
> 
> This, sadly, your ilk

Veering into CoC violation territory I see

> has the power to enforce. I am ancient enough in
> the project to remember the time where supporting every use case was
> almost an official motto, and lucid enough to realise that it was the
> main reason for the success of the project.

Things change

/Tomas
___
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] Query from Reuters on XZ, open source, and Microsoft

[Tomas Härdin]

mån 2024-04-08 klockan 13:13 -0500 skrev Romain Beauxis:
> On Wed, Apr 3, 2024, 11:39 Kieran Kunhya via ffmpeg-devel <
> ffmpeg-devel@ffmpeg.org> wrote:
> 
> > Hi Raphael,
> > 
> > I was the author of the tweet and I gave a short talk about this
> > topic at
> > Demuxed at a video conference last year:
> > https://m.youtube.com/watch?v=OIyOEuQQsCQ=930s
> > 
> > That said this is a community project and it would be best to
> > continue the
> > discussion on this mailing list unless agreed otherwise.
> > 
> 
> Thank you for sharing your talk. It's indeed unfortunate that large
> companies are not more generous with the projects they depend on
> _heavily_
> 
> I would like to offer a constructive feedback really not intended as
> trolling. I believe that supporting a more modern development
> workflow such
> as the GitHub PR or gitlab MR would go very long way in helping
> onboarding
> new developers.

Considering which company owns GitHub and which company was the target
of Kieran's criticism, this seems ill-adviced

Also as someone who had to maintain a Gitlab instance at uni for a
couple of years, I agree with Rémi's points

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/libsvt1: check return value of sned/receive functions

[Sean McGovern]

Hi James,

On Tue, Apr 9, 2024, 09:05 James Almer  wrote:

> Signed-off-by: James Almer 
> ---
>  libavcodec/libsvtav1.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
> index 105c3369c0..6ff893cf10 100644
> --- a/libavcodec/libsvtav1.c
> +++ b/libavcodec/libsvtav1.c
> @@ -486,6 +486,7 @@ static int eb_send_frame(AVCodecContext *avctx, const
> AVFrame *frame)
>  {
>  SvtContext   *svt_enc = avctx->priv_data;
>  EbBufferHeaderType  *headerPtr = svt_enc->in_buf;
> +EbErrorType svt_ret;
>  int ret;
>
>  if (!frame) {
> @@ -524,7 +525,9 @@ static int eb_send_frame(AVCodecContext *avctx, const
> AVFrame *frame)
>  if (avctx->gop_size == 1)
>  headerPtr->pic_type = EB_AV1_KEY_PICTURE;
>
> -svt_av1_enc_send_picture(svt_enc->svt_handle, headerPtr);
> +svt_ret = svt_av1_enc_send_picture(svt_enc->svt_handle, headerPtr);
> +if (svt_ret != EB_ErrorNone)
> +return svt_print_error(avctx, svt_ret, "Error sending a frame to
> encoder");
>
>  return 0;
>  }
> @@ -579,6 +582,8 @@ static int eb_receive_packet(AVCodecContext *avctx,
> AVPacket *pkt)
>  svt_ret = svt_av1_enc_get_packet(svt_enc->svt_handle, ,
> svt_enc->eos_flag);
>  if (svt_ret == EB_NoErrorEmptyQueue)
>  return AVERROR(EAGAIN);
> +else if (svt_ret != EB_ErrorNone)
> +return svt_print_error(avctx, svt_ret, "Error getting an output
> packet from encoder");
>
>  #if SVT_AV1_CHECK_VERSION(2, 0, 0)
>  if (headerPtr->flags & EB_BUFFERFLAG_EOS) {
> --
> 2.44.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>

Commit title is mis-spelled: sned -> send.

Other than that, looks OK.

-- Sean McGovern

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

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

Re: [FFmpeg-devel] [PATCH v2 02/11] avcodec/dovi_rpu: properly replace context header

[Niklas Haas]

On Tue, 09 Apr 2024 17:36:30 +0200 Andreas Rheinhardt 
 wrote:
> Niklas Haas:
> > From: Niklas Haas 
> > 
> > This was never set in ff_dovi_ctx_replace(), leading to possibly
> > out-of-date when copying from a sub-thread to the main thread.
> > ---
> 
> Sub-thread to the main thread? update_thread_context is not called with
> the main (user-facing) AVCodecContext.

Changed to "from one thread to another".

> 
> >  libavcodec/dovi_rpu.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
> > index d95c7e03af9..bfb7b9fe661 100644
> > --- a/libavcodec/dovi_rpu.c
> > +++ b/libavcodec/dovi_rpu.c
> > @@ -75,6 +75,7 @@ void ff_dovi_ctx_replace(DOVIContext *s, const 
> > DOVIContext *s0)
> >  {
> >  s->logctx = s0->logctx;
> >  s->cfg = s0->cfg;
> > +s->header = s0->header;
> >  s->mapping = s0->mapping;
> >  s->color = s0->color;
> >  for (int i = 0; i <= DOVI_MAX_DM_ID; i++)
> 
> ___
> 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 v2 04/11] avcodec/dovi_rpu: clarify semantics of guess_profile()

[Niklas Haas]

On Tue, 09 Apr 2024 17:37:32 +0200 Andreas Rheinhardt 
 wrote:
> Niklas Haas:
> > From: Niklas Haas 
> > 
> > This is based on HEVC only, H.264/AV1 use their own (hopefully correctly
> > signalled) profiles.
> > ---
> >  libavcodec/dovi_rpu.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
> > 
> > diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
> > index 267e52ceb66..4da711d763e 100644
> > --- a/libavcodec/dovi_rpu.c
> > +++ b/libavcodec/dovi_rpu.c
> > @@ -121,7 +121,8 @@ int ff_dovi_attach_side_data(DOVIContext *s, AVFrame 
> > *frame)
> >  return 0;
> >  }
> >  
> > -static int guess_profile(const AVDOVIRpuDataHeader *hdr)
> > +/* Note: Only works for HEVC */
> > +static int guess_hevc_profile(const AVDOVIRpuDataHeader *hdr)
> >  {
> >  switch (hdr->vdr_rpu_profile) {
> >  case 0:
> > @@ -510,7 +511,7 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t 
> > *rpu, size_t rpu_size,
> >  use_prev_vdr_rpu = get_bits1(gb);
> >  use_nlq = (hdr->rpu_format & 0x700) == 0 && 
> > !hdr->disable_residual_flag;
> >  
> > -profile = s->cfg.dv_profile ? s->cfg.dv_profile : guess_profile(hdr);
> > +profile = s->cfg.dv_profile ? s->cfg.dv_profile : 
> > guess_hevc_profile(hdr);
> >  if (profile == 5 && use_nlq) {
> >  av_log(s->logctx, AV_LOG_ERROR, "Profile 5 RPUs should not use 
> > NLQ\n");
> >  goto fail;
> 
> Is guess_hevc_profile only called for HEVC?

Yes. All non-HEVC codecs explicitly override s->cfg.dv_profile before
calling into this function.

But probably we should document that more clearly somewhere.

> 
> - Andreas
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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 0/3] avcodec/h264dec: Fix dropped frames when draining

[Derek Buitenhuis]

On 4/3/2024 10:45 PM, arch1t3cht wrote:
> Can I bump this? It's my first time sending a patch here so let me know
> if I did something wrong.

To me, it LGTM, but I would like someone more experience in H.264 internals
to OK it, too - possibly Michael?

- Derek
___
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] movenc: Allow writing timed ID3 metadata

[James Almer]

On 4/4/2024 7:29 AM, Martin Storsjö wrote:

This is based on a spec at https://aomediacodec.github.io/id3-emsg/,
further based on ISO/IEC 23009-1:2019.

Within libavformat, timed ID3 metadata (already supported by the
mpegts demuxer and muxer) is handled as a separate data AVStream
with codec type AV_CODEC_ID_TIMED_ID3. However, it doesn't
have a corresponding track in the mov file - instead, these events
are written as separate toplevel 'emsg' boxes.
---
  libavformat/movenc.c   | 49 -
  libavformat/tests/movenc.c | 55 +-
  tests/ref/fate/movenc  |  8 ++
  3 files changed, 104 insertions(+), 8 deletions(-)


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

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

Re: [FFmpeg-devel] [PATCH] aarch64: ac3dsp: Simplify the end of ff_ac3_sum_square_butterfly_float_neon

[J. Dekker]

Martin Storsjö  writes:

> Before:   Cortex A53 A72 A78
> ac3_sum_square_bufferfly_float_neon:  1005.7   516.5   224.5
> After:
> ac3_sum_square_bufferfly_float_neon:   981.7   504.5   223.2
> ---
>  libavcodec/aarch64/ac3dsp_neon.S | 16 
>  1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/aarch64/ac3dsp_neon.S 
> b/libavcodec/aarch64/ac3dsp_neon.S
> index 20beb6cc50..7e97cc39f7 100644
> --- a/libavcodec/aarch64/ac3dsp_neon.S
> +++ b/libavcodec/aarch64/ac3dsp_neon.S
> @@ -103,17 +103,9 @@ function ff_ac3_sum_square_butterfly_float_neon, export=1
>  fmlav3.4s, v17.4s, v17.4s
>  subsw3, w3, #4
>  b.gt1b
> -faddp   v0.4s, v0.4s, v0.4s
> -faddp   v0.2s, v0.2s, v0.2s
> -st1 {v0.s}[0], [x0], #4
> -faddp   v1.4s, v1.4s, v1.4s
> -faddp   v1.2s, v1.2s, v1.2s
> -st1 {v1.s}[0], [x0], #4
> -faddp   v2.4s, v2.4s, v2.4s
> -faddp   v2.2s, v2.2s, v2.2s
> -st1 {v2.s}[0], [x0], #4
> -faddp   v3.4s, v3.4s, v3.4s
> -faddp   v3.2s, v3.2s, v3.2s
> -st1 {v3.s}[0], [x0]
> +faddp   v0.4s, v0.4s, v1.4s
> +faddp   v2.4s, v2.4s, v3.4s
> +faddp   v0.4s, v0.4s, v2.4s
> +st1 {v0.4s}, [x0]
>  ret
>  endfunc

Thanks, LGTM. Pushed with M1 benchmark on Linux.

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

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

Re: [FFmpeg-devel] [PATCH] lavc/vvc_parser: Fix integer overflow calculating framerate

[Nuo Mi]

On Tue, Apr 9, 2024 at 3:04 AM James Almer  wrote:

> On 4/8/2024 3:20 PM, Frank Plowman wrote:
> > num_units_in_tick and time_scale are both 32-bit unsigned integers.
> > Storing them as ints was causing overflows.
> >
> > Signed-off-by: Frank Plowman 
> > ---
> >   libavcodec/vvc_parser.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vvc_parser.c b/libavcodec/vvc_parser.c
> > index a6a5be27ae..e3501fa139 100644
> > --- a/libavcodec/vvc_parser.c
> > +++ b/libavcodec/vvc_parser.c
> > @@ -191,8 +191,8 @@ static void set_parser_ctx(AVCodecParserContext *s,
> AVCodecContext *avctx,
> >
> >   if (sps->sps_ptl_dpb_hrd_params_present_flag &&
> >   sps->sps_timing_hrd_params_present_flag) {
> > -int num =
> sps->sps_general_timing_hrd_parameters.num_units_in_tick;
> > -int den = sps->sps_general_timing_hrd_parameters.time_scale;
> > +uint32_t num =
> sps->sps_general_timing_hrd_parameters.num_units_in_tick;
> > +uint32_t den =
> sps->sps_general_timing_hrd_parameters.time_scale;
> >
> >   if (num != 0 && den != 0)
> >   av_reduce(>framerate.den, >framerate.num,
>
> LGTM.
>
Pushed this and others.
Thank you, Frank and James.

> ___
> 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] tests/checkasm: add exclude_guest for non-x86 linux perf

[J. Dekker]

exclude_guest is currently only supported on x86. However, not
specifying 'exclude_guest' implies that you can count guest events
should you run one. This creates an ABI issue whereby some non-x86
kernels require specifying exclude_guest = 1 explicitly.

Signed-off-by: J. Dekker 
---
 tests/checkasm/checkasm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index dcd2fd6957..8be6cb0f55 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -742,6 +742,9 @@ static int bench_init_linux(void)
 .disabled   = 1, // start counting only on demand
 .exclude_kernel = 1,
 .exclude_hv = 1,
+#if !ARCH_X86
+.exclude_guest  = 1,
+#endif
 };
 
 printf("benchmarking with Linux Perf Monitoring API\n");
-- 
2.44.0

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

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

Re: [FFmpeg-devel] [PATCH v3 3/5] configure: switch to shebang without space

[J. Dekker]

Martin Storsjö  writes:

> On Tue, 9 Apr 2024, J. Dekker wrote:
>
>> Note that the config.sh file is left without a shebang, this file is
>> supposed to be sourced into the current environment.
>>
>> This commit is purely cosmetic.
>>
>> Signed-off-by: J. Dekker 
>> ---
>> configure | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Thanks, this set seems fine to me - the explanations seem good now. (I'd
> consider merging patches 3-5 though, but keeping the full commit message from
> patch 3).)
>

Thanks for review, pushed with 3-5 squashed.

-- 
jd
___
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 3/5] configure: switch to shebang without space

[Martin Storsjö]

On Tue, 9 Apr 2024, J. Dekker wrote:


Note that the config.sh file is left without a shebang, this file is
supposed to be sourced into the current environment.

This commit is purely cosmetic.

Signed-off-by: J. Dekker 
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)


Thanks, this set seems fine to me - the explanations seem good now. (I'd 
consider merging patches 3-5 though, but keeping the full commit message 
from patch 3).)


// Martin

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

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

[FFmpeg-devel] [PATCH v3 5/5] doc/texidep: switch to shebang without space

[J. Dekker]

This commit is purely cosmetic.

Signed-off-by: J. Dekker 
---
 doc/texidep.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/doc/texidep.pl b/doc/texidep.pl
index 099690378e..33e6c7c53e 100644
--- a/doc/texidep.pl
+++ b/doc/texidep.pl
@@ -1,4 +1,4 @@
-#! /usr/bin/env perl
+#!/usr/bin/env perl
 
 # This script will print the dependency of a Texinfo file to stdout.
 # texidep.pl   
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH v3 4/5] tests/fate.sh: switch to shebang without space

[J. Dekker]

This commit is purely cosmetic.

Signed-off-by: J. Dekker 
---
 tests/fate-run.sh | 2 +-
 tests/fate.sh | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 9863e4f2d9..6ae0320c60 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -1,4 +1,4 @@
-#! /bin/sh
+#!/bin/sh
 
 export LC_ALL=C
 
diff --git a/tests/fate.sh b/tests/fate.sh
index 07908be3a5..c5ee18de80 100755
--- a/tests/fate.sh
+++ b/tests/fate.sh
@@ -1,4 +1,4 @@
-#! /bin/sh
+#!/bin/sh
 
 config=$1
 
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH v3 3/5] configure: switch to shebang without space

[J. Dekker]

Note that the config.sh file is left without a shebang, this file is
supposed to be sourced into the current environment.

This commit is purely cosmetic.

Signed-off-by: J. Dekker 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 7c22772485..55f1fc354d 100755
--- a/configure
+++ b/configure
@@ -4737,7 +4737,7 @@ chmod +x $TMPE
 
 # make sure we can execute files in $TMPDIR
 cat > $TMPSH 2>> $logfile <> $logfile 2>&1
 if ! $TMPSH >> $logfile 2>&1; then
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH v3 2/5] ffbuild/libversion.sh: add shebang

[J. Dekker]

The implicit interpreter is dependent on the environment, and isn't
guaranteed to be /bin/sh. Some packagers call this script directly, and
in certain environments such as containers using qemu-user through
binfmt_misc emulation on Linux it doesn't fallback to /bin/sh.

To fix these cases we add the interpreter explicitly.

Signed-off-by: J. Dekker 
---
 ffbuild/libversion.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ffbuild/libversion.sh b/ffbuild/libversion.sh
index a94ab58057..ecaa90cde6 100755
--- a/ffbuild/libversion.sh
+++ b/ffbuild/libversion.sh
@@ -1,3 +1,4 @@
+#!/bin/sh
 toupper(){
 echo "$@" | tr abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ
 }
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH v3 1/5] configure: simplify bigendian check

[J. Dekker]

The preferred way to use LTO is --enable-lto but often times packagers
still end up with -flto in cflags for various reasons. Using grep
on binary object files is brittle and relies on specific object
representation, which in the case of LLVM bitcode, debug information or
other intermediary formats can fail silently.

This patch changes the check to a more commonly used define for GCC
style compilers. More checks may be needed to cover other potential
compilers that don't use the __BYTE_ORDER__ define.

Signed-off-by: J. Dekker 
---
 configure | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/configure b/configure
index f511fbae49..7c22772485 100755
--- a/configure
+++ b/configure
@@ -6120,11 +6120,7 @@ extern_prefix=${sym%%ff_extern*}
 
 check_cc pragma_deprecated "" '_Pragma("GCC diagnostic push") _Pragma("GCC 
diagnostic ignored \"-Wdeprecated-declarations\"")'
 
-# The global variable ensures the bits appear unchanged in the object file.
-test_cc 

Re: [FFmpeg-devel] [PATCH] avcodec/vvc/ps: reset sps_id_used on PS uninit

[Nuo Mi]

On Mon, Apr 8, 2024 at 11:15 PM Frank Plowman  wrote:

> On 08/04/2024 15:12, Nuo Mi wrote:
> > On Mon, Apr 8, 2024 at 4:37 PM Frank Plowman 
> wrote:
> >
> >> On 07/04/2024 15:48, James Almer wrote:
> >>> On 4/7/2024 10:38 AM, Nuo Mi wrote:
>  On Sun, Apr 7, 2024 at 11:05 AM James Almer 
> wrote:
> 
> > Signed-off-by: James Almer 
> > ---
> >   libavcodec/vvc/ps.c | 1 +
> >   1 file changed, 1 insertion(+)
> >
> > diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
> > index 3c71c34bae..83ee75fb62 100644
> > --- a/libavcodec/vvc/ps.c
> > +++ b/libavcodec/vvc/ps.c
> > @@ -912,6 +912,7 @@ void ff_vvc_ps_uninit(VVCParamSets *ps)
> >   ff_refstruct_unref(>sps_list[i]);
> >   for (int i = 0; i < FF_ARRAY_ELEMS(ps->pps_list); i++)
> >   ff_refstruct_unref(>pps_list[i]);
> > +ps->sps_id_used = 0;
> >
>  Hi James,
>  thank you for the patch.
> 
>  Is this really necessary?
>  vvc_ps_uninit will be called by vvc_decode_free,
>  We are not supposed to use any member of VVCParamSets after
>  vvc_decode_free.
> >>>
> >>> My bad, i thought it was also called on every flush() call.
> >>>
> >>> Something like the following:
> >>>
>  diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
>  index eb447604fe..463536512e 100644
>  --- a/libavcodec/vvc/dec.c
>  +++ b/libavcodec/vvc/dec.c
>  @@ -963,6 +963,8 @@ static av_cold void
>  vvc_decode_flush(AVCodecContext *avctx)
>   ff_vvc_flush_dpb(last);
>   }
> 
>  +s->ps->sps_id_used = 0;
>  +
>   s->eos = 1;
>   }
> >>>
> >>> Should be done on FFCodec.flush() (like when seeking) as the previous
> >>> state is no longer valid, right?
> >>
> >> Yes I agree, I think this is needed.  Cases where the random access
> >> point has no leading pictures should be covered by the existing logic as
> >> these always fall at the start of a CVS, but I think this is needed to
> >> cover the case in which there are leading pictures.
> >>
> > This patch isn't necessary.
> > Leading pictures won't carry SPS.
> > IDR, CRA, and GDR will carry SPS, but they will also start a new CVS,
> which
> > will covered by the current logic.
> >
>
> I may be misunderstanding the spec, NoOutputBeforeRecoveryFlag is set
> for pictures which have no leading pictures, no?  In any case take, for
> instance, a CRA picture.  In most cases, CRA pictures have
> NoOutputBeforeRecoveryFlag=0, therefore are not CLVSS pictures and
> sps_id_used is not reset by the existing logic.  Do we not need to reset
> sps_id_used when seeking to a CRA then?
>
After seeking, we'll set s->last_eos to 1.
For a CRA, decode_recovery_flag will set s->no_output_before_recovery_flag
to s->last_eos.
So no_output_before_recovery_flag will be 1, not 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 v2] avcodec/libx264: bump minimum required version to 155

[Niklas Haas]

From: Niklas Haas 

This version is seven years old, and present in Debian oldoldstable,
Ubuntu 20.04 and Leap 15.0.

Allows cleaning up the file substantially. In particular, this is
motivated by the desire to stop relying on init_static_data.
---
 configure|  2 +-
 libavcodec/libx264.c | 52 ++--
 2 files changed, 8 insertions(+), 46 deletions(-)

diff --git a/configure b/configure
index f511fbae492..248ce2040d6 100755
--- a/configure
+++ b/configure
@@ -7007,7 +7007,7 @@ enabled libwebp   && {
 enabled libwebp_encoder  && require_pkg_config libwebp "libwebp >= 
0.2.0" webp/encode.h WebPGetEncoderVersion
 enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder 
"libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; }
 enabled libx264   && require_pkg_config libx264 x264 "stdint.h x264.h" 
x264_encoder_encode &&
- require_cpp_condition libx264 x264.h "X264_BUILD 
>= 122" && {
+ require_cpp_condition libx264 x264.h "X264_BUILD 
>= 155" && {
  [ "$toolchain" != "msvc" ] ||
  require_cpp_condition libx264 x264.h "X264_BUILD 
>= 158"; } &&
  check_cpp_condition libx264_hdr10 x264.h 
"X264_BUILD >= 163" &&
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index eadb20d2b39..2715f277f1f 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -270,11 +270,9 @@ static void reconfig_encoder(AVCodecContext *ctx, const 
AVFrame *frame)
 case AV_STEREO3D_FRAMESEQUENCE:
 fpa_type = 5;
 break;
-#if X264_BUILD >= 145
 case AV_STEREO3D_2D:
 fpa_type = 6;
 break;
-#endif
 default:
 fpa_type = -1;
 break;
@@ -394,14 +392,14 @@ static int setup_mb_info(AVCodecContext *ctx, 
x264_picture_t *pic,
 return 0;
 }
 
-static int setup_roi(AVCodecContext *ctx, x264_picture_t *pic, int bit_depth,
+static int setup_roi(AVCodecContext *ctx, x264_picture_t *pic,
  const AVFrame *frame, const uint8_t *data, size_t size)
 {
 X264Context *x4 = ctx->priv_data;
 
 int mbx = (frame->width + MB_SIZE - 1) / MB_SIZE;
 int mby = (frame->height + MB_SIZE - 1) / MB_SIZE;
-int qp_range = 51 + 6 * (bit_depth - 8);
+int qp_range = 51 + 6 * (x4->params.i_bitdepth - 8);
 int nb_rois;
 const AVRegionOfInterest *roi;
 uint32_t roi_size;
@@ -476,7 +474,7 @@ static int setup_frame(AVCodecContext *ctx, const AVFrame 
*frame,
 x264_sei_t *sei = >extra_sei;
 unsigned int sei_data_size = 0;
 int64_t wallclock = 0;
-int bit_depth, ret;
+int ret;
 AVFrameSideData *sd;
 AVFrameSideData *mbinfo_sd;
 
@@ -486,12 +484,7 @@ static int setup_frame(AVCodecContext *ctx, const AVFrame 
*frame,
 
 x264_picture_init(pic);
 pic->img.i_csp   = x4->params.i_csp;
-#if X264_BUILD >= 153
-bit_depth = x4->params.i_bitdepth;
-#else
-bit_depth = x264_bit_depth;
-#endif
-if (bit_depth > 8)
+if (x4->params.i_bitdepth > 8)
 pic->img.i_csp |= X264_CSP_HIGH_DEPTH;
 pic->img.i_plane = av_pix_fmt_count_planes(ctx->pix_fmt);
 
@@ -564,7 +557,7 @@ static int setup_frame(AVCodecContext *ctx, const AVFrame 
*frame,
 
 sd = av_frame_get_side_data(frame, AV_FRAME_DATA_REGIONS_OF_INTEREST);
 if (sd) {
-ret = setup_roi(ctx, pic, bit_depth, frame, sd->data, sd->size);
+ret = setup_roi(ctx, pic, frame, sd->data, sd->size);
 if (ret < 0)
 goto fail;
 }
@@ -1109,9 +1102,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
 x4->params.p_log_private= avctx;
 x4->params.i_log_level  = X264_LOG_DEBUG;
 x4->params.i_csp= convert_pix_fmt(avctx->pix_fmt);
-#if X264_BUILD >= 153
 x4->params.i_bitdepth   = 
av_pix_fmt_desc_get(avctx->pix_fmt)->comp[0].depth;
-#endif
 
 PARSE_X264_OPT("weightp", wpredp);
 
@@ -1180,11 +1171,10 @@ static av_cold int X264_init(AVCodecContext *avctx)
 else if (x4->params.i_level_idc > 0) {
 int i;
 int mbn = AV_CEIL_RSHIFT(avctx->width, 4) * 
AV_CEIL_RSHIFT(avctx->height, 4);
-int scale = X264_BUILD < 129 ? 384 : 1;
 
 for (i = 0; iparams.i_level_idc)
-x4->params.i_frame_reference = av_clip(x264_levels[i].dpb / 
mbn / scale, 1, x4->params.i_frame_reference);
+x4->params.i_frame_reference = av_clip(x264_levels[i].dpb / 
mbn, 1, x4->params.i_frame_reference);
 }
 
 if (avctx->trellis >= 0)
@@ -1228,12 +1218,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
 x4->params.b_vfr_input = 0;
 }
 if (x4->avcintra_class >= 0)
-#if X264_BUILD >= 142
 x4->params.i_avcintra_class = x4->avcintra_class;
-#else
-av_log(avctx, AV_LOG_ERROR,
-   "x264 too old for AVC Intra, at least version 142 

[FFmpeg-devel] [PATCH] avcodec/libsvt1: check return value of sned/receive functions

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/libsvtav1.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 105c3369c0..6ff893cf10 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -486,6 +486,7 @@ static int eb_send_frame(AVCodecContext *avctx, const 
AVFrame *frame)
 {
 SvtContext   *svt_enc = avctx->priv_data;
 EbBufferHeaderType  *headerPtr = svt_enc->in_buf;
+EbErrorType svt_ret;
 int ret;
 
 if (!frame) {
@@ -524,7 +525,9 @@ static int eb_send_frame(AVCodecContext *avctx, const 
AVFrame *frame)
 if (avctx->gop_size == 1)
 headerPtr->pic_type = EB_AV1_KEY_PICTURE;
 
-svt_av1_enc_send_picture(svt_enc->svt_handle, headerPtr);
+svt_ret = svt_av1_enc_send_picture(svt_enc->svt_handle, headerPtr);
+if (svt_ret != EB_ErrorNone)
+return svt_print_error(avctx, svt_ret, "Error sending a frame to 
encoder");
 
 return 0;
 }
@@ -579,6 +582,8 @@ static int eb_receive_packet(AVCodecContext *avctx, 
AVPacket *pkt)
 svt_ret = svt_av1_enc_get_packet(svt_enc->svt_handle, , 
svt_enc->eos_flag);
 if (svt_ret == EB_NoErrorEmptyQueue)
 return AVERROR(EAGAIN);
+else if (svt_ret != EB_ErrorNone)
+return svt_print_error(avctx, svt_ret, "Error getting an output packet 
from encoder");
 
 #if SVT_AV1_CHECK_VERSION(2, 0, 0)
 if (headerPtr->flags & EB_BUFFERFLAG_EOS) {
-- 
2.44.0

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

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

Re: [FFmpeg-devel] [PATCH v2 13/17] fftools/ffmpeg_filter: set strict_std_compliance

[Niklas Haas]

On Mon, 08 Apr 2024 14:57:17 +0200 Niklas Haas  wrote:
> From: Niklas Haas 
> 
> For avcodec_get_supported_config(), which requires this value be set on
> the actual ost->enc_ctx being queried.
> ---
>  fftools/ffmpeg_filter.c | 16 ++--
>  1 file changed, 6 insertions(+), 10 deletions(-)
> 
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index ac04841a16c..9ff064f5f68 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -770,6 +770,7 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream 
> *ost,
>  FilterGraph  *fg = ofilter->graph;
>  FilterGraphPriv *fgp = fgp_from_fg(fg);
>  const AVCodec *c = ost->enc_ctx->codec;
> +const AVDictionaryEntry *strict = av_dict_get(ost->encoder_opts, 
> "strict", NULL, 0);
>  int ret;
>  
>  av_assert0(!ofilter->ost);
> @@ -780,6 +781,10 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream 
> *ost,
>  ofp->ts_offset = of->start_time == AV_NOPTS_VALUE ? 0 : 
> of->start_time;
>  ofp->enc_timebase = ost->enc_timebase;
>  
> +/* Ensure this is up-to-date for avcodefc_get_supported_config() */
> +if (strict)
> +av_opt_set(ost->enc_ctx, strict->key, strict->value, 0);
> +
>  switch (ost->enc_ctx->codec_type) {
>  case AVMEDIA_TYPE_VIDEO:
>  ofp->width  = ost->enc_ctx->width;
> @@ -800,16 +805,7 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream 
> *ost,
>  { AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, 
> AV_PIX_FMT_YUVJ444P,
>AV_PIX_FMT_NONE };
>  
> -const AVDictionaryEntry *strict = 
> av_dict_get(ost->encoder_opts, "strict", NULL, 0);
> -int strict_val = ost->enc_ctx->strict_std_compliance;
> -
> -if (strict) {
> -const AVOption *o = av_opt_find(ost->enc_ctx, 
> strict->key, NULL, 0, 0);
> -av_assert0(o);
> -av_opt_eval_int(ost->enc_ctx, o, strict->value, 
> _val);
> -}
> -
> -if (strict_val > FF_COMPLIANCE_UNOFFICIAL)
> +if (ost->enc_ctx->strict_std_compliance > 
> FF_COMPLIANCE_UNOFFICIAL)
>  ofp->formats = mjpeg_formats;
>  }
>  }
> -- 
> 2.44.0
> 

Note: Will be no longer needed if elenril's encoder_opts series is
merged first, so that would be preferred as this is sort of a hack.
___
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 09/17] avcodec/codec_internal: nuke init_static_data()

[Niklas Haas]

On Mon, 08 Apr 2024 14:57:13 +0200 Niklas Haas  wrote:
> From: Niklas Haas 
> 
> All hail get_supported_config()
> ---
>  libavcodec/allcodecs.c  | 7 +--
>  libavcodec/codec_internal.h | 8 
>  2 files changed, 1 insertion(+), 14 deletions(-)
> 
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index a9f1797930a..1f22e06e710 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -916,13 +916,8 @@ static AVOnce av_codec_static_init = AV_ONCE_INIT;
>  static void av_codec_init_static(void)
>  {
>  for (int i = 0; codec_list[i]; i++) {
> -const FFCodec *codec = codec_list[i];
> -if (codec->init_static_data) {
> -codec->init_static_data((FFCodec*) codec);
> -continue;
> -}
> -
>  /* Backward compatibility with deprecated public fields */
> +const FFCodec *codec = codec_list[i];
>  if (!codec->get_supported_config)
>  continue;
>  
> diff --git a/libavcodec/codec_internal.h b/libavcodec/codec_internal.h
> index bac3e30ba2c..d3033db3375 100644
> --- a/libavcodec/codec_internal.h
> +++ b/libavcodec/codec_internal.h
> @@ -174,14 +174,6 @@ typedef struct FFCodec {
>   */
>  const FFCodecDefault *defaults;
>  
> -/**
> - * Initialize codec static data, called from av_codec_iterate().
> - *
> - * This is not intended for time consuming operations as it is
> - * run for every codec regardless of that codec being used.
> - */
> -void (*init_static_data)(struct FFCodec *codec);
> -
>  int (*init)(struct AVCodecContext *);
>  
>  union {
> -- 
> 2.44.0
> 

Note: This depends on my other series for dropping init_static_data from
libx264.
___
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 10/11] avcodec/libx265: implement dolby vision coding

[Niklas Haas]

From: Niklas Haas 

libx265 supports these natively, we just need to attach the generated
NALs to the x265picture, as well as setting the appropriate DV profile.
---
 libavcodec/libx265.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 0645cd20457..c4ce5d3 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -36,6 +36,7 @@
 #include "libavutil/pixdesc.h"
 #include "avcodec.h"
 #include "codec_internal.h"
+#include "dovi_rpu.h"
 #include "encode.h"
 #include "packet_internal.h"
 #include "atsc_a53.h"
@@ -78,6 +79,8 @@ typedef struct libx265Context {
  * encounter a frame with ROI side data.
  */
 int roi_warned;
+
+DOVIContext dovi;
 } libx265Context;
 
 static int is_keyframe(NalUnitType naltype)
@@ -143,6 +146,8 @@ static av_cold int libx265_encode_close(AVCodecContext 
*avctx)
 if (ctx->encoder)
 ctx->api->encoder_close(ctx->encoder);
 
+ff_dovi_ctx_unref(>dovi);
+
 return 0;
 }
 
@@ -526,6 +531,14 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 }
 
+#if X265_BUILD >= 167
+ctx->dovi.logctx = avctx;
+if ((ret = ff_dovi_configure(>dovi, avctx)) < 0)
+return ret;
+ctx->params->dolbyProfile = ctx->dovi.cfg.dv_profile * 10 +
+ctx->dovi.cfg.dv_bl_signal_compatibility_id;
+#endif
+
 ctx->encoder = ctx->api->encoder_open(ctx->params);
 if (!ctx->encoder) {
 av_log(avctx, AV_LOG_ERROR, "Cannot open libx265 encoder.\n");
@@ -629,6 +642,10 @@ static void free_picture(libx265Context *ctx, x265_picture 
*pic)
 for (int i = 0; i < sei->numPayloads; i++)
 av_free(sei->payloads[i].payload);
 
+#if X265_BUILD >= 167
+av_free(pic->rpu.payload);
+#endif
+
 if (pic->userData) {
 int idx = (int)(intptr_t)pic->userData - 1;
 rd_release(ctx, idx);
@@ -660,6 +677,7 @@ static int libx265_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 sei->numPayloads = 0;
 
 if (pic) {
+AVFrameSideData *sd;
 ReorderedData *rd;
 int rd_idx;
 
@@ -760,6 +778,24 @@ static int libx265_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 sei->numPayloads++;
 }
 }
+
+#if X265_BUILD >= 167
+sd = av_frame_get_side_data(pic, AV_FRAME_DATA_DOVI_METADATA);
+if (ctx->dovi.cfg.dv_profile && sd) {
+const AVDOVIMetadata *metadata = (const AVDOVIMetadata *)sd->data;
+ret = ff_dovi_rpu_generate(>dovi, metadata, 
,
+   );
+if (ret < 0) {
+free_picture(ctx, );
+return ret;
+}
+} else if (ctx->dovi.cfg.dv_profile) {
+av_log(avctx, AV_LOG_ERROR, "Dolby Vision enabled, but received 
frame "
+   "without AV_FRAME_DATA_DOVI_METADATA");
+free_picture(ctx, );
+return AVERROR_INVALIDDATA;
+}
+#endif
 }
 
 ret = ctx->api->encoder_encode(ctx->encoder, , ,
@@ -914,6 +950,10 @@ static const AVOption options[] = {
 { "udu_sei", "Use user data unregistered SEI if available",
 OFFSET(udu_sei),   AV_OPT_TYPE_BOOL,   { .i64 = 0 }, 0, 1, 
VE },
 { "a53cc",   "Use A53 Closed Captions (if available)", 
 OFFSET(a53_cc),AV_OPT_TYPE_BOOL,   { .i64 = 1 }, 0, 1, 
VE },
 { "x265-params", "set the x265 configuration using a :-separated list of 
key=value parameters", OFFSET(x265_opts), AV_OPT_TYPE_DICT,   { 0 }, 0, 0, VE },
+#if X265_BUILD >= 167
+{ "dolbyvision", "Enable Dolby Vision RPU coding", OFFSET(dovi.enable), 
AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, .unit = "dovi" },
+{   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" },
+#endif
 { NULL }
 };
 
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH v2 09/11] avcodec/libaomenc: implement dolby vision coding

[Niklas Haas]

From: Niklas Haas 

---
 libavcodec/libaomenc.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 4a71bba9c9c..b43a902a384 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -43,6 +43,7 @@
 #include "avcodec.h"
 #include "bsf.h"
 #include "codec_internal.h"
+#include "dovi_rpu.h"
 #include "encode.h"
 #include "internal.h"
 #include "libaom.h"
@@ -70,6 +71,7 @@ struct FrameListData {
 typedef struct AOMEncoderContext {
 AVClass *class;
 AVBSFContext *bsf;
+DOVIContext dovi;
 struct aom_codec_ctx encoder;
 struct aom_image rawimg;
 struct aom_fixed_buf twopass_stats;
@@ -421,6 +423,7 @@ static av_cold int aom_free(AVCodecContext *avctx)
 av_freep(>stats_out);
 free_frame_list(ctx->coded_frame_list);
 av_bsf_free(>bsf);
+ff_dovi_ctx_unref(>dovi);
 return 0;
 }
 
@@ -989,6 +992,10 @@ static av_cold int aom_init(AVCodecContext *avctx,
 if (!cpb_props)
 return AVERROR(ENOMEM);
 
+ctx->dovi.logctx = avctx;
+if ((res = ff_dovi_configure(>dovi, avctx)) < 0)
+return res;
+
 if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
 const AVBitStreamFilter *filter = 
av_bsf_get_by_name("extract_extradata");
 int ret;
@@ -1242,6 +1249,7 @@ static int aom_encode(AVCodecContext *avctx, AVPacket 
*pkt,
 unsigned long duration = 0;
 int res, coded_size;
 aom_enc_frame_flags_t flags = 0;
+AVFrameSideData *sd;
 
 if (frame) {
 rawimg  = >rawimg;
@@ -1279,6 +1287,24 @@ FF_ENABLE_DEPRECATION_WARNINGS
 break;
 }
 
+sd = av_frame_get_side_data(frame, AV_FRAME_DATA_DOVI_METADATA);
+if (ctx->dovi.cfg.dv_profile && sd) {
+const AVDOVIMetadata *metadata = (const AVDOVIMetadata *)sd->data;
+uint8_t *t35;
+int size;
+if ((res = ff_dovi_rpu_generate(>dovi, metadata, , 
)) < 0)
+return res;
+res = aom_img_add_metadata(rawimg, OBU_METADATA_TYPE_ITUT_T35,
+   t35, size, AOM_MIF_ANY_FRAME);
+av_free(t35);
+if (res != AOM_CODEC_OK)
+return AVERROR(ENOMEM);
+} else if (ctx->dovi.cfg.dv_profile) {
+av_log(avctx, AV_LOG_ERROR, "Dolby Vision enabled, but received 
frame "
+   "without AV_FRAME_DATA_DOVI_METADATA\n");
+return AVERROR_INVALIDDATA;
+}
+
 if (frame->pict_type == AV_PICTURE_TYPE_I)
 flags |= AOM_EFLAG_FORCE_KF;
 }
@@ -1459,6 +1485,8 @@ static const AVOption options[] = {
 { "ssim",NULL, 0, AV_OPT_TYPE_CONST, {.i64 = 
AOM_TUNE_SSIM}, 0, 0, VE, .unit = "tune"},
 FF_AV1_PROFILE_OPTS
 { "still-picture", "Encode in single frame mode (typically used for still 
AVIF images).", OFFSET(still_picture), AV_OPT_TYPE_BOOL, {.i64 = 0}, -1, 1, VE 
},
+{ "dolbyvision", "Enable Dolby Vision RPU coding", 
OFFSET(dovi.enable), AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, 
.unit = "dovi" },
+{   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" },
 { "enable-rect-partitions", "Enable rectangular partitions", 
OFFSET(enable_rect_partitions), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { "enable-1to4-partitions", "Enable 1:4/4:1 partitions", 
OFFSET(enable_1to4_partitions), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
 { "enable-ab-partitions",   "Enable ab shape partitions",
OFFSET(enable_ab_partitions),   AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH v2 08/11] avformat/movenc: warn if dovi cfg ignored

[Niklas Haas]

From: Niklas Haas 

Since this is guarded behind strict unofficial, we should warn if the
user feeds a dolby vision stream to this muxer, as it will otherwise
result in a broken file.
---
 libavformat/movenc.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 15b65dcf96d..0f819214be9 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -2528,16 +2528,21 @@ static int mov_write_video_tag(AVFormatContext *s, 
AVIOContext *pb, MOVMuxContex
 const AVPacketSideData *spherical_mapping = 
av_packet_side_data_get(track->st->codecpar->coded_side_data,
 
track->st->codecpar->nb_coded_side_data,
 
AV_PKT_DATA_SPHERICAL);
-const AVPacketSideData *dovi = 
av_packet_side_data_get(track->st->codecpar->coded_side_data,
-   
track->st->codecpar->nb_coded_side_data,
-   
AV_PKT_DATA_DOVI_CONF);
-
 if (stereo_3d)
 mov_write_st3d_tag(s, pb, (AVStereo3D*)stereo_3d->data);
 if (spherical_mapping)
 mov_write_sv3d_tag(mov->fc, pb, 
(AVSphericalMapping*)spherical_mapping->data);
-if (dovi)
+}
+
+if (track->mode == MODE_MP4) {
+const AVPacketSideData *dovi = 
av_packet_side_data_get(track->st->codecpar->coded_side_data,
+   
track->st->codecpar->nb_coded_side_data,
+   
AV_PKT_DATA_DOVI_CONF);
+if (dovi && mov->fc->strict_std_compliance <= 
FF_COMPLIANCE_UNOFFICIAL) {
 mov_write_dvcc_dvvc_tag(s, pb, (AVDOVIDecoderConfigurationRecord 
*)dovi->data);
+} else if (dovi) {
+av_log(mov->fc, AV_LOG_WARNING, "Not writing 'dvcC'/'dvvC' box. 
Requires -strict unofficial.\n");
+}
 }
 
 if (track->par->sample_aspect_ratio.den && 
track->par->sample_aspect_ratio.num) {
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH v2 07/11] avcodec/dovi_rpu: add ff_dovi_rpu_generate()

[Niklas Haas]

From: Niklas Haas 

This function takes a decoded AVDOVIMetadata struct and turns it back
into a binary RPU. Verified using existing tools, and matches the
bitstream in official reference files.

I decided to just roll the EMDF and NAL encapsulation into this function
because the end user will need to do it otherwise anyways.
---
 libavcodec/dovi_rpu.c | 542 ++
 libavcodec/dovi_rpu.h |  20 +-
 2 files changed, 560 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index 54994188a96..272a5125b65 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -29,6 +29,9 @@
 #include "dovi_rpu.h"
 #include "golomb.h"
 #include "get_bits.h"
+#include "itut35.h"
+#include "put_bits.h"
+#include "put_golomb.h"
 #include "refstruct.h"
 
 enum {
@@ -361,6 +364,42 @@ static inline int64_t get_se_coef(GetBitContext *gb, const 
AVDOVIRpuDataHeader *
 return 0; /* unreachable */
 }
 
+static inline void put_ue_coef(PutBitContext *pb, const AVDOVIRpuDataHeader 
*hdr,
+   uint64_t coef)
+{
+union { uint32_t u32; float f32; } fpart;
+
+switch (hdr->coef_data_type) {
+case RPU_COEFF_FIXED:
+set_ue_golomb(pb, coef >> hdr->coef_log2_denom);
+put_bits64(pb, hdr->coef_log2_denom,
+   coef & ((1LL << hdr->coef_log2_denom) - 1));
+break;
+case RPU_COEFF_FLOAT:
+fpart.f32 = coef / (float) (1LL << hdr->coef_log2_denom);
+put_bits64(pb, hdr->coef_log2_denom, fpart.u32);
+break;
+}
+}
+
+static inline void put_se_coef(PutBitContext *pb, const AVDOVIRpuDataHeader 
*hdr,
+   uint64_t coef)
+{
+union { uint32_t u32; float f32; } fpart;
+
+switch (hdr->coef_data_type) {
+case RPU_COEFF_FIXED:
+set_se_golomb(pb, coef >> hdr->coef_log2_denom);
+put_bits64(pb, hdr->coef_log2_denom,
+   coef & ((1LL << hdr->coef_log2_denom) - 1));
+break;
+case RPU_COEFF_FLOAT:
+fpart.f32 = coef / (float) (1LL << hdr->coef_log2_denom);
+put_bits64(pb, hdr->coef_log2_denom, fpart.u32);
+break;
+}
+}
+
 static inline unsigned get_variable_bits(GetBitContext *gb, int n)
 {
 unsigned int value = get_bits(gb, n);
@@ -891,3 +930,506 @@ fail:
 ff_dovi_ctx_unref(s); /* don't leak potentially invalid state */
 return AVERROR_INVALIDDATA;
 }
+
+static int av_q2den(AVRational q, int den)
+{
+if (q.den == den)
+return q.num;
+q = av_mul_q(q, av_make_q(den, 1));
+return (q.num + (q.den >> 1)) / q.den;
+}
+
+static void generate_ext_v1(PutBitContext *pb, const AVDOVIDmData *dm)
+{
+int ext_block_length, start_pos, pad_bits;
+
+switch (dm->level) {
+case 1:   ext_block_length = 5;  break;
+case 2:   ext_block_length = 11; break;
+case 4:   ext_block_length = 3;  break;
+case 5:   ext_block_length = 7;  break;
+case 6:   ext_block_length = 8;  break;
+case 255: ext_block_length = 6;  break;
+default: return;
+}
+
+set_ue_golomb(pb, ext_block_length);
+put_bits(pb, 8, dm->level);
+start_pos = put_bits_count(pb);
+
+switch (dm->level) {
+case 1:
+put_bits(pb, 12, dm->l1.min_pq);
+put_bits(pb, 12, dm->l1.max_pq);
+put_bits(pb, 12, dm->l1.avg_pq);
+break;
+case 2:
+put_bits(pb, 12, dm->l2.target_max_pq);
+put_bits(pb, 12, dm->l2.trim_slope);
+put_bits(pb, 12, dm->l2.trim_offset);
+put_bits(pb, 12, dm->l2.trim_power);
+put_bits(pb, 12, dm->l2.trim_chroma_weight);
+put_bits(pb, 12, dm->l2.trim_saturation_gain);
+put_bits(pb, 13, dm->l2.ms_weight + 8192);
+break;
+case 4:
+put_bits(pb, 12, dm->l4.anchor_pq);
+put_bits(pb, 12, dm->l4.anchor_power);
+break;
+case 5:
+put_bits(pb, 13, dm->l5.left_offset);
+put_bits(pb, 13, dm->l5.right_offset);
+put_bits(pb, 13, dm->l5.top_offset);
+put_bits(pb, 13, dm->l5.bottom_offset);
+break;
+case 6:
+put_bits(pb, 16, dm->l6.max_luminance);
+put_bits(pb, 16, dm->l6.min_luminance);
+put_bits(pb, 16, dm->l6.max_cll);
+put_bits(pb, 16, dm->l6.max_fall);
+break;
+case 255:
+put_bits(pb, 8, dm->l255.dm_run_mode);
+put_bits(pb, 8, dm->l255.dm_run_version);
+for (int i = 0; i < 4; i++)
+put_bits(pb, 8, dm->l255.dm_debug[i]);
+break;
+}
+
+pad_bits = ext_block_length * 8 - (put_bits_count(pb) - start_pos);
+av_assert1(pad_bits >= 0);
+put_bits(pb, pad_bits, 0);
+}
+
+static void put_cie_xy(PutBitContext *pb, AVCIExy xy)
+{
+const int denom = 32767;
+put_sbits(pb, 16, av_q2den(xy.x, denom));
+put_sbits(pb, 16, av_q2den(xy.y, denom));
+}
+
+#define ANY6(arr) (arr[0] || arr[1] || arr[2] || arr[3] || arr[4] || arr[5])
+#define ANY_XY(xy) (xy.x.num || xy.y.num)
+#define 

[FFmpeg-devel] [PATCH v2 05/11] avcodec/dovi_rpu: add ff_dovi_configure()

[Niklas Haas]

From: Niklas Haas 

We need to set up the configuration struct appropriately based on the
codec type, colorspace metadata, and presence/absence of an EL (though,
we currently don't support an EL).

When present, we use the signalled RPU data header to help infer (and
validate) the right values.

Behavior can be controlled by a new DOVIContext.enable flag.
---
 libavcodec/dovi_rpu.c | 176 ++
 libavcodec/dovi_rpu.h |  23 +-
 2 files changed, 198 insertions(+), 1 deletion(-)

diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index 4da711d763e..d3a284c150d 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -144,6 +144,182 @@ static int guess_hevc_profile(const AVDOVIRpuDataHeader 
*hdr)
 return 0; /* unknown */
 }
 
+static struct {
+uint64_t pps; // maximum pixels per second
+int width; // maximum width
+int main; // maximum bitrate in main tier
+int high; // maximum bitrate in high tier
+} dv_levels[] = {
+ [1] = {1280*720*24,1280,  20,  50},
+ [2] = {1280*720*30,1280,  20,  50},
+ [3] = {1920*1080*24,   1920,  20,  70},
+ [4] = {1920*1080*30,   2560,  20,  70},
+ [5] = {1920*1080*60,   3840,  20,  70},
+ [6] = {3840*2160*24,   3840,  25, 130},
+ [7] = {3840*2160*30,   3840,  25, 130},
+ [8] = {3840*2160*48,   3840,  40, 130},
+ [9] = {3840*2160*60,   3840,  40, 130},
+[10] = {3840*2160*120,  3840,  60, 240},
+[11] = {3840*2160*120,  7680,  60, 240},
+[12] = {7680*4320*60,   7680, 120, 450},
+[13] = {7680*4320*120u, 7680, 240, 800},
+};
+
+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;
+size_t cfg_size;
+uint64_t pps;
+
+if (!s->enable)
+goto skip;
+
+sd = av_frame_side_data_get(avctx->decoded_side_data,
+avctx->nb_decoded_side_data, 
AV_FRAME_DATA_DOVI_METADATA);
+
+if (sd)
+hdr = av_dovi_get_header((const AVDOVIMetadata *) sd->data);
+
+if (s->enable == FF_DOVI_AUTOMATIC && !hdr)
+goto skip;
+
+switch (avctx->codec_id) {
+case AV_CODEC_ID_AV1:  dv_profile = 10; break;
+case AV_CODEC_ID_H264: dv_profile = 9;  break;
+case AV_CODEC_ID_HEVC: dv_profile = hdr ? guess_hevc_profile(hdr) : 8; 
break;
+default:
+/* No other encoder should be calling this! */
+av_assert0(0);
+return AVERROR_BUG;
+}
+
+if (avctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
+if (dv_profile == 9) {
+if (avctx->pix_fmt != AV_PIX_FMT_YUV420P)
+dv_profile = 0;
+} else {
+if (avctx->pix_fmt != AV_PIX_FMT_YUV420P10)
+dv_profile = 0;
+}
+}
+
+switch (dv_profile) {
+case 0: /* None */
+bl_compat_id = -1;
+break;
+case 4: /* HEVC with enhancement layer */
+case 7:
+if (s->enable > 0) {
+av_log(s->logctx, AV_LOG_ERROR, "Coding of Dolby Vision 
enhancement "
+   "layers is currently unsupported.");
+return AVERROR_PATCHWELCOME;
+} else {
+goto skip;
+}
+case 5: /* HEVC with proprietary IPTPQc2 */
+bl_compat_id = 0;
+break;
+case 10:
+/* FIXME: check for proper H.273 tags once those are added */
+if (hdr && hdr->bl_video_full_range_flag) {
+/* AV1 with proprietary IPTPQc2 */
+bl_compat_id = 0;
+break;
+}
+/* fall through */
+case 8: /* HEVC (or AV1) with BL compatibility */
+if (avctx->colorspace == AVCOL_SPC_BT2020_NCL &&
+avctx->color_primaries == AVCOL_PRI_BT2020 &&
+avctx->color_trc == AVCOL_TRC_SMPTE2084) {
+bl_compat_id = 1;
+} else if (avctx->colorspace == AVCOL_SPC_BT2020_NCL &&
+   avctx->color_primaries == AVCOL_PRI_BT2020 &&
+   avctx->color_trc == AVCOL_TRC_ARIB_STD_B67) {
+bl_compat_id = 4;
+} else if (avctx->colorspace == AVCOL_SPC_BT709 &&
+   avctx->color_primaries == AVCOL_PRI_BT709 &&
+   avctx->color_trc == AVCOL_TRC_BT709) {
+bl_compat_id = 2;
+} else {
+/* Not a valid colorspace combination */
+bl_compat_id = -1;
+}
+}
+
+if (!dv_profile || bl_compat_id < 0) {
+if (s->enable > 0) {
+av_log(s->logctx, AV_LOG_ERROR, "Dolby Vision enabled, but could "
+   "not determine profile and compaatibility mode. 
Double-check "
+   "colorspace and format settings for compatibility?\n");
+return AVERROR(EINVAL);
+}
+goto skip;
+}
+
+pps = avctx->width * avctx->height;
+if (avctx->framerate.num) {
+pps = 

[FFmpeg-devel] [PATCH v2 06/11] avcodec/dovi_rpu: make `enable` also affect decoding

[Niklas Haas]

From: Niklas Haas 

This could be used by codecs to selectively disable parsing Dolby Vision
RPUs, and is cheap to support.
---
 libavcodec/av1dec.c   | 1 +
 libavcodec/dovi_rpu.c | 6 ++
 libavcodec/dovi_rpu.h | 2 ++
 libavcodec/hevcdec.c  | 1 +
 libavcodec/libdav1d.c | 1 +
 5 files changed, 11 insertions(+)

diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 4c1405df779..20865b4f129 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -1551,6 +1551,7 @@ static void av1_decode_flush(AVCodecContext *avctx)
 static const AVOption av1_options[] = {
 { "operating_point",  "Select an operating point of the scalable 
bitstream",
   OFFSET(operating_point), AV_OPT_TYPE_INT, { .i64 = 0 
}, 0, AV1_MAX_OPERATING_POINTS - 1, VD },
+{ "dolbyvision", "Decode Dolby Vision RPUs", OFFSET(dovi.enable), 
AV_OPT_TYPE_BOOL, {.i64 = 1 }, 0, 1, VD },
 { NULL }
 };
 
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index d3a284c150d..54994188a96 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -90,6 +90,9 @@ int ff_dovi_attach_side_data(DOVIContext *s, AVFrame *frame)
 AVDOVIMetadata *dovi;
 size_t dovi_size, ext_sz;
 
+if (!s->enable)
+return 0;
+
 if (!s->mapping || !s->color)
 return 0; /* incomplete dovi metadata */
 
@@ -558,6 +561,9 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 uint8_t use_nlq;
 uint8_t profile;
 
+if (!s->enable)
+return 0;
+
 if (rpu_size < 5)
 goto fail;
 
diff --git a/libavcodec/dovi_rpu.h b/libavcodec/dovi_rpu.h
index 56395707369..8dc69a2733d 100644
--- a/libavcodec/dovi_rpu.h
+++ b/libavcodec/dovi_rpu.h
@@ -37,6 +37,8 @@ typedef struct DOVIContext {
  *
  * For encoding, FF_DOVI_AUTOMATIC enables Dolby Vision only if
  * avctx->decoded_side_data contains an AVDOVIMetadata.
+ *
+ * For decoding, FF_DOVI_AUTOMATIC has the same meaning as 1.
  */
 #define FF_DOVI_AUTOMATIC -1
 int enable;
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 4bc9e2afc1d..651773260e3 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -3689,6 +3689,7 @@ static const AVOption options[] = {
 AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, PAR },
 { "strict-displaywin", "stricly apply default display window size", 
OFFSET(apply_defdispwin),
 AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, PAR },
+{ "dolbyvision", "Decode Dolby Vision RPUs", OFFSET(dovi_ctx.enable), 
AV_OPT_TYPE_BOOL, {.i64 = 1 }, 0, 1, PAR },
 { NULL },
 };
 
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 09fe767fb86..f9e1a181fc3 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -674,6 +674,7 @@ static const AVOption libdav1d_options[] = {
 { "filmgrain", "Apply Film Grain", OFFSET(apply_grain), AV_OPT_TYPE_BOOL, 
{ .i64 = -1 }, -1, 1, VD | AV_OPT_FLAG_DEPRECATED },
 { "oppoint",  "Select an operating point of the scalable bitstream", 
OFFSET(operating_point), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 31, VD },
 { "alllayers", "Output all spatial layers", OFFSET(all_layers), 
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
+{ "dolbyvision", "Decode Dolby Vision RPUs", OFFSET(dovi.enable), 
AV_OPT_TYPE_BOOL, {.i64 = 1 }, 0, 1, VD },
 { NULL }
 };
 
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH v2 11/11] avcodec/libsvtav1: implement dolby vision coding

[Niklas Haas]

From: Niklas Haas 

---
 libavcodec/libsvtav1.c | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 105c3369c0f..cd62103dba4 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "libavutil/common.h"
 #include "libavutil/frame.h"
@@ -35,6 +36,7 @@
 #include "libavutil/avassert.h"
 
 #include "codec_internal.h"
+#include "dovi_rpu.h"
 #include "encode.h"
 #include "packet_internal.h"
 #include "avcodec.h"
@@ -62,6 +64,8 @@ typedef struct SvtContext {
 
 EOS_STATUS eos_flag;
 
+DOVIContext dovi;
+
 // User options.
 AVDictionary *svtav1_opts;
 int enc_mode;
@@ -418,6 +422,7 @@ static int read_in_data(EbSvtAv1EncConfiguration *param, 
const AVFrame *frame,
 in_data->cr_stride = AV_CEIL_RSHIFT(frame->linesize[2], bytes_shift);
 
 header_ptr->n_filled_len = frame_size;
+svt_metadata_array_free(_ptr->metadata);
 
 return 0;
 }
@@ -451,6 +456,11 @@ static av_cold int eb_enc_init(AVCodecContext *avctx)
 return svt_print_error(avctx, svt_ret, "Error initializing encoder");
 }
 
+svt_enc->dovi.logctx = avctx;
+ret = ff_dovi_configure(_enc->dovi, avctx);
+if (ret < 0)
+return ret;
+
 if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
 EbBufferHeaderType *headerPtr = NULL;
 
@@ -486,6 +496,7 @@ static int eb_send_frame(AVCodecContext *avctx, const 
AVFrame *frame)
 {
 SvtContext   *svt_enc = avctx->priv_data;
 EbBufferHeaderType  *headerPtr = svt_enc->in_buf;
+AVFrameSideData *sd;
 int ret;
 
 if (!frame) {
@@ -524,6 +535,24 @@ static int eb_send_frame(AVCodecContext *avctx, const 
AVFrame *frame)
 if (avctx->gop_size == 1)
 headerPtr->pic_type = EB_AV1_KEY_PICTURE;
 
+sd = av_frame_get_side_data(frame, AV_FRAME_DATA_DOVI_METADATA);
+if (svt_enc->dovi.cfg.dv_profile && sd) {
+const AVDOVIMetadata *metadata = (const AVDOVIMetadata *)sd->data;
+uint8_t *t35;
+int size;
+if ((ret = ff_dovi_rpu_generate(_enc->dovi, metadata, , 
)) < 0)
+return ret;
+ret = svt_add_metadata(headerPtr, EB_AV1_METADATA_TYPE_ITUT_T35, t35, 
size);
+av_free(t35);
+if (ret < 0)
+return AVERROR(ENOMEM);
+} else if (svt_enc->dovi.cfg.dv_profile) {
+av_log(avctx, AV_LOG_ERROR, "Dolby Vision enabled, but received frame "
+   "without AV_FRAME_DATA_DOVI_METADATA\n");
+return AVERROR_INVALIDDATA;
+}
+
+
 svt_av1_enc_send_picture(svt_enc->svt_handle, headerPtr);
 
 return 0;
@@ -644,11 +673,13 @@ static av_cold int eb_enc_close(AVCodecContext *avctx)
 }
 if (svt_enc->in_buf) {
 av_free(svt_enc->in_buf->p_buffer);
+svt_metadata_array_free(_enc->in_buf->metadata);
 av_freep(_enc->in_buf);
 }
 
 av_buffer_pool_uninit(_enc->pool);
 av_frame_free(_enc->frame);
+ff_dovi_ctx_unref(_enc->dovi);
 
 return 0;
 }
@@ -695,6 +726,9 @@ static const AVOption options[] = {
   AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 63, VE },
 { "svtav1-params", "Set the SVT-AV1 configuration using a :-separated list 
of key=value parameters", OFFSET(svtav1_opts), AV_OPT_TYPE_DICT, { 0 }, 0, 0, 
VE },
 
+{ "dolbyvision", "Enable Dolby Vision RPU coding", OFFSET(dovi.enable), 
AV_OPT_TYPE_BOOL, {.i64 = FF_DOVI_AUTOMATIC }, -1, 1, VE, .unit = "dovi" },
+{   "auto", NULL, 0, AV_OPT_TYPE_CONST, {.i64 = FF_DOVI_AUTOMATIC}, .flags 
= VE, .unit = "dovi" },
+
 {NULL},
 };
 
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH v2 04/11] avcodec/dovi_rpu: clarify semantics of guess_profile()

[Niklas Haas]

From: Niklas Haas 

This is based on HEVC only, H.264/AV1 use their own (hopefully correctly
signalled) profiles.
---
 libavcodec/dovi_rpu.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index 267e52ceb66..4da711d763e 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -121,7 +121,8 @@ int ff_dovi_attach_side_data(DOVIContext *s, AVFrame *frame)
 return 0;
 }
 
-static int guess_profile(const AVDOVIRpuDataHeader *hdr)
+/* Note: Only works for HEVC */
+static int guess_hevc_profile(const AVDOVIRpuDataHeader *hdr)
 {
 switch (hdr->vdr_rpu_profile) {
 case 0:
@@ -510,7 +511,7 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 use_prev_vdr_rpu = get_bits1(gb);
 use_nlq = (hdr->rpu_format & 0x700) == 0 && !hdr->disable_residual_flag;
 
-profile = s->cfg.dv_profile ? s->cfg.dv_profile : guess_profile(hdr);
+profile = s->cfg.dv_profile ? s->cfg.dv_profile : guess_hevc_profile(hdr);
 if (profile == 5 && use_nlq) {
 av_log(s->logctx, AV_LOG_ERROR, "Profile 5 RPUs should not use NLQ\n");
 goto fail;
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH v2 03/11] avcodec/dovi_rpu: clarify error on missing RPU VDR

[Niklas Haas]

From: Niklas Haas 

The code was written under the misguided assumption that these fields
would only be present when the value changes, however this does not
match the actual patent specification, which says that streams are
required to either always signal this metadata, or never signal it.

That said, the specification does not really clarify what the defaults
of these fields should be in the event that this metadata is missing, so
without any sample file or other reference I don't wish to hazard
a guess at how to interpret these fields.

Fix the current behavior by making sure we always throw this error, even
for files that have the vdr sequence info in one frame but are missing
it in the next frame.
---
 libavcodec/dovi_rpu.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index bfb7b9fe661..267e52ceb66 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -499,11 +499,11 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 hdr->el_spatial_resampling_filter_flag = get_bits1(gb);
 hdr->disable_residual_flag = get_bits1(gb);
 }
-}
-
-if (!hdr->bl_bit_depth) {
-av_log(s->logctx, AV_LOG_ERROR, "Missing RPU VDR sequence info?\n");
-goto fail;
+} else {
+/* lack of documentation/samples */
+avpriv_request_sample(s->logctx, "Missing RPU VDR sequence info\n");
+ff_dovi_ctx_unref(s);
+return AVERROR_PATCHWELCOME;
 }
 
 vdr_dm_metadata_present = get_bits1(gb);
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH v2 02/11] avcodec/dovi_rpu: properly replace context header

[Niklas Haas]

From: Niklas Haas 

This was never set in ff_dovi_ctx_replace(), leading to possibly
out-of-date when copying from a sub-thread to the main thread.
---
 libavcodec/dovi_rpu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index d95c7e03af9..bfb7b9fe661 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -75,6 +75,7 @@ void ff_dovi_ctx_replace(DOVIContext *s, const DOVIContext 
*s0)
 {
 s->logctx = s0->logctx;
 s->cfg = s0->cfg;
+s->header = s0->header;
 s->mapping = s0->mapping;
 s->color = s0->color;
 for (int i = 0; i <= DOVI_MAX_DM_ID; i++)
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH v2 01/11] avcodec/dovi_rpu: store entire config record

[Niklas Haas]

From: Niklas Haas 

And make it public.

For encoding, users may also be interested in the configured level and
compatibility ID. So generalize the dv_profile field and just expose the
whole configuration record.

This makes the already rather reductive ff_dovi_update_cfg() function
almost wholly redundant, since users can just directly assign
DOVIContext.cfg.
---
 libavcodec/av1dec.c   |  6 +++---
 libavcodec/dovi_rpu.c | 16 
 libavcodec/dovi_rpu.h | 21 -
 libavcodec/hevcdec.c  | 13 ++---
 libavcodec/libdav1d.c |  6 +++---
 5 files changed, 28 insertions(+), 34 deletions(-)

diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 824725c031f..4c1405df779 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -888,10 +888,10 @@ static av_cold int av1_decode_init(AVCodecContext *avctx)
 }
 
 s->dovi.logctx = avctx;
-s->dovi.dv_profile = 10; // default for AV1
+s->dovi.cfg.dv_profile = 10; // default for AV1
 sd = ff_get_coded_side_data(avctx, AV_PKT_DATA_DOVI_CONF);
-if (sd && sd->size > 0)
-ff_dovi_update_cfg(>dovi, (AVDOVIDecoderConfigurationRecord *) 
sd->data);
+if (sd && sd->size >= sizeof(s->dovi.cfg))
+s->dovi.cfg = *(AVDOVIDecoderConfigurationRecord *) sd->data;
 
 return ret;
 }
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index 9f7a6b00664..d95c7e03af9 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -64,7 +64,7 @@ void ff_dovi_ctx_flush(DOVIContext *s)
 
 *s = (DOVIContext) {
 .logctx = s->logctx,
-.dv_profile = s->dv_profile,
+.cfg = s->cfg,
 /* preserve temporary buffer */
 .rpu_buf = s->rpu_buf,
 .rpu_buf_sz = s->rpu_buf_sz,
@@ -74,22 +74,14 @@ void ff_dovi_ctx_flush(DOVIContext *s)
 void ff_dovi_ctx_replace(DOVIContext *s, const DOVIContext *s0)
 {
 s->logctx = s0->logctx;
+s->cfg = s0->cfg;
 s->mapping = s0->mapping;
 s->color = s0->color;
-s->dv_profile = s0->dv_profile;
 for (int i = 0; i <= DOVI_MAX_DM_ID; i++)
 ff_refstruct_replace(>vdr[i], s0->vdr[i]);
 ff_refstruct_replace(>ext_blocks, s0->ext_blocks);
 }
 
-void ff_dovi_update_cfg(DOVIContext *s, const AVDOVIDecoderConfigurationRecord 
*cfg)
-{
-if (!cfg)
-return;
-
-s->dv_profile = cfg->dv_profile;
-}
-
 int ff_dovi_attach_side_data(DOVIContext *s, AVFrame *frame)
 {
 AVFrameSideData *sd;
@@ -392,7 +384,7 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 goto fail;
 
 /* Container */
-if (s->dv_profile == 10 /* dav1.10 */) {
+if (s->cfg.dv_profile == 10 /* dav1.10 */) {
 /* DV inside AV1 re-uses an EMDF container skeleton, but with fixed
  * values - so we can effectively treat this as a magic byte sequence.
  *
@@ -517,7 +509,7 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu, 
size_t rpu_size,
 use_prev_vdr_rpu = get_bits1(gb);
 use_nlq = (hdr->rpu_format & 0x700) == 0 && !hdr->disable_residual_flag;
 
-profile = s->dv_profile ? s->dv_profile : guess_profile(hdr);
+profile = s->cfg.dv_profile ? s->cfg.dv_profile : guess_profile(hdr);
 if (profile == 5 && use_nlq) {
 av_log(s->logctx, AV_LOG_ERROR, "Profile 5 RPUs should not use NLQ\n");
 goto fail;
diff --git a/libavcodec/dovi_rpu.h b/libavcodec/dovi_rpu.h
index 9f26f332ceb..9a68e45bf1b 100644
--- a/libavcodec/dovi_rpu.h
+++ b/libavcodec/dovi_rpu.h
@@ -31,6 +31,16 @@
 typedef struct DOVIContext {
 void *logctx;
 
+/**
+ * Currently active dolby vision configuration, or {0} for none.
+ * Set by the user when decoding.
+ *
+ * Note: sizeof(cfg) is not part of the libavutil ABI, so users should
+ * never pass  to any other library calls. This is included merely as
+ * a way to look up the values of fields known at compile time.
+ */
+AVDOVIDecoderConfigurationRecord cfg;
+
 /**
  * Currently active RPU data header, updates on every dovi_rpu_parse().
  */
@@ -56,7 +66,6 @@ typedef struct DOVIContext {
 struct DOVIVdr *vdr[DOVI_MAX_DM_ID+1]; ///< RefStruct references
 uint8_t *rpu_buf; ///< temporary buffer
 unsigned rpu_buf_sz;
-uint8_t dv_profile;
 
 } DOVIContext;
 
@@ -68,17 +77,11 @@ void ff_dovi_ctx_replace(DOVIContext *s, const DOVIContext 
*s0);
 void ff_dovi_ctx_unref(DOVIContext *s);
 
 /**
- * Partially reset the internal state. Resets per-frame state while preserving
- * fields parsed from the configuration record.
+ * Partially reset the internal state. Resets per-frame state, but preserves
+ * the stream-wide configuration record.
  */
 void ff_dovi_ctx_flush(DOVIContext *s);
 
-/**
- * Read the contents of an AVDOVIDecoderConfigurationRecord (usually provided
- * by stream side data) and update internal state accordingly.
- */
-void ff_dovi_update_cfg(DOVIContext *s, const AVDOVIDecoderConfigurationRecord 
*cfg);
-
 /**
  * Parse the contents of a 

[FFmpeg-devel] [PATCH v2 00/11] avcodec: add Dolby Vision encoding

[Niklas Haas]

Changes since v1:

- Moved dolbyvision option from AVCodecContext to DOVIContext, and
  add an explicit option only to codecs that use it
- Changed its type to AV_OPT_TYPE_BOOL
- Made it control decoding as well as encoding, so you can use
  `-dolbyvision off` as an input option to suppress it
- Added support for libsvtav1 encoding as well

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

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

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: bump minimum required version to 160

[Niklas Haas]

On Sat, 06 Apr 2024 22:28:26 +0200 Michael Niedermayer  
wrote:
> On Fri, Apr 05, 2024 at 07:44:52PM +0200, Niklas Haas wrote:
> > From: Niklas Haas 
> > 
> > This version is four years old, and present in Debian oldstable, Ubuntu
> > 22.04 and Leap 15.1.
> 
> Ubuntu 20.04 has general support till 2025-05-29
> Ubuntu 18.04 has security support (ESM) till 2028-04

I'll relax it from 160 back down to version 155 then. That covers Ubuntu
20.04 and Debian oldoldstable.

> 
> thx
> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Nations do behave wisely once they have exhausted all other alternatives. 
> -- Abba Eban
> ___
> 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 v1 1/2] avutil/loongarch:add LSX optimization for aac audio decode

[pengxu]

Add functions:
vector_fmul_window_lsx
butterflies_float_lsx
vector_fmul_scalar_lsx

./ffmpeg -i ../../1.aac -f null -
before:482x
after:523x
---
 libavutil/float_dsp.c |   2 +
 libavutil/float_dsp.h |   1 +
 libavutil/loongarch/Makefile  |   5 +-
 libavutil/loongarch/float_dsp.S   | 287 ++
 libavutil/loongarch/float_dsp.h   |  32 ++
 .../loongarch/float_dsp_init_loongarch.c  |  35 +++
 6 files changed, 361 insertions(+), 1 deletion(-)
 create mode 100644 libavutil/loongarch/float_dsp.S
 create mode 100644 libavutil/loongarch/float_dsp.h
 create mode 100644 libavutil/loongarch/float_dsp_init_loongarch.c

diff --git a/libavutil/float_dsp.c b/libavutil/float_dsp.c
index e9fb023466..7128ff3f96 100644
--- a/libavutil/float_dsp.c
+++ b/libavutil/float_dsp.c
@@ -162,6 +162,8 @@ av_cold AVFloatDSPContext *avpriv_float_dsp_alloc(int 
bit_exact)
 ff_float_dsp_init_x86(fdsp);
 #elif ARCH_MIPS
 ff_float_dsp_init_mips(fdsp);
+#elif ARCH_LOONGARCH64
+ff_float_dsp_init_loongarch(fdsp);
 #endif
 return fdsp;
 }
diff --git a/libavutil/float_dsp.h b/libavutil/float_dsp.h
index 342a8715c5..679a930eab 100644
--- a/libavutil/float_dsp.h
+++ b/libavutil/float_dsp.h
@@ -206,6 +206,7 @@ void ff_float_dsp_init_ppc(AVFloatDSPContext *fdsp, int 
strict);
 void ff_float_dsp_init_riscv(AVFloatDSPContext *fdsp);
 void ff_float_dsp_init_x86(AVFloatDSPContext *fdsp);
 void ff_float_dsp_init_mips(AVFloatDSPContext *fdsp);
+void ff_float_dsp_init_loongarch(AVFloatDSPContext *fdsp);
 
 /**
  * Allocate a float DSP context.
diff --git a/libavutil/loongarch/Makefile b/libavutil/loongarch/Makefile
index 2addd9351c..ae710f0515 100644
--- a/libavutil/loongarch/Makefile
+++ b/libavutil/loongarch/Makefile
@@ -1 +1,4 @@
-OBJS += loongarch/cpu.o
+OBJS += loongarch/cpu.o \
+   loongarch/float_dsp_init_loongarch.o
+
+LSX-OBJS += loongarch/float_dsp.o
diff --git a/libavutil/loongarch/float_dsp.S b/libavutil/loongarch/float_dsp.S
new file mode 100644
index 00..5073c8424f
--- /dev/null
+++ b/libavutil/loongarch/float_dsp.S
@@ -0,0 +1,287 @@
+/*
+ * Loongarch LASX/LSX optimizeds dsp
+ *
+ * Copyright (c) 2024 Loongson Technology Corporation Limited
+ * Contributed by PengXu 
+ *
+ * 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 "libavcodec/loongarch/loongson_asm.S"
+
+
+/* void vector_fmul_window(float *dst, const float *src0,
+   const float *src1, const float *win, int len) */
+function vector_fmul_window_lsx
+addi.d  sp, sp, -8
+st.d$r23,   sp, 0
+
+movet4, a0
+movet5, a1
+movet6, a2
+movet7, a3
+movet8, a4
+slli.d  t8, t8, 2
+
+add.d   t4, t4, t8
+add.d   t7, t7, t8
+add.d   t5, t5, t8
+
+add.d   a6, $r0,t8
+addi.d  a7, t8, -4
+
+movea5, $r0
+srai.d  t0, a4, 2
+beq a5, t0, .VFW02
+
+.VFW01:
+sub.d   t1, t5, a6
+addi.d  t2, a7, -12
+vld vr1,t1, 0x00  //s0
+vldxvr2,a2, t2//s1
+
+sub.d   t1, t7, a6
+vld vr3,t1, 0x00  //wi
+vldxvr4,t7, t2//wj
+
+vpermi.wvr2,vr2,0x1b
+vpermi.wvr4,vr4,0x1b
+
+vfmul.s vr5,vr2,vr3
+vfmsub.svr5,vr1,vr4,vr5  //dsti
+
+vfmul.s vr6,vr2,vr4
+vfmadd.svr6,vr1,vr3,vr6  //dstj
+
+vpermi.wvr6,vr6,0x1b
+
+sub.d   t1, t4, a6
+vst vr5,t1, 0x00
+vstxvr6,t4, t2
+
+addi.d  a6, a6, -16
+addi.d  a7, a7, -16
+
+addi.d  a5, a5, 1
+blt a5, t0, .VFW01
+
+.VFW02:
+andit0, a4, 2
+beq $r0,t0, .VFW03
+
+sub.d   t0, t5, a6
+addi.d  t1, a7, -4
+add.d   t1, t5, t1
+
+sub.d   t2, t7, a6
+addi.d  t3, a7, -4
+  

[FFmpeg-devel] [PATCH v1 2/2] avcodec/loongarch:add LSX optimization for aac audio encode

[pengxu]

Add functions:
ff_abs_pow34_lsx
ff_aac_quantize_bands_lsx

./ffmpeg -f s16le -ac 2 -i ../../1.pcm -c:a aac -f null -
before:37.5x
after:48.1x
---
 libavcodec/aacencdsp.h|   3 +
 libavcodec/loongarch/Makefile |   2 +
 libavcodec/loongarch/aacencdsp.S  | 255 ++
 libavcodec/loongarch/aacencdsp.h  |  35 +++
 .../loongarch/aacencdsp_init_loongarch.c  |  33 +++
 5 files changed, 328 insertions(+)
 create mode 100644 libavcodec/loongarch/aacencdsp.S
 create mode 100644 libavcodec/loongarch/aacencdsp.h
 create mode 100644 libavcodec/loongarch/aacencdsp_init_loongarch.c

diff --git a/libavcodec/aacencdsp.h b/libavcodec/aacencdsp.h
index 67836d8cf7..5db27a95a9 100644
--- a/libavcodec/aacencdsp.h
+++ b/libavcodec/aacencdsp.h
@@ -34,6 +34,7 @@ typedef struct AACEncDSPContext {
 
 void ff_aacenc_dsp_init_riscv(AACEncDSPContext *s);
 void ff_aacenc_dsp_init_x86(AACEncDSPContext *s);
+void ff_aacenc_dsp_init_loongarch(AACEncDSPContext *s);
 
 static inline void abs_pow34_v(float *out, const float *in, const int size)
 {
@@ -66,6 +67,8 @@ static inline void ff_aacenc_dsp_init(AACEncDSPContext *s)
 ff_aacenc_dsp_init_riscv(s);
 #elif ARCH_X86
 ff_aacenc_dsp_init_x86(s);
+#elif ARCH_LOONGARCH64
+ff_aacenc_dsp_init_loongarch(s);
 #endif
 }
 
diff --git a/libavcodec/loongarch/Makefile b/libavcodec/loongarch/Makefile
index 07da2964e4..483917d336 100644
--- a/libavcodec/loongarch/Makefile
+++ b/libavcodec/loongarch/Makefile
@@ -9,6 +9,7 @@ OBJS-$(CONFIG_HPELDSP)+= 
loongarch/hpeldsp_init_loongarch.o
 OBJS-$(CONFIG_IDCTDSP)+= loongarch/idctdsp_init_loongarch.o
 OBJS-$(CONFIG_VIDEODSP)   += loongarch/videodsp_init.o
 OBJS-$(CONFIG_HEVC_DECODER)   += loongarch/hevcdsp_init_loongarch.o
+OBJS-$(CONFIG_AAC_ENCODER)+= loongarch/aacencdsp_init_loongarch.o
 LASX-OBJS-$(CONFIG_H264QPEL)  += loongarch/h264qpel_lasx.o
 LASX-OBJS-$(CONFIG_H264DSP)   += loongarch/h264dsp_lasx.o \
  loongarch/h264_deblock_lasx.o
@@ -38,3 +39,4 @@ LSX-OBJS-$(CONFIG_H264QPEL)   += loongarch/h264qpel.o 
\
  loongarch/h264qpel_lsx.o
 LSX-OBJS-$(CONFIG_H264CHROMA) += loongarch/h264chroma.o
 LSX-OBJS-$(CONFIG_H264PRED)   += loongarch/h264intrapred.o
+LSX-OBJS-$(CONFIG_AAC_ENCODER)+= loongarch/aacencdsp.o
diff --git a/libavcodec/loongarch/aacencdsp.S b/libavcodec/loongarch/aacencdsp.S
new file mode 100644
index 00..a7cfd3bb1c
--- /dev/null
+++ b/libavcodec/loongarch/aacencdsp.S
@@ -0,0 +1,255 @@
+/*
+ * Loongarch LASX/LSX optimizeds AAC encoder DSP functions
+ *
+ * Copyright (c) 2024 Loongson Technology Corporation Limited
+ * Contributed by PengXu 
+ *
+ * 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 "loongson_asm.S"
+
+
+/* void ff_abs_pow34_lsx(float *out, const float *in, const int size); */
+// Param, out:a0, in:a1, size:a2
+function ff_abs_pow34_lsx
+move  t0,  zero  //loop param
+move  t1,  zero  //data index
+
+srai.dt2,  a2,  2
+beq   zero,t2,  .FAPL02
+
+.FAPL01:
+add.d t3,  a1,  t1
+fld.s f0,  t3,  0x00
+fld.s f1,  t3,  0x04
+fld.s f2,  t3,  0x08
+fld.s f3,  t3,  0x0c
+
+fabs.sf0,  f0
+fabs.sf1,  f1
+fabs.sf2,  f2
+fabs.sf3,  f3
+
+vextrins.wvr0, vr1, 0x10
+vextrins.wvr0, vr2, 0x20
+vextrins.wvr0, vr3, 0x30
+
+vfsqrt.s  vr4, vr0
+vfmul.s   vr5, vr0, vr4
+vfsqrt.s  vr6, vr5
+
+vstx  vr6, a0,  t1
+
+addi.dt1,  t1,  16
+addi.dt0,  t0,  1
+blt   t0,  t2,  .FAPL01
+
+.FAPL02:  /* &2 */
+andi  t0,  a2,  2
+beq   zero,t0,  .FAPL03
+
+add.d t3,  a1,  t1
+add.d t4,  a0,  t1
+
+fld.s f0,  t3,  0x00
+fld.s f1,  t3,  0x04
+
+

[FFmpeg-devel] [PATCH v1 2/2] avcodec/loongarch:add LSX optimization for aac audio encode

[pengxu]

Add functions:
ff_abs_pow34_lsx
ff_aac_quantize_bands_lsx

./ffmpeg -f s16le -ac 2 -i ../../1.pcm -c:a aac -f null -
before:37.5x
after:48.1x
---
 libavcodec/aacencdsp.h|   3 +
 libavcodec/loongarch/Makefile |   2 +
 libavcodec/loongarch/aacencdsp.S  | 255 ++
 libavcodec/loongarch/aacencdsp.h  |  35 +++
 .../loongarch/aacencdsp_init_loongarch.c  |  33 +++
 5 files changed, 328 insertions(+)
 create mode 100644 libavcodec/loongarch/aacencdsp.S
 create mode 100644 libavcodec/loongarch/aacencdsp.h
 create mode 100644 libavcodec/loongarch/aacencdsp_init_loongarch.c

diff --git a/libavcodec/aacencdsp.h b/libavcodec/aacencdsp.h
index 67836d8cf7..5db27a95a9 100644
--- a/libavcodec/aacencdsp.h
+++ b/libavcodec/aacencdsp.h
@@ -34,6 +34,7 @@ typedef struct AACEncDSPContext {
 
 void ff_aacenc_dsp_init_riscv(AACEncDSPContext *s);
 void ff_aacenc_dsp_init_x86(AACEncDSPContext *s);
+void ff_aacenc_dsp_init_loongarch(AACEncDSPContext *s);
 
 static inline void abs_pow34_v(float *out, const float *in, const int size)
 {
@@ -66,6 +67,8 @@ static inline void ff_aacenc_dsp_init(AACEncDSPContext *s)
 ff_aacenc_dsp_init_riscv(s);
 #elif ARCH_X86
 ff_aacenc_dsp_init_x86(s);
+#elif ARCH_LOONGARCH64
+ff_aacenc_dsp_init_loongarch(s);
 #endif
 }
 
diff --git a/libavcodec/loongarch/Makefile b/libavcodec/loongarch/Makefile
index 07da2964e4..483917d336 100644
--- a/libavcodec/loongarch/Makefile
+++ b/libavcodec/loongarch/Makefile
@@ -9,6 +9,7 @@ OBJS-$(CONFIG_HPELDSP)+= 
loongarch/hpeldsp_init_loongarch.o
 OBJS-$(CONFIG_IDCTDSP)+= loongarch/idctdsp_init_loongarch.o
 OBJS-$(CONFIG_VIDEODSP)   += loongarch/videodsp_init.o
 OBJS-$(CONFIG_HEVC_DECODER)   += loongarch/hevcdsp_init_loongarch.o
+OBJS-$(CONFIG_AAC_ENCODER)+= loongarch/aacencdsp_init_loongarch.o
 LASX-OBJS-$(CONFIG_H264QPEL)  += loongarch/h264qpel_lasx.o
 LASX-OBJS-$(CONFIG_H264DSP)   += loongarch/h264dsp_lasx.o \
  loongarch/h264_deblock_lasx.o
@@ -38,3 +39,4 @@ LSX-OBJS-$(CONFIG_H264QPEL)   += loongarch/h264qpel.o 
\
  loongarch/h264qpel_lsx.o
 LSX-OBJS-$(CONFIG_H264CHROMA) += loongarch/h264chroma.o
 LSX-OBJS-$(CONFIG_H264PRED)   += loongarch/h264intrapred.o
+LSX-OBJS-$(CONFIG_AAC_ENCODER)+= loongarch/aacencdsp.o
diff --git a/libavcodec/loongarch/aacencdsp.S b/libavcodec/loongarch/aacencdsp.S
new file mode 100644
index 00..a7cfd3bb1c
--- /dev/null
+++ b/libavcodec/loongarch/aacencdsp.S
@@ -0,0 +1,255 @@
+/*
+ * Loongarch LASX/LSX optimizeds AAC encoder DSP functions
+ *
+ * Copyright (c) 2024 Loongson Technology Corporation Limited
+ * Contributed by PengXu 
+ *
+ * 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 "loongson_asm.S"
+
+
+/* void ff_abs_pow34_lsx(float *out, const float *in, const int size); */
+// Param, out:a0, in:a1, size:a2
+function ff_abs_pow34_lsx
+move  t0,  zero  //loop param
+move  t1,  zero  //data index
+
+srai.dt2,  a2,  2
+beq   zero,t2,  .FAPL02
+
+.FAPL01:
+add.d t3,  a1,  t1
+fld.s f0,  t3,  0x00
+fld.s f1,  t3,  0x04
+fld.s f2,  t3,  0x08
+fld.s f3,  t3,  0x0c
+
+fabs.sf0,  f0
+fabs.sf1,  f1
+fabs.sf2,  f2
+fabs.sf3,  f3
+
+vextrins.wvr0, vr1, 0x10
+vextrins.wvr0, vr2, 0x20
+vextrins.wvr0, vr3, 0x30
+
+vfsqrt.s  vr4, vr0
+vfmul.s   vr5, vr0, vr4
+vfsqrt.s  vr6, vr5
+
+vstx  vr6, a0,  t1
+
+addi.dt1,  t1,  16
+addi.dt0,  t0,  1
+blt   t0,  t2,  .FAPL01
+
+.FAPL02:  /* &2 */
+andi  t0,  a2,  2
+beq   zero,t0,  .FAPL03
+
+add.d t3,  a1,  t1
+add.d t4,  a0,  t1
+
+fld.s f0,  t3,  0x00
+fld.s f1,  t3,  0x04
+
+

Re: [FFmpeg-devel] Add optimization in swscale for LA.

[Shiyou Yin]

> 2024年3月27日 03:31，Michael Niedermayer  写道：
> 
> On Tue, Mar 26, 2024 at 11:11:00AM +0800, Shiyou Yin wrote:
>> 
>>> 2024年3月16日 11:03，Shiyou Yin  写道：
>>> 
>>> [PATCH 1/3] swscale: [LA] Optimize range convert for yuvj420p.
>>> [PATCH 2/3] swscale: [LA] Optimize yuv2plane1_8_c.
>>> [PATCH 3/3] swscale: [LA] Optimize swscale funcs in input.c
>>> 
>>> ___
>>> 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”.
>> 
>> Hi, Michale
>>Could you please help to review this patch set, thanks.
> 
> I can apply it if it has been reviewed but i cannot review it currently
> 
> thx
> 

Please help to apply this patch set, it has been tested and reviewed by my 
colleague.
___
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] lavc/vvc: Fix out-of-bounds array access

[Frank Plowman]

The 2 which has been changed to an 8 in the array length expression is
the maximum value of sps_bitdepth_minus8.  This was missed when updating
to VVCv2, which increased this maximum from 2 to 8.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/intra.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/libavcodec/vvc/intra.c b/libavcodec/vvc/intra.c
index 5ac7d02c80..def113239b 100644
--- a/libavcodec/vvc/intra.c
+++ b/libavcodec/vvc/intra.c
@@ -339,18 +339,22 @@ static void derive_qp(const VVCLocalContext *lc, const 
TransformUnit *tu, Transf
 //8.7.3 Scaling process for transform coefficients
 static av_always_inline int derive_scale(const TransformBlock *tb, const int 
sh_dep_quant_used_flag)
 {
-static const uint8_t rem6[63 + 2 * 6 + 1] = {
+static const uint8_t rem6[63 + 8 * 6 + 1] = {
 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2,
 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5,
 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3,
-4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3
+4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1,
+2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5, 0, 1, 2, 3, 4, 5,
+0, 1, 2, 3,
 };
 
-static const uint8_t div6[63 + 2 * 6 + 1] = {
+static const uint8_t div6[63 + 8 * 6 + 1] = {
 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 2, 3,  3,  3,
 3, 3, 3, 4, 4, 4, 4, 4, 4, 5, 5, 5, 5, 5, 5, 6, 6, 6, 6,  6,  6,
 7, 7, 7, 7, 7, 7, 8, 8, 8, 8, 8, 8, 9, 9, 9, 9, 9, 9, 10, 10, 10, 10,
-10, 10, 11, 11, 11, 11, 11, 11, 12, 12, 12, 12
+10, 10, 11, 11, 11, 11, 11, 11, 12, 12, 12, 12, 12, 12, 13, 13, 13, 13,
+13, 13, 14, 14, 14, 14, 14, 14, 15, 15, 15, 15, 15, 15, 16, 16, 16, 16,
+16, 16, 17, 17, 17, 17, 17, 17, 18, 18, 18, 18,
 };
 
 const static int level_scale[2][6] = {
-- 
2.44.0

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

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

Re: [FFmpeg-devel] [PATCH v2 2/2] configure: simplify bigendian check

[Martin Storsjö]

On Mon, 8 Apr 2024, J. Dekker wrote:


The preferred way to use LTO is --enable-lto but often times packagers
still end up with -flto in cflags for various reasons. Using grep
on binary object files is brittle and relies on specific object
representation, which in the case of LLVM bitcode, debug-info or other
intermediary formats can fail silently.

This patch changes the check to a more commonly used define for
big-endian systems.


It's not common only for big-endian systems, but for GCC-style compilers 
on all endians.



More checks may need to be added in the future to cover legacy machines.


Don't use the word "legacy" here. This define is not standard, so it's 
perfectly plausible to have a modern, standards compliant compiler that 
just doesn't use this define.


With the commmit message you added here, the change is ok, but please do 
reword the last sentence above.


I'd suggest changing the last paragraph into this:

---
This patch changes the check to a more commonly used define for
GCC style compilers. More checks may be needed to cover other potential 
compilers that don't use the __BYTE_ORDER__ define.

---

// Martin

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

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

Re: [FFmpeg-devel] [PATCH v2 1/2] configure, etc: unify shebang usage

[Martin Storsjö]

On Mon, 8 Apr 2024, J. Dekker wrote:


In some cases, these scripts can be called directly by packagers, and
some systems require the interpreter to be explicit.


It is unclear to me which of the changes are needed and for what reason, 
please elaborate much more in the commit message.


Is it possible to elaborate on "some systems require the interpreter to be 
explicit"? It'd be much nicer to reason about if there was a concrete 
example of such a case (even if it certainly is right to add the missing 
shebang line).


The changes I see fall into these categories:

- Change "#! " into "#!. Does this change have a functional 
effect for someone (where, and why?) or is it purely a cosmetic change?
- Add a shebang line in the generated ffbuild/config.sh. This script is 
highly unlikely to be useful to call on its own like that, so while this 
probably is good for consistency I don't see it ever making a difference.
- Add a shebang line in ffbuild/libversion.sh. I can see the value in 
calling this script directly, outside of our build system. I presume this 
is the actual change that makes a difference here?


I don't mind the changes, but I'd prefer to split them into two separate 
commits; add missing shebangs (with an example of the case where it really 
does make a difference), vs removing extra spaces in shebangs for 
consistency (with explicit clarification in the commit message whether 
this is only for stylistic consistency or whether it does make a 
difference somewhere, and if it does, where).


// Martin

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

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

Re: [FFmpeg-devel] Query from Reuters on XZ, open source, and Microsoft

[Nicolas George]

Rémi Denis-Courmont (12024-04-09):
> Switching to an own Gitlab instance would simplify code review (that's
> why I'm in favour) but it will add more burden on system admins, and
> make joining the project harder.

Over the last fifteen months, I have updated GitLab sixteen times for
security issues (actually thirty two: sixteen for the mathematicians,
sixteen for the computer scientists).

I am pointing that for the burden, I am not offering to do the same for
free for the people who are so short-sighted they feel entitled to block
software-defined radio, break real-time display devices, prevent me from
adding the strings API necessary for proper built-in documentation and
information exfiltration from devices, etc., and apparently can.

-- 
  Nicolas George
___
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] lavc/vvc: Avoid overflow in coeff scale intermediate

[Frank Plowman]

Make intermediate result 64-bits to avoid an overflow before the right
shift.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/intra.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vvc/intra.c b/libavcodec/vvc/intra.c
index e515fb9710..5ac7d02c80 100644
--- a/libavcodec/vvc/intra.c
+++ b/libavcodec/vvc/intra.c
@@ -416,7 +416,7 @@ static const uint8_t* derive_scale_m(const VVCLocalContext 
*lc, const TransformB
 static av_always_inline int scale_coeff(const TransformBlock *tb, int coeff,
 const int scale, const int scale_m, const int log2_transform_range)
 {
-coeff = (coeff * scale * scale_m + tb->bd_offset) >> tb->bd_shift;
+coeff = ((int64_t) coeff * scale * scale_m + tb->bd_offset) >> 
tb->bd_shift;
 coeff = av_clip_intp2(coeff, log2_transform_range);
 return coeff;
 }
-- 
2.44.0

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

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

[FFmpeg-devel] [PATCH] lavc/vvc: Fix buffer overread in CABAC

[Frank Plowman]

The size variable here is taken as gospel for the bounds of the input
buffer in later logic.  Clamp it to ensure that the returned region
does not extend past that allocated in the underlying GetBitContext,
even in the case entry point offsets are signalled in the bitstream.
Also assert this for good measure.

Signed-off-by: Frank Plowman 
---
 libavcodec/vvc/dec.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index 27ffbb741d..a4fc40b40a 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -497,9 +497,11 @@ static void ep_init_cabac_decoder(SliceContext *sc, const 
int index,
 skipped++;
 }
 size = end - start;
+size = av_clip(size, 0, get_bits_left(gb) / 8);
 } else {
 size = get_bits_left(gb) / 8;
 }
+av_assert0(gb->buffer + get_bits_count(gb) / 8 + size <= gb->buffer_end);
 ff_init_cabac_decoder (>cc, gb->buffer + get_bits_count(gb) / 8, size);
 skip_bits(gb, size * 8);
 }
-- 
2.44.0

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

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

Re: [FFmpeg-devel] [PATCH] avutil/hwcontext_d3d12va: wait the texture is used before to free it.

[Wu, Tong1]

Hi,

>From: ffmpeg-devel  On Behalf Of Renan
>Lavarec via ffmpeg-devel
>Sent: Monday, April 8, 2024 11:27 PM
>To: ffmpeg-devel@ffmpeg.org
>Cc: Renan Lavarec 
>Subject: [FFmpeg-devel] [PATCH] avutil/hwcontext_d3d12va: wait the texture is
>used before to free it.
>
>From: Renan Lavarec 124602499+rlavarec-
>g...@users.noreply.github.comg...@users.noreply.github.com>
>Date: Mon, 8 Apr 2024 14:38:10 +0200
>Subject: [PATCH] avutil/hwcontext_d3d12va: wait the texture is used inside the
>GPU before to free it.
>
>fix: ID3D12Resource2::: CORRUPTION: An ID3D12Resource
>object (0x0222D58B5450:'Unnamed Object') is referenced by GPU
>operations in-flight on Command Queue (0x0222EEC87090:'Unnamed
>ID3D12CommandQueue Object').
> It is not safe to final-release objects that may have GPU operations 
> pending.
>This can result in application instability. [ EXECUTION ERROR #921:
>OBJECT_DELETED_WHILE_STILL_IN_USE]
>---
>libavutil/hwcontext_d3d12va.c | 3 +++
>1 file changed, 3 insertions(+)
>
>diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
>index cfc016315d..621a79d257 100644
>--- a/libavutil/hwcontext_d3d12va.c
>+++ b/libavutil/hwcontext_d3d12va.c
>@@ -220,6 +220,9 @@ static void free_texture(void *opaque, uint8_t *data)
>{
> AVD3D12VAFrame *frame = (AVD3D12VAFrame *)data;
>
>+// Wait texture to be available
>+d3d12va_fence_completion(>sync_ctx);
>+
> D3D12_OBJECT_RELEASE(frame->texture);
> D3D12_OBJECT_RELEASE(frame->sync_ctx.fence);
> if (frame->sync_ctx.event)
>--
>2.44.0.windows.1

At what scenario will this happen? I think decoder should be responsible for 
the completion of the CommandQueue before releasing the buffer pool. And that's 
what d3d12va_decode has already done in uninit call. Thanks.

-Tong 
___
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 02/27] avcodec/decode: Add new ProgressFrame API

[Andreas Rheinhardt]

Michael Niedermayer:
> On Mon, Apr 08, 2024 at 10:13:40PM +0200, Andreas Rheinhardt wrote:
>> Frame-threaded decoders with inter-frame dependencies
>> use the ThreadFrame API for syncing. It works as follows:
>>
>> During init each thread allocates an AVFrame for every
>> ThreadFrame.
>>
>> Thread A reads the header of its packet and allocates
>> a buffer for an AVFrame with ff_thread_get_ext_buffer()
>> (which also allocates a small structure that is shared
>> with other references to this frame) and sets its fields,
>> including side data. Then said thread calls ff_thread_finish_setup().
>> From that moment onward it is not allowed to change any
>> of the AVFrame fields at all any more, but it may change
>> fields which are an indirection away, like the content of
>> AVFrame.data or already existing side data.
>>
>> After thread A has called ff_thread_finish_setup(),
>> another thread (the user one) calls the codec's update_thread_context
>> callback which in turn calls ff_thread_ref_frame() which
>> calls av_frame_ref() which reads every field of A's
>> AVFrame; hence the above restriction on modifications
>> of the AVFrame (as any modification of the AVFrame by A after
>> ff_thread_finish_setup() would be a data race). Of course,
>> this av_frame_ref() also incurs allocations and therefore
>> needs to be checked. ff_thread_ref_frame() also references
>> the small structure used for communicating progress.
>>
>> This av_frame_ref() makes it awkward to propagate values that
>> only become known during decoding to later threads (in case of
>> frame reordering or other mechanisms of delayed output (like
>> show-existing-frames) it's not the decoding thread, but a later
>> thread that returns the AVFrame). E.g. for VP9 when exporting video
>> encoding parameters as side data the number of blocks only
>> becomes known during decoding, so one can't allocate the side data
>> before ff_thread_finish_setup(). It is currently being done afterwards
>> and this leads to a data race in the vp9-encparams test when using
>> frame-threading. Returning decode_error_flags is also complicated
>> by this.
>>
>> To perform this exchange a buffer shared between the references
>> is needed (notice that simply giving the later threads a pointer
>> to the original AVFrame does not work, because said AVFrame will
>> be reused lateron when thread A decodes the next packet given to it).
>> One could extend the buffer already used for progress for this
>> or use a new one (requiring yet another allocation), yet both
>> of these approaches have the drawback of being unnatural, ugly
>> and requiring quite a lot of ad-hoc code. E.g. in case of the VP9
>> side data mentioned above one could not simply use the helper
>> that allocates and adds the side data to an AVFrame in one go.
>>
>> The ProgressFrame API meanwhile offers a different solution to all
>> of this. It is based around the idea that the most natural
>> shared object for sharing information about an AVFrame between
>> decoding threads is the AVFrame itself. To actually implement this
>> the AVFrame needs to be reference counted. This is achieved by
>> putting a (ownership) pointer into a shared (and opaque) structure
>> that is managed by the RefStruct API and which also contains
>> the stuff necessary for progress reporting.
>> The users get a pointer to this AVFrame with the understanding
>> that the owner may set all the fields until it has indicated
>> that it has finished decoding this AVFrame; then the users are
>> allowed to read everything. Every decoder may of course employ
>> a different contract than the one outlined above.
>>
>> Given that there is no underlying av_frame_ref(), creating
>> references to a ProgressFrame can't fail. Only
>> ff_thread_progress_get_buffer() can fail, but given that
>> it will replace calls to ff_thread_get_ext_buffer() it is
>> at places where errors are already expected and properly
>> taken care of.
>>
>> The ProgressFrames are empty (i.e. the AVFrame pointer is NULL
>> and the AVFrames are not allocated during init at all)
>> while not being in use; ff_thread_progress_get_buffer() both
>> sets up the actual ProgressFrame and already calls
>> ff_thread_get_buffer(). So instead of checking for
>> ThreadFrame.f->data[0] or ThreadFrame.f->buf[0] being NULL
>> for "this reference frame is non-existing" one should check for
>> ProgressFrame.f.
>>
>> This also implies that one can only set AVFrame properties
>> after having allocated the buffer. This restriction is not deep:
>> if it becomes onerous for any codec, ff_thread_progress_get_buffer()
>> can be broken up. The user would then have to get a buffer
>> himself.
>>
>> In order to avoid unnecessary allocations, the shared structure
>> is pooled, so that both the structure as well as the AVFrame
>> itself are reused. This means that there won't be lots of
>> unnecessary allocations in case of non-frame-threaded decoding.
>> It might even turn out to have fewer than the current 

[FFmpeg-devel] [PATCH v3 01/27] avcodec/threadprogress: Add new API for frame-threaded progress

[Andreas Rheinhardt]

The API is similar to the ThreadFrame API, with the exception
that it no longer has an included AVFrame and that it has its
own mutexes and condition variables which makes it more independent
of pthread_frame.c. One can wait on anything via a ThreadProgress.
One just has to ensure that the lifetime of the object containing
the ThreadProgress is long enough. This will typically be solved
by putting a ThreadProgress in a refcounted structure that is
shared between threads.

Signed-off-by: Andreas Rheinhardt 
---
Now using ff_mutex_*/ff_cond_* instead of their pthread counterparts.

 libavcodec/threadprogress.c | 79 
 libavcodec/threadprogress.h | 91 +
 2 files changed, 170 insertions(+)
 create mode 100644 libavcodec/threadprogress.c
 create mode 100644 libavcodec/threadprogress.h

diff --git a/libavcodec/threadprogress.c b/libavcodec/threadprogress.c
new file mode 100644
index 00..62c4fd898b
--- /dev/null
+++ b/libavcodec/threadprogress.c
@@ -0,0 +1,79 @@
+/*
+ * Copyright (c) 2022 Andreas Rheinhardt 
+ *
+ * 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 
+#include 
+
+#include "pthread_internal.h"
+#include "threadprogress.h"
+#include "libavutil/attributes.h"
+#include "libavutil/thread.h"
+
+DEFINE_OFFSET_ARRAY(ThreadProgress, thread_progress, init,
+(offsetof(ThreadProgress, progress_mutex)),
+(offsetof(ThreadProgress, progress_cond)));
+
+av_cold int ff_thread_progress_init(ThreadProgress *pro, int init_mode)
+{
+atomic_init(>progress, init_mode ? -1 : INT_MAX);
+#if HAVE_THREADS
+if (init_mode)
+return ff_pthread_init(pro, thread_progress_offsets);
+#endif
+pro->init = init_mode;
+return 0;
+}
+
+av_cold void ff_thread_progress_destroy(ThreadProgress *pro)
+{
+#if HAVE_THREADS
+ff_pthread_free(pro, thread_progress_offsets);
+#else
+pro->init = 0;
+#endif
+}
+
+void ff_thread_progress_report(ThreadProgress *pro, int n)
+{
+if (atomic_load_explicit(>progress, memory_order_relaxed) >= n)
+return;
+
+atomic_store_explicit(>progress, n, memory_order_release);
+
+ff_mutex_lock(>progress_mutex);
+ff_cond_broadcast(>progress_cond);
+ff_mutex_unlock(>progress_mutex);
+}
+
+void ff_thread_progress_await(const ThreadProgress *pro_c, int n)
+{
+/* Casting const away here is safe, because we only read from progress
+ * and will leave pro_c in the same state upon leaving the function
+ * as it had at the beginning. */
+ThreadProgress *pro = (ThreadProgress*)pro_c;
+
+if (atomic_load_explicit(>progress, memory_order_acquire) >= n)
+return;
+
+ff_mutex_lock(>progress_mutex);
+while (atomic_load_explicit(>progress, memory_order_relaxed) < n)
+ff_cond_wait(>progress_cond, >progress_mutex);
+ff_mutex_unlock(>progress_mutex);
+}
diff --git a/libavcodec/threadprogress.h b/libavcodec/threadprogress.h
new file mode 100644
index 00..786802cbf1
--- /dev/null
+++ b/libavcodec/threadprogress.h
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2022 Andreas Rheinhardt 
+ *
+ * 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_THREADPROGRESS_H
+#define AVCODEC_THREADPROGRESS_H
+
+/**
+ * ThreadProgress is an API to easily notify other threads about progress
+ * of any kind as long as it can be packaged into an int and is consistent
+ * with the natural ordering of integers.
+ *
+ * Each initialized ThreadProgress can be in one of two modes: No-op mode
+ * or