date:20240730

Re: [FFmpeg-devel] [PATCH] lavu/hwcontext_qsv: Derive bind flag from frame type if no valid surface

2024-07-30 Thread Xiang, Haihao

On Ma, 2024-07-29 at 15:27 +, Tong Wu wrote:
-Original Message-
From: ffmpeg-devel 
mailto:ffmpeg-devel-boun...@ffmpeg.org>> On 
Behalf Of
fei.w.wang-at-intel@ffmpeg.org
Sent: 2024年7月23日 9:27
To: ffmpeg-devel@ffmpeg.org
Cc: fei.w.w...@intel.com
Subject: [FFmpeg-devel] [PATCH] lavu/hwcontext_qsv: Derive bind flag from
frame type if no valid surface

From: Fei Wang mailto:fei.w.w...@intel.com>>

Fix cmd:
ffmpeg.exe -init_hw_device d3d11va=d3d -init_hw_device qsv=qsv@d3d \
-filter_hw_device d3d -hwaccel qsv -hwaccel_output_format qsv  \
-i in.h264 -vf "hwmap,format=d3d11,hwdownload,format=nv12" -y out.yuv

Signed-off-by: Fei Wang mailto:fei.w.w...@intel.com>>
---
libavutil/hwcontext_qsv.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c index
7cec347478..09156275ec 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -1549,8 +1549,11 @@ static int
qsv_frames_derive_from(AVHWFramesContext *dst_ctx,
dst_hwctx->texture_infos[i].texture = 
(ID3D11Texture2D*)pair->first;
dst_hwctx->texture_infos[i].index = pair->second ==
(mfxMemId)MFX_INFINITE ? (intptr_t)0 : (intptr_t)pair->second;
}
-ID3D11Texture2D_GetDesc(dst_hwctx->texture_infos[0].texture,
&texDesc);
-dst_hwctx->BindFlags = texDesc.BindFlags;
+if (src_hwctx->nb_surfaces) {
+ID3D11Texture2D_GetDesc(dst_hwctx->texture_infos[0].texture,
&texDesc);
+dst_hwctx->BindFlags = texDesc.BindFlags;
+} else
+dst_hwctx->BindFlags =
+ qsv_get_d3d11va_bind_flags(src_hwctx->frame_type);
}
break;
#endif
--
2.34.1


Tested. LGTM. Thanks.

Applied, thx

- Haihao

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

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

___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavc/qsvdec: Add VVC decoder

2024-07-30 Thread Xiang, Haihao

On Vr, 2024-07-26 at 04:43 +, Xiang, Haihao wrote:
> On Vr, 2024-06-14 at 16:28 +0800, fei.w.wang-at-intel@ffmpeg.org wrote:
> > From: Fei Wang 
> > 
> > Signed-off-by: Fei Wang 
> > ---
> >  Changelog  | 1 +
> >  configure  | 1 +
> >  doc/decoders.texi  | 2 +-
> >  libavcodec/allcodecs.c | 1 +
> >  libavcodec/qsv.c   | 4 
> >  libavcodec/qsvdec.c    | 7 ++-
> >  libavcodec/version.h   | 2 +-
> >  7 files changed, 15 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Changelog b/Changelog
> > index 881b0e67a3..1fd1fce0c6 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -13,6 +13,7 @@ version :
> >  - VVC decoder compatible with DVB test content
> >  - xHE-AAC decoder
> >  - removed DEC Alpha DSP and support code
> > +- Intel QSV-accelerated VVC decoding
> >  
> >  
> >  version 7.0:
> > diff --git a/configure b/configure
> > index 6d31698142..d50f444141 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3421,6 +3421,7 @@ vp9_vaapi_encoder_select="vaapi_encode"
> >  vp9_qsv_encoder_deps="libmfx MFX_CODEC_VP9"
> >  vp9_qsv_encoder_select="qsvenc"
> >  vp9_v4l2m2m_decoder_deps="v4l2_m2m vp9_v4l2_m2m"
> > +vvc_qsv_decoder_select="qsvdec"
> >  
> >  # parsers
> >  aac_parser_select="adts_header mpeg4audio"
> > diff --git a/doc/decoders.texi b/doc/decoders.texi
> > index 293c82c2ba..2fcc761d2f 100644
> > --- a/doc/decoders.texi
> > +++ b/doc/decoders.texi
> > @@ -157,7 +157,7 @@ Force to use a specific number of threads
> >  @section QSV Decoders
> >  
> >  The family of Intel QuickSync Video decoders (VC1, MPEG-2, H.264, HEVC,
> > -JPEG/MJPEG, VP8, VP9, AV1).
> > +JPEG/MJPEG, VP8, VP9, AV1, VVC).
> >  
> >  @subsection Common Options
> >  
> > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > index b102a8069e..a73b4e1673 100644
> > --- a/libavcodec/allcodecs.c
> > +++ b/libavcodec/allcodecs.c
> > @@ -885,6 +885,7 @@ extern const FFCodec ff_vp9_mediacodec_encoder;
> >  extern const FFCodec ff_vp9_qsv_decoder;
> >  extern const FFCodec ff_vp9_vaapi_encoder;
> >  extern const FFCodec ff_vp9_qsv_encoder;
> > +extern const FFCodec ff_vvc_qsv_decoder;
> >  
> >  // null codecs
> >  extern const FFCodec ff_vnull_decoder;
> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> > index 0c6fbd0dc0..221c1b24e5 100644
> > --- a/libavcodec/qsv.c
> > +++ b/libavcodec/qsv.c
> > @@ -73,6 +73,10 @@ int ff_qsv_codec_id_to_mfx(enum AVCodecID codec_id)
> >  case AV_CODEC_ID_AV1:
> >  return MFX_CODEC_AV1;
> >  #endif
> > +#if QSV_VERSION_ATLEAST(2, 11)
> > +    case AV_CODEC_ID_VVC:
> > +    return MFX_CODEC_VVC;
> > +#endif
> >  
> >  default:
> >  break;
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> > index f2cd6ae05c..9ad3439991 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -933,7 +933,8 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext
> > *q,
> >  frame->pict_type = ff_qsv_map_pictype(aframe.frame-
> > > dec_info.FrameType);
> >  
> >  if (avctx->codec_id == AV_CODEC_ID_H264 ||
> > -    avctx->codec_id == AV_CODEC_ID_HEVC) {
> > +    avctx->codec_id == AV_CODEC_ID_HEVC ||
> > +    avctx->codec_id == AV_CODEC_ID_VVC) {
> >  if (aframe.frame->dec_info.FrameType & MFX_FRAMETYPE_IDR)
> >  frame->flags |= AV_FRAME_FLAG_KEY;
> >  else
> > @@ -1300,3 +1301,7 @@ DEFINE_QSV_DECODER(vp9, VP9, NULL)
> >  #if CONFIG_AV1_QSV_DECODER
> >  DEFINE_QSV_DECODER(av1, AV1, NULL)
> >  #endif
> > +
> > +#if CONFIG_VVC_QSV_DECODER
> > +DEFINE_QSV_DECODER(vvc, VVC, NULL)
> > +#endif
> > diff --git a/libavcodec/version.h b/libavcodec/version.h
> > index 7acb261bb3..37c4c39451 100644
> > --- a/libavcodec/version.h
> > +++ b/libavcodec/version.h
> > @@ -29,7 +29,7 @@
> >  
> >  #include "version_major.h"
> >  
> > -#define LIBAVCODEC_VERSION_MINOR   7
> > +#define LIBAVCODEC_VERSION_MINOR   8
> >  #define LIBAVCODEC_VERSION_MICRO 100
> >  
> >  #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> 
> LGTM, will apply

Fixed conflict in Changelog & libavcodec/version.h and applied. 

Thanks
Haihao

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

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

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

Re: [FFmpeg-devel] [PATCH 02/18] avcodec/pcm-bluray/dvd: Use correct pointer types on BE

2024-07-30 Thread Sebastian Ramacher

Hi

On 2024-03-29 00:10:31 +0100, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/pcm-bluray.c | 5 +++--
>  libavcodec/pcm-dvd.c| 2 +-
>  2 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/pcm-bluray.c b/libavcodec/pcm-bluray.c
> index f65609514a..235020d78f 100644
> --- a/libavcodec/pcm-bluray.c
> +++ b/libavcodec/pcm-bluray.c
> @@ -167,7 +167,7 @@ static int pcm_bluray_decode_frame(AVCodecContext *avctx, 
> AVFrame *frame,
>  samples *= num_source_channels;
>  if (AV_SAMPLE_FMT_S16 == avctx->sample_fmt) {
>  #if HAVE_BIGENDIAN
> -bytestream2_get_buffer(&gb, dst16, buf_size);
> +bytestream2_get_buffer(&gb, (uint8_t*)dst16, buf_size);
>  #else
>  do {
>  *dst16++ = bytestream2_get_be16u(&gb);
> @@ -187,7 +187,8 @@ static int pcm_bluray_decode_frame(AVCodecContext *avctx, 
> AVFrame *frame,
>  if (AV_SAMPLE_FMT_S16 == avctx->sample_fmt) {
>  do {
>  #if HAVE_BIGENDIAN
> -bytestream2_get_buffer(&gb, dst16, 
> avctx->ch_layout.nb_channels * 2);
> +bytestream2_get_buffer(&gb, (uint8_t*)dst16,
> +   avctx->ch_layout.nb_channels * 2);
>  dst16 += avctx->ch_layout.nb_channels;
>  #else
>  channel = avctx->ch_layout.nb_channels;
> diff --git a/libavcodec/pcm-dvd.c b/libavcodec/pcm-dvd.c
> index 419b2a138f..319746c62e 100644
> --- a/libavcodec/pcm-dvd.c
> +++ b/libavcodec/pcm-dvd.c
> @@ -157,7 +157,7 @@ static void *pcm_dvd_decode_samples(AVCodecContext 
> *avctx, const uint8_t *src,
>  switch (avctx->bits_per_coded_sample) {
>  case 16: {
>  #if HAVE_BIGENDIAN
> -bytestream2_get_buffer(&gb, dst16, blocks * s->block_size);
> +bytestream2_get_buffer(&gb, (uint8_t*)dst16, blocks * s->block_size);
>  dst16 += blocks * s->block_size / 2;
>  #else
>  int samples = blocks * avctx->ch_layout.nb_channels;
> -- 

Please backport this patch to 7.0 to fix https://trac.ffmpeg.org/ticket/9

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

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/vaapi_decode: Make it possible to send multiple slice params buffers

2024-07-30 Thread Sebastian Ramacher

On 2024-05-07 06:59:51 +, Xiang, Haihao wrote:
> On So, 2024-04-28 at 09:26 +0200, David Rosca wrote:
> > ---
> >  libavcodec/vaapi_av1.c    | 2 +-
> >  libavcodec/vaapi_decode.c | 3 ++-
> >  libavcodec/vaapi_decode.h | 1 +
> >  libavcodec/vaapi_h264.c   | 2 +-
> >  libavcodec/vaapi_hevc.c   | 4 ++--
> >  libavcodec/vaapi_mjpeg.c  | 2 +-
> >  libavcodec/vaapi_mpeg2.c  | 2 +-
> >  libavcodec/vaapi_mpeg4.c  | 2 +-
> >  libavcodec/vaapi_vc1.c    | 2 +-
> >  libavcodec/vaapi_vp8.c    | 2 +-
> >  libavcodec/vaapi_vp9.c    | 2 +-
> >  11 files changed, 13 insertions(+), 11 deletions(-)
> > 
> > diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
> > index 1f563483b9..4a90db1e09 100644
> > --- a/libavcodec/vaapi_av1.c
> > +++ b/libavcodec/vaapi_av1.c
> > @@ -409,7 +409,7 @@ static int vaapi_av1_decode_slice(AVCodecContext *avctx,
> >  .tg_end    = s->tg_end,
> >  };
> >  
> > -    err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param,
> > +    err = ff_vaapi_decode_make_slice_buffer(avctx, pic, &slice_param, 
> > 1,
> > 
> > sizeof(VASliceParameterBufferAV1),
> >  buffer,
> >  size);
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index 21b273cd0f..8e9f647c20 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -63,6 +63,7 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext 
> > *avctx,
> >  int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
> >    VAAPIDecodePicture *pic,
> >    const void *params_data,
> > +  int nb_params,
> >    size_t params_size,
> >    const void *slice_data,
> >    size_t slice_size)
> > @@ -88,7 +89,7 @@ int ff_vaapi_decode_make_slice_buffer(AVCodecContext 
> > *avctx,
> >  
> >  vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
> >   VASliceParameterBufferType,
> > - params_size, 1, (void*)params_data,
> > + params_size, nb_params, (void*)params_data,
> >   &pic->slice_buffers[index]);
> >  if (vas != VA_STATUS_SUCCESS) {
> >  av_log(avctx, AV_LOG_ERROR, "Failed to create slice "
> > diff --git a/libavcodec/vaapi_decode.h b/libavcodec/vaapi_decode.h
> > index 6beda14e52..702171e108 100644
> > --- a/libavcodec/vaapi_decode.h
> > +++ b/libavcodec/vaapi_decode.h
> > @@ -73,6 +73,7 @@ int ff_vaapi_decode_make_param_buffer(AVCodecContext 
> > *avctx,
> >  int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
> >    VAAPIDecodePicture *pic,
> >    const void *params_data,
> > +  int nb_params,
> >    size_t params_size,
> >    const void *slice_data,
> >    size_t slice_size);
> > diff --git a/libavcodec/vaapi_h264.c b/libavcodec/vaapi_h264.c
> > index 55cf5a05ee..b47531ce1c 100644
> > --- a/libavcodec/vaapi_h264.c
> > +++ b/libavcodec/vaapi_h264.c
> > @@ -375,7 +375,7 @@ static int vaapi_h264_decode_slice(AVCodecContext 
> > *avctx,
> >     slice_param.chroma_offset_l1);
> >  
> >  err = ff_vaapi_decode_make_slice_buffer(avctx, pic,
> > -    &slice_param,
> > sizeof(slice_param),
> > +    &slice_param, 1,
> > sizeof(slice_param),
> >  buffer, size);
> >  if (err) {
> >  ff_vaapi_decode_cancel(avctx, pic);
> > diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
> > index 3bdd2dd1b8..3937b7574a 100644
> > --- a/libavcodec/vaapi_hevc.c
> > +++ b/libavcodec/vaapi_hevc.c
> > @@ -353,7 +353,7 @@ static int vaapi_hevc_end_frame(AVCodecContext *avctx)
> >  if (pic->last_size) {
> >  last_slice_param->LongSliceFlags.fields.LastSliceOfPic = 1;
> >  ret = ff_vaapi_decode_make_slice_buffer(avctx, &pic->pic,
> > -    &pic->last_slice_param,
> > slice_param_size,
> > +    &pic->last_slice_param, 1,
> > slice_param_size,
> >  pic->last_buffer, pic-
> > >last_size);
> >  if (ret < 0)
> >  goto fail;
> > @@ -471,7 +471,7 @@ static int vaapi_hevc_decode_slice(AVCodecContext 
> > *avctx,
> >  
> >  if (!sh->first_slice_in_pic_flag) {
> >  err = ff_vaapi_decode_make_slice_buffer(avctx, &pic->pic,
> > -

Re: [FFmpeg-devel] [PATCH] libavcodec: fix -Wint-conversion in vulkan

2024-07-30 Thread Sebastian Ramacher

On 2024-01-06 22:40:39 +0100, Lynne wrote:
> Jan 6, 2024, 07:18 by s...@gentoo.org:
> 
> >
> > Sam James  writes:
> >
> >> FIx warnings (soon to be errors in GCC 14, already so in Clang 15):
> >> ```
> >> src/libavcodec/vulkan_av1.c: In function ‘vk_av1_create_params’:
> >> src/libavcodec/vulkan_av1.c:183:43: error: initialization of ‘long long 
> >> unsigned int’ from ‘void *’ makes integer from pointer without a cast 
> >> [-Wint-conversion]
> >>  183 | .videoSessionParametersTemplate = NULL,
> >>  |   ^~~~
> >> src/libavcodec/vulkan_av1.c:183:43: note: (near initialization for 
> >> ‘(anonymous).videoSessionParametersTemplate’)
> >> ```
> >>
> >> Use Vulkan's VK_NULL_HANDLE instead of bare NULL.
> >>
> >> Fix Trac ticket #10724.
> >>
> >> Was reported downstream in Gentoo at https://bugs.gentoo.org/919067.
> >>
> >> Signed-off-by: Sam James 
> >>
> >
> > ping
> >
> 
> Missed it.
> Pushed, thanks.

Please backport this patch to partly address 
https://trac.ffmpeg.org/ticket/5.

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

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

Re: [FFmpeg-devel] [PATCH] libavcodec: fix -Wint-conversion in vulkan

2024-07-30 Thread Sebastian Ramacher

On 2024-07-30 11:58:15 +0200, Sebastian Ramacher wrote:
> On 2024-01-06 22:40:39 +0100, Lynne wrote:
> > Jan 6, 2024, 07:18 by s...@gentoo.org:
> > 
> > >
> > > Sam James  writes:
> > >
> > >> FIx warnings (soon to be errors in GCC 14, already so in Clang 15):
> > >> ```
> > >> src/libavcodec/vulkan_av1.c: In function ‘vk_av1_create_params’:
> > >> src/libavcodec/vulkan_av1.c:183:43: error: initialization of ‘long long 
> > >> unsigned int’ from ‘void *’ makes integer from pointer without a cast 
> > >> [-Wint-conversion]
> > >>  183 | .videoSessionParametersTemplate = NULL,
> > >>  |   ^~~~
> > >> src/libavcodec/vulkan_av1.c:183:43: note: (near initialization for 
> > >> ‘(anonymous).videoSessionParametersTemplate’)
> > >> ```
> > >>
> > >> Use Vulkan's VK_NULL_HANDLE instead of bare NULL.
> > >>
> > >> Fix Trac ticket #10724.
> > >>
> > >> Was reported downstream in Gentoo at https://bugs.gentoo.org/919067.
> > >>
> > >> Signed-off-by: Sam James 
> > >>
> > >
> > > ping
> > >
> > 
> > Missed it.
> > Pushed, thanks.
> 
> Please backport this patch to partly address 
> https://trac.ffmpeg.org/ticket/5.

Forget it. I was looking at the wrong patch.

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

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

[FFmpeg-devel] [PATCH] Revert "lavf/vf_setpts: unset output framerate"

2024-07-30 Thread Arkadiusz Hiler

This reverts commit 43fd3d5df6a19fc768a33e37855aa7f8c7050cf0.

Fixes: 43fd3d5df6a1 ("lavf/vf_setpts: unset output framerate")
Fixes: #11086
Signed-off-by: Arkadiusz Hiler 
---
 libavfilter/setpts.c | 17 +--
 tests/ref/fate/filter-setpts | 89 +++-
 2 files changed, 39 insertions(+), 67 deletions(-)

diff --git a/libavfilter/setpts.c b/libavfilter/setpts.c
index 60cf2b642e0c..60fb3be0b50a 100644
--- a/libavfilter/setpts.c
+++ b/libavfilter/setpts.c
@@ -150,13 +150,6 @@ static int config_input(AVFilterLink *inlink)
 return 0;
 }
 
-static int config_output_video(AVFilterLink *outlink)
-{
-outlink->frame_rate = (AVRational){ 1, 0 };
-
-return 0;
-}
-
 #define BUF_SIZE 64
 
 static inline char *double2int64str(char *buf, double v)
@@ -330,14 +323,6 @@ static const AVFilterPad avfilter_vf_setpts_inputs[] = {
 },
 };
 
-static const AVFilterPad outputs_video[] = {
-{
-.name = "default",
-.type = AVMEDIA_TYPE_VIDEO,
-.config_props = config_output_video,
-},
-};
-
 const AVFilter ff_vf_setpts = {
 .name= "setpts",
 .description = NULL_IF_CONFIG_SMALL("Set PTS for the output video 
frame."),
@@ -351,7 +336,7 @@ const AVFilter ff_vf_setpts = {
 .priv_class = &setpts_class,
 
 FILTER_INPUTS(avfilter_vf_setpts_inputs),
-FILTER_OUTPUTS(outputs_video),
+FILTER_OUTPUTS(ff_video_default_filterpad),
 };
 #endif /* CONFIG_SETPTS_FILTER */
 
diff --git a/tests/ref/fate/filter-setpts b/tests/ref/fate/filter-setpts
index 08e02038315f..efdcf6a16eef 100644
--- a/tests/ref/fate/filter-setpts
+++ b/tests/ref/fate/filter-setpts
@@ -1,55 +1,42 @@
-#tb 0: 1/1000
+#tb 0: 1/25
 #media_type 0: video
 #codec_id 0: rawvideo
 #dimensions 0: 352x288
 #sar 0: 0/1
-0,  0,  0,0,   152064, 0x05b789ef
-0, 28, 28,0,   152064, 0x4bb46551
-0, 57, 57,0,   152064, 0x9dddf64a
-0, 86, 86,0,   152064, 0x2a8380b0
-0,115,115,0,   152064, 0x4de3b652
-0,144,144,0,   152064, 0xedb5a8e6
-0,172,172,0,   152064, 0xe20f7c23
-0,201,201,0,   152064, 0x5ab58bac
-0,229,229,0,   152064, 0x1f1b8026
-0,258,258,0,   152064, 0x91373915
-0,286,286,0,   152064, 0x02344760
-0,314,314,0,   152064, 0x30f5fcd5
-0,343,343,0,   152064, 0xc711ad61
-0,371,371,0,   152064, 0x24eca223
-0,399,399,0,   152064, 0x52a48ddd
-0,427,427,0,   152064, 0xa91c0f05
-0,456,456,0,   152064, 0x8e364e18
-0,484,484,0,   152064, 0xb15d38c8
-0,512,512,0,   152064, 0xf25f6acc
-0,541,541,0,   152064, 0xf34ddbff
-0,570,570,0,   152064, 0xfc7bf570
-0,598,598,0,   152064, 0x9dc72412
-0,627,627,0,   152064, 0x445d1d59
-0,656,656,0,   152064, 0x2f2768ef
-0,685,685,0,   152064, 0xce09f9d6
-0,714,714,0,   152064, 0x95579936
-0,743,743,0,   152064, 0x43d796b5
-0,772,772,0,   152064, 0xd780d887
-0,800,800,0,   152064, 0x76d2a455
-0,829,829,0,   152064, 0x6dc3650e
-0,858,858,0,   152064, 0x0f9d6aca
-0,887,887,0,   152064, 0xe295c51e
-0,915,915,0,   152064, 0xd766fc8d
-0,944,944,0,   152064, 0xe22f7a30
-0,972,972,0,   152064, 0x7fea4378
-0,   1000,   1000,0,   152064, 0xfa8d94fb
-0,   1029,   1029,0,   152064, 0x4c9737ab
-0,   1057,   1057,0,   152064, 0xa50d01f8
-0,   1085,   1085,0,   152064, 0x0b07594c
-0,   1113,   1113,0,   152064, 0x88734edd
-0,   1142,   1142,0,   152064, 0xd2735925
-0,   1170,   1170,0,   152064, 0xd4e49e08
-0,   1198,   1198,0,   152064, 0x20cebfa9
-0,   1227,   1227,0,   152064, 0x575c20ec
-0,   1255,   1255,0,   152064, 0xfd500471
-0,   1284,   1284,0,   152064, 0x61b47e73
-0,   1313,   1313,0,   152064, 0x09ef53ff
-0,   1341,   1341,0,   152064, 0x6e88c5c2
-0,   1370,   1370,0,   152064, 0xbb87b483
-0,   1399,   1399,0,   152064, 0x4bbad8ea
+0,  0,  0,1,   152064, 0x05b789ef
+0,  1,  1,1,   152064, 0x4bb46551
+0,  2,  2,1,   152064, 0x9dddf64a
+0,  3,  3,1,   152064, 0x2a8380b0
+0,

Re: [FFmpeg-devel] [PATCH] Revert "lavf/vf_setpts: unset output framerate"

2024-07-30 Thread Zhao Zhili


> 在 2024年7月30日，下午8:19，Arkadiusz Hiler  写道：
> 
> This reverts commit 43fd3d5df6a19fc768a33e37855aa7f8c7050cf0.
> 
> Fixes: 43fd3d5df6a1 ("lavf/vf_setpts: unset output framerate")
> Fixes: #11086

It’s a bug of svtav1 encoder to not support VFR. You can use -enc_time_base as 
a workaround.

> Signed-off-by: Arkadiusz Hiler 
> ---
> libavfilter/setpts.c | 17 +--
> tests/ref/fate/filter-setpts | 89 +++-
> 2 files changed, 39 insertions(+), 67 deletions(-)
> 
> diff --git a/libavfilter/setpts.c b/libavfilter/setpts.c
> index 60cf2b642e0c..60fb3be0b50a 100644
> --- a/libavfilter/setpts.c
> +++ b/libavfilter/setpts.c
> @@ -150,13 +150,6 @@ static int config_input(AVFilterLink *inlink)
> return 0;
> }
> 
> -static int config_output_video(AVFilterLink *outlink)
> -{
> -outlink->frame_rate = (AVRational){ 1, 0 };
> -
> -return 0;
> -}
> -
> #define BUF_SIZE 64
> 
> static inline char *double2int64str(char *buf, double v)
> @@ -330,14 +323,6 @@ static const AVFilterPad avfilter_vf_setpts_inputs[] = {
> },
> };
> 
> -static const AVFilterPad outputs_video[] = {
> -{
> -.name = "default",
> -.type = AVMEDIA_TYPE_VIDEO,
> -.config_props = config_output_video,
> -},
> -};
> -
> const AVFilter ff_vf_setpts = {
> .name= "setpts",
> .description = NULL_IF_CONFIG_SMALL("Set PTS for the output video 
> frame."),
> @@ -351,7 +336,7 @@ const AVFilter ff_vf_setpts = {
> .priv_class = &setpts_class,
> 
> FILTER_INPUTS(avfilter_vf_setpts_inputs),
> -FILTER_OUTPUTS(outputs_video),
> +FILTER_OUTPUTS(ff_video_default_filterpad),
> };
> #endif /* CONFIG_SETPTS_FILTER */
> 
> diff --git a/tests/ref/fate/filter-setpts b/tests/ref/fate/filter-setpts
> index 08e02038315f..efdcf6a16eef 100644
> --- a/tests/ref/fate/filter-setpts
> +++ b/tests/ref/fate/filter-setpts
> @@ -1,55 +1,42 @@
> -#tb 0: 1/1000
> +#tb 0: 1/25
> #media_type 0: video
> #codec_id 0: rawvideo
> #dimensions 0: 352x288
> #sar 0: 0/1
> -0,  0,  0,0,   152064, 0x05b789ef
> -0, 28, 28,0,   152064, 0x4bb46551
> -0, 57, 57,0,   152064, 0x9dddf64a
> -0, 86, 86,0,   152064, 0x2a8380b0
> -0,115,115,0,   152064, 0x4de3b652
> -0,144,144,0,   152064, 0xedb5a8e6
> -0,172,172,0,   152064, 0xe20f7c23
> -0,201,201,0,   152064, 0x5ab58bac
> -0,229,229,0,   152064, 0x1f1b8026
> -0,258,258,0,   152064, 0x91373915
> -0,286,286,0,   152064, 0x02344760
> -0,314,314,0,   152064, 0x30f5fcd5
> -0,343,343,0,   152064, 0xc711ad61
> -0,371,371,0,   152064, 0x24eca223
> -0,399,399,0,   152064, 0x52a48ddd
> -0,427,427,0,   152064, 0xa91c0f05
> -0,456,456,0,   152064, 0x8e364e18
> -0,484,484,0,   152064, 0xb15d38c8
> -0,512,512,0,   152064, 0xf25f6acc
> -0,541,541,0,   152064, 0xf34ddbff
> -0,570,570,0,   152064, 0xfc7bf570
> -0,598,598,0,   152064, 0x9dc72412
> -0,627,627,0,   152064, 0x445d1d59
> -0,656,656,0,   152064, 0x2f2768ef
> -0,685,685,0,   152064, 0xce09f9d6
> -0,714,714,0,   152064, 0x95579936
> -0,743,743,0,   152064, 0x43d796b5
> -0,772,772,0,   152064, 0xd780d887
> -0,800,800,0,   152064, 0x76d2a455
> -0,829,829,0,   152064, 0x6dc3650e
> -0,858,858,0,   152064, 0x0f9d6aca
> -0,887,887,0,   152064, 0xe295c51e
> -0,915,915,0,   152064, 0xd766fc8d
> -0,944,944,0,   152064, 0xe22f7a30
> -0,972,972,0,   152064, 0x7fea4378
> -0,   1000,   1000,0,   152064, 0xfa8d94fb
> -0,   1029,   1029,0,   152064, 0x4c9737ab
> -0,   1057,   1057,0,   152064, 0xa50d01f8
> -0,   1085,   1085,0,   152064, 0x0b07594c
> -0,   1113,   1113,0,   152064, 0x88734edd
> -0,   1142,   1142,0,   152064, 0xd2735925
> -0,   1170,   1170,0,   152064, 0xd4e49e08
> -0,   1198,   1198,0,   152064, 0x20cebfa9
> -0,   1227,   1227,0,   152064, 0x575c20ec
> -0,   1255,   1255,0,   152064, 0xfd500471
> -0,   1284,   1284,0,   152064, 0x61b47e73
> -0,   1313,   1313,0,   152064, 0x09ef53ff
> -0,   1341,   1341,0,   152064, 0x6e88c5c2
> -0,   1370,

Re: [FFmpeg-devel] [PATCH 1/4] swscale/yuv2rgb: prepare YUV2RGBFUNC macro for multi-planar rgb

2024-07-30 Thread Ramiro Polla

On Tue, Jul 23, 2024 at 2:46 PM Ramiro Polla  wrote:
> This will be used in the upcoming yuv42{0,2}p -> gbrp unscaled
> colorspace converters.

ping on this patchset.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 0/2] Interpret a degenerate SAR as 1/1.

2024-07-30 Thread Giovanni Mascellani

I came across some H.264 files in the wild whose SAR is set to
20480/0. The files are provided by the Ubisoft game OddBallers, and
are seemingly accepted and played properly when the game is played on
Windows (thus using the Microsoft Media Foundations
implementation).

When running the game with Wine the files are ultimately decoded by
libavcodec (via GStreamer), and playback is broken. It seems that only
a frame each second or so (maybe the key frames? I didn't check) is
decoded and presented, the others are discarded. After dumping the
video, I ran it with ffplay and it has the same problem, and the
following message is emitted many times:

  [h264 @ 0x7fd7301ef440] ignoring invalid SAR: 20480/1

Interestingly the invalid SAR is dumped as 20480/1 (which would be
strange, but in princple legal), while the file has 20480/0 (which
doesn't make sense at all). Equally interestingly, the frames that are
presented are indeed presented with SAR 1/1, like they are on Windows.

The H.264 standard says that "When aspect_ratio_idc is equal to 0 or
sar_width is equal to 0 or sar_height is equal to 0, the sample aspect
ratio shall be considered unspecified by this Recommendation |
International Standard". Given the behavior on Windows it seems that
the de facto standard way to solve the missing specification is to
assume that SAR is 1/1, which is what my patches seek to do.

With these patches both Wine and ffplay replay the broken file
correctly.

Since this is my first contributing to ffmpeg and I am not very
experienced in the project architecture, I'm not sure this is the
right abstraction level at which this problem should be handled. If
it's not, I'd be grateful if you could direct me to the appropriate
place.

Giovanni Mascellani (2):
  avcodec/h2645_vui: Interpret a degenerate SAR as 1/1.
  avcodec/evc_ps: Interpret a degenerate SAR as 1/1.

 libavcodec/evc_ps.c| 4 
 libavcodec/h2645_vui.c | 4 
 2 files changed, 8 insertions(+)

-- 
2.45.2

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

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

[FFmpeg-devel] [PATCH 1/2] avcodec/h2645_vui: Interpret a degenerate SAR as 1/1.

2024-07-30 Thread Giovanni Mascellani

The specification doesn't say what should happen in this case.
Other implementations (e.g., Microsoft's Media Foundations) seem
to interpret this as 1/1.

Signed-off-by: Giovanni Mascellani 
---
 libavcodec/h2645_vui.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/h2645_vui.c b/libavcodec/h2645_vui.c
index e5c7bf46f9..a9c0dbbef9 100644
--- a/libavcodec/h2645_vui.c
+++ b/libavcodec/h2645_vui.c
@@ -46,6 +46,10 @@ void ff_h2645_decode_common_vui_params(GetBitContext *gb, 
H2645VUI *vui, void *l
 else if (vui->aspect_ratio_idc == EXTENDED_SAR) {
 vui->sar.num = get_bits(gb, 16);
 vui->sar.den = get_bits(gb, 16);
+if (vui->sar.num == 0 || vui->sar.den == 0) {
+vui->sar.num = 1;
+vui->sar.den = 1;
+}
 } else
 av_log(logctx, AV_LOG_WARNING,
"Unknown SAR index: %u.\n", vui->aspect_ratio_idc);
-- 
2.45.2

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

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

[FFmpeg-devel] [PATCH 2/2] avcodec/evc_ps: Interpret a degenerate SAR as 1/1.

2024-07-30 Thread Giovanni Mascellani

The specification doesn't say what should happen in this case.
Other implementations (e.g., Microsoft's Media Foundations) seem
to interpret this as 1/1.

Signed-off-by: Giovanni Mascellani 
---
 libavcodec/evc_ps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/evc_ps.c b/libavcodec/evc_ps.c
index 637572d324..6c871e965e 100644
--- a/libavcodec/evc_ps.c
+++ b/libavcodec/evc_ps.c
@@ -87,6 +87,10 @@ static int vui_parameters(GetBitContext *gb, VUIParameters 
*vui)
 if (vui->aspect_ratio_idc == EXTENDED_SAR) {
 vui->sar_width = get_bits(gb, 16);
 vui->sar_height = get_bits(gb, 16);
+if (vui->sar_width == 0 || vui->sar_height == 0) {
+vui->sar_width = 1;
+vui->sar_height = 1;
+}
 }
 }
 vui->overscan_info_present_flag = get_bits(gb, 1);
-- 
2.45.2

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

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

Re: [FFmpeg-devel] [PATCH] Revert "lavf/vf_setpts: unset output framerate"

2024-07-30 Thread Anton Khirnov

Quoting Arkadiusz Hiler (2024-07-30 14:19:25)
> This reverts commit 43fd3d5df6a19fc768a33e37855aa7f8c7050cf0.

Rejected, unsetting framerate is in general correct.

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

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

[FFmpeg-devel] [PATCH] lavu/riscv: Fallback to getauxval() for cpu flags

2024-07-30 Thread Nathan E. Egge

Signed-off-by: Nathan E. Egge 
---
 libavutil/riscv/cpu.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
index e035f4b024..13b939b9d9 100644
--- a/libavutil/riscv/cpu.c
+++ b/libavutil/riscv/cpu.c
@@ -90,7 +90,8 @@ int ff_get_cpu_flags_riscv(void)
 default:
 }
 }
-#elif HAVE_GETAUXVAL
+#endif
+#if HAVE_GETAUXVAL
 {
 const unsigned long hwcap = getauxval(AT_HWCAP);
 
@@ -100,14 +101,16 @@ int ff_get_cpu_flags_riscv(void)
 ret |= AV_CPU_FLAG_RVF;
 if (hwcap & HWCAP_RV('D'))
 ret |= AV_CPU_FLAG_RVD;
-if (hwcap & HWCAP_RV('B'))
-ret |= AV_CPU_FLAG_RVB_ADDR | AV_CPU_FLAG_RVB_BASIC |
-   AV_CPU_FLAG_RVB;
 
 /* The V extension implies all Zve* functional subsets */
 if (hwcap & HWCAP_RV('V'))
  ret |= AV_CPU_FLAG_RVV_I32 | AV_CPU_FLAG_RVV_I64
   | AV_CPU_FLAG_RVV_F32 | AV_CPU_FLAG_RVV_F64;
+
+/* The V extension implies Zb* on all existing hardware */
+if (hwcap & (HWCAP_RV('B') | HWCAP_RV('V')))
+ret |= AV_CPU_FLAG_RVB_ADDR | AV_CPU_FLAG_RVB_BASIC |
+   AV_CPU_FLAG_RVB;
 }
 #endif
 
-- 
2.45.1

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

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

[FFmpeg-devel] [PATCH 0/2] some cleanups for compat/w32dlfcn.h

2024-07-30 Thread Ramiro Polla

I have only tested that it builds, but not that it runs on a real
Windows system.

Ramiro Polla (2):
  compat/w32dlfcn: remove backup definitions for safe LoadLibrary flags
  compat/w32dlfcn: remove support for pre-KB2533623 Win7 systems

 compat/w32dlfcn.h | 58 ---
 1 file changed, 58 deletions(-)

-- 
2.30.2

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

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

[FFmpeg-devel] [PATCH 2/2] compat/w32dlfcn: remove support for pre-KB2533623 Win7 systems

2024-07-30 Thread Ramiro Polla

The KB2533623 security update has been released 13 years ago and
Windows 7 has reached end of extended support 4 years ago.
---
 compat/w32dlfcn.h | 52 ---
 1 file changed, 52 deletions(-)

diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index 8ae718f4bd..856ad74cc1 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -68,58 +68,6 @@ static inline HMODULE win32_dlopen(const char *name)
 HMODULE module = NULL;
 if (utf8towchar(name, &name_w))
 name_w = NULL;
-#if _WIN32_WINNT < 0x0602
-// On Win7 and earlier we check if KB2533623 is available
-if (!GetProcAddress(GetModuleHandleW(L"kernel32.dll"), 
"SetDefaultDllDirectories")) {
-wchar_t *path = NULL, *new_path;
-DWORD pathlen, pathsize, namelen;
-if (!name_w)
-goto exit;
-namelen = wcslen(name_w);
-// Try local directory first
-path = get_module_filename(NULL);
-if (!path)
-goto exit;
-new_path = wcsrchr(path, '\\');
-if (!new_path)
-goto exit;
-pathlen = new_path - path;
-pathsize = pathlen + namelen + 2;
-new_path = av_realloc_array(path, pathsize, sizeof *path);
-if (!new_path)
-goto exit;
-path = new_path;
-wcscpy(path + pathlen + 1, name_w);
-module = LoadLibraryExW(path, NULL, LOAD_WITH_ALTERED_SEARCH_PATH);
-if (module == NULL) {
-// Next try System32 directory
-pathlen = GetSystemDirectoryW(path, pathsize);
-if (!pathlen)
-goto exit;
-// Buffer is not enough in two cases:
-// 1. system directory + \ + module name
-// 2. system directory even without the module name.
-if (pathlen + namelen + 2 > pathsize) {
-pathsize = pathlen + namelen + 2;
-new_path = av_realloc_array(path, pathsize, sizeof *path);
-if (!new_path)
-goto exit;
-path = new_path;
-// Query again to handle the case #2.
-pathlen = GetSystemDirectoryW(path, pathsize);
-if (!pathlen)
-goto exit;
-}
-path[pathlen] = L'\\';
-wcscpy(path + pathlen + 1, name_w);
-module = LoadLibraryExW(path, NULL, LOAD_WITH_ALTERED_SEARCH_PATH);
-}
-exit:
-av_free(path);
-av_free(name_w);
-return module;
-}
-#endif
 #if HAVE_WINRT
 if (!name_w)
 return NULL;
-- 
2.30.2

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

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

[FFmpeg-devel] [PATCH 1/2] compat/w32dlfcn: remove backup definitions for safe LoadLibrary flags

2024-07-30 Thread Ramiro Polla

Since we now expect C17, it is safe to assume that the toolchain will
have these flags defined.
---
 compat/w32dlfcn.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index ac20e83a7a..8ae718f4bd 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -120,12 +120,6 @@ exit:
 return module;
 }
 #endif
-#ifndef LOAD_LIBRARY_SEARCH_APPLICATION_DIR
-#   define LOAD_LIBRARY_SEARCH_APPLICATION_DIR 0x0200
-#endif
-#ifndef LOAD_LIBRARY_SEARCH_SYSTEM32
-#   define LOAD_LIBRARY_SEARCH_SYSTEM320x0800
-#endif
 #if HAVE_WINRT
 if (!name_w)
 return NULL;
-- 
2.30.2

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

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

Re: [FFmpeg-devel] [PATCH v3 2/2] libavformat/vapoursynth: Update to API version 4, load library at runtime

2024-07-30 Thread Ramiro Polla

On Mon, Jul 29, 2024 at 5:56 AM Stefan Oltmanns via ffmpeg-devel
 wrote:
> Am 28.07.24 um 15:15 schrieb Ramiro Polla:
> > I think calling win32_dlopen() with a full path will be problematic for
> > systems without KB2533623. win32_dlopen() might need to be fixed in a
> > separate patch.
>
> Yes, win32_dlopen would need to check if a full path is already given
> and if yes skip all the stuff to determine it's own and system32 path,
> but instead just use the given parameter directly. To check if it's a
> full path it should be enough to check if it either starts with "\??\"
> (NT-style path) or if the second character is ":" (win32 style path).
>
> But is this really is needed for an operating system that reached
> support end over 4 years ago and does not have a security patch applied
> released over 13 years ago?
> I don't know what ffmpeg's exact policy is in this case, just asking.

Makes sense. I sent a patchset to clean this, but I haven't been able
to test on a real Windows system.

I'll test the vapoursynth patches later on Linux.

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

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

[FFmpeg-devel] [PATCH] avformat/mov: support sidx reference_type = 1

2024-07-30 Thread jiangjie

---
 libavformat/mov.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1052691936..38f015a766 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5964,11 +5964,10 @@ static int mov_read_sidx(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 int index;
 MOVFragmentStreamInfo * frag_stream_info;
 uint32_t size = avio_rb32(pb);
+// ReferenceType = (size & (1 << 31)) ? 1 : 0
+size = size & 0x7FFF;
+
 uint32_t duration = avio_rb32(pb);
-if (size & 0x8000) {
-avpriv_request_sample(c->fc, "sidx reference_type 1");
-return AVERROR_PATCHWELCOME;
-}
 avio_rb32(pb); // sap_flags
 timestamp = av_rescale_q(pts, timescale, st->time_base);
 
-- 
2.43.0

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

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

Re: [FFmpeg-devel] [PATCH 2/2] compat/w32dlfcn: remove support for pre-KB2533623 Win7 systems

2024-07-30 Thread Rémi Denis-Courmont

Le tiistaina 30. heinäkuuta 2024, 17.09.15 EEST Ramiro Polla a écrit :
> The KB2533623 security update has been released 13 years ago and
> Windows 7 has reached end of extended support 4 years ago.

No objections, but what will this imply in terms of which Windows versions 
FFmpeg supports?

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



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

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

Re: [FFmpeg-devel] [PATCH 1/2] compat/w32dlfcn: remove backup definitions for safe LoadLibrary flags

2024-07-30 Thread James Almer


On 7/30/2024 11:09 AM, Ramiro Polla wrote:

Since we now expect C17, it is safe to assume that the toolchain will
have these flags defined.


We expect C11, but probe for C17 and use it if available.


---
  compat/w32dlfcn.h | 6 --
  1 file changed, 6 deletions(-)

diff --git a/compat/w32dlfcn.h b/compat/w32dlfcn.h
index ac20e83a7a..8ae718f4bd 100644
--- a/compat/w32dlfcn.h
+++ b/compat/w32dlfcn.h
@@ -120,12 +120,6 @@ exit:
  return module;
  }
  #endif
-#ifndef LOAD_LIBRARY_SEARCH_APPLICATION_DIR
-#   define LOAD_LIBRARY_SEARCH_APPLICATION_DIR 0x0200
-#endif
-#ifndef LOAD_LIBRARY_SEARCH_SYSTEM32
-#   define LOAD_LIBRARY_SEARCH_SYSTEM320x0800
-#endif
  #if HAVE_WINRT
  if (!name_w)
  return NULL;

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

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

Re: [FFmpeg-devel] [PATCH] lavu/riscv: Fallback to getauxval() for cpu flags

2024-07-30 Thread Rémi Denis-Courmont

Le tiistaina 30. heinäkuuta 2024, 17.07.52 EEST Nathan E. Egge a écrit :
> Signed-off-by: Nathan E. Egge 
> ---
>  libavutil/riscv/cpu.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
> index e035f4b024..13b939b9d9 100644
> --- a/libavutil/riscv/cpu.c
> +++ b/libavutil/riscv/cpu.c
> @@ -90,7 +90,8 @@ int ff_get_cpu_flags_riscv(void)
>  default:
>  }
>  }
> -#elif HAVE_GETAUXVAL
> +#endif
> +#if HAVE_GETAUXVAL

I don't see the point in doing that. If  and/or  
exist, the target is the upstream GNU/Linux ABI. That being the case, falling 
back to the auxillary vector is pointless, as noted in previous commits.

The Canaan (5.10) and SpacemiT (6.1) vendor forks of the Linux kernel do not 
have those two headers and their SDK should take the HAVE_GETAUXVAL branch as 
things stand already.

The `elif` there is meant to drop nominally useless code whilst also not 
mistaking the XTheadVector extension for proper RVV on T-Head vendor kernels. 
This patch reintroduces the problem.

>  {
>  const unsigned long hwcap = getauxval(AT_HWCAP);
> 
> @@ -100,14 +101,16 @@ int ff_get_cpu_flags_riscv(void)
>  ret |= AV_CPU_FLAG_RVF;
>  if (hwcap & HWCAP_RV('D'))
>  ret |= AV_CPU_FLAG_RVD;
> -if (hwcap & HWCAP_RV('B'))
> -ret |= AV_CPU_FLAG_RVB_ADDR | AV_CPU_FLAG_RVB_BASIC |
> -   AV_CPU_FLAG_RVB;

This would break B detection on the presumptive OpenBSD and FreeBSD ABIs.

>  /* The V extension implies all Zve* functional subsets */
>  if (hwcap & HWCAP_RV('V'))
>   ret |= AV_CPU_FLAG_RVV_I32 | AV_CPU_FLAG_RVV_I64
> 
>| AV_CPU_FLAG_RVV_F32 | AV_CPU_FLAG_RVV_F64;
> 
> +
> +/* The V extension implies Zb* on all existing hardware */
> +if (hwcap & (HWCAP_RV('B') | HWCAP_RV('V')))
> +ret |= AV_CPU_FLAG_RVB_ADDR | AV_CPU_FLAG_RVB_BASIC |
> +   AV_CPU_FLAG_RVB;

Normally I would say that this belongs in a separate commit. But this 
contradicts the ISA specifications as well as the semantics Linux interfaces 
and, again, the presumptive BSD interfaces.

This does work on all of the two bits of *contemporary* commercially available 
*silicon*. This does breaks some correct emulator and simulator 
implementations though, and we have no warranties that this won't break some 
real hardware in the future. And indeed, this would break pure RVA22 hardware.

>  }
>  #endif

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



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

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

Re: [FFmpeg-devel] [PATCH 2/2] compat/w32dlfcn: remove support for pre-KB2533623 Win7 systems

2024-07-30 Thread Ramiro Polla

On Tue, Jul 30, 2024 at 5:17 PM Rémi Denis-Courmont  wrote:
> Le tiistaina 30. heinäkuuta 2024, 17.09.15 EEST Ramiro Polla a écrit :
> > The KB2533623 security update has been released 13 years ago and
> > Windows 7 has reached end of extended support 4 years ago.
>
> No objections, but what will this imply in terms of which Windows versions
> FFmpeg supports?

Calls to dlopen() with non-absolute and non-relative paths (i.e.: just
the module name) on systems with Windows 7 which do not have the
security update KB2533623 (and systems older than Windows 7) will not
restrict the search path to the executable's directory and the system
directory. They will instead use the default search order.

This will affect avisynth, mfenc, amfenc, vsrc_ddagrab, and
hwcontext_{d3d11va,d3d12va,dxva2,vaapi,vulkan}.

So support remains the same (all will still run), but for the older
systems security will be a bit more relaxed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCHv2] lavc/h264dsp: stick R-V V biweight to 16-bit

2024-07-30 Thread Rémi Denis-Courmont

T-Head C908 (ns):
h264_biweight2_8_c:2414.5
h264_biweight2_8_rvv_i32:   701.8 (before)
h264_biweight2_8_rvv_i32:   468.5 (after)
h264_biweight4_8_c:4655.3
h264_biweight4_8_rvv_i32:  1377.5 (before)
h264_biweight4_8_rvv_i32:   931.8 (after)
h264_biweight8_8_c:9701.5
h264_biweight8_8_rvv_i32:  2896.0 (before)
h264_biweight8_8_rvv_i32:  2070.5 (after)
h264_biweight16_8_c:  18025.0
h264_biweight16_8_rvv_i32: 3460.8 (before)
h264_biweight16_8_rvv_i32: 1978.0 (after)

SpacemiT X60 (ns):
h264_biweight2_8_c:2415.5
h264_biweight2_8_rvv_i32:   478.2 (before)
h264_biweight2_8_rvv_i32:   362.8 (after)
h264_biweight4_8_c:4655.3
h264_biweight4_8_rvv_i32:   946.7 (before)
h264_biweight4_8_rvv_i32:   727.3 (after)
h264_biweight8_8_c:9061.8
h264_biweight8_8_rvv_i32:  2071.7 (before)
h264_biweight8_8_rvv_i32:  1685.8 (after)
h264_biweight16_8_c:  18020.5
h264_biweight16_8_rvv_i32: 3457.2 (before)
h264_biweight16_8_rvv_i32: 1935.8 (after)
---
 libavcodec/riscv/h264dsp_rvv.S | 43 +++---
 1 file changed, 19 insertions(+), 24 deletions(-)

diff --git a/libavcodec/riscv/h264dsp_rvv.S b/libavcodec/riscv/h264dsp_rvv.S
index a38bf7ef1d..0e08de43e4 100644
--- a/libavcodec/riscv/h264dsp_rvv.S
+++ b/libavcodec/riscv/h264dsp_rvv.S
@@ -56,22 +56,21 @@ func ff_h264_biweight_pixels_simple_8_rvv, zve32x
 addia7, a7, 1
 ori a7, a7, 1
 sll a7, a7, a4
+addia4, a4, 1
 1:
-vsetvli zero, t6, e32, m4, ta, ma
+vsetvli zero, t6, e16, m2, ta, ma
 vle8.v  v8, (a0)
 addia3, a3, -1
 vle8.v  v12, (a1)
 add a1, a1, a2
 vmv.v.x v16, a7
-vsetvli zero, zero, e16, m2, ta, ma
-vzext.vf2   v24, v8
-vzext.vf2   v28, v12
-vwmaccsu.vx v16, a5, v24
-vwmaccsu.vx v16, a6, v28
-vnclip.wx   v16, v16, a4
+vsetvli zero, zero, e8, m1, ta, ma
+vwmaccsu.vx v16, a5, v8
+vwmaccsu.vx v16, a6, v12
+vsetvli zero, zero, e16, m2, ta, ma
 vmax.vx v16, v16, zero
 vsetvli zero, zero, e8, m1, ta, ma
-vnclipu.wi  v8, v16, 1
+vnclipu.wx  v8, v16, a4
 vse8.v  v8, (a0)
 add a0, a0, a2
 bneza3, 1b
@@ -121,33 +120,29 @@ func ff_h264_biweight_pixels_8_rvv, zve32x
 addia7, a7, 1
 ori a7, a7, 1
 sll a7, a7, a4
+addia4, a4, 1
 1:
 mv  t0, a0
 mv  t1, a1
 mv  t5, t6
 2:
-vsetvli t2, a3, e32, m8, ta, ma
+vsetvli t2, a3, e16, m8, ta, ma
 vlsseg2e8.v v0, (t0), a2
-vlsseg2e8.v v4, (t1), a2
+vlsseg2e8.v v8, (t1), a2
 addit5, t5, -2
 vmv.v.x v16, a7
 vmv.v.x v24, a7
-vsetvli zero, zero, e16, m4, ta, ma
-vzext.vf2   v8, v0
-vzext.vf2   v12, v2
-vwmaccsu.vx v16, a5, v8
-vwmaccsu.vx v24, a5, v12
-vzext.vf2   v8, v4
-vzext.vf2   v12, v6
+vsetvli zero, zero, e8, m4, ta, ma
+vwmaccsu.vx v16, a5, v0
+vwmaccsu.vx v24, a5, v4
 vwmaccsu.vx v16, a6, v8
 vwmaccsu.vx v24, a6, v12
-vnclip.wx   v8, v16, a4
-vnclip.wx   v12, v24, a4
-vmax.vx v8, v8, zero
-vmax.vx v12, v12, zero
-vsetvli zero, zero, e8, m2, ta, ma
-vnclipu.wi  v0, v8, 1
-vnclipu.wi  v2, v12, 1
+vsetvli zero, zero, e16, m8, ta, ma
+vmax.vx v16, v16, zero
+vmax.vx v24, v24, zero
+vsetvli zero, zero, e8, m4, ta, ma
+vnclipu.wx  v0, v16, a4
+vnclipu.wx  v4, v24, a4
 vssseg2e8.v v0, (t0), a2
 addit0, t0, 2
 addit1, t1, 2
-- 
2.45.2

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

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

Re: [FFmpeg-devel] [PATCH] avformat/mov: support sidx reference_type = 1

2024-07-30 Thread James Almer


On 7/30/2024 11:56 AM, jiangjie wrote:

---
  libavformat/mov.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index 1052691936..38f015a766 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -5964,11 +5964,10 @@ static int mov_read_sidx(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
  int index;
  MOVFragmentStreamInfo * frag_stream_info;
  uint32_t size = avio_rb32(pb);
+// ReferenceType = (size & (1 << 31)) ? 1 : 0
+size = size & 0x7FFF;
+
  uint32_t duration = avio_rb32(pb);
-if (size & 0x8000) {
-avpriv_request_sample(c->fc, "sidx reference_type 1");
-return AVERROR_PATCHWELCOME;
-}


Per the spec:

"Each entry in the SegmentIndexBox contains a reference type that 
indicates whether the reference points directly to the media bytes of a 
referenced leaf subsegment, or to a SegmentIndexBox that describes how 
the referenced subsegment is further subdivided; as a result, the 
segment may be indexed in a ‘hierarchical’ or ‘daisy-chain’ or other 
form by documenting time and byte offset information for other 
SegmentIndexBoxes applying to portions of the same (sub)segment"


And

"reference_type set to 1 indicates that the reference is to a 
SegmentIndexBox; otherwise the reference is to media content (e.g., in 
the case of files based on this document, to a MovieFragmentBox); if a 
separate index segment is used, then entries with reference type 1 are 
in the index segment, and entries with reference type 0 are in the media 
file".


All the code below this part assumes movie fragment, not another sidx 
box, so this patch is just ignoring the reference_type bit and thus is 
not correct.

Proper support for reference_type == 1 is needed.


  avio_rb32(pb); // sap_flags
  timestamp = av_rescale_q(pts, timescale, st->time_base);
  

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

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

[FFmpeg-devel] [PATCH] lavc/h264dsp: stick R-V V weight to 16-bit precision

2024-07-30 Thread Rémi Denis-Courmont

T-Head C908 (ns):
h264_weight2_8_c:1607.8
h264_weight2_8_rvv_i32:   515.0 (before)
h264_weight2_8_rvv_i32:   348.5 (after)
h264_weight4_8_c:2255.8
h264_weight4_8_rvv_i32:  1015.0 (before)
h264_weight4_8_rvv_i32:   691.0 (after)
h264_weight8_8_c:3857.5
h264_weight8_8_rvv_i32:  2218.8 (before)
h264_weight8_8_rvv_i32:  1561.3 (after)
h264_weight16_8_c:   7431.5
h264_weight16_8_rvv_i32: 2737.3 (before)
h264_weight16_8_rvv_i32: 1848.3 (after)

SpacemiT X60 (ns):
h264_weight2_8_c:1624.1
h264_weight2_8_rvv_i32:   352.6 (before)
h264_weight2_8_rvv_i32:   259.3 (after)
h264_weight4_8_c:2259.3
h264_weight4_8_rvv_i32:   685.8 (before)
h264_weight4_8_rvv_i32:   530.3 (after)
h264_weight8_8_c:4103.3
h264_weight8_8_rvv_i32:  1581.8 (before)
h264_weight8_8_rvv_i32:  1238.6 (after)
h264_weight16_8_c:   7624.3
h264_weight16_8_rvv_i32: 2738.1 (before)
h264_weight16_8_rvv_i32: 1853.3 (after)
---
 libavcodec/riscv/h264dsp_rvv.S | 37 +++---
 1 file changed, 16 insertions(+), 21 deletions(-)

diff --git a/libavcodec/riscv/h264dsp_rvv.S b/libavcodec/riscv/h264dsp_rvv.S
index 0e08de43e4..0d641008cb 100644
--- a/libavcodec/riscv/h264dsp_rvv.S
+++ b/libavcodec/riscv/h264dsp_rvv.S
@@ -32,17 +32,15 @@ func ff_h264_weight_pixels_simple_8_rvv, zve32x
 csrwi   vxrm, 0
 sll a5, a5, a3
 1:
-vsetvli zero, a6, e32, m4, ta, ma
+vsetvli zero, a6, e16, m2, ta, ma
 vle8.v  v8, (a0)
 addia2, a2, -1
-vmv.v.x v16, a5
-vsetvli zero, zero, e16, m2, ta, ma
 vzext.vf2   v24, v8
-vwmaccsu.vx v16, a4, v24
-vnclip.wx   v16, v16, a3
+vmul.vx v16, v24, a4
+vsadd.vxv16, v16, a5
 vmax.vx v16, v16, zero
 vsetvli zero, zero, e8, m1, ta, ma
-vnclipu.wi  v8, v16, 0
+vnclipu.wx  v8, v16, a3
 vse8.v  v8, (a0)
 add a0, a0, a1
 bneza2, 1b
@@ -85,23 +83,20 @@ func ff_h264_weight_pixels_8_rvv, zve32x
 mv  t0, a0
 mv  t6, a6
 2:
-vsetvli t2, a2, e32, m8, ta, ma
+vsetvli t2, a2, e16, m8, ta, ma
 vlsseg2e8.v v0, (t0), a1
 addit6, t6, -2
-vmv.v.x v16, a5
-vmv.v.x v24, a5
-vsetvli zero, zero, e16, m4, ta, ma
-vzext.vf2   v8, v0
-vzext.vf2   v12, v2
-vwmaccsu.vx v16, a4, v8
-vwmaccsu.vx v24, a4, v12
-vnclip.wx   v8, v16, a3
-vnclip.wx   v12, v24, a3
-vmax.vx v8, v8, zero
-vmax.vx v12, v12, zero
-vsetvli zero, zero, e8, m2, ta, ma
-vnclipu.wi  v0, v8, 0
-vnclipu.wi  v2, v12, 0
+vzext.vf2   v16, v0
+vzext.vf2   v24, v4
+vmul.vx v16, v16, a4
+vmul.vx v24, v24, a4
+vsadd.vxv16, v16, a5
+vsadd.vxv24, v24, a5
+vmax.vx v16, v16, zero
+vmax.vx v24, v24, zero
+vsetvli zero, zero, e8, m4, ta, ma
+vnclipu.wx  v0, v16, a3
+vnclipu.wx  v4, v24, a3
 vssseg2e8.v v0, (t0), a1
 addit0, t0, 2
 bnezt6, 2b
-- 
2.45.2

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

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

Re: [FFmpeg-devel] [PATCH 1/4] lavc/vp8dsp: R-V V 256 bilin,epel

2024-07-30 Thread flow gg

Hi, these four patches have v2 (although the first one seems to be the
same).

From my understanding, moving from supporting only 128b to adding 256b
versions can simultaneously improve LMUL and solve some issues related to
insufficient vector registers (vvc, vp9).
This can be very helpful in certain situations.

If we continue to support 512, 1024, ..., it almost exclusively improves
LMUL. Therefore, 256b is the most worthwhile addition, and we can skip
adding 512b, 1024b, etc.

Additionally, even though longer hardware will continually be developed,
the most used will probably still be 128b and 256b.
If someone complains that FFmpeg's RVV doesn't support 1024b well, it can
be said that it's not just RISC-V that lacks good support.
However, if the 256b performance is not good, then it seems like an issue
with RISC-V. :)

I think maybe we can give some preference to the two smallest lengths?

Rémi Denis-Courmont  于2024年7月29日周一 22:45写道：

> Hi,
>
> Le lauantaina 22. kesäkuuta 2024, 18.58.03 EEST u...@foxmail.com a écrit :
> > From: sunyuechi 
>
> In my opinion, we can't keep on like this. By the end of year, there will
> also
> be 512-bit vector hardware. In the worst case, specialisation on vector
> length
> could require 7 variants of every function, as many as legal LMUL values.
>
> Generating the LMUL at run time or initialisation time is too slow for
> fixed-
> size functions, so I can only see two viable options here:
>
> 1) We ignore this problem entirely and only optimise to 128-bit or to the
> current minimum VLEN. The intent of the specification is ostensibly that
> processing should scale according to the current value of VL, not
> VTYPE.LMUL.
> That is why the minimum legal LMUL value is SEW/ELEN rather than 1/VLMAX
> (and
> draft versions did not even have fractional multipliers).
>
> 2) The specialisation code is heavily factored, including in the C
> initialisation side.
>
> Personally, I prefer to ignore the problem until we see more mature and
> varied
> hardware. I do note that SiFive is ostensibly not specialising their code
> by
> VLEN, which tends to confirm that this is just a case of immature design
> from
> T-Head.
>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] fftools/ffmpeg: show video stats in progress output without filters

2024-07-30 Thread Jan Garcia via ffmpeg-devel

Since ffmpeg 6.1 video stats are accidentally hidden from progress output
if no filters are used.
This patch re-enables video stats (like frames=) in the progress output.
---
 Changelog| 1 +
 fftools/ffmpeg.c | 8 +---
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Changelog b/Changelog
index 571b27ad98..2c2cbf9179 100644
--- a/Changelog
+++ b/Changelog
@@ -5,6 +5,7 @@ version :
 - Raw Captions with Time (RCWT) closed caption demuxer
 - LC3/LC3plus decoding/encoding using external library liblc3
 - ffmpeg CLI filtergraph chaining
+- ffmpeg CLI again shows video stats in progress output
 - LC3/LC3plus demuxer and muxer
 - pad_vaapi, drawbox_vaapi filters
 - vf_scale supports secondary ref input and framesync options
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 3aa2e12780..420ba3c6e4 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -587,7 +587,7 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 av_bprintf(&buf_script, "stream_%d_%d_q=%.1f\n",
ost->file->index, ost->index, q);
 }
-if (!vid && ost->type == AVMEDIA_TYPE_VIDEO && ost->filter) {
+if (!vid && ost->type == AVMEDIA_TYPE_VIDEO) {
 float fps;
 uint64_t frame_number = atomic_load(&ost->packets_written);
 
@@ -601,8 +601,10 @@ static void print_report(int is_last_report, int64_t 
timer_start, int64_t cur_ti
 if (is_last_report)
 av_bprintf(&buf, "L");
 
-nb_frames_dup  = atomic_load(&ost->filter->nb_frames_dup);
-nb_frames_drop = atomic_load(&ost->filter->nb_frames_drop);
+if (ost->filter) {
+nb_frames_dup  = atomic_load(&ost->filter->nb_frames_dup);
+nb_frames_drop = atomic_load(&ost->filter->nb_frames_drop);
+}
 
 vid = 1;
 }
-- 
2.44.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 v2] libavfilter: add PipeWire-based grab

2024-07-30 Thread François-Simon Fauteux-Chapleau

- On Jul 28, 2024, at 10:53 AM, Quack Doc quackdoct...@gmail.com wrote:
> Is it possible to use this without using the portals API and without
> systemd? That would be much appreciated if so since the portal is not very
> flexible.

I don't like the portals API either and would rather not have to use it, but
as far as I can tell there is no alternative. All the other projects that
use PipeWire for screen capture that I've looked at (e.g. WebRTC, OBS Studio)
use it, and according to the XDG Desktop Portal documentation,
"the primary way of capturing screens and windows on Wayland desktops is
through the ScreenCast portal, and some desktop environments don’t even expose
other means to capture the screen or windows."
(https://flatpak.github.io/xdg-desktop-portal/docs/reasons-to-use-portals.html)

> As for systemd it would be great to be able to use this on
> non-systemd platforms.

Using the ScreenCast portal requires an XDG Desktop Portal backend
implementation, see e.g.
https://wiki.archlinux.org/title/XDG_Desktop_Portal
https://flatpak.github.io/xdg-desktop-portal/docs/writing-a-new-backend.html
I don't know if any backend currently supports non-systemd platforms (on my
system at least, the backend is implemented as a systemd service), but
assuming you can find one, then it should be possible to get screen capture
to work.

___
ffmpeg-devel mailing list
ffmpeg-devel@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/av1_vaapi: Enable AV1Profile2 VAAPI support.

2024-07-30 Thread David (Ming Qiang) Wu via ffmpeg-devel

AV1Profile2 VAAPI is supported and tested on AMD VCN5.

Signed-off-by: David (Ming Qiang) Wu 
---
 libavcodec/av1dec.c   | 3 +++
 libavcodec/vaapi_decode.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index 1d5b9ef4f4..77f63661a0 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -599,6 +599,9 @@ static int get_pixel_format(AVCodecContext *avctx)
 case AV_PIX_FMT_YUV420P12:
 #if CONFIG_AV1_VULKAN_HWACCEL
 *fmtp++ = AV_PIX_FMT_VULKAN;
+#endif
+#if CONFIG_AV1_VAAPI_HWACCEL
+*fmtp++ = AV_PIX_FMT_VAAPI;
 #endif
 break;
 case AV_PIX_FMT_YUV422P:
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index a59194340f..a077e47326 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -448,6 +448,9 @@ static const struct {
 MAP(AV1, AV1_MAIN,AV1Profile0),
 MAP(AV1, AV1_HIGH,AV1Profile1),
 #endif
+#if VA_CHECK_VERSION(1, 23, 0)
+MAP(AV1, AV1_PROFESSIONAL, AV1Profile2),
+#endif
 
 #undef MAP
 };
-- 
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/h264_mp4toannexb: Prepend SPS/PPS to buffering period SEI

2024-07-30 Thread Josh Allmann

On Mon, 22 Jul 2024 at 17:17, Timo Rothenpieler  wrote:
>
> On 23/07/2024 01:01, Josh Allmann wrote:
> > On Tue, 9 Jul 2024 at 12:06, Josh Allmann  wrote:
> >>
> >> Encoders may emit a buffering period SEI without a corresponding
> >> SPS/PPS if the SPS/PPS is carried out-of-band, eg with avcc.
> >>
> >> During Annex B conversion, this may result in the SPS/PPS being
> >> inserted *after* the buffering period SEI but before the IDR NAL.
> >>
> >> Since the buffering period SEI references the SPS, the SPS/PPS
> >> needs to come first.
> >> ---
> >>
> >> Notes:
> >>  v2: Updated FATE test refs
> >>
> >>   libavcodec/bsf/h264_mp4toannexb.c  | 13 +
> >>   tests/ref/fate/h264-bsf-mp4toannexb|  2 +-
> >>   tests/ref/fate/h264_mp4toannexb_ticket2991 | 18 +-
> >>   tests/ref/fate/segment-mp4-to-ts   | 12 ++--
> >>   4 files changed, 29 insertions(+), 16 deletions(-)
> >>
> >
> > Ping again for review. Looking at the FATE output, this patch fixes a number
> > of things - see [1] for details
>
> patch generally looks good to me, but I'm not closely familiar with the
> code there.
>

Thanks, is there anyone else more familiar with the code who can also
sign off on this patch?

Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v4 1/3] avcodec/jpeg2000dec: Add support for CAP and CPF markers

2024-07-30 Thread Tomas Härdin

fre 2024-07-26 klockan 23:29 +0200 skrev Michael Niedermayer:
> On Thu, Jul 25, 2024 at 05:06:04PM -0700, Pierre-Anthony Lemieux
> wrote:
> > On Thu, Jul 25, 2024 at 2:17 AM Tomas Härdin 
> > wrote:
> > > 
> > > sön 2024-07-21 klockan 14:07 +0900 skrev Pierre-Anthony Lemieux:
> > > > On Sat, Jul 20, 2024 at 5:12 PM Tomas Härdin 
> > > > wrote:
> > > > > 
> > > > > tor 2024-07-18 klockan 23:10 +0900 skrev Pierre-Anthony
> > > > > Lemieux:
> > > > > > On Mon, Jul 15, 2024 at 10:33 PM Tomas Härdin
> > > > > > 
> > > > > > wrote:
> > > > > > > 
> > > > > > > fre 2024-07-12 klockan 12:51 -0700 skrev Pierre-Anthony
> > > > > > > Lemieux:
> > > > > > > > On Thu, Jul 11, 2024 at 10:28 PM Tomas Härdin
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > 
> > > > > > > > > > +    if (s->in_tile_headers == 1 && s->isHT
> > > > > > > > > > &&
> > > > > > > > > > (!s-
> > > > > > > > > > > Ccap15_b11))
> > > > > > > > > > +    av_log(s->avctx, AV_LOG_WARNING,
> > > > > > > > > > "COD
> > > > > > > > > > marker
> > > > > > > > > > is
> > > > > > > > > > found in HOMOGENEOUS HT set\n");
> > > > > > > > > 
> > > > > > > > > How bad is this and the other markers being present
> > > > > > > > > in this
> > > > > > > > > case?
> > > > > > > > 
> > > > > > > > At the very least, it means that signaling is
> > > > > > > > inconsistent
> > > > > > > > within
> > > > > > > > the
> > > > > > > > codestream since the standard states that:
> > > > > > > > """
> > > > > > > > The HOMOGENEOUS set is the set of HTJ2K codestreams
> > > > > > > > where:
> > > > > > > > • none of the functional marker segments, e.g., COD,
> > > > > > > > COC,
> > > > > > > > RGN,
> > > > > > > > QCD,
> > > > > > > > QCC, and POC, are present in any
> > > > > > > > tile-part header; and
> > > > > > > > • no PPT marker segment is present.
> > > > > > > > """
> > > > > > > > 
> > > > > > > > The point of signalling that a codestream is
> > > > > > > > "HOMOGENEOUS" is
> > > > > > > > to
> > > > > > > > allow
> > > > > > > > decoders to configure themselves solely based on
> > > > > > > > information
> > > > > > > > retrieved
> > > > > > > > entirely from the main header.
> > > > > > > > 
> > > > > > > > Since, AFAIK, FFMPEG does not rely on the HOMOGENEOUS
> > > > > > > > to
> > > > > > > > short-
> > > > > > > > circuit
> > > > > > > > configuration, incorrect HOMOGENEOUS signalling will
> > > > > > > > likely
> > > > > > > > not
> > > > > > > > impact
> > > > > > > > FFMPEG.
> > > > > > > 
> > > > > > > It could happen that information in tile headers
> > > > > > > contradict
> > > > > > > information
> > > > > > > in the main header, right? In such a case it sounds like
> > > > > > > we
> > > > > > > can't
> > > > > > > be
> > > > > > > sure which decode is the correct one.
> > > > > > 
> > > > > > Per the spec, the decoder uses the COD information in tile-
> > > > > > parts
> > > > > > over
> > > > > > the COD information in the header.
> > > > > > 
> > > > > > The issue here is that a decoder, upon seeing HOMOGENEOUS,
> > > > > > simply
> > > > > > does
> > > > > > not bother with looking for COD information in tile-parts,
> > > > > > thereby
> > > > > > missing critical information.
> > > > > 
> > > > > So it is actually perfectly legal? Then it seems this patch
> > > > > is
> > > > > wrong
> > > > 
> > > > What is not "illegal": the HOMOGENEOUS flag being equal to true
> > > > *and*
> > > > having COD marker segments in tile-parts.
> > > > 
> > > > This is what the patch detects.
> > > > 
> > > > FFMPEG can decode such illegal codestream. Other decoders might
> > > > not.
> > > > 
> > > > The question is: what should FFMPEG do? Should FFMPEG exit or
> > > > warn
> > > > and continue.
> > > 
> > > If the spec allows it but it's perhaps unadviced then warning
> > > about it
> > > seems reasonable
> > 
> > (I totally messed up my double negative. Repeat below. Sorry for
> > the confusion.)
> > 
> > What is "illegal": the HOMOGENEOUS flag being equal to true *and*
> > having COD marker segments in tile-parts.
> > 
> > This is what the patch detects.
> > 
> > FFMPEG can decode such illegal codestream. Other decoders might
> > not.
> > 
> > The question is: what should FFMPEG do? Should FFMPEG exit or warn
> > and continue.
> 
> Does such a codestream actually exist ? I mean is this just a
> hypothetical case
> or something existing ?

This is more to stem the stream before anything happens because we were
lax with parsing

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

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

Re: [FFmpeg-devel] [PATCH v2 1/1] lavfi/vf_gopromax_opencl: add GoPor Max 360 video filter

2024-07-30 Thread Michael Niedermayer

On Mon, Jul 29, 2024 at 01:30:34AM +0900, TADANO Tokumei wrote:
> On 2024/07/28 18:26, Michael Niedermayer wrote:
> > On Sun, Jul 28, 2024 at 01:42:09AM +0900, TADANO Tokumei wrote:
> > > 
> > > On 2024/07/27 13:30, TADANO Tokumei wrote:
> > > > Add an OpenCL filter for filtering GoPro Max native .360 files
> > > > into standard equirectangular or youtube equiangular cubemap (eac)
> > > > projection.
> > > > 
> > > > The .360 file contains separated two video streams.
> > > > This filter combine two streams into single stream with standard
> > > > format.
> > > > ---
> > > >doc/filters.texi |  78 +++
> > > >libavfilter/Makefile |   2 +
> > > >libavfilter/allfilters.c |   1 +
> > > >libavfilter/opencl/gopromax.cl   | 280 
> > > >libavfilter/opencl_source.h  |   1 +
> > > >libavfilter/vf_gopromax_opencl.c | 351 
> > > > +++
> > > >6 files changed, 713 insertions(+)
> > > >create mode 100644 libavfilter/opencl/gopromax.cl
> > > >create mode 100644 libavfilter/vf_gopromax_opencl.c
> > > 
> > > The patchwork failed, but it was caused by opencl.c (not by this patch):
> > > 
> > >   In file included from ./libavutil/common.h:48:0,
> > >   from ./libavutil/avutil.h:301,
> > >   from ./libavutil/opt.h:31,
> > >   from libavdevice/sdl2.c:31:
> > > ./config.h:335:0: warning: 'HAVE_PTHREAD_SETNAME_NP' redefined
> > >   #define HAVE_PTHREAD_SETNAME_NP 0
> > > In file included from /usr/include/SDL2/SDL_stdinc.h:31:0,
> > >   from /usr/include/SDL2/SDL_main.h:25,
> > >   from /usr/include/SDL2/SDL.h:32,
> > >   from libavdevice/sdl2.c:26:
> > > /usr/include/SDL2/SDL_config.h:186:0: note: this is the location of the 
> > > previous definition
> > >   #define HAVE_PTHREAD_SETNAME_NP 1
> > > In file included from libavfilter/opencl.h:31:0,
> > >   from libavfilter/opencl.c:26:
> > > ./libavutil/hwcontext_opencl.h:25:10: fatal error: CL/cl.h: No such file 
> > > or directory
> > >   #include
> > >^
> > > compilation terminated.
> > > make: *** [libavfilter/opencl.o] Error 1
> > 
> > with this patch it fails here on ubuntu:
> > /usr/bin/ld: libavfilter/libavfilter.a(opencl.o): undefined reference to 
> > symbol 'clBuildProgram@@OPENCL_1.0'
> > /usr/bin/ld: /usr/local/cuda/targets/x86_64-linux/lib/libOpenCL.so.1: error 
> > adding symbols: DSO missing from command line
> > 
> > thx
> 
> I tested on Ubuntu 22.04, and it works fine.

My failure was on a 20.04

thx

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

If the United States is serious about tackling the national security threats 
related to an insecure 5G network, it needs to rethink the extent to which it
values corporate profits and government espionage over security.-Bruce Schneier


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 0/2] Interpret a degenerate SAR as 1/1.

2024-07-30 Thread Michael Niedermayer

On Tue, Jul 30, 2024 at 03:11:47PM +0200, Giovanni Mascellani wrote:
> I came across some H.264 files in the wild whose SAR is set to
> 20480/0. The files are provided by the Ubisoft game OddBallers, and
> are seemingly accepted and played properly when the game is played on
> Windows (thus using the Microsoft Media Foundations
> implementation).
> 
> When running the game with Wine the files are ultimately decoded by
> libavcodec (via GStreamer), and playback is broken. It seems that only
> a frame each second or so (maybe the key frames? I didn't check) is
> decoded and presented, the others are discarded. After dumping the
> video, I ran it with ffplay and it has the same problem, and the
> following message is emitted many times:
> 
>   [h264 @ 0x7fd7301ef440] ignoring invalid SAR: 20480/1
> 
> Interestingly the invalid SAR is dumped as 20480/1 (which would be
> strange, but in princple legal), while the file has 20480/0 (which
> doesn't make sense at all). Equally interestingly, the frames that are
> presented are indeed presented with SAR 1/1, like they are on Windows.
> 
> The H.264 standard says that "When aspect_ratio_idc is equal to 0 or
> sar_width is equal to 0 or sar_height is equal to 0, the sample aspect
> ratio shall be considered unspecified by this Recommendation |
> International Standard". Given the behavior on Windows it seems that
> the de facto standard way to solve the missing specification is to
> assume that SAR is 1/1, which is what my patches seek to do.

Why does playback fail ?

1/1 and unspecified are different things, 0/0 would be unspecified
where does 20480/0 turn into 20480/1 ? or did i misunderstand this?

thx

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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 0/2] Interpret a degenerate SAR as 1/1.

2024-07-30 Thread James Almer


On 7/30/2024 5:54 PM, Michael Niedermayer wrote:

On Tue, Jul 30, 2024 at 03:11:47PM +0200, Giovanni Mascellani wrote:

I came across some H.264 files in the wild whose SAR is set to
20480/0. The files are provided by the Ubisoft game OddBallers, and
are seemingly accepted and played properly when the game is played on
Windows (thus using the Microsoft Media Foundations
implementation).

When running the game with Wine the files are ultimately decoded by
libavcodec (via GStreamer), and playback is broken. It seems that only
a frame each second or so (maybe the key frames? I didn't check) is
decoded and presented, the others are discarded. After dumping the
video, I ran it with ffplay and it has the same problem, and the
following message is emitted many times:

   [h264 @ 0x7fd7301ef440] ignoring invalid SAR: 20480/1

Interestingly the invalid SAR is dumped as 20480/1 (which would be
strange, but in princple legal), while the file has 20480/0 (which
doesn't make sense at all). Equally interestingly, the frames that are
presented are indeed presented with SAR 1/1, like they are on Windows.

The H.264 standard says that "When aspect_ratio_idc is equal to 0 or
sar_width is equal to 0 or sar_height is equal to 0, the sample aspect
ratio shall be considered unspecified by this Recommendation |
International Standard". Given the behavior on Windows it seems that
the de facto standard way to solve the missing specification is to
assume that SAR is 1/1, which is what my patches seek to do.


Why does playback fail ?

1/1 and unspecified are different things, 0/0 would be unspecified


afair we use 0/1 for unspecified, since it prevents division by 0 
without having to worry about extra sanity checks.



where does 20480/0 turn into 20480/1 ? or did i misunderstand this?

thx

[...]


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

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

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

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

Re: [FFmpeg-devel] [PATCH 0/2] Interpret a degenerate SAR as 1/1.

2024-07-30 Thread Michael Niedermayer

On Tue, Jul 30, 2024 at 06:15:30PM -0300, James Almer wrote:
> On 7/30/2024 5:54 PM, Michael Niedermayer wrote:
> > On Tue, Jul 30, 2024 at 03:11:47PM +0200, Giovanni Mascellani wrote:
> > > I came across some H.264 files in the wild whose SAR is set to
> > > 20480/0. The files are provided by the Ubisoft game OddBallers, and
> > > are seemingly accepted and played properly when the game is played on
> > > Windows (thus using the Microsoft Media Foundations
> > > implementation).
> > > 
> > > When running the game with Wine the files are ultimately decoded by
> > > libavcodec (via GStreamer), and playback is broken. It seems that only
> > > a frame each second or so (maybe the key frames? I didn't check) is
> > > decoded and presented, the others are discarded. After dumping the
> > > video, I ran it with ffplay and it has the same problem, and the
> > > following message is emitted many times:
> > > 
> > >[h264 @ 0x7fd7301ef440] ignoring invalid SAR: 20480/1
> > > 
> > > Interestingly the invalid SAR is dumped as 20480/1 (which would be
> > > strange, but in princple legal), while the file has 20480/0 (which
> > > doesn't make sense at all). Equally interestingly, the frames that are
> > > presented are indeed presented with SAR 1/1, like they are on Windows.
> > > 
> > > The H.264 standard says that "When aspect_ratio_idc is equal to 0 or
> > > sar_width is equal to 0 or sar_height is equal to 0, the sample aspect
> > > ratio shall be considered unspecified by this Recommendation |
> > > International Standard". Given the behavior on Windows it seems that
> > > the de facto standard way to solve the missing specification is to
> > > assume that SAR is 1/1, which is what my patches seek to do.
> > 
> > Why does playback fail ?
> > 
> > 1/1 and unspecified are different things, 0/0 would be unspecified
> 
> afair we use 0/1 for unspecified, since it prevents division by 0 without
> having to worry about extra sanity checks.

why this is a bad idea:

if a rectangle W/H with unspecified AR is 0/1, now the H/W rectangle has 1/0

OTOH if you use 0/0 then both W/H and H/W are naturally 0/0

what about scaling?

0/1 scaled by a/b is 0/b, while 0/0 scaled by a/b is 0/0

what about adding ratios ? 0/1 + a/b = a/b (thats not unspecified anymore)
OTOH
0/0 + a/b = 0/0 :)

so people may argue about this, but 0/0 behaves much closer to unspecified than 
0/1
so fewer special cases are needed if 0/0 is used. And 0/1 really is 0 and 0
is not unspecified in a mathematical sense which is why it works so poorly for 
that

And in floats 0/0 is NaN which is again behaving much closer to unspecified.
If you do an operation with a NaN the result is NaN, same as if you do an
operation with a unspecified ratio, the result is unspecified

Thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The smallest minority on earth is the individual. Those who deny 
individual rights cannot claim to be defenders of minorities. - Ayn Rand


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 v4 1/3] avcodec/jpeg2000dec: Add support for CAP and CPF markers

2024-07-30 Thread Michael Niedermayer

On Tue, Jul 30, 2024 at 10:22:37PM +0200, Tomas Härdin wrote:
> fre 2024-07-26 klockan 23:29 +0200 skrev Michael Niedermayer:
> > On Thu, Jul 25, 2024 at 05:06:04PM -0700, Pierre-Anthony Lemieux
> > wrote:
> > > On Thu, Jul 25, 2024 at 2:17 AM Tomas Härdin 
> > > wrote:
> > > > 
> > > > sön 2024-07-21 klockan 14:07 +0900 skrev Pierre-Anthony Lemieux:
> > > > > On Sat, Jul 20, 2024 at 5:12 PM Tomas Härdin 
> > > > > wrote:
> > > > > > 
> > > > > > tor 2024-07-18 klockan 23:10 +0900 skrev Pierre-Anthony
> > > > > > Lemieux:
> > > > > > > On Mon, Jul 15, 2024 at 10:33 PM Tomas Härdin
> > > > > > > 
> > > > > > > wrote:
> > > > > > > > 
> > > > > > > > fre 2024-07-12 klockan 12:51 -0700 skrev Pierre-Anthony
> > > > > > > > Lemieux:
> > > > > > > > > On Thu, Jul 11, 2024 at 10:28 PM Tomas Härdin
> > > > > > > > > 
> > > > > > > > > wrote:
> > > > > > > > > > 
> > > > > > > > > > > +    if (s->in_tile_headers == 1 && s->isHT
> > > > > > > > > > > &&
> > > > > > > > > > > (!s-
> > > > > > > > > > > > Ccap15_b11))
> > > > > > > > > > > +    av_log(s->avctx, AV_LOG_WARNING,
> > > > > > > > > > > "COD
> > > > > > > > > > > marker
> > > > > > > > > > > is
> > > > > > > > > > > found in HOMOGENEOUS HT set\n");
> > > > > > > > > > 
> > > > > > > > > > How bad is this and the other markers being present
> > > > > > > > > > in this
> > > > > > > > > > case?
> > > > > > > > > 
> > > > > > > > > At the very least, it means that signaling is
> > > > > > > > > inconsistent
> > > > > > > > > within
> > > > > > > > > the
> > > > > > > > > codestream since the standard states that:
> > > > > > > > > """
> > > > > > > > > The HOMOGENEOUS set is the set of HTJ2K codestreams
> > > > > > > > > where:
> > > > > > > > > • none of the functional marker segments, e.g., COD,
> > > > > > > > > COC,
> > > > > > > > > RGN,
> > > > > > > > > QCD,
> > > > > > > > > QCC, and POC, are present in any
> > > > > > > > > tile-part header; and
> > > > > > > > > • no PPT marker segment is present.
> > > > > > > > > """
> > > > > > > > > 
> > > > > > > > > The point of signalling that a codestream is
> > > > > > > > > "HOMOGENEOUS" is
> > > > > > > > > to
> > > > > > > > > allow
> > > > > > > > > decoders to configure themselves solely based on
> > > > > > > > > information
> > > > > > > > > retrieved
> > > > > > > > > entirely from the main header.
> > > > > > > > > 
> > > > > > > > > Since, AFAIK, FFMPEG does not rely on the HOMOGENEOUS
> > > > > > > > > to
> > > > > > > > > short-
> > > > > > > > > circuit
> > > > > > > > > configuration, incorrect HOMOGENEOUS signalling will
> > > > > > > > > likely
> > > > > > > > > not
> > > > > > > > > impact
> > > > > > > > > FFMPEG.
> > > > > > > > 
> > > > > > > > It could happen that information in tile headers
> > > > > > > > contradict
> > > > > > > > information
> > > > > > > > in the main header, right? In such a case it sounds like
> > > > > > > > we
> > > > > > > > can't
> > > > > > > > be
> > > > > > > > sure which decode is the correct one.
> > > > > > > 
> > > > > > > Per the spec, the decoder uses the COD information in tile-
> > > > > > > parts
> > > > > > > over
> > > > > > > the COD information in the header.
> > > > > > > 
> > > > > > > The issue here is that a decoder, upon seeing HOMOGENEOUS,
> > > > > > > simply
> > > > > > > does
> > > > > > > not bother with looking for COD information in tile-parts,
> > > > > > > thereby
> > > > > > > missing critical information.
> > > > > > 
> > > > > > So it is actually perfectly legal? Then it seems this patch
> > > > > > is
> > > > > > wrong
> > > > > 
> > > > > What is not "illegal": the HOMOGENEOUS flag being equal to true
> > > > > *and*
> > > > > having COD marker segments in tile-parts.
> > > > > 
> > > > > This is what the patch detects.
> > > > > 
> > > > > FFMPEG can decode such illegal codestream. Other decoders might
> > > > > not.
> > > > > 
> > > > > The question is: what should FFMPEG do? Should FFMPEG exit or
> > > > > warn
> > > > > and continue.
> > > > 
> > > > If the spec allows it but it's perhaps unadviced then warning
> > > > about it
> > > > seems reasonable
> > > 
> > > (I totally messed up my double negative. Repeat below. Sorry for
> > > the confusion.)
> > > 
> > > What is "illegal": the HOMOGENEOUS flag being equal to true *and*
> > > having COD marker segments in tile-parts.
> > > 
> > > This is what the patch detects.
> > > 
> > > FFMPEG can decode such illegal codestream. Other decoders might
> > > not.
> > > 
> > > The question is: what should FFMPEG do? Should FFMPEG exit or warn
> > > and continue.
> > 
> > Does such a codestream actually exist ? I mean is this just a
> > hypothetical case
> > or something existing ?
> 
> This is more to stem the stream before anything happens because we were
> lax with parsing

If such files dont exist then being picky makes sense

thx

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

You can kill me, but you cannot change the t

Re: [FFmpeg-devel] [PATCH] Check codec_whitelist before reinitializing AVCtx.priv_data.

2024-07-30 Thread Dale Curtis

I realized there are a couple more allocations that can be skipped here
when a codec is not on the allow list. Here's the updated patch.

- dale

On Mon, Jul 29, 2024 at 10:19 AM Dale Curtis 
wrote:

> This ensures that if a codec isn't on codec_whitelist, its VUI
> information can still be populated during find_stream_info()
> via parsers.
>
> Signed-off-by: Dale Curtis 
> ---
>  libavcodec/avcodec.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
>

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

38 matches

Mail list logo