Re: [FFmpeg-devel] [PATCH 2/2] lavc/blockdsp: R-V V fill_block

2024-04-29 Thread Rémi Denis-Courmont


Le 30 avril 2024 03:26:25 GMT+03:00, flow gg  a écrit :
>Hi, I initially used a loop, but according to libavcodec/blockdsp.h,
>
>the maximum is 8x16 = 128 bytes, so using ff_get_rv_vlenb() >= 16 and m8
>does not require a loop.

It's okay to assume that VLENB is at least 16 bytes (as long as it's checked), 
but the code seems to assume (?) that it's *exactly* 16 bytes, which will break 
on future hardware.

>
>```
>/* add and put pixel (decoding)
> * Block sizes for op_pixels_func are 8x4,8x8 16x8 16x16.
> * h for op_pixels_func is limited to { width / 2, width },
> * but never larger than 16 and never smaller than 4. */
>typedef void (*op_fill_func)(uint8_t *block /* align width (8 or 16) */,
> uint8_t value, ptrdiff_t line_size, int h);
>```
>
>Rémi Denis-Courmont  于2024年4月30日周二 01:31写道:
>
>> Le maanantaina 29. huhtikuuta 2024, 10.09.41 EEST flow gg a écrit :
>> >
>>
>> Are you sure that this works with all vector lengths?
>> The block8 code looks odd.
>>
>> --
>> レミ・デニ-クールモン
>> http://www.remlab.net/
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@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 5/6] vaapi_av1: Fix force_integer_mv value

2024-04-29 Thread Xiang, Haihao
On Sa, 2024-04-27 at 16:30 +0100, Mark Thompson wrote:
> ---
>  libavcodec/vaapi_av1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
> index 1f563483b9..f61bf63098 100644
> --- a/libavcodec/vaapi_av1.c
> +++ b/libavcodec/vaapi_av1.c
> @@ -220,7 +220,7 @@ static int vaapi_av1_start_frame(AVCodecContext *avctx,
>  .error_resilient_mode = frame_header-
> >error_resilient_mode,
>  .disable_cdf_update   = frame_header->disable_cdf_update,
>  .allow_screen_content_tools   = frame_header-
> >allow_screen_content_tools,
> -    .force_integer_mv = frame_header->force_integer_mv,
> +    .force_integer_mv = s->cur_frame.force_integer_mv,
>  .allow_intrabc    = frame_header->allow_intrabc,
>  .use_superres = frame_header->use_superres,
>  .allow_high_precision_mv  = frame_header-
> >allow_high_precision_mv,

LGTM, vaapi av1 also requires this value instead of the syntax element value.

Thanks
Haihao


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

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


Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_hevc: Don't require exact profiles

2024-04-29 Thread Xiang, Haihao
On So, 2024-04-28 at 15:14 +0100, Mark Thompson wrote:
> On 24/04/2024 14:45, Xiang, Haihao wrote:
> > On Ma, 2024-04-22 at 22:23 +0100, Mark Thompson wrote:
> > > Rather than turning the constraint flags into a single profile and then
> > > searching for that profile (and failing if it doesn't match any profile
> > > exactly), instead search all supported profiles and use the first one
> > > which supports the given set of constraint flags.
> > > ---
> > > This fixes decode of rext 8-bit 4:2:0; it will correctly pick Main 12 or
> > > Main
> > > 4:2:2 10 or Main 4:4:4 (first one available) to use as the decoding
> > > profile
> > > after this patch.
> > 
> > sw decoding and vaapi decoding might have different bits (There is the same
> > issue if applying Fei's patchset).  
> > 
> > For example:
> > $ ffmpeg -hwaccel vaapi -f lavfi -i testsrc -vf 'format=nv12,hwupload' -c:v
> > hevc_vaapi -profile:v rext -vframes 30 -y out.mp4
> > 
> > 8bit ouput if using sw decoding:
> > $ ffmpeg -i out.mp4 -f null - 
> > [...]
> > Stream #0:0(und): Video: wrapped_avframe, yuv420p(tv, progressive), 320x240
> > [SAR
> > 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn (default)
> > 
> > 12bit output if using vaapi decoding:
> > $ ffmpeg -hwaccel vaapi -i out.mp4 -f null -
> > [...]
> >  Stream #0:0(und): Video: wrapped_avframe, p012le(tv, progressive), 320x240
> > [SAR
> > 1:1 DAR 4:3], q=2-31, 200 kb/s, 25 fps, 25 tbn (default)
> 
> That comes from what the driver reports support for, though?
> 
> E.g. with the Intel iHD driver, I have
> 
>     {
>     "profile": 23,
>     "name": "HEVCMain12",
> ...
>     "surface_formats": [
>     {
>     "rt_format": "YUV420",
>     "max_width": 16384,
>     "max_height": 16384,
>     "memory_types": [
>     "VA",
>     "DRM_PRIME_2",
>     ],
>     "pixel_formats": [
>     "P012",
>     "P016",
>     ],
>     },
> 
> So to decode a 4:2:0 8-bit input it is asking for a P012 or P016 surface.
> 
> If the driver reported that a Main 12 profile 4:2:0 8-bit input could be
> decoded to an NV12 surface then it would be picked by the logic in
> vaapi_decode_find_best_format(), since it would be a better match than the
> higher-depth formats.

You are right, the iHD driver doesn't report the support for HEVCMain12 8bit. 

Thanks
Haihao

___
ffmpeg-devel mailing list
ffmpeg-devel@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 WIP v2 1/9] avfilter/dnn: Refactor DNN parameter configuration system

2024-04-29 Thread Chen, Wenbin
> -Original Message-
> From: ffmpeg-devel  On Behalf Of Zhao
> Zhili
> Sent: Sunday, April 28, 2024 2:47 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zhao Zhili 
> Subject: [FFmpeg-devel] [PATCH WIP v2 1/9] avfilter/dnn: Refactor DNN
> parameter configuration system
> 
> From: Zhao Zhili 
> +
> +void *ff_dnn_child_next(DnnContext *obj, void *prev) {
> +size_t pre_offset;
> +char *ptr;
> +
> +if (!prev) {
> +obj->clazz = &dnn_base_class;
> +return obj;
> +}
> +
> +pre_offset = (char *)prev - (char *)obj;
> +for (int i = 0; i < FF_ARRAY_ELEMS(dnn_backend_info_list) - 1; i++) {
> +if (dnn_backend_info_list[i].offset == pre_offset) {
> +ptr = (char *)obj + dnn_backend_info_list[i + 1].offset;
> +*(const AVClass **) ptr = dnn_backend_info_list[i + 1].class;
> +return ptr;
> +}
> +}
> +
> +return NULL;
> +}

Can this function be simplified by implementing AVFilter.preinit interface in 
each dnn filter
and assign class to DNNContext and TF/OV/THOption in preinit function?  I don't 
think setting AVClass
in child_next() function is the proper way.

wenbin

> +
> +const AVClass *ff_dnn_child_class_iterate(void **iter)
> +{
> +uintptr_t i = (uintptr_t) *iter;
> +
> +if (i < FF_ARRAY_ELEMS(dnn_backend_info_list)) {
> +*iter = (void *)(i + 1);
> +return dnn_backend_info_list[i].class;
> +}
> +
> +return NULL;
> +}
___
ffmpeg-devel mailing list
ffmpeg-devel@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 WIP 0/9] Refactor DNN

2024-04-29 Thread Chen, Wenbin
> > On Apr 29, 2024, at 18:29, Guo, Yejun 
> wrote:
> >
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> Zhao
> >> Zhili
> >> Sent: Sunday, April 28, 2024 6:55 PM
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH WIP 0/9] Refactor DNN
> >>
> >>
> >>
> >>> On Apr 28, 2024, at 18:34, Guo, Yejun  >> intel@ffmpeg.org> wrote:
> >>>
>  -Original Message-
>  From: ffmpeg-devel   > On Behalf Of Zhao Zhili
>  Sent: Sunday, April 28, 2024 12:42 AM
>  To: ffmpeg-devel@ffmpeg.org 
>  Cc: Zhao Zhili  >
>  Subject: [FFmpeg-devel] [PATCH WIP 0/9] Refactor DNN
> 
>  From: Zhao Zhili 
> 
>  During the refactor progress, I have found some serious issues, which
>  is not resolved by the patchset:
> 
>  1. Tensorflow backend is broken.
> 
>  I think it doesn't work since 2021 at least. For example, it destroy
>  a thread and create a new thread for each frame, and it destroy an
>  invalid thread at the first
>  frame:
> >>>
> >>> It works from the day that code is merged, till today. It is by design
> >>> to keep the code simplicity by using the feature that pthread_join
> >>> accepts a parameter that is not a joinable thread.
> >>>
> >>> Please share more info if you experienced a real case that it does not
> work.
> >>
> >> It will abort if ASSERT_LEVEL > 1.
> >>
> >> #define ASSERT_PTHREAD_ABORT(func, ret) do {\
> >>char errbuf[AV_ERROR_MAX_STRING_SIZE] = ""; \
> >>av_log(NULL, AV_LOG_FATAL, AV_STRINGIFY(func)   \
> >>   " failed with error: %s\n",  \
> >>   av_make_error_string(errbuf, AV_ERROR_MAX_STRING_SIZE,   \
> >>AVERROR(ret))); \
> >>abort();\
> >> } while (0)
> >>
> >> I think the check is there just to prevent call pthread_join(0, &ptr) by
> accident,
> >> so we shouldn’t do that on purpose.
> >>
> > Nice catch with configure assert level > 1, will fix, and patch also 
> > welcome,
> thanks.
> 
> If I read the code correctly, it destroy a thread and create a new thread for
> each
> frame. I think this “async” mode isn’t common in ffmpeg’s design. Create new
> thread
> for each frame can be heavy on some platforms. We use slice threading to
> improve
> parallel, and thread with command queue to improve throughput. In this
> case with
> tensorflow do the heavy lift, if it doesn’t support async operation, simple
> synchronous
> operation with tensorflow backend should be find. The “async” mode is
> unnecessary
> and use more resource  over the benefit it provides.

I think we need to keep async support.
1. Some model cannot make full use of resource. This may be caused by tensorflow
implementation or by model design. Async has benefit on this situation.
2. Async helps to build pipeline. You don't need to wait the output. If a 
"synchronous" filter
followed by another "synchronous" filter, it can be the bottle neck of the 
whole pipeline.

The benefit on these two situations will be more obvious if model is running on 
GPU.( Tensorflow
has not added device support yet.)

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

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


Re: [FFmpeg-devel] [PATCH 1/2] checkasm/blockdsp: add fill_block test

2024-04-29 Thread flow gg
Since there is no 8x16, not test 8x16, and updated it in the reply

flow gg  于2024年4月29日周一 15:09写道:

>
>
From fc7c28cb78e0c90880f31c0b8d6f2fc16d0fe581 Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Mon, 29 Apr 2024 14:18:23 +0800
Subject: [PATCH 1/2] checkasm/blockdsp: add fill_block test

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

diff --git a/tests/checkasm/blockdsp.c b/tests/checkasm/blockdsp.c
index 22a2f79455..19d69b8687 100644
--- a/tests/checkasm/blockdsp.c
+++ b/tests/checkasm/blockdsp.c
@@ -29,6 +29,11 @@
 #include "libavutil/intreadwrite.h"
 #include "libavutil/mem_internal.h"
 
+typedef struct {
+const char *name;
+int size;
+} test;
+
 #define randomize_buffers(size) \
 do {\
 int i;  \
@@ -52,6 +57,30 @@ do {\
 }   \
 } while (0)
 
+static void check_fill(BlockDSPContext *h){
+const test tests[] = {
+{"fill_block_tab[0]", 16},
+{"fill_block_tab[1]", 8},
+};
+LOCAL_ALIGNED_32(uint8_t, buf0, [16 * 16]);
+LOCAL_ALIGNED_32(uint8_t, buf1, [16 * 16]);
+
+for (size_t t = 0; t < FF_ARRAY_ELEMS(tests); ++t) {
+int n = tests[t].size;
+declare_func(void, uint8_t *block, uint8_t value,
+ ptrdiff_t line_size, int h);
+if (check_func(h->fill_block_tab[t], "blockdsp.%s", tests[t].name)) {
+uint8_t value = rnd();
+randomize_buffers(tests[t].size);
+call_ref(buf0, value, n, n);
+call_new(buf1, value, n, n);
+if (memcmp(buf0, buf1, sizeof(*buf0) * n * n))
+fail();
+bench_new(buf0, value, n, n);
+}
+}
+}
+
 void checkasm_check_blockdsp(void)
 {
 LOCAL_ALIGNED_32(uint16_t, buf0, [6 * 8 * 8]);
@@ -64,5 +93,7 @@ void checkasm_check_blockdsp(void)
 check_clear(clear_block,  8 * 8);
 check_clear(clear_blocks, 8 * 8 * 6);
 
+check_fill(&h);
+
 report("blockdsp");
 }
-- 
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 2/2] lavc/blockdsp: R-V V fill_block

2024-04-29 Thread flow gg
Since there is no 8x16, I changed m8 to m4, and updated it in the reply



flow gg  于2024年4月30日周二 08:26写道:

> Hi, I initially used a loop, but according to libavcodec/blockdsp.h,
>
> the maximum is 8x16 = 128 bytes, so using ff_get_rv_vlenb() >= 16 and m8
> does not require a loop.
>
> ```
> /* add and put pixel (decoding)
>  * Block sizes for op_pixels_func are 8x4,8x8 16x8 16x16.
>  * h for op_pixels_func is limited to { width / 2, width },
>  * but never larger than 16 and never smaller than 4. */
> typedef void (*op_fill_func)(uint8_t *block /* align width (8 or 16) */,
>  uint8_t value, ptrdiff_t line_size, int h);
> ```
>
> Rémi Denis-Courmont  于2024年4月30日周二 01:31写道:
>
>> Le maanantaina 29. huhtikuuta 2024, 10.09.41 EEST flow gg a écrit :
>> >
>>
>> Are you sure that this works with all vector lengths?
>> The block8 code looks odd.
>>
>> --
>> レミ・デニ-クールモン
>> http://www.remlab.net/
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>>
>
From 38068cd4c770b24ac494bddab6c3d19149d2f5cb Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Wed, 6 Mar 2024 12:46:03 +0800
Subject: [PATCH 2/2] lavc/blockdsp: R-V V fill_block

C908:
blockdsp.fill_block_tab[0]_c: 549.7
blockdsp.fill_block_tab[0]_rvv_i64: 48.2
blockdsp.fill_block_tab[1]_c: 77.0
blockdsp.fill_block_tab[1]_rvv_i64: 19.7
---
 libavcodec/riscv/blockdsp_init.c |  6 ++
 libavcodec/riscv/blockdsp_rvv.S  | 21 +
 2 files changed, 27 insertions(+)

diff --git a/libavcodec/riscv/blockdsp_init.c b/libavcodec/riscv/blockdsp_init.c
index 59b2f9d47b..42c8e87fa7 100644
--- a/libavcodec/riscv/blockdsp_init.c
+++ b/libavcodec/riscv/blockdsp_init.c
@@ -27,6 +27,10 @@
 
 void ff_clear_block_rvv(int16_t *block);
 void ff_clear_blocks_rvv(int16_t *block);
+void ff_fill_block16_rvv(uint8_t *block, uint8_t value, ptrdiff_t line_size,
+   int h);
+void ff_fill_block8_rvv(uint8_t *block, uint8_t value, ptrdiff_t line_size,
+   int h);
 
 av_cold void ff_blockdsp_init_riscv(BlockDSPContext *c)
 {
@@ -36,6 +40,8 @@ av_cold void ff_blockdsp_init_riscv(BlockDSPContext *c)
 if (flags & AV_CPU_FLAG_RVV_I64 && ff_get_rv_vlenb() >= 16) {
 c->clear_block = ff_clear_block_rvv;
 c->clear_blocks = ff_clear_blocks_rvv;
+c->fill_block_tab[0] = ff_fill_block16_rvv;
+c->fill_block_tab[1] = ff_fill_block8_rvv;
 }
 #endif
 }
diff --git a/libavcodec/riscv/blockdsp_rvv.S b/libavcodec/riscv/blockdsp_rvv.S
index 8bb00bb467..18ab17da00 100644
--- a/libavcodec/riscv/blockdsp_rvv.S
+++ b/libavcodec/riscv/blockdsp_rvv.S
@@ -40,3 +40,24 @@ func ff_clear_blocks_rvv, zve64x
 
 ret
 endfunc
+
+func ff_fill_block16_rvv, zve32x
+vsetivli  t0, 16, e8, m1, ta, ma
+vmv.v.x   v8, a1
+1:
+addi  a3, a3, -1
+vse8.vv8, (a0)
+add   a0, a0, a2
+bnez  a3, 1b
+
+ret
+endfunc
+
+func ff_fill_block8_rvv, zve64x
+vsetvli   t0, zero, e8, m4, ta, ma
+vmv.v.x   v8, a1
+vsetvli   t0, a3, e64, m4, ta, ma
+vsse64.v  v8, (a0), a2
+
+ret
+endfunc
-- 
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 3/3] avutil/opt: Preserve nb_channels in opt_free

2024-04-29 Thread Michael Niedermayer
Fixes: division by 0
Fixes: decoder modifying demuxer channels on failure
Fixes: -sseof -5 -i zgclab/ffmpeg_crash/poc3

Found-by: Wang Dawei and Zhou Geng, from Zhongguancun Laboratory
Signed-off-by: Michael Niedermayer 
---
 libavutil/opt.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavutil/opt.c b/libavutil/opt.c
index ecbf7efe5fb..24c08e4bc06 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -132,9 +132,11 @@ static void opt_free_elem(const AVOption *o, void *ptr)
 av_dict_free((AVDictionary **)ptr);
 break;
 
-case AV_OPT_TYPE_CHLAYOUT:
+case AV_OPT_TYPE_CHLAYOUT: {
+int nb_channels = ((AVChannelLayout *)ptr)->nb_channels;
 av_channel_layout_uninit((AVChannelLayout *)ptr);
-break;
+((AVChannelLayout *)ptr)->nb_channels = nb_channels;
+break;}
 
 default:
 break;
-- 
2.43.2

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

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


[FFmpeg-devel] [PATCH 2/3] avformat/concatdec: Check file

2024-04-29 Thread Michael Niedermayer
Fixes: null pointer dereference
Fixes: -stream_loop 1 -ss 00:00:05 -i zgclab/ffmpeg_crash/poc2 -codec:v copy 
-codec:a aac -y output.mp4

Found-by: Wang Dawei and Zhou Geng, from Zhongguancun Laboratory
Signed-off-by: Michael Niedermayer 
---
 libavformat/concatdec.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index 493659649cf..fe65d0c7688 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -639,6 +639,11 @@ static int concat_parse_script(AVFormatContext *avf)
 }
 }
 
+if (!file) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
 if (file->inpoint != AV_NOPTS_VALUE && file->outpoint != AV_NOPTS_VALUE) {
 if (file->inpoint  > file->outpoint ||
 file->outpoint - (uint64_t)file->inpoint > INT64_MAX)
-- 
2.43.2

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

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


[FFmpeg-devel] [PATCH 1/3] avformat/kvag: Check sample_rate

2024-04-29 Thread Michael Niedermayer
Fixes: Division by 0
Fixes: -copyts -start_at_zero -itsoffset 00:00:01 -itsscale 1 -ss 00:00:02  -i 
zgclab/ffmpeg_crash/poc1 output.mp4

Found-by: Wang Dawei and Zhou Geng, from Zhongguancun Laboratory
Signed-off-by: Michael Niedermayer 
---
 libavformat/kvag.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/kvag.c b/libavformat/kvag.c
index 1d0aee09942..b55aa893ec2 100644
--- a/libavformat/kvag.c
+++ b/libavformat/kvag.c
@@ -38,7 +38,7 @@
 typedef struct KVAGHeader {
 uint32_tmagic;
 uint32_tdata_size;
-uint32_tsample_rate;
+intsample_rate;
 uint16_tstereo;
 } KVAGHeader;
 
@@ -70,6 +70,9 @@ static int kvag_read_header(AVFormatContext *s)
 hdr.sample_rate = AV_RL32(buf +  8);
 hdr.stereo  = AV_RL16(buf + 12);
 
+if (hdr.sample_rate <= 0)
+return AVERROR_INVALIDDATA;
+
 par = st->codecpar;
 par->codec_type = AVMEDIA_TYPE_AUDIO;
 par->codec_id   = AV_CODEC_ID_ADPCM_IMA_SSI;
-- 
2.43.2

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

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


Re: [FFmpeg-devel] [PATCH 2/2] lavc/blockdsp: R-V V fill_block

2024-04-29 Thread flow gg
Hi, I initially used a loop, but according to libavcodec/blockdsp.h,

the maximum is 8x16 = 128 bytes, so using ff_get_rv_vlenb() >= 16 and m8
does not require a loop.

```
/* add and put pixel (decoding)
 * Block sizes for op_pixels_func are 8x4,8x8 16x8 16x16.
 * h for op_pixels_func is limited to { width / 2, width },
 * but never larger than 16 and never smaller than 4. */
typedef void (*op_fill_func)(uint8_t *block /* align width (8 or 16) */,
 uint8_t value, ptrdiff_t line_size, int h);
```

Rémi Denis-Courmont  于2024年4月30日周二 01:31写道:

> Le maanantaina 29. huhtikuuta 2024, 10.09.41 EEST flow gg a écrit :
> >
>
> Are you sure that this works with all vector lengths?
> The block8 code looks odd.
>
> --
> レミ・デニ-クールモン
> http://www.remlab.net/
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


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

2024-04-29 Thread Hendrik Leppkes
On Mon, Apr 29, 2024 at 6:44 PM Ondřej Fiala  wrote:
>
> I would really suggest you look at SourceHut.

While SourceHut might be a slight improvement over the current
situation (and only slight), it being fundamentally still based on
email makes it inherit a lot of limitations and problems, and the
functionality of the web interface is severely lacking, as key
functions like commenting on patches are relegated back to your email
client.
Patch display functionality isn't any better then a mail client with a
bit of syntax highlighting, nevermind bespoke review tools that are
entirely absent, as it just sends you to your email client to respond.

At least thats what I see when checking the SourceHut instance of
SourceHut itself.

As far as solutions go, this isn't one that I would imagine, I'm
afraid. It's essentially a mailing list with patchwork. We have that
now.

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

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


Re: [FFmpeg-devel] [PATCH 2/4] lavc/vp9dsp: R-V V ipred vert

2024-04-29 Thread flow gg
updated it in the reply and https://github.com/hleft/FFmpeg/tree/vp8vp9

Rémi Denis-Courmont  于2024年4月30日周二 01:57写道:

> Le perjantaina 22. maaliskuuta 2024, 8.02.38 EEST flow gg a écrit :
> > Because the previous patch was updated, so it was updated in this
> response
>
> Seemingly needs rebase since April 7.
>
> --
> レミ・デニ-クールモン
> http://www.remlab.net/
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
From f9a3d9d10536520c8a0b34de46fd5804796207ac Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Sun, 7 Apr 2024 13:21:02 +0800
Subject: [PATCH 08/20] lavc/vp9dsp: R-V V ipred vert

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

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

2024-04-29 Thread Michael Niedermayer
On Mon, Apr 29, 2024 at 08:52:32AM +0200, Paul B Mahol wrote:
> On Sun, Apr 28, 2024 at 11:31 PM Michael Niedermayer 
> wrote:
> 
> > Fixes: CID1439569 Unchecked return value
> > Fixes: CID1439578 Unchecked return value
> >
> > Sponsored-by: Sovereign Tech Fund
> >
> 
> And they paid you for this low effort work!

not yet, i have over 600 coverity issues to go over, ATM coverity lists 677
outstanding.

some are in fact low effort, I wish all where low effort sadly thats not the 
case

Also these issues are open since many years (these 2 here since 2018)
apparently they where too high effort for anyone to deal with them before

also you and everyone is very welcome to submit a proposal / SoW
for any maintaince work. Low effort, High effort, anything ffmpeg
related. I presume there will be future rounds from STF


> 
> Applause!

thx

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

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr


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

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


Re: [FFmpeg-devel] [PATCH 2/5] avcodec/aaccoder: assert that escape case len is not causing issues

2024-04-29 Thread Michael Niedermayer
On Mon, Apr 29, 2024 at 12:26:24AM +0200, Lynne wrote:
> Apr 28, 2024, 23:57 by mich...@niedermayer.cc:
> 
> > On Sun, Apr 28, 2024 at 11:41:20PM +0200, Lynne wrote:
> >
> >> Apr 28, 2024, 23:31 by mich...@niedermayer.cc:
> >>
> >> > Inspired by CID1465483 Unintentional integer overflow
> >> >
> >> > Sponsored-by: Sovereign Tech Fund
> >> > Signed-off-by: Michael Niedermayer 
> >> > ---
> >> >  libavcodec/aaccoder.c | 2 ++
> >> >  1 file changed, 2 insertions(+)
> >> >
> >> > diff --git a/libavcodec/aaccoder.c b/libavcodec/aaccoder.c
> >> > index 4ce54ca8867..6e5817e237b 100644
> >> > --- a/libavcodec/aaccoder.c
> >> > +++ b/libavcodec/aaccoder.c
> >> > @@ -178,6 +178,8 @@ static av_always_inline float 
> >> > quantize_and_encode_band_cost_template(
> >> >  int coef = av_clip_uintp2(quant(fabsf(in[i+j]), Q, ROUNDING), 13);
> >> >  int len = av_log2(coef);
> >> > 
> >> > +av_assert2(len >= 4);
> >> > +
> >> >  put_bits(pb, len - 4 + 1, (1 << (len - 4 + 1)) - 2);
> >> >  put_sbits(pb, len, coef);
> >> >  }
> >> >
> >>
> >> I'm not sure that's correct to do. Any specific cases where this happens?
> >>
> >
> > if len is 3 or less then put_bits will have a negative value or
> > undefined shift
> >
> > coverity sasid this:
> > " overflow_before_widen: Potentially overflowing expression 1 << len - 4 + 
> > 1 with type int (32 bits, signed) is evaluated using 32-bit arithmetic, and 
> > then used in a context that expects an expression of type BitBuf (64 bits, 
> > unsigned). To avoid overflow, cast 1 to type BitBuf."
> >
> > So what coverity really said is that the expression could exeed 32bit 
> > _because_ its
> > used in 64bit context. Thats just stupid from coverity also teh clip above
> > limits this to 13 bit so i dont see how it can overflow in the "too large" 
> > direction
> > and i marked this one as false positive.
> >
> > I wasnt 100% sure about the too small side, i tested it and its never too 
> > small
> > but coverity didnt claim it could be too small, so that question is outside 
> > the issue
> > So i added a assert in this patch.
> >
> 
> Could you instead use 64-bit arithmetic for `coef`?
> Such a general assert here could result in false alarms, like the AAC
> encoder suffered from before, which would make development harder.

If you dont like the assert, then its best to just drop the patch.
It doesnt fix anything, it was just intended to clarify that the
case of len < 4 doesnt occur. The coverity issue is a false positive

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

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


Re: [FFmpeg-devel] [PATCH] libavdevice: Improve example in deprecation message for opengl and sdl

2024-04-29 Thread Alexander Strasser via ffmpeg-devel
On 2024-04-14 21:24 +0200, Nicolas George wrote:
> Nicolas George (12024-04-14):
> > Either we find options to make ffplay display frames as fast as
> > possible, or we must document to the user that no adequate replacement
> > exists.
>
> Please add “-vf setpts=0”. It still has a little more latency than a
> built-in device, but at least the feature is not *completely* broken.

Thank for your feedback. I sent a v2 with `-vf setpts=0`.


> > Or we make a point of fixing the devices that were broken.
>
> We still should.

As long as we are not able to get it fixed, an improved suggestion in
the deprecation message seems better than what we have now.


  Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavdevice: Improve example in deprecation message for opengl and sdl

2024-04-29 Thread Alexander Strasser via ffmpeg-devel
When piping ffmpeg into ffplay both programs write a status line in
the terminal. That causes flickering and invisibility of one or the
other status line.

As compromise set ffplay log level to warning, so it doesn't show
the status line.

The user is usually testing ffmpeg command lines and want's a
preview of the result. This way the user can see the ffmpeg output
and still see errors and warnings from ffplay, should they occur.

Additionally set PTS to zero in ffplay to lessen the delay until
the frames are displayed. Without it delay is quite observable
when e.g. live capturing with low frame rates.
---

Same as previous patch, but with setpts=0 in ffplay as suggested by
Nicolas George.


 libavdevice/opengl_enc.c | 2 +-
 libavdevice/sdl2.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavdevice/opengl_enc.c b/libavdevice/opengl_enc.c
index 6f7a30ff9e..93d3959880 100644
--- a/libavdevice/opengl_enc.c
+++ b/libavdevice/opengl_enc.c
@@ -1067,7 +1067,7 @@ static av_cold int opengl_write_header(AVFormatContext *h)
 av_log(opengl, AV_LOG_WARNING,
 "The opengl output device is deprecated due to being fundamentally 
incompatible with libavformat API. "
 "For monitoring purposes in ffmpeg you can output to a file or use 
pipes and a video player.\n"
-"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n"
+"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay 
-loglevel warning -vf setpts=0 -\n"
 );
 opengl->warned = 1;
 }
diff --git a/libavdevice/sdl2.c b/libavdevice/sdl2.c
index 779c8e08b0..491c8dafe8 100644
--- a/libavdevice/sdl2.c
+++ b/libavdevice/sdl2.c
@@ -167,7 +167,7 @@ static int sdl2_write_header(AVFormatContext *s)
 av_log(sdl, AV_LOG_WARNING,
 "The sdl output device is deprecated due to being fundamentally 
incompatible with libavformat API. "
 "For monitoring purposes in ffmpeg you can output to a file or use 
pipes and a video player.\n"
-"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay -\n"
+"Example: ffmpeg -i INPUT -f nut -c:v rawvideo - | ffplay 
-loglevel warning -vf setpts=0 -\n"
 );
 sdl->warned = 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 57/57] avcodec/ituh263enc: Remove redundant check

2024-04-29 Thread Andreas Rheinhardt
It is redundant due to the identical check in ff_mpv_encode_init().

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/ituh263enc.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
index b65a1c069a..c17303bff9 100644
--- a/libavcodec/ituh263enc.c
+++ b/libavcodec/ituh263enc.c
@@ -865,11 +865,6 @@ av_cold void ff_h263_encode_init(MpegEncContext *s)
 s->c_dc_scale_table= ff_mpeg1_dc_scale_table;
 }
 
-if (s->lmin > s->lmax) {
-av_log(s->avctx, AV_LOG_WARNING, "Clipping lmin value to %d\n", 
s->lmax);
-s->lmin = s->lmax;
-}
-
 ff_thread_once(&init_static_once, h263_encode_init_static);
 }
 
-- 
2.40.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 56/57] avcodec/mpegvideo: Use enum for msmpeg4_version

2024-04-29 Thread Andreas Rheinhardt
Improves readability.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h263dec.c | 34 ++--
 libavcodec/motion_est.c  |  8 +--
 libavcodec/mpegvideo.c   |  6 +--
 libavcodec/mpegvideo.h   | 10 +++-
 libavcodec/mpegvideo_enc.c   | 28 ++
 libavcodec/mpv_reconstruct_mb_template.c |  2 +-
 libavcodec/msmpeg4.c | 17 +++---
 libavcodec/msmpeg4dec.c  | 68 
 libavcodec/msmpeg4enc.c  | 37 ++---
 libavcodec/vc1dec.c  |  2 +-
 10 files changed, 114 insertions(+), 98 deletions(-)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index b9762be9c9..eee7978452 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -113,23 +113,23 @@ av_cold int ff_h263_decode_init(AVCodecContext *avctx)
 break;
 case AV_CODEC_ID_MSMPEG4V1:
 s->h263_pred   = 1;
-s->msmpeg4_version = 1;
+s->msmpeg4_version = MSMP4_V1;
 break;
 case AV_CODEC_ID_MSMPEG4V2:
 s->h263_pred   = 1;
-s->msmpeg4_version = 2;
+s->msmpeg4_version = MSMP4_V2;
 break;
 case AV_CODEC_ID_MSMPEG4V3:
 s->h263_pred   = 1;
-s->msmpeg4_version = 3;
+s->msmpeg4_version = MSMP4_V3;
 break;
 case AV_CODEC_ID_WMV1:
 s->h263_pred   = 1;
-s->msmpeg4_version = 4;
+s->msmpeg4_version = MSMP4_WMV1;
 break;
 case AV_CODEC_ID_WMV2:
 s->h263_pred   = 1;
-s->msmpeg4_version = 5;
+s->msmpeg4_version = MSMP4_WMV2;
 break;
 case AV_CODEC_ID_H263I:
 break;
@@ -227,7 +227,7 @@ static int decode_slice(MpegEncContext *s)
 
 for (; s->mb_y < s->mb_height; s->mb_y++) {
 /* per-row end of slice checks */
-if (s->msmpeg4_version) {
+if (s->msmpeg4_version != MSMP4_UNUSED) {
 if (s->resync_mb_y + s->slice_height == s->mb_y) {
 ff_er_add_slice(&s->er, s->resync_mb_x, s->resync_mb_y,
 s->mb_x - 1, s->mb_y, ER_MB_END);
@@ -236,7 +236,7 @@ static int decode_slice(MpegEncContext *s)
 }
 }
 
-if (s->msmpeg4_version == 1) {
+if (s->msmpeg4_version == MSMP4_V1) {
 s->last_dc[0] =
 s->last_dc[1] =
 s->last_dc[2] = 128;
@@ -375,12 +375,12 @@ static int decode_slice(MpegEncContext *s)
 }
 
 // handle formats which don't have unique end markers
-if (s->msmpeg4_version || (s->workaround_bugs & FF_BUG_NO_PADDING)) { // 
FIXME perhaps solve this more cleanly
+if (s->msmpeg4_version != MSMP4_UNUSED || (s->workaround_bugs & 
FF_BUG_NO_PADDING)) { // FIXME perhaps solve this more cleanly
 int left  = get_bits_left(&s->gb);
 int max_extra = 7;
 
 /* no markers in M$ crap */
-if (s->msmpeg4_version && s->pict_type == AV_PICTURE_TYPE_I)
+if (s->msmpeg4_version != MSMP4_UNUSED && s->pict_type == 
AV_PICTURE_TYPE_I)
 max_extra += 17;
 
 /* buggy padding but the frame should still end approximately at
@@ -474,10 +474,12 @@ retry:
 return ret;
 
 /* let's go :-) */
-if (CONFIG_WMV2_DECODER && s->msmpeg4_version == 5) {
+if (CONFIG_WMV2_DECODER && s->msmpeg4_version == MSMP4_WMV2) {
 ret = ff_wmv2_decode_picture_header(s);
-} else if (CONFIG_MSMPEG4DEC && s->msmpeg4_version) {
+#if CONFIG_MSMPEG4DEC
+} else if (s->msmpeg4_version != MSMP4_UNUSED) {
 ret = ff_msmpeg4_decode_picture_header(s);
+#endif
 } else if (CONFIG_MPEG4_DECODER && avctx->codec_id == AV_CODEC_ID_MPEG4) {
 ret = ff_mpeg4_decode_picture_header(avctx->priv_data, &s->gb, 0, 0);
 s->skipped_last_frame = (ret == FRAME_SKIPPED);
@@ -583,13 +585,15 @@ retry:
 /* the second part of the wmv2 header contains the MB skip bits which
  * are stored in current_picture->mb_type which is not available before
  * ff_mpv_frame_start() */
-if (CONFIG_WMV2_DECODER && s->msmpeg4_version == 5) {
+#if CONFIG_WMV2_DECODER
+if (s->msmpeg4_version == MSMP4_WMV2) {
 ret = ff_wmv2_decode_secondary_picture_header(s);
 if (ret < 0)
 return ret;
 if (ret == 1)
 goto frame_end;
 }
+#endif
 
 /* decode each macroblock */
 s->mb_x = 0;
@@ -597,7 +601,7 @@ retry:
 
 slice_ret = decode_slice(s);
 while (s->mb_y < s->mb_height) {
-if (s->msmpeg4_version) {
+if (s->msmpeg4_version != MSMP4_UNUSED) {
 if (s->slice_height == 0 || s->mb_x != 0 || slice_ret < 0 ||
 (s->mb_y % s->slice_height) != 0 || get_bits_left(&s->gb) < 0)
 break;
@@ -609,14 +613,14 @@ retry:
 s->er.error_occurred = 1;
 }
 
-if (s->msmpeg4_version < 4 && s->h263_pred)
+if (s->msmpeg4_version < MSMP4_WMV1 && s->h263

[FFmpeg-devel] [PATCH 55/57] avcodec/mpegvideo: Remove pblocks

2024-04-29 Thread Andreas Rheinhardt
It has been added in a579db0c4fe026d49c71d1ff64a2d1d07c152d68
due to XvMC, but today it is only used to swap U and V
for VCR2, a MPEG-2 variant with U and V swapped.
This can be done in a simpler fashion, namely by simply
swapping the U and V pointers of the corresponding
MPVWorkPictures.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12dec.c | 20 
 libavcodec/mpegvideo.c | 22 ++
 libavcodec/mpegvideo.h |  1 -
 3 files changed, 18 insertions(+), 25 deletions(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 55e3a31e95..139e825216 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -535,14 +535,14 @@ static int mpeg_decode_mb(MpegEncContext *s, int16_t 
block[12][64])
 
 if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO) {
 for (i = 0; i < mb_block_count; i++)
-if ((ret = mpeg2_decode_block_intra(s, *s->pblocks[i], i)) < 0)
+if ((ret = mpeg2_decode_block_intra(s, s->block[i], i)) < 0)
 return ret;
 } else {
 for (i = 0; i < 6; i++) {
 ret = ff_mpeg1_decode_block_intra(&s->gb,
   s->intra_matrix,
   
s->intra_scantable.permutated,
-  s->last_dc, *s->pblocks[i],
+  s->last_dc, s->block[i],
   i, s->qscale);
 if (ret < 0) {
 av_log(s->avctx, AV_LOG_ERROR, "ac-tex damaged at %d %d\n",
@@ -760,7 +760,7 @@ static int mpeg_decode_mb(MpegEncContext *s, int16_t 
block[12][64])
 
 for (i = 0; i < mb_block_count; i++) {
 if (cbp & (1 << 11)) {
-if ((ret = mpeg2_decode_block_non_intra(s, 
*s->pblocks[i], i)) < 0)
+if ((ret = mpeg2_decode_block_non_intra(s, 
s->block[i], i)) < 0)
 return ret;
 } else {
 s->block_last_index[i] = -1;
@@ -770,7 +770,7 @@ static int mpeg_decode_mb(MpegEncContext *s, int16_t 
block[12][64])
 } else {
 for (i = 0; i < 6; i++) {
 if (cbp & 32) {
-if ((ret = mpeg1_decode_block_inter(s, *s->pblocks[i], 
i)) < 0)
+if ((ret = mpeg1_decode_block_inter(s, s->block[i], 
i)) < 0)
 return ret;
 } else {
 s->block_last_index[i] = -1;
@@ -1279,6 +1279,7 @@ static int mpeg_field_start(Mpeg1Context *s1, const 
uint8_t *buf, int buf_size)
 {
 MpegEncContext *s = &s1->mpeg_enc_ctx;
 AVCodecContext *avctx = s->avctx;
+int second_field = 0;
 int ret;
 
 if (!(avctx->flags2 & AV_CODEC_FLAG2_CHUNKS)) {
@@ -1362,6 +1363,7 @@ static int mpeg_field_start(Mpeg1Context *s1, const 
uint8_t *buf, int buf_size)
 if (HAVE_THREADS && (avctx->active_thread_type & FF_THREAD_FRAME))
 ff_thread_finish_setup(avctx);
 } else { // second field
+second_field = 1;
 if (!s->cur_pic.ptr) {
 av_log(s->avctx, AV_LOG_ERROR, "first field missing\n");
 return AVERROR_INVALIDDATA;
@@ -1389,6 +1391,16 @@ static int mpeg_field_start(Mpeg1Context *s1, const 
uint8_t *buf, int buf_size)
 if (avctx->hwaccel) {
 if ((ret = FF_HW_CALL(avctx, start_frame, buf, buf_size)) < 0)
 return ret;
+} else if (s->codec_tag == MKTAG('V', 'C', 'R', '2')) {
+// Exchange UV
+FFSWAP(uint8_t*,  s->cur_pic.data[1], s->cur_pic.data[2]);
+FFSWAP(ptrdiff_t, s->cur_pic.linesize[1], s->cur_pic.linesize[2]);
+if (!second_field) {
+FFSWAP(uint8_t*,  s->next_pic.data[1], s->next_pic.data[2]);
+FFSWAP(ptrdiff_t, s->next_pic.linesize[1], 
s->next_pic.linesize[2]);
+FFSWAP(uint8_t*,  s->last_pic.data[1], s->last_pic.data[2]);
+FFSWAP(ptrdiff_t, s->last_pic.linesize[1], 
s->last_pic.linesize[2]);
+}
 }
 
 return 0;
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 17516f6fab..3cb8d06914 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -365,8 +365,6 @@ av_cold void ff_mpv_idct_init(MpegEncContext *s)
 
 static int init_duplicate_context(MpegEncContext *s)
 {
-int i;
-
 if (s->encoding) {
 s->me.map = av_mallocz(2 * ME_MAP_SIZE * sizeof(*s->me.map));
 if (!s->me.map)
@@ -382,15 +380,6 @@ static int init_duplicate_context(MpegEncContext *s)
 return AVERROR(ENOMEM);
 s->block = s->blocks[0];
 
-for (i = 0; i < 12; i++) {
-s->pblocks[i] = &s->block[i];
-}
-
-if (s->avctx->codec_tag == AV_RL32("VCR2")) {
-// exchange uv
-FFSWAP(void *, s->pblocks[4], s->pblocks[5]);
-}
-
 if (s->o

[FFmpeg-devel] [PATCH 54/57] avcodec/mpeg12dec: Don't initialize inter_scantable

2024-04-29 Thread Andreas Rheinhardt
MPEG-1/2 only needs one scantable and therefore all code
already uses the intra one. So stop initializing
the inter one altogether.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12dec.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 52f98986f6..55e3a31e95 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1256,13 +1256,10 @@ static int 
mpeg_decode_picture_coding_extension(Mpeg1Context *s1)
 s->chroma_420_type= get_bits1(&s->gb);
 s->progressive_frame  = get_bits1(&s->gb);
 
-if (s->alternate_scan) {
-ff_init_scantable(s->idsp.idct_permutation, &s->inter_scantable, 
ff_alternate_vertical_scan);
-ff_init_scantable(s->idsp.idct_permutation, &s->intra_scantable, 
ff_alternate_vertical_scan);
-} else {
-ff_init_scantable(s->idsp.idct_permutation, &s->inter_scantable, 
ff_zigzag_direct);
-ff_init_scantable(s->idsp.idct_permutation, &s->intra_scantable, 
ff_zigzag_direct);
-}
+// We only initialize intra_scantable, as both scantables always coincide
+// and all code therefore only uses the intra one.
+ff_init_scantable(s->idsp.idct_permutation, &s->intra_scantable,
+  s->alternate_scan ? ff_alternate_vertical_scan : 
ff_zigzag_direct);
 
 /* composite display not parsed */
 ff_dlog(s->avctx, "intra_dc_precision=%d\n", s->intra_dc_precision);
-- 
2.40.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 53/57] avcodec/mpeg12dec: Pass Mpeg1Context* in mpeg_field_start()

2024-04-29 Thread Andreas Rheinhardt
Avoids a cast.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12dec.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 0d5540fd2f..52f98986f6 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1278,10 +1278,10 @@ static int 
mpeg_decode_picture_coding_extension(Mpeg1Context *s1)
 return 0;
 }
 
-static int mpeg_field_start(MpegEncContext *s, const uint8_t *buf, int 
buf_size)
+static int mpeg_field_start(Mpeg1Context *s1, const uint8_t *buf, int buf_size)
 {
+MpegEncContext *s = &s1->mpeg_enc_ctx;
 AVCodecContext *avctx = s->avctx;
-Mpeg1Context *s1  = (Mpeg1Context *) s;
 int ret;
 
 if (!(avctx->flags2 & AV_CODEC_FLAG2_CHUNKS)) {
@@ -2460,7 +2460,7 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame 
*picture,
 if (s->first_slice) {
 skip_frame = 0;
 s->first_slice = 0;
-if ((ret = mpeg_field_start(s2, buf, buf_size)) < 0)
+if ((ret = mpeg_field_start(s, buf, buf_size)) < 0)
 return ret;
 }
 if (!s2->cur_pic.ptr) {
-- 
2.40.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 52/57] avcodec/mpegvideo_dec: Don't sync encoder-only coded_picture_number

2024-04-29 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo.c | 1 -
 libavcodec/mpegvideo_dec.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index b5c3de85f3..17516f6fab 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -520,7 +520,6 @@ void ff_mpv_common_defaults(MpegEncContext *s)
 s->progressive_sequence  = 1;
 s->picture_structure = PICT_FRAME;
 
-s->coded_picture_number  = 0;
 s->picture_number= 0;
 
 s->f_code= 1;
diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
index f840dc9ffc..0a50cfac5b 100644
--- a/libavcodec/mpegvideo_dec.c
+++ b/libavcodec/mpegvideo_dec.c
@@ -114,7 +114,6 @@ int ff_mpeg_update_thread_context(AVCodecContext *dst,
 
 s->quarter_sample   = s1->quarter_sample;
 
-s->coded_picture_number = s1->coded_picture_number;
 s->picture_number   = s1->picture_number;
 
 ff_mpv_replace_picture(&s->cur_pic,  &s1->cur_pic);
-- 
2.40.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 51/57] avcodec/mpegvideo_dec: Simplify check for "does pic exist?"

2024-04-29 Thread Andreas Rheinhardt
The days in which an MPVPicture* is set with the corresponding frame
being blank are over; this allows to simplify some checks.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo_dec.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
index 9d2b7671e3..f840dc9ffc 100644
--- a/libavcodec/mpegvideo_dec.c
+++ b/libavcodec/mpegvideo_dec.c
@@ -312,9 +312,10 @@ int ff_mpv_alloc_dummy_frames(MpegEncContext *s)
 AVCodecContext *avctx = s->avctx;
 int ret;
 
-if ((!s->last_pic.ptr || !s->last_pic.ptr->f->buf[0]) &&
-(s->pict_type != AV_PICTURE_TYPE_I)) {
-if (s->pict_type == AV_PICTURE_TYPE_B && s->next_pic.ptr && 
s->next_pic.ptr->f->buf[0])
+av_assert1(!s->last_pic.ptr || s->last_pic.ptr->f->buf[0]);
+av_assert1(!s->next_pic.ptr || s->next_pic.ptr->f->buf[0]);
+if (!s->last_pic.ptr && s->pict_type != AV_PICTURE_TYPE_I) {
+if (s->pict_type == AV_PICTURE_TYPE_B && s->next_pic.ptr)
 av_log(avctx, AV_LOG_DEBUG,
"allocating dummy last picture for B frame\n");
 else if (s->codec_id != AV_CODEC_ID_H261 /* H.261 has no keyframes */ 
&&
@@ -332,8 +333,7 @@ int ff_mpv_alloc_dummy_frames(MpegEncContext *s)
 color_frame(s->last_pic.ptr->f, luma_val);
 }
 }
-if ((!s->next_pic.ptr || !s->next_pic.ptr->f->buf[0]) &&
-s->pict_type == AV_PICTURE_TYPE_B) {
+if (!s->next_pic.ptr && s->pict_type == AV_PICTURE_TYPE_B) {
 /* Allocate a dummy frame */
 ret = alloc_dummy_frame(s, &s->next_pic);
 if (ret < 0)
-- 
2.40.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 50/57] avcodec/mpeg12enc: Simplify writing startcodes

2024-04-29 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12enc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index ea193e007a..5f9974ba21 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -271,11 +271,10 @@ static av_cold int encode_init(AVCodecContext *avctx)
 return 0;
 }
 
-static void put_header(MpegEncContext *s, int header)
+static void put_header(MpegEncContext *s, uint32_t header)
 {
 align_put_bits(&s->pb);
-put_bits(&s->pb, 16, header >> 16);
-put_sbits(&s->pb, 16, header);
+put_bits32(&s->pb, header);
 }
 
 /* put sequence header if needed */
-- 
2.40.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 49/57] avcodec/mpegvideo_enc: Unify initializing PutBitContexts

2024-04-29 Thread Andreas Rheinhardt
This also rids us of the requirement to preserve the PutBitContext
in ff_update_duplicate_context().

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo.c |  1 -
 libavcodec/mpegvideo_enc.c | 42 +-
 2 files changed, 19 insertions(+), 24 deletions(-)

diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index f4ad08f25b..b5c3de85f3 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -471,7 +471,6 @@ static void backup_duplicate_context(MpegEncContext *bak, 
MpegEncContext *src)
 COPY(start_mb_y);
 COPY(end_mb_y);
 COPY(me.map_generation);
-COPY(pb);
 COPY(dct_error_sum);
 COPY(dct_count[0]);
 COPY(dct_count[1]);
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 2bf4fc2cea..ddd68f2da8 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -84,7 +84,7 @@
 #define QMAT_SHIFT_MMX 16
 #define QMAT_SHIFT 21
 
-static int encode_picture(MpegEncContext *s);
+static int encode_picture(MpegEncContext *s, const AVPacket *pkt);
 static int dct_quantize_refine(MpegEncContext *s, int16_t *block, int16_t 
*weight, int16_t *orig, int n, int qscale);
 static int sse_mb(MpegEncContext *s);
 static void denoise_dct_c(MpegEncContext *s, int16_t *block);
@@ -1669,7 +1669,6 @@ static int select_input_picture(MpegEncContext *s)
 ff_mpv_unref_picture(&s->cur_pic);
 return ret;
 }
-s->me.temp = s->me.scratchpad = s->sc.b_scratchpad;
 s->picture_number = s->cur_pic.ptr->display_picture_number;
 
 }
@@ -1755,7 +1754,7 @@ int ff_mpv_encode_picture(AVCodecContext *avctx, AVPacket 
*pkt,
   const AVFrame *pic_arg, int *got_packet)
 {
 MpegEncContext *s = avctx->priv_data;
-int i, stuffing_count, ret;
+int stuffing_count, ret;
 int context_count = s->slice_context_count;
 
 ff_mpv_unref_picture(&s->cur_pic);
@@ -1791,21 +1790,11 @@ int ff_mpv_encode_picture(AVCodecContext *avctx, 
AVPacket *pkt,
 s->prev_mb_info = s->last_mb_info = s->mb_info_size = 0;
 }
 
-for (i = 0; i < context_count; i++) {
-int start_y = s->thread_context[i]->start_mb_y;
-int   end_y = s->thread_context[i]->  end_mb_y;
-int h   = s->mb_height;
-uint8_t *start = pkt->data + (size_t)(((int64_t) pkt->size) * 
start_y / h);
-uint8_t *end   = pkt->data + (size_t)(((int64_t) pkt->size) *   
end_y / h);
-
-init_put_bits(&s->thread_context[i]->pb, start, end - start);
-}
-
 s->pict_type = s->new_pic->pict_type;
 //emms_c();
 frame_start(s);
 vbv_retry:
-ret = encode_picture(s);
+ret = encode_picture(s, pkt);
 if (growing_buffer) {
 av_assert0(s->pb.buf == avctx->internal->byte_buffer);
 pkt->data = s->pb.buf;
@@ -1849,10 +1838,6 @@ vbv_retry:
 s->time_base   = s->last_time_base;
 s->last_non_b_time = s->time - s->pp_time;
 }
-for (i = 0; i < context_count; i++) {
-PutBitContext *pb = &s->thread_context[i]->pb;
-init_put_bits(pb, pb->buf, pb->buf_end - pb->buf);
-}
 s->vbv_ignore_qmax = 1;
 av_log(avctx, AV_LOG_VERBOSE, "reencoding frame due to VBV\n");
 goto vbv_retry;
@@ -3568,7 +3553,7 @@ static void set_frame_distances(MpegEncContext * s){
 }
 }
 
-static int encode_picture(MpegEncContext *s)
+static int encode_picture(MpegEncContext *s, const AVPacket *pkt)
 {
 int i, ret;
 int bits;
@@ -3617,12 +3602,23 @@ static int encode_picture(MpegEncContext *s)
 }
 
 s->mb_intra=0; //for the rate distortion & bit compare functions
-for(i=1; ithread_context[i];
-ret = ff_update_duplicate_context(slice_context, s);
-if (ret < 0)
-return ret;
+uint8_t *start, *end;
+int h;
+
+if (i) {
+ret = ff_update_duplicate_context(slice_context, s);
+if (ret < 0)
+return ret;
+}
 slice_context->me.temp = slice_context->me.scratchpad = 
slice_context->sc.b_scratchpad;
+
+h = s->mb_height;
+start = pkt->data + (size_t)(((int64_t) pkt->size) * 
slice_context->start_mb_y / h);
+end   = pkt->data + (size_t)(((int64_t) pkt->size) * slice_context->  
end_mb_y / h);
+
+init_put_bits(&s->thread_context[i]->pb, start, end - start);
 }
 
 if(ff_init_me(s)<0)
-- 
2.40.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 48/57] avcodec/mpegpicture: Avoid MotionEstContext in ff_mpeg_framesize_alloc()

2024-04-29 Thread Andreas Rheinhardt
Only set the ScratchpadContext and let the users that need it
(i.e. encoders) set the MotionEstContext stuff themselves.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegpicture.c   | 18 +++---
 libavcodec/mpegpicture.h   |  7 +++
 libavcodec/mpegvideo.c | 10 +++---
 libavcodec/mpegvideo_dec.c |  5 ++---
 libavcodec/mpegvideo_enc.c |  7 +--
 libavcodec/svq1enc.c   |  6 +++---
 6 files changed, 23 insertions(+), 30 deletions(-)

diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index cfb97a664d..fc4fec082d 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -25,7 +25,6 @@
 #include "libavutil/imgutils.h"
 
 #include "avcodec.h"
-#include "motion_est.h"
 #include "mpegpicture.h"
 #include "refstruct.h"
 
@@ -137,8 +136,8 @@ void ff_mpv_workpic_from_pic(MPVWorkPicture *wpic, 
MPVPicture *pic)
 set_workpic_from_pic(wpic, pic);
 }
 
-int ff_mpeg_framesize_alloc(AVCodecContext *avctx, MotionEstContext *me,
-ScratchpadContext *sc, int linesize)
+int ff_mpv_framesize_alloc(AVCodecContext *avctx,
+   ScratchpadContext *sc, int linesize)
 {
 #   define EMU_EDGE_HEIGHT (4 * 70)
 int linesizeabs = FFABS(linesize);
@@ -159,7 +158,7 @@ int ff_mpeg_framesize_alloc(AVCodecContext *avctx, 
MotionEstContext *me,
 return AVERROR(ENOMEM);
 
 av_freep(&sc->edge_emu_buffer);
-av_freep(&me->scratchpad);
+av_freep(&sc->b_scratchpad);
 
 // edge emu needs blocksize + filter length - 1
 // (= 17x17 for  halfpel / 21x21 for H.264)
@@ -168,16 +167,14 @@ int ff_mpeg_framesize_alloc(AVCodecContext *avctx, 
MotionEstContext *me,
 // linesize * interlaced * MBsize
 // we also use this buffer for encoding in encode_mb_internal() needig an 
additional 32 lines
 if (!FF_ALLOCZ_TYPED_ARRAY(sc->edge_emu_buffer, alloc_size * 
EMU_EDGE_HEIGHT) ||
-!FF_ALLOCZ_TYPED_ARRAY(me->scratchpad,  alloc_size * 4 * 16 * 2)) {
+!FF_ALLOCZ_TYPED_ARRAY(sc->b_scratchpad,alloc_size * 4 * 16 * 2)) {
 sc->linesize = 0;
 av_freep(&sc->edge_emu_buffer);
 return AVERROR(ENOMEM);
 }
 sc->linesize = linesizeabs;
 
-me->temp= me->scratchpad;
-sc->b_scratchpad= me->scratchpad;
-sc->obmc_scratchpad = me->scratchpad + 16;
+sc->obmc_scratchpad = sc->b_scratchpad + 16;
 
 return 0;
 }
@@ -238,14 +235,13 @@ static int alloc_picture_tables(BufferPoolContext *pools, 
MPVPicture *pic,
 }
 
 int ff_mpv_alloc_pic_accessories(AVCodecContext *avctx, MPVWorkPicture *wpic,
- MotionEstContext *me, ScratchpadContext *sc,
+ ScratchpadContext *sc,
  BufferPoolContext *pools, int mb_height)
 {
 MPVPicture *pic = wpic->ptr;
 int ret;
 
-ret = ff_mpeg_framesize_alloc(avctx, me, sc,
-  pic->f->linesize[0]);
+ret = ff_mpv_framesize_alloc(avctx, sc, pic->f->linesize[0]);
 if (ret < 0)
 goto fail;
 
diff --git a/libavcodec/mpegpicture.h b/libavcodec/mpegpicture.h
index 5f619a29bf..185238d09c 100644
--- a/libavcodec/mpegpicture.h
+++ b/libavcodec/mpegpicture.h
@@ -25,7 +25,6 @@
 #include 
 
 #include "avcodec.h"
-#include "motion_est.h"
 #include "threadprogress.h"
 
 #define MPV_MAX_PLANES 3
@@ -121,7 +120,7 @@ struct FFRefStructPool *ff_mpv_alloc_pic_pool(int 
init_progress);
  * and set the MPVWorkPicture's fields.
  */
 int ff_mpv_alloc_pic_accessories(AVCodecContext *avctx, MPVWorkPicture *pic,
- MotionEstContext *me, ScratchpadContext *sc,
+ ScratchpadContext *sc,
  BufferPoolContext *pools, int mb_height);
 
 /**
@@ -133,8 +132,8 @@ int ff_mpv_alloc_pic_accessories(AVCodecContext *avctx, 
MPVWorkPicture *pic,
 int ff_mpv_pic_check_linesize(void *logctx, const struct AVFrame *f,
   ptrdiff_t *linesizep, ptrdiff_t *uvlinesizep);
 
-int ff_mpeg_framesize_alloc(AVCodecContext *avctx, MotionEstContext *me,
-ScratchpadContext *sc, int linesize);
+int ff_mpv_framesize_alloc(AVCodecContext *avctx,
+   ScratchpadContext *sc, int linesize);
 
 void ff_mpv_unref_picture(MPVWorkPicture *pic);
 void ff_mpv_workpic_from_pic(MPVWorkPicture *wpic, MPVPicture *pic);
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 711bf6c17a..f4ad08f25b 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -438,9 +438,8 @@ static void free_duplicate_context(MpegEncContext *s)
 return;
 
 av_freep(&s->sc.edge_emu_buffer);
-av_freep(&s->me.scratchpad);
-s->me.temp =
-s->sc.b_scratchpad =
+av_freep(&s->sc.b_scratchpad);
+s->me.temp = s->me.scratchpad =
 s->sc.obmc_scratchpad = NULL;
 s->sc.linesize = 0;
 
@@ -465,8 +464,6 @@ static void backup_duplicate_context(MpegEn

[FFmpeg-devel] [PATCH 47/57] avcodec/mpegpicture: Use union for b_scratchpad and rd_scratchpad

2024-04-29 Thread Andreas Rheinhardt
These pointers point to the same buffers, so one can just
use a union for them and avoid synchronising one of them.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegpicture.c | 1 -
 libavcodec/mpegpicture.h | 6 --
 libavcodec/mpegvideo.c   | 1 -
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index 234bf45735..cfb97a664d 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -176,7 +176,6 @@ int ff_mpeg_framesize_alloc(AVCodecContext *avctx, 
MotionEstContext *me,
 sc->linesize = linesizeabs;
 
 me->temp= me->scratchpad;
-sc->rd_scratchpad   = me->scratchpad;
 sc->b_scratchpad= me->scratchpad;
 sc->obmc_scratchpad = me->scratchpad + 16;
 
diff --git a/libavcodec/mpegpicture.h b/libavcodec/mpegpicture.h
index b66fedc132..5f619a29bf 100644
--- a/libavcodec/mpegpicture.h
+++ b/libavcodec/mpegpicture.h
@@ -33,9 +33,11 @@
 
 typedef struct ScratchpadContext {
 uint8_t *edge_emu_buffer; ///< temporary buffer for if MVs point to 
out-of-frame data
-uint8_t *rd_scratchpad;   ///< scratchpad for rate distortion mb 
decision
 uint8_t *obmc_scratchpad;
-uint8_t *b_scratchpad;///< scratchpad used for writing into write 
only buffers
+union {
+uint8_t *b_scratchpad;///< scratchpad used for writing into write 
only buffers
+uint8_t *rd_scratchpad;   ///< scratchpad for rate distortion mb 
decision
+};
 int  linesize;///< linesize that the buffers in this 
context have been allocated for
 } ScratchpadContext;
 
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index dc7fee2ac7..711bf6c17a 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -440,7 +440,6 @@ static void free_duplicate_context(MpegEncContext *s)
 av_freep(&s->sc.edge_emu_buffer);
 av_freep(&s->me.scratchpad);
 s->me.temp =
-s->sc.rd_scratchpad =
 s->sc.b_scratchpad =
 s->sc.obmc_scratchpad = NULL;
 s->sc.linesize = 0;
-- 
2.40.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 46/57] avcodec/mpegpicture: Avoid loop and branch when setting motion_val

2024-04-29 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegpicture.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index d175bbc924..234bf45735 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -223,6 +223,7 @@ static int alloc_picture_tables(BufferPoolContext *pools, 
MPVPicture *pic,
 for (int i = 0; i < 2; i++) {
 GET_BUFFER(ref_index,, [i]);
 GET_BUFFER(motion_val, _base, [i]);
+pic->motion_val[i] = pic->motion_val_base[i] + 4;
 }
 }
 #undef GET_BUFFER
@@ -231,6 +232,9 @@ static int alloc_picture_tables(BufferPoolContext *pools, 
MPVPicture *pic,
 pic->mb_height = mb_height;
 pic->mb_stride = pools->alloc_mb_stride;
 
+pic->qscale_table = pic->qscale_table_base + 2 * pic->mb_stride + 1;
+pic->mb_type  = pic->mb_type_base  + 2 * pic->mb_stride + 1;
+
 return 0;
 }
 
@@ -250,13 +254,6 @@ int ff_mpv_alloc_pic_accessories(AVCodecContext *avctx, 
MPVWorkPicture *wpic,
 if (ret < 0)
 goto fail;
 
-pic->qscale_table = pic->qscale_table_base + 2 * pic->mb_stride + 1;
-pic->mb_type  = pic->mb_type_base  + 2 * pic->mb_stride + 1;
-
-if (pic->motion_val_base[0]) {
-for (int i = 0; i < 2; i++)
-pic->motion_val[i] = pic->motion_val_base[i] + 4;
-}
 set_workpic_from_pic(wpic, pic);
 
 return 0;
-- 
2.40.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 45/57] avcodec/mpegpicture: Use ThreadProgress instead of ThreadFrame API

2024-04-29 Thread Andreas Rheinhardt
Given that MPVPictures are already directly shared between threads
in case of frame-threaded decoding, one can simply use it to
pass decoding progress information between threads. This allows
to avoid one level of indirection; it also means avoids allocations
(of the ThreadFrameProgress structure) in case of frame-threading
and indeed makes ff_thread_release_ext_buffer() decoder-only
(actually, H.264-decoder-only).

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/error_resilience.c| 13 
 libavcodec/error_resilience.h|  1 +
 libavcodec/mpeg4videodec.c   |  8 
 libavcodec/mpeg_er.c |  2 +-
 libavcodec/mpegpicture.c | 19 --
 libavcodec/mpegpicture.h |  6 +++---
 libavcodec/mpegvideo_dec.c   | 25 +---
 libavcodec/mpegvideo_enc.c   |  2 +-
 libavcodec/mpv_reconstruct_mb_template.c |  8 
 libavcodec/pthread_frame.c   |  5 -
 libavcodec/rv34.c| 16 +++
 11 files changed, 58 insertions(+), 47 deletions(-)

diff --git a/libavcodec/error_resilience.c b/libavcodec/error_resilience.c
index 66d03987b6..56844d5084 100644
--- a/libavcodec/error_resilience.c
+++ b/libavcodec/error_resilience.c
@@ -34,6 +34,7 @@
 #include "mpegutils.h"
 #include "mpegvideo.h"
 #include "threadframe.h"
+#include "threadprogress.h"
 
 /**
  * @param stride the number of MVs to get to the next row
@@ -409,8 +410,12 @@ static void guess_mv(ERContext *s)
 set_mv_strides(s, &mot_step, &mot_stride);
 
 num_avail = 0;
-if (s->last_pic.motion_val[0])
-ff_thread_await_progress(s->last_pic.tf, mb_height-1, 0);
+if (s->last_pic.motion_val[0]) {
+if (s->last_pic.tf)
+ff_thread_await_progress(s->last_pic.tf, mb_height-1, 0);
+else
+ff_thread_progress_await(s->last_pic.progress, mb_height - 1);
+}
 for (i = 0; i < mb_width * mb_height; i++) {
 const int mb_xy = s->mb_index2xy[i];
 int f = 0;
@@ -763,7 +768,7 @@ static int is_intra_more_likely(ERContext *s)
 if (s->avctx->codec_id == AV_CODEC_ID_H264) {
 // FIXME
 } else {
-ff_thread_await_progress(s->last_pic.tf, mb_y, 0);
+ff_thread_progress_await(s->last_pic.progress, mb_y);
 }
 is_intra_likely += s->sad(NULL, last_mb_ptr, mb_ptr,
   linesize[0], 16);
@@ -1198,7 +1203,7 @@ void ff_er_frame_end(ERContext *s, int 
*decode_error_flags)
 int time_pb = s->pb_time;
 
 av_assert0(s->avctx->codec_id != AV_CODEC_ID_H264);
-ff_thread_await_progress(s->next_pic.tf, mb_y, 0);
+ff_thread_progress_await(s->next_pic.progress, mb_y);
 
 s->mv[0][0][0] = s->next_pic.motion_val[0][xy][0] *  
time_pb/ time_pp;
 s->mv[0][0][1] = s->next_pic.motion_val[0][xy][1] *  
time_pb/ time_pp;
diff --git a/libavcodec/error_resilience.h b/libavcodec/error_resilience.h
index 1346639c3c..a1b9b9ec1a 100644
--- a/libavcodec/error_resilience.h
+++ b/libavcodec/error_resilience.h
@@ -40,6 +40,7 @@
 typedef struct ERPicture {
 AVFrame *f;
 const struct ThreadFrame *tf;
+const struct ThreadProgress *progress;
 
 // it is the caller's responsibility to allocate these buffers
 int16_t (*motion_val[2])[2];
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index b07d016a8b..a1ae86bbe0 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -45,7 +45,7 @@
 #include "internal.h"
 #include "profiles.h"
 #include "qpeldsp.h"
-#include "threadframe.h"
+#include "threadprogress.h"
 #include "xvididct.h"
 #include "unary.h"
 
@@ -1807,7 +1807,7 @@ static int mpeg4_decode_mb(MpegEncContext *s, int16_t 
block[6][64])
 s->last_mv[i][1][1] = 0;
 }
 
-ff_thread_await_progress(&s->next_pic.ptr->tf, s->mb_y, 0);
+ff_thread_progress_await(&s->next_pic.ptr->progress, s->mb_y);
 }
 
 /* if we skipped it in the future P-frame than skip it now too */
@@ -2012,10 +2012,10 @@ end:
 
 if (s->pict_type == AV_PICTURE_TYPE_B) {
 const int delta = s->mb_x + 1 == s->mb_width ? 2 : 1;
-ff_thread_await_progress(&s->next_pic.ptr->tf,
+ff_thread_progress_await(&s->next_pic.ptr->progress,
 (s->mb_x + delta >= s->mb_width)
 ? FFMIN(s->mb_y + 1, s->mb_height - 1)
-: s->mb_y, 0);
+: s->mb_y);
 if (s->next_pic.mbskip_table[xy + delta])
 return SLICE_OK;
 }
diff --git a/libavcodec/mpeg_er.c b/libavcodec/mpeg

[FFmpeg-devel] [PATCH 44/57] avcodec/mpeg4videoenc: Simplify writing startcodes

2024-04-29 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg4videoenc.c | 21 +++--
 1 file changed, 7 insertions(+), 14 deletions(-)

diff --git a/libavcodec/mpeg4videoenc.c b/libavcodec/mpeg4videoenc.c
index 31307cc8dd..f89f29690a 100644
--- a/libavcodec/mpeg4videoenc.c
+++ b/libavcodec/mpeg4videoenc.c
@@ -886,8 +886,7 @@ static void mpeg4_encode_gop_header(MpegEncContext *s)
 int64_t hours, minutes, seconds;
 int64_t time;
 
-put_bits(&s->pb, 16, 0);
-put_bits(&s->pb, 16, GOP_STARTCODE);
+put_bits32(&s->pb, GOP_STARTCODE);
 
 time = s->cur_pic.ptr->f->pts;
 if (s->reordered_input_picture[1])
@@ -936,13 +935,11 @@ static void 
mpeg4_encode_visual_object_header(MpegEncContext *s)
 
 // FIXME levels
 
-put_bits(&s->pb, 16, 0);
-put_bits(&s->pb, 16, VOS_STARTCODE);
+put_bits32(&s->pb, VOS_STARTCODE);
 
 put_bits(&s->pb, 8, profile_and_level_indication);
 
-put_bits(&s->pb, 16, 0);
-put_bits(&s->pb, 16, VISUAL_OBJ_STARTCODE);
+put_bits32(&s->pb, VISUAL_OBJ_STARTCODE);
 
 put_bits(&s->pb, 1, 1);
 put_bits(&s->pb, 4, vo_ver_id);
@@ -969,10 +966,8 @@ static void mpeg4_encode_vol_header(MpegEncContext *s,
 vo_type = SIMPLE_VO_TYPE;
 }
 
-put_bits(&s->pb, 16, 0);
-put_bits(&s->pb, 16, 0x100 + vo_number);/* video obj */
-put_bits(&s->pb, 16, 0);
-put_bits(&s->pb, 16, 0x120 + vol_number);   /* video obj layer */
+put_bits32(&s->pb, 0x100 + vo_number);/* video obj */
+put_bits32(&s->pb, 0x120 + vol_number);   /* video obj layer */
 
 put_bits(&s->pb, 1, 0); /* random access vol */
 put_bits(&s->pb, 8, vo_type);   /* video obj type indication */
@@ -1049,8 +1044,7 @@ static void mpeg4_encode_vol_header(MpegEncContext *s,
 
 /* user data */
 if (!(s->avctx->flags & AV_CODEC_FLAG_BITEXACT)) {
-put_bits(&s->pb, 16, 0);
-put_bits(&s->pb, 16, 0x1B2);/* user_data */
+put_bits32(&s->pb, USER_DATA_STARTCODE);
 ff_put_string(&s->pb, LIBAVCODEC_IDENT, 0);
 }
 }
@@ -1074,8 +1068,7 @@ int ff_mpeg4_encode_picture_header(MpegEncContext *s)
 
 s->partitioned_frame = s->data_partitioning && s->pict_type != 
AV_PICTURE_TYPE_B;
 
-put_bits(&s->pb, 16, 0);/* vop header */
-put_bits(&s->pb, 16, VOP_STARTCODE);/* vop header */
+put_bits32(&s->pb, VOP_STARTCODE);  /* vop header */
 put_bits(&s->pb, 2, s->pict_type - 1);  /* pict type: I = 0 , P = 1 */
 
 time_div  = FFUDIV(s->time, s->avctx->time_base.den);
-- 
2.40.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 43/57] avcodec/mpeg4videoenc: Avoid branch for writing stuffing

2024-04-29 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg4videoenc.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/libavcodec/mpeg4videoenc.c b/libavcodec/mpeg4videoenc.c
index e853282b4b..31307cc8dd 100644
--- a/libavcodec/mpeg4videoenc.c
+++ b/libavcodec/mpeg4videoenc.c
@@ -865,11 +865,9 @@ void ff_mpeg4_encode_mb(MpegEncContext *s, int16_t 
block[6][64],
  */
 void ff_mpeg4_stuffing(PutBitContext *pbc)
 {
-int length;
-put_bits(pbc, 1, 0);
-length = (-put_bits_count(pbc)) & 7;
-if (length)
-put_bits(pbc, length, (1 << length) - 1);
+int length = 8 - (put_bits_count(pbc) & 7);
+
+put_bits(pbc, length, (1 << (length - 1)) - 1);
 }
 
 /* must be called before writing the header */
-- 
2.40.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 42/57] avcodec/mpegpicture: Make MPVPicture refcounted

2024-04-29 Thread Andreas Rheinhardt
Up until now, an initialized MpegEncContext had an array of
MPVPictures (way more than were ever needed) and the MPVPicture*
contained in the MPVWorkPictures as well as the input_picture
and reordered_input_picture arrays (for the encoder) pointed
into this array. Several of the pointers could point to the
same slot and because there was no reference counting involved,
one had to check for aliasing before unreferencing.
Furthermore, given that these pointers were not ownership pointers
the pointers were often simply reset without unreferencing
the slot (happened e.g. for the RV30 and RV40 decoders) or
there were moved without resetting the src pointer (happened
for the encoders where the entries in the input_picture
and reordered_input_picture arrays were not reset).
Instead actually releasing these pictures was performed by looping
over the whole array and checking which one of the entries needed
to be kept. Given that the array had way too many slots (36),
this meant that more than 30 MPVPictures have been unnecessarily
unreferenced in every ff_mpv_frame_start(); something similar
happened for the encoder.

This commit changes this by making the MPVPictures refcounted
via the RefStruct API. The MPVPictures itself are part of a pool
so that this does not entail constant allocations; instead,
the amount of allocations actually goes down, because the
earlier code used such a large array of MPVPictures (36 entries) and
allocated an AVFrame for every one of these on every
ff_mpv_common_init(). In fact, the pool is only freed when closing
the codec, so that reinitializations don't lead to new allocations
(this avoids having to sync the pool in update_thread_context).

Making MPVPictures refcounted also has another key benefit:
It makes it possible to directly share them across threads
(when using frame-threaded decoding), eliminating ugly code
with underlying av_frame_ref()'s; sharing these pictures
can't fail any more.

The pool is allocated in ff_mpv_decode_init() for decoders,
which therefore can fail now. This and the fact that the pool
is not unreferenced in ff_mpv_common_end() also necessitated
to mark several mpegvideo-decoders with the FF_CODEC_CAP_INIT_CLEANUP
flag.

*: This also means that there is no good reason any more for
ff_mpv_common_frame_size_change() to exist.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/flvdec.c|   3 +-
 libavcodec/h261dec.c   |   5 +-
 libavcodec/h263dec.c   |  14 ++--
 libavcodec/intelh263dec.c  |   3 +-
 libavcodec/mjpegenc.c  |   2 +-
 libavcodec/mpeg12dec.c |  11 ++-
 libavcodec/mpeg4videodec.c |   3 +-
 libavcodec/mpegpicture.c   | 160 -
 libavcodec/mpegpicture.h   |  14 ++--
 libavcodec/mpegvideo.c |  21 +
 libavcodec/mpegvideo.h |   2 +-
 libavcodec/mpegvideo_dec.c |  72 +
 libavcodec/mpegvideo_enc.c |  74 +
 libavcodec/mpegvideodec.h  |   4 +-
 libavcodec/msmpeg4dec.c|  12 ++-
 libavcodec/rv10.c  |   8 +-
 libavcodec/rv34.c  |   6 +-
 libavcodec/svq1enc.c   |   3 -
 libavcodec/vc1dec.c|   8 +-
 19 files changed, 176 insertions(+), 249 deletions(-)

diff --git a/libavcodec/flvdec.c b/libavcodec/flvdec.c
index 1bb1b12917..f4bfd99417 100644
--- a/libavcodec/flvdec.c
+++ b/libavcodec/flvdec.c
@@ -121,6 +121,7 @@ const FFCodec ff_flv_decoder = {
 FF_CODEC_DECODE_CB(ff_h263_decode_frame),
 .close  = ff_mpv_decode_close,
 .p.capabilities = AV_CODEC_CAP_DRAW_HORIZ_BAND | AV_CODEC_CAP_DR1,
-.caps_internal  = FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM,
+.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP |
+  FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM,
 .p.max_lowres   = 3,
 };
diff --git a/libavcodec/h261dec.c b/libavcodec/h261dec.c
index d8d0dcf3cf..392f1aef1d 100644
--- a/libavcodec/h261dec.c
+++ b/libavcodec/h261dec.c
@@ -84,10 +84,13 @@ static av_cold int h261_decode_init(AVCodecContext *avctx)
 static AVOnce init_static_once = AV_ONCE_INIT;
 H261DecContext *const h = avctx->priv_data;
 MpegEncContext *const s = &h->s;
+int ret;
 
 s->private_ctx = &h->common;
 // set defaults
-ff_mpv_decode_init(s, avctx);
+ret = ff_mpv_decode_init(s, avctx);
+if (ret < 0)
+return ret;
 
 s->out_format  = FMT_H261;
 s->low_delay   = 1;
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index b8db4ffc98..b9762be9c9 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -95,7 +95,9 @@ av_cold int ff_h263_decode_init(AVCodecContext *avctx)
 s->out_format  = FMT_H263;
 
 // set defaults
-ff_mpv_decode_init(s, avctx);
+ret = ff_mpv_decode_init(s, avctx);
+if (ret < 0)
+return ret;
 
 s->quant_precision = 5;
 s->decode_mb   = ff_h263_decode_mb;
@@ -427,7 +429,7 @@ int ff_h263_decode_frame(AVCodecContext *avctx, AVFrame 
*pict,
 if (s->low_delay == 0 && s->next_pic.ptr) {
 if ((ret = av_frame_ref

[FFmpeg-devel] [PATCH 41/57] avcodec/mpegvideo_dec: Add close function for mpegvideo-decoders

2024-04-29 Thread Andreas Rheinhardt
Currently identical to the H.261 and H.263 close functions
(which it replaces). It will be extended in future commits.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/flvdec.c|  4 ++--
 libavcodec/h261dec.c   | 11 +--
 libavcodec/h263dec.c   | 12 ++--
 libavcodec/h263dec.h   |  1 -
 libavcodec/intelh263dec.c  |  2 +-
 libavcodec/mpeg12dec.c |  3 +--
 libavcodec/mpeg4videodec.c |  2 +-
 libavcodec/mpegvideo_dec.c |  8 
 libavcodec/mpegvideodec.h  |  1 +
 libavcodec/msmpeg4dec.c|  9 +
 libavcodec/rv10.c  | 12 ++--
 libavcodec/rv30.c  |  1 +
 libavcodec/rv34.c  |  8 +++-
 libavcodec/rv40.c  |  1 +
 libavcodec/vc1dec.c| 18 --
 libavcodec/wmv2dec.c   |  3 ++-
 16 files changed, 43 insertions(+), 53 deletions(-)

diff --git a/libavcodec/flvdec.c b/libavcodec/flvdec.c
index 8baaed06a8..1bb1b12917 100644
--- a/libavcodec/flvdec.c
+++ b/libavcodec/flvdec.c
@@ -24,7 +24,7 @@
 #include "flvdec.h"
 #include "h263dec.h"
 #include "mpegvideo.h"
-#include "mpegvideodata.h"
+#include "mpegvideodec.h"
 
 int ff_flv_decode_picture_header(MpegEncContext *s)
 {
@@ -118,8 +118,8 @@ const FFCodec ff_flv_decoder = {
 .p.id   = AV_CODEC_ID_FLV1,
 .priv_data_size = sizeof(MpegEncContext),
 .init   = ff_h263_decode_init,
-.close  = ff_h263_decode_end,
 FF_CODEC_DECODE_CB(ff_h263_decode_frame),
+.close  = ff_mpv_decode_close,
 .p.capabilities = AV_CODEC_CAP_DRAW_HORIZ_BAND | AV_CODEC_CAP_DR1,
 .caps_internal  = FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM,
 .p.max_lowres   = 3,
diff --git a/libavcodec/h261dec.c b/libavcodec/h261dec.c
index 9acfd984ee..d8d0dcf3cf 100644
--- a/libavcodec/h261dec.c
+++ b/libavcodec/h261dec.c
@@ -660,15 +660,6 @@ static int h261_decode_frame(AVCodecContext *avctx, 
AVFrame *pict,
 return get_consumed_bytes(s, buf_size);
 }
 
-static av_cold int h261_decode_end(AVCodecContext *avctx)
-{
-H261DecContext *const h = avctx->priv_data;
-MpegEncContext *s = &h->s;
-
-ff_mpv_common_end(s);
-return 0;
-}
-
 const FFCodec ff_h261_decoder = {
 .p.name = "h261",
 CODEC_LONG_NAME("H.261"),
@@ -676,8 +667,8 @@ const FFCodec ff_h261_decoder = {
 .p.id   = AV_CODEC_ID_H261,
 .priv_data_size = sizeof(H261DecContext),
 .init   = h261_decode_init,
-.close  = h261_decode_end,
 FF_CODEC_DECODE_CB(h261_decode_frame),
+.close  = ff_mpv_decode_close,
 .p.capabilities = AV_CODEC_CAP_DR1,
 .p.max_lowres   = 3,
 };
diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 4fe4a3..b8db4ffc98 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -159,14 +159,6 @@ av_cold int ff_h263_decode_init(AVCodecContext *avctx)
 return 0;
 }
 
-av_cold int ff_h263_decode_end(AVCodecContext *avctx)
-{
-MpegEncContext *s = avctx->priv_data;
-
-ff_mpv_common_end(s);
-return 0;
-}
-
 /**
  * Return the number of bytes consumed for building the current frame.
  */
@@ -702,8 +694,8 @@ const FFCodec ff_h263_decoder = {
 .p.id   = AV_CODEC_ID_H263,
 .priv_data_size = sizeof(MpegEncContext),
 .init   = ff_h263_decode_init,
-.close  = ff_h263_decode_end,
 FF_CODEC_DECODE_CB(ff_h263_decode_frame),
+.close  = ff_mpv_decode_close,
 .p.capabilities = AV_CODEC_CAP_DRAW_HORIZ_BAND | AV_CODEC_CAP_DR1 |
   AV_CODEC_CAP_DELAY,
 .caps_internal  = FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM,
@@ -719,8 +711,8 @@ const FFCodec ff_h263p_decoder = {
 .p.id   = AV_CODEC_ID_H263P,
 .priv_data_size = sizeof(MpegEncContext),
 .init   = ff_h263_decode_init,
-.close  = ff_h263_decode_end,
 FF_CODEC_DECODE_CB(ff_h263_decode_frame),
+.close  = ff_mpv_decode_close,
 .p.capabilities = AV_CODEC_CAP_DRAW_HORIZ_BAND | AV_CODEC_CAP_DR1 |
   AV_CODEC_CAP_DELAY,
 .caps_internal  = FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM,
diff --git a/libavcodec/h263dec.h b/libavcodec/h263dec.h
index a01acc0834..633d4aa577 100644
--- a/libavcodec/h263dec.h
+++ b/libavcodec/h263dec.h
@@ -47,7 +47,6 @@ int ff_h263_decode_motion(MpegEncContext * s, int pred, int 
f_code);
 int ff_h263_decode_init(AVCodecContext *avctx);
 int ff_h263_decode_frame(AVCodecContext *avctx, AVFrame *frame,
  int *got_frame, AVPacket *avpkt);
-int ff_h263_decode_end(AVCodecContext *avctx);
 void ff_h263_decode_init_vlc(void);
 int ff_h263_decode_picture_header(MpegEncContext *s);
 int ff_h263_decode_gob_header(MpegEncContext *s);
diff --git a/libavcodec/intelh263dec.c b/libavcodec/intelh263dec.c
index 5d34892ef7..d4051c36f1 100644
--- a/libavcodec/intelh263dec.c
+++ b/libavcodec/intelh263dec.c
@@ -132,8 +132,8 @@ const FFCodec ff_h263i_decoder = {
 .p.id   = AV_CODEC_ID_H263I,
 .priv_data_size = sizeof(MpegEncCont

[FFmpeg-devel] [PATCH 40/57] avformat/riff: Declare VCR2 to be MPEG-2

2024-04-29 Thread Andreas Rheinhardt
This brings it in line with mpeg12dec.c.
(This entry has been added before the MPEG2VIDEO codec id
existed.)

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/riff.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/riff.c b/libavformat/riff.c
index 157976583c..bbdf7c9cc3 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -161,7 +161,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
 { AV_CODEC_ID_MPEG2VIDEO,   MKTAG('M', 'P', 'E', 'G') },
 { AV_CODEC_ID_MPEG1VIDEO,   MKTAG('P', 'I', 'M', '1') },
 { AV_CODEC_ID_MPEG2VIDEO,   MKTAG('P', 'I', 'M', '2') },
-{ AV_CODEC_ID_MPEG1VIDEO,   MKTAG('V', 'C', 'R', '2') },
+{ AV_CODEC_ID_MPEG2VIDEO,   MKTAG('V', 'C', 'R', '2') },
 { AV_CODEC_ID_MPEG1VIDEO,   MKTAG( 1 ,  0 ,  0 ,  16) },
 { AV_CODEC_ID_MPEG2VIDEO,   MKTAG( 2 ,  0 ,  0 ,  16) },
 { AV_CODEC_ID_MPEG4,MKTAG( 4 ,  0 ,  0 ,  16) },
-- 
2.40.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 39/57] avcodec/mpeg12dec: Set out_format only once

2024-04-29 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12dec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index e573d3cdff..0e2012b324 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -794,6 +794,8 @@ static av_cold int mpeg_decode_init(AVCodecContext *avctx)
 Mpeg1Context *s= avctx->priv_data;
 MpegEncContext *s2 = &s->mpeg_enc_ctx;
 
+s2->out_format = FMT_MPEG1;
+
 if (   avctx->codec_tag != AV_RL32("VCR2")
 && avctx->codec_tag != AV_RL32("BW10"))
 avctx->coded_width = avctx->coded_height = 0; // do not trust 
dimensions from input
@@ -1859,7 +1861,6 @@ static int mpeg1_decode_sequence(AVCodecContext *avctx,
 s->chroma_format= 1;
 s->codec_id =
 s->avctx->codec_id  = AV_CODEC_ID_MPEG1VIDEO;
-s->out_format   = FMT_MPEG1;
 if (s->avctx->flags & AV_CODEC_FLAG_LOW_DELAY)
 s->low_delay = 1;
 
@@ -1877,7 +1878,6 @@ static int vcr2_init_sequence(AVCodecContext *avctx)
 int i, v, ret;
 
 /* start new MPEG-1 context decoding */
-s->out_format = FMT_MPEG1;
 if (s->context_initialized)
 ff_mpv_common_end(s);
 
-- 
2.40.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 38/57] avcodec/mpeg12dec: Remove write-only assignment

2024-04-29 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12dec.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 3cd706de36..e573d3cdff 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2788,8 +2788,6 @@ static int ipu_decode_frame(AVCodecContext *avctx, 
AVFrame *frame,
   
m->intra_scantable.permutated,
   m->last_dc, s->block[n],
   n, m->qscale);
-if (ret >= 0)
-m->block_last_index[n] = ret;
 } else {
 ret = mpeg2_decode_block_intra(m, s->block[n], n);
 }
-- 
2.40.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 37/57] avcodec/mpeg12dec: Only initialize IDCT for IPU

2024-04-29 Thread Andreas Rheinhardt
This is all that is used. This is in preparation for further
commits that will extend ff_mpv_decode_init() in a way
that will make it possible to fail and require cleanup.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12dec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 097e4ba19a..3cd706de36 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2830,8 +2830,9 @@ static av_cold int ipu_decode_init(AVCodecContext *avctx)
 MpegEncContext *m = &s->m;
 
 avctx->pix_fmt = AV_PIX_FMT_YUV420P;
+m->avctx   = avctx;
 
-ff_mpv_decode_init(m, avctx);
+ff_idctdsp_init(&m->idsp, avctx);
 ff_mpeg12_init_vlcs();
 
 for (int i = 0; i < 64; i++) {
-- 
2.40.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 36/57] avcodec/mpeg12dec: Don't initialize inter tables for IPU

2024-04-29 Thread Andreas Rheinhardt
IPU is intra-only.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12dec.c | 16 ++--
 1 file changed, 2 insertions(+), 14 deletions(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index e3f2dd8af7..097e4ba19a 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2751,13 +2751,8 @@ static int ipu_decode_frame(AVCodecContext *avctx, 
AVFrame *frame,
 m->intra_vlc_format = !!(s->flags & 0x20);
 m->alternate_scan = !!(s->flags & 0x10);
 
-if (s->flags & 0x10) {
-ff_init_scantable(m->idsp.idct_permutation, &m->inter_scantable, 
ff_alternate_vertical_scan);
-ff_init_scantable(m->idsp.idct_permutation, &m->intra_scantable, 
ff_alternate_vertical_scan);
-} else {
-ff_init_scantable(m->idsp.idct_permutation, &m->inter_scantable, 
ff_zigzag_direct);
-ff_init_scantable(m->idsp.idct_permutation, &m->intra_scantable, 
ff_zigzag_direct);
-}
+ff_init_scantable(m->idsp.idct_permutation, &m->intra_scantable,
+  s->flags & 0x10 ? ff_alternate_vertical_scan : 
ff_zigzag_direct);
 
 m->last_dc[0] = m->last_dc[1] = m->last_dc[2] = 1 << (7 + (s->flags & 3));
 m->qscale = 1;
@@ -2846,13 +2841,6 @@ static av_cold int ipu_decode_init(AVCodecContext *avctx)
 m->chroma_intra_matrix[j] = v;
 }
 
-for (int i = 0; i < 64; i++) {
-int j = m->idsp.idct_permutation[i];
-int v = ff_mpeg1_default_non_intra_matrix[i];
-m->inter_matrix[j]= v;
-m->chroma_inter_matrix[j] = v;
-}
-
 return 0;
 }
 
-- 
2.40.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 35/57] avcodec/mpegvideo_enc: Reindentation

2024-04-29 Thread Andreas Rheinhardt
Also try to use loop-scope for iterators.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo_enc.c | 193 ++---
 1 file changed, 96 insertions(+), 97 deletions(-)

diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 5b0a2edfa6..ce827712af 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1480,129 +1480,128 @@ fail:
  */
 static int set_bframe_chain_length(MpegEncContext *s)
 {
-int i;
-
 /* Either nothing to do or can't do anything */
 if (s->reordered_input_picture[0] || !s->input_picture[0])
 return 0;
 
 /* set next picture type & ordering */
-if (s->frame_skip_threshold || s->frame_skip_factor) {
-if (s->picture_in_gop_number < s->gop_size &&
-s->next_pic.ptr &&
-skip_check(s, s->input_picture[0], s->next_pic.ptr)) {
-// FIXME check that the gop check above is +-1 correct
-ff_mpeg_unref_picture(s->input_picture[0]);
+if (s->frame_skip_threshold || s->frame_skip_factor) {
+if (s->picture_in_gop_number < s->gop_size &&
+s->next_pic.ptr &&
+skip_check(s, s->input_picture[0], s->next_pic.ptr)) {
+// FIXME check that the gop check above is +-1 correct
+ff_mpeg_unref_picture(s->input_picture[0]);
 
-ff_vbv_update(s, 0);
+ff_vbv_update(s, 0);
 
-return 0;
-}
+return 0;
 }
+}
 
-if (/*s->picture_in_gop_number >= s->gop_size ||*/
-!s->next_pic.ptr || s->intra_only) {
-s->reordered_input_picture[0] = s->input_picture[0];
-s->reordered_input_picture[0]->f->pict_type = AV_PICTURE_TYPE_I;
-s->reordered_input_picture[0]->coded_picture_number =
-s->coded_picture_number++;
-} else {
-int b_frames = 0;
-
-if (s->avctx->flags & AV_CODEC_FLAG_PASS2) {
-for (i = 0; i < s->max_b_frames + 1; i++) {
-int pict_num = s->input_picture[0]->display_picture_number 
+ i;
-
-if (pict_num >= s->rc_context.num_entries)
-break;
-if (!s->input_picture[i]) {
-s->rc_context.entry[pict_num - 1].new_pict_type = 
AV_PICTURE_TYPE_P;
-break;
-}
+if (/*s->picture_in_gop_number >= s->gop_size ||*/
+!s->next_pic.ptr || s->intra_only) {
+s->reordered_input_picture[0] = s->input_picture[0];
+s->reordered_input_picture[0]->f->pict_type = AV_PICTURE_TYPE_I;
+s->reordered_input_picture[0]->coded_picture_number =
+s->coded_picture_number++;
+} else {
+int b_frames = 0;
 
-s->input_picture[i]->f->pict_type =
-s->rc_context.entry[pict_num].new_pict_type;
-}
-}
+if (s->avctx->flags & AV_CODEC_FLAG_PASS2) {
+for (int i = 0; i < s->max_b_frames + 1; i++) {
+int pict_num = s->input_picture[0]->display_picture_number + i;
 
-if (s->b_frame_strategy == 0) {
-b_frames = s->max_b_frames;
-while (b_frames && !s->input_picture[b_frames])
-b_frames--;
-} else if (s->b_frame_strategy == 1) {
-for (i = 1; i < s->max_b_frames + 1; i++) {
-if (s->input_picture[i] &&
-s->input_picture[i]->b_frame_score == 0) {
-s->input_picture[i]->b_frame_score =
-get_intra_count(s,
-s->input_picture[i
]->f->data[0],
-s->input_picture[i - 
1]->f->data[0],
-s->linesize) + 1;
-}
-}
-for (i = 0; i < s->max_b_frames + 1; i++) {
-if (!s->input_picture[i] ||
-s->input_picture[i]->b_frame_score - 1 >
-s->mb_num / s->b_sensitivity)
-break;
+if (pict_num >= s->rc_context.num_entries)
+break;
+if (!s->input_picture[i]) {
+s->rc_context.entry[pict_num - 1].new_pict_type = 
AV_PICTURE_TYPE_P;
+break;
 }
 
-b_frames = FFMAX(0, i - 1);
+s->input_picture[i]->f->pict_type =
+s->rc_context.entry[pict_num].new_pict_type;
+}
+}
 
-/* reset scores */
-for (i = 0; i < b_frames + 1; i++) {
-s->input_picture[i]->b_frame_score = 0;
-}
-} else if (s->b_frame_strategy == 2) {
-b_frames = estimate_best_b_count(s);

[FFmpeg-devel] [PATCH 34/57] avcodec/mpegvideo_enc: Return early when getting length of B frame chain

2024-04-29 Thread Andreas Rheinhardt
Possible now that this is a function of its own.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo_enc.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index c0b7769ccd..5b0a2edfa6 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1482,8 +1482,11 @@ static int set_bframe_chain_length(MpegEncContext *s)
 {
 int i;
 
+/* Either nothing to do or can't do anything */
+if (s->reordered_input_picture[0] || !s->input_picture[0])
+return 0;
+
 /* set next picture type & ordering */
-if (!s->reordered_input_picture[0] && s->input_picture[0]) {
 if (s->frame_skip_threshold || s->frame_skip_factor) {
 if (s->picture_in_gop_number < s->gop_size &&
 s->next_pic.ptr &&
@@ -1599,7 +1602,6 @@ static int set_bframe_chain_length(MpegEncContext *s)
 s->coded_picture_number++;
 }
 }
-}
 
 return 0;
 }
-- 
2.40.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 33/57] avcodec/mpegvideo_enc: Factor setting length of B frame chain out

2024-04-29 Thread Andreas Rheinhardt
It already avoids a goto and will be useful in the future
to be able to specify each functions tasks and obligations.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo_enc.c | 33 +
 1 file changed, 25 insertions(+), 8 deletions(-)

diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 066dca9ac5..c0b7769ccd 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1472,13 +1472,15 @@ fail:
 return best_b_count;
 }
 
-static int select_input_picture(MpegEncContext *s)
+/**
+ * Determines whether an input picture is discarded or not
+ * and if not determines the length of the next chain of B frames
+ * and puts these pictures (including the P frame) into
+ * reordered_input_picture.
+ */
+static int set_bframe_chain_length(MpegEncContext *s)
 {
-int i, ret;
-
-for (int i = 1; i <= MAX_B_FRAMES; i++)
-s->reordered_input_picture[i - 1] = s->reordered_input_picture[i];
-s->reordered_input_picture[MAX_B_FRAMES] = NULL;
+int i;
 
 /* set next picture type & ordering */
 if (!s->reordered_input_picture[0] && s->input_picture[0]) {
@@ -1491,7 +1493,7 @@ static int select_input_picture(MpegEncContext *s)
 
 ff_vbv_update(s, 0);
 
-goto no_output_pic;
+return 0;
 }
 }
 
@@ -1598,7 +1600,22 @@ static int select_input_picture(MpegEncContext *s)
 }
 }
 }
-no_output_pic:
+
+return 0;
+}
+
+static int select_input_picture(MpegEncContext *s)
+{
+int ret;
+
+for (int i = 1; i <= MAX_B_FRAMES; i++)
+s->reordered_input_picture[i - 1] = s->reordered_input_picture[i];
+s->reordered_input_picture[MAX_B_FRAMES] = NULL;
+
+ret = set_bframe_chain_length(s);
+if (ret < 0)
+return ret;
+
 av_frame_unref(s->new_pic);
 
 if (s->reordered_input_picture[0]) {
-- 
2.40.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 32/57] avcodec/error_resilience: Deduplicate cleanup code

2024-04-29 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/error_resilience.c | 20 ++--
 1 file changed, 6 insertions(+), 14 deletions(-)

diff --git a/libavcodec/error_resilience.c b/libavcodec/error_resilience.c
index efbacb8760..66d03987b6 100644
--- a/libavcodec/error_resilience.c
+++ b/libavcodec/error_resilience.c
@@ -948,19 +948,10 @@ void ff_er_frame_end(ERContext *s, int 
*decode_error_flags)
 s->ref_index[i]   = av_calloc(s->mb_stride * s->mb_height, 4 * 
sizeof(uint8_t));
 s->motion_val_base[i] = av_calloc(size + 4, 2 * sizeof(uint16_t));
 if (!s->ref_index[i] || !s->motion_val_base[i])
-break;
+goto cleanup;
 s->cur_pic.ref_index[i]  = s->ref_index[i];
 s->cur_pic.motion_val[i] = s->motion_val_base[i] + 4;
 }
-if (i < 2) {
-for (i = 0; i < 2; i++) {
-av_freep(&s->ref_index[i]);
-av_freep(&s->motion_val_base[i]);
-s->cur_pic.ref_index[i]  = NULL;
-s->cur_pic.motion_val[i] = NULL;
-}
-return;
-}
 }
 
 if (s->avctx->debug & FF_DEBUG_ER) {
@@ -1344,14 +1335,15 @@ void ff_er_frame_end(ERContext *s, int 
*decode_error_flags)
 s->mbintra_table[mb_xy] = 1;
 }
 
+memset(&s->cur_pic, 0, sizeof(ERPicture));
+memset(&s->last_pic, 0, sizeof(ERPicture));
+memset(&s->next_pic, 0, sizeof(ERPicture));
+
+cleanup:
 for (i = 0; i < 2; i++) {
 av_freep(&s->ref_index[i]);
 av_freep(&s->motion_val_base[i]);
 s->cur_pic.ref_index[i]  = NULL;
 s->cur_pic.motion_val[i] = NULL;
 }
-
-memset(&s->cur_pic, 0, sizeof(ERPicture));
-memset(&s->last_pic, 0, sizeof(ERPicture));
-memset(&s->next_pic, 0, sizeof(ERPicture));
 }
-- 
2.40.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 31/57] avcodec/mpegpicture: Split MPVPicture into WorkPicture and ordinary Pic

2024-04-29 Thread Andreas Rheinhardt
There are two types of MPVPictures: Three (cur_pic, last_pic, next_pic)
that are directly part of MpegEncContext and an array of MPVPictures
that are separately allocated and are mostly accessed via pointers
(cur|last|next)_pic_ptr; they are also used to store AVFrames in the
encoder (necessary due to B-frames). As the name implies, each of the
former is directly associated with one of the _ptr pointers:
They actually share the same underlying buffers, but the ones
that are part of the context can have their data pointers offset
and their linesize doubled for field pictures.

Up until now, each of these had their own references; in particular,
there was an underlying av_frame_ref() to sync cur_pic and cur_pic_ptr
etc. This is wasteful.

This commit changes this relationship: cur_pic, last_pic and next_pic
now become MPVWorkPictures; this structure does not have an AVFrame
at all any more, but only the cached values of data and linesize.
It also contains a pointer to the corresponding MPVPicture, establishing
a more natural relationsship between the two.
This already means that creating the context-pictures from the pointers
can no longer fail.

What has not been changed is the fact that the MPVPicture* pointers
are not ownership pointers and that the MPVPictures are part of an
array of MPVPictures that is owned by a single AVCodecContext.
Doing so will be done in a latter commit.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/d3d12va_mpeg2.c   |  10 +-
 libavcodec/d3d12va_vc1.c |  10 +-
 libavcodec/dxva2_mpeg2.c |  16 +--
 libavcodec/dxva2_vc1.c   |  20 ++--
 libavcodec/h261dec.c |   7 +-
 libavcodec/h263dec.c |  33 +++---
 libavcodec/ituh263dec.c  |   4 +-
 libavcodec/mpeg12dec.c   |  56 -
 libavcodec/mpeg12enc.c   |  14 +--
 libavcodec/mpeg4videodec.c   |   4 +-
 libavcodec/mpeg4videoenc.c   |   4 +-
 libavcodec/mpeg_er.c |   6 +-
 libavcodec/mpegpicture.c |  58 ++---
 libavcodec/mpegpicture.h |  31 -
 libavcodec/mpegvideo.c   |  11 --
 libavcodec/mpegvideo.h   |   9 +-
 libavcodec/mpegvideo_dec.c   | 143 +--
 libavcodec/mpegvideo_enc.c   |  99 ++--
 libavcodec/mpegvideo_motion.c|   8 +-
 libavcodec/mpv_reconstruct_mb_template.c |   4 +-
 libavcodec/mss2.c|   2 +-
 libavcodec/nvdec_mpeg12.c|   6 +-
 libavcodec/nvdec_mpeg4.c |   6 +-
 libavcodec/nvdec_vc1.c   |   6 +-
 libavcodec/ratecontrol.c |  10 +-
 libavcodec/rv10.c|  28 ++---
 libavcodec/rv34.c|  38 +++---
 libavcodec/snowenc.c |  17 +--
 libavcodec/svq1enc.c |   5 +-
 libavcodec/vaapi_mpeg2.c |  12 +-
 libavcodec/vaapi_mpeg4.c |  14 +--
 libavcodec/vaapi_vc1.c   |  14 ++-
 libavcodec/vc1.c |   2 +-
 libavcodec/vc1_block.c   |  12 +-
 libavcodec/vc1_mc.c  |  32 ++---
 libavcodec/vc1_pred.c|   2 +-
 libavcodec/vc1dec.c  |  37 +++---
 libavcodec/vdpau.c   |   2 +-
 libavcodec/vdpau_mpeg12.c|   8 +-
 libavcodec/vdpau_mpeg4.c |   6 +-
 libavcodec/vdpau_vc1.c   |  12 +-
 libavcodec/videotoolbox.c|   2 +-
 libavcodec/wmv2dec.c |   2 +-
 43 files changed, 397 insertions(+), 425 deletions(-)

diff --git a/libavcodec/d3d12va_mpeg2.c b/libavcodec/d3d12va_mpeg2.c
index c2cf78104c..86a7d97b34 100644
--- a/libavcodec/d3d12va_mpeg2.c
+++ b/libavcodec/d3d12va_mpeg2.c
@@ -44,7 +44,7 @@ static int d3d12va_mpeg2_start_frame(AVCodecContext *avctx, 
av_unused const uint
 {
 const MpegEncContext  *s   = avctx->priv_data;
 D3D12VADecodeContext  *ctx = D3D12VA_DECODE_CONTEXT(avctx);
-D3D12DecodePictureContext *ctx_pic = 
s->cur_pic_ptr->hwaccel_picture_private;
+D3D12DecodePictureContext *ctx_pic = 
s->cur_pic.ptr->hwaccel_picture_private;
 
 if (!ctx)
 return -1;
@@ -69,7 +69,7 @@ static int d3d12va_mpeg2_start_frame(AVCodecContext *avctx, 
av_unused const uint
 static int d3d12va_mpeg2_decode_slice(AVCodecContext *avctx, const uint8_t 
*buffer, uint32_t size)
 {
 const MpegEncContext  *s   = avctx->priv_data;
-D3D12DecodePictureContext *ctx_pic = 
s->cur_pic_ptr->hwaccel_picture_private;
+D3D12DecodePictureContext *ctx_pic = 
s->cur_pic.ptr->hwaccel_picture_private;
 
 if (ctx_pic->slice_count >= MAX_SLICES) {
 return AVERROR(ERANGE);
@@ -88,7 +88,7 @@ static int d3d12va_mpeg2_decode_slice(AVCodecContext *avctx, 
const uint8_t *buff
 sta

[FFmpeg-devel] [PATCH 30/57] avcodec/mpegpicture: Rename Picture->MPVPicture

2024-04-29 Thread Andreas Rheinhardt
Picture is just too generic.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/dxva2_mpeg2.c  |  2 +-
 libavcodec/dxva2_vc1.c|  4 ++--
 libavcodec/intrax8.c  |  2 +-
 libavcodec/intrax8.h  |  2 +-
 libavcodec/ituh263dec.c   |  4 ++--
 libavcodec/mpeg4videoenc.c|  2 +-
 libavcodec/mpeg_er.c  |  2 +-
 libavcodec/mpegpicture.c  | 16 
 libavcodec/mpegpicture.h  | 18 +-
 libavcodec/mpegvideo.h| 18 +-
 libavcodec/mpegvideo_dec.c| 13 +++--
 libavcodec/mpegvideo_enc.c|  6 +++---
 libavcodec/mpegvideo_motion.c |  2 +-
 libavcodec/mpegvideodec.h |  5 +++--
 libavcodec/mss2.c |  2 +-
 libavcodec/ratecontrol.c  |  2 +-
 libavcodec/rv34.c |  2 +-
 libavcodec/vc1dec.c   |  2 +-
 libavcodec/vdpau.c|  2 +-
 libavcodec/vdpau_mpeg12.c |  4 ++--
 libavcodec/vdpau_mpeg4.c  |  2 +-
 libavcodec/vdpau_vc1.c|  4 ++--
 22 files changed, 59 insertions(+), 57 deletions(-)

diff --git a/libavcodec/dxva2_mpeg2.c b/libavcodec/dxva2_mpeg2.c
index fde615f530..d29a5bb538 100644
--- a/libavcodec/dxva2_mpeg2.c
+++ b/libavcodec/dxva2_mpeg2.c
@@ -45,7 +45,7 @@ void ff_dxva2_mpeg2_fill_picture_parameters(AVCodecContext 
*avctx,
 DXVA_PictureParameters *pp)
 {
 const struct MpegEncContext *s = avctx->priv_data;
-const Picture *current_picture = s->cur_pic_ptr;
+const MPVPicture *current_picture = s->cur_pic_ptr;
 int is_field = s->picture_structure != PICT_FRAME;
 
 memset(pp, 0, sizeof(*pp));
diff --git a/libavcodec/dxva2_vc1.c b/libavcodec/dxva2_vc1.c
index 7122f1cfea..f536da1008 100644
--- a/libavcodec/dxva2_vc1.c
+++ b/libavcodec/dxva2_vc1.c
@@ -46,7 +46,7 @@ void ff_dxva2_vc1_fill_picture_parameters(AVCodecContext 
*avctx,
 {
 const VC1Context *v = avctx->priv_data;
 const MpegEncContext *s = &v->s;
-const Picture *current_picture = s->cur_pic_ptr;
+const MPVPicture *current_picture = s->cur_pic_ptr;
 int intcomp = 0;
 
 // determine if intensity compensation is needed
@@ -336,7 +336,7 @@ static int dxva2_vc1_decode_slice(AVCodecContext *avctx,
   uint32_t size)
 {
 const VC1Context *v = avctx->priv_data;
-const Picture *current_picture = v->s.cur_pic_ptr;
+const MPVPicture *current_picture = v->s.cur_pic_ptr;
 struct dxva2_picture_context *ctx_pic = 
current_picture->hwaccel_picture_private;
 unsigned position;
 
diff --git a/libavcodec/intrax8.c b/libavcodec/intrax8.c
index 40085c69ce..f1dce86a50 100644
--- a/libavcodec/intrax8.c
+++ b/libavcodec/intrax8.c
@@ -730,7 +730,7 @@ av_cold void ff_intrax8_common_end(IntraX8Context *w)
 av_freep(&w->prediction_table);
 }
 
-int ff_intrax8_decode_picture(IntraX8Context *w, Picture *pict,
+int ff_intrax8_decode_picture(IntraX8Context *w, MPVPicture *pict,
   GetBitContext *gb, int *mb_x, int *mb_y,
   int dquant, int quant_offset,
   int loopfilter, int lowdelay)
diff --git a/libavcodec/intrax8.h b/libavcodec/intrax8.h
index 8e22361f1f..b9f8c4250b 100644
--- a/libavcodec/intrax8.h
+++ b/libavcodec/intrax8.h
@@ -106,7 +106,7 @@ void ff_intrax8_common_end(IntraX8Context *w);
  * @param quant_offset offset away from zero
  * @param loopfilter enable filter after decoding a block
  */
-int ff_intrax8_decode_picture(IntraX8Context *w, Picture *pict,
+int ff_intrax8_decode_picture(IntraX8Context *w, MPVPicture *pict,
   GetBitContext *gb, int *mb_x, int *mb_y,
   int quant, int halfpq,
   int loopfilter, int lowdelay);
diff --git a/libavcodec/ituh263dec.c b/libavcodec/ituh263dec.c
index 492cb5e0d4..2e4d74adc8 100644
--- a/libavcodec/ituh263dec.c
+++ b/libavcodec/ituh263dec.c
@@ -719,7 +719,7 @@ static int h263_get_modb(GetBitContext *gb, int pb_frame, 
int *cbpb)
 
 #define tab_size ((signed)FF_ARRAY_ELEMS(s->direct_scale_mv[0]))
 #define tab_bias (tab_size / 2)
-static inline void set_one_direct_mv(MpegEncContext *s, const Picture *p, int 
i)
+static inline void set_one_direct_mv(MpegEncContext *s, const MPVPicture *p, 
int i)
 {
 int xy   = s->block_index[i];
 uint16_t time_pp = s->pp_time;
@@ -750,7 +750,7 @@ static inline void set_one_direct_mv(MpegEncContext *s, 
const Picture *p, int i)
 static int set_direct_mv(MpegEncContext *s)
 {
 const int mb_index = s->mb_x + s->mb_y * s->mb_stride;
-const Picture *p = &s->next_pic;
+const MPVPicture *p = &s->next_pic;
 int colocated_mb_type = p->mb_type[mb_index];
 int i;
 
diff --git a/libavcodec/mpeg4videoenc.c b/libavcodec/mpeg4videoenc.c
index 596155c8a1..6c743b8641 100644
--- a/libavcodec/mpeg4videoenc.c
+++ b/libavcodec/mpeg4videoenc.c
@@ -654,7 +654,7 @@ void ff_mpeg4_encode_mb(MpegEncContext *s, int16_t 
block[6][64],
  

[FFmpeg-devel] [PATCH 29/57] avcodec/mpegvideo_enc: Move copying properties to alloc_picture()

2024-04-29 Thread Andreas Rheinhardt
This way said function sets everything (except for the actual
contents of the frame's data). Also rename it to prepare_picture()
given its new role.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo_enc.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 426a4a4ff2..b310baf3ed 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1091,7 +1091,11 @@ static int get_intra_count(MpegEncContext *s, const 
uint8_t *src,
 return acc;
 }
 
-static int alloc_picture(MpegEncContext *s, AVFrame *f)
+/**
+ * Allocates new buffers for an AVFrame and copies the properties
+ * from another AVFrame.
+ */
+static int prepare_picture(MpegEncContext *s, AVFrame *f, const AVFrame 
*props_frame)
 {
 AVCodecContext *avctx = s->avctx;
 int ret;
@@ -1107,6 +,10 @@ static int alloc_picture(MpegEncContext *s, AVFrame *f)
 if (ret < 0)
 return ret;
 
+ret = av_frame_copy_props(f, props_frame);
+if (ret < 0)
+return ret;
+
 for (int i = 0; f->data[i]; i++) {
 int offset = (EDGE_WIDTH >> (i ? s->chroma_y_shift : 0)) *
  f->linesize[i] +
@@ -1186,14 +1194,9 @@ static int load_input_picture(MpegEncContext *s, const 
AVFrame *pic_arg)
 return ret;
 pic->shared = 1;
 } else {
-ret = alloc_picture(s, pic->f);
+ret = prepare_picture(s, pic->f, pic_arg);
 if (ret < 0)
 goto fail;
-ret = av_frame_copy_props(pic->f, pic_arg);
-if (ret < 0) {
-ff_mpeg_unref_picture(pic);
-return ret;
-}
 
 for (int i = 0; i < 3; i++) {
 ptrdiff_t src_stride = pic_arg->linesize[i];
@@ -1607,11 +1610,8 @@ no_output_pic:
 // input is a shared pix, so we can't modify it -> allocate a new
 // one & ensure that the shared one is reuseable
 av_frame_move_ref(s->new_pic, s->reordered_input_picture[0]->f);
-ret = alloc_picture(s, s->reordered_input_picture[0]->f);
-if (ret < 0)
-goto fail;
 
-ret = av_frame_copy_props(s->reordered_input_picture[0]->f, 
s->new_pic);
+ret = prepare_picture(s, s->reordered_input_picture[0]->f, 
s->new_pic);
 if (ret < 0)
 goto fail;
 } else {
-- 
2.40.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 28/57] avcodec/mpegvideo_enc: Pass AVFrame*, not Picture* to alloc_picture()

2024-04-29 Thread Andreas Rheinhardt
It now only deals with the AVFrame and no longer with the accessories.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo_enc.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 8e1ea36022..426a4a4ff2 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1091,30 +1091,30 @@ static int get_intra_count(MpegEncContext *s, const 
uint8_t *src,
 return acc;
 }
 
-static int alloc_picture(MpegEncContext *s, Picture *pic)
+static int alloc_picture(MpegEncContext *s, AVFrame *f)
 {
 AVCodecContext *avctx = s->avctx;
 int ret;
 
-pic->f->width  = avctx->width  + 2 * EDGE_WIDTH;
-pic->f->height = avctx->height + 2 * EDGE_WIDTH;
+f->width  = avctx->width  + 2 * EDGE_WIDTH;
+f->height = avctx->height + 2 * EDGE_WIDTH;
 
-ret = ff_encode_alloc_frame(avctx, pic->f);
+ret = ff_encode_alloc_frame(avctx, f);
 if (ret < 0)
 return ret;
 
-ret = ff_mpv_pic_check_linesize(avctx, pic->f, &s->linesize, 
&s->uvlinesize);
+ret = ff_mpv_pic_check_linesize(avctx, f, &s->linesize, &s->uvlinesize);
 if (ret < 0)
 return ret;
 
-for (int i = 0; pic->f->data[i]; i++) {
+for (int i = 0; f->data[i]; i++) {
 int offset = (EDGE_WIDTH >> (i ? s->chroma_y_shift : 0)) *
- pic->f->linesize[i] +
+ f->linesize[i] +
  (EDGE_WIDTH >> (i ? s->chroma_x_shift : 0));
-pic->f->data[i] += offset;
+f->data[i] += offset;
 }
-pic->f->width  = avctx->width;
-pic->f->height = avctx->height;
+f->width  = avctx->width;
+f->height = avctx->height;
 
 return 0;
 }
@@ -1186,7 +1186,7 @@ static int load_input_picture(MpegEncContext *s, const 
AVFrame *pic_arg)
 return ret;
 pic->shared = 1;
 } else {
-ret = alloc_picture(s, pic);
+ret = alloc_picture(s, pic->f);
 if (ret < 0)
 goto fail;
 ret = av_frame_copy_props(pic->f, pic_arg);
@@ -1607,7 +1607,7 @@ no_output_pic:
 // input is a shared pix, so we can't modify it -> allocate a new
 // one & ensure that the shared one is reuseable
 av_frame_move_ref(s->new_pic, s->reordered_input_picture[0]->f);
-ret = alloc_picture(s, s->reordered_input_picture[0]);
+ret = alloc_picture(s, s->reordered_input_picture[0]->f);
 if (ret < 0)
 goto fail;
 
-- 
2.40.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 27/57] avcodec/mpegpicture: Split ff_alloc_picture() into check and alloc part

2024-04-29 Thread Andreas Rheinhardt
ff_alloc_picture() currently does two things: It checks the
consistency of the linesize (which should not be necessary, but is)
and it allocates certain buffers. (It does not actually allocate
the picture buffers, so its name is misleading.)
This commit splits it into two separate functions. The rationale
for this is that for the encoders, every picture needs its linesizes
checked, but not every picture needs these extra buffers.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegpicture.c   | 70 ++
 libavcodec/mpegpicture.h   | 15 ++--
 libavcodec/mpegvideo_dec.c |  8 +++--
 libavcodec/mpegvideo_enc.c | 57 ++-
 4 files changed, 69 insertions(+), 81 deletions(-)

diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index d0b529dc37..8a058c4a77 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -91,40 +91,27 @@ int ff_mpeg_framesize_alloc(AVCodecContext *avctx, 
MotionEstContext *me,
 return 0;
 }
 
-/**
- * Check the pic's linesize and allocate linesize dependent scratch buffers
- */
-static int handle_pic_linesizes(AVCodecContext *avctx, Picture *pic,
-MotionEstContext *me, ScratchpadContext *sc,
-int linesize, int uvlinesize)
+int ff_mpv_pic_check_linesize(void *logctx, const AVFrame *f,
+  ptrdiff_t *linesizep, ptrdiff_t *uvlinesizep)
 {
-int ret;
-
-if ((linesize   &&   linesize != pic->f->linesize[0]) ||
-(uvlinesize && uvlinesize != pic->f->linesize[1])) {
-av_log(avctx, AV_LOG_ERROR, "Stride change unsupported: "
-   "linesize=%d/%d uvlinesize=%d/%d)\n",
-   linesize,   pic->f->linesize[0],
-   uvlinesize, pic->f->linesize[1]);
-ff_mpeg_unref_picture(pic);
+ptrdiff_t linesize = *linesizep, uvlinesize = *uvlinesizep;
+
+if ((linesize   &&   linesize != f->linesize[0]) ||
+(uvlinesize && uvlinesize != f->linesize[1])) {
+av_log(logctx, AV_LOG_ERROR, "Stride change unsupported: "
+   "linesize=%"PTRDIFF_SPECIFIER"/%d 
uvlinesize=%"PTRDIFF_SPECIFIER"/%d)\n",
+   linesize,   f->linesize[0],
+   uvlinesize, f->linesize[1]);
 return AVERROR_PATCHWELCOME;
 }
 
-if (av_pix_fmt_count_planes(pic->f->format) > 2 &&
-pic->f->linesize[1] != pic->f->linesize[2]) {
-av_log(avctx, AV_LOG_ERROR, "uv stride mismatch unsupported\n");
-ff_mpeg_unref_picture(pic);
+if (av_pix_fmt_count_planes(f->format) > 2 &&
+f->linesize[1] != f->linesize[2]) {
+av_log(logctx, AV_LOG_ERROR, "uv stride mismatch unsupported\n");
 return AVERROR_PATCHWELCOME;
 }
-
-ret = ff_mpeg_framesize_alloc(avctx, me, sc,
-  pic->f->linesize[0]);
-if (ret < 0) {
-av_log(avctx, AV_LOG_ERROR,
-   "get_buffer() failed to allocate context scratch buffers.\n");
-ff_mpeg_unref_picture(pic);
-return ret;
-}
+*linesizep   = f->linesize[0];
+*uvlinesizep = f->linesize[1];
 
 return 0;
 }
@@ -155,28 +142,22 @@ static int alloc_picture_tables(BufferPoolContext *pools, 
Picture *pic,
 return 0;
 }
 
-/**
- * Allocate a Picture.
- * The pixels are allocated/set by calling get_buffer() if shared = 0
- */
-int ff_alloc_picture(AVCodecContext *avctx, Picture *pic, MotionEstContext *me,
- ScratchpadContext *sc, BufferPoolContext *pools,
- int mb_height, ptrdiff_t *linesize, ptrdiff_t *uvlinesize)
+int ff_mpv_alloc_pic_accessories(AVCodecContext *avctx, Picture *pic,
+ MotionEstContext *me, ScratchpadContext *sc,
+ BufferPoolContext *pools, int mb_height)
 {
 int ret;
 
-if (handle_pic_linesizes(avctx, pic, me, sc,
- *linesize, *uvlinesize) < 0)
-return -1;
-
-*linesize   = pic->f->linesize[0];
-*uvlinesize = pic->f->linesize[1];
-
 for (int i = 0; i < MPV_MAX_PLANES; i++) {
 pic->data[i] = pic->f->data[i];
 pic->linesize[i] = pic->f->linesize[i];
 }
 
+ret = ff_mpeg_framesize_alloc(avctx, me, sc,
+  pic->f->linesize[0]);
+if (ret < 0)
+goto fail;
+
 ret = alloc_picture_tables(pools, pic, mb_height);
 if (ret < 0)
 goto fail;
@@ -191,9 +172,8 @@ int ff_alloc_picture(AVCodecContext *avctx, Picture *pic, 
MotionEstContext *me,
 
 return 0;
 fail:
-av_log(avctx, AV_LOG_ERROR, "Error allocating a picture.\n");
-ff_mpeg_unref_picture(pic);
-return AVERROR(ENOMEM);
+av_log(avctx, AV_LOG_ERROR, "Error allocating picture accessories.\n");
+return ret;
 }
 
 /**
diff --git a/libavcodec/mpegpicture.h b/libavcodec/mpegpicture.h
index 814f71213e..6589b38262 100644
--- a/libavcodec/mpegpicture.h
+++ b/libavcodec/mpegpicture.h

[FFmpeg-devel] [PATCH 26/57] avcodec/mpegpicture: Improve error messages and code

2024-04-29 Thread Andreas Rheinhardt
Make it clear that this is not a failure of get_buffer/the user,
but a deficit of mpegvideo.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegpicture.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index bca0e6de01..d0b529dc37 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -102,20 +102,19 @@ static int handle_pic_linesizes(AVCodecContext *avctx, 
Picture *pic,
 
 if ((linesize   &&   linesize != pic->f->linesize[0]) ||
 (uvlinesize && uvlinesize != pic->f->linesize[1])) {
-av_log(avctx, AV_LOG_ERROR,
-   "get_buffer() failed (stride changed: linesize=%d/%d 
uvlinesize=%d/%d)\n",
+av_log(avctx, AV_LOG_ERROR, "Stride change unsupported: "
+   "linesize=%d/%d uvlinesize=%d/%d)\n",
linesize,   pic->f->linesize[0],
uvlinesize, pic->f->linesize[1]);
 ff_mpeg_unref_picture(pic);
-return -1;
+return AVERROR_PATCHWELCOME;
 }
 
 if (av_pix_fmt_count_planes(pic->f->format) > 2 &&
 pic->f->linesize[1] != pic->f->linesize[2]) {
-av_log(avctx, AV_LOG_ERROR,
-   "get_buffer() failed (uv stride mismatch)\n");
+av_log(avctx, AV_LOG_ERROR, "uv stride mismatch unsupported\n");
 ff_mpeg_unref_picture(pic);
-return -1;
+return AVERROR_PATCHWELCOME;
 }
 
 ret = ff_mpeg_framesize_alloc(avctx, me, sc,
-- 
2.40.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 25/57] avcodec/vc1_pred: Remove unused function parameter

2024-04-29 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/vc1_pred.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavcodec/vc1_pred.c b/libavcodec/vc1_pred.c
index f5e80fe0ef..9141290d26 100644
--- a/libavcodec/vc1_pred.c
+++ b/libavcodec/vc1_pred.c
@@ -66,7 +66,7 @@ static av_always_inline int scaleforsame_x(const VC1Context 
*v, int n /* MV */,
 return av_clip(scaledvalue, -v->range_x, v->range_x - 1);
 }
 
-static av_always_inline int scaleforsame_y(const VC1Context *v, int i, int n 
/* MV */, int dir)
+static av_always_inline int scaleforsame_y(const VC1Context *v, int n /* MV 
*/, int dir)
 {
 int scaledvalue, refdist;
 int scalesame1, scalesame2;
@@ -161,7 +161,7 @@ static av_always_inline int scaleforopp_y(const VC1Context 
*v, int n /* MV */, i
 }
 }
 
-static av_always_inline int scaleforsame(const VC1Context *v, int i, int n /* 
MV */,
+static av_always_inline int scaleforsame(const VC1Context *v, int n /* MV */,
  int dim, int dir)
 {
 int brfd, scalesame;
@@ -170,7 +170,7 @@ static av_always_inline int scaleforsame(const VC1Context 
*v, int i, int n /* MV
 n >>= hpel;
 if (v->s.pict_type != AV_PICTURE_TYPE_B || v->second_field || !dir) {
 if (dim)
-n = scaleforsame_y(v, i, n, dir) * (1 << hpel);
+n = scaleforsame_y(v, n, dir) * (1 << hpel);
 else
 n = scaleforsame_x(v, n, dir) * (1 << hpel);
 return n;
@@ -365,16 +365,16 @@ void ff_vc1_pred_mv(VC1Context *v, int n, int dmv_x, int 
dmv_y,
 v->mv_f[dir][xy + v->blocks_off] = 0;
 v->ref_field_type[dir] = v->cur_field_type;
 if (a_valid && a_f) {
-field_predA[0] = scaleforsame(v, n, field_predA[0], 0, dir);
-field_predA[1] = scaleforsame(v, n, field_predA[1], 1, dir);
+field_predA[0] = scaleforsame(v, field_predA[0], 0, dir);
+field_predA[1] = scaleforsame(v, field_predA[1], 1, dir);
 }
 if (b_valid && b_f) {
-field_predB[0] = scaleforsame(v, n, field_predB[0], 0, dir);
-field_predB[1] = scaleforsame(v, n, field_predB[1], 1, dir);
+field_predB[0] = scaleforsame(v, field_predB[0], 0, dir);
+field_predB[1] = scaleforsame(v, field_predB[1], 1, dir);
 }
 if (c_valid && c_f) {
-field_predC[0] = scaleforsame(v, n, field_predC[0], 0, dir);
-field_predC[1] = scaleforsame(v, n, field_predC[1], 1, dir);
+field_predC[0] = scaleforsame(v, field_predC[0], 0, dir);
+field_predC[1] = scaleforsame(v, field_predC[1], 1, dir);
 }
 }
 
-- 
2.40.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 24/57] avcodec/mpegvideo: Add const where appropriate

2024-04-29 Thread Andreas Rheinhardt
Specifically, add const to the pointed-to-type of pointers
that point to something static or that belong to last_pic
or next_pic (because modifying these might lead to data races).

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h261dec.c|  2 +-
 libavcodec/h261enc.c|  2 +-
 libavcodec/ituh263dec.c |  6 +++---
 libavcodec/ituh263enc.c |  2 +-
 libavcodec/mpeg12dec.c  |  6 +++---
 libavcodec/mpeg12enc.c  |  8 
 libavcodec/mpeg4videodec.c  |  9 -
 libavcodec/mpeg4videoenc.c  | 32 ---
 libavcodec/mpeg_er.c|  2 +-
 libavcodec/mpegvideo_enc.c  |  6 +++---
 libavcodec/mpegvideoenc.h   |  2 +-
 libavcodec/msmpeg4dec.c |  6 +++---
 libavcodec/ratecontrol.c| 22 ++---
 libavcodec/rv34.c   |  3 ++-
 libavcodec/vc1_loopfilter.c | 20 +--
 libavcodec/vc1_mc.c |  4 ++--
 libavcodec/vc1_pred.c   | 38 ++---
 libavcodec/vc1dec.c |  6 +++---
 18 files changed, 88 insertions(+), 88 deletions(-)

diff --git a/libavcodec/h261dec.c b/libavcodec/h261dec.c
index 77aa08687d..00edd7a7c2 100644
--- a/libavcodec/h261dec.c
+++ b/libavcodec/h261dec.c
@@ -281,7 +281,7 @@ static int h261_decode_block(H261DecContext *h, int16_t 
*block, int n, int coded
 {
 MpegEncContext *const s = &h->s;
 int level, i, j, run;
-RLTable *rl = &ff_h261_rl_tcoeff;
+const RLTable *rl = &ff_h261_rl_tcoeff;
 const uint8_t *scan_table;
 
 /* For the variable length encoding there are two code tables, one being
diff --git a/libavcodec/h261enc.c b/libavcodec/h261enc.c
index 438ebb63d9..58ac23ebe7 100644
--- a/libavcodec/h261enc.c
+++ b/libavcodec/h261enc.c
@@ -167,7 +167,7 @@ static void h261_encode_block(H261EncContext *h, int16_t 
*block, int n)
 {
 MpegEncContext *const s = &h->s;
 int level, run, i, j, last_index, last_non_zero, sign, slevel, code;
-RLTable *rl;
+const RLTable *rl;
 
 rl = &ff_h261_rl_tcoeff;
 if (s->mb_intra) {
diff --git a/libavcodec/ituh263dec.c b/libavcodec/ituh263dec.c
index 9358363ed8..492cb5e0d4 100644
--- a/libavcodec/ituh263dec.c
+++ b/libavcodec/ituh263dec.c
@@ -534,7 +534,7 @@ static int h263_decode_block(MpegEncContext * s, int16_t * 
block,
  int n, int coded)
 {
 int level, i, j, run;
-RLTable *rl = &ff_h263_rl_inter;
+const RLTable *rl = &ff_h263_rl_inter;
 const uint8_t *scan_table;
 GetBitContext gb= s->gb;
 
@@ -719,7 +719,7 @@ static int h263_get_modb(GetBitContext *gb, int pb_frame, 
int *cbpb)
 
 #define tab_size ((signed)FF_ARRAY_ELEMS(s->direct_scale_mv[0]))
 #define tab_bias (tab_size / 2)
-static inline void set_one_direct_mv(MpegEncContext *s, Picture *p, int i)
+static inline void set_one_direct_mv(MpegEncContext *s, const Picture *p, int 
i)
 {
 int xy   = s->block_index[i];
 uint16_t time_pp = s->pp_time;
@@ -750,7 +750,7 @@ static inline void set_one_direct_mv(MpegEncContext *s, 
Picture *p, int i)
 static int set_direct_mv(MpegEncContext *s)
 {
 const int mb_index = s->mb_x + s->mb_y * s->mb_stride;
-Picture *p = &s->next_pic;
+const Picture *p = &s->next_pic;
 int colocated_mb_type = p->mb_type[mb_index];
 int i;
 
diff --git a/libavcodec/ituh263enc.c b/libavcodec/ituh263enc.c
index 70a65423f3..b65a1c069a 100644
--- a/libavcodec/ituh263enc.c
+++ b/libavcodec/ituh263enc.c
@@ -305,7 +305,7 @@ static const int dquant_code[5]= {1,0,9,2,3};
 static void h263_encode_block(MpegEncContext * s, int16_t * block, int n)
 {
 int level, run, last, i, j, last_index, last_non_zero, sign, slevel, code;
-RLTable *rl;
+const RLTable *rl;
 
 rl = &ff_h263_rl_inter;
 if (s->mb_intra && !s->h263_aic) {
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index c04d351e0c..6877b9ef4a 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -160,7 +160,7 @@ static inline int mpeg1_decode_block_inter(MpegEncContext 
*s,
int16_t *block, int n)
 {
 int level, i, j, run;
-uint8_t *const scantable = s->intra_scantable.permutated;
+const uint8_t *const scantable = s->intra_scantable.permutated;
 const uint16_t *quant_matrix = s->inter_matrix;
 const int qscale = s->qscale;
 
@@ -244,7 +244,7 @@ static inline int 
mpeg2_decode_block_non_intra(MpegEncContext *s,
int16_t *block, int n)
 {
 int level, i, j, run;
-uint8_t *const scantable = s->intra_scantable.permutated;
+const uint8_t *const scantable = s->intra_scantable.permutated;
 const uint16_t *quant_matrix;
 const int qscale = s->qscale;
 int mismatch;
@@ -331,7 +331,7 @@ static inline int mpeg2_decode_block_intra(MpegEncContext 
*s,
 int level, dc, diff, i, j, run;
 int component;
 const RL_VLC_ELEM *rl_vlc;
-uint8_t *const scantable = s->intra_scantable.permutated;
+ 

[FFmpeg-devel] [PATCH 23/57] avcodec/rv30, rv34, rv40: Avoid indirection

2024-04-29 Thread Andreas Rheinhardt
Use the cached values from MpegEncContext.(cur|last|next)_pic
instead of the corresponding *_pic_ptr.
Also do the same in wmv2dec.c and mpegvideo_enc.c.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo_enc.c |   2 +-
 libavcodec/rv30.c  |  18 +++---
 libavcodec/rv34.c  | 122 +++--
 libavcodec/rv40.c  |  10 +--
 libavcodec/wmv2dec.c   |   7 +--
 5 files changed, 80 insertions(+), 79 deletions(-)

diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 372e96cb39..6b4c3b6649 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -2145,7 +2145,7 @@ static av_always_inline void 
encode_mb_internal(MpegEncContext *s,
 update_qscale(s);
 
 if (!(s->mpv_flags & FF_MPV_FLAG_QP_RD)) {
-s->qscale = s->cur_pic_ptr->qscale_table[mb_xy];
+s->qscale = s->cur_pic.qscale_table[mb_xy];
 s->dquant = s->qscale - last_qp;
 
 if (s->out_format == FMT_H263) {
diff --git a/libavcodec/rv30.c b/libavcodec/rv30.c
index a4e38edf54..9c8bb966e9 100644
--- a/libavcodec/rv30.c
+++ b/libavcodec/rv30.c
@@ -160,7 +160,7 @@ static void rv30_loop_filter(RV34DecContext *r, int row)
 
 mb_pos = row * s->mb_stride;
 for(mb_x = 0; mb_x < s->mb_width; mb_x++, mb_pos++){
-int mbtype = s->cur_pic_ptr->mb_type[mb_pos];
+int mbtype = s->cur_pic.mb_type[mb_pos];
 if(IS_INTRA(mbtype) || IS_SEPARATE_DC(mbtype))
 r->deblock_coefs[mb_pos] = 0x;
 if(IS_INTRA(mbtype))
@@ -172,11 +172,11 @@ static void rv30_loop_filter(RV34DecContext *r, int row)
  */
 mb_pos = row * s->mb_stride;
 for(mb_x = 0; mb_x < s->mb_width; mb_x++, mb_pos++){
-cur_lim = rv30_loop_filt_lim[s->cur_pic_ptr->qscale_table[mb_pos]];
+cur_lim = rv30_loop_filt_lim[s->cur_pic.qscale_table[mb_pos]];
 if(mb_x)
-left_lim = rv30_loop_filt_lim[s->cur_pic_ptr->qscale_table[mb_pos 
- 1]];
+left_lim = rv30_loop_filt_lim[s->cur_pic.qscale_table[mb_pos - 1]];
 for(j = 0; j < 16; j += 4){
-Y = s->cur_pic_ptr->f->data[0] + mb_x*16 + (row*16 + j) * 
s->linesize + 4 * !mb_x;
+Y = s->cur_pic.data[0] + mb_x*16 + (row*16 + j) * s->linesize + 4 
* !mb_x;
 for(i = !mb_x; i < 4; i++, Y += 4){
 int ij = i + j;
 loc_lim = 0;
@@ -196,7 +196,7 @@ static void rv30_loop_filter(RV34DecContext *r, int row)
 if(mb_x)
 left_cbp = (r->cbp_chroma[mb_pos - 1] >> (k*4)) & 0xF;
 for(j = 0; j < 8; j += 4){
-C = s->cur_pic_ptr->f->data[k + 1] + mb_x*8 + (row*8 + j) * 
s->uvlinesize + 4 * !mb_x;
+C = s->cur_pic.data[k + 1] + mb_x*8 + (row*8 + j) * 
s->uvlinesize + 4 * !mb_x;
 for(i = !mb_x; i < 2; i++, C += 4){
 int ij = i + (j >> 1);
 loc_lim = 0;
@@ -214,11 +214,11 @@ static void rv30_loop_filter(RV34DecContext *r, int row)
 }
 mb_pos = row * s->mb_stride;
 for(mb_x = 0; mb_x < s->mb_width; mb_x++, mb_pos++){
-cur_lim = rv30_loop_filt_lim[s->cur_pic_ptr->qscale_table[mb_pos]];
+cur_lim = rv30_loop_filt_lim[s->cur_pic.qscale_table[mb_pos]];
 if(row)
-top_lim = rv30_loop_filt_lim[s->cur_pic_ptr->qscale_table[mb_pos - 
s->mb_stride]];
+top_lim = rv30_loop_filt_lim[s->cur_pic.qscale_table[mb_pos - 
s->mb_stride]];
 for(j = 4*!row; j < 16; j += 4){
-Y = s->cur_pic_ptr->f->data[0] + mb_x*16 + (row*16 + j) * 
s->linesize;
+Y = s->cur_pic.data[0] + mb_x*16 + (row*16 + j) * s->linesize;
 for(i = 0; i < 4; i++, Y += 4){
 int ij = i + j;
 loc_lim = 0;
@@ -238,7 +238,7 @@ static void rv30_loop_filter(RV34DecContext *r, int row)
 if(row)
 top_cbp = (r->cbp_chroma[mb_pos - s->mb_stride] >> (k*4)) & 
0xF;
 for(j = 4*!row; j < 8; j += 4){
-C = s->cur_pic_ptr->f->data[k+1] + mb_x*8 + (row*8 + j) * 
s->uvlinesize;
+C = s->cur_pic.data[k+1] + mb_x*8 + (row*8 + j) * 
s->uvlinesize;
 for(i = 0; i < 2; i++, C += 4){
 int ij = i + (j >> 1);
 loc_lim = 0;
diff --git a/libavcodec/rv34.c b/libavcodec/rv34.c
index 467a6ab5a1..941d983501 100644
--- a/libavcodec/rv34.c
+++ b/libavcodec/rv34.c
@@ -367,7 +367,7 @@ static int rv34_decode_intra_mb_header(RV34DecContext *r, 
int8_t *intra_types)
 
 r->is16 = get_bits1(gb);
 if(r->is16){
-s->cur_pic_ptr->mb_type[mb_pos] = MB_TYPE_INTRA16x16;
+s->cur_pic.mb_type[mb_pos] = MB_TYPE_INTRA16x16;
 r->block_type = RV34_MB_TYPE_INTRA16x16;
 t = get_bits(gb, 2);
 fill_rectangle(intra_types, 4, 4, r->intra_types_stride, t, 
sizeof(intra_types[0]));
@@ -377,7 +377,7 @@ static int rv34_decode_intra_mb_header(RV34DecContext *r, 
in

[FFmpeg-devel] [PATCH 22/57] avcodec/mpegpicture: Cache AVFrame.data and linesize values

2024-04-29 Thread Andreas Rheinhardt
This avoids an indirection and is in preparation for removing
the AVFrame from MpegEncContext.(cur|last|next)_pic altogether.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/motion_est.c  | 16 +++
 libavcodec/mpeg12dec.c   | 14 +++---
 libavcodec/mpeg_er.c |  6 +--
 libavcodec/mpegpicture.c | 14 ++
 libavcodec/mpegpicture.h |  4 ++
 libavcodec/mpegvideo.c   | 10 ++--
 libavcodec/mpegvideo_dec.c   |  4 +-
 libavcodec/mpegvideo_enc.c   | 16 +++
 libavcodec/mpegvideo_motion.c|  4 +-
 libavcodec/mpv_reconstruct_mb_template.c | 12 ++---
 libavcodec/msmpeg4.c |  4 +-
 libavcodec/mss2.c|  4 +-
 libavcodec/svq1enc.c |  6 +--
 libavcodec/vc1_block.c   |  8 ++--
 libavcodec/vc1_mc.c  | 60 
 libavcodec/vc1dec.c  | 28 +--
 16 files changed, 114 insertions(+), 96 deletions(-)

diff --git a/libavcodec/motion_est.c b/libavcodec/motion_est.c
index 07148e16ec..892e2a3d08 100644
--- a/libavcodec/motion_est.c
+++ b/libavcodec/motion_est.c
@@ -703,11 +703,11 @@ static inline int h263_mv4_search(MpegEncContext *s, int 
mx, int my, int shift)
 offset= (s->mb_x*8 + (mx>>1)) + (s->mb_y*8 + (my>>1))*s->uvlinesize;
 
 if(s->no_rounding){
-s->hdsp.put_no_rnd_pixels_tab[1][dxy](c->scratchpad, 
s->last_pic.f->data[1] + offset, s->uvlinesize, 8);
-s->hdsp.put_no_rnd_pixels_tab[1][dxy](c->scratchpad + 8, 
s->last_pic.f->data[2] + offset, s->uvlinesize, 8);
+s->hdsp.put_no_rnd_pixels_tab[1][dxy](c->scratchpad, 
s->last_pic.data[1] + offset, s->uvlinesize, 8);
+s->hdsp.put_no_rnd_pixels_tab[1][dxy](c->scratchpad + 8, 
s->last_pic.data[2] + offset, s->uvlinesize, 8);
 }else{
-s->hdsp.put_pixels_tab   [1][dxy](c->scratchpad, 
s->last_pic.f->data[1] + offset, s->uvlinesize, 8);
-s->hdsp.put_pixels_tab   [1][dxy](c->scratchpad + 8, 
s->last_pic.f->data[2] + offset, s->uvlinesize, 8);
+s->hdsp.put_pixels_tab   [1][dxy](c->scratchpad, 
s->last_pic.data[1] + offset, s->uvlinesize, 8);
+s->hdsp.put_pixels_tab   [1][dxy](c->scratchpad + 8, 
s->last_pic.data[2] + offset, s->uvlinesize, 8);
 }
 
 dmin_sum += s->mecc.mb_cmp[1](s, s->new_pic->data[1] + s->mb_x * 8 + 
s->mb_y * 8 * s->uvlinesize, c->scratchpad, s->uvlinesize, 8);
@@ -899,7 +899,7 @@ void ff_estimate_p_frame_motion(MpegEncContext * s,
 const int shift= 1+s->quarter_sample;
 int mb_type=0;
 
-init_ref(c, s->new_pic->data, s->last_pic.f->data, NULL, 16*mb_x, 16*mb_y, 
0);
+init_ref(c, s->new_pic->data, s->last_pic.data, NULL, 16*mb_x, 16*mb_y, 0);
 
 av_assert0(s->quarter_sample==0 || s->quarter_sample==1);
 av_assert0(s->linesize == c->stride);
@@ -1070,7 +1070,7 @@ int ff_pre_estimate_p_frame_motion(MpegEncContext * s,
 int P[10][2];
 const int shift= 1+s->quarter_sample;
 const int xy= mb_x + mb_y*s->mb_stride;
-init_ref(c, s->new_pic->data, s->last_pic.f->data, NULL, 16*mb_x, 16*mb_y, 
0);
+init_ref(c, s->new_pic->data, s->last_pic.data, NULL, 16*mb_x, 16*mb_y, 0);
 
 av_assert0(s->quarter_sample==0 || s->quarter_sample==1);
 
@@ -1499,8 +1499,8 @@ void ff_estimate_b_frame_motion(MpegEncContext * s,
 int fmin, bmin, dmin, fbmin, bimin, fimin;
 int type=0;
 const int xy = mb_y*s->mb_stride + mb_x;
-init_ref(c, s->new_pic->data, s->last_pic.f->data,
- s->next_pic.f->data, 16 * mb_x, 16 * mb_y, 2);
+init_ref(c, s->new_pic->data, s->last_pic.data,
+ s->next_pic.data, 16 * mb_x, 16 * mb_y, 2);
 
 get_limits(s, 16*mb_x, 16*mb_y);
 
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 4aba5651a6..c04d351e0c 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1297,12 +1297,12 @@ static int mpeg_field_start(MpegEncContext *s, const 
uint8_t *buf, int buf_size)
 
 for (int i = 0; i < 3; i++) {
 if (s->picture_structure == PICT_BOTTOM_FIELD) {
-s->cur_pic.f->data[i] = FF_PTR_ADD(s->cur_pic.f->data[i],
-   
s->cur_pic.f->linesize[i]);
+s->cur_pic.data[i] = FF_PTR_ADD(s->cur_pic.data[i],
+s->cur_pic.linesize[i]);
 }
-s->cur_pic.f->linesize[i]  *= 2;
-s->last_pic.f->linesize[i] *= 2;
-s->next_pic.f->linesize[i] *= 2;
+s->cur_pic.linesize[i]  *= 2;
+s->last_pic.linesize[i] *= 2;
+s->next_pic.linesize[i] *= 2;
 }
 }
 
@@ -1377,9 +1377,9 @@ static int mpeg_field_start(MpegEncContext *s, const 
uint8_t *buf, int 

[FFmpeg-devel] [PATCH 21/57] avcodec/mpegpicture: Reduce value of MAX_PLANES define

2024-04-29 Thread Andreas Rheinhardt
No mpegvideo based codec supports alpha.
While just at it, also make the define shorter.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegpicture.h   | 2 +-
 libavcodec/mpegvideo.h | 2 +-
 libavcodec/mpegvideo_enc.c | 7 +++
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/libavcodec/mpegpicture.h b/libavcodec/mpegpicture.h
index 363732910a..8e3c119acc 100644
--- a/libavcodec/mpegpicture.h
+++ b/libavcodec/mpegpicture.h
@@ -27,7 +27,7 @@
 #include "motion_est.h"
 #include "threadframe.h"
 
-#define MPEGVIDEO_MAX_PLANES 4
+#define MPV_MAX_PLANES 3
 #define MAX_PICTURE_COUNT 36
 #define EDGE_WIDTH 16
 
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index 57c1f7e423..bef7c399c2 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -256,7 +256,7 @@ typedef struct MpegEncContext {
 uint8_t *mb_mean;   ///< Table for MB luminance
 int64_t mb_var_sum; ///< sum of MB variance for current frame
 int64_t mc_mb_var_sum;  ///< motion compensated MB variance for 
current frame
-uint64_t encoding_error[MPEGVIDEO_MAX_PLANES];
+uint64_t encoding_error[MPV_MAX_PLANES];
 
 int motion_est;  ///< ME algorithm
 int me_penalty_compensation;
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 63c280c2ba..47e97999af 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1634,7 +1634,7 @@ no_output_pic:
 } else {
 // input is not a shared pix -> reuse buffer for current_pix
 s->cur_pic_ptr = s->reordered_input_picture[0];
-for (i = 0; i < 4; i++) {
+for (int i = 0; i < MPV_MAX_PLANES; i++) {
 if (s->new_pic->data[i])
 s->new_pic->data[i] += INPLACE_OFFSET;
 }
@@ -1861,12 +1861,11 @@ vbv_retry:
 if (avctx->flags & AV_CODEC_FLAG_PASS1)
 ff_write_pass1_stats(s);
 
-for (i = 0; i < 4; i++) {
+for (int i = 0; i < MPV_MAX_PLANES; i++)
 avctx->error[i] += s->encoding_error[i];
-}
 ff_side_data_set_encoder_stats(pkt, s->cur_pic.f->quality,
s->encoding_error,
-   (avctx->flags&AV_CODEC_FLAG_PSNR) ? 
MPEGVIDEO_MAX_PLANES : 0,
+   (avctx->flags&AV_CODEC_FLAG_PSNR) ? 
MPV_MAX_PLANES : 0,
s->pict_type);
 
 if (avctx->flags & AV_CODEC_FLAG_PASS1)
-- 
2.40.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 19/57] avcodec/mpegpicture: Use RefStruct-pool API

2024-04-29 Thread Andreas Rheinhardt
It involves less allocations and therefore has less
potential errors to be checked. One consequence thereof
is that updating the picture tables can no longer fail.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegpicture.c | 81 ++--
 libavcodec/mpegpicture.h | 21 ---
 libavcodec/mpegvideo.c   | 28 --
 3 files changed, 53 insertions(+), 77 deletions(-)

diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index b83fee67f8..ad6157f0c1 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -18,8 +18,6 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#include 
-
 #include "libavutil/avassert.h"
 #include "libavutil/common.h"
 #include "libavutil/mem.h"
@@ -34,13 +32,13 @@
 
 static void av_noinline free_picture_tables(Picture *pic)
 {
-av_buffer_unref(&pic->mbskip_table_buf);
-av_buffer_unref(&pic->qscale_table_buf);
-av_buffer_unref(&pic->mb_type_buf);
+ff_refstruct_unref(&pic->mbskip_table);
+ff_refstruct_unref(&pic->qscale_table_base);
+ff_refstruct_unref(&pic->mb_type_base);
 
 for (int i = 0; i < 2; i++) {
-av_buffer_unref(&pic->motion_val_buf[i]);
-av_buffer_unref(&pic->ref_index_buf[i]);
+ff_refstruct_unref(&pic->motion_val_base[i]);
+ff_refstruct_unref(&pic->ref_index[i]);
 }
 
 pic->mb_width  =
@@ -135,18 +133,18 @@ static int handle_pic_linesizes(AVCodecContext *avctx, 
Picture *pic,
 static int alloc_picture_tables(BufferPoolContext *pools, Picture *pic,
 int mb_height)
 {
-#define GET_BUFFER(name, idx_suffix) do { \
-pic->name ## _buf idx_suffix = av_buffer_pool_get(pools->name ## _pool); \
-if (!pic->name ## _buf idx_suffix) \
+#define GET_BUFFER(name, buf_suffix, idx_suffix) do { \
+pic->name ## buf_suffix idx_suffix = ff_refstruct_pool_get(pools->name ## 
_pool); \
+if (!pic->name ## buf_suffix idx_suffix) \
 return AVERROR(ENOMEM); \
 } while (0)
-GET_BUFFER(mbskip_table,);
-GET_BUFFER(qscale_table,);
-GET_BUFFER(mb_type,);
+GET_BUFFER(mbskip_table,,);
+GET_BUFFER(qscale_table, _base,);
+GET_BUFFER(mb_type, _base,);
 if (pools->motion_val_pool) {
 for (int i = 0; i < 2; i++) {
-GET_BUFFER(motion_val, [i]);
-GET_BUFFER(ref_index,  [i]);
+GET_BUFFER(ref_index,, [i]);
+GET_BUFFER(motion_val, _base, [i]);
 }
 }
 #undef GET_BUFFER
@@ -166,7 +164,7 @@ int ff_alloc_picture(AVCodecContext *avctx, Picture *pic, 
MotionEstContext *me,
  ScratchpadContext *sc, BufferPoolContext *pools,
  int mb_height, ptrdiff_t *linesize, ptrdiff_t *uvlinesize)
 {
-int i, ret;
+int ret;
 
 if (handle_pic_linesizes(avctx, pic, me, sc,
  *linesize, *uvlinesize) < 0)
@@ -179,19 +177,12 @@ int ff_alloc_picture(AVCodecContext *avctx, Picture *pic, 
MotionEstContext *me,
 if (ret < 0)
 goto fail;
 
-pic->mbskip_table = pic->mbskip_table_buf->data;
-pic->qscale_table = pic->qscale_table_buf->data   + 2 * pic->mb_stride 
+ 1;
-pic->mb_type  = (uint32_t*)pic->mb_type_buf->data + 2 * pic->mb_stride 
+ 1;
-
-if (pic->motion_val_buf[0]) {
-for (i = 0; i < 2; i++) {
-pic->motion_val[i] = (int16_t (*)[2])pic->motion_val_buf[i]->data 
+ 4;
-pic->ref_index[i]  = pic->ref_index_buf[i]->data;
-/* FIXME: The output of H.263 with OBMC depends upon
- * the earlier content of the buffer; therefore we
- * reset it here. */
-memset(pic->motion_val_buf[i]->data, 0, 
pic->motion_val_buf[i]->size);
-}
+pic->qscale_table = pic->qscale_table_base + 2 * pic->mb_stride + 1;
+pic->mb_type  = pic->mb_type_base  + 2 * pic->mb_stride + 1;
+
+if (pic->motion_val_base[0]) {
+for (int i = 0; i < 2; i++)
+pic->motion_val[i] = pic->motion_val_base[i] + 4;
 }
 
 return 0;
@@ -223,36 +214,24 @@ void ff_mpeg_unref_picture(Picture *pic)
 pic->coded_picture_number   = 0;
 }
 
-static int update_picture_tables(Picture *dst, const Picture *src)
+static void update_picture_tables(Picture *dst, const Picture *src)
 {
-int i, ret;
-
-ret  = av_buffer_replace(&dst->mbskip_table_buf, src->mbskip_table_buf);
-ret |= av_buffer_replace(&dst->qscale_table_buf, src->qscale_table_buf);
-ret |= av_buffer_replace(&dst->mb_type_buf,  src->mb_type_buf);
-for (i = 0; i < 2; i++) {
-ret |= av_buffer_replace(&dst->motion_val_buf[i], 
src->motion_val_buf[i]);
-ret |= av_buffer_replace(&dst->ref_index_buf[i],  
src->ref_index_buf[i]);
-}
-
-if (ret < 0) {
-free_picture_tables(dst);
-return ret;
+ff_refstruct_replace(&dst->mbskip_table, src->mbskip_table);
+ff_refstruct_replace(&dst->qscale_table_base, src->qscale_tab

[FFmpeg-devel] [PATCH 18/57] avcodec/mpegpicture: Reindent after the previous commit

2024-04-29 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegpicture.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index bd4ddc6b55..b83fee67f8 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -291,12 +291,9 @@ fail:
 
 int ff_find_unused_picture(AVCodecContext *avctx, Picture *picture, int shared)
 {
-int i;
-
-for (i = 0; i < MAX_PICTURE_COUNT; i++) {
-if (!picture[i].f->buf[0])
-return i;
-}
+for (int i = 0; i < MAX_PICTURE_COUNT; i++)
+if (!picture[i].f->buf[0])
+return i;
 
 av_log(avctx, AV_LOG_FATAL,
"Internal error, picture buffer overflow\n");
-- 
2.40.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 17/57] avcodec/mpegvideo, mpegpicture: Add buffer pool

2024-04-29 Thread Andreas Rheinhardt
This avoids constant allocations+frees and will also allow
to simply switch to the RefStruct API, thereby avoiding
the overhead of the AVBuffer API.
It also simplifies the code, because it removes the "needs_realloc"
field: It was added in 435c0b87d28b48dc2e0360adc404a0e2d66d16a0,
before the introduction of the AVBuffer API: given that these buffers
may be used by different threads, they were not freed immediately
and instead were marked as being freed later by setting needs_realloc.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegpicture.c   | 155 -
 libavcodec/mpegpicture.h   |  27 ---
 libavcodec/mpegvideo.c |  37 +
 libavcodec/mpegvideo.h |   2 +
 libavcodec/mpegvideo_dec.c |  35 -
 libavcodec/mpegvideo_enc.c |  13 ++--
 6 files changed, 112 insertions(+), 157 deletions(-)

diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index 06c82880a8..bd4ddc6b55 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -29,15 +29,11 @@
 #include "avcodec.h"
 #include "motion_est.h"
 #include "mpegpicture.h"
-#include "mpegvideo.h"
 #include "refstruct.h"
 #include "threadframe.h"
 
 static void av_noinline free_picture_tables(Picture *pic)
 {
-pic->alloc_mb_width  =
-pic->alloc_mb_height = 0;
-
 av_buffer_unref(&pic->mbskip_table_buf);
 av_buffer_unref(&pic->qscale_table_buf);
 av_buffer_unref(&pic->mb_type_buf);
@@ -46,43 +42,9 @@ static void av_noinline free_picture_tables(Picture *pic)
 av_buffer_unref(&pic->motion_val_buf[i]);
 av_buffer_unref(&pic->ref_index_buf[i]);
 }
-}
-
-static int make_table_writable(AVBufferRef **ref)
-{
-AVBufferRef *old = *ref, *new;
-
-if (av_buffer_is_writable(old))
-return 0;
-new = av_buffer_allocz(old->size);
-if (!new)
-return AVERROR(ENOMEM);
-av_buffer_unref(ref);
-*ref = new;
-return 0;
-}
-
-static int make_tables_writable(Picture *pic)
-{
-#define MAKE_WRITABLE(table) \
-do {\
-int ret = make_table_writable(&pic->table); \
-if (ret < 0) \
-return ret; \
-} while (0)
-
-MAKE_WRITABLE(mbskip_table_buf);
-MAKE_WRITABLE(qscale_table_buf);
-MAKE_WRITABLE(mb_type_buf);
-
-if (pic->motion_val_buf[0]) {
-for (int i = 0; i < 2; i++) {
-MAKE_WRITABLE(motion_val_buf[i]);
-MAKE_WRITABLE(ref_index_buf[i]);
-}
-}
 
-return 0;
+pic->mb_width  =
+pic->mb_height = 0;
 }
 
 int ff_mpeg_framesize_alloc(AVCodecContext *avctx, MotionEstContext *me,
@@ -170,38 +132,28 @@ static int handle_pic_linesizes(AVCodecContext *avctx, 
Picture *pic,
 return 0;
 }
 
-static int alloc_picture_tables(AVCodecContext *avctx, Picture *pic, int 
encoding, int out_format,
-int mb_stride, int mb_width, int mb_height, 
int b8_stride)
+static int alloc_picture_tables(BufferPoolContext *pools, Picture *pic,
+int mb_height)
 {
-const int big_mb_num= mb_stride * (mb_height + 1) + 1;
-const int mb_array_size = mb_stride * mb_height;
-const int b8_array_size = b8_stride * mb_height * 2;
-int i;
-
-
-pic->mbskip_table_buf = av_buffer_allocz(mb_array_size + 2);
-pic->qscale_table_buf = av_buffer_allocz(big_mb_num + mb_stride);
-pic->mb_type_buf  = av_buffer_allocz((big_mb_num + mb_stride) *
- sizeof(uint32_t));
-if (!pic->mbskip_table_buf || !pic->qscale_table_buf || !pic->mb_type_buf)
-return AVERROR(ENOMEM);
-
-if (out_format == FMT_H263 || encoding ||
-(avctx->export_side_data & AV_CODEC_EXPORT_DATA_MVS)) {
-int mv_size= 2 * (b8_array_size + 4) * sizeof(int16_t);
-int ref_index_size = 4 * mb_array_size;
-
-for (i = 0; mv_size && i < 2; i++) {
-pic->motion_val_buf[i] = av_buffer_allocz(mv_size);
-pic->ref_index_buf[i]  = av_buffer_allocz(ref_index_size);
-if (!pic->motion_val_buf[i] || !pic->ref_index_buf[i])
-return AVERROR(ENOMEM);
+#define GET_BUFFER(name, idx_suffix) do { \
+pic->name ## _buf idx_suffix = av_buffer_pool_get(pools->name ## _pool); \
+if (!pic->name ## _buf idx_suffix) \
+return AVERROR(ENOMEM); \
+} while (0)
+GET_BUFFER(mbskip_table,);
+GET_BUFFER(qscale_table,);
+GET_BUFFER(mb_type,);
+if (pools->motion_val_pool) {
+for (int i = 0; i < 2; i++) {
+GET_BUFFER(motion_val, [i]);
+GET_BUFFER(ref_index,  [i]);
 }
 }
+#undef GET_BUFFER
 
-pic->alloc_mb_width  = mb_width;
-pic->alloc_mb_height = mb_height;
-pic->alloc_mb_stride = mb_stride;
+pic->mb_width  = pools->alloc_mb_width;
+pic->mb_height = mb_height;
+pic->mb_stride = pools->alloc_mb_stride;
 
 return 0;
 }
@@ -211,17 +163,11 @@ static int alloc_picture_tables(AVCodecContext *avctx, 
Picture *pic, int encodin
  * The pixels a

[FFmpeg-devel] [PATCH 16/57] avcodec/mpegvideo: Redo aligning mb_height for VC-1

2024-04-29 Thread Andreas Rheinhardt
VC-1 can switch from between being progressive and interlaced
on a per-frame basis. In the latter case, the number of macroblocks
is aligned to two (or equivalently, the height to 32); therefore
certain buffers are allocated for the bigger mb_height
(see 950fb8acb42f4dab9b1638721992991c0584dbf5 and
017e234c204f8ffb5f85a073231247881be1ac6f).

This commit changes how this is done: Aligning these buffers is
restricted to VC-1 and it is done directly by aligning
mb_height (but not MpegEncContext.mb_height) instead of
adding something in an ad-hoc manner.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo.c | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 2ef69a5224..ce1edca95d 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -364,14 +364,8 @@ av_cold void ff_mpv_idct_init(MpegEncContext *s)
 
 static int init_duplicate_context(MpegEncContext *s)
 {
-int y_size = s->b8_stride * (2 * s->mb_height + 1);
-int c_size = s->mb_stride * (s->mb_height + 1);
-int yc_size = y_size + 2 * c_size;
 int i;
 
-if (s->mb_height & 1)
-yc_size += 2*s->b8_stride + 2*s->mb_stride;
-
 if (s->encoding) {
 s->me.map = av_mallocz(2 * ME_MAP_SIZE * sizeof(*s->me.map));
 if (!s->me.map)
@@ -397,6 +391,11 @@ static int init_duplicate_context(MpegEncContext *s)
 }
 
 if (s->out_format == FMT_H263) {
+int mb_height = s->msmpeg4_version == 6 /* VC-1 like */ ?
+FFALIGN(s->mb_height, 2) : s->mb_height;
+int y_size = s->b8_stride * (2 * mb_height + 1);
+int c_size = s->mb_stride * (mb_height + 1);
+int yc_size = y_size + 2 * c_size;
 /* ac values */
 if (!FF_ALLOCZ_TYPED_ARRAY(s->ac_val_base,  yc_size))
 return AVERROR(ENOMEM);
@@ -538,17 +537,24 @@ void ff_mpv_common_defaults(MpegEncContext *s)
 int ff_mpv_init_context_frame(MpegEncContext *s)
 {
 int y_size, c_size, yc_size, i, mb_array_size, mv_table_size, x, y;
+int mb_height;
 
 if (s->codec_id == AV_CODEC_ID_MPEG2VIDEO && !s->progressive_sequence)
 s->mb_height = (s->height + 31) / 32 * 2;
 else
 s->mb_height = (s->height + 15) / 16;
 
+/* VC-1 can change from being progressive to interlaced on a per-frame
+ * basis. We therefore allocate certain buffers so big that they work
+ * in both instances. */
+mb_height = s->msmpeg4_version == 6 /* VC-1 like*/ ?
+FFALIGN(s->mb_height, 2) : s->mb_height;
+
 s->mb_width   = (s->width + 15) / 16;
 s->mb_stride  = s->mb_width + 1;
 s->b8_stride  = s->mb_width * 2 + 1;
-mb_array_size = s->mb_height * s->mb_stride;
-mv_table_size = (s->mb_height + 2) * s->mb_stride + 1;
+mb_array_size = mb_height * s->mb_stride;
+mv_table_size = (mb_height + 2) * s->mb_stride + 1;
 
 /* set default edge pos, will be overridden
  * in decode_header if needed */
@@ -564,13 +570,10 @@ int ff_mpv_init_context_frame(MpegEncContext *s)
 s->block_wrap[4] =
 s->block_wrap[5] = s->mb_stride;
 
-y_size  = s->b8_stride * (2 * s->mb_height + 1);
-c_size  = s->mb_stride * (s->mb_height + 1);
+y_size  = s->b8_stride * (2 * mb_height + 1);
+c_size  = s->mb_stride * (mb_height + 1);
 yc_size = y_size + 2   * c_size;
 
-if (s->mb_height & 1)
-yc_size += 2*s->b8_stride + 2*s->mb_stride;
-
 if (!FF_ALLOCZ_TYPED_ARRAY(s->mb_index2xy, s->mb_num + 1))
 return AVERROR(ENOMEM);
 for (y = 0; y < s->mb_height; y++)
@@ -602,7 +605,7 @@ int ff_mpv_init_context_frame(MpegEncContext *s)
 }
 
 if (s->msmpeg4_version >= 3) {
-s->coded_block_base = av_mallocz(y_size + 
(s->mb_height&1)*2*s->b8_stride);
+s->coded_block_base = av_mallocz(y_size);
 if (!s->coded_block_base)
 return AVERROR(ENOMEM);
 s->coded_block = s->coded_block_base + s->b8_stride + 1;
-- 
2.40.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 15/57] avcodec/mpegpicture: Always reset motion val buffer

2024-04-29 Thread Andreas Rheinhardt
Codecs call ff_find_unused_picture() to get the index of
an unused picture; said picture may have buffers left
from using it previously (these buffers are intentionally
not unreferenced so that it might be possible to reuse them;
this is mpegvideo's version of a bufferpool). They should
not make any assumptions about which picture they get.
Yet somehow this is not true when decoding OBMC: Returning
random empty pictures (instead of the first one) leads
to nondeterministic results; similarly, explicitly
rezeroing the buffer before handing it over to the codec
changes the outcome of the h263-obmc tests, but it makes it
independent of the returned pictures. Therefore this commit
does so.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegpicture.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index 88b4d5dec1..06c82880a8 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -245,6 +245,10 @@ int ff_alloc_picture(AVCodecContext *avctx, Picture *pic, 
MotionEstContext *me,
 for (i = 0; i < 2; i++) {
 pic->motion_val[i] = (int16_t (*)[2])pic->motion_val_buf[i]->data 
+ 4;
 pic->ref_index[i]  = pic->ref_index_buf[i]->data;
+/* FIXME: The output of H.263 with OBMC depends upon
+ * the earlier content of the buffer; therefore we
+ * reset it here. */
+memset(pic->motion_val_buf[i]->data, 0, 
pic->motion_val_buf[i]->size);
 }
 }
 
-- 
2.40.1

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

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


Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: only check index_edit_rate when calculating the index tables

2024-04-29 Thread Tomas Härdin
mån 2024-04-15 klockan 21:34 +0200 skrev Marton Balint:
> Commit ed49391961999f028e0bc55767d0eef6eeb15e49 started rejecting
> negative
> index segment edit rates to avoid negative av_rescale parameters.
> There are two
> problems with this:
> 
> 1) there is already a validation for zero (uninitialized) rates later
> on
> 2) it rejects files with 0/0 index edit rates which do exist and we
> should
> continue to support those

There are no such files in FATE last time I checked. At the very least
we need to know which vendor is producing such broken files.

Without tests covering the workflows we want to support, we have no
confidence in refactoriing. This leads to cargo culting. And to be
sure, every workflow we support means a non-trivial amount of work,
especially when it comes to MXF.

/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 6/6] avformat/mxfdec: Check body_offset

2024-04-29 Thread Tomas Härdin
fre 2024-04-26 klockan 05:08 +0200 skrev Michael Niedermayer:
> Fixes: signed integer overflow: 538976288 - -9223372036315799520
> cannot be represented in type 'long'
> Fixes: 68060/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-
> 5523457266745344
> 
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mxfdec.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 233d614f783..e65cec74c23 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -791,6 +791,9 @@ static int mxf_read_partition_pack(void *arg,
> AVIOContext *pb, int tag, int size
>  partition->index_sid = avio_rb32(pb);
>  partition->body_offset = avio_rb64(pb);
>  partition->body_sid = avio_rb32(pb);
> +    if (partition->body_offset < 0)
> +    return AVERROR_INVALIDDATA;

The spec says BodyOffset is UInt64, so this means we drop support for
files >= 2^63 bytes. This is probably fine though. Supporting such
large files would be a pain in more places than here.

MXF is sometimes used to archive scanned copies of film, but even raw
16k rgb48 essence @ 120 Hz takes over 1000 days of footage to hit the
2^63 limit..

I took a look at the body_offset logic and it looks like it should be
correct when we force them to be non-negative.

TL;DR: looks OK

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

2024-04-29 Thread Rémi Denis-Courmont
Le maanantaina 29. huhtikuuta 2024, 22.04.00 EEST Davy Durham a écrit :
> Presently do you not have to create an account on the devel mailing list to
> contribute to ffmpeg?

Yes, but subscribing to a mailing list is much easier than creating a Gitlab 
account (especially if 2FA is needed), and cloning FFmpeg there.

Still that is a minor inconvenience for first time contributors, which is way 
way outweighed by the extra convenience for the code review and merge process.

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



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

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


Re: [FFmpeg-devel] [PATCH] avcodec/riscv/vp9dsp: Fix inclusion guard

2024-04-29 Thread Jan Ekström
On Mon, Apr 29, 2024 at 9:33 PM Andreas Rheinhardt
 wrote:
>
> Fixes fate-source.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
> I intend to apply this soon.

Verified that this fixes fate-source, LGTM.

Thanks for noticing this.

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

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


[FFmpeg-devel] [PATCH 2/2] lavc/ac3dsp: R-V V sum_square_butterfly_float

2024-04-29 Thread Rémi Denis-Courmont
As we do not need to widen accumulators to 64 bits, we effectively get
double capacity for unrolling compared to the integer function. This
explains the slightly better performance gains.

ac3_sum_square_bufferfly_float_c:   65.2
ac3_sum_square_bufferfly_float_rvv_f32: 12.2
---
 libavcodec/riscv/ac3dsp_init.c |  6 +-
 libavcodec/riscv/ac3dsp_rvv.S  | 39 ++
 2 files changed, 44 insertions(+), 1 deletion(-)

diff --git a/libavcodec/riscv/ac3dsp_init.c b/libavcodec/riscv/ac3dsp_init.c
index be5e153fac..e120aa2dce 100644
--- a/libavcodec/riscv/ac3dsp_init.c
+++ b/libavcodec/riscv/ac3dsp_init.c
@@ -30,6 +30,8 @@ void ff_extract_exponents_rvb(uint8_t *exp, int32_t *coef, 
int nb_coefs);
 void ff_float_to_fixed24_rvv(int32_t *dst, const float *src, size_t len);
 void ff_sum_square_butterfly_int32_rvv(int64_t *, const int32_t *,
const int32_t *, int);
+void ff_sum_square_butterfly_float_rvv(float *, const float *,
+   const float *, int);
 
 av_cold void ff_ac3dsp_init_riscv(AC3DSPContext *c)
 {
@@ -39,8 +41,10 @@ av_cold void ff_ac3dsp_init_riscv(AC3DSPContext *c)
 if (flags & AV_CPU_FLAG_RVB_ADDR) {
 if (flags & AV_CPU_FLAG_RVB_BASIC)
 c->extract_exponents = ff_extract_exponents_rvb;
-if (flags & AV_CPU_FLAG_RVV_F32)
+if (flags & AV_CPU_FLAG_RVV_F32) {
 c->float_to_fixed24 = ff_float_to_fixed24_rvv;
+c->sum_square_butterfly_float = ff_sum_square_butterfly_float_rvv;
+}
 # if __riscv_xlen >= 64
 if (flags & AV_CPU_FLAG_RVV_I64)
 c->sum_square_butterfly_int32 = ff_sum_square_butterfly_int32_rvv;
diff --git a/libavcodec/riscv/ac3dsp_rvv.S b/libavcodec/riscv/ac3dsp_rvv.S
index dd0b4cd797..397e000ab0 100644
--- a/libavcodec/riscv/ac3dsp_rvv.S
+++ b/libavcodec/riscv/ac3dsp_rvv.S
@@ -78,3 +78,42 @@ func ff_sum_square_butterfly_int32_rvv, zve64x
 ret
 endfunc
 #endif
+
+func ff_sum_square_butterfly_float_rvv, zve32f
+vsetvli t0, zero, e32, m8, ta, ma
+vmv.v.x v0, zero
+vmv.v.x v8, zero
+1:
+vsetvli t0, a3, e32, m4, tu, ma
+vle32.v v16, (a1)
+sub a3, a3, t0
+vle32.v v20, (a2)
+sh2add  a1, t0, a1
+vfadd.vvv24, v16, v20
+sh2add  a2, t0, a2
+vfsub.vvv28, v16, v20
+vfmacc.vv   v0, v16, v16
+vfmacc.vv   v4, v20, v20
+vfmacc.vv   v8, v24, v24
+vfmacc.vv   v12, v28, v28
+bneza3, 1b
+
+vsetvli t0, zero, e32, m4, ta, ma
+vmv.s.x v16, zero
+vmv.s.x v17, zero
+vfredsum.vs v16, v0, v16
+vmv.s.x v18, zero
+vfredsum.vs v17, v4, v17
+vmv.s.x v19, zero
+vfredsum.vs v18, v8, v18
+vfmv.f.sft0, v16
+vfredsum.vs v19, v12, v19
+vfmv.f.sft1, v17
+fsw ft0,   (a0)
+vfmv.f.sft2, v18
+fsw ft1,  4(a0)
+vfmv.f.sft3, v19
+fsw ft2,  8(a0)
+fsw ft3, 12(a0)
+ret
+endfunc
-- 
2.43.0

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

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


[FFmpeg-devel] [PATCH 1/2] lavc/ac3dsp: R-V V sum_square_butterfly_int32

2024-04-29 Thread Rémi Denis-Courmont
ac3_sum_square_bufferfly_int32_c:   61.0
ac3_sum_square_bufferfly_int32_rvv_i64: 14.7
---
 libavcodec/riscv/ac3dsp_init.c |  6 +
 libavcodec/riscv/ac3dsp_rvv.S  | 41 ++
 2 files changed, 47 insertions(+)

diff --git a/libavcodec/riscv/ac3dsp_init.c b/libavcodec/riscv/ac3dsp_init.c
index b9e14d56ca..be5e153fac 100644
--- a/libavcodec/riscv/ac3dsp_init.c
+++ b/libavcodec/riscv/ac3dsp_init.c
@@ -28,6 +28,8 @@
 
 void ff_extract_exponents_rvb(uint8_t *exp, int32_t *coef, int nb_coefs);
 void ff_float_to_fixed24_rvv(int32_t *dst, const float *src, size_t len);
+void ff_sum_square_butterfly_int32_rvv(int64_t *, const int32_t *,
+   const int32_t *, int);
 
 av_cold void ff_ac3dsp_init_riscv(AC3DSPContext *c)
 {
@@ -39,6 +41,10 @@ av_cold void ff_ac3dsp_init_riscv(AC3DSPContext *c)
 c->extract_exponents = ff_extract_exponents_rvb;
 if (flags & AV_CPU_FLAG_RVV_F32)
 c->float_to_fixed24 = ff_float_to_fixed24_rvv;
+# if __riscv_xlen >= 64
+if (flags & AV_CPU_FLAG_RVV_I64)
+c->sum_square_butterfly_int32 = ff_sum_square_butterfly_int32_rvv;
+# endif
 }
 #endif
 }
diff --git a/libavcodec/riscv/ac3dsp_rvv.S b/libavcodec/riscv/ac3dsp_rvv.S
index b8d32c4677..dd0b4cd797 100644
--- a/libavcodec/riscv/ac3dsp_rvv.S
+++ b/libavcodec/riscv/ac3dsp_rvv.S
@@ -37,3 +37,44 @@ func ff_float_to_fixed24_rvv, zve32f
 
 ret
 endfunc
+
+#if __riscv_xlen >= 64
+func ff_sum_square_butterfly_int32_rvv, zve64x
+vsetvlit0, zero, e64, m8, ta, ma
+vmv.v.xv0, zero
+vmv.v.xv8, zero
+1:
+vsetvlit0, a3, e32, m2, tu, ma
+vle32.vv16, (a1)
+suba3, a3, t0
+vle32.vv20, (a2)
+sh2add a1, t0, a1
+vadd.vvv24, v16, v20
+sh2add a2, t0, a2
+vsub.vvv28, v16, v20
+vwmacc.vv  v0, v16, v16
+vwmacc.vv  v4, v20, v20
+vwmacc.vv  v8, v24, v24
+vwmacc.vv  v12, v28, v28
+bnez   a3, 1b
+
+vsetvlit0, zero, e64, m4, ta, ma
+vmv.s.xv16, zero
+vmv.s.xv17, zero
+vredsum.vs v16, v0, v16
+vmv.s.xv18, zero
+vredsum.vs v17, v4, v17
+vmv.s.xv19, zero
+vredsum.vs v18, v8, v18
+vmv.x.st0, v16
+vredsum.vs v19, v12, v19
+vmv.x.st1, v17
+sd t0,   (a0)
+vmv.x.st2, v18
+sd t1,  8(a0)
+vmv.x.st3, v19
+sd t2, 16(a0)
+sd t3, 24(a0)
+ret
+endfunc
+#endif
-- 
2.43.0

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

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


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

2024-04-29 Thread Davy Durham
Presently do you not have to create an account on the devel mailing list to
contribute to ffmpeg?

So on the flip side, I (actually) find it just as annoying to have to
create such accounts at every project rather than my having one account at
GitHub (or a relatively few for other hosting sites) and can then
contribute to literally thousands of projects without any friction.

Moreover now being subscribed to that list I get 50 emails a day that I
have to wait through. Just so long as I want to contribute. Sure I can
create rules but it is pretty obnoxious.

As a casual contributor, I much prefer getting notifications about my
occasion contributions.  But one can opt to get notified of everything by
subscribing to the whole project.

On Mon, Apr 29, 2024, 11:44 AM Ondřej Fiala  wrote:

> On Mon Apr 29, 2024 at 8:03 AM CEST, Davy Durham wrote:
> > On 4/19/24 09:50, Niklas Haas wrote:
> > +1 from me too.  Please oh, please oh, /please/ modernize the patch
> > management.  I don't know what the opposition/inability to use github is
> > all about.  But gitlab should be a great improvement on the ML/patchwork
> > situation.
> I can give you my POV as someone who dislikes GitHub-like workflows. I
> have no idea if anyone's gonna read it, but anyway...
>
> To contribute with GitHub/GitLab, I have to create an account. This
> might sound trivial, but I find it really annoying to have to maintain
> an account on a bunch of code hosting platform just to contribute a single
> patch to a bunch of software projects. I guarantee you I wouldn't
> contribute
> to ffmpeg if I had to create an account to do so (though my patch wasn't
> incorporated anyway despite it being like 20 lines, so I guess it wouldn't
> change much).
>
> Another issue which is very important to me is the fact that neither GitHub
> nor GitLab work reliably with various privacy add-ons and browser settings.
> Gitea is the only GitHub-like software that is usable with these, so if you
> really have to use a GitHub-like workflow, please consider that over GitLab
> if you care at all about usability.GitLab is the worst in this respect
> because not a single thing about it works without JavaScript (I mean,
> I can't even read a project's README without it).
>
> I would really suggest you look at SourceHut. It keeps mailing list with
> patches workflow, but all the patches are tracked including whether they
> were incorporated, rejected, someone requested changes, etc. Other than
> that it has many features you find in other code hosting platforms,
> including an issue tracker, CI/CD, an equivalent for GitHub's "wiki"
> and "pages" features, etc. It's more accessible than all the platforms
> I've mentioned above, in particular it seems to work well even in limited
> browsers without JavaScript and the UI is faster (much faster than GitLab).
>
> It also does not require you to have an account to contribute. In fact,
> I don't have an account there either and want to make it clear that I am
> not connected to SourceHut in any way. I just really enjoy the experience
> of contributing like:
>
> $ git format-patch master
> $ git send-email ~username/project-de...@lists.sr.ht
>
> No need to sign up to a mailing list or a code hosting platform, no need
> to create a "fork" and a pull request, ...
>
> >
> > gitlab has a hosted edition for opensource projects
> > .   (Or is the
> > opposition to github about trusting someone else to host it in general?)
> >
> > Automated CI/CD pipelines will change your /life/ if you've never used
> > them.  I was once opposed but wouldn't want to do it any other way for
> > any significant project anymore.
> >
> > Inline comments on MRs would be a great improvement for discussions and
> > requests from maintainers, and plus it's much easier to see/drill-into
> > those discussion from the blame view.
> >
> > my two cents
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


[FFmpeg-devel] [PATCH] avcodec/riscv/vp9dsp: Fix inclusion guard

2024-04-29 Thread Andreas Rheinhardt
Fixes fate-source.

Signed-off-by: Andreas Rheinhardt 
---
I intend to apply this soon.

 libavcodec/riscv/vp9dsp.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/riscv/vp9dsp.h b/libavcodec/riscv/vp9dsp.h
index 0540c7303d..25047ed507 100644
--- a/libavcodec/riscv/vp9dsp.h
+++ b/libavcodec/riscv/vp9dsp.h
@@ -18,8 +18,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#ifndef AVCODEC_RISCV_VP9DSP_RISCV_H
-#define AVCODEC_RISCV_VP9DSP_RISCV_H
+#ifndef AVCODEC_RISCV_VP9DSP_H
+#define AVCODEC_RISCV_VP9DSP_H
 
 #include 
 #include 
@@ -168,4 +168,4 @@ VP9_COPY_RISCV_RVI_FUNC(4);
 #undef VP9_BILINEAR_RISCV_RVV_FUNC
 #undef VP9_COPY_AVG_RISCV_RVV_FUNC
 
-#endif  // #ifndef AVCODEC_RISCV_VP9DSP_RISCV_H
+#endif  // #ifndef AVCODEC_RISCV_VP9DSP_H
-- 
2.40.1

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

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


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

2024-04-29 Thread Lynne
Apr 29, 2024, 19:30 by gsean...@gmail.com:

> Hi,
>
> On Mon, Apr 29, 2024 at 12:58 PM Michael Niedermayer
>  wrote:
>
>>
>> Hi
>>
>> On Sat, Apr 27, 2024 at 02:16:36PM +0200, Lynne wrote:
>> > Hi,
>> >
>> > I'm requesting a reimbursement for attending the Khronos F2F
>> > event in Brussels on 2024-04-26, where I gave a talk about the
>> > current status of Vulkan Video integration into FFmpeg:
>> >  - Currently implemented decoding features
>> >  - What we would like to be improved (stability, speed and testing from 
>> > all vendors)
>> >  - Currently implemented WIP encoding features
>> >  - What we would need to implement in order to match nvenc in terms of 
>> > quality on most vendors
>> >
>> > Also, I collaborated on future extensions to the standard,
>> > and discussed AV1 issues recently found in the specifications
>> > and how we could fix them.
>> >
>> > 95 GBP: Eurostar to Bruxelle-Midi
>> > 95 GBP: Eurostar from Bruxelle-Midi
>> > Total: 190 GBP
>>
>> LGTM
>>
>> PS: maybe we should make a page on trac that links to all talks from all 
>> FFmpeg developers
>>
>
> Is there video/audio from this talk? I would like to watch/listen if so.
>

Unfortunately, Khronos doesn't really publish them.
But if you want, I can explain what is lacking somewhere.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [PATCH 2/4] lavc/vp9dsp: R-V V ipred vert

2024-04-29 Thread Rémi Denis-Courmont
Le perjantaina 22. maaliskuuta 2024, 8.02.38 EEST flow gg a écrit :
> Because the previous patch was updated, so it was updated in this response

Seemingly needs rebase since April 7.

-- 
レミ・デニ-クールモン
http://www.remlab.net/



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

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


Re: [FFmpeg-devel] [PATCH v3 0/1] avformat/demux: fix accurate probing of durations in mpegts/ps

2024-04-29 Thread Nicolas Gaullier
>Envoyé : lundi 22 avril 2024 14:32
>À : ffmpeg-devel@ffmpeg.org
>Objet : Re: [FFmpeg-devel] [PATCH v3 0/1] avformat/demux: fix accurate probing 
>of durations in mpegts/ps
>
>>De : Nicolas Gaullier  Envoyé : mardi 2 
>>avril 2024 23:26 Objet : [PATCH v3 0/1] avformat/demux: fix accurate 
>>probing of durations in mpegts/ps
>>
>>v3: rebased after ed9363052f4b8b8 applied tonight (add 
>>duration_probesize AVOption)
>>
>>Note: I have no other plan for demux/probing; with these two patches, I can 
>>cover my use cases, especially mpegts-concats.
>>
>>For remembering, previous cover-letters:
>>
>>v1
>>ff_read_packet() is more lightweight, but it leads to important issues when 
>>looking for accurate durations.
>>As a side effect, the code looks also simpler with regular av_read_frame() 
>>calls.
>>1)Updates in the fate tests do exhibit most of the results.
>>
>>2)See also more directly the case of an audio PES containing many frames:
>>>ffprobe tests/data/lavf/lavf.ts -select_streams a -show_entries 
>>>stream=duration -of flat
>>Before patch:
>>  streams.stream.0.duration="0.757556"
>>After patch:
>>  streams.stream.0.duration="1.018778"
>>
>>3)Here is an additional (commonplace) sample to demonstrate the benefit for 
>>twofields-encoded video:
>>>https://0x0.st/HFbm.ts (say h264-50i_mp2.ts)
>>
>>>ffprobe h264-50i_mp2.ts -show_entries stream=duration -of flat
>>Before patch:
>>  streams.stream.0.duration="2.06"
>>  streams.stream.1.duration="1.176000"
>>After patch:
>>  streams.stream.0.duration="2.08"
>>  streams.stream.1.duration="1.20"
>>
>>
>>v2
>>v1: There was an issue with teletext where resolution is set just once at 
>>decoder init (teletext resolution is fixed/hard coded), so it is somewhat 
>>fragile: when a demuxer context update occurs, it is lost/overriden by 
avcodec_parameters_to_context(sti->avctx, st->codecpar) in 
>>read_frame_internal.
>>They could have been other scenario besides teletext, I don't know.
>>v2: So now at estimate_timings_from_pts, with one or more seeking involved 
>>(seeking is detected by the mpegts demuxer and set last_vn=-1, so pmt is 
>>forced/updated and results in demuxer context update), it is required to 
preserve the info in codecpar at first.
>>Thanks to Michael for reporting the issue.
>>
>>
>>Nicolas Gaullier (1):
>>  avformat/demux: Fix accurate probing of durations in mpegts/ps
>>
>> libavformat/demux.c   |  36 ++--
>> tests/ref/fate/concat-demuxer-simple2-lavf-ts | 170 +-
>> tests/ref/fate/ts-opus-demux  |   4 +-
>> 3 files changed, 100 insertions(+), 110 deletions(-)
>
>Ping for review ?
>The patch (https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=11386) 
>still applies on current master.
>Thanks.

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

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


Re: [FFmpeg-devel] [PATCH 2/2] lavc/blockdsp: R-V V fill_block

2024-04-29 Thread Rémi Denis-Courmont
Le maanantaina 29. huhtikuuta 2024, 10.09.41 EEST flow gg a écrit :
> 

Are you sure that this works with all vector lengths?
The block8 code looks odd.

-- 
レミ・デニ-クールモン
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


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

2024-04-29 Thread Sean McGovern
Hi,

On Mon, Apr 29, 2024 at 12:58 PM Michael Niedermayer
 wrote:
>
> Hi
>
> On Sat, Apr 27, 2024 at 02:16:36PM +0200, Lynne wrote:
> > Hi,
> >
> > I'm requesting a reimbursement for attending the Khronos F2F
> > event in Brussels on 2024-04-26, where I gave a talk about the
> > current status of Vulkan Video integration into FFmpeg:
> >  - Currently implemented decoding features
> >  - What we would like to be improved (stability, speed and testing from all 
> > vendors)
> >  - Currently implemented WIP encoding features
> >  - What we would need to implement in order to match nvenc in terms of 
> > quality on most vendors
> >
> > Also, I collaborated on future extensions to the standard,
> > and discussed AV1 issues recently found in the specifications
> > and how we could fix them.
> >
> > 95 GBP: Eurostar to Bruxelle-Midi
> > 95 GBP: Eurostar from Bruxelle-Midi
> > Total: 190 GBP
>
> LGTM
>
> PS: maybe we should make a page on trac that links to all talks from all 
> FFmpeg developers
>

Is there video/audio from this talk? I would like to watch/listen if so.

-- 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] [REFUND-REQUEST] Vulkan F2F travel

2024-04-29 Thread Michael Niedermayer
Hi

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

LGTM

PS: maybe we should make a page on trac that links to all talks from all FFmpeg 
developers

thx

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

Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.



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

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


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

2024-04-29 Thread Ondřej Fiala
On Mon Apr 29, 2024 at 6:37 PM CEST, Ondřej Fiala wrote:
> $ git format-patch master
> $ git send-email ~username/project-de...@lists.sr.ht
Should have checked what I'm writing. The second line should be
$ git send-email --to ~username/project-de...@lists.sr.ht *.patch

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

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


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

2024-04-29 Thread Ondřej Fiala
On Mon Apr 29, 2024 at 8:03 AM CEST, Davy Durham wrote:
> On 4/19/24 09:50, Niklas Haas wrote:
> +1 from me too.  Please oh, please oh, /please/ modernize the patch 
> management.  I don't know what the opposition/inability to use github is 
> all about.  But gitlab should be a great improvement on the ML/patchwork 
> situation.
I can give you my POV as someone who dislikes GitHub-like workflows. I
have no idea if anyone's gonna read it, but anyway...

To contribute with GitHub/GitLab, I have to create an account. This
might sound trivial, but I find it really annoying to have to maintain
an account on a bunch of code hosting platform just to contribute a single
patch to a bunch of software projects. I guarantee you I wouldn't contribute
to ffmpeg if I had to create an account to do so (though my patch wasn't
incorporated anyway despite it being like 20 lines, so I guess it wouldn't
change much).

Another issue which is very important to me is the fact that neither GitHub
nor GitLab work reliably with various privacy add-ons and browser settings.
Gitea is the only GitHub-like software that is usable with these, so if you
really have to use a GitHub-like workflow, please consider that over GitLab
if you care at all about usability.GitLab is the worst in this respect
because not a single thing about it works without JavaScript (I mean,
I can't even read a project's README without it).

I would really suggest you look at SourceHut. It keeps mailing list with
patches workflow, but all the patches are tracked including whether they
were incorporated, rejected, someone requested changes, etc. Other than
that it has many features you find in other code hosting platforms,
including an issue tracker, CI/CD, an equivalent for GitHub's "wiki"
and "pages" features, etc. It's more accessible than all the platforms
I've mentioned above, in particular it seems to work well even in limited
browsers without JavaScript and the UI is faster (much faster than GitLab).

It also does not require you to have an account to contribute. In fact,
I don't have an account there either and want to make it clear that I am
not connected to SourceHut in any way. I just really enjoy the experience
of contributing like:

$ git format-patch master
$ git send-email ~username/project-de...@lists.sr.ht

No need to sign up to a mailing list or a code hosting platform, no need
to create a "fork" and a pull request, ...

>
> gitlab has a hosted edition for opensource projects 
> .   (Or is the 
> opposition to github about trusting someone else to host it in general?)
>
> Automated CI/CD pipelines will change your /life/ if you've never used 
> them.  I was once opposed but wouldn't want to do it any other way for 
> any significant project anymore.
>
> Inline comments on MRs would be a great improvement for discussions and 
> requests from maintainers, and plus it's much easier to see/drill-into 
> those discussion from the blame view.
>
> my two cents
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 1/4] avcodec/x86/vvc: add alf filter luma and chroma avx2 optimizations

2024-04-29 Thread Andreas Rheinhardt
toq...@outlook.com:
> vvc_alf_filter_chroma_16x12_10_c: 7235.5
> vvc_alf_filter_chroma_16x12_10_avx2: 9751.0

Are these numbers correct? If so, the avx2 version should not be committed.

- Andreas

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

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


Re: [FFmpeg-devel] [PATCH 2/4] tests/checkasm: add checkasm_check_vvc_alf and check_alf_filter

2024-04-29 Thread Lynne
Apr 29, 2024, 17:25 by toq...@outlook.com:

> From: Wu Jianhua 
>
> Signed-off-by: Wu Jianhua 
> ---
>  tests/checkasm/Makefile   |   2 +-
>  tests/checkasm/checkasm.c |   3 +-
>  tests/checkasm/checkasm.h |   1 +
>  tests/checkasm/vvc_alf.c  | 133 ++
>  4 files changed, 137 insertions(+), 2 deletions(-)
>  create mode 100644 tests/checkasm/vvc_alf.c
>
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index 2673e1d098..5a3e3985c4 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -41,7 +41,7 @@ AVCODECOBJS-$(CONFIG_V210_DECODER)  += v210dec.o
>  AVCODECOBJS-$(CONFIG_V210_ENCODER)  += v210enc.o
>  AVCODECOBJS-$(CONFIG_VORBIS_DECODER)+= vorbisdsp.o
>  AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
> -AVCODECOBJS-$(CONFIG_VVC_DECODER)   += vvc_mc.o
> +AVCODECOBJS-$(CONFIG_VVC_DECODER)   += vvc_alf.o vvc_mc.o
>  
>  CHECKASMOBJS-$(CONFIG_AVCODEC)  += $(AVCODECOBJS-yes)
>  
> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> index 8be6cb0f55..8b2bf2827b 100644
> --- a/tests/checkasm/checkasm.c
> +++ b/tests/checkasm/checkasm.c
> @@ -198,7 +198,8 @@ static const struct {
>  { "vorbisdsp", checkasm_check_vorbisdsp },
>  #endif
>  #if CONFIG_VVC_DECODER
> -{ "vvc_mc", checkasm_check_vvc_mc },
> +{ "vvc_alf", checkasm_check_vvc_alf },
> +{ "vvc_mc",  checkasm_check_vvc_mc  },
>  #endif
>  #endif
>  #if CONFIG_AVFILTER
> diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
> index f90920dee7..c6a5cf42dd 100644
> --- a/tests/checkasm/checkasm.h
> +++ b/tests/checkasm/checkasm.h
> @@ -132,6 +132,7 @@ void checkasm_check_vp8dsp(void);
>  void checkasm_check_vp9dsp(void);
>  void checkasm_check_videodsp(void);
>  void checkasm_check_vorbisdsp(void);
> +void checkasm_check_vvc_alf(void);
>  void checkasm_check_vvc_mc(void);
>  
>  struct CheckasmPerf;
> diff --git a/tests/checkasm/vvc_alf.c b/tests/checkasm/vvc_alf.c
> new file mode 100644
> index 00..10469e1528
> --- /dev/null
> +++ b/tests/checkasm/vvc_alf.c
> @@ -0,0 +1,133 @@
> +/*
> + * Copyright (c) 2023-2024 Nuo Mi 
> + * Copyright (c) 2023-2024 Wu Jianhua 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 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 General Public License for more details.
> + *
> + * You should have received a copy of the GNU 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 "checkasm.h"
> +#include "libavcodec/vvc/ctu.h"
> +#include "libavcodec/vvc/data.h"
> +#include "libavcodec/vvc/dsp.h"
> +
> +#include "libavutil/common.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/mem_internal.h"
> +
> +static const uint32_t pixel_mask[3] = { 0x, 0x03ff03ff, 0x0fff0fff };
> +
> +#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
> +#define SRC_PIXEL_STRIDE (MAX_CTU_SIZE + 2 * ALF_PADDING_SIZE)
> +#define DST_PIXEL_STRIDE (SRC_PIXEL_STRIDE + 4)
> +#define SRC_BUF_SIZE (SRC_PIXEL_STRIDE * (MAX_CTU_SIZE + 3 * 2) * 2) //+3 * 
> 2 for top and bottom row, *2 for high bit depth
> +#define DST_BUF_SIZE (DST_PIXEL_STRIDE * (MAX_CTU_SIZE + 3 * 2) * 2)
> +#define LUMA_PARAMS_SIZE (MAX_CTU_SIZE * MAX_CTU_SIZE / ALF_BLOCK_SIZE / 
> ALF_BLOCK_SIZE * ALF_NUM_COEFF_LUMA)
> +
> +#define randomize_buffers(buf0, buf1, size) \
> +do {\
> +uint32_t mask = pixel_mask[(bit_depth - 8) >> 1];   \
> +int k;  \
> +for (k = 0; k < size; k += 4) { \
> +uint32_t r = rnd() & mask;  \
> +AV_WN32A(buf0 + k, r);  \
> +AV_WN32A(buf1 + k, r);  \
> +}   \
> +} while (0)
> +
> +#define randomize_buffers2(buf, size, filter)   \
> +do {\
> +int k;  \
> +if (filter) {   \
> +for (k = 0; k < size; k++) {\
> +int8_t r = rnd();   \
> +buf[k] = r; \
> +}   \
> +} else {

[FFmpeg-devel] [PATCH 4/4] tests/checkasm/vvc_alf: add check_alf_classify

2024-04-29 Thread toqsxw
From: Wu Jianhua 

Perforamnce Test:
clip before (fps)after (fps)
delta
Tango2_3840x2160_60_10_420_27_LD.266 56  115
105.36%
RitualDance_1920x1080_60_10_420_32_LD.266272 481 
76.83%
RitualDance_1920x1080_60_10_420_37_RA.266303 426 
40.59%

Signed-off-by: Wu Jianhua 
---
 tests/checkasm/vvc_alf.c | 47 
 1 file changed, 47 insertions(+)

diff --git a/tests/checkasm/vvc_alf.c b/tests/checkasm/vvc_alf.c
index 10469e1528..9526260598 100644
--- a/tests/checkasm/vvc_alf.c
+++ b/tests/checkasm/vvc_alf.c
@@ -121,6 +121,47 @@ static void check_alf_filter(VVCDSPContext *c, const int 
bit_depth)
 }
 }
 
+static void check_alf_classify(VVCDSPContext *c, const int bit_depth)
+{
+LOCAL_ALIGNED_32(int, class_idx0, [SRC_BUF_SIZE]);
+LOCAL_ALIGNED_32(int, transpose_idx0, [SRC_BUF_SIZE]);
+LOCAL_ALIGNED_32(int, class_idx1, [SRC_BUF_SIZE]);
+LOCAL_ALIGNED_32(int, transpose_idx1, [SRC_BUF_SIZE]);
+LOCAL_ALIGNED_32(uint8_t, src0, [SRC_BUF_SIZE]);
+LOCAL_ALIGNED_32(uint8_t, src1, [SRC_BUF_SIZE]);
+LOCAL_ALIGNED_32(int32_t, alf_gradient_tmp, [ALF_GRADIENT_SIZE * 
ALF_GRADIENT_SIZE * ALF_NUM_DIR]);
+
+ptrdiff_t stride = SRC_PIXEL_STRIDE * SIZEOF_PIXEL;
+int offset = (3 * SRC_PIXEL_STRIDE + 3) * SIZEOF_PIXEL;
+
+declare_func_emms(AV_CPU_FLAG_AVX2, void, int *class_idx, int 
*transpose_idx,
+const uint8_t *src, ptrdiff_t src_stride, int width, int height, int 
vb_pos, int *gradient_tmp);
+
+randomize_buffers(src0, src1, SRC_BUF_SIZE);
+
+for (int h = 4; h <= MAX_CTU_SIZE; h += 4) {
+for (int w = 4; w <= MAX_CTU_SIZE; w += 4) {
+const int id_size = w * h / ALF_BLOCK_SIZE / ALF_BLOCK_SIZE * 
sizeof(int);
+const int vb_pos  = MAX_CTU_SIZE - ALF_BLOCK_SIZE;
+if (check_func(c->alf.classify, "vvc_alf_classify_%dx%d_%d", w, h, 
bit_depth)) {
+memset(class_idx0, 0, id_size);
+memset(class_idx1, 0, id_size);
+memset(transpose_idx0, 0, id_size);
+memset(transpose_idx1, 0, id_size);
+call_ref(class_idx0, transpose_idx0, src0 + offset, stride, w, 
h, vb_pos, alf_gradient_tmp);
+
+call_new(class_idx1, transpose_idx1, src1 + offset, stride, w, 
h, vb_pos, alf_gradient_tmp);
+
+if (memcmp(class_idx0, class_idx1, id_size))
+fail();
+if (memcmp(transpose_idx0, transpose_idx1, id_size))
+fail();
+bench_new(class_idx1, transpose_idx1, src1 + offset, stride, 
w, h, vb_pos, alf_gradient_tmp);
+}
+}
+}
+}
+
 void checkasm_check_vvc_alf(void)
 {
 int bit_depth;
@@ -130,4 +171,10 @@ void checkasm_check_vvc_alf(void)
 check_alf_filter(&h, bit_depth);
 }
 report("alf_filter");
+
+for (bit_depth = 8; bit_depth <= 12; bit_depth += 2) {
+ff_vvc_dsp_init(&h, bit_depth);
+check_alf_classify(&h, bit_depth);
+}
+report("alf_classify");
 }
-- 
2.44.0.windows.1

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

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


[FFmpeg-devel] [PATCH 2/4] tests/checkasm: add checkasm_check_vvc_alf and check_alf_filter

2024-04-29 Thread toqsxw
From: Wu Jianhua 

Signed-off-by: Wu Jianhua 
---
 tests/checkasm/Makefile   |   2 +-
 tests/checkasm/checkasm.c |   3 +-
 tests/checkasm/checkasm.h |   1 +
 tests/checkasm/vvc_alf.c  | 133 ++
 4 files changed, 137 insertions(+), 2 deletions(-)
 create mode 100644 tests/checkasm/vvc_alf.c

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 2673e1d098..5a3e3985c4 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -41,7 +41,7 @@ AVCODECOBJS-$(CONFIG_V210_DECODER)  += v210dec.o
 AVCODECOBJS-$(CONFIG_V210_ENCODER)  += v210enc.o
 AVCODECOBJS-$(CONFIG_VORBIS_DECODER)+= vorbisdsp.o
 AVCODECOBJS-$(CONFIG_VP9_DECODER)   += vp9dsp.o
-AVCODECOBJS-$(CONFIG_VVC_DECODER)   += vvc_mc.o
+AVCODECOBJS-$(CONFIG_VVC_DECODER)   += vvc_alf.o vvc_mc.o
 
 CHECKASMOBJS-$(CONFIG_AVCODEC)  += $(AVCODECOBJS-yes)
 
diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
index 8be6cb0f55..8b2bf2827b 100644
--- a/tests/checkasm/checkasm.c
+++ b/tests/checkasm/checkasm.c
@@ -198,7 +198,8 @@ static const struct {
 { "vorbisdsp", checkasm_check_vorbisdsp },
 #endif
 #if CONFIG_VVC_DECODER
-{ "vvc_mc", checkasm_check_vvc_mc },
+{ "vvc_alf", checkasm_check_vvc_alf },
+{ "vvc_mc",  checkasm_check_vvc_mc  },
 #endif
 #endif
 #if CONFIG_AVFILTER
diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
index f90920dee7..c6a5cf42dd 100644
--- a/tests/checkasm/checkasm.h
+++ b/tests/checkasm/checkasm.h
@@ -132,6 +132,7 @@ void checkasm_check_vp8dsp(void);
 void checkasm_check_vp9dsp(void);
 void checkasm_check_videodsp(void);
 void checkasm_check_vorbisdsp(void);
+void checkasm_check_vvc_alf(void);
 void checkasm_check_vvc_mc(void);
 
 struct CheckasmPerf;
diff --git a/tests/checkasm/vvc_alf.c b/tests/checkasm/vvc_alf.c
new file mode 100644
index 00..10469e1528
--- /dev/null
+++ b/tests/checkasm/vvc_alf.c
@@ -0,0 +1,133 @@
+/*
+ * Copyright (c) 2023-2024 Nuo Mi 
+ * Copyright (c) 2023-2024 Wu Jianhua 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 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 General Public License for more details.
+ *
+ * You should have received a copy of the GNU 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 "checkasm.h"
+#include "libavcodec/vvc/ctu.h"
+#include "libavcodec/vvc/data.h"
+#include "libavcodec/vvc/dsp.h"
+
+#include "libavutil/common.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mem_internal.h"
+
+static const uint32_t pixel_mask[3] = { 0x, 0x03ff03ff, 0x0fff0fff };
+
+#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
+#define SRC_PIXEL_STRIDE (MAX_CTU_SIZE + 2 * ALF_PADDING_SIZE)
+#define DST_PIXEL_STRIDE (SRC_PIXEL_STRIDE + 4)
+#define SRC_BUF_SIZE (SRC_PIXEL_STRIDE * (MAX_CTU_SIZE + 3 * 2) * 2) //+3 * 2 
for top and bottom row, *2 for high bit depth
+#define DST_BUF_SIZE (DST_PIXEL_STRIDE * (MAX_CTU_SIZE + 3 * 2) * 2)
+#define LUMA_PARAMS_SIZE (MAX_CTU_SIZE * MAX_CTU_SIZE / ALF_BLOCK_SIZE / 
ALF_BLOCK_SIZE * ALF_NUM_COEFF_LUMA)
+
+#define randomize_buffers(buf0, buf1, size) \
+do {\
+uint32_t mask = pixel_mask[(bit_depth - 8) >> 1];   \
+int k;  \
+for (k = 0; k < size; k += 4) { \
+uint32_t r = rnd() & mask;  \
+AV_WN32A(buf0 + k, r);  \
+AV_WN32A(buf1 + k, r);  \
+}   \
+} while (0)
+
+#define randomize_buffers2(buf, size, filter)   \
+do {\
+int k;  \
+if (filter) {   \
+for (k = 0; k < size; k++) {\
+int8_t r = rnd();   \
+buf[k] = r; \
+}   \
+} else {\
+for (k = 0; k < size; k++) {\
+int r = rnd() % FF_ARRAY_ELEMS(clip_set);   \
+buf[k] = clip_set[r];   \
+}   

[FFmpeg-devel] [PATCH 1/4] avcodec/x86/vvc: add alf filter luma and chroma avx2 optimizations

2024-04-29 Thread toqsxw
From: Wu Jianhua 

vvc_alf_filter_chroma_4x4_10_c: 657.0
vvc_alf_filter_chroma_4x4_10_avx2: 138.0
vvc_alf_filter_chroma_4x8_10_c: 1264.7
vvc_alf_filter_chroma_4x8_10_avx2: 253.5
vvc_alf_filter_chroma_4x12_10_c: 1841.7
vvc_alf_filter_chroma_4x12_10_avx2: 375.5
vvc_alf_filter_chroma_4x16_10_c: 2442.7
vvc_alf_filter_chroma_4x16_10_avx2: 491.7
vvc_alf_filter_chroma_4x20_10_c: 3057.0
vvc_alf_filter_chroma_4x20_10_avx2: 607.2
vvc_alf_filter_chroma_4x24_10_c: 3667.0
vvc_alf_filter_chroma_4x24_10_avx2: 747.5
vvc_alf_filter_chroma_4x28_10_c: 4286.7
vvc_alf_filter_chroma_4x28_10_avx2: 849.0
vvc_alf_filter_chroma_4x32_10_c: 4886.0
vvc_alf_filter_chroma_4x32_10_avx2: 967.5
vvc_alf_filter_chroma_8x4_10_c: 1250.5
vvc_alf_filter_chroma_8x4_10_avx2: 261.0
vvc_alf_filter_chroma_8x8_10_c: 2430.7
vvc_alf_filter_chroma_8x8_10_avx2: 494.7
vvc_alf_filter_chroma_8x12_10_c: 3631.2
vvc_alf_filter_chroma_8x12_10_avx2: 734.5
vvc_alf_filter_chroma_8x16_10_c: 13675.7
vvc_alf_filter_chroma_8x16_10_avx2: 972.0
vvc_alf_filter_chroma_8x20_10_c: 6212.0
vvc_alf_filter_chroma_8x20_10_avx2: 1211.0
vvc_alf_filter_chroma_8x24_10_c: 7440.7
vvc_alf_filter_chroma_8x24_10_avx2: 1447.0
vvc_alf_filter_chroma_8x28_10_c: 8460.5
vvc_alf_filter_chroma_8x28_10_avx2: 1682.5
vvc_alf_filter_chroma_8x32_10_c: 9665.2
vvc_alf_filter_chroma_8x32_10_avx2: 1917.7
vvc_alf_filter_chroma_12x4_10_c: 1865.2
vvc_alf_filter_chroma_12x4_10_avx2: 391.7
vvc_alf_filter_chroma_12x8_10_c: 3625.2
vvc_alf_filter_chroma_12x8_10_avx2: 739.0
vvc_alf_filter_chroma_12x12_10_c: 5427.5
vvc_alf_filter_chroma_12x12_10_avx2: 1094.2
vvc_alf_filter_chroma_12x16_10_c: 7237.7
vvc_alf_filter_chroma_12x16_10_avx2: 1447.2
vvc_alf_filter_chroma_12x20_10_c: 9035.2
vvc_alf_filter_chroma_12x20_10_avx2: 1805.2
vvc_alf_filter_chroma_12x24_10_c: 11135.7
vvc_alf_filter_chroma_12x24_10_avx2: 2158.2
vvc_alf_filter_chroma_12x28_10_c: 12644.0
vvc_alf_filter_chroma_12x28_10_avx2: 2511.2
vvc_alf_filter_chroma_12x32_10_c: 14441.7
vvc_alf_filter_chroma_12x32_10_avx2: 2888.0
vvc_alf_filter_chroma_16x4_10_c: 2410.0
vvc_alf_filter_chroma_16x4_10_avx2: 251.7
vvc_alf_filter_chroma_16x8_10_c: 4943.0
vvc_alf_filter_chroma_16x8_10_avx2: 479.0
vvc_alf_filter_chroma_16x12_10_c: 7235.5
vvc_alf_filter_chroma_16x12_10_avx2: 9751.0
vvc_alf_filter_chroma_16x16_10_c: 10142.7
vvc_alf_filter_chroma_16x16_10_avx2: 935.5
vvc_alf_filter_chroma_16x20_10_c: 12029.0
vvc_alf_filter_chroma_16x20_10_avx2: 1174.5
vvc_alf_filter_chroma_16x24_10_c: 14414.2
vvc_alf_filter_chroma_16x24_10_avx2: 1410.5
vvc_alf_filter_chroma_16x28_10_c: 16813.0
vvc_alf_filter_chroma_16x28_10_avx2: 1713.0
vvc_alf_filter_chroma_16x32_10_c: 19228.5
vvc_alf_filter_chroma_16x32_10_avx2: 2256.0
vvc_alf_filter_chroma_20x4_10_c: 3015.2
vvc_alf_filter_chroma_20x4_10_avx2: 371.7
vvc_alf_filter_chroma_20x8_10_c: 6170.2
vvc_alf_filter_chroma_20x8_10_avx2: 721.0
vvc_alf_filter_chroma_20x12_10_c: 9019.7
vvc_alf_filter_chroma_20x12_10_avx2: 1102.7
vvc_alf_filter_chroma_20x16_10_c: 12040.2
vvc_alf_filter_chroma_20x16_10_avx2: 1422.5
vvc_alf_filter_chroma_20x20_10_c: 15010.7
vvc_alf_filter_chroma_20x20_10_avx2: 1765.7
vvc_alf_filter_chroma_20x24_10_c: 18017.7
vvc_alf_filter_chroma_20x24_10_avx2: 2124.7
vvc_alf_filter_chroma_20x28_10_c: 21025.5
vvc_alf_filter_chroma_20x28_10_avx2: 2488.2
vvc_alf_filter_chroma_20x32_10_c: 31128.5
vvc_alf_filter_chroma_20x32_10_avx2: 3205.2
vvc_alf_filter_chroma_24x4_10_c: 3701.2
vvc_alf_filter_chroma_24x4_10_avx2: 494.7
vvc_alf_filter_chroma_24x8_10_c: 7613.0
vvc_alf_filter_chroma_24x8_10_avx2: 957.2
vvc_alf_filter_chroma_24x12_10_c: 10816.7
vvc_alf_filter_chroma_24x12_10_avx2: 1427.7
vvc_alf_filter_chroma_24x16_10_c: 14390.5
vvc_alf_filter_chroma_24x16_10_avx2: 1948.2
vvc_alf_filter_chroma_24x20_10_c: 17989.5
vvc_alf_filter_chroma_24x20_10_avx2: 2363.7
vvc_alf_filter_chroma_24x24_10_c: 21581.7
vvc_alf_filter_chroma_24x24_10_avx2: 2839.7
vvc_alf_filter_chroma_24x28_10_c: 25179.2
vvc_alf_filter_chroma_24x28_10_avx2: 3313.2
vvc_alf_filter_chroma_24x32_10_c: 28776.2
vvc_alf_filter_chroma_24x32_10_avx2: 4154.7
vvc_alf_filter_chroma_28x4_10_c: 4331.2
vvc_alf_filter_chroma_28x4_10_avx2: 624.2
vvc_alf_filter_chroma_28x8_10_c: 8445.0
vvc_alf_filter_chroma_28x8_10_avx2: 1197.7
vvc_alf_filter_chroma_28x12_10_c: 12684.5
vvc_alf_filter_chroma_28x12_10_avx2: 1786.7
vvc_alf_filter_chroma_28x16_10_c: 16924.5
vvc_alf_filter_chroma_28x16_10_avx2: 2378.7
vvc_alf_filter_chroma_28x20_10_c: 38361.0
vvc_alf_filter_chroma_28x20_10_avx2: 2967.0
vvc_alf_filter_chroma_28x24_10_c: 25329.0
vvc_alf_filter_chroma_28x24_10_avx2: 3564.2
vvc_alf_filter_chroma_28x28_10_c: 29514.0
vvc_alf_filter_chroma_28x28_10_avx2: 4151.7
vvc_alf_filter_chroma_28x32_10_c: 33673.2
vvc_alf_filter_chroma_28x32_10_avx2: 5125.0
vvc_alf_filter_chroma_32x4_10_c: 4945.2
vvc_alf_filter_chroma_32x4_10_avx2: 485.7
vvc_alf_filter_chroma_32x8_10_c: 9658.7
vvc_alf_filter_chroma_32x8_10_avx2: 943.7
vvc_alf_filter_chroma_32x12_10_c: 16177.7
vvc_alf_filter_chroma_32x12_10_avx2: 1443.7
vvc_alf_filter_chroma_32x16

[FFmpeg-devel] [PATCH v2 2/14] avcodec/mpegpicture: Store linesize in ScratchpadContext

2024-04-29 Thread Andreas Rheinhardt
The mpegvideo-based codecs currently require the linesize to be
constant (except when the frame dimensions change); one reason
for this is that certain scratch buffers whose size depend on
linesize are only allocated once and are presumed to be correctly
sized if the pointers are != NULL.

This commit changes this by storing the actual linesize these
buffers belong to and reallocating the buffers if it does not
suffice. This is not enough to actually support changing linesizes,
but it is a start. And it is a prerequisite for the next patch.

Also don't emit an error message in case the source ctx's
edge_emu_buffer is unset in ff_mpeg_update_thread_context().
It need not be an error at all; e.g. it is a perfectly normal
state in case a hardware acceleration is used as the scratch
buffers are not allocated in this case (it is easy to run into
this issue with MPEG-4) or if the src context was not initialized
at all (e.g. because the first packet contained garbage).

Signed-off-by: Andreas Rheinhardt 
---
Updated the commit message to include that this also removes
error spam for MPEG-4 frame-threading with hwaccel.

 libavcodec/mpegpicture.c   | 19 ++-
 libavcodec/mpegpicture.h   |  1 +
 libavcodec/mpegvideo.c | 19 +++
 libavcodec/mpegvideo_dec.c | 19 +++
 4 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index 06b6daa01a..aa882cf747 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -89,12 +89,16 @@ int ff_mpeg_framesize_alloc(AVCodecContext *avctx, 
MotionEstContext *me,
 ScratchpadContext *sc, int linesize)
 {
 #   define EMU_EDGE_HEIGHT (4 * 70)
-int alloc_size = FFALIGN(FFABS(linesize) + 64, 32);
+int linesizeabs = FFABS(linesize);
+int alloc_size = FFALIGN(linesizeabs + 64, 32);
+
+if (linesizeabs <= sc->linesize)
+return 0;
 
 if (avctx->hwaccel)
 return 0;
 
-if (linesize < 24) {
+if (linesizeabs < 24) {
 av_log(avctx, AV_LOG_ERROR, "Image too small, temporary buffers cannot 
function\n");
 return AVERROR_PATCHWELCOME;
 }
@@ -102,6 +106,9 @@ int ff_mpeg_framesize_alloc(AVCodecContext *avctx, 
MotionEstContext *me,
 if (av_image_check_size2(alloc_size, EMU_EDGE_HEIGHT, avctx->max_pixels, 
AV_PIX_FMT_NONE, 0, avctx) < 0)
 return AVERROR(ENOMEM);
 
+av_freep(&sc->edge_emu_buffer);
+av_freep(&me->scratchpad);
+
 // edge emu needs blocksize + filter length - 1
 // (= 17x17 for  halfpel / 21x21 for H.264)
 // VC-1 computes luma and chroma simultaneously and needs 19X19 + 9x9
@@ -110,9 +117,11 @@ int ff_mpeg_framesize_alloc(AVCodecContext *avctx, 
MotionEstContext *me,
 // we also use this buffer for encoding in encode_mb_internal() needig an 
additional 32 lines
 if (!FF_ALLOCZ_TYPED_ARRAY(sc->edge_emu_buffer, alloc_size * 
EMU_EDGE_HEIGHT) ||
 !FF_ALLOCZ_TYPED_ARRAY(me->scratchpad,  alloc_size * 4 * 16 * 2)) {
+sc->linesize = 0;
 av_freep(&sc->edge_emu_buffer);
 return AVERROR(ENOMEM);
 }
+sc->linesize = linesizeabs;
 
 me->temp= me->scratchpad;
 sc->rd_scratchpad   = me->scratchpad;
@@ -149,9 +158,9 @@ static int handle_pic_linesizes(AVCodecContext *avctx, 
Picture *pic,
 return -1;
 }
 
-if (!sc->edge_emu_buffer &&
-(ret = ff_mpeg_framesize_alloc(avctx, me, sc,
-   pic->f->linesize[0])) < 0) {
+ret = ff_mpeg_framesize_alloc(avctx, me, sc,
+  pic->f->linesize[0]);
+if (ret < 0) {
 av_log(avctx, AV_LOG_ERROR,
"get_buffer() failed to allocate context scratch buffers.\n");
 ff_mpeg_unref_picture(pic);
diff --git a/libavcodec/mpegpicture.h b/libavcodec/mpegpicture.h
index a457586be5..215e7388ef 100644
--- a/libavcodec/mpegpicture.h
+++ b/libavcodec/mpegpicture.h
@@ -38,6 +38,7 @@ typedef struct ScratchpadContext {
 uint8_t *rd_scratchpad;   ///< scratchpad for rate distortion mb 
decision
 uint8_t *obmc_scratchpad;
 uint8_t *b_scratchpad;///< scratchpad used for writing into write 
only buffers
+int  linesize;///< linesize that the buffers in this 
context have been allocated for
 } ScratchpadContext;
 
 /**
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 7af823b8bd..130ccb4c97 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -443,6 +443,7 @@ static void free_duplicate_context(MpegEncContext *s)
 s->sc.rd_scratchpad =
 s->sc.b_scratchpad =
 s->sc.obmc_scratchpad = NULL;
+s->sc.linesize = 0;
 
 av_freep(&s->dct_error_sum);
 av_freep(&s->me.map);
@@ -464,12 +465,9 @@ static void free_duplicate_contexts(MpegEncContext *s)
 static void backup_duplicate_context(MpegEncContext *bak, MpegEncContext *src)
 {
 #define COPY(a) bak->a = src->a
-COPY(sc.

Re: [FFmpeg-devel] [PATCH v2] avformat: enable UDP IPv6 multicast interface selection using zone index

2024-04-29 Thread Lynne
Apr 29, 2024, 13:34 by r...@remlab.net:

>
>
> Le 29 avril 2024 13:32:41 GMT+03:00, Lynne  a écrit :
> >Apr 29, 2024, 11:56 by r...@remlab.net:
>
>>>
>>>
>>> Le 29 avril 2024 11:20:24 GMT+03:00, Lynne  a écrit :
>>>
> >They were they deprecated?
>
> They caused more bugs than they solved problems (because what we need is 
> to add IPv6 to IPv4 apps, not IPv4 to IPv6 apps).
>
>>> >What bugs did they cause?
>>>
>>> Obviously anything that assumes IPv6 semantics is prone to breaking.
>>>
 i know they're not very well used, because the

>>> >documentation is very lacking,
>>>
>>> No, they're not used because they are officially deprecated for 15+ years 
>>> (see RFC5156).
>>>
> >The RFC says that IPv4-Compatible addresses are deprecated,
> >but doesn't say that about IPv4-Mapped addresses.
>
> Ah, yeah, the case against mapped addresses did not make it to RFC status, 
> likely because the main author tragically died, see 
> draft-itojun-v6ops-v4mapped-harmful.
>

The draft recommends that their use on the wire is forbidden,
which is a niche use-case some vendors did.


> But anyway, I am not a vendor of IP stacks. I am just the messenger here: 
> mapped addresses are not portable and so you should not rely on them in 
> portable code.
>

Fair enough, thanks for looking into it, will keep it in mind that
OpenBSD doesn't implement this yet.
I'm sure IPv4 will be deprecated soon. The Czech government is
so optimistic it announced it'll stop hosting its website under it
in just 8 years from now.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avformat/file: fail for non-numerical arguments to pipe:

2024-04-29 Thread Nils Goroll

Before this patch, the implementation of pipe: inputs/outputs would
silently fall back to stdin/stdout for any argument not successfully
parsed by strtol().

This patch introduces an explicit error for any non-numerical arguments,
which should avoid user confusion as in #10977.

New behavior:

$ cat /tmp/video.mkv | ./ffmpeg -i pipe:aa -acodec copy -vcodec copy -f matroska 
pipe:1 | cat >/tmp/out.mkv


[pipe @ 0x5618c7bcf740] Non-numerical argument "aa" to pipe:
[in#0 @ 0x5618c7bced00] Error opening input: Invalid argument
Error opening input file pipe:aa.
Error opening input files: Invalid argument

Signed-off-by: Nils Goroll 
---
 libavformat/file.c | 19 +++
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/libavformat/file.c b/libavformat/file.c
index 0b7452bc20..317a769e32 100644
--- a/libavformat/file.c
+++ b/libavformat/file.c
@@ -437,18 +437,21 @@ static int pipe_open(URLContext *h, const char *filename, 
int flags)

 {
 FileContext *c = h->priv_data;
 int fd;
-char *final;
+char *final = NULL;
  if (c->fd < 0) {
 av_strstart(filename, "pipe:", &filename);
 -fd = strtol(filename, &final, 10);
-if((filename == final) || *final ) {/* No digits found, or something 
like 10ab */

-if (flags & AVIO_FLAG_WRITE) {
-fd = 1;
-} else {
-fd = 0;
-}
+if (*filename == '\0')
+fd = (flags & AVIO_FLAG_WRITE) ? 1 : 0;
+else
+fd = strtol(filename, &final, 10);
+
+if (final != NULL && *final != '\0') {
+av_log(h, AV_LOG_ERROR,
+"Non-numerical argument \"%s\" to pipe:\n",
+   filename);
+return AVERROR(EINVAL);
 }
 c->fd = fd;
 }
--
2.39.2

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

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


Re: [FFmpeg-devel] [PATCH WIP 0/9] Refactor DNN

2024-04-29 Thread Zhao Zhili


> On Apr 29, 2024, at 18:29, Guo, Yejun  
> wrote:
> 
> 
> 
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of Zhao
>> Zhili
>> Sent: Sunday, April 28, 2024 6:55 PM
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [PATCH WIP 0/9] Refactor DNN
>> 
>> 
>> 
>>> On Apr 28, 2024, at 18:34, Guo, Yejun > intel@ffmpeg.org> wrote:
>>> 
 -Original Message-
 From: ffmpeg-devel >>> > On Behalf Of Zhao Zhili
 Sent: Sunday, April 28, 2024 12:42 AM
 To: ffmpeg-devel@ffmpeg.org 
 Cc: Zhao Zhili mailto:zhiliz...@tencent.com>>
 Subject: [FFmpeg-devel] [PATCH WIP 0/9] Refactor DNN
 
 From: Zhao Zhili 
 
 During the refactor progress, I have found some serious issues, which
 is not resolved by the patchset:
 
 1. Tensorflow backend is broken.
 
 I think it doesn't work since 2021 at least. For example, it destroy
 a thread and create a new thread for each frame, and it destroy an
 invalid thread at the first
 frame:
>>> 
>>> It works from the day that code is merged, till today. It is by design
>>> to keep the code simplicity by using the feature that pthread_join
>>> accepts a parameter that is not a joinable thread.
>>> 
>>> Please share more info if you experienced a real case that it does not work.
>> 
>> It will abort if ASSERT_LEVEL > 1.
>> 
>> #define ASSERT_PTHREAD_ABORT(func, ret) do {\
>>char errbuf[AV_ERROR_MAX_STRING_SIZE] = ""; \
>>av_log(NULL, AV_LOG_FATAL, AV_STRINGIFY(func)   \
>>   " failed with error: %s\n",  \
>>   av_make_error_string(errbuf, AV_ERROR_MAX_STRING_SIZE,   \
>>AVERROR(ret))); \
>>abort();\
>> } while (0)
>> 
>> I think the check is there just to prevent call pthread_join(0, &ptr) by 
>> accident,
>> so we shouldn’t do that on purpose.
>> 
> Nice catch with configure assert level > 1, will fix, and patch also welcome, 
> thanks.

If I read the code correctly, it destroy a thread and create a new thread for 
each
frame. I think this “async” mode isn’t common in ffmpeg’s design. Create new 
thread
for each frame can be heavy on some platforms. We use slice threading to improve
parallel, and thread with command queue to improve throughput. In this case with
tensorflow do the heavy lift, if it doesn’t support async operation, simple 
synchronous
operation with tensorflow backend should be find. The “async” mode is 
unnecessary
and use more resource  over the benefit it provides.

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] avformat: enable UDP IPv6 multicast interface selection using zone index

2024-04-29 Thread Rémi Denis-Courmont


Le 29 avril 2024 13:32:41 GMT+03:00, Lynne  a écrit :
>Apr 29, 2024, 11:56 by r...@remlab.net:
>
>>
>>
>> Le 29 avril 2024 11:20:24 GMT+03:00, Lynne  a écrit :
>>
 >They were they deprecated?

 They caused more bugs than they solved problems (because what we need is 
 to add IPv6 to IPv4 apps, not IPv4 to IPv6 apps).

>> >What bugs did they cause?
>>
>> Obviously anything that assumes IPv6 semantics is prone to breaking.
>>
>>> i know they're not very well used, because the
>>>
>> >documentation is very lacking,
>>
>> No, they're not used because they are officially deprecated for 15+ years 
>> (see RFC5156).
>>
>
>The RFC says that IPv4-Compatible addresses are deprecated,
>but doesn't say that about IPv4-Mapped addresses.

Ah, yeah, the case against mapped addresses did not make it to RFC status, 
likely because the main author tragically died, see 
draft-itojun-v6ops-v4mapped-harmful.

But anyway, I am not a vendor of IP stacks. I am just the messenger here: 
mapped addresses are not portable and so you should not rely on them in 
portable code.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avformat: enable UDP IPv6 multicast interface selection using zone index

2024-04-29 Thread Lynne
Apr 29, 2024, 11:56 by r...@remlab.net:

>
>
> Le 29 avril 2024 11:20:24 GMT+03:00, Lynne  a écrit :
>
>>> >They were they deprecated?
>>>
>>> They caused more bugs than they solved problems (because what we need is to 
>>> add IPv6 to IPv4 apps, not IPv4 to IPv6 apps).
>>>
> >What bugs did they cause?
>
> Obviously anything that assumes IPv6 semantics is prone to breaking.
>
>> i know they're not very well used, because the
>>
> >documentation is very lacking,
>
> No, they're not used because they are officially deprecated for 15+ years 
> (see RFC5156).
>

The RFC says that IPv4-Compatible addresses are deprecated,
but doesn't say that about IPv4-Mapped addresses.

The kernel would have dropped support for them if that had happened,
they started doing a cleanup of the whole stack a year ago and even
dropped UDP-Lite.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 WIP 0/9] Refactor DNN

2024-04-29 Thread Guo, Yejun


> -Original Message-
> From: ffmpeg-devel  On Behalf Of Zhao
> Zhili
> Sent: Sunday, April 28, 2024 6:55 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH WIP 0/9] Refactor DNN
> 
> 
> 
> > On Apr 28, 2024, at 18:34, Guo, Yejun  intel@ffmpeg.org> wrote:
> >
> >> -Original Message-
> >> From: ffmpeg-devel  >> > On Behalf Of Zhao Zhili
> >> Sent: Sunday, April 28, 2024 12:42 AM
> >> To: ffmpeg-devel@ffmpeg.org 
> >> Cc: Zhao Zhili mailto:zhiliz...@tencent.com>>
> >> Subject: [FFmpeg-devel] [PATCH WIP 0/9] Refactor DNN
> >>
> >> From: Zhao Zhili 
> >>
> >> During the refactor progress, I have found some serious issues, which
> >> is not resolved by the patchset:
> >>
> >> 1. Tensorflow backend is broken.
> >>
> >> I think it doesn't work since 2021 at least. For example, it destroy
> >> a thread and create a new thread for each frame, and it destroy an
> >> invalid thread at the first
> >> frame:
> >
> > It works from the day that code is merged, till today. It is by design
> > to keep the code simplicity by using the feature that pthread_join
> > accepts a parameter that is not a joinable thread.
> >
> > Please share more info if you experienced a real case that it does not work.
> 
> It will abort if ASSERT_LEVEL > 1.
> 
> #define ASSERT_PTHREAD_ABORT(func, ret) do {\
> char errbuf[AV_ERROR_MAX_STRING_SIZE] = ""; \
> av_log(NULL, AV_LOG_FATAL, AV_STRINGIFY(func)   \
>" failed with error: %s\n",  \
>av_make_error_string(errbuf, AV_ERROR_MAX_STRING_SIZE,   \
> AVERROR(ret))); \
> abort();\
> } while (0)
> 
> I think the check is there just to prevent call pthread_join(0, &ptr) by 
> accident,
> so we shouldn’t do that on purpose.
> 
Nice catch with configure assert level > 1, will fix, and patch also welcome, 
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] avformat: enable UDP IPv6 multicast interface selection using zone index

2024-04-29 Thread Rémi Denis-Courmont


Le 29 avril 2024 11:20:24 GMT+03:00, Lynne  a écrit :
>> >They were they deprecated?
>>
>> They caused more bugs than they solved problems (because what we need is to 
>> add IPv6 to IPv4 apps, not IPv4 to IPv6 apps).
>>
>
>What bugs did they cause?

Obviously anything that assumes IPv6 semantics is prone to breaking.

> i know they're not very well used, because the
>documentation is very lacking,

No, they're not used because they are officially deprecated for 15+ years (see 
RFC5156).
___
ffmpeg-devel mailing list
ffmpeg-devel@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] G729 encoding

2024-04-29 Thread Marco Garbin
Hi to all,
when will be available the g729 encoding features ?

Thanks

Marco

Marco Garbin

Net Reply
Via Robert Koch, 1/4
20152 - Milano - ITALY
phone: +39 02 535761
m.gar...@reply.it
www.reply.it

[https://images.reply.eu/img2/net.png]
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v4 4/4] lavf: Add documentation for private "Context" classes

2024-04-29 Thread Andrew Sayers
Doxygen thinks any text like "Context for foo" is a link to a struct called 
"Context".
Add a description and a better link, to avoid confusing readers.
---
 libavformat/async.c | 3 +++
 libavformat/cache.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/libavformat/async.c b/libavformat/async.c
index e096b0bc6f..3c28d418ae 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -53,6 +53,9 @@ typedef struct RingBuffer
 int   read_pos;
 } RingBuffer;
 
+/**
+ * @brief @ref md_doc_2context "Context" for testing async
+ */
 typedef struct Context {
 AVClass*class;
 URLContext *inner;
diff --git a/libavformat/cache.c b/libavformat/cache.c
index 5f78adba9d..3cc0edec82 100644
--- a/libavformat/cache.c
+++ b/libavformat/cache.c
@@ -52,6 +52,9 @@ typedef struct CacheEntry {
 int size;
 } CacheEntry;
 
+/**
+ * @brief @ref md_doc_2context "Context" for a cache
+ */
 typedef struct Context {
 AVClass *class;
 int fd;
-- 
2.43.0

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

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


[FFmpeg-devel] [PATCH v4 3/4] all: Link to "context" from all contexts with documentation

2024-04-29 Thread Andrew Sayers
Some headings needed to be rewritten to accomodate the text,
(hopefully) without changing the meaning.
---
 libavcodec/aac/aacdec.h|  2 +-
 libavcodec/aacenc.h|  2 +-
 libavcodec/ac3enc.h|  2 +-
 libavcodec/amfenc.h|  2 +-
 libavcodec/atrac.h |  2 +-
 libavcodec/avcodec.h   |  3 ++-
 libavcodec/bsf.h   |  2 +-
 libavcodec/cbs.h   |  2 +-
 libavcodec/d3d11va.h   |  3 +--
 libavcodec/h264dsp.h   |  2 +-
 libavcodec/h264pred.h  |  2 +-
 libavcodec/mediacodec.h|  2 +-
 libavcodec/mpegaudiodec_template.c |  2 +-
 libavcodec/pthread_frame.c |  4 ++--
 libavcodec/qsv.h   |  6 --
 libavcodec/sbr.h   |  2 +-
 libavcodec/smacker.c   |  2 +-
 libavcodec/vdpau.h |  3 ++-
 libavcodec/videotoolbox.h  |  5 +++--
 libavfilter/avfilter.h |  2 +-
 libavformat/avformat.h |  3 ++-
 libavformat/avio.h |  3 ++-
 libavutil/audio_fifo.h |  2 +-
 libavutil/hwcontext.h  | 21 -
 libavutil/hwcontext_cuda.h |  2 +-
 libavutil/hwcontext_d3d11va.h  |  4 ++--
 libavutil/hwcontext_d3d12va.h  |  6 +++---
 libavutil/hwcontext_drm.h  |  2 +-
 libavutil/hwcontext_dxva2.h|  4 ++--
 libavutil/hwcontext_mediacodec.h   |  2 +-
 libavutil/hwcontext_opencl.h   |  4 ++--
 libavutil/hwcontext_qsv.h  |  4 ++--
 libavutil/hwcontext_vaapi.h|  6 +++---
 libavutil/hwcontext_vdpau.h|  2 +-
 libavutil/hwcontext_vulkan.h   |  4 ++--
 libavutil/lfg.h|  2 +-
 36 files changed, 66 insertions(+), 57 deletions(-)

diff --git a/libavcodec/aac/aacdec.h b/libavcodec/aac/aacdec.h
index 4cf764e2e9..71d61813f4 100644
--- a/libavcodec/aac/aacdec.h
+++ b/libavcodec/aac/aacdec.h
@@ -248,7 +248,7 @@ typedef struct AACDecDSP {
 } AACDecDSP;
 
 /**
- * main AAC decoding context
+ * main AAC decoding @ref md_doc_2context "context"
  */
 struct AACDecContext {
 const struct AVClass  *class;
diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
index d07960620e..1a645f4719 100644
--- a/libavcodec/aacenc.h
+++ b/libavcodec/aacenc.h
@@ -207,7 +207,7 @@ typedef struct AACPCEInfo {
 } AACPCEInfo;
 
 /**
- * AAC encoder context
+ * AAC encoder @ref md_doc_2context "context"
  */
 typedef struct AACEncContext {
 AVClass *av_class;
diff --git a/libavcodec/ac3enc.h b/libavcodec/ac3enc.h
index 30812617cc..c725007077 100644
--- a/libavcodec/ac3enc.h
+++ b/libavcodec/ac3enc.h
@@ -152,7 +152,7 @@ typedef struct AC3Block {
 } AC3Block;
 
 /**
- * AC-3 encoder private context.
+ * AC-3 encoder private @ref md_doc_2context "context"
  */
 typedef struct AC3EncodeContext {
 AVClass *av_class;  ///< AVClass used for AVOption
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
index 2dbd378ef8..f142ede63a 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -43,7 +43,7 @@ typedef struct AmfTraceWriter {
 } AmfTraceWriter;
 
 /**
-* AMF encoder context
+* AMF encoder @ref md_doc_2context "context"
 */
 
 typedef struct AmfContext {
diff --git a/libavcodec/atrac.h b/libavcodec/atrac.h
index 05208bbee6..1527e376a9 100644
--- a/libavcodec/atrac.h
+++ b/libavcodec/atrac.h
@@ -39,7 +39,7 @@ typedef struct AtracGainInfo {
 } AtracGainInfo;
 
 /**
- *  Gain compensation context structure.
+ *  Gain compensation @ref md_doc_2context "context"
  */
 typedef struct AtracGCContext {
 float   gain_tab1[16];  ///< gain compensation level table
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 968009a192..9180fedca7 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -430,7 +430,8 @@ typedef struct RcOverride{
 #define AV_GET_ENCODE_BUFFER_FLAG_REF (1 << 0)
 
 /**
- * main external API structure.
+ * @ref md_doc_2context "Context" for an encode or decode session
+ *
  * New fields can be added to the end with minor version bumps.
  * Removal, reordering and changes to existing fields require a major
  * version bump.
diff --git a/libavcodec/bsf.h b/libavcodec/bsf.h
index a09c69f242..bf79afa7cc 100644
--- a/libavcodec/bsf.h
+++ b/libavcodec/bsf.h
@@ -56,7 +56,7 @@
  */
 
 /**
- * The bitstream filter state.
+ * Bitstream filter @ref md_doc_2context "context"
  *
  * This struct must be allocated with av_bsf_alloc() and freed with
  * av_bsf_free().
diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index d479b1ac2d..0ff64d2fef 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -214,7 +214,7 @@ typedef void (*CBSTraceWriteCallback)(void *trace_context,
   int64_t value);
 
 /**
- * Context structure for coded bitstream operations.
+ * @ref md_doc_2context "Context" structure for coded bitstream operations.
  */
 typedef struct CodedBitstreamContext {
 /**
diff --git a/libavcodec/d3d11va.h 

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

2024-04-29 Thread Andrew Sayers
---
 libavutil/log.h | 11 ---
 libavutil/opt.h |  7 ---
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/libavutil/log.h b/libavutil/log.h
index ab7ceabe22..cfbf416679 100644
--- a/libavutil/log.h
+++ b/libavutil/log.h
@@ -59,9 +59,14 @@ typedef enum {
 struct AVOptionRanges;
 
 /**
- * Describe the class of an AVClass context structure. That is an
- * arbitrary struct of which the first field is a pointer to an
- * AVClass struct (e.g. AVCodecContext, AVFormatContext etc.).
+ * Metadata about an arbitrary data structure
+ *
+ * A @ref md_doc_2context "context struct" whose first member is a pointer
+ * to an AVClass object is called an "AVClass context structure"
+ * (e.g. AVCodecContext, AVFormatContext etc.).
+ *
+ * AVClass is often combined with @ref avoptions "AVOptions" to create
+ * "AVOptions-enabled structs" that can be easily configured by users.
  */
 typedef struct AVClass {
 /**
diff --git a/libavutil/opt.h b/libavutil/opt.h
index 855e363091..82ac933a2a 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -39,9 +39,10 @@
  * @defgroup avoptions AVOptions
  * @ingroup lavu_data
  * @{
- * AVOptions provide a generic system to declare options on arbitrary structs
- * ("objects"). An option can have a help text, a type and a range of possible
- * values. Options may then be enumerated, read and written to.
+ * Builds on AVClass, adding a generic system to declare options.
+ *
+ * An option can have a help text, a type and a range of possible values.
+ * Options may then be enumerated, read and written to.
  *
  * There are two modes of access to members of AVOption and its child structs.
  * One is called 'native access', and refers to access from the code that
-- 
2.43.0

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

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


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

2024-04-29 Thread Andrew Sayers
Derived from detailed explanations kindly provided by Stefano Sabatini:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325903.html
---
 doc/context.md | 308 +
 1 file changed, 308 insertions(+)
 create mode 100644 doc/context.md

diff --git a/doc/context.md b/doc/context.md
new file mode 100644
index 00..73297f53aa
--- /dev/null
+++ b/doc/context.md
@@ -0,0 +1,308 @@
+# Introduction to contexts
+
+Like many C projects, FFmpeg has adopted the subset of
+[object-oriented 
programming](https://en.wikipedia.org/wiki/Object-oriented_programming)
+techniques that help solve its problems.  Object-like structures are called 
"contexts",
+and this document provides a general introduction to how they work.
+
+Object-oriented programming tends to focus on
+[access](https://en.wikipedia.org/wiki/Access_modifiers) as a primary concern.
+For example, members of a class are often designated "private" to indicate
+they are only accessible to code that's part of the class.  Less focus is put 
on
+[reflection](https://en.wikipedia.org/wiki/Reflection_(computer_programming)),
+where it is provided at all.  For example, C++ has no built-in way to serialize
+the state of an arbitrary object.
+
+Reflection is extremely important for FFmpeg, because user-facing
+options are implemented by reflecting the state of contexts.  Limiting
+access is a secondary concern, mainly important for ensuring
+implementation details can change between versions.
+
+Knowledge of object-oriented programming concepts can help when learning 
FFmpeg,
+but it's important not to fixate on FFmpeg's access control features,
+nor to overlook its reflection capabilities.  This document compares
+FFmpeg and OOP techniques where relevant, but does not require an understanding
+of object-oriented programming.
+
+## Example: modify text then print it
+
+The example below shows a context structure that receives input strings,
+modifies them in some context-dependant way, then prints them to a specified
+filehandle.
+
+```c
+/**
+ * Type information, accessible at runtime.
+ *
+ * Useful when configuring objects.
+ */
+enum ModifyThenPrintDialect {
+MODIFY_THEN_PRINT_DIALECT_PLAIN_TEXT = 0,
+MODIFY_THEN_PRINT_DIALECT_REGEX  = 1,
+MODIFY_THEN_PRINT_DIALECT_REGEX_PCRE = 2
+};
+
+/**
+ * User-facing information about types
+ *
+ * Useful for describing contexts to the user.
+ */
+static const char *ModifyThenPrintDialectName[] = {
+"plain text",
+"regular expression",
+"Perl-compatible regular expression"
+};
+
+/**
+ * Context for functions that modify strings before printing them
+ */
+struct ModifyThenPrintContext {
+
+/**
+ * Information about the type of this particular instance
+ *
+ * Object-oriented programs would probably replace this with "sub-classes",
+ * where each class extends the base class to implement one dialect.
+ * But information about a type can also work more like "mixins",
+ * where several pieces of unrelated functionality are blended together
+ * to create an interface for a specific purpose.
+ */
+enum ModifyThenPrintDialect dialect;
+
+/**
+ * Internal context
+ *
+ * Contains anything that isn't part of the public interface.
+ * The most obvious OOP analogy is to "private" members that are only
+ * accessible to code that's part of the class.  But it could also contain
+ * information about "virtual functions" - functions that every sub-class
+ * guarantees to implement, but in their own class-specific way.
+ */
+void *priv_data;
+
+/**
+ * User-configurable options
+ *
+ * Best set through an API, but can be set directly if necessary
+ *
+ * Data from users needs to be validated before it's set, and the API
+ * might e.g. want to update some internal buffer for performance reasons.
+ * Setting these directly is always less robust than using an API,
+ * but might be worthwhile if you're willing to spend the time checking
+ * for edge cases, and don't mind your code misbehaving if future
+ * versions change the API but not the structure.
+ *
+ * Object-oriented programs would likely make these "protected" members,
+ * initialised in a constructor and accessed with getters and setters.
+ * That means code *related* to this class can access them directly,
+ * while unrelated code accesses them indirectly by calling functions.
+ *
+ * But the "protected access" analogy is quite limited. In particular,
+ * protected members don't have any special reflective properties,
+ * whereas FFmpeg options are usually configurable by end users.
+ */
+char *replace_this;
+char *with_this;
+
+/**
+ * Programmer-configurable variable
+ *
+ * Object-oriented programs would represent this as a public member.
+ */
+FILE *out;
+
+};
+
+/**
+ * Allocate and initialize a ModifyThe

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

2024-04-29 Thread Andrew Sayers
On Mon, Apr 22, 2024 at 07:05:12PM +0200, Stefano Sabatini wrote:
> On date Monday 2024-04-22 16:56:48 +0100, Andrew Sayers wrote:
> > Derived from detailed explanations kindly provided by Stefano Sabatini:
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325903.html
> > ---
> >  doc/context.md | 276 +
> >  1 file changed, 276 insertions(+)
> >  create mode 100644 doc/context.md
> > 
> > diff --git a/doc/context.md b/doc/context.md
> > new file mode 100644
> > index 00..73caacf54f
> > --- /dev/null
> > +++ b/doc/context.md
> > @@ -0,0 +1,276 @@
> > +# Context-oriented programming
> > +
> > +Like many C projects, FFmpeg has adopted the subset of object-oriented 
> > techniques
> > +that help solve its problems.  Object-like structures are called 
> > "contexts",
> > +and this document provides a general introduction to how they work.
> > +
> > +Object-oriented programming usually focusses on *access* as a primary 
> > concern.
> > +For example, members of an object are visibly designated "private", 
> > "constant"
> > +etc. to control how they are accessed.  *Reflection* is a secondary 
> > concern,
> > +where it is provided at all.  For example, C++ has no built-in way to get a
> > +string containing the name of a variable.
> > +
> > +Reflection is extremely important for FFmpeg, because user-facing options 
> > are
> > +implemented by reflecting state at runtime. Limiting access is a secondary
> > +concern, mainly important for ensuring implementation details can change
> > +between versions.
> > +
> > +An object-oriented programmer learning FFmpeg should be careful not to 
> > fixate on
> > +FFmpeg's access control features, nor to overlook its reflection 
> > capabilities.
> > +Both are present, but have been given the level of focus appropriate for 
> > the task.
> > +
> > +## Example: modify text then print it
> > +
> > +The example below shows a context structure that receives input strings,
> > +modifies them in some context-dependant way, then prints them to a 
> > specified
> > +filehandle.
> > +
> > +```c
> > +/**
> > + * Type information, accessible at runtime.
> > + *
> > + * Useful when configuring objects.
> > + */
> > +enum ModifyThenPrintDialect {
> > +MODIFY_THEN_PRINT_PLAIN_TEXT = 0,
> > +MODIFY_THEN_PRINT_REGEX  = 1,
> > +MODIFY_THEN_PRINT_REGEX_PCRE = 2
> > +};
> > +
> > +/**
> > + * User-facing information about types
> > + *
> > + * Useful for describing contexts to the user.
> > + */
> > +static const char* ModifyThenPrintDialectName[] = {
> > +"plain text",
> > +"regular expression",
> > +"Perl-compatible regular expression"
> > +};
> > +
> > +/**
> > + * Context for functions that modify strings before printing them
> > + */
> > +struct ModifyThenPrintContext {
> > +
> > +/**
> > + * Information about the type of this particular instance
> > + *
> > + * Object-oriented programs would probably represent this example
> > + * as a sub-class, but some instance-specific functionality
> > + * behaves more like a mixin.
> > + */
> > +enum ModifyThenPrintDialect dialect;
> > +
> > +/**
> > + * Internal context
> > + *
> > + * Object-oriented programs would put private members in here,
> > + * but could also use it to store a virtual function table
> > + * or other "invisible" information.
> > + */
> 
> > +void* priv_data;
> 
> style:
> type *name;
> 
> here and below
> 
> 
> > +
> > +/**
> > + * User-configurable options
> > + *
> > + * Best set through an API, but can be set directly if necessary
> > + *
> > + * Data from users needs to be validated before it's set, and the API
> > + * might e.g. want to update some internal buffer when these change.
> > + * Setting this directly is always less robust than using an API,
> > + * but might be worthwhile if you're willing to spend the time checking
> > + * for edge cases, and don't mind your code misbehaving if future
> > + * versions change the API but not the structure.
> > + *
> > + * Object-oriented programs would likely make these protected members,
> > + * initialised in a constructor and accessed with getters and setters.
> > + * Making them user-configurable would be left to the programmer.
> > + */
> > +char *replace_this;
> > +char *with_this;
> > +
> > +/**
> > + * Programmer-configurable variable
> > + *
> > + * Object-oriented programs would represent this as a public member.
> > + */
> > +FILE *out;
> > +
> > +};
> > +
> > +/**
> > + * Allocate and initialize a ModifyThenPrintContext
> > + *
> > + * This creates a new pointer, then fills in some sensible defaults.
> > + *
> > + * We can reasonably assume this function will initialise `priv_data`
> > + * with a dialect-specific object, but shouldn't make any assumptions
> > + * about what that object is.
> > + *
> > + * Object-orie

Re: [FFmpeg-devel] [PATCH] doc/Doxfyile: Refactor for maintainability

2024-04-29 Thread Andrew Sayers
On Sun, Apr 28, 2024 at 11:46:18PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Sun, Apr 28, 2024 at 11:10:22AM +0100, Andrew Sayers wrote:
> [...]
> > Ping ?
> > 
> > Michael, this is in response to your request[0].  I've queued up some more
> > patches that depend on this and would help attract and retain developers 
> > (e.g.
> > warning when you're looking at old documentation).  What would be involved 
> > in
> > getting this sort of thing on the website itself?
> 
> I dont have the time to review this
> 
> if you split the patch between updates to to comments and updates to teh 
> actual
> configuration this may make it easier to review to whoever does review it

Thanks for letting me know.

For anyone who does pick this up - this patch does not contain any changes
to the configuration.  I've attached a default 1.8.2 configuration file in case
you want to use them for a review, but it's a real timesink so I'd recommend
the build-and-diff approach in the patch description.

My interest in this patch was about getting the website itself updated.
My understanding is that can't happen without Michael's involvement,
so I'm planning to focus my attention elsewhere.
# Doxyfile 1.8.2

# This file describes the settings to be used by the documentation system
# doxygen (www.doxygen.org) for a project.
#
# All text after a hash (#) is considered a comment and will be ignored.
# The format is:
#   TAG = value [value, ...]
# For lists items can also be appended using:
#   TAG += value [value, ...]
# Values that contain spaces should be placed between quotes (" ").

#---
# Project related configuration options
#---

# This tag specifies the encoding used for all characters in the config file
# that follow. The default is UTF-8 which is also the encoding used for all
# text before the first occurrence of this tag. Doxygen uses libiconv (or the
# iconv built into libc) for the transcoding. See
# http://www.gnu.org/software/libiconv for the list of possible encodings.

DOXYFILE_ENCODING  = UTF-8

# The PROJECT_NAME tag is a single word (or sequence of words) that should
# identify the project. Note that if you do not use Doxywizard you need
# to put quotes around the project name if it contains spaces.

PROJECT_NAME   = "My Project"

# The PROJECT_NUMBER tag can be used to enter a project or revision number.
# This could be handy for archiving the generated documentation or
# if some version control system is used.

PROJECT_NUMBER =

# Using the PROJECT_BRIEF tag one can provide an optional one line description
# for a project that appears at the top of each page and should give viewer
# a quick idea about the purpose of the project. Keep the description short.

PROJECT_BRIEF  =

# With the PROJECT_LOGO tag one can specify an logo or icon that is
# included in the documentation. The maximum height of the logo should not
# exceed 55 pixels and the maximum width should not exceed 200 pixels.
# Doxygen will copy the logo to the output directory.

PROJECT_LOGO   =

# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute)
# base path where the generated documentation will be put.
# If a relative path is entered, it will be relative to the location
# where doxygen was started. If left blank the current directory will be used.

OUTPUT_DIRECTORY   =

# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create
# 4096 sub-directories (in 2 levels) under the output directory of each output
# format and will distribute the generated files over these directories.
# Enabling this option can be useful when feeding doxygen a huge amount of
# source files, where putting all generated files in the same directory would
# otherwise cause performance problems for the file system.

CREATE_SUBDIRS = NO

# The OUTPUT_LANGUAGE tag is used to specify the language in which all
# documentation generated by doxygen is written. Doxygen will use this
# information to generate all constant output in the proper language.
# The default language is English, other supported languages are:
# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional,
# Croatian, Czech, Danish, Dutch, Esperanto, Farsi, Finnish, French, German,
# Greek, Hungarian, Italian, Japanese, Japanese-en (Japanese with English
# messages), Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian,
# Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrillic, Slovak,
# Slovene, Spanish, Swedish, Ukrainian, and Vietnamese.

OUTPUT_LANGUAGE= English

# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will
# include brief member descriptions after the members that are listed in
# the file and class documentation (similar to JavaDoc).
# Set to NO to disable this.

BRIEF_MEMBER_DESC  = YES

# If the REPEAT_BRIEF tag is 

Re: [FFmpeg-devel] [PATCH v2] avformat: enable UDP IPv6 multicast interface selection using zone index

2024-04-29 Thread Lynne
Apr 29, 2024, 09:34 by r...@remlab.net:

>
>
> Le 28 avril 2024 23:11:48 GMT+03:00, Lynne  a écrit :
> >Apr 28, 2024, 20:15 by r...@remlab.net:
>
>>> Le torstaina 11. huhtikuuta 2024, 10.50.01 EEST Lynne a écrit :
>>>
 Is there a reason why we can't switch to IPv4 addresses mapped
 in IPv6 and just use the IPv6 API everywhere?

>>>
>>> IPv6-mapped IPv4 addresses are pretty much deprecated, if supported 
>>> anymore. 
>>> Some people consider them insecure. But even if you don't agree with that 
>>> assessment, the fact of the matter is that they are not portable.
>>>
> >They were they deprecated?
>
> They caused more bugs than they solved problems (because what we need is to 
> add IPv6 to IPv4 apps, not IPv4 to IPv6 apps).
>

What bugs did they cause? I know they're not very well used, because the
documentation is very lacking, but given that it's a feature of the standard
network stack of both Linux and Windows, surely it's fuzzed and unit tested
more than enough.


>> Why would they not be portable?
>>
>
> Some OS just don't support them, or have a privileged setting to disable them 
> globally. As a user process, you can't rely on them.
>

Which ones have a setting?
Some have a setting to disable IPv6 globally which must be fairly more used,
but I haven't heard ones which have that setting in.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avformat: enable UDP IPv6 multicast interface selection using zone index

2024-04-29 Thread Rémi Denis-Courmont


Le 28 avril 2024 23:11:48 GMT+03:00, Lynne  a écrit :
>Apr 28, 2024, 20:15 by r...@remlab.net:
>
>> Le torstaina 11. huhtikuuta 2024, 10.50.01 EEST Lynne a écrit :
>>
>>> Is there a reason why we can't switch to IPv4 addresses mapped
>>> in IPv6 and just use the IPv6 API everywhere?
>>>
>>
>> IPv6-mapped IPv4 addresses are pretty much deprecated, if supported anymore. 
>> Some people consider them insecure. But even if you don't agree with that 
>> assessment, the fact of the matter is that they are not portable.
>>
>
>They were they deprecated?

They caused more bugs than they solved problems (because what we need is to add 
IPv6 to IPv4 apps, not IPv4 to IPv6 apps).

> Why would they not be portable?

Some OS just don't support them, or have a privileged setting to disable them 
globally. As a user process, you can't rely on them.

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

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


[FFmpeg-devel] [PATCH 2/2] lavc/blockdsp: R-V V fill_block

2024-04-29 Thread flow gg

From 4315f4e4774e3006d7cc55b6d235cb80e0173cf9 Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Wed, 6 Mar 2024 12:46:03 +0800
Subject: [PATCH 2/2] lavc/blockdsp: R-V V fill_block

C908:
blockdsp.fill_block_tab[0]_c: 550.0
blockdsp.fill_block_tab[0]_rvv_i64: 48.2
blockdsp.fill_block_tab[1]_c: 148.7
blockdsp.fill_block_tab[1]_rvv_i64: 29.7
---
 libavcodec/riscv/blockdsp_init.c |  6 ++
 libavcodec/riscv/blockdsp_rvv.S  | 21 +
 2 files changed, 27 insertions(+)

diff --git a/libavcodec/riscv/blockdsp_init.c b/libavcodec/riscv/blockdsp_init.c
index 59b2f9d47b..42c8e87fa7 100644
--- a/libavcodec/riscv/blockdsp_init.c
+++ b/libavcodec/riscv/blockdsp_init.c
@@ -27,6 +27,10 @@
 
 void ff_clear_block_rvv(int16_t *block);
 void ff_clear_blocks_rvv(int16_t *block);
+void ff_fill_block16_rvv(uint8_t *block, uint8_t value, ptrdiff_t line_size,
+   int h);
+void ff_fill_block8_rvv(uint8_t *block, uint8_t value, ptrdiff_t line_size,
+   int h);
 
 av_cold void ff_blockdsp_init_riscv(BlockDSPContext *c)
 {
@@ -36,6 +40,8 @@ av_cold void ff_blockdsp_init_riscv(BlockDSPContext *c)
 if (flags & AV_CPU_FLAG_RVV_I64 && ff_get_rv_vlenb() >= 16) {
 c->clear_block = ff_clear_block_rvv;
 c->clear_blocks = ff_clear_blocks_rvv;
+c->fill_block_tab[0] = ff_fill_block16_rvv;
+c->fill_block_tab[1] = ff_fill_block8_rvv;
 }
 #endif
 }
diff --git a/libavcodec/riscv/blockdsp_rvv.S b/libavcodec/riscv/blockdsp_rvv.S
index 8bb00bb467..71d72cce56 100644
--- a/libavcodec/riscv/blockdsp_rvv.S
+++ b/libavcodec/riscv/blockdsp_rvv.S
@@ -40,3 +40,24 @@ func ff_clear_blocks_rvv, zve64x
 
 ret
 endfunc
+
+func ff_fill_block16_rvv, zve32x
+vsetivli  t0, 16, e8, m1, ta, ma
+vmv.v.x   v8, a1
+1:
+addi  a3, a3, -1
+vse8.vv8, (a0)
+add   a0, a0, a2
+bnez  a3, 1b
+
+ret
+endfunc
+
+func ff_fill_block8_rvv, zve64x
+vsetvli   t0, zero, e8, m8, ta, ma
+vmv.v.x   v8, a1
+vsetvli   t0, a3, e64, m8, ta, ma
+vsse64.v  v8, (a0), a2
+
+ret
+endfunc
-- 
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 1/2] checkasm/blockdsp: add fill_block test

2024-04-29 Thread flow gg

From 0c196a37cb4036d8c618c06c02a011b910cc56ce Mon Sep 17 00:00:00 2001
From: sunyuechi 
Date: Mon, 29 Apr 2024 14:18:23 +0800
Subject: [PATCH 1/2] checkasm/blockdsp: add fill_block test

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

diff --git a/tests/checkasm/blockdsp.c b/tests/checkasm/blockdsp.c
index 22a2f79455..355e111d43 100644
--- a/tests/checkasm/blockdsp.c
+++ b/tests/checkasm/blockdsp.c
@@ -29,6 +29,11 @@
 #include "libavutil/intreadwrite.h"
 #include "libavutil/mem_internal.h"
 
+typedef struct {
+const char *name;
+int size;
+} test;
+
 #define randomize_buffers(size) \
 do {\
 int i;  \
@@ -52,6 +57,31 @@ do {\
 }   \
 } while (0)
 
+static void check_fill(BlockDSPContext *h){
+const test tests[] = {
+{"fill_block_tab[0]", 16},
+{"fill_block_tab[1]", 8},
+};
+const int n = 16;
+
+LOCAL_ALIGNED_32(uint8_t, buf0, [16 * 32]);
+LOCAL_ALIGNED_32(uint8_t, buf1, [16 * 32]);
+
+for (size_t t = 0; t < FF_ARRAY_ELEMS(tests); ++t) {
+declare_func(void, uint8_t *block, uint8_t value,
+ ptrdiff_t line_size, int h);
+if (check_func(h->fill_block_tab[t], "blockdsp.%s", tests[t].name)) {
+uint8_t value = rnd();
+randomize_buffers(tests[t].size);
+call_ref(buf0, value, 16, n);
+call_new(buf1, value, 16, n);
+if (memcmp(buf0, buf1, sizeof(*buf0) * tests[t].size * n))
+fail();
+bench_new(buf0, value, 16, n);
+}
+}
+}
+
 void checkasm_check_blockdsp(void)
 {
 LOCAL_ALIGNED_32(uint16_t, buf0, [6 * 8 * 8]);
@@ -64,5 +94,7 @@ void checkasm_check_blockdsp(void)
 check_clear(clear_block,  8 * 8);
 check_clear(clear_blocks, 8 * 8 * 6);
 
+check_fill(&h);
+
 report("blockdsp");
 }
-- 
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 2/2] lavc/vc1dsp: R-V V mspel_pixels

2024-04-29 Thread flow gg
Happy to see you back :)

Rémi Denis-Courmont  于2024年4月29日周一 02:06写道:

> Le sunnuntaina 7. huhtikuuta 2024, 8.38.54 EEST flow gg a écrit :
> > ping
>
> I have been away for a while, and catching up takes time, sorry.
>
> --
> レミ・デニ-クールモン
> http://www.remlab.net/
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


  1   2   >