Re: [FFmpeg-devel] [PATCH v3] fate/png: add mDCv and cLLi read and write test

[金波]

Sorry, X86 seems not test fate-png-mdcv. BUT arm and loongarch tested, FATE 
failed on them.

> -原始邮件-
> 发件人: 金波 
> 发送时间:2024-10-16 14:55:54 (星期三)
> 收件人: "FFmpeg development discussions and patches" 
> 主题: Re: [FFmpeg-devel] [PATCH v3] fate/png: add mDCv and cLLi read and write 
> test
> 
> > -原始邮件-
> > 发件人: "Leo Izen" 
> > 发送时间:2024-07-16 10:23:51 (星期二)
> > 收件人: ffmpeg-devel@ffmpeg.org
> > 抄送: "Jan Ekström" , "Andreas Rheinhardt" 
> > , "Leo Izen" 
> > 主题: [FFmpeg-devel] [PATCH v3] fate/png: add mDCv and cLLi read and write 
> > test
> > 
> > This test confirms that we can write mDCv and cLLi chunks and read them
> > back via the png decoder. It uses an HEVC conformance sample with this
> > metadata as the base source for the side data in the frames.
> > 
> > Signed-off-by: Leo Izen 
> > Reported-by: Jan Ekström 
> > Reviewed-by: Jan Ekström 
> > Reviewed-by: Andreas Rheinhardt 
> > ---
> >  tests/fate/image.mak|  6 ++
> >  tests/ref/fate/png-mdcv | 22 ++
> >  2 files changed, 28 insertions(+)
> >  create mode 100644 tests/ref/fate/png-mdcv
> > 
> > diff --git a/tests/fate/image.mak b/tests/fate/image.mak
> > index 753936ec20..042cf6438f 100644
> > --- a/tests/fate/image.mak
> > +++ b/tests/fate/image.mak
> > @@ -416,6 +416,12 @@ FATE_PNG_PROBE-$(call ALLYES, LCMS2) += 
> > fate-png-icc-parse
> >  fate-png-icc-parse: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_frames \
> >  -flags2 icc_profiles $(TARGET_SAMPLES)/png1/lena-int_rgb24.png
> >  
> > +FATE_PNG_TRANSCODE-$(call TRANSCODE, PNG HEVC, IMAGE2PIPE HEVC, \
> > +IMAGE_PNG_PIPE_DEMUXER HEVC_PARSER PNG_DECODER SCALE_FILTER) += 
> > fate-png-mdcv
> > +fate-png-mdcv: CMD = transcode hevc 
> > $(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc image2pipe \
> > +"-pix_fmt rgb24 -vf scale -c png" "" \
> > +"-show_frames -show_entries frame=side_data_list -of flat"
> > +
> >  FATE_PNG-$(call DEMDEC, IMAGE2, PNG) += $(FATE_PNG)
> >  FATE_PNG_PROBE-$(call DEMDEC, IMAGE2, PNG) += $(FATE_PNG_PROBE)
> >  FATE_IMAGE_FRAMECRC += $(FATE_PNG-yes)
> > diff --git a/tests/ref/fate/png-mdcv b/tests/ref/fate/png-mdcv
> > new file mode 100644
> > index 00..c524a94ded
> > --- /dev/null
> > +++ b/tests/ref/fate/png-mdcv
> > @@ -0,0 +1,22 @@
> > +fc68fe6c8c72343b96d2695f6913995b *tests/data/fate/png-mdcv.image2pipe
> > +439248 tests/data/fate/png-mdcv.image2pipe
> > +#tb 0: 1/25
> > +#media_type 0: video
> > +#codec_id 0: rawvideo
> > +#dimensions 0: 1280x720
> > +#sar 0: 0/1
> > +0,  0,  0,1,  2764800, 0x2bfc7b42
> > +frames.frame.0.side_data_list.side_data.0.side_data_type="Content light 
> > level metadata"
> > +frames.frame.0.side_data_list.side_data.0.max_content=1000
> > +frames.frame.0.side_data_list.side_data.0.max_average=200
> > +frames.frame.0.side_data_list.side_data.1.side_data_type="Mastering 
> > display metadata"
> > +frames.frame.0.side_data_list.side_data.1.red_x="13250/5"
> > +frames.frame.0.side_data_list.side_data.1.red_y="7500/5"
> > +frames.frame.0.side_data_list.side_data.1.green_x="34000/5"
> > +frames.frame.0.side_data_list.side_data.1.green_y="16000/5"
> > +frames.frame.0.side_data_list.side_data.1.blue_x="2/5"
> > +frames.frame.0.side_data_list.side_data.1.blue_y="0/5"
> > +frames.frame.0.side_data_list.side_data.1.white_point_x="15635/5"
> > +frames.frame.0.side_data_list.side_data.1.white_point_y="16450/5"
> > +frames.frame.0.side_data_list.side_data.1.min_luminance="50/1"
> > +frames.frame.0.side_data_list.side_data.1.max_luminance="1000/1"
> > -- 
> > 2.45.2
> 
> Hi，all：
> fate fails sinc e30bc8a963eab1097bfb985351ca7eaf1f272ba6. I tested on Arm and 
> X86, there existed, too. Or, maybe I missed something else ? I am not 
> knowlegeable enough to fix this. Thx.
> 
> //error
> +++ tests/data/fate/png-mdcv  2024-10-16 14:35:19.264696951 +0800
> @@ -1,5 +1,5 @@
> -4001769a41d37d567c4cc0c532e20b54 *tests/data/fate/png-mdcv.image2pipe
> -2774225 tests/data/fate/png-mdcv.image2pipe
> +b674209fd9cd8eff945a6bc1a4b306d3 *tests/data/fate/png-mdcv.image2pipe
> +2774240 tests/data/fate/png-mdcv.image2pipe
>  #tb 0: 1/25
>  #media_type 0: video
>  #codec_id 0: rawvideo
> Test png-mdcv failed. Look at tests/data/fate/png-mdcv.err for details.
> 
> 
> 
> 本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制或散发）本邮件及其附件中的信息。如果您错收本邮件，请您立即电话或邮件通知发件人并删除本邮件。
>  
> This email and its attachments contain confidential information from Loongson 
> Technology , which is intended only for the person or entity whose address is 
> listed above. Any use of the information contained herein in any way 
> (including, but not limited to, total or partial disclosure, reproduction or 
> dissemination) by persons other than the intended recipient(s) is prohibited. 
> If you receive this email in error, please notify the sender by phone or 
> email immediately and delete it. 
> 
> 


本邮件及其附件含有龙芯中科的商业秘密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其

Re: [FFmpeg-devel] [PATCH] hw_base_encode: Free pictures on close

[Lynne via ffmpeg-devel]

On 15/10/2024 17:51, Lynne via ffmpeg-devel wrote:

On 15/10/2024 16:49, David Rosca wrote:

Fixes leaking recon surfaces with VAAPI.
---
  libavcodec/hw_base_encode.c | 5 +
  1 file changed, 5 insertions(+)

diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 7b6ec97d3b..912c707a68 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -804,6 +804,11 @@ int ff_hw_base_encode_init(AVCodecContext *avctx, 
FFHWBaseEncodeContext *ctx)

  int ff_hw_base_encode_close(FFHWBaseEncodeContext *ctx)
  {
+    FFHWBaseEncodePicture *pic;
+
+    for (pic = ctx->pic_start; pic; pic = pic->next)
+    base_encode_pic_free(pic);
+
  av_fifo_freep2(&ctx->encode_fifo);
  av_frame_free(&ctx->frame);


I've noticed this happening with Vulkan as well.

LGTM, I'll push this after testing it in a few hours

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

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


Thanks, pushed


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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/2] vulkan: enable selecting a compatible representation of format

[Lynne via ffmpeg-devel]

On 16/10/2024 11:56, emufan 4568 wrote:

This works okay on the VC2 vulkan encoder patch

Στις Τετ 16 Οκτ 2024 στις 10:21 π.μ., ο/η Lynne via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> έγραψε:


When using **integer** images inside shaders, it turns out
that conversion doesn't automatically happen, but we need to
explicitly use the imageviews to get the image exposed as
a suitable representation for the shader.

Finally enables bitexact image representations.
---
  libavfilter/vf_nlmeans_vulkan.c |  4 +-
  libavfilter/vulkan_filter.c | 14 ++---
  libavutil/vulkan.c  | 98 -
  libavutil/vulkan.h  |  2 +-
  4 files changed, 106 insertions(+), 12 deletions(-)

diff --git a/libavfilter/vf_nlmeans_vulkan.c
b/libavfilter/vf_nlmeans_vulkan.c
index 68393273d8..5b0f137a40 100644
--- a/libavfilter/vf_nlmeans_vulkan.c
+++ b/libavfilter/vf_nlmeans_vulkan.c
@@ -854,7 +854,7 @@ static int nlmeans_vulkan_filter_frame(AVFilterLink
*link, AVFrame *in)
  ws_buf = NULL;

  /* Input frame prep */
-RET(ff_vk_create_imageviews(vkctx, exec, in_views, in));
+RET(ff_vk_create_imageviews(vkctx, exec, in_views, in,
FF_VK_REP_FLOAT));
  ff_vk_frame_barrier(vkctx, exec, in, img_bar, &nb_img_bar,
  VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
  VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT,
@@ -863,7 +863,7 @@ static int nlmeans_vulkan_filter_frame(AVFilterLink
*link, AVFrame *in)
  VK_QUEUE_FAMILY_IGNORED);

  /* Output frame prep */
-RET(ff_vk_create_imageviews(vkctx, exec, out_views, out));
+RET(ff_vk_create_imageviews(vkctx, exec, out_views, out,
FF_VK_REP_FLOAT));
  ff_vk_frame_barrier(vkctx, exec, out, img_bar, &nb_img_bar,
  VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
  VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT,
diff --git a/libavfilter/vulkan_filter.c b/libavfilter/vulkan_filter.c
index 85665b4d42..bdbebb3cb2 100644
--- a/libavfilter/vulkan_filter.c
+++ b/libavfilter/vulkan_filter.c
@@ -257,7 +257,7 @@ int ff_vk_filter_process_simple(FFVulkanContext
*vkctx, FFVkExecPool *e,
  RET(ff_vk_exec_add_dep_frame(vkctx, exec, out_f,
   VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
   VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
-RET(ff_vk_create_imageviews(vkctx, exec, out_views, out_f));
+RET(ff_vk_create_imageviews(vkctx, exec, out_views, out_f,
FF_VK_REP_FLOAT));
  ff_vk_shader_update_img_array(vkctx, exec, shd, out_f, out_views, 0,
!!in_f,
VK_IMAGE_LAYOUT_GENERAL,
VK_NULL_HANDLE);
@@ -265,7 +265,7 @@ int ff_vk_filter_process_simple(FFVulkanContext
*vkctx, FFVkExecPool *e,
  RET(ff_vk_exec_add_dep_frame(vkctx, exec, in_f,
   VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,

VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
-RET(ff_vk_create_imageviews(vkctx, exec, in_views,  in_f));
+RET(ff_vk_create_imageviews(vkctx, exec, in_views,  in_f,
FF_VK_REP_FLOAT));
  ff_vk_shader_update_img_array(vkctx, exec, shd,  in_f,  in_views,
0, 0,

  VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL,
sampler);
@@ -336,9 +336,9 @@ int ff_vk_filter_process_2pass(FFVulkanContext *vkctx,
FFVkExecPool *e,
   VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
   VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));

-RET(ff_vk_create_imageviews(vkctx, exec, in_views,  in));
-RET(ff_vk_create_imageviews(vkctx, exec, tmp_views, tmp));
-RET(ff_vk_create_imageviews(vkctx, exec, out_views, out));
+RET(ff_vk_create_imageviews(vkctx, exec, in_views,  in,
FF_VK_REP_FLOAT));
+RET(ff_vk_create_imageviews(vkctx, exec, tmp_views, tmp,
FF_VK_REP_FLOAT));
+RET(ff_vk_create_imageviews(vkctx, exec, out_views, out,
FF_VK_REP_FLOAT));

  ff_vk_frame_barrier(vkctx, exec, in, img_bar, &nb_img_bar,
  VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
@@ -418,12 +418,12 @@ int ff_vk_filter_process_Nin(FFVulkanContext *vkctx,
FFVkExecPool *e,
  RET(ff_vk_exec_add_dep_frame(vkctx, exec, out,
   VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
   VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
-RET(ff_vk_create_imageviews(vkctx, exec, out_views, out));
+RET(ff_vk_create_imageviews(vkctx, exec, out_views, out,
FF_VK_REP_FLOAT));
  for (int i = 0; i < nb_in; i++) {
  RET(ff_vk_exec_add_dep_frame(vkctx, exec, in[i],
   VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,

VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
-RET(ff_vk_create_imageviews(vkctx, exec, in_views[i], in[i]));
+RET(ff_vk_create_imageviews(vkctx, exec, in_views[i], in[i],
FF_VK_REP_FLOAT));
  }

  /* Update descriptor se

Re: [FFmpeg-devel] [PATCH 2/2] vulkan: enable selecting a compatible representation of format

[emufan 4568]

This works okay on the VC2 vulkan encoder patch

Στις Τετ 16 Οκτ 2024 στις 10:21 π.μ., ο/η Lynne via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> έγραψε:

> When using **integer** images inside shaders, it turns out
> that conversion doesn't automatically happen, but we need to
> explicitly use the imageviews to get the image exposed as
> a suitable representation for the shader.
>
> Finally enables bitexact image representations.
> ---
>  libavfilter/vf_nlmeans_vulkan.c |  4 +-
>  libavfilter/vulkan_filter.c | 14 ++---
>  libavutil/vulkan.c  | 98 -
>  libavutil/vulkan.h  |  2 +-
>  4 files changed, 106 insertions(+), 12 deletions(-)
>
> diff --git a/libavfilter/vf_nlmeans_vulkan.c
> b/libavfilter/vf_nlmeans_vulkan.c
> index 68393273d8..5b0f137a40 100644
> --- a/libavfilter/vf_nlmeans_vulkan.c
> +++ b/libavfilter/vf_nlmeans_vulkan.c
> @@ -854,7 +854,7 @@ static int nlmeans_vulkan_filter_frame(AVFilterLink
> *link, AVFrame *in)
>  ws_buf = NULL;
>
>  /* Input frame prep */
> -RET(ff_vk_create_imageviews(vkctx, exec, in_views, in));
> +RET(ff_vk_create_imageviews(vkctx, exec, in_views, in,
> FF_VK_REP_FLOAT));
>  ff_vk_frame_barrier(vkctx, exec, in, img_bar, &nb_img_bar,
>  VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
>  VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT,
> @@ -863,7 +863,7 @@ static int nlmeans_vulkan_filter_frame(AVFilterLink
> *link, AVFrame *in)
>  VK_QUEUE_FAMILY_IGNORED);
>
>  /* Output frame prep */
> -RET(ff_vk_create_imageviews(vkctx, exec, out_views, out));
> +RET(ff_vk_create_imageviews(vkctx, exec, out_views, out,
> FF_VK_REP_FLOAT));
>  ff_vk_frame_barrier(vkctx, exec, out, img_bar, &nb_img_bar,
>  VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
>  VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT,
> diff --git a/libavfilter/vulkan_filter.c b/libavfilter/vulkan_filter.c
> index 85665b4d42..bdbebb3cb2 100644
> --- a/libavfilter/vulkan_filter.c
> +++ b/libavfilter/vulkan_filter.c
> @@ -257,7 +257,7 @@ int ff_vk_filter_process_simple(FFVulkanContext
> *vkctx, FFVkExecPool *e,
>  RET(ff_vk_exec_add_dep_frame(vkctx, exec, out_f,
>   VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
>   VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
> -RET(ff_vk_create_imageviews(vkctx, exec, out_views, out_f));
> +RET(ff_vk_create_imageviews(vkctx, exec, out_views, out_f,
> FF_VK_REP_FLOAT));
>  ff_vk_shader_update_img_array(vkctx, exec, shd, out_f, out_views, 0,
> !!in_f,
>VK_IMAGE_LAYOUT_GENERAL,
>VK_NULL_HANDLE);
> @@ -265,7 +265,7 @@ int ff_vk_filter_process_simple(FFVulkanContext
> *vkctx, FFVkExecPool *e,
>  RET(ff_vk_exec_add_dep_frame(vkctx, exec, in_f,
>   VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
>
> VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
> -RET(ff_vk_create_imageviews(vkctx, exec, in_views,  in_f));
> +RET(ff_vk_create_imageviews(vkctx, exec, in_views,  in_f,
> FF_VK_REP_FLOAT));
>  ff_vk_shader_update_img_array(vkctx, exec, shd,  in_f,  in_views,
> 0, 0,
>
>  VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL,
>sampler);
> @@ -336,9 +336,9 @@ int ff_vk_filter_process_2pass(FFVulkanContext *vkctx,
> FFVkExecPool *e,
>   VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
>   VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
>
> -RET(ff_vk_create_imageviews(vkctx, exec, in_views,  in));
> -RET(ff_vk_create_imageviews(vkctx, exec, tmp_views, tmp));
> -RET(ff_vk_create_imageviews(vkctx, exec, out_views, out));
> +RET(ff_vk_create_imageviews(vkctx, exec, in_views,  in,
> FF_VK_REP_FLOAT));
> +RET(ff_vk_create_imageviews(vkctx, exec, tmp_views, tmp,
> FF_VK_REP_FLOAT));
> +RET(ff_vk_create_imageviews(vkctx, exec, out_views, out,
> FF_VK_REP_FLOAT));
>
>  ff_vk_frame_barrier(vkctx, exec, in, img_bar, &nb_img_bar,
>  VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
> @@ -418,12 +418,12 @@ int ff_vk_filter_process_Nin(FFVulkanContext *vkctx,
> FFVkExecPool *e,
>  RET(ff_vk_exec_add_dep_frame(vkctx, exec, out,
>   VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
>   VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
> -RET(ff_vk_create_imageviews(vkctx, exec, out_views, out));
> +RET(ff_vk_create_imageviews(vkctx, exec, out_views, out,
> FF_VK_REP_FLOAT));
>  for (int i = 0; i < nb_in; i++) {
>  RET(ff_vk_exec_add_dep_frame(vkctx, exec, in[i],
>   VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
>
> VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
> -RET(ff_vk_create_imageviews(vkctx, exec, in_views[i], in[i]));
> +RE

Re: [FFmpeg-devel] [Uncompressed MP4] RFC - Draft Encoder

[Tomas Härdin]

Have a look at mov_get_rawvideo_codec_tag()

/Tomas

tis 2024-10-15 klockan 08:17 -0600 skrev Devon Sookhoo:
> This updated patch registers the 'uncv' tag in the isom_tags.c
> ff_codec_movvideo_tags[] list. However, I still need to specify the
> tag
> with the "-tag:v uncv" option. I hoped this change would set 'uncv'
> as the
> default tag for raw mp4 video, but I'm not sure what the issue is.
> 
> I'm also looking into passing FATE and adding additional test cases
> to
> cover this new code. The documentation is helpful, but there's still
> a
> steep learning curve to get all this put together.
> 
> Any help would be greatly appreciated.
> 
> On Sat, Oct 12, 2024 at 1:59 AM Tomas Härdin  wrote:
> 
> > ons 2024-10-09 klockan 20:08 -0600 skrev Devon Sookhoo:
> > > Sounds good, I'll look into adding rawvideo to the list of
> > > movcodec_tags.
> > > 
> > > Looking at the AVPixFmtDescriptor, I noticed:
> > > AVComponentDescriptor
> > > comp[4]; Does this line limit the component count to only four?
> > > Encoding
> > > video with many components is an important use case.
> > 
> > I am aware of no pixel format with more than 4 components so
> > probably.
> > I've never seen hyperspectral imagery used in this project. I've
> > worked
> > with it before though
> > 
> > > Complex pixels are used in applications that involve both
> > > amplitude
> > > and
> > > phase information, particularly in signal processing and imaging
> > > techniques
> > > where the Fourier transform is frequently applied. Examples
> > > include
> > > Synthetic Aperture Radar (SAR), MRI scans, and radio astronomy.
> > 
> > Yep, suspected as much
> > 
> > /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".
> > 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] lavf/mxfdec: Set a scan direction explicitly

[Tomas Härdin]

mån 2024-10-14 klockan 16:46 +0200 skrev Tomas Härdin:
> Passes fate-mxf

Will push in a few days

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

[FFmpeg-devel] [PATCH 2/2] vulkan: enable selecting a compatible representation of format

[Lynne via ffmpeg-devel]

When using **integer** images inside shaders, it turns out
that conversion doesn't automatically happen, but we need to
explicitly use the imageviews to get the image exposed as
a suitable representation for the shader.

Finally enables bitexact image representations.
---
 libavfilter/vf_nlmeans_vulkan.c |  4 +-
 libavfilter/vulkan_filter.c | 14 ++---
 libavutil/vulkan.c  | 98 -
 libavutil/vulkan.h  |  2 +-
 4 files changed, 106 insertions(+), 12 deletions(-)

diff --git a/libavfilter/vf_nlmeans_vulkan.c b/libavfilter/vf_nlmeans_vulkan.c
index 68393273d8..5b0f137a40 100644
--- a/libavfilter/vf_nlmeans_vulkan.c
+++ b/libavfilter/vf_nlmeans_vulkan.c
@@ -854,7 +854,7 @@ static int nlmeans_vulkan_filter_frame(AVFilterLink *link, 
AVFrame *in)
 ws_buf = NULL;
 
 /* Input frame prep */
-RET(ff_vk_create_imageviews(vkctx, exec, in_views, in));
+RET(ff_vk_create_imageviews(vkctx, exec, in_views, in, FF_VK_REP_FLOAT));
 ff_vk_frame_barrier(vkctx, exec, in, img_bar, &nb_img_bar,
 VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
 VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT,
@@ -863,7 +863,7 @@ static int nlmeans_vulkan_filter_frame(AVFilterLink *link, 
AVFrame *in)
 VK_QUEUE_FAMILY_IGNORED);
 
 /* Output frame prep */
-RET(ff_vk_create_imageviews(vkctx, exec, out_views, out));
+RET(ff_vk_create_imageviews(vkctx, exec, out_views, out, FF_VK_REP_FLOAT));
 ff_vk_frame_barrier(vkctx, exec, out, img_bar, &nb_img_bar,
 VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
 VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT,
diff --git a/libavfilter/vulkan_filter.c b/libavfilter/vulkan_filter.c
index 85665b4d42..bdbebb3cb2 100644
--- a/libavfilter/vulkan_filter.c
+++ b/libavfilter/vulkan_filter.c
@@ -257,7 +257,7 @@ int ff_vk_filter_process_simple(FFVulkanContext *vkctx, 
FFVkExecPool *e,
 RET(ff_vk_exec_add_dep_frame(vkctx, exec, out_f,
  VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
  VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
-RET(ff_vk_create_imageviews(vkctx, exec, out_views, out_f));
+RET(ff_vk_create_imageviews(vkctx, exec, out_views, out_f, 
FF_VK_REP_FLOAT));
 ff_vk_shader_update_img_array(vkctx, exec, shd, out_f, out_views, 0, 
!!in_f,
   VK_IMAGE_LAYOUT_GENERAL,
   VK_NULL_HANDLE);
@@ -265,7 +265,7 @@ int ff_vk_filter_process_simple(FFVulkanContext *vkctx, 
FFVkExecPool *e,
 RET(ff_vk_exec_add_dep_frame(vkctx, exec, in_f,
  VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
  VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
-RET(ff_vk_create_imageviews(vkctx, exec, in_views,  in_f));
+RET(ff_vk_create_imageviews(vkctx, exec, in_views,  in_f, 
FF_VK_REP_FLOAT));
 ff_vk_shader_update_img_array(vkctx, exec, shd,  in_f,  in_views, 0, 0,
   
VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL,
   sampler);
@@ -336,9 +336,9 @@ int ff_vk_filter_process_2pass(FFVulkanContext *vkctx, 
FFVkExecPool *e,
  VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
  VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
 
-RET(ff_vk_create_imageviews(vkctx, exec, in_views,  in));
-RET(ff_vk_create_imageviews(vkctx, exec, tmp_views, tmp));
-RET(ff_vk_create_imageviews(vkctx, exec, out_views, out));
+RET(ff_vk_create_imageviews(vkctx, exec, in_views,  in, FF_VK_REP_FLOAT));
+RET(ff_vk_create_imageviews(vkctx, exec, tmp_views, tmp, FF_VK_REP_FLOAT));
+RET(ff_vk_create_imageviews(vkctx, exec, out_views, out, FF_VK_REP_FLOAT));
 
 ff_vk_frame_barrier(vkctx, exec, in, img_bar, &nb_img_bar,
 VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
@@ -418,12 +418,12 @@ int ff_vk_filter_process_Nin(FFVulkanContext *vkctx, 
FFVkExecPool *e,
 RET(ff_vk_exec_add_dep_frame(vkctx, exec, out,
  VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
  VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
-RET(ff_vk_create_imageviews(vkctx, exec, out_views, out));
+RET(ff_vk_create_imageviews(vkctx, exec, out_views, out, FF_VK_REP_FLOAT));
 for (int i = 0; i < nb_in; i++) {
 RET(ff_vk_exec_add_dep_frame(vkctx, exec, in[i],
  VK_PIPELINE_STAGE_2_ALL_COMMANDS_BIT,
  VK_PIPELINE_STAGE_2_COMPUTE_SHADER_BIT));
-RET(ff_vk_create_imageviews(vkctx, exec, in_views[i], in[i]));
+RET(ff_vk_create_imageviews(vkctx, exec, in_views[i], in[i], 
FF_VK_REP_FLOAT));
 }
 
 /* Update descriptor sets */
diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
index 346ed97953..11884fbd50 100644
--- a

[FFmpeg-devel] [PATCH 1/2] hwcontext_vulkan: always enable MUTABLE creation flag

[Lynne via ffmpeg-devel]

We need it even for something as simple as bitexact opening
of images.
---
 libavutil/hwcontext_vulkan.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index 6a5f1325ac..dec5fdaa46 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -2726,11 +2726,11 @@ static int vulkan_frames_init(AVHWFramesContext *hwfc)
 !(hwctx->usage & 
VK_IMAGE_USAGE_VIDEO_DECODE_DST_BIT_KHR)));
 int sampleable = hwctx->usage & (VK_IMAGE_USAGE_SAMPLED_BIT |
  VK_IMAGE_USAGE_STORAGE_BIT);
+hwctx->img_flags = VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT;
 if (sampleable && !is_lone_dpb) {
-hwctx->img_flags = VK_IMAGE_CREATE_ALIAS_BIT;
+hwctx->img_flags |= VK_IMAGE_CREATE_ALIAS_BIT;
 if ((fmt->vk_planes > 1) && (hwctx->format[0] == fmt->vkf))
-hwctx->img_flags |= VK_IMAGE_CREATE_MUTABLE_FORMAT_BIT |
-VK_IMAGE_CREATE_EXTENDED_USAGE_BIT;
+hwctx->img_flags |= VK_IMAGE_CREATE_EXTENDED_USAGE_BIT;
 }
 }
 
-- 
2.45.2.753.g447d99e1c3b
___
ffmpeg-devel mailing list
ffmpeg-devel@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] AVFilter

[Niklas Haas]

On Tue, 15 Oct 2024 18:12:21 +0200 Michael Niedermayer  
wrote:
> Hi all
>
> This is a quick RFC about peoples oppinions on AVFilter
>
> The question: Should anyone be able to write a filter (which
> other people can use) ?
> Or should only we be able to add filters ?

As a compromise, we could allow external filters with a more strict ABI
requirement, i.e. the filter must be built against the exact same version of
libavfilter. That way, we could still change the API as needed, without
needing to maintain long-term ABI compatibility.

I think that from a corrent PoV, the status quo of external filters being
added out-of-tree at build time is fine, and maybe we could make that process
a bit easier.

Another thing to mention is that a lot of downstream use cases for custom
filters could be solved by adding a single proprammable "custom" filter that
calls a user-provided callback function. This filter could be given a more
limited but stable API, without limiting our ability to change the internal
details. Think of something like buffersink/buffersrc, but for custom filters.

>
> (This relates to what parts of the API are publically accessable)
>
> So whats the point of this RFC ?
>
> If we want a public API that allows writing filters then work on the API
> has to be compatible with that direction.
>
> "compatible" for example would be, "Adding whats missing to the public API"
> or "deprecating existing API and writing a better API that makes all needed
> parts public"
>
> "incompatible" for example is "making bits and pieces private that are needed
> by filters
>
> Some of the currently pending patches seem to fall into the "incompatible"
> category, while iam not sure what peoples oppinions is on the direction
> of AVfilter, which is why iam bringing this up
>
> Thx
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is a danger to trust the dream we wish for rather than
> the science we have, -- Dr. Kenneth Brown
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 4/4] avcodec/vvcdec: remove unused tb_pos_x0 and tb_pos_y0

[Nuo Mi]

On Fri, Oct 4, 2024 at 10:31 PM Nuo Mi  wrote:

> This change will save approximately 531 MB for an 8K clip when processed
> with 16 threads.
>
Applied.

> The calculation is as follows:
> 7680 * 4320 * sizeof(int) * 2 * 2 * 16 / (4 * 4).
> ---
>  libavcodec/vvc/ctu.c | 10 +++---
>  libavcodec/vvc/dec.c |  2 --
>  libavcodec/vvc/dec.h |  2 --
>  3 files changed, 3 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/vvc/ctu.c b/libavcodec/vvc/ctu.c
> index e49976c66b..1e06119cfd 100644
> --- a/libavcodec/vvc/ctu.c
> +++ b/libavcodec/vvc/ctu.c
> @@ -38,7 +38,7 @@ typedef enum VVCModeType {
>  MODE_TYPE_INTRA,
>  } VVCModeType;
>
> -static void set_tb_pos(const VVCFrameContext *fc, const TransformBlock
> *tb)
> +static void set_tb_size(const VVCFrameContext *fc, const TransformBlock
> *tb)
>  {
>  const int x_tb  = tb->x0 >> MIN_TU_LOG2;
>  const int y_tb  = tb->y0 >> MIN_TU_LOG2;
> @@ -50,10 +50,6 @@ static void set_tb_pos(const VVCFrameContext *fc, const
> TransformBlock *tb)
>
>  for (int y = y_tb; y < end; y++) {
>  const int off = y * fc->ps.pps->min_tu_width + x_tb;
> -for (int i = 0; i < width; i++) {
> -fc->tab.tb_pos_x0[is_chroma][off + i] = tb->x0;
> -fc->tab.tb_pos_y0[is_chroma][off + i] = tb->y0;
> -}
>  memset(fc->tab.tb_width [is_chroma] + off, tb->tb_width,  width);
>  memset(fc->tab.tb_height[is_chroma] + off, tb->tb_height, width);
>  }
> @@ -397,7 +393,7 @@ static int hls_transform_unit(VVCLocalContext *lc, int
> x0, int y0,int tu_width,
>  set_tb_tab(fc->tab.tu_coded_flag[tb->c_idx],
> tu->coded_flag[tb->c_idx], fc, tb);
>  }
>  if (tb->c_idx != CR)
> -set_tb_pos(fc, tb);
> +set_tb_size(fc, tb);
>  if (tb->c_idx == CB)
>  set_tb_tab(fc->tab.tu_joint_cbcr_residual_flag,
> tu->joint_cbcr_residual_flag, fc, tb);
>  }
> @@ -514,7 +510,7 @@ static int skipped_transform_tree(VVCLocalContext *lc,
> int x0, int y0,int tu_wid
>  for (int i = c_start; i < c_end; i++) {
>  TransformBlock *tb = add_tb(tu, lc, x0, y0, tu_width >>
> sps->hshift[i], tu_height >> sps->vshift[i], i);
>  if (i != CR)
> -set_tb_pos(fc, tb);
> +set_tb_size(fc, tb);
>  }
>  }
>
> diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
> index 13ca752eec..9b7afe4c38 100644
> --- a/libavcodec/vvc/dec.c
> +++ b/libavcodec/vvc/dec.c
> @@ -207,8 +207,6 @@ static void min_tu_nz_tl_init(TabList *l,
> VVCFrameContext *fc)
>  tl_init(l, 0, changed);
>
>  for (int i = LUMA; i <= CHROMA; i++) {
> -TL_ADD(tb_pos_x0[i], pic_size_in_min_tu);
> -TL_ADD(tb_pos_y0[i], pic_size_in_min_tu);
>  TL_ADD(tb_width[i],  pic_size_in_min_tu);
>  TL_ADD(tb_height[i], pic_size_in_min_tu);
>  }
> diff --git a/libavcodec/vvc/dec.h b/libavcodec/vvc/dec.h
> index 159c60942b..7254b515fd 100644
> --- a/libavcodec/vvc/dec.h
> +++ b/libavcodec/vvc/dec.h
> @@ -172,8 +172,6 @@ typedef struct VVCFrameContext {
>
>  uint8_t *tu_coded_flag[VVC_MAX_SAMPLE_ARRAYS];  ///<
> tu_y_coded_flag[][],  tu_cb_coded_flag[][],  tu_cr_coded_flag[][]
>  uint8_t *tu_joint_cbcr_residual_flag;   ///<
> tu_joint_cbcr_residual_flag[][]
> -int *tb_pos_x0[2];
> -int *tb_pos_y0[2];
>  uint8_t *tb_width[2];
>  uint8_t *tb_height[2];
>  uint8_t *pcmf[2];
> --
> 2.34.1
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avcodec/vvc/thread: Check frame to be non NULL

[Nuo Mi]

On Mon, Oct 14, 2024 at 11:25 PM Nuo Mi  wrote:

> Fixes: NULL pointer dereference
> Fixes:
> 71303/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VVC_fuzzer-4875859050168320
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Reported-by
> :
> Michael Niedermayer 
>
will apply.
Thank you

> ---
>  libavcodec/vvc/dec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
> index edf2607f50..522fa8416e 100644
> --- a/libavcodec/vvc/dec.c
> +++ b/libavcodec/vvc/dec.c
> @@ -1000,7 +1000,7 @@ static int vvc_decode_frame(AVCodecContext *avctx,
> AVFrame *output,
>  if (ret < 0)
>  return ret;
>
> -if (!fc->ft)
> +if (!fc->ft || !fc->ref)
>  return avpkt->size;
>
>  ret = submit_frame(s, fc, output, got_output);
> --
> 2.34.1
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [Uncompressed MP4] RFC - Draft Encoder

[Devon Sookhoo]

With this patch, I can generate an uncompressed mp4 without specifying the
-c:v rawvideo option:

$ ffmpeg  -i input.mp4  -c:v rawvideo  -pix_fmt rgb24  output.mp4

Originally, it was failing the mux.c validate_codec_tag() function and
never reached mov_get_rawvideo_codec_tag(). I found the following
init_muxer() comment useful:
// the current rawvideo encoding system ends up setting
// the wrong codec_tag for avi/mov, we override it here

On Wed, Oct 16, 2024 at 4:11 AM Tomas Härdin  wrote:

> Have a look at mov_get_rawvideo_codec_tag()
>
> /Tomas
>
> tis 2024-10-15 klockan 08:17 -0600 skrev Devon Sookhoo:
> > This updated patch registers the 'uncv' tag in the isom_tags.c
> > ff_codec_movvideo_tags[] list. However, I still need to specify the
> > tag
> > with the "-tag:v uncv" option. I hoped this change would set 'uncv'
> > as the
> > default tag for raw mp4 video, but I'm not sure what the issue is.
> >
> > I'm also looking into passing FATE and adding additional test cases
> > to
> > cover this new code. The documentation is helpful, but there's still
> > a
> > steep learning curve to get all this put together.
> >
> > Any help would be greatly appreciated.
> >
> > On Sat, Oct 12, 2024 at 1:59 AM Tomas Härdin  wrote:
> >
> > > ons 2024-10-09 klockan 20:08 -0600 skrev Devon Sookhoo:
> > > > Sounds good, I'll look into adding rawvideo to the list of
> > > > movcodec_tags.
> > > >
> > > > Looking at the AVPixFmtDescriptor, I noticed:
> > > > AVComponentDescriptor
> > > > comp[4]; Does this line limit the component count to only four?
> > > > Encoding
> > > > video with many components is an important use case.
> > >
> > > I am aware of no pixel format with more than 4 components so
> > > probably.
> > > I've never seen hyperspectral imagery used in this project. I've
> > > worked
> > > with it before though
> > >
> > > > Complex pixels are used in applications that involve both
> > > > amplitude
> > > > and
> > > > phase information, particularly in signal processing and imaging
> > > > techniques
> > > > where the Fourier transform is frequently applied. Examples
> > > > include
> > > > Synthetic Aperture Radar (SAR), MRI scans, and radio astronomy.
> > >
> > > Yep, suspected as much
> > >
> > > /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".
> > >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@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".
>


0001-Encode-RGB-interleaved-8-bit-uncompressed-mp4.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 5/5] libavcodec/ffv1: Support storing LSB raw

[Michael Niedermayer]

On Wed, Oct 16, 2024 at 03:26:39PM +0200, Michael Niedermayer wrote:
> This makes a 16bit RGB raw sample 25% faster at a 2% loss of compression with 
> rawlsb=4
> 
> Please test and comment
> 
> This stores the LSB through non binary range coding, this is simpler than 
> using a
> separate coder
> For cases where range coding is not wanted its probably best to use golomb 
> rice
> for everything.
> 
> We also pass the LSB through the decorrelation and context stages (which is 
> basically free)
> this leads to slightly better compression than separating them earlier.
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/ffv1.h |  2 ++
>  libavcodec/ffv1_template.c| 19 ++-
>  libavcodec/ffv1dec.c  |  2 ++
>  libavcodec/ffv1dec_template.c | 16 +---
>  libavcodec/ffv1enc.c  | 15 ++-
>  libavcodec/ffv1enc_template.c | 17 +++--
>  6 files changed, 56 insertions(+), 15 deletions(-)

3rd implemantation :)
you might ask why i implement this 4?! times
Heres why: (tests done with 4 rawlsb bits, 16bit per sample input)

The original (no decompression supported, bits riped out before context model 
and decorrelation, seperate buffer)
-rw-r- 1 michael michael   91403202 Oct 15 22:48 film4st.nut

I dont remember
-rw-r- 1 michael michael   91253765 Oct 15 23:14 film4st-new.nut

bits extracted after decorrelation and context model, interleaved range coder, 
simple but not efficient rangecoder implemantation
-rw-r- 1 michael michael   91080109 Oct 16 00:14 film4st-new2.nut

This current, bits extracted after decorrelation and context model, simplest 
and most efficient range coder implemantation
-rw-r- 1 michael michael   90996813 Oct 16 15:14 film4st-new3.nut
same but with quantization table 1
-rw-r- 1 michael michael   89883371 Oct 16 15:50 film4st-new3q1.nut

Heres the reference without rawlsb:
-rw-r- 1 michael michael   88090676 Oct 15 22:49 film0st.nut
-rw-r- 1 michael michael   88168254 Oct 16 15:50 film0st-q1.nut

So this implemantation so far performs best and is also very simple

thx

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

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


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

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

Re: [FFmpeg-devel] [PATCH] lavc/vvc: Validate subpartitioning structure

[Nuo Mi]

On Tue, Oct 15, 2024 at 7:54 AM Frank Plowman  wrote:

> Thank you for your reply.
>
> On 14/10/2024 16:16, Nuo Mi wrote:
> > On Mon, Oct 14, 2024 at 3:14 AM Frank Plowman 
> wrote:
> >
> >> On 13/10/2024 05:43, Nuo Mi wrote:
> >>> On Sun, Oct 6, 2024 at 6:49 AM Frank Plowman 
> >> wrote:
> >>>
>  H.266 (V3) section 6.3.3 dictates that the division of the picture
> into
>  subpictures must be exhaustive and mutually exclusive, i.e. that each
>  CTU "belongs to" one and only one subpicture.  In most cases this is
>  guaranteed by the syntax, but in the case sps_subpic_same_size_flag=0,
>  we must check this is true ourselves.
> 
>  Signed-off-by: Frank Plowman 
>  ---
>   libavcodec/cbs_h266_syntax_template.c | 46
> +--
>   1 file changed, 44 insertions(+), 2 deletions(-)
> 
>  diff --git a/libavcodec/cbs_h266_syntax_template.c
>  b/libavcodec/cbs_h266_syntax_template.c
>  index b4165b43b3..822ee26f46 100644
>  --- a/libavcodec/cbs_h266_syntax_template.c
>  +++ b/libavcodec/cbs_h266_syntax_template.c
>  @@ -1191,7 +1191,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx,
>  RWContext *rw,
>  win_left_edge_ctus >
>  current->sps_subpic_ctu_top_left_x[i]
>  ? win_left_edge_ctus -
>  current->sps_subpic_ctu_top_left_x[i]
>  : 0,
>  -   MAX_UINT_BITS(wlen), 1, i);
>  +   tmp_width_val -
>  current->sps_subpic_ctu_top_left_x[i] - 1, 1, i);
>   } else {
>   infer(sps_subpic_width_minus1[i],
> tmp_width_val -
>  @@ -1208,7 +1208,7 @@ static int FUNC(sps)(CodedBitstreamContext *ctx,
>  RWContext *rw,
>  win_top_edge_ctus >
>  current->sps_subpic_ctu_top_left_y[i]
>  ? win_top_edge_ctus -
>  current->sps_subpic_ctu_top_left_y[i]
>  : 0,
>  -   MAX_UINT_BITS(hlen), 1, i);
>  +   tmp_height_val -
>  current->sps_subpic_ctu_top_left_y[i] - 1, 1, i);
>   } else {
>   infer(sps_subpic_height_minus1[i],
> tmp_height_val -
>  @@ -1242,6 +1242,48 @@ static int FUNC(sps)(CodedBitstreamContext
> *ctx,
>  RWContext *rw,
> 
> >> infer(sps_loop_filter_across_subpic_enabled_flag[i],
>  0);
>   }
>   }
>  +// If the subpic partitioning structure is signalled
>  explicitly,
>  +// validate it constitutes an exhaustive and mutually
>  exclusive
>  +// coverage of the picture, per 6.3.3.  If the
> partitioning
>  is not
>  +// provided explicitly, then it is ensured by the syntax
> >> and
>  we need
>  +// not check.
>  +if (!current->sps_subpic_same_size_flag) {
>  +char *ctu_in_subpic = av_mallocz(tmp_width_val *
>  tmp_height_val);
> 
> >>> Thank you for the patch.
> >>> The slices will cover the entire subpicture without any overlap, and
> the
> >>> CTUs will cover the entire slice without any overlap.
> >>> We will check num_slices_in_subpic[] in FUNC(pps). How about summing
> all
> >>> the values in num_slices_in_subpic[] and verifying if it equals
> >>> sps_num_subpics_minus1 + 1?
> >>
> >> This is not sufficient in the case pps_single_slice_per_subpic flag is
> >> 1.  When this flag is 1, the slice layout is the same as the subpicture
> >> layout and so your suggested condition is always satisfied.  In this
> >> case, we have no guarantees that the slice layout is valid however.
> >>
> > We can only determine this after decoding all slice headers. see
> > https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/vvc/ps.c#L1218
>
> I'm sorry I'm not sure I follow exactly.  What can we not determine
> until decoding slice headers?  pps_single_slice_per_subpic is a PPS
> flag.  Also, in the cases I have which have issues with invalid
> subpic/slice structures, we start hitting bugs and crashes in
>
Could you please share the clip with me?

> frame_setup, for example in pps_slice_map, before ff_vvc_decode_sh has
> been called even.
>
Sorry for the confussion.
We can only know how many CTUs in a slice after we decode the slice header.


> > The task_init_parse function will ensure that a single CTU does not
> belong
> > to two slices.
>
> Looking at the implementation of task_init_parse, I see it checks a
> single task object is not initialised multiple times, but the location
> of this CTU is simply supplied by the caller and already depends on the
> slice structure (ep->ctu_{start,end}, ctb_addr_in_curr_slice), which may
> be in

[FFmpeg-devel] [PATCH 3/5] avcodec/rangecoder: Move refill check out of refill() function

[Michael Niedermayer]

If the function is not inlined, this is more efficient. Also
it allows calling refill() without the check

Signed-off-by: Michael Niedermayer 
---
 libavcodec/rangecoder.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index 2248161bca1..da13c453edd 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -112,7 +112,6 @@ static inline void put_rac(RangeCoder *c, uint8_t *const 
state, int bit)
 
 static inline void refill(RangeCoder *c)
 {
-if (c->range < 0x100) {
 c->range <<= 8;
 c->low   <<= 8;
 if (c->bytestream < c->bytestream_end) {
@@ -120,7 +119,6 @@ static inline void refill(RangeCoder *c)
 c->bytestream++;
 } else
 c->overread ++;
-}
 }
 
 static inline int get_rac(RangeCoder *c, uint8_t *const state)
@@ -130,13 +128,15 @@ static inline int get_rac(RangeCoder *c, uint8_t *const 
state)
 c->range -= range1;
 if (c->low < c->range) {
 *state = c->zero_state[*state];
-refill(c);
+if (c->range < 0x100)
+refill(c);
 return 0;
 } else {
 c->low  -= c->range;
 *state   = c->one_state[*state];
 c->range = range1;
-refill(c);
+if (c->range < 0x100)
+refill(c);
 return 1;
 }
 }
-- 
2.47.0

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

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

[FFmpeg-devel] [PATCH 2/5] avcodec/rangecoder: Do not loop renormalization

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/rangecoder.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index 110908d6bdd..2248161bca1 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -106,7 +106,7 @@ static inline void put_rac(RangeCoder *c, uint8_t *const 
state, int bit)
 *state   = c->one_state[*state];
 }
 
-while (c->range < 0x100)
+if (c->range < 0x100)
 renorm_encoder(c);
 }
 
-- 
2.47.0

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

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

[FFmpeg-devel] [PATCH 4/5] avcodec/rangecoder: Implement reading and writing upto 8 bits raw

[Michael Niedermayer]

This is much faster than doing 1 bit and updating a state

Signed-off-by: Michael Niedermayer 
---
 libavcodec/rangecoder.h   | 53 +++
 libavcodec/tests/rangecoder.c | 13 +
 2 files changed, 66 insertions(+)

diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index da13c453edd..4cfdd2fdbe9 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -82,6 +82,28 @@ static inline void renorm_encoder(RangeCoder *c)
 c->range <<= 8;
 }
 
+static inline void renorm_encoder_raw(RangeCoder *c, int extra)
+{
+if (c->outstanding_byte < 0) {
+c->outstanding_byte = c->low >> 8 + extra;
+} else if (c->low <= 0xFF00 << extra) {
+*c->bytestream++ = c->outstanding_byte;
+for (; c->outstanding_count; c->outstanding_count--)
+*c->bytestream++ = 0xFF;
+c->outstanding_byte = c->low >> 8 + extra;
+} else if (c->low >= 0x1 << extra) {
+*c->bytestream++ = c->outstanding_byte + 1;
+for (; c->outstanding_count; c->outstanding_count--)
+*c->bytestream++ = 0x00;
+c->outstanding_byte = (c->low >> 8 + extra) & 0xFF;
+} else {
+c->outstanding_count++;
+}
+
+c->low = (c->low & ((1 << 8 + extra) - 1)) << 8 - extra;
+c->range <<= 8 - extra;
+}
+
 static inline int get_rac_count(RangeCoder *c)
 {
 int x = c->bytestream - c->bytestream_start + c->outstanding_count;
@@ -110,6 +132,21 @@ static inline void put_rac(RangeCoder *c, uint8_t *const 
state, int bit)
 renorm_encoder(c);
 }
 
+static inline void put_rac_raw(RangeCoder *c, int bits, int len)
+{
+int r = c->range >> len;
+av_assert2(len <= 8);
+av_assert2(bits >> len == 0);
+
+if (r < 0x100) {
+c->low = (c->low << len) + c->range * bits;
+renorm_encoder_raw(c, len);
+} else {
+c->low += r * bits;
+c->range = r;
+}
+}
+
 static inline void refill(RangeCoder *c)
 {
 c->range <<= 8;
@@ -141,4 +178,20 @@ static inline int get_rac(RangeCoder *c, uint8_t *const 
state)
 }
 }
 
+static inline int get_rac_raw(RangeCoder *c, int len)
+{
+int bits;
+int r = c->range >> len;
+av_assert2(len <= 8);
+
+if (r < 0x100) {
+refill(c);
+r = c->range >> len;
+}
+bits = c->low / r;
+c->low -= r * bits;
+c->range = r;
+return bits;
+}
+
 #endif /* AVCODEC_RANGECODER_H */
diff --git a/libavcodec/tests/rangecoder.c b/libavcodec/tests/rangecoder.c
index fd858535a5b..7634953585d 100644
--- a/libavcodec/tests/rangecoder.c
+++ b/libavcodec/tests/rangecoder.c
@@ -76,6 +76,11 @@ int main(void)
 for (i = 0; i < SIZE; i++)
 put_rac(&c, state, r[i] & 1);
 
+for (i = 0; i < SIZE; i++) {
+int len = r[i++] % 7 + 1;
+put_rac_raw(&c, r[i]&((1

[FFmpeg-devel] [PATCH 1/5] avcodec/rangecoder: only perform renorm check/loop for callers that need it

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/rangecoder.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index 89d178ac314..110908d6bdd 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -62,7 +62,6 @@ void ff_build_rac_states(RangeCoder *c, int factor, int 
max_p);
 static inline void renorm_encoder(RangeCoder *c)
 {
 // FIXME: optimize
-while (c->range < 0x100) {
 if (c->outstanding_byte < 0) {
 c->outstanding_byte = c->low >> 8;
 } else if (c->low <= 0xFF00) {
@@ -81,7 +80,6 @@ static inline void renorm_encoder(RangeCoder *c)
 
 c->low = (c->low & 0xFF) << 8;
 c->range <<= 8;
-}
 }
 
 static inline int get_rac_count(RangeCoder *c)
@@ -108,7 +106,8 @@ static inline void put_rac(RangeCoder *c, uint8_t *const 
state, int bit)
 *state   = c->one_state[*state];
 }
 
-renorm_encoder(c);
+while (c->range < 0x100)
+renorm_encoder(c);
 }
 
 static inline void refill(RangeCoder *c)
-- 
2.47.0

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

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

[FFmpeg-devel] [PATCH 5/5] libavcodec/ffv1: Support storing LSB raw

[Michael Niedermayer]

This makes a 16bit RGB raw sample 25% faster at a 2% loss of compression with 
rawlsb=4

Please test and comment

This stores the LSB through non binary range coding, this is simpler than using 
a
separate coder
For cases where range coding is not wanted its probably best to use golomb rice
for everything.

We also pass the LSB through the decorrelation and context stages (which is 
basically free)
this leads to slightly better compression than separating them earlier.

Signed-off-by: Michael Niedermayer 
---
 libavcodec/ffv1.h |  2 ++
 libavcodec/ffv1_template.c| 19 ++-
 libavcodec/ffv1dec.c  |  2 ++
 libavcodec/ffv1dec_template.c | 16 +---
 libavcodec/ffv1enc.c  | 15 ++-
 libavcodec/ffv1enc_template.c | 17 +++--
 6 files changed, 56 insertions(+), 15 deletions(-)

diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
index 4f5a8ab2be7..02bfc33f680 100644
--- a/libavcodec/ffv1.h
+++ b/libavcodec/ffv1.h
@@ -83,6 +83,7 @@ typedef struct FFV1SliceContext {
 int slice_coding_mode;
 int slice_rct_by_coef;
 int slice_rct_ry_coef;
+int rawlsb;
 
 // RefStruct reference, array of MAX_PLANES elements
 PlaneContext *plane;
@@ -139,6 +140,7 @@ typedef struct FFV1Context {
 int key_frame_ok;
 int context_model;
 int qtable;
+int rawlsb;
 
 int bits_per_raw_sample;
 int packed_at_lsb;
diff --git a/libavcodec/ffv1_template.c b/libavcodec/ffv1_template.c
index abb90a12e49..10206702ee8 100644
--- a/libavcodec/ffv1_template.c
+++ b/libavcodec/ffv1_template.c
@@ -30,24 +30,25 @@ static inline int RENAME(predict)(TYPE *src, TYPE *last)
 }
 
 static inline int RENAME(get_context)(const int16_t 
quant_table[MAX_CONTEXT_INPUTS][MAX_QUANT_TABLE_SIZE],
-  TYPE *src, TYPE *last, TYPE *last2)
+  TYPE *src, TYPE *last, TYPE *last2, int 
rawlsb)
 {
 const int LT = last[-1];
 const int T  = last[0];
 const int RT = last[1];
 const int L  = src[-1];
+const int rawoff = (1<> 1;
 
 if (quant_table[3][127] || quant_table[4][127]) {
 const int TT = last2[0];
 const int LL = src[-2];
-return quant_table[0][(L - LT) & MAX_QUANT_TABLE_MASK] +
-   quant_table[1][(LT - T) & MAX_QUANT_TABLE_MASK] +
-   quant_table[2][(T - RT) & MAX_QUANT_TABLE_MASK] +
-   quant_table[3][(LL - L) & MAX_QUANT_TABLE_MASK] +
-   quant_table[4][(TT - T) & MAX_QUANT_TABLE_MASK];
+return quant_table[0][(L - LT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[1][(LT - T + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[2][(T - RT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[3][(LL - L + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[4][(TT - T + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK];
 } else
-return quant_table[0][(L - LT) & MAX_QUANT_TABLE_MASK] +
-   quant_table[1][(LT - T) & MAX_QUANT_TABLE_MASK] +
-   quant_table[2][(T - RT) & MAX_QUANT_TABLE_MASK];
+return quant_table[0][(L - LT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[1][(LT - T + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[2][(T - RT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK];
 }
 
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 5c099e49ad4..fc96bfb4cea 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -249,6 +249,8 @@ static int decode_slice_header(const FFV1Context *f,
 return AVERROR_INVALIDDATA;
 }
 }
+if (f->micro_version > 2)
+sc->rawlsb = get_symbol(c, state, 0);
 }
 
 return 0;
diff --git a/libavcodec/ffv1dec_template.c b/libavcodec/ffv1dec_template.c
index 2da6bd935dc..dbdcad7768e 100644
--- a/libavcodec/ffv1dec_template.c
+++ b/libavcodec/ffv1dec_template.c
@@ -60,8 +60,13 @@ RENAME(decode_line)(FFV1Context *f, FFV1SliceContext *sc,
 return AVERROR_INVALIDDATA;
 }
 
-context = RENAME(get_context)(quant_table,
-  sample[1] + x, sample[0] + x, sample[1] 
+ x);
+if (sc->rawlsb) {
+context = RENAME(get_context)(quant_table,
+  sample[1] + x, sample[0] + x, 
sample[1] + x, sc->rawlsb);
+} else {
+context = RENAME(get_context)(quant_table,
+  sample[1] + x, sample[0] + x, 
sample[1] + x, 0);
+}
 if (context < 0) {
 context = -context;
 sign= 1;
@@ -71,7 +76,12 @@ RENAME(decode_line)(FFV1Context *f, FFV1SliceContext *sc,
 av_assert2(context < p->context_count);
 
 if (ac != AC_GOLOMB_RICE) {
-diff = get_symbol_inline(c, p->state[context], 1);
+   

Re: [FFmpeg-devel] [PATCH 5/5] libavcodec/ffv1: Support storing LSB raw

[Jerome Martinez]

Le 16/10/2024 à 15:54, Michael Niedermayer a écrit :

3rd implemantation :)
you might ask why i implement this 4?! times
Heres why: (tests done with 4 rawlsb bits, 16bit per sample input)


I tested on my side also including the speed as the goal is to avoid the 
speed cost of the LSB, with 6K content from scanner (analog input, last 
bits are more or less random).

Speed Compr
0,037x    0,471    No patch
0,051x    0,491    bitfield
0,046x    0,489    rangecoder

the 25% gain in the speed is clearly visible (actually it 27%  in my 
tests) with the bitfield version of storing LSB, but it is a lot less 
visible with the rangecoder version (the one from today):
There is a small 0.5% gain in size at the cost of 9% of speed, it is not 
worth it IMO.


I prefer by far your first version (really storing LSB as raw), it is 
fast as expected (25% less time) and adding the range coder creates 
something not really interesting (20% less time "only" for so little 
gain in size compared to 25%)

___
ffmpeg-devel mailing list
ffmpeg-devel@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] Make H.274 film grain support optional for H.264. Saves ~779kb.

[Niklas Haas]

On Mon, 14 Oct 2024 11:03:49 -0700 Dale Curtis  wrote:
> Any issues remaining with this patch? Thanks in advance for applying.
>
> - dale

I guess I'll apply it in 24h if there are no objections.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Make H.274 film grain support optional for H.264. Saves ~779kb.

[Lynne via ffmpeg-devel]

On 16/10/2024 14:06, Niklas Haas wrote:

On Mon, 14 Oct 2024 11:03:49 -0700 Dale Curtis  wrote:

Any issues remaining with this patch? Thanks in advance for applying.

- dale


I guess I'll apply it in 24h if there are no objections.


The dynamically allocated version, right?


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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/2] libavcodec/ffv1: Support storing LSB raw

[Michael Niedermayer]

On Wed, Oct 16, 2024 at 03:36:55PM +0200, Michael Niedermayer wrote:
> On Wed, Oct 16, 2024 at 02:13:35AM +0200, Lynne via ffmpeg-devel wrote:
> > On 16/10/2024 01:17, Michael Niedermayer wrote:
> > > This makes a 16bit RGB raw sample 25% faster at a 2% loss of compression 
> > > with rawlsb=4
> > > 
> > > Please test and comment
> > > 
> > > This stores the LSB through non binary range coding, this is simpler than 
> > > using a
> > > separate coder
> > > For cases where range coding is not wanted its probably best to use 
> > > golomb rice
> > > for everything.
> > > 
> > > We also pass the LSB through the decorrelation and context stages (which 
> > > is basically free)
> > > this leads to slightly better compression than separating them earlier.
> > > 
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >   libavcodec/ffv1.h |  2 ++
> > >   libavcodec/ffv1_template.c| 19 ++-
> > >   libavcodec/ffv1dec.c  |  2 ++
> > >   libavcodec/ffv1dec_template.c | 16 +---
> > >   libavcodec/ffv1enc.c  | 15 ++-
> > >   libavcodec/ffv1enc_template.c | 17 +++--
> > >   libavcodec/rangecoder.h   | 20 
> > >   libavcodec/tests/rangecoder.c |  9 +
> > >   8 files changed, 85 insertions(+), 15 deletions(-)
> [...]
> > > diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
> > > index 89d178ac314..d02a65fa7da 100644
> > > --- a/libavcodec/rangecoder.h
> > > +++ b/libavcodec/rangecoder.h
> > > @@ -111,6 +111,16 @@ static inline void put_rac(RangeCoder *c, uint8_t 
> > > *const state, int bit)
> > >   renorm_encoder(c);
> > >   }
> > > +static inline void put_rac_raw(RangeCoder *c, int bits, int len)
> > > +{
> > > +int r = c->range >> len;
> > > +
> > > +c->low += r * bits;
> > > +c->range = r;
> > > +
> > > +renorm_encoder(c);
> > > +}
> > > +
> > >   static inline void refill(RangeCoder *c)
> > >   {
> > >   if (c->range < 0x100) {
> > > @@ -142,4 +152,14 @@ static inline int get_rac(RangeCoder *c, uint8_t 
> > > *const state)
> > >   }
> > >   }
> > > +static inline int get_rac_raw(RangeCoder *c, int len)
> > > +{
> > > +int r = c->range >> len;
> > > +int bits = c->low / r;
> > > +c->low -= r * bits;
> > > +c->range = r;
> > > +refill(c);
> > > +return bits;
> > > +}
> > > +
> [...]
> >
> > You're interfering with the rangecoder by asking it to write very random
> > data in between each symbol.
> 
> the data is needed in that order for context modeling and decorrelation
> to work.
> 
> At least with the CPU implementation we have this gives the same speedup
> but better compression and its simpler code

btw, on a related note, whould something like this:

diff --git a/libavcodec/ffv1dec_template.c b/libavcodec/ffv1dec_template.c
index dbdcad7768e..5d4d51cc070 100644
--- a/libavcodec/ffv1dec_template.c
+++ b/libavcodec/ffv1dec_template.c
@@ -39,6 +39,8 @@ RENAME(decode_line)(FFV1Context *f, FFV1SliceContext *sc,
 if (is_input_end(c, gb, ac))
 return AVERROR_INVALIDDATA;

+c->range = 1slice_coding_mode == 1) {
 int i;
 for (x = 0; x < w; x++) {
diff --git a/libavcodec/ffv1enc_template.c b/libavcodec/ffv1enc_template.c
index 848328c70af..0a3cb8f28b9 100644
--- a/libavcodec/ffv1enc_template.c
+++ b/libavcodec/ffv1enc_template.c
@@ -40,6 +40,7 @@ RENAME(encode_line)(FFV1Context *f, FFV1SliceContext *sc,
 av_log(logctx, AV_LOG_ERROR, "encoded frame too large\n");
 return AVERROR_INVALIDDATA;
 }
+c->range = 1pb, 0) < w * 4) {
 av_log(logctx, AV_LOG_ERROR, "encoded frame too large\n");

help a GPU implementation ?
The idea here is to reduce the number of different states the range coder can 
be in
at the end of each line so the next line has fewer states to consider
but maybe iam totally wrong and misunderstanding the problem

Above change seems to cost maybe 0.1-0.2% compression on vsynth1 and vsynth2 
tests

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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/2] libavcodec/ffv1: Support storing LSB raw

[Michael Niedermayer]

On Wed, Oct 16, 2024 at 02:13:35AM +0200, Lynne via ffmpeg-devel wrote:
> On 16/10/2024 01:17, Michael Niedermayer wrote:
> > This makes a 16bit RGB raw sample 25% faster at a 2% loss of compression 
> > with rawlsb=4
> > 
> > Please test and comment
> > 
> > This stores the LSB through non binary range coding, this is simpler than 
> > using a
> > separate coder
> > For cases where range coding is not wanted its probably best to use golomb 
> > rice
> > for everything.
> > 
> > We also pass the LSB through the decorrelation and context stages (which is 
> > basically free)
> > this leads to slightly better compression than separating them earlier.
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >   libavcodec/ffv1.h |  2 ++
> >   libavcodec/ffv1_template.c| 19 ++-
> >   libavcodec/ffv1dec.c  |  2 ++
> >   libavcodec/ffv1dec_template.c | 16 +---
> >   libavcodec/ffv1enc.c  | 15 ++-
> >   libavcodec/ffv1enc_template.c | 17 +++--
> >   libavcodec/rangecoder.h   | 20 
> >   libavcodec/tests/rangecoder.c |  9 +
> >   8 files changed, 85 insertions(+), 15 deletions(-)
[...]
> > diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
> > index 89d178ac314..d02a65fa7da 100644
> > --- a/libavcodec/rangecoder.h
> > +++ b/libavcodec/rangecoder.h
> > @@ -111,6 +111,16 @@ static inline void put_rac(RangeCoder *c, uint8_t 
> > *const state, int bit)
> >   renorm_encoder(c);
> >   }
> > +static inline void put_rac_raw(RangeCoder *c, int bits, int len)
> > +{
> > +int r = c->range >> len;
> > +
> > +c->low += r * bits;
> > +c->range = r;
> > +
> > +renorm_encoder(c);
> > +}
> > +
> >   static inline void refill(RangeCoder *c)
> >   {
> >   if (c->range < 0x100) {
> > @@ -142,4 +152,14 @@ static inline int get_rac(RangeCoder *c, uint8_t 
> > *const state)
> >   }
> >   }
> > +static inline int get_rac_raw(RangeCoder *c, int len)
> > +{
> > +int r = c->range >> len;
> > +int bits = c->low / r;
> > +c->low -= r * bits;
> > +c->range = r;
> > +refill(c);
> > +return bits;
> > +}
> > +
[...]
>
> You're interfering with the rangecoder by asking it to write very random
> data in between each symbol.

the data is needed in that order for context modeling and decorrelation
to work.

At least with the CPU implementation we have this gives the same speedup
but better compression and its simpler code


> You should do what Opus does and write the rawbits in a separate buffer
> which gets merged at the very end.

I like more what h264 does with storing raw bits (get_cabac_bypass())
and given that h264 also works with much higher bitrates as a video codec
than opus as a audio codec, it seems the example is closer to our use case.


> 
> I think rather than doing this, you should instead simply permit golomb
> coding to be used on high bit-depths.

yes or rather, not "instead" but too.
We should permit golomb coding on high bit-depths.

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


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

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

[FFmpeg-devel] (No Subject)

[Cynthia via ffmpeg-devel]

>From d7863bab8e1028b6cfb3ce848e216e86ff00eca0 Mon Sep 17 00:00:00 2001
From: cynthia2006 
Date: Tue, 28 May 2024 22:03:50 +0530
Subject: [PATCH] lavc/mjpegdec: add option for ignorning malformed APPx
 segments
X-Unsent: 1
To: ffmpeg-devel@ffmpeg.org

A few cameras, namely Logitech C270 or similar produce MJPEG frames containing
malformed APP0 chunks, and as a result of which, FFmpeg spams stdout with

"[mjpeg @ 0xcoffeebabe] unable to decode APP fields: Invalid data found when 
processing input"

The issue is explained in full-detail here: 
https://stackoverflow.com/q/55439184.
TL;DR The second APP0 chunk is the culprit here.

Issue is mitigated if those segments are ignored. This patch adds a MJPEG 
decoder private
option `-allow_malformed_app` which if enabled, ignores those malformed APP0 
segments.

Signed-off-by: cynthia2006 
---
 libavcodec/mjpegdec.c | 5 +
 libavcodec/mjpegdec.h | 1 +
 2 files changed, 6 insertions(+)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 1481a7f285..b1e26044c0 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1863,6 +1863,9 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
 av_log(s->avctx, AV_LOG_WARNING, "skipping APPx (len=%"PRId32") 
for bayer-encoded image\n", len);
 skip_bits(&s->gb, len);
 return 0;
+} else if (s->allow_malformed_app) {
+skip_bits(&s->gb, len);
+return 0;
 } else
 return AVERROR_INVALIDDATA;
 }
@@ -2988,6 +2991,8 @@ static void decode_flush(AVCodecContext *avctx)
 static const AVOption options[] = {
 { "extern_huff", "Use external huffman table.",
   OFFSET(extern_huff), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
+{ "allow_malformed_app", "Allow (ignore) malformed APPx chunks.",
+  OFFSET(allow_malformed_app), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
 { NULL },
 };
 
diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
index 13c524d597..d7e4f88682 100644
--- a/libavcodec/mjpegdec.h
+++ b/libavcodec/mjpegdec.h
@@ -138,6 +138,7 @@ typedef struct MJpegDecodeContext {
 unsigned int ljpeg_buffer_size;
 
 int extern_huff;
+int allow_malformed_app;
 AVDictionary *exif_metadata;
 
 AVStereo3D *stereo3d; ///!< stereoscopic information (cached, since it is 
read before frame allocation)
-- 
2.45.1


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

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

Re: [FFmpeg-devel] [PATCH 10/20] swscale/output: add VYU444 output support

[Michael Niedermayer]

On Wed, Oct 09, 2024 at 02:03:28PM -0300, James Almer wrote:
> On 10/8/2024 4:56 PM, Michael Niedermayer wrote:
> > On Mon, Oct 07, 2024 at 09:29:45AM -0300, James Almer wrote:
> > > Signed-off-by: James Almer 
> > > ---
> > >   libswscale/output.c  | 43 
> > >   libswscale/utils.c   |  2 +-
> > >   tests/ref/fate/filter-pixdesc-vyu444 |  1 +
> > >   tests/ref/fate/filter-pixfmts-copy   |  1 +
> > >   tests/ref/fate/filter-pixfmts-crop   |  1 +
> > >   tests/ref/fate/filter-pixfmts-field  |  1 +
> > >   tests/ref/fate/filter-pixfmts-fieldorder |  1 +
> > >   tests/ref/fate/filter-pixfmts-hflip  |  1 +
> > >   tests/ref/fate/filter-pixfmts-il |  1 +
> > >   tests/ref/fate/filter-pixfmts-null   |  1 +
> > >   tests/ref/fate/filter-pixfmts-pad|  1 +
> > >   tests/ref/fate/filter-pixfmts-scale  |  1 +
> > >   tests/ref/fate/filter-pixfmts-transpose  |  1 +
> > >   tests/ref/fate/filter-pixfmts-vflip  |  1 +
> > >   14 files changed, 56 insertions(+), 1 deletion(-)
> > >   create mode 100644 tests/ref/fate/filter-pixdesc-vyu444
> > > 
> > > diff --git a/libswscale/output.c b/libswscale/output.c
> > > index a11bedde95..6716cfad34 100644
> > > --- a/libswscale/output.c
> > > +++ b/libswscale/output.c
> > > @@ -2931,6 +2931,46 @@ yuv2uyva_X_c(SwsContext *c, const int16_t 
> > > *lumFilter,
> > >   }
> > >   }
> > > +static void
> > > +yuv2vyu444_X_c(SwsContext *c, const int16_t *lumFilter,
> > > +   const int16_t **lumSrc, int lumFilterSize,
> > > +   const int16_t *chrFilter, const int16_t **chrUSrc,
> > > +   const int16_t **chrVSrc, int chrFilterSize,
> > > +   const int16_t **alpSrc, uint8_t *dest, int dstW, int y)
> > > +{
> > > +int i;
> > > +
> > > +for (i = 0; i < dstW; i++) {
> > > +int j;
> > > +int Y = 1 << 18, U = 1 << 18;
> > > +int V = 1 << 18;
> > > +
> > > +for (j = 0; j < lumFilterSize; j++)
> > > +Y += lumSrc[j][i] * lumFilter[j];
> > > +
> > > +for (j = 0; j < chrFilterSize; j++)
> > > +U += chrUSrc[j][i] * chrFilter[j];
> > > +
> > > +for (j = 0; j < chrFilterSize; j++)
> > > +V += chrVSrc[j][i] * chrFilter[j];
> > > +
> > > +Y >>= 19;
> > > +U >>= 19;
> > > +V >>= 19;
> > > +
> > > +if (Y  & 0x100)
> > > +Y = av_clip_uint8(Y);
> > > +if (U  & 0x100)
> > > +U = av_clip_uint8(U);
> > > +if (V  & 0x100)
> > > +V = av_clip_uint8(V);
> > > +
> > > +dest[3 * i] = V;
> > > +dest[3 * i + 1] = Y;
> > > +dest[3 * i + 2] = U;
> > > +}
> > > +}
> > > +
> > >   #define output_pixel(pos, val, bits) \
> > >   AV_WL16(pos, av_clip_uintp2(val >> shift, bits) << output_shift);
> > > @@ -3465,6 +3505,9 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
> > >   *yuv2packed2 = yuv2uyvy422_2_c;
> > >   *yuv2packedX = yuv2uyvy422_X_c;
> > >   break;
> > > +case AV_PIX_FMT_VYU444:
> > > +*yuv2packedX = yuv2vyu444_X_c;
> > > +break;
> > 
> > does this work in the unscaled and 2 tap scaling cases ? (which would 
> > normally
> > use teh other 2pointers
> 
> I tried
> 
> ./ffmpeg.exe -noauto_conversion_filters -cpuflags 0 -f image2 -c:v pgmyuv -i
> ./tests/vsynth1/%02d.pgm -vf scale=sws_flags=bilinear,format=vyu444 -vcodec
> rawvideo -pix_fmt vyu444 -frames:v 1 -y out.nut
> 

> And it works (The output looks fine with ffplay). Is there some other way to
> test that?

is that command above actually scaling anything ? it looks like input and output
have t he same size

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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] nuv1 in avi

[Michael Niedermayer]

On Wed, Oct 16, 2024 at 12:39:14AM +0300, Andrew Randrianasulu wrote:
> вс, 13 окт. 2024 г., 14:40 Anton Khirnov :
> 
> > Quoting Andrew Randrianasulu (2024-10-08 14:03:13)
> > > I was experimenting with mencoder
> > >
> > > 
> > >
> > > what do you think? ;)
> >
> > why oh oh god why?
> >
> 
> Because mplayer (and mencoder) was first program I successfully compiled
> many, many years back and I used mencoder on underpowered ~400 Mhz Celeron
> for capturing some video
> 
> https://randrianasulu.livejournal.com/13569.html
> 
> now it may considered obsolete, but underpowered hardware still exist. For
> example, PinePhone I was reading about have some 4*1.1 GHz ARM, so ffmpeg
> was used there via cli anyway, surprisingly no-one showed mpeg2 line? It
> was mjpeg or vp8 (9) or x264 ultrafast 
> 
> https://www.reddit.com/r/PINE64official/comments/18awye8/pinephone_video_recording/
> 
> now, x86 and ARM surely different, but if something can be scaled back to
> non-MMX Pentium it probably will work on many "obsolete" devices where
> latest SIMD sets not available. I actually used some version of Indeo codec
> back in ~2001 for recording in ... 176*144 ? on exactly Pentium 1 150Mhz.
> Under win 9x, from VirtualDub. I was surprised it worked at all (with
> preview!).
> 
> So, I set my AMD FX to 1400 Mhz, fired up mplayer/mencoder under qemu-i386
> to see how it performs with some binary mjpeg encoder (MainConcept's mjpeg,
> claimed to reach realtime 640*480 on PII 300 Mhz (from settings probably
> one field only)). Found mencoder was doing 25 fps with binary encoder dll,

> ffmpeg 0.5.15 was doing up to 40 fps in mjpeg/i420 if compiled for i486,
> ffmpeg 4.4/latest was doing up to 20 fps. Not sure why, but it was
> interesting!

if you have time you could
git bisect
to identify tha cause, but it could be more than 1 commit
and it could be something boring like a change of quality vs speed settings

thx

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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] hw_base_encode: Free pictures on close

[Cameron Gutman]

On Wed, Oct 16, 2024 at 5:49 AM Lynne via ffmpeg-devel
 wrote:
>
> On 15/10/2024 17:51, Lynne via ffmpeg-devel wrote:
> > On 15/10/2024 16:49, David Rosca wrote:
> >> Fixes leaking recon surfaces with VAAPI.
> >> ---
> >>   libavcodec/hw_base_encode.c | 5 +
> >>   1 file changed, 5 insertions(+)
> >>
> >> diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
> >> index 7b6ec97d3b..912c707a68 100644
> >> --- a/libavcodec/hw_base_encode.c
> >> +++ b/libavcodec/hw_base_encode.c
> >> @@ -804,6 +804,11 @@ int ff_hw_base_encode_init(AVCodecContext *avctx,
> >> FFHWBaseEncodeContext *ctx)
> >>   int ff_hw_base_encode_close(FFHWBaseEncodeContext *ctx)
> >>   {
> >> +FFHWBaseEncodePicture *pic;
> >> +
> >> +for (pic = ctx->pic_start; pic; pic = pic->next)
> >> +base_encode_pic_free(pic);
> >> +
> >>   av_fifo_freep2(&ctx->encode_fifo);
> >>   av_frame_free(&ctx->frame);
> >
> > I've noticed this happening with Vulkan as well.
> >
> > LGTM, I'll push this after testing it in a few hours
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> Thanks, pushed

Aha, I was chasing a major VAAPI leak (VAAPI surfaces, DRI fds, etc)
in FFmpeg 7.1 when performing multiple VAAPI encoding sessions in a
single process that turned out to be fixed by this patch.
Unfortunately, this particular fix has a use-after-free since
base_encode_pic_free() frees pic before we read pic->next.

You probably want something like:
while (ctx->pic_start) {
pic = ctx->pic_start->next;
base_encode_pic_free(ctx->pic_start);
ctx->pic_start = pic;
}

Since this is a 7.1 regression, I'd appreciate it if you could also
cherry-pick this commit and the UAF fix into release/7.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 5/5] libavcodec/ffv1: Support storing LSB raw

[Jerome Martinez]

Le 16/10/2024 à 21:51, Michael Niedermayer a écrit :

did you try qtable 1 ? strangely it performed better for the file i used 
compression wise


Updated with latest code (in practice, no change in previous values):
0,037x    0,471    No patch
0,051x    0,491    bitfield
0,046x    0,489    rangecoder
0,046x    0,486    rangecoder qtable=1

qtable=1 helps but still not enough for being interesting compared to 
the bitfield version.



also i cleaned the code up a bit and reposted, some of the code was
not exactly optimized

here the old "bitfield"
real0m5.545s
real0m5.655s
real0m5.643s

vs. just now posted:
real0m5.407s
real0m5.393s
real0m5.404s


Even more interesting to keep the bitfield version rather than the range 
coder!


FYI I test on 2 different sets of 2 seconds of real content, on SSD, 1 
min of encoding each so result is stable, unfortunately I don't have 
more content but I try to have more.

___
ffmpeg-devel mailing list
ffmpeg-devel@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] AVFilter

[Michael Niedermayer]

Hi Niklas

On Wed, Oct 16, 2024 at 02:30:47PM +0200, Niklas Haas wrote:
> On Tue, 15 Oct 2024 18:12:21 +0200 Michael Niedermayer 
>  wrote:
> > Hi all
> >
> > This is a quick RFC about peoples oppinions on AVFilter
> >
> > The question: Should anyone be able to write a filter (which
> > other people can use) ?
> > Or should only we be able to add filters ?
> 
> As a compromise, we could allow external filters with a more strict ABI
> requirement, i.e. the filter must be built against the exact same version of
> libavfilter. That way, we could still change the API as needed, without
> needing to maintain long-term ABI compatibility.

yes, thats possible, in fact given that we dont change the API in ways
that matter to filters that often, it seems a rather minor thing.
Like introducing a FILTER_API_VERSION and just bumping that when a
change is being done.


> 
> I think that from a corrent PoV, the status quo of external filters being
> added out-of-tree at build time is fine, and maybe we could make that process
> a bit easier.

id really like to see a way by which people can write and maintain
their filters somewhere like github and them being available with reasonable
effort on the user side to applications using libavfilter.


> 
> Another thing to mention is that a lot of downstream use cases for custom
> filters could be solved by adding a single proprammable "custom" filter that
> calls a user-provided callback function. This filter could be given a more
> limited but stable API, without limiting our ability to change the internal
> details. Think of something like buffersink/buffersrc, but for custom filters.

Thats one specific usecase.
But there are generic filters too which are independant of the application using
libavfilter

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

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

Re: [FFmpeg-devel] [PATCH v2 2/2] tests/fate: disable compression for zlib-based codecs

[Ramiro Polla]

On Mon, Oct 14, 2024 at 10:57 PM Michael Niedermayer
 wrote:
> On Sun, Sep 29, 2024 at 08:36:29PM +0200, Ramiro Polla wrote:
> > FATE results differ when using the original zlib and zlib-ng.
> >
> > Since we don't need to test the result from zlib itself, this commit
> > disables compression on tests for zlib-based codecs, which ends up
> > giving the same results with both libraries.
> > ---
> >  tests/fate/cover-art.mak  |  6 +--
> >  tests/fate/image.mak  |  4 +-
> >  tests/fate/lavf-image.mak |  5 ++-
> >  tests/fate/lavf-video.mak |  4 +-
> >  tests/fate/mov.mak|  2 +-
> >  tests/fate/vcodec.mak |  4 +-
> >  tests/ref/fate/copy-apng  |  4 +-
> >  tests/ref/fate/cover-art-aiff-id3v2-remux |  6 +--
> >  tests/ref/fate/cover-art-flac-remux   | 48 +--
> >  tests/ref/fate/cover-art-mp3-id3v2-remux  |  6 +--
> >  tests/ref/fate/mov-cover-image|  6 +--
> >  tests/ref/fate/png-icc|  6 +--
> >  tests/ref/fate/png-mdcv   |  4 +-
> >  tests/ref/lavf/apng   |  4 +-
> >  tests/ref/lavf/apng.png   |  4 +-
> >  tests/ref/lavf/gray16be.png   |  4 +-
> >  tests/ref/lavf/png|  4 +-
> >  tests/ref/lavf/rgb48be.png|  4 +-
> >  tests/ref/seek/vsynth_lena-flashsv| 40 +--
> >  tests/ref/vsynth/vsynth1-flashsv  |  4 +-
> >  tests/ref/vsynth/vsynth1-mpng |  4 +-
> >  tests/ref/vsynth/vsynth1-zlib |  4 +-
> >  tests/ref/vsynth/vsynth2-flashsv  |  4 +-
> >  tests/ref/vsynth/vsynth2-mpng |  4 +-
> >  tests/ref/vsynth/vsynth2-zlib |  4 +-
> >  tests/ref/vsynth/vsynth3-flashsv  |  4 +-
> >  tests/ref/vsynth/vsynth3-mpng |  4 +-
> >  tests/ref/vsynth/vsynth3-zlib |  4 +-
> >  tests/ref/vsynth/vsynth_lena-flashsv  |  4 +-
> >  tests/ref/vsynth/vsynth_lena-mpng |  4 +-
> >  tests/ref/vsynth/vsynth_lena-zlib |  4 +-
> >  31 files changed, 120 insertions(+), 93 deletions(-)
>
> with latest git i get this:
>
> make -j32 -k fate-png-mdcv fate-mov-cover-image
> TESTpng-mdcv
> TESTmov-cover-image
> --- ./tests/ref/fate/mov-cover-image2024-10-14 22:49:44.488637985 +0200
> +++ tests/data/fate/mov-cover-image 2024-10-14 22:56:27.175855259 +0200
> @@ -1,4 +1,4 @@
> -ecc0c7b60d4b00a2f04367c2ecd402c2 *tests/data/fate/mov-cover-image.mp4
> +ad553810e0ce362697a2b21544daebde *tests/data/fate/mov-cover-image.mp4
>  2063262 tests/data/fate/mov-cover-image.mp4
>  #extradata 0:2, 0x00340022
>  #tb 0: 1/44100
> @@ -20,7 +20,7 @@
>  0,  -1088,  -1088, 1024,6, 0x027e00e8, F=0x5
>  0,-64,-64, 1024,6, 0x027e00e8
>  1,  0,  0,0,25441, 0xe82503b0
> -2,  0,  0,0,  1084000, 0x70fc8139
> +2,  0,  0,0,  1084000, 0x413c7ee9
>  0,960,960, 1024,6, 0x027e00e8
>  0,   1984,   1984, 1024,6, 0x027e00e8
>  0,   3008,   3008, 1024,6, 0x027e00e8
> Test mov-cover-image failed. Look at tests/data/fate/mov-cover-image.err for 
> details.
> make: *** [tests/Makefile:311: fate-mov-cover-image] Error 1
> --- ./tests/ref/fate/png-mdcv   2024-10-14 22:49:44.488637985 +0200
> +++ tests/data/fate/png-mdcv2024-10-14 22:56:27.227855667 +0200
> @@ -1,5 +1,5 @@
> -4001769a41d37d567c4cc0c532e20b54 *tests/data/fate/png-mdcv.image2pipe
> -2774225 tests/data/fate/png-mdcv.image2pipe
> +b674209fd9cd8eff945a6bc1a4b306d3 *tests/data/fate/png-mdcv.image2pipe
> +2774240 tests/data/fate/png-mdcv.image2pipe
>  #tb 0: 1/25
>  #media_type 0: video
>  #codec_id 0: rawvideo
> Test png-mdcv failed. Look at tests/data/fate/png-mdcv.err for details.
> make: *** [tests/Makefile:311: fate-png-mdcv] Error 1

The difference in the png tests comes from a bugfix in zlib itself:
https://github.com/madler/zlib/commit/8ba393e70d984d902b15b9e6876f4d0d38ae4be8

The output of uncompressed data _may_ change between zlib versions
1.2.11 and 1.2.12.

We could just update the fate boxes to use zlib >= 1.2.12. Or write
our own ff_deflate_uncompressed() which bypasses zlib. I can't think
of anything better off the top of my head. Other suggestions are
welcome.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/libopusenc: add support for mapping family 2

[James Almer]

Signed-off-by: James Almer 
---
 libavcodec/libopusenc.c | 55 +++--
 1 file changed, 42 insertions(+), 13 deletions(-)

diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
index 6b8b2cda0e..fcd0254be3 100644
--- a/libavcodec/libopusenc.c
+++ b/libavcodec/libopusenc.c
@@ -191,21 +191,25 @@ static int libopus_check_max_channels(AVCodecContext 
*avctx,
 }
 
 static int libopus_check_vorbis_layout(AVCodecContext *avctx, int 
mapping_family) {
-av_assert2(avctx->ch_layout.nb_channels < 
FF_ARRAY_ELEMS(ff_vorbis_ch_layouts));
-
 if (avctx->ch_layout.order == AV_CHANNEL_ORDER_UNSPEC) {
 av_log(avctx, AV_LOG_WARNING,
"No channel layout specified. Opus encoder will use Vorbis "
"channel layout for %d channels.\n", 
avctx->ch_layout.nb_channels);
-} else if (av_channel_layout_compare(&avctx->ch_layout, 
&ff_vorbis_ch_layouts[avctx->ch_layout.nb_channels - 1])) {
-char name[32];
-
-av_channel_layout_describe(&avctx->ch_layout, name, sizeof(name));
-av_log(avctx, AV_LOG_ERROR,
-   "Invalid channel layout %s for specified mapping family %d.\n",
-   name, mapping_family);
-
-return AVERROR(EINVAL);
+} else if (avctx->ch_layout.order == AV_CHANNEL_ORDER_NATIVE) {
+av_assert2(avctx->ch_layout.nb_channels < 
FF_ARRAY_ELEMS(ff_vorbis_ch_layouts));
+if (av_channel_layout_compare(&avctx->ch_layout, 
&ff_vorbis_ch_layouts[avctx->ch_layout.nb_channels - 1])) {
+char name[32];
+av_channel_layout_describe(&avctx->ch_layout, name, sizeof(name));
+av_log(avctx, AV_LOG_ERROR,
+   "Invalid channel layout %s for specified mapping family 
%d.\n",
+   name, mapping_family);
+
+return AVERROR(EINVAL);
+}
+} else if (avctx->ch_layout.order != AV_CHANNEL_ORDER_AMBISONIC) {
+av_log(avctx, AV_LOG_WARNING,
+   "Unsupported channel layout specified. Opus encoder will use 
Vorbis "
+   "channel layout for %d channels.\n", 
avctx->ch_layout.nb_channels);
 }
 
 return 0;
@@ -221,7 +225,8 @@ static int libopus_validate_layout_and_get_channel_map(
 
 switch (mapping_family) {
 case -1:
-ret = libopus_check_max_channels(avctx, 8);
+ret = libopus_check_max_channels(avctx, avctx->ch_layout.order == 
AV_CHANNEL_ORDER_AMBISONIC
+? 227 : 8);
 if (ret == 0) {
 ret = libopus_check_vorbis_layout(avctx, mapping_family);
 /* Channels do not need to be reordered. */
@@ -242,6 +247,9 @@ static int libopus_validate_layout_and_get_channel_map(
 channel_map = 
ff_vorbis_channel_layout_offsets[avctx->ch_layout.nb_channels - 1];
 }
 break;
+case 2:
+ret = libopus_check_max_channels(avctx, 227);
+break;
 case 255:
 ret = libopus_check_max_channels(avctx, 254);
 break;
@@ -345,7 +353,7 @@ static av_cold int libopus_encode_init(AVCodecContext 
*avctx)
 return av_ret;
 }
 
-if (opus->opts.mapping_family == -1) {
+if (opus->opts.mapping_family == -1 && avctx->ch_layout.order != 
AV_CHANNEL_ORDER_AMBISONIC) {
 /* By default, use mapping family 1 for the header but use the older
  * libopus multistream API to avoid surround masking. */
 
@@ -367,6 +375,27 @@ static av_cold int libopus_encode_init(AVCodecContext 
*avctx)
  * mapping and coupled stream counts to its internal defaults and will
  * use surround masking analysis to save bits. */
 mapping_family = opus->opts.mapping_family;
+if (mapping_family == -1) {
+int ambisonic_order, non_diegetic_channels;
+
+mapping_family = 2;
+av_assert2(avctx->ch_layout.order == AV_CHANNEL_ORDER_AMBISONIC);
+ambisonic_order = 
av_channel_layout_ambisonic_order(&avctx->ch_layout);
+if (ambisonic_order < 0) {
+av_log(avctx, AV_LOG_ERROR, "Invalid ambisonic channel layout 
for mapping channel 2\n");
+ret = AVERROR(EINVAL);
+goto fail;
+}
+
+non_diegetic_channels = channels - (ambisonic_order + 1) * 
(ambisonic_order + 1);
+if (non_diegetic_channels &&
+(non_diegetic_channels != 2 ||
+ av_channel_layout_subset(&avctx->ch_layout, 
AV_CH_LAYOUT_STEREO) != AV_CH_LAYOUT_STEREO)) {
+av_log(avctx, AV_LOG_ERROR, "Invalid amount of non-diegetic 
channels for mapping channel 2\n");
+ret = AVERROR(EINVAL);
+goto fail;
+}
+}
 enc = opus_multistream_surround_encoder_create(
 avctx->sample_rate, channels, mapping_family,
 &opus->stream_count, &coupled_stream_count, 
libopus_channel_mapping,
-- 
2.46.2

__

[FFmpeg-devel] [PATCH] avcodec/ffv1: Support >8bit rice golomb

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/ffv1.h| 2 +-
 libavcodec/ffv1enc.c | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
index 02bfc33f680..7e84c98235f 100644
--- a/libavcodec/ffv1.h
+++ b/libavcodec/ffv1.h
@@ -54,8 +54,8 @@
 #define AC_RANGE_DEFAULT_TAB_FORCE -2
 
 typedef struct VlcState {
+uint32_t error_sum;
 int16_t drift;
-uint16_t error_sum;
 int8_t bias;
 uint8_t count;
 } VlcState;
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 0548daf8c47..ae0bb0057ce 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -248,7 +248,7 @@ static inline void put_vlc_symbol(PutBitContext *pb, 
VlcState *const state,
 i += i;
 }
 
-av_assert2(k <= 13);
+av_assert2(k <= 16);
 
 code = v ^ ((2 * state->drift + state->count) >> 31);
 
@@ -711,10 +711,10 @@ static av_cold int encode_init(AVCodecContext *avctx)
 }
 av_assert0(s->bits_per_raw_sample >= 8);
 
-if (s->bits_per_raw_sample > 8) {
+if (s->bits_per_raw_sample > (s->version > 3 ? 16 : 8)) {
 if (s->ac == AC_GOLOMB_RICE) {
 av_log(avctx, AV_LOG_INFO,
-"bits_per_raw_sample > 8, forcing range coder\n");
+"high bits_per_raw_sample, forcing range coder\n");
 s->ac = AC_RANGE_CUSTOM_TAB;
 }
 }
-- 
2.47.0

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

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

Re: [FFmpeg-devel] [PATCH v2 2/2] tests/fate: disable compression for zlib-based codecs

[James Almer]

On 10/16/2024 4:34 PM, Ramiro Polla wrote:

On Mon, Oct 14, 2024 at 10:57 PM Michael Niedermayer
 wrote:

On Sun, Sep 29, 2024 at 08:36:29PM +0200, Ramiro Polla wrote:

FATE results differ when using the original zlib and zlib-ng.

Since we don't need to test the result from zlib itself, this commit
disables compression on tests for zlib-based codecs, which ends up
giving the same results with both libraries.
---
  tests/fate/cover-art.mak  |  6 +--
  tests/fate/image.mak  |  4 +-
  tests/fate/lavf-image.mak |  5 ++-
  tests/fate/lavf-video.mak |  4 +-
  tests/fate/mov.mak|  2 +-
  tests/fate/vcodec.mak |  4 +-
  tests/ref/fate/copy-apng  |  4 +-
  tests/ref/fate/cover-art-aiff-id3v2-remux |  6 +--
  tests/ref/fate/cover-art-flac-remux   | 48 +--
  tests/ref/fate/cover-art-mp3-id3v2-remux  |  6 +--
  tests/ref/fate/mov-cover-image|  6 +--
  tests/ref/fate/png-icc|  6 +--
  tests/ref/fate/png-mdcv   |  4 +-
  tests/ref/lavf/apng   |  4 +-
  tests/ref/lavf/apng.png   |  4 +-
  tests/ref/lavf/gray16be.png   |  4 +-
  tests/ref/lavf/png|  4 +-
  tests/ref/lavf/rgb48be.png|  4 +-
  tests/ref/seek/vsynth_lena-flashsv| 40 +--
  tests/ref/vsynth/vsynth1-flashsv  |  4 +-
  tests/ref/vsynth/vsynth1-mpng |  4 +-
  tests/ref/vsynth/vsynth1-zlib |  4 +-
  tests/ref/vsynth/vsynth2-flashsv  |  4 +-
  tests/ref/vsynth/vsynth2-mpng |  4 +-
  tests/ref/vsynth/vsynth2-zlib |  4 +-
  tests/ref/vsynth/vsynth3-flashsv  |  4 +-
  tests/ref/vsynth/vsynth3-mpng |  4 +-
  tests/ref/vsynth/vsynth3-zlib |  4 +-
  tests/ref/vsynth/vsynth_lena-flashsv  |  4 +-
  tests/ref/vsynth/vsynth_lena-mpng |  4 +-
  tests/ref/vsynth/vsynth_lena-zlib |  4 +-
  31 files changed, 120 insertions(+), 93 deletions(-)


with latest git i get this:

make -j32 -k fate-png-mdcv fate-mov-cover-image
TESTpng-mdcv
TESTmov-cover-image
--- ./tests/ref/fate/mov-cover-image2024-10-14 22:49:44.488637985 +0200
+++ tests/data/fate/mov-cover-image 2024-10-14 22:56:27.175855259 +0200
@@ -1,4 +1,4 @@
-ecc0c7b60d4b00a2f04367c2ecd402c2 *tests/data/fate/mov-cover-image.mp4
+ad553810e0ce362697a2b21544daebde *tests/data/fate/mov-cover-image.mp4
  2063262 tests/data/fate/mov-cover-image.mp4
  #extradata 0:2, 0x00340022
  #tb 0: 1/44100
@@ -20,7 +20,7 @@
  0,  -1088,  -1088, 1024,6, 0x027e00e8, F=0x5
  0,-64,-64, 1024,6, 0x027e00e8
  1,  0,  0,0,25441, 0xe82503b0
-2,  0,  0,0,  1084000, 0x70fc8139
+2,  0,  0,0,  1084000, 0x413c7ee9
  0,960,960, 1024,6, 0x027e00e8
  0,   1984,   1984, 1024,6, 0x027e00e8
  0,   3008,   3008, 1024,6, 0x027e00e8
Test mov-cover-image failed. Look at tests/data/fate/mov-cover-image.err for 
details.
make: *** [tests/Makefile:311: fate-mov-cover-image] Error 1
--- ./tests/ref/fate/png-mdcv   2024-10-14 22:49:44.488637985 +0200
+++ tests/data/fate/png-mdcv2024-10-14 22:56:27.227855667 +0200
@@ -1,5 +1,5 @@
-4001769a41d37d567c4cc0c532e20b54 *tests/data/fate/png-mdcv.image2pipe
-2774225 tests/data/fate/png-mdcv.image2pipe
+b674209fd9cd8eff945a6bc1a4b306d3 *tests/data/fate/png-mdcv.image2pipe
+2774240 tests/data/fate/png-mdcv.image2pipe
  #tb 0: 1/25
  #media_type 0: video
  #codec_id 0: rawvideo
Test png-mdcv failed. Look at tests/data/fate/png-mdcv.err for details.
make: *** [tests/Makefile:311: fate-png-mdcv] Error 1


The difference in the png tests comes from a bugfix in zlib itself:
https://github.com/madler/zlib/commit/8ba393e70d984d902b15b9e6876f4d0d38ae4be8

The output of uncompressed data _may_ change between zlib versions
1.2.11 and 1.2.12.

We could just update the fate boxes to use zlib >= 1.2.12. Or write
our own ff_deflate_uncompressed() which bypasses zlib. I can't think
of anything better off the top of my head. Other suggestions are
welcome.


The obvious solution is writing a ff_deflate_uncompressed() we would use 
for compression_level 0. Another is shipping zlib in our tree and adding 
a configure option to use the system one. But until any of them happens, 
I'll revert this patch.




OpenPGP_signature.asc
Description: OpenPGP digital 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 5/5] libavcodec/ffv1: Support storing LSB raw

[Michael Niedermayer]

Hi Jerome

On Wed, Oct 16, 2024 at 10:29:18PM +0200, Jerome Martinez wrote:
> Le 16/10/2024 à 21:51, Michael Niedermayer a écrit :
> > did you try qtable 1 ? strangely it performed better for the file i used 
> > compression wise
> 
> Updated with latest code (in practice, no change in previous values):
> 0,037x    0,471    No patch
> 0,051x    0,491    bitfield
> 0,046x    0,489    rangecoder
> 0,046x    0,486    rangecoder qtable=1
> 
> qtable=1 helps but still not enough for being interesting compared to the
> bitfield version.
> 
> > also i cleaned the code up a bit and reposted, some of the code was
> > not exactly optimized
> > 
> > here the old "bitfield"
> > real0m5.545s
> > real0m5.655s
> > real0m5.643s
> > 
> > vs. just now posted:
> > real0m5.407s
> > real0m5.393s
> > real0m5.404s
> 
> Even more interesting to keep the bitfield version rather than the range
> coder!

what are you testing?
the new code is faster than the old code.
There is something not right here, the range coder based implementation
i posted now is 5% faster then the range coder based one i posted earlier today
thats overall speed meassured with "time ./ffmpeg"
if you see no difference there is something fishy

i simply tested this:
./ffmpeg -i rawsamples/16/01.dpx -threads 1  -c:v ffv1 -context 1 -coder 1 
-strict -2 -level 4 -rawlsb 4   -y /tmp/speedtest4.nut

It uses 1 thread as the speed with more threads was very unstable between runs
and we want to know how fast ffv1 is not how multithreading behaves


> 
> FYI I test on 2 different sets of 2 seconds of real content, on SSD, 1 min
> of encoding each so result is stable, unfortunately I don't have more
> content but I try to have more.

can this content be downloaded somewhere ?

thx

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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] [WIP] False positives on Coverity

[Michael Niedermayer]

On Mon, Aug 12, 2024 at 07:40:41PM +0200, Michael Niedermayer wrote:
> On Thu, Jul 25, 2024 at 04:41:26PM +0200, Michael Niedermayer wrote:
> > On Sat, Jul 13, 2024 at 01:20:23AM +0200, Michael Niedermayer wrote:
> > > On Fri, Jul 12, 2024 at 01:55:42AM +0200, Michael Niedermayer wrote:
> > > [...]
> > > > Only 7 outstanding remain from prior may. and 19 total. So 99% of issues
> > > 
> > > down to 3 outstanding prior may and 8 overall
> > > 
> > > 
> > > [...]
> > > > 1604599 Overflowed constant; intentional
> > > > 1604530 Infinite loop ; "intentional"
> > > > 700368 Explicit null dereferenced ; the loop will exit after this and 
> > > > the code cannot be reached
> > > > 1559187 Data race condition ; intentional
> > > > 1591898 Unsigned compared against 0 ; pollfd has a signed fd on some 
> > > > platforms
> > > > 1559180 Check of thread-shared field evades lock acquisition ; See 
> > > > source code
> > > 
> > > 4 more false positives:
> > > 1604428 Overflowed return value ; avio_tell() misanalysis
> > > 1604511 Overflowed constant ; intentional
> > > 1604570 Overflowed constant ; not possible
> > > 1591857 Resource leak ; I think this works like intended
> > 
> > Heres a CSV of the fate of the issues from the 22nd april outstanding set
> > (this should match the other things posted)
> > 
> > Some of the issues where categorized and or fixed by Andreas or possibly
> > other people. These are listed too now as far as it could be inferred
> > from git and coverity CSVs and various notes easily. Sadly coverity does
> > not export the usernames of people updating an entry in any CSV.
> > 
> > If you see any errors, dont hesitate to post corrections
> 
> Jonatas from SPI found some errors, so here are corrected files :)

Has anyone else done work on Coverity that is covered by the STF Coverity
Project and intends to sign the contracts and send an invoice ?

Iam asking because if noone else wants to claim any part of the coverity
project work, i will eventually send an invoice for the last remaining part
of the coverity work to SPI/STF.

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 5/5] libavcodec/ffv1: Support storing LSB raw

[Michael Niedermayer]

On Wed, Oct 16, 2024 at 10:53:37PM +0200, Michael Niedermayer wrote:
> Hi Jerome
> 
> On Wed, Oct 16, 2024 at 10:29:18PM +0200, Jerome Martinez wrote:
> > Le 16/10/2024 à 21:51, Michael Niedermayer a écrit :
> > > did you try qtable 1 ? strangely it performed better for the file i used 
> > > compression wise
> > 
> > Updated with latest code (in practice, no change in previous values):
> > 0,037x    0,471    No patch
> > 0,051x    0,491    bitfield
> > 0,046x    0,489    rangecoder
> > 0,046x    0,486    rangecoder qtable=1
> > 
> > qtable=1 helps but still not enough for being interesting compared to the
> > bitfield version.
> > 
> > > also i cleaned the code up a bit and reposted, some of the code was
> > > not exactly optimized
> > > 
> > > here the old "bitfield"
> > > real  0m5.545s
> > > real  0m5.655s
> > > real  0m5.643s
> > > 
> > > vs. just now posted:
> > > real  0m5.407s
> > > real  0m5.393s
> > > real  0m5.404s
> > 
> > Even more interesting to keep the bitfield version rather than the range
> > coder!
> 
> what are you testing?
> the new code is faster than the old code.
> There is something not right here, the range coder based implementation
> i posted now is 5% faster then the range coder based one i posted earlier 
> today
> thats overall speed meassured with "time ./ffmpeg"
> if you see no difference there is something fishy
> 
> i simply tested this:
> ./ffmpeg -i rawsamples/16/01.dpx -threads 1  -c:v ffv1 -context 1 -coder 1 
> -strict -2 -level 4 -rawlsb 4   -y /tmp/speedtest4.nut

compiler was this:  gcc 9 (Ubuntu 9.4.0-1ubuntu1~20.04.2)

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

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

[FFmpeg-devel] [PATCH 3/8] avcodec/rangecoder: Move refill check out of refill() function

[Michael Niedermayer]

If the function is not inlined, this is more efficient. Also
it allows calling refill() without the check

Signed-off-by: Michael Niedermayer 
---
 libavcodec/rangecoder.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index 2248161bca1..da13c453edd 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -112,7 +112,6 @@ static inline void put_rac(RangeCoder *c, uint8_t *const 
state, int bit)
 
 static inline void refill(RangeCoder *c)
 {
-if (c->range < 0x100) {
 c->range <<= 8;
 c->low   <<= 8;
 if (c->bytestream < c->bytestream_end) {
@@ -120,7 +119,6 @@ static inline void refill(RangeCoder *c)
 c->bytestream++;
 } else
 c->overread ++;
-}
 }
 
 static inline int get_rac(RangeCoder *c, uint8_t *const state)
@@ -130,13 +128,15 @@ static inline int get_rac(RangeCoder *c, uint8_t *const 
state)
 c->range -= range1;
 if (c->low < c->range) {
 *state = c->zero_state[*state];
-refill(c);
+if (c->range < 0x100)
+refill(c);
 return 0;
 } else {
 c->low  -= c->range;
 *state   = c->one_state[*state];
 c->range = range1;
-refill(c);
+if (c->range < 0x100)
+refill(c);
 return 1;
 }
 }
-- 
2.47.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/8] avcodec/rangecoder: only perform renorm check/loop for callers that need it

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/rangecoder.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index 89d178ac314..110908d6bdd 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -62,7 +62,6 @@ void ff_build_rac_states(RangeCoder *c, int factor, int 
max_p);
 static inline void renorm_encoder(RangeCoder *c)
 {
 // FIXME: optimize
-while (c->range < 0x100) {
 if (c->outstanding_byte < 0) {
 c->outstanding_byte = c->low >> 8;
 } else if (c->low <= 0xFF00) {
@@ -81,7 +80,6 @@ static inline void renorm_encoder(RangeCoder *c)
 
 c->low = (c->low & 0xFF) << 8;
 c->range <<= 8;
-}
 }
 
 static inline int get_rac_count(RangeCoder *c)
@@ -108,7 +106,8 @@ static inline void put_rac(RangeCoder *c, uint8_t *const 
state, int bit)
 *state   = c->one_state[*state];
 }
 
-renorm_encoder(c);
+while (c->range < 0x100)
+renorm_encoder(c);
 }
 
 static inline void refill(RangeCoder *c)
-- 
2.47.0

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

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

[FFmpeg-devel] [PATCH 2/8] avcodec/rangecoder: Do not loop renormalization

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/rangecoder.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index 110908d6bdd..2248161bca1 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -106,7 +106,7 @@ static inline void put_rac(RangeCoder *c, uint8_t *const 
state, int bit)
 *state   = c->one_state[*state];
 }
 
-while (c->range < 0x100)
+if (c->range < 0x100)
 renorm_encoder(c);
 }
 
-- 
2.47.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 8/8] libavcodec/ffv1: Support storing LSB raw

[Michael Niedermayer]

This makes a 16bit RGB raw sample about 25% faster at a 2% loss of compression 
with rawlsb=4

This stores the LSB through non binary range coding, this is simpler than using 
a
separate coder
For cases where range coding is not wanted its probably best to use golomb rice
for everything.

We also pass the LSB through the decorrelation and context stages (which is 
basically free)
this leads to slightly better compression than separating them earlier.

Signed-off-by: Michael Niedermayer 
---
 libavcodec/ffv1.h |  2 ++
 libavcodec/ffv1_template.c| 19 ++-
 libavcodec/ffv1dec.c  |  2 ++
 libavcodec/ffv1dec_template.c | 16 +---
 libavcodec/ffv1enc.c  | 15 ++-
 libavcodec/ffv1enc_template.c | 17 +++--
 6 files changed, 56 insertions(+), 15 deletions(-)

diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
index d9010a1c5f6..7e84c98235f 100644
--- a/libavcodec/ffv1.h
+++ b/libavcodec/ffv1.h
@@ -83,6 +83,7 @@ typedef struct FFV1SliceContext {
 int slice_coding_mode;
 int slice_rct_by_coef;
 int slice_rct_ry_coef;
+int rawlsb;
 
 // RefStruct reference, array of MAX_PLANES elements
 PlaneContext *plane;
@@ -139,6 +140,7 @@ typedef struct FFV1Context {
 int key_frame_ok;
 int context_model;
 int qtable;
+int rawlsb;
 
 int bits_per_raw_sample;
 int packed_at_lsb;
diff --git a/libavcodec/ffv1_template.c b/libavcodec/ffv1_template.c
index abb90a12e49..10206702ee8 100644
--- a/libavcodec/ffv1_template.c
+++ b/libavcodec/ffv1_template.c
@@ -30,24 +30,25 @@ static inline int RENAME(predict)(TYPE *src, TYPE *last)
 }
 
 static inline int RENAME(get_context)(const int16_t 
quant_table[MAX_CONTEXT_INPUTS][MAX_QUANT_TABLE_SIZE],
-  TYPE *src, TYPE *last, TYPE *last2)
+  TYPE *src, TYPE *last, TYPE *last2, int 
rawlsb)
 {
 const int LT = last[-1];
 const int T  = last[0];
 const int RT = last[1];
 const int L  = src[-1];
+const int rawoff = (1<> 1;
 
 if (quant_table[3][127] || quant_table[4][127]) {
 const int TT = last2[0];
 const int LL = src[-2];
-return quant_table[0][(L - LT) & MAX_QUANT_TABLE_MASK] +
-   quant_table[1][(LT - T) & MAX_QUANT_TABLE_MASK] +
-   quant_table[2][(T - RT) & MAX_QUANT_TABLE_MASK] +
-   quant_table[3][(LL - L) & MAX_QUANT_TABLE_MASK] +
-   quant_table[4][(TT - T) & MAX_QUANT_TABLE_MASK];
+return quant_table[0][(L - LT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[1][(LT - T + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[2][(T - RT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[3][(LL - L + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[4][(TT - T + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK];
 } else
-return quant_table[0][(L - LT) & MAX_QUANT_TABLE_MASK] +
-   quant_table[1][(LT - T) & MAX_QUANT_TABLE_MASK] +
-   quant_table[2][(T - RT) & MAX_QUANT_TABLE_MASK];
+return quant_table[0][(L - LT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[1][(LT - T + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK] +
+   quant_table[2][(T - RT + rawoff >> rawlsb) & 
MAX_QUANT_TABLE_MASK];
 }
 
diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 5c099e49ad4..fc96bfb4cea 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -249,6 +249,8 @@ static int decode_slice_header(const FFV1Context *f,
 return AVERROR_INVALIDDATA;
 }
 }
+if (f->micro_version > 2)
+sc->rawlsb = get_symbol(c, state, 0);
 }
 
 return 0;
diff --git a/libavcodec/ffv1dec_template.c b/libavcodec/ffv1dec_template.c
index 2da6bd935dc..dbdcad7768e 100644
--- a/libavcodec/ffv1dec_template.c
+++ b/libavcodec/ffv1dec_template.c
@@ -60,8 +60,13 @@ RENAME(decode_line)(FFV1Context *f, FFV1SliceContext *sc,
 return AVERROR_INVALIDDATA;
 }
 
-context = RENAME(get_context)(quant_table,
-  sample[1] + x, sample[0] + x, sample[1] 
+ x);
+if (sc->rawlsb) {
+context = RENAME(get_context)(quant_table,
+  sample[1] + x, sample[0] + x, 
sample[1] + x, sc->rawlsb);
+} else {
+context = RENAME(get_context)(quant_table,
+  sample[1] + x, sample[0] + x, 
sample[1] + x, 0);
+}
 if (context < 0) {
 context = -context;
 sign= 1;
@@ -71,7 +76,12 @@ RENAME(decode_line)(FFV1Context *f, FFV1SliceContext *sc,
 av_assert2(context < p->context_count);
 
 if (ac != AC_GOLOMB_RICE) {
-diff = get_symbol_inline(c, p->state[context], 1);
+if (sc->ra

[FFmpeg-devel] [PATCH 4/8] avcodec/rangecoder: Avoid checking for the first byte on every renormalization

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/rangecoder.h | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index da13c453edd..944ad492fda 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -62,10 +62,9 @@ void ff_build_rac_states(RangeCoder *c, int factor, int 
max_p);
 static inline void renorm_encoder(RangeCoder *c)
 {
 // FIXME: optimize
-if (c->outstanding_byte < 0) {
-c->outstanding_byte = c->low >> 8;
-} else if (c->low <= 0xFF00) {
-*c->bytestream++ = c->outstanding_byte;
+if (c->low <= 0xFF00) {
+*c->bytestream = c->outstanding_byte;
+c->bytestream += c->outstanding_byte >= 0;
 for (; c->outstanding_count; c->outstanding_count--)
 *c->bytestream++ = 0xFF;
 c->outstanding_byte = c->low >> 8;
-- 
2.47.0

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

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

[FFmpeg-devel] [PATCH 5/8] avcodec/rangecoder: Remove unneeded outstanding byte mask

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/rangecoder.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index 944ad492fda..cdd99eff565 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -72,7 +72,7 @@ static inline void renorm_encoder(RangeCoder *c)
 *c->bytestream++ = c->outstanding_byte + 1;
 for (; c->outstanding_count; c->outstanding_count--)
 *c->bytestream++ = 0x00;
-c->outstanding_byte = (c->low >> 8) & 0xFF;
+c->outstanding_byte = c->low >> 8;
 } else {
 c->outstanding_count++;
 }
-- 
2.47.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 7/8] avcodec/rangecoder: Implement reading and writing upto 8 bits raw

[Michael Niedermayer]

This is much faster than doing 1 bit and updating a state

Signed-off-by: Michael Niedermayer 
---
 libavcodec/rangecoder.h   | 46 +++
 libavcodec/tests/rangecoder.c | 13 ++
 2 files changed, 59 insertions(+)

diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index 15217a99a3c..39eb5987ca8 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -76,6 +76,22 @@ static inline void renorm_encoder(RangeCoder *c)
 c->range <<= 8;
 }
 
+static inline void renorm_encoder_raw(RangeCoder *c)
+{
+if (c->low - 0xFF0001 >= 0x100 - 0xFF0001U) {
+int mask = c->low - 0xFF0001 >> 31;
+*c->bytestream = c->outstanding_byte + 1 + mask;
+c->bytestream += c->outstanding_byte >= 0;
+for (; c->outstanding_count; c->outstanding_count--)
+*c->bytestream++ = mask;
+c->outstanding_byte = c->low >> 16;
+} else {
+c->outstanding_count++;
+}
+
+c->low &= 0x;
+}
+
 static inline int get_rac_count(RangeCoder *c)
 {
 int x = c->bytestream - c->bytestream_start + c->outstanding_count;
@@ -104,6 +120,20 @@ static inline void put_rac(RangeCoder *c, uint8_t *const 
state, int bit)
 renorm_encoder(c);
 }
 
+static inline void put_rac_raw(RangeCoder *c, int bits, int len)
+{
+int r = c->range >> len;
+
+if (r < 0x100) {
+c->range <<= 8 - len;
+c->low = (c->low << 8) + c->range * bits;
+renorm_encoder_raw(c);
+} else {
+c->low += r * bits;
+c->range = r;
+}
+}
+
 static inline void refill(RangeCoder *c)
 {
 c->range <<= 8;
@@ -135,4 +165,20 @@ static inline int get_rac(RangeCoder *c, uint8_t *const 
state)
 }
 }
 
+static inline int get_rac_raw(RangeCoder *c, int len)
+{
+int bits;
+int r = c->range >> len;
+av_assert2(len <= 8);
+
+if (r < 0x100) {
+refill(c);
+r = c->range >> len;
+}
+bits = c->low / r;
+c->low -= r * bits;
+c->range = r;
+return bits;
+}
+
 #endif /* AVCODEC_RANGECODER_H */
diff --git a/libavcodec/tests/rangecoder.c b/libavcodec/tests/rangecoder.c
index fd858535a5b..7634953585d 100644
--- a/libavcodec/tests/rangecoder.c
+++ b/libavcodec/tests/rangecoder.c
@@ -76,6 +76,11 @@ int main(void)
 for (i = 0; i < SIZE; i++)
 put_rac(&c, state, r[i] & 1);
 
+for (i = 0; i < SIZE; i++) {
+int len = r[i++] % 7 + 1;
+put_rac_raw(&c, r[i]&((1

[FFmpeg-devel] [PATCH 6/8] avcodec/rangecoder: eliminate main branch from renorm_encoder()

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavcodec/rangecoder.h | 13 -
 1 file changed, 4 insertions(+), 9 deletions(-)

diff --git a/libavcodec/rangecoder.h b/libavcodec/rangecoder.h
index cdd99eff565..15217a99a3c 100644
--- a/libavcodec/rangecoder.h
+++ b/libavcodec/rangecoder.h
@@ -61,17 +61,12 @@ void ff_build_rac_states(RangeCoder *c, int factor, int 
max_p);
 
 static inline void renorm_encoder(RangeCoder *c)
 {
-// FIXME: optimize
-if (c->low <= 0xFF00) {
-*c->bytestream = c->outstanding_byte;
+if (c->low - 0xFF01 >= 0x1 - 0xFF01U) {
+int mask = c->low - 0xFF01 >> 31;
+*c->bytestream = c->outstanding_byte + 1 + mask;
 c->bytestream += c->outstanding_byte >= 0;
 for (; c->outstanding_count; c->outstanding_count--)
-*c->bytestream++ = 0xFF;
-c->outstanding_byte = c->low >> 8;
-} else if (c->low >= 0x1) {
-*c->bytestream++ = c->outstanding_byte + 1;
-for (; c->outstanding_count; c->outstanding_count--)
-*c->bytestream++ = 0x00;
+*c->bytestream++ = mask;
 c->outstanding_byte = c->low >> 8;
 } else {
 c->outstanding_count++;
-- 
2.47.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] libavcodec/ffv1: Support storing LSB raw

[Michael Niedermayer]

Hi Jerome

On Wed, Oct 16, 2024 at 06:27:09PM +0200, Jerome Martinez wrote:
> Le 16/10/2024 à 15:54, Michael Niedermayer a écrit :
> > 3rd implemantation :)
> > you might ask why i implement this 4?! times
> > Heres why: (tests done with 4 rawlsb bits, 16bit per sample input)
> 
> I tested on my side also including the speed as the goal is to avoid the
> speed cost of the LSB, with 6K content from scanner (analog input, last bits
> are more or less random).
> Speed Compr
> 0,037x    0,471    No patch
> 0,051x    0,491    bitfield
> 0,046x    0,489    rangecoder
> 
> the 25% gain in the speed is clearly visible (actually it 27%  in my tests)
> with the bitfield version of storing LSB, but it is a lot less visible with
> the rangecoder version (the one from today):
> There is a small 0.5% gain in size at the cost of 9% of speed, it is not
> worth it IMO.
>
> I prefer by far your first version (really storing LSB as raw), it is fast
> as expected (25% less time) and adding the range coder creates something not
> really interesting (20% less time "only" for so little gain in size compared
> to 25%)

did you try qtable 1 ? strangely it performed better for the file i used 
compression wise

also i cleaned the code up a bit and reposted, some of the code was
not exactly optimized

here the old "bitfield"
real0m5.545s
real0m5.655s
real0m5.643s

vs. just now posted:
real0m5.407s
real0m5.393s
real0m5.404s

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/ffv1: add a named constant for the quant table size

[Michael Niedermayer]

On Wed, Oct 16, 2024 at 01:17:34AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/ffv1.h  |  4 +++-
>  libavcodec/ffv1_template.c | 18 +-
>  libavcodec/ffv1enc.c   |  6 +++---
>  3 files changed, 15 insertions(+), 13 deletions(-)

will apply

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

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

Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/ffv1enc: Add option to select the quantization table

[Michael Niedermayer]

On Tue, Oct 15, 2024 at 12:46:49AM +0200, Michael Niedermayer wrote:
> Sponsored-by: Sovereign Tech Fund
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/ffv1.h| 1 +
>  libavcodec/ffv1enc.c | 4 +++-
>  2 files changed, 4 insertions(+), 1 deletion(-)

will apply

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

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


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

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

Re: [FFmpeg-devel] [PATCH] avcodec/ffv1: RCT is only possible with RGB

[Michael Niedermayer]

On Thu, Oct 03, 2024 at 04:35:27PM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/ffv1dec.c | 2 +-
>  libavcodec/ffv1enc.c | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)

will apply

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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