Re: [FFmpeg-devel] [PATCH v2 1/2] avutil: move bswapdsp from avcodec to avutil

2022-12-06 Thread Andreas Rheinhardt
Mark Reid:
> On Tue, Dec 6, 2022 at 8:11 PM Andreas Rheinhardt <
> andreas.rheinha...@outlook.com> wrote:
> 
>> mindm...@gmail.com:
>>> From: Mark Reid 
>>>
>>> Also renamed bswap_buf to bswap32_buf
>>> ---
>>>  configure | 56 ---
>>>  libavcodec/4xm.c  | 14 ++---
>>>  libavcodec/Makefile   |  1 -
>>>  libavcodec/ac3dec.c   |  4 +-
>>>  libavcodec/ac3dec.h   |  4 +-
>>>  libavcodec/alsdec.c   | 12 ++--
>>>  libavcodec/apedec.c   | 10 ++--
>>>  libavcodec/asv.c  |  4 +-
>>>  libavcodec/asv.h  |  4 +-
>>>  libavcodec/asvdec.c   |  4 +-
>>>  libavcodec/asvenc.c   |  4 +-
>>>  libavcodec/cllc.c |  6 +-
>>>  libavcodec/eamad.c|  6 +-
>>>  libavcodec/eatqi.c| 10 ++--
>>>  libavcodec/exr.c  |  6 +-
>>>  libavcodec/flacenc.c  |  6 +-
>>>  libavcodec/fraps.c| 10 ++--
>>>  libavcodec/hevcdec.c  |  4 +-
>>>  libavcodec/hevcdec.h  |  4 +-
>>>  libavcodec/huffyuvdec.c   | 14 ++---
>>>  libavcodec/huffyuvenc.c   |  8 +--
>>>  libavcodec/imc.c  |  6 +-
>>>  libavcodec/imm4.c | 12 ++--
>>>  libavcodec/mdec.c |  6 +-
>>>  libavcodec/mimic.c| 12 ++--
>>>  libavcodec/mobiclip.c |  6 +-
>>>  libavcodec/motionpixels.c | 10 ++--
>>>  libavcodec/mpc.h  |  4 +-
>>>  libavcodec/mpc7.c |  8 +--
>>>  libavcodec/rawdec.c   |  8 +--
>>>  libavcodec/riscv/Makefile |  3 -
>>>  libavcodec/shorten.c  |  7 ++-
>>>  libavcodec/truemotion2.c  | 11 ++--
>>>  libavcodec/truespeech.c   |  8 +--
>>>  libavcodec/utvideo.h  |  4 +-
>>>  libavcodec/utvideodec.c   | 16 +++---
>>>  libavcodec/utvideoenc.c   | 10 ++--
>>>  libavcodec/x86/Makefile   |  2 -
>>>  libavcodec/ylc.c  | 18 +++---
>>>  libavutil/Makefile|  2 +
>>>  {libavcodec => libavutil}/bswapdsp.c  | 17 +++---
>>>  {libavcodec => libavutil}/bswapdsp.h  | 16 +++---
>>>  libavutil/riscv/Makefile  |  7 ++-
>>>  .../riscv/bswapdsp_init.c |  9 +--
>>>  .../riscv/bswapdsp_rvb.S  |  0
>>>  .../riscv/bswapdsp_rvv.S  |  0
>>>  libavutil/version.h   |  2 +-
>>>  libavutil/x86/Makefile|  8 ++-
>>>  {libavcodec => libavutil}/x86/bswapdsp.asm|  4 +-
>>>  {libavcodec => libavutil}/x86/bswapdsp_init.c | 17 +++---
>>>  tests/checkasm/Makefile   |  2 +-
>>>  tests/checkasm/bswapdsp.c |  8 +--
>>>  tests/checkasm/checkasm.c |  4 +-
>>>  53 files changed, 216 insertions(+), 222 deletions(-)
>>>  rename {libavcodec => libavutil}/bswapdsp.c (80%)
>>>  rename {libavcodec => libavutil}/bswapdsp.h (71%)
>>>  rename {libavcodec => libavutil}/riscv/bswapdsp_init.c (85%)
>>>  rename {libavcodec => libavutil}/riscv/bswapdsp_rvb.S (100%)
>>>  rename {libavcodec => libavutil}/riscv/bswapdsp_rvv.S (100%)
>>>  rename {libavcodec => libavutil}/x86/bswapdsp.asm (97%)
>>>  rename {libavcodec => libavutil}/x86/bswapdsp_init.c (80%)
>>>
>>> diff --git a/configure b/configure
>>> index f4eedfc207..03b502ea37 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -2421,7 +2421,6 @@ CONFIG_EXTRA="
>>>  audio_frame_queue
>>>  audiodsp
>>>  blockdsp
>>> -bswapdsp
>>>  cabac
>>>  cbs
>>>  cbs_av1
>>> @@ -2749,8 +2748,8 @@ aac_decoder_select="adts_header mpeg4audio sinewin"
>>>  aac_fixed_decoder_select="adts_header mpeg4audio"
>>>  aac_encoder_select="audio_frame_queue iirfilter lpc sinewin"
>>>  aac_latm_decoder_select="aac_decoder aac_latm_parser"
>>> -ac3_decoder_select="ac3_parser ac3dsp bswapdsp fmtconvert"
>>> -ac3_fixed_decoder_select="ac3_parser ac3dsp bswapdsp"
>>> +ac3_decoder_select="ac3_parser ac3dsp fmtconvert"
>>> +ac3_fixed_decoder_select="ac3_parser ac3dsp"
>>>  ac3_encoder_select="ac3dsp audiodsp me_cmp"
>>>  ac3_fixed_encoder_select="ac3dsp audiodsp me_cmp"
>>>  acelp_kelvin_decoder_select="audiodsp"
>>> @@ -2759,20 +2758,20 @@ adpcm_g722_encoder_select="g722dsp"
>>>  agm_decoder_select="idctdsp"
>>>  aic_decoder_select="golomb idctdsp"
>>>  alac_encoder_select="lpc"
>>> 

Re: [FFmpeg-devel] [PATCH v2 1/2] avutil: move bswapdsp from avcodec to avutil

2022-12-06 Thread Mark Reid
On Tue, Dec 6, 2022 at 8:11 PM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> mindm...@gmail.com:
> > From: Mark Reid 
> >
> > Also renamed bswap_buf to bswap32_buf
> > ---
> >  configure | 56 ---
> >  libavcodec/4xm.c  | 14 ++---
> >  libavcodec/Makefile   |  1 -
> >  libavcodec/ac3dec.c   |  4 +-
> >  libavcodec/ac3dec.h   |  4 +-
> >  libavcodec/alsdec.c   | 12 ++--
> >  libavcodec/apedec.c   | 10 ++--
> >  libavcodec/asv.c  |  4 +-
> >  libavcodec/asv.h  |  4 +-
> >  libavcodec/asvdec.c   |  4 +-
> >  libavcodec/asvenc.c   |  4 +-
> >  libavcodec/cllc.c |  6 +-
> >  libavcodec/eamad.c|  6 +-
> >  libavcodec/eatqi.c| 10 ++--
> >  libavcodec/exr.c  |  6 +-
> >  libavcodec/flacenc.c  |  6 +-
> >  libavcodec/fraps.c| 10 ++--
> >  libavcodec/hevcdec.c  |  4 +-
> >  libavcodec/hevcdec.h  |  4 +-
> >  libavcodec/huffyuvdec.c   | 14 ++---
> >  libavcodec/huffyuvenc.c   |  8 +--
> >  libavcodec/imc.c  |  6 +-
> >  libavcodec/imm4.c | 12 ++--
> >  libavcodec/mdec.c |  6 +-
> >  libavcodec/mimic.c| 12 ++--
> >  libavcodec/mobiclip.c |  6 +-
> >  libavcodec/motionpixels.c | 10 ++--
> >  libavcodec/mpc.h  |  4 +-
> >  libavcodec/mpc7.c |  8 +--
> >  libavcodec/rawdec.c   |  8 +--
> >  libavcodec/riscv/Makefile |  3 -
> >  libavcodec/shorten.c  |  7 ++-
> >  libavcodec/truemotion2.c  | 11 ++--
> >  libavcodec/truespeech.c   |  8 +--
> >  libavcodec/utvideo.h  |  4 +-
> >  libavcodec/utvideodec.c   | 16 +++---
> >  libavcodec/utvideoenc.c   | 10 ++--
> >  libavcodec/x86/Makefile   |  2 -
> >  libavcodec/ylc.c  | 18 +++---
> >  libavutil/Makefile|  2 +
> >  {libavcodec => libavutil}/bswapdsp.c  | 17 +++---
> >  {libavcodec => libavutil}/bswapdsp.h  | 16 +++---
> >  libavutil/riscv/Makefile  |  7 ++-
> >  .../riscv/bswapdsp_init.c |  9 +--
> >  .../riscv/bswapdsp_rvb.S  |  0
> >  .../riscv/bswapdsp_rvv.S  |  0
> >  libavutil/version.h   |  2 +-
> >  libavutil/x86/Makefile|  8 ++-
> >  {libavcodec => libavutil}/x86/bswapdsp.asm|  4 +-
> >  {libavcodec => libavutil}/x86/bswapdsp_init.c | 17 +++---
> >  tests/checkasm/Makefile   |  2 +-
> >  tests/checkasm/bswapdsp.c |  8 +--
> >  tests/checkasm/checkasm.c |  4 +-
> >  53 files changed, 216 insertions(+), 222 deletions(-)
> >  rename {libavcodec => libavutil}/bswapdsp.c (80%)
> >  rename {libavcodec => libavutil}/bswapdsp.h (71%)
> >  rename {libavcodec => libavutil}/riscv/bswapdsp_init.c (85%)
> >  rename {libavcodec => libavutil}/riscv/bswapdsp_rvb.S (100%)
> >  rename {libavcodec => libavutil}/riscv/bswapdsp_rvv.S (100%)
> >  rename {libavcodec => libavutil}/x86/bswapdsp.asm (97%)
> >  rename {libavcodec => libavutil}/x86/bswapdsp_init.c (80%)
> >
> > diff --git a/configure b/configure
> > index f4eedfc207..03b502ea37 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2421,7 +2421,6 @@ CONFIG_EXTRA="
> >  audio_frame_queue
> >  audiodsp
> >  blockdsp
> > -bswapdsp
> >  cabac
> >  cbs
> >  cbs_av1
> > @@ -2749,8 +2748,8 @@ aac_decoder_select="adts_header mpeg4audio sinewin"
> >  aac_fixed_decoder_select="adts_header mpeg4audio"
> >  aac_encoder_select="audio_frame_queue iirfilter lpc sinewin"
> >  aac_latm_decoder_select="aac_decoder aac_latm_parser"
> > -ac3_decoder_select="ac3_parser ac3dsp bswapdsp fmtconvert"
> > -ac3_fixed_decoder_select="ac3_parser ac3dsp bswapdsp"
> > +ac3_decoder_select="ac3_parser ac3dsp fmtconvert"
> > +ac3_fixed_decoder_select="ac3_parser ac3dsp"
> >  ac3_encoder_select="ac3dsp audiodsp me_cmp"
> >  ac3_fixed_encoder_select="ac3dsp audiodsp me_cmp"
> >  acelp_kelvin_decoder_select="audiodsp"
> > @@ -2759,20 +2758,20 @@ adpcm_g722_encoder_select="g722dsp"
> >  agm_decoder_select="idctdsp"
> >  aic_decoder_select="golomb idctdsp"
> >  alac_encoder_select="lpc"
> > -als_decoder_select="bswapdsp 

Re: [FFmpeg-devel] [PATCH] lavfi/vf_scale_qsv: remove PI, PHI and E

2022-12-06 Thread Gyan Doshi




On 2022-12-07 08:13 am, Xiang, Haihao wrote:

From: Haihao Xiang 

PI, PHI and E are defined in libavutil/eval.c, and user may use these
constants for scale_qsv filter, so we needn't re-define these variables
in vf_scale_qsv.c


LGTM.




Signed-off-by: Haihao Xiang 
---
  libavfilter/vf_scale_qsv.c | 9 -
  1 file changed, 9 deletions(-)

diff --git a/libavfilter/vf_scale_qsv.c b/libavfilter/vf_scale_qsv.c
index 758e730f78..fa37e95429 100644
--- a/libavfilter/vf_scale_qsv.c
+++ b/libavfilter/vf_scale_qsv.c
@@ -44,9 +44,6 @@
  #include "video.h"
  
  static const char *const var_names[] = {

-"PI",
-"PHI",
-"E",
  "in_w",   "iw",
  "in_h",   "ih",
  "out_w",  "ow",
@@ -57,9 +54,6 @@ static const char *const var_names[] = {
  };
  
  enum var_name {

-VAR_PI,
-VAR_PHI,
-VAR_E,
  VAR_IN_W,   VAR_IW,
  VAR_IN_H,   VAR_IH,
  VAR_OUT_W,  VAR_OW,
@@ -470,9 +464,6 @@ static int qsvscale_config_props(AVFilterLink *outlink)
  char *expr;
  int ret;
  
-var_values[VAR_PI]= M_PI;

-var_values[VAR_PHI]   = M_PHI;
-var_values[VAR_E] = M_E;
  var_values[VAR_IN_W]  = var_values[VAR_IW] = inlink->w;
  var_values[VAR_IN_H]  = var_values[VAR_IH] = inlink->h;
  var_values[VAR_OUT_W] = var_values[VAR_OW] = NAN;


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

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


Re: [FFmpeg-devel] [PATCH v2 1/2] avutil: move bswapdsp from avcodec to avutil

2022-12-06 Thread Andreas Rheinhardt
mindm...@gmail.com:
> From: Mark Reid 
> 
> Also renamed bswap_buf to bswap32_buf
> ---
>  configure | 56 ---
>  libavcodec/4xm.c  | 14 ++---
>  libavcodec/Makefile   |  1 -
>  libavcodec/ac3dec.c   |  4 +-
>  libavcodec/ac3dec.h   |  4 +-
>  libavcodec/alsdec.c   | 12 ++--
>  libavcodec/apedec.c   | 10 ++--
>  libavcodec/asv.c  |  4 +-
>  libavcodec/asv.h  |  4 +-
>  libavcodec/asvdec.c   |  4 +-
>  libavcodec/asvenc.c   |  4 +-
>  libavcodec/cllc.c |  6 +-
>  libavcodec/eamad.c|  6 +-
>  libavcodec/eatqi.c| 10 ++--
>  libavcodec/exr.c  |  6 +-
>  libavcodec/flacenc.c  |  6 +-
>  libavcodec/fraps.c| 10 ++--
>  libavcodec/hevcdec.c  |  4 +-
>  libavcodec/hevcdec.h  |  4 +-
>  libavcodec/huffyuvdec.c   | 14 ++---
>  libavcodec/huffyuvenc.c   |  8 +--
>  libavcodec/imc.c  |  6 +-
>  libavcodec/imm4.c | 12 ++--
>  libavcodec/mdec.c |  6 +-
>  libavcodec/mimic.c| 12 ++--
>  libavcodec/mobiclip.c |  6 +-
>  libavcodec/motionpixels.c | 10 ++--
>  libavcodec/mpc.h  |  4 +-
>  libavcodec/mpc7.c |  8 +--
>  libavcodec/rawdec.c   |  8 +--
>  libavcodec/riscv/Makefile |  3 -
>  libavcodec/shorten.c  |  7 ++-
>  libavcodec/truemotion2.c  | 11 ++--
>  libavcodec/truespeech.c   |  8 +--
>  libavcodec/utvideo.h  |  4 +-
>  libavcodec/utvideodec.c   | 16 +++---
>  libavcodec/utvideoenc.c   | 10 ++--
>  libavcodec/x86/Makefile   |  2 -
>  libavcodec/ylc.c  | 18 +++---
>  libavutil/Makefile|  2 +
>  {libavcodec => libavutil}/bswapdsp.c  | 17 +++---
>  {libavcodec => libavutil}/bswapdsp.h  | 16 +++---
>  libavutil/riscv/Makefile  |  7 ++-
>  .../riscv/bswapdsp_init.c |  9 +--
>  .../riscv/bswapdsp_rvb.S  |  0
>  .../riscv/bswapdsp_rvv.S  |  0
>  libavutil/version.h   |  2 +-
>  libavutil/x86/Makefile|  8 ++-
>  {libavcodec => libavutil}/x86/bswapdsp.asm|  4 +-
>  {libavcodec => libavutil}/x86/bswapdsp_init.c | 17 +++---
>  tests/checkasm/Makefile   |  2 +-
>  tests/checkasm/bswapdsp.c |  8 +--
>  tests/checkasm/checkasm.c |  4 +-
>  53 files changed, 216 insertions(+), 222 deletions(-)
>  rename {libavcodec => libavutil}/bswapdsp.c (80%)
>  rename {libavcodec => libavutil}/bswapdsp.h (71%)
>  rename {libavcodec => libavutil}/riscv/bswapdsp_init.c (85%)
>  rename {libavcodec => libavutil}/riscv/bswapdsp_rvb.S (100%)
>  rename {libavcodec => libavutil}/riscv/bswapdsp_rvv.S (100%)
>  rename {libavcodec => libavutil}/x86/bswapdsp.asm (97%)
>  rename {libavcodec => libavutil}/x86/bswapdsp_init.c (80%)
> 
> diff --git a/configure b/configure
> index f4eedfc207..03b502ea37 100755
> --- a/configure
> +++ b/configure
> @@ -2421,7 +2421,6 @@ CONFIG_EXTRA="
>  audio_frame_queue
>  audiodsp
>  blockdsp
> -bswapdsp
>  cabac
>  cbs
>  cbs_av1
> @@ -2749,8 +2748,8 @@ aac_decoder_select="adts_header mpeg4audio sinewin"
>  aac_fixed_decoder_select="adts_header mpeg4audio"
>  aac_encoder_select="audio_frame_queue iirfilter lpc sinewin"
>  aac_latm_decoder_select="aac_decoder aac_latm_parser"
> -ac3_decoder_select="ac3_parser ac3dsp bswapdsp fmtconvert"
> -ac3_fixed_decoder_select="ac3_parser ac3dsp bswapdsp"
> +ac3_decoder_select="ac3_parser ac3dsp fmtconvert"
> +ac3_fixed_decoder_select="ac3_parser ac3dsp"
>  ac3_encoder_select="ac3dsp audiodsp me_cmp"
>  ac3_fixed_encoder_select="ac3dsp audiodsp me_cmp"
>  acelp_kelvin_decoder_select="audiodsp"
> @@ -2759,20 +2758,20 @@ adpcm_g722_encoder_select="g722dsp"
>  agm_decoder_select="idctdsp"
>  aic_decoder_select="golomb idctdsp"
>  alac_encoder_select="lpc"
> -als_decoder_select="bswapdsp mpeg4audio"
> +als_decoder_select="mpeg4audio"
>  amrnb_decoder_select="lsp"
>  amrwb_decoder_select="lsp"
>  amv_decoder_select="sp5x_decoder exif"
>  amv_encoder_select="jpegtables mpegvideoenc"
> -ape_decoder_select="bswapdsp llauddsp"
> +ape_decoder_select="llauddsp"
>  

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add new minimize_copies hwaccel_flag

2022-12-06 Thread Andreas Rheinhardt
Timo Rothenpieler:
> ---
>  doc/APIchanges |  3 +++
>  libavcodec/avcodec.h   | 11 +++
>  libavcodec/options_table.h |  1 +
>  libavcodec/version.h   |  2 +-
>  4 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index ab7ce15fae..9c1f905a61 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
>  
>  API changes, most recent first:
>  
> +2022-12-xx - xx - lavc 59.54.101 - avcodec.h
> +  Add AV_HWACCEL_FLAG_MINIMIZE_COPIES.
> +
>  2022-11-xx - xx - lavu 57.43.100 - tx.h
>Add AV_TX_FLOAT_DCT, AV_TX_DOUBLE_DCT and AV_TX_INT32_DCT.
>  
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 3edd8e2636..a72551bb5e 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2253,6 +2253,17 @@ typedef struct AVHWAccel {
>   */
>  #define AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH (1 << 2)
>  
> +/**
> + * Hardware acceleration can have a limited number of direct output surfaces.
> + * For some processing chains, this can be okay, but others will run into the
> + * limit and in turn produce very confusing errors.
> + *
> + * Thus, the hwaccel will by default make a safety copy. If a users really
> + * wants to minimize the amount of copies, they can set this flag and ensure
> + * their chain does not exhaust the surface pool.
> + */
> +#define AV_HWACCEL_FLAG_MINIMIZE_COPIES (1 << 3)
> +
>  /**
>   * @}
>   */
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index cd02f5096f..05e8948bc2 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -399,6 +399,7 @@ static const AVOption avcodec_options[] = {
>  {"ignore_level", "ignore level even if the codec level used is unknown or 
> higher than the maximum supported level reported by the hardware driver", 0, 
> AV_OPT_TYPE_CONST, { .i64 = AV_HWACCEL_FLAG_IGNORE_LEVEL }, INT_MIN, INT_MAX, 
> V | D, "hwaccel_flags" },
>  {"allow_high_depth", "allow to output YUV pixel formats with a different 
> chroma sampling than 4:2:0 and/or other than 8 bits per component", 0, 
> AV_OPT_TYPE_CONST, {.i64 = AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH }, INT_MIN, 
> INT_MAX, V | D, "hwaccel_flags"},
>  {"allow_profile_mismatch", "attempt to decode anyway if HW accelerated 
> decoder's supported profiles do not exactly match the stream", 0, 
> AV_OPT_TYPE_CONST, {.i64 = AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH }, INT_MIN, 
> INT_MAX, V | D, "hwaccel_flags"},
> +{"minimize_copies", "minimize number of frame copies at cost of risking 
> surface pool exhaustion", 0, AV_OPT_TYPE_CONST, {.i64 = 
> AV_HWACCEL_FLAG_MINIMIZE_COPIES }, INT_MIN, INT_MAX, V | D, "hwaccel_flags"},
>  {"extra_hw_frames", "Number of extra hardware frames to allocate for the 
> user", OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, 
> V|D },
>  {"discard_damaged_percentage", "Percentage of damaged samples to discard a 
> frame", OFFSET(discard_damaged_percentage), AV_OPT_TYPE_INT, {.i64 = 95 }, 0, 
> 100, V|D },
>  {NULL},
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index d149bc6c46..9e66920593 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -30,7 +30,7 @@
>  #include "version_major.h"
>  
>  #define LIBAVCODEC_VERSION_MINOR  54
> -#define LIBAVCODEC_VERSION_MICRO 100
> +#define LIBAVCODEC_VERSION_MICRO 101

A new public define needs a minor bump.

>  
>  #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> LIBAVCODEC_VERSION_MINOR, \

___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavfi/vf_scale_qsv: remove PI, PHI and E

2022-12-06 Thread Xiang, Haihao
From: Haihao Xiang 

PI, PHI and E are defined in libavutil/eval.c, and user may use these
constants for scale_qsv filter, so we needn't re-define these variables
in vf_scale_qsv.c

Signed-off-by: Haihao Xiang 
---
 libavfilter/vf_scale_qsv.c | 9 -
 1 file changed, 9 deletions(-)

diff --git a/libavfilter/vf_scale_qsv.c b/libavfilter/vf_scale_qsv.c
index 758e730f78..fa37e95429 100644
--- a/libavfilter/vf_scale_qsv.c
+++ b/libavfilter/vf_scale_qsv.c
@@ -44,9 +44,6 @@
 #include "video.h"
 
 static const char *const var_names[] = {
-"PI",
-"PHI",
-"E",
 "in_w",   "iw",
 "in_h",   "ih",
 "out_w",  "ow",
@@ -57,9 +54,6 @@ static const char *const var_names[] = {
 };
 
 enum var_name {
-VAR_PI,
-VAR_PHI,
-VAR_E,
 VAR_IN_W,   VAR_IW,
 VAR_IN_H,   VAR_IH,
 VAR_OUT_W,  VAR_OW,
@@ -470,9 +464,6 @@ static int qsvscale_config_props(AVFilterLink *outlink)
 char *expr;
 int ret;
 
-var_values[VAR_PI]= M_PI;
-var_values[VAR_PHI]   = M_PHI;
-var_values[VAR_E] = M_E;
 var_values[VAR_IN_W]  = var_values[VAR_IW] = inlink->w;
 var_values[VAR_IN_H]  = var_values[VAR_IH] = inlink->h;
 var_values[VAR_OUT_W] = var_values[VAR_OW] = NAN;
-- 
2.25.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] lavu/hwcontext_vaapi: Skip 'vgem' driver

2022-12-06 Thread Xiang, Haihao
On Ma, 2022-12-05 at 14:33 -0800, Brian Norris wrote:
> There can be more than one available render node, and it's not
> guaranteed the first node we come across is the correct one. In
> particular, 'vgem' devices are common, and are
> never VAAPI-enabled and thus not valid here.
> 
> We have a 'kernel_driver' arg already for specifying a single driver we
> *do* want, but it doesn't support a negation, nor a list. It's easier
> just to automatically skip 'vgem' anyway, to avoid foisting this burden
> on users.
> 
> This has precedent in libva-utils already:
> 
>   bfb6b98ed62a exclude vgem node and invalid drm node in vainfo
>   
> https://github.com/intel/libva-utils/commit/bfb6b98ed62ac14a840ba62639ab902a23912258
> 
> Signed-off-by: Brian Norris 
> ---
> 
> Changes in v2:
>  - strncmp() -> strcmp()
> 
>  libavutil/hwcontext_vaapi.c | 29 ++---
>  1 file changed, 22 insertions(+), 7 deletions(-)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 4bcde74f6212..938bd5447d5e 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -1700,6 +1700,7 @@ static int vaapi_device_create(AVHWDeviceContext *ctx,
> const char *device,
>  char path[64];
>  int n, max_devices = 8;
>  #if CONFIG_LIBDRM
> +drmVersion *info;
>  const AVDictionaryEntry *kernel_driver;
>  kernel_driver = av_dict_get(opts, "kernel_driver", NULL, 0);
>  #endif
> @@ -1713,9 +1714,15 @@ static int vaapi_device_create(AVHWDeviceContext *ctx,
> const char *device,
>  break;
>  }
>  #if CONFIG_LIBDRM
> +info = drmGetVersion(priv->drm_fd);
> +if (!info) {
> +av_log(ctx, AV_LOG_VERBOSE,
> +   "Failed to get DRM version for device %d.\n", n);
> +close(priv->drm_fd);
> +priv->drm_fd = -1;
> +continue;
> +}
>  if (kernel_driver) {
> -drmVersion *info;
> -info = drmGetVersion(priv->drm_fd);
>  if (strcmp(kernel_driver->value, info->name)) {
>  av_log(ctx, AV_LOG_VERBOSE, "Ignoring device %d "
> "with non-matching kernel driver (%s).\n",
> @@ -1730,12 +1737,20 @@ static int vaapi_device_create(AVHWDeviceContext *ctx,
> const char *device,
> "with matching kernel driver (%s).\n",
> n, info->name);
>  drmFreeVersion(info);
> -} else
> -#endif
> -{
> -av_log(ctx, AV_LOG_VERBOSE, "Trying to use "
> -   "DRM render node for device %d.\n", n);
> +break;
> +// drmGetVersion() ensures |info->name| is 0-terminated.
> +} else if (!strcmp(info->name, "vgem")) {
> +av_log(ctx, AV_LOG_VERBOSE,
> +   "Skipping vgem node for device %d.\n", n);
> +drmFreeVersion(info);
> +close(priv->drm_fd);
> +priv->drm_fd = -1;
> +continue;
>  }
> +drmFreeVersion(info);
> +#endif
> +av_log(ctx, AV_LOG_VERBOSE, "Trying to use "
> +   "DRM render node for device %d.\n", n);
>  break;
>  }
>  if (n >= max_devices)

LGTM, I'll apply this patch if no more comment

Thanks
Haihao

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

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


Re: [FFmpeg-devel] [PATCH] lavfi/vf_vpp_qsv: use macros for extra mfx parameter

2022-12-06 Thread Xiang, Haihao
On Ma, 2022-12-05 at 14:25 +0800, Xiang, Haihao wrote:
> From: Haihao Xiang 
> 
> Make it easy to add new extra mfx parameter buffer. No functional
> change.
> 
> Signed-off-by: Haihao Xiang 
> ---
>  libavfilter/vf_vpp_qsv.c | 86 
>  1 file changed, 34 insertions(+), 52 deletions(-)
> 
> diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> index a14b3de7b5..61ea0c4256 100644
> --- a/libavfilter/vf_vpp_qsv.c
> +++ b/libavfilter/vf_vpp_qsv.c
> @@ -365,53 +365,44 @@ static int config_output(AVFilterLink *outlink)
>  param.crop = 
>  }
>  
> -if (vpp->deinterlace) {
> -memset(>deinterlace_conf, 0, sizeof(mfxExtVPPDeinterlacing));
> -vpp->deinterlace_conf.Header.BufferId =
> MFX_EXTBUFF_VPP_DEINTERLACING;
> -vpp->deinterlace_conf.Header.BufferSz =
> sizeof(mfxExtVPPDeinterlacing);
> -vpp->deinterlace_conf.Mode = vpp->deinterlace == 1 ?
> - MFX_DEINTERLACING_BOB :
> MFX_DEINTERLACING_ADVANCED;
> +#define INIT_MFX_EXTBUF(extbuf, id) do { \
> +memset(>extbuf, 0, sizeof(vpp->extbuf)); \
> +vpp->extbuf.Header.BufferId = id; \
> +vpp->extbuf.Header.BufferSz = sizeof(vpp->extbuf); \
> +param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)>extbuf; \
> +} while (0)
> +
> +#define SET_MFX_PARAM_FIELD(extbuf, field, value) do { \
> +vpp->extbuf.field = value; \
> +} while (0)
>  
> -param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)
> >deinterlace_conf;
> +if (vpp->deinterlace) {
> +INIT_MFX_EXTBUF(deinterlace_conf, MFX_EXTBUFF_VPP_DEINTERLACING);
> +SET_MFX_PARAM_FIELD(deinterlace_conf, Mode, (vpp->deinterlace == 1 ?
> +MFX_DEINTERLACING_BOB :
> MFX_DEINTERLACING_ADVANCED));
>  }
>  
>  if (vpp->use_frc) {
> -memset(>frc_conf, 0, sizeof(mfxExtVPPFrameRateConversion));
> -vpp->frc_conf.Header.BufferId =
> MFX_EXTBUFF_VPP_FRAME_RATE_CONVERSION;
> -vpp->frc_conf.Header.BufferSz = sizeof(mfxExtVPPFrameRateConversion);
> -vpp->frc_conf.Algorithm = MFX_FRCALGM_DISTRIBUTED_TIMESTAMP;
> -
> -param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)>frc_conf;
> +INIT_MFX_EXTBUF(frc_conf, MFX_EXTBUFF_VPP_FRAME_RATE_CONVERSION);
> +SET_MFX_PARAM_FIELD(frc_conf, Algorithm,
> MFX_FRCALGM_DISTRIBUTED_TIMESTAMP);
>  }
>  
>  if (vpp->denoise) {
> -memset(>denoise_conf, 0, sizeof(mfxExtVPPDenoise));
> -vpp->denoise_conf.Header.BufferId = MFX_EXTBUFF_VPP_DENOISE;
> -vpp->denoise_conf.Header.BufferSz = sizeof(mfxExtVPPDenoise);
> -vpp->denoise_conf.DenoiseFactor   = vpp->denoise;
> -
> -param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)
> >denoise_conf;
> +INIT_MFX_EXTBUF(denoise_conf, MFX_EXTBUFF_VPP_DENOISE);
> +SET_MFX_PARAM_FIELD(denoise_conf, DenoiseFactor, vpp->denoise);
>  }
>  
>  if (vpp->detail) {
> -memset(>detail_conf, 0, sizeof(mfxExtVPPDetail));
> -vpp->detail_conf.Header.BufferId  = MFX_EXTBUFF_VPP_DETAIL;
> -vpp->detail_conf.Header.BufferSz  = sizeof(mfxExtVPPDetail);
> -vpp->detail_conf.DetailFactor = vpp->detail;
> -
> -param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)
> >detail_conf;
> +INIT_MFX_EXTBUF(detail_conf, MFX_EXTBUFF_VPP_DETAIL);
> +SET_MFX_PARAM_FIELD(detail_conf, DetailFactor, vpp->detail);
>  }
>  
>  if (vpp->procamp) {
> -memset(>procamp_conf, 0, sizeof(mfxExtVPPProcAmp));
> -vpp->procamp_conf.Header.BufferId  = MFX_EXTBUFF_VPP_PROCAMP;
> -vpp->procamp_conf.Header.BufferSz  = sizeof(mfxExtVPPProcAmp);
> -vpp->procamp_conf.Hue  = vpp->hue;
> -vpp->procamp_conf.Saturation   = vpp->saturation;
> -vpp->procamp_conf.Contrast = vpp->contrast;
> -vpp->procamp_conf.Brightness   = vpp->brightness;
> -
> -param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)
> >procamp_conf;
> +INIT_MFX_EXTBUF(procamp_conf, MFX_EXTBUFF_VPP_PROCAMP);
> +SET_MFX_PARAM_FIELD(procamp_conf, Hue, vpp->hue);
> +SET_MFX_PARAM_FIELD(procamp_conf, Saturation, vpp->saturation);
> +SET_MFX_PARAM_FIELD(procamp_conf, Contrast, vpp->contrast);
> +SET_MFX_PARAM_FIELD(procamp_conf, Brightness, vpp->brightness);
>  }
>  
>  if (vpp->transpose >= 0) {
> @@ -458,18 +449,14 @@ static int config_output(AVFilterLink *outlink)
>  
>  if (vpp->rotate) {
>  if (QSV_RUNTIME_VERSION_ATLEAST(mfx_version, 1, 17)) {
> -memset(>rotation_conf, 0, sizeof(mfxExtVPPRotation));
> -vpp->rotation_conf.Header.BufferId  = MFX_EXTBUFF_VPP_ROTATION;
> -vpp->rotation_conf.Header.BufferSz  = sizeof(mfxExtVPPRotation);
> -vpp->rotation_conf.Angle = vpp->rotate;
> +INIT_MFX_EXTBUF(rotation_conf, MFX_EXTBUFF_VPP_ROTATION);
> +  

Re: [FFmpeg-devel] [PATCH v3] libavfilter/qsvvpp: Change the alignment to meet the requirement of YUV420P format

2022-12-06 Thread Xiang, Haihao
On Ma, 2022-12-05 at 14:32 +0800, wenbin.chen-at-intel@ffmpeg.org wrote:
> From: Wenbin Chen 
> 
> When process yuv420 frames, FFmpeg uses same alignment on Y/U/V
> planes. VPL and MSDK use Y plane's pitch / 2 as U/V planes's
> pitch, which makes U/V planes 16-bytes aligned. We need to set
> a separate alignment to meet runtime's behaviour.
> 
> Now alignment is changed to 16 so that the linesizes of U/V planes
> meet the requirment of VPL/MSDK. Add get_buffer.video callback to
> qsv filters to change the default get_buffer behaviour.
> 
> Now the commandline works fine:
> ffmpeg -f rawvideo -pix_fmt yuv420p -s:v 3082x1884 \
> -i ./3082x1884.yuv -vf 'vpp_qsv=w=2466:h=1508' -f rawvideo \
> -pix_fmt yuv420p 2466_1508.yuv
> 
> Signed-off-by: Wenbin Chen 
> ---
>  libavfilter/qsvvpp.c | 13 +
>  libavfilter/qsvvpp.h |  1 +
>  libavfilter/vf_deinterlace_qsv.c |  1 +
>  libavfilter/vf_overlay_qsv.c |  2 ++
>  libavfilter/vf_scale_qsv.c   |  1 +
>  libavfilter/vf_vpp_qsv.c |  1 +
>  6 files changed, 19 insertions(+)
> 
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index 8428ee89ab..d5cfeab402 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -1003,3 +1003,16 @@ int ff_qsvvpp_create_mfx_session(void *ctx,
>  }
>  
>  #endif
> +
> +AVFrame *ff_qsvvpp_get_video_buffer(AVFilterLink *inlink, int w, int h)
> +{
> +/* When process YUV420 frames, FFmpeg uses same alignment on Y/U/V
> + * planes. VPL and MSDK use Y plane's pitch / 2 as U/V planes's
> + * pitch, which makes U/V planes 16-bytes aligned. We need to set a
> + * separate alignment to meet runtime's behaviour.
> +*/
> +return ff_default_get_video_buffer2(inlink,
> +FFALIGN(inlink->w, 32),
> +FFALIGN(inlink->h, 32),
> +16);
> +}
> diff --git a/libavfilter/qsvvpp.h b/libavfilter/qsvvpp.h
> index a8cfcc565a..6f7c9bfc15 100644
> --- a/libavfilter/qsvvpp.h
> +++ b/libavfilter/qsvvpp.h
> @@ -127,4 +127,5 @@ int ff_qsvvpp_print_warning(void *log_ctx, mfxStatus err,
>  int ff_qsvvpp_create_mfx_session(void *ctx, void *loader, mfxIMPL
> implementation,
>   mfxVersion *pver, mfxSession *psession);
>  
> +AVFrame *ff_qsvvpp_get_video_buffer(AVFilterLink *inlink, int w, int h);
>  #endif /* AVFILTER_QSVVPP_H */
> diff --git a/libavfilter/vf_deinterlace_qsv.c
> b/libavfilter/vf_deinterlace_qsv.c
> index 98ed7283ad..6c94923f02 100644
> --- a/libavfilter/vf_deinterlace_qsv.c
> +++ b/libavfilter/vf_deinterlace_qsv.c
> @@ -581,6 +581,7 @@ static const AVFilterPad qsvdeint_inputs[] = {
>  .name = "default",
>  .type = AVMEDIA_TYPE_VIDEO,
>  .filter_frame = qsvdeint_filter_frame,
> +.get_buffer.video = ff_qsvvpp_get_video_buffer,
>  },
>  };
>  
> diff --git a/libavfilter/vf_overlay_qsv.c b/libavfilter/vf_overlay_qsv.c
> index d947a1faa1..1a2c1b1e96 100644
> --- a/libavfilter/vf_overlay_qsv.c
> +++ b/libavfilter/vf_overlay_qsv.c
> @@ -399,11 +399,13 @@ static const AVFilterPad overlay_qsv_inputs[] = {
>  .name  = "main",
>  .type  = AVMEDIA_TYPE_VIDEO,
>  .config_props  = config_main_input,
> +.get_buffer.video = ff_qsvvpp_get_video_buffer,
>  },
>  {
>  .name  = "overlay",
>  .type  = AVMEDIA_TYPE_VIDEO,
>  .config_props  = config_overlay_input,
> +.get_buffer.video = ff_qsvvpp_get_video_buffer,
>  },
>  };
>  
> diff --git a/libavfilter/vf_scale_qsv.c b/libavfilter/vf_scale_qsv.c
> index 758e730f78..36d5f3a6ec 100644
> --- a/libavfilter/vf_scale_qsv.c
> +++ b/libavfilter/vf_scale_qsv.c
> @@ -641,6 +641,7 @@ static const AVFilterPad qsvscale_inputs[] = {
>  .name = "default",
>  .type = AVMEDIA_TYPE_VIDEO,
>  .filter_frame = qsvscale_filter_frame,
> +.get_buffer.video = ff_qsvvpp_get_video_buffer,
>  },
>  };
>  
> diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> index 4a053f9145..b26d19c3bc 100644
> --- a/libavfilter/vf_vpp_qsv.c
> +++ b/libavfilter/vf_vpp_qsv.c
> @@ -634,6 +634,7 @@ static const AVFilterPad vpp_inputs[] = {
>  .name  = "default",
>  .type  = AVMEDIA_TYPE_VIDEO,
>  .config_props  = config_input,
> +.get_buffer.video = ff_qsvvpp_get_video_buffer,
>  },
>  };

LGTM, will apply,

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] [PATCH 2/2] avutil/tx_template: Use more unsigned ints to avoid undefined overflows

2022-12-06 Thread Michael Niedermayer
Fixes: signed integer overflow: 574590586 - -1875616554 cannot be represented 
in type 'int'
Fixes: 
53914/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5037125846564864

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavutil/tx_template.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavutil/tx_template.c b/libavutil/tx_template.c
index ac3dc22a2c..983de75a47 100644
--- a/libavutil/tx_template.c
+++ b/libavutil/tx_template.c
@@ -659,7 +659,7 @@ static void TX_NAME(ff_tx_fft8_ns)(AVTXContext *s, void 
*_dst,
 {
 TXComplex *src = _src;
 TXComplex *dst = _dst;
-TXSample t1, t2, t3, t4, t5, t6, r0, i0, r1, i1;
+TXUSample t1, t2, t3, t4, t5, t6, r0, i0, r1, i1;
 const TXSample cos = TX_TAB(ff_tx_tab_8)[1];
 
 TX_NAME(ff_tx_fft4_ns)(s, dst, src, stride);
@@ -680,7 +680,7 @@ static void TX_NAME(ff_tx_fft16_ns)(AVTXContext *s, void 
*_dst,
 TXComplex *dst = _dst;
 const TXSample *cos = TX_TAB(ff_tx_tab_16);
 
-TXSample t1, t2, t3, t4, t5, t6, r0, i0, r1, i1;
+TXUSample t1, t2, t3, t4, t5, t6, r0, i0, r1, i1;
 TXSample cos_16_1 = cos[1];
 TXSample cos_16_2 = cos[2];
 TXSample cos_16_3 = cos[3];
-- 
2.17.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 1/2] avcodec/dts2pts_bsf: Avoid searching for poc == INT_MIN-1

2022-12-06 Thread Michael Niedermayer
Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in type 
'int'
Fixes: 
53876/clusterfuzz-testcase-minimized-ffmpeg_BSF_DTS2PTS_fuzzer-6569754750222336

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/dts2pts_bsf.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/dts2pts_bsf.c b/libavcodec/dts2pts_bsf.c
index 522d5e1eb0..48612e59db 100644
--- a/libavcodec/dts2pts_bsf.c
+++ b/libavcodec/dts2pts_bsf.c
@@ -461,9 +461,10 @@ static int dts2pts_filter(AVBSFContext *ctx, AVPacket *out)
 poc_node = av_tree_find(s->root, , cmp_find, NULL);
 }
 }
-} else {
+} else if (s->eof && frame.poc > INT_MIN) {
 DTS2PTSFrame dup = (DTS2PTSFrame) { NULL, frame.poc - 1, 
frame.poc_diff, frame.gop };
-if (s->eof && (poc_node = av_tree_find(s->root, , cmp_find, NULL)) 
&& poc_node->poc == dup.poc) {
+poc_node = av_tree_find(s->root, , cmp_find, NULL);
+if (poc_node && poc_node->poc == dup.poc) {
 out->pts = poc_node->dts;
 if (out->pts != AV_NOPTS_VALUE)
 out->pts += poc_node->duration;
@@ -480,7 +481,8 @@ static int dts2pts_filter(AVBSFContext *ctx, AVPacket *out)
poc_node->poc, poc_node->gop, poc_node->dts, 
poc_node->duration);
 } else
 av_log(ctx, AV_LOG_WARNING, "No timestamp for POC %d in tree\n", 
frame.poc);
-}
+} else
+av_log(ctx, AV_LOG_WARNING, "No timestamp for POC %d in tree\n", 
frame.poc);
 av_log(ctx, AV_LOG_DEBUG, "Returning frame for POC %d, GOP %d, dts 
%"PRId64", pts %"PRId64"\n",
frame.poc, frame.gop, out->dts, out->pts);
 
-- 
2.17.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 2/2] avcodec/nvdec: make explicit copy of frames unless user requested otherwise

2022-12-06 Thread Philip Langdale
On Mon,  5 Dec 2022 23:25:59 +0100
Timo Rothenpieler  wrote:

> ---
>  libavcodec/nvdec.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
> index fbaedf0b6b..76ee395734 100644
> --- a/libavcodec/nvdec.c
> +++ b/libavcodec/nvdec.c
> @@ -51,6 +51,8 @@ typedef struct NVDECDecoder {
>  
>  CudaFunctions *cudl;
>  CuvidFunctions *cvdl;
> +
> +int minimize_copies;
>  } NVDECDecoder;
>  
>  typedef struct NVDECFramePool {
> @@ -344,6 +346,8 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
>  int cuvid_codec_type, cuvid_chroma_format, chroma_444;
>  int ret = 0;
>  
> +int minimize_copies = !!(avctx->hwaccel_flags &
> AV_HWACCEL_FLAG_MINIMIZE_COPIES); +
>  sw_desc = av_pix_fmt_desc_get(avctx->sw_pix_fmt);
>  if (!sw_desc)
>  return AVERROR_BUG;
> @@ -402,7 +406,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
>  params.CodecType   = cuvid_codec_type;
>  params.ChromaFormat= cuvid_chroma_format;
>  params.ulNumDecodeSurfaces = frames_ctx->initial_pool_size;
> -params.ulNumOutputSurfaces = frames_ctx->initial_pool_size;
> +params.ulNumOutputSurfaces = minimize_copies ?
> frames_ctx->initial_pool_size : 1; 
>  ret = nvdec_decoder_create(>decoder_ref,
> frames_ctx->device_ref, , avctx); if (ret < 0) {
> @@ -417,6 +421,7 @@ int ff_nvdec_decode_init(AVCodecContext *avctx)
>  }
>  
>  decoder = (NVDECDecoder*)ctx->decoder_ref->data;
> +decoder->minimize_copies = minimize_copies;
>  decoder->real_hw_frames_ref = real_hw_frames_ref;
>  real_hw_frames_ref = NULL;
>  
> @@ -554,7 +559,11 @@ copy_fail:
>  
>  finish:
>  CHECK_CU(decoder->cudl->cuCtxPopCurrent());
> -return ret;
> +
> +if (ret < 0 || decoder->minimize_copies)
> +return ret;
> +
> +return av_frame_make_writable(frame);
>  }
>  
>  int ff_nvdec_start_frame(AVCodecContext *avctx, AVFrame *frame)

LGTM.


--phil
___
ffmpeg-devel mailing list
ffmpeg-devel@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: add new minimize_copies hwaccel_flag

2022-12-06 Thread Philip Langdale
On Mon,  5 Dec 2022 23:25:58 +0100
Timo Rothenpieler  wrote:

> ---
>  doc/APIchanges |  3 +++
>  libavcodec/avcodec.h   | 11 +++
>  libavcodec/options_table.h |  1 +
>  libavcodec/version.h   |  2 +-
>  4 files changed, 16 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index ab7ce15fae..9c1f905a61 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
>  
>  API changes, most recent first:
>  
> +2022-12-xx - xx - lavc 59.54.101 - avcodec.h
> +  Add AV_HWACCEL_FLAG_MINIMIZE_COPIES.
> +
>  2022-11-xx - xx - lavu 57.43.100 - tx.h
>Add AV_TX_FLOAT_DCT, AV_TX_DOUBLE_DCT and AV_TX_INT32_DCT.
>  
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 3edd8e2636..a72551bb5e 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2253,6 +2253,17 @@ typedef struct AVHWAccel {
>   */
>  #define AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH (1 << 2)
>  
> +/**
> + * Hardware acceleration can have a limited number of direct output
> surfaces.
> + * For some processing chains, this can be okay, but others will run
> into the
> + * limit and in turn produce very confusing errors.
> + *
> + * Thus, the hwaccel will by default make a safety copy. If a users
> really
> + * wants to minimize the amount of copies, they can set this flag
> and ensure
> + * their chain does not exhaust the surface pool.
> + */
> +#define AV_HWACCEL_FLAG_MINIMIZE_COPIES (1 << 3)

I would soften the statement about making a safety copy to make it
clear that only hwaccels where limits are relevant will make safety
copies. Otherwise people will think every other hwaccel has suddenly
started doing it.

Otherwise, LGTM.

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

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


Re: [FFmpeg-devel] [PATCH v2 1/2] avutil: move bswapdsp from avcodec to avutil

2022-12-06 Thread Mark Reid
On Tue, Dec 6, 2022 at 10:21 AM James Almer  wrote:

> On 12/5/2022 7:16 PM, mindm...@gmail.com wrote:
> > diff --git a/libavcodec/bswapdsp.h b/libavutil/bswapdsp.h
> > similarity index 71%
> > rename from libavcodec/bswapdsp.h
> > rename to libavutil/bswapdsp.h
> > index 6f4db66115..b540560d6a 100644
> > --- a/libavcodec/bswapdsp.h
> > +++ b/libavutil/bswapdsp.h
> > @@ -16,18 +16,16 @@
> >   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> >   */
> >
> > -#ifndef AVCODEC_BSWAPDSP_H
> > -#define AVCODEC_BSWAPDSP_H
> > +#ifndef AVUTIL_BSWAPDSP_H
> > +#define AVUTIL_BSWAPDSP_H
> >
> >  #include 
> >
> > -typedef struct BswapDSPContext {
> > -void (*bswap_buf)(uint32_t *dst, const uint32_t *src, int w);
> > +typedef struct AVBSwapDSPContext {
> > +void (*bswap32_buf)(uint32_t *dst, const uint32_t *src, int len);
> >  void (*bswap16_buf)(uint16_t *dst, const uint16_t *src, int len);
> > -} BswapDSPContext;
> > +} AVBSwapDSPContext;
> >
> > -void ff_bswapdsp_init(BswapDSPContext *c);
> > -void ff_bswapdsp_init_riscv(BswapDSPContext *c);
> > -void ff_bswapdsp_init_x86(BswapDSPContext *c);
> > +void av_bswapdsp_init(AVBSwapDSPContext *c);
> >
> > -#endif /* AVCODEC_BSWAPDSP_H */
> > +#endif /* AVUTIL_BSWAPDSP_H */
>
> For what's supposed to become an installer header, this is barebones in
> the documentation department.
>
> Also, does this have any real use for API users? If you want to access
> these functions from swscale as well as lavc, you could either duplicate
> the code, or use the avpriv prefix.
> I'm not a fan of adding public API for something that has no use outside
> of our own libraries.
>

I agree, I don't see a need for this to be public. I'll change it to use
the avpriv prefix if that's okay.
I'll add a little doc to the header too anyway.

the blockdsp is disappearing from configure is a mistake, I'll fix that too



> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] Defect: MediaCodec Encoder - Pixel ColorSpace of many Adreno GPUs not supported

2022-12-06 Thread Ben Temple
MediaCodec Encoder: Pixel ColorSpace of many Adreno GPUs is not supported
(<= Adreno 650 in our testing)What you were trying to accomplish?

I am trying to transcode an MP4 file using the MediaCodec encoder support
that was recently added by Zhao Zhili  here

(
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/0ff18a7d6d496f89d9e007ddd1cad7116baf5c7c
)
The problem you encountered:

On multiple phones containing an Adreno GPU, the encoding process
immediately fails because the color space expected by the GPU is
unsupported.

The exact error output: “does not support color format 19”

Phone information:

Model Name: Samsung Galaxy S10

Model Number: SM-G793U1

GPU Information: Adreno 640


Other phones that were tested and not working with this same error:

Brand Model name Model number OS GPU

Huawei Honor 10 COL-L29 Android 8.1 Mali-G72
Xiaomi Redmi Note 9S Redmi Note 9S Android 11 Adreno (TM) 618
Samsung Galaxy Z Flip SM-F700U1 Android 11 Adreno (TM) 640
Razer Razer phone Phone Android 7.1.1 Adreno (TM) 540
Essential PH-1 PH-1 Android 8.1 Adreno (TM) 541
Huawei Nexus 6P Nexus 6P Android 8.1 Adreno (TM) 430
Samsung Galaxy S6 SM-G920A Android 7 Mali-T760
Samsung Galaxy Tab S4 (Tablet) SM-T830 Android 10 Adreno (TM) 540
Samsung Galaxy S20 FE SM-G780G/DS Android 12 Adreno (TM) 650
Samsung Galaxy S10 SM-G973U1 Android 11 Adreno (TM) 640
Samsung Galaxy Note10 SM-N970U1 Android 12 Adreno (TM) 640

The following phones did not exhibit this behavior and were able to encode
without issues:

Brand Model name Model number OS GPU

Samsung Galaxy S21 Ultra 5G SM-G998U1 Android 12 Adreno (TM) 660
Huawei P10 plus VKY-L29 Android 8.1 Mali-G71
Huawei P40 Lite JNY-LX1 Android 10 Mali-G52
Samsung Galaxy S8 SM-G950F Android 9 Mali-G71
Samsung Galaxy S10+ Sm-G975F Android 12 Mali-G76
Huawei P30 ELE-L29 Android 10 Mali-G76
Google Pixel 4XL Pixel 4XL Android 13 Adreno (TM) 640
Samsung Galaxy S7 SM-G930F Android 8 Mali-T880
Samsung Galaxy S10 SM-G973F Android 11 Mali-G76
Samsung Galaxy S20 FE SM-G780F Android 11 Mali G77
Google Pixel 6 Pixel 6 Android 13 Mali-G78

The exact command line you were using:

-hwaccel mediacodec -hwaccel_output_format mediacodec -i
"/data/user/0/com.test.ffmpeg_kit_android_demo/cache/test_input.mp4"  -c:v
h264_mediacodec  -ndk_codec 1  -y
"/data/user/0/com.test.ffmpeg_kit_android_demo/cache/test_output.mp4"
-loglevel trace
Console output:

See attached console_output.log
Input Files:

See attached test_input.mp4


console_output.log
Description: Binary data


test_input.mp4
Description: video/mp4
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avfilter: add corr video filter

2022-12-06 Thread Paul B Mahol
Adds yet another metric filter.

Patch attached.
From 47f30e54b184e4b96f2e9da78671ca5d85c83762 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Tue, 6 Dec 2022 21:31:33 +0100
Subject: [PATCH] avfilter: add corr video filter

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  22 +++
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_corr.c| 339 +++
 4 files changed, 363 insertions(+)
 create mode 100644 libavfilter/vf_corr.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 4b74bce34f..252741b254 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10097,6 +10097,28 @@ ffmpeg -f lavfi -i nullsrc=s=100x100,coreimage=filter=CIQRCodeGenerator@@inputMe
 @end example
 @end itemize
 
+@section corr
+
+Obtain the correlation between two input videos.
+
+This filter takes two input videos.
+
+Both input videos must have the same resolution and pixel format for
+this filter to work correctly. Also it assumes that both inputs
+have the same number of frames, which are compared one by one.
+
+The obtained per component, average, min and max correlation is printed through
+the logging system.
+
+The filter stores the calculated correlation of each frame in frame metadata.
+
+In the below example the input file @file{main.mpg} being processed is compared
+with the reference file @file{ref.mpg}.
+
+@example
+ffmpeg -i main.mpg -i ref.mpg -lavfi corr -f null -
+@end example
+
 @section cover_rect
 
 Cover a rectangular object
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 2791b6a950..9a850d5dc5 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -243,6 +243,7 @@ OBJS-$(CONFIG_CONVOLUTION_OPENCL_FILTER) += vf_convolution_opencl.o opencl.o
 OBJS-$(CONFIG_CONVOLVE_FILTER)   += vf_convolve.o framesync.o
 OBJS-$(CONFIG_COPY_FILTER)   += vf_copy.o
 OBJS-$(CONFIG_COREIMAGE_FILTER)  += vf_coreimage.o
+OBJS-$(CONFIG_CORR_FILTER)   += vf_corr.o framesync.o
 OBJS-$(CONFIG_COVER_RECT_FILTER) += vf_cover_rect.o lavfutils.o
 OBJS-$(CONFIG_CROP_FILTER)   += vf_crop.o
 OBJS-$(CONFIG_CROPDETECT_FILTER) += vf_cropdetect.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 3ff20e76ce..2ece5c15c8 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -223,6 +223,7 @@ extern const AVFilter ff_vf_convolution_opencl;
 extern const AVFilter ff_vf_convolve;
 extern const AVFilter ff_vf_copy;
 extern const AVFilter ff_vf_coreimage;
+extern const AVFilter ff_vf_corr;
 extern const AVFilter ff_vf_cover_rect;
 extern const AVFilter ff_vf_crop;
 extern const AVFilter ff_vf_cropdetect;
diff --git a/libavfilter/vf_corr.c b/libavfilter/vf_corr.c
new file mode 100644
index 00..3e3951d001
--- /dev/null
+++ b/libavfilter/vf_corr.c
@@ -0,0 +1,339 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Calculate the correlation between two input videos.
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+#include "drawutils.h"
+#include "formats.h"
+#include "framesync.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct CorrContext {
+const AVClass *class;
+FFFrameSync fs;
+double score, min_score, max_score, score_comp[4];
+uint64_t nb_frames;
+int is_rgb;
+uint8_t rgba_map[4];
+int max[4];
+char comps[4];
+int nb_components;
+int planewidth[4];
+int planeheight[4];
+int (*filter_slice)(AVFilterContext *ctx, void *arg,
+int jobnr, int nb_jobs);
+} CorrContext;
+
+#define OFFSET(x) offsetof(CorrContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static void set_meta(AVFilterContext *ctx,
+ AVDictionary **metadata, const char *key, char comp, float d)
+{
+char value[128];
+snprintf(value, sizeof(value), "%f", d);
+if (comp) {
+char key2[128];
+snprintf(key2, sizeof(key2), "lavfi.%s.%s%s%c",
+ ctx->filter->name, ctx->filter->name, key, comp);
+av_dict_set(metadata, key2, value, 0);
+} else {
+char 

Re: [FFmpeg-devel] [PATCH v2 1/2] avutil: move bswapdsp from avcodec to avutil

2022-12-06 Thread James Almer

On 12/5/2022 7:16 PM, mindm...@gmail.com wrote:

diff --git a/libavcodec/bswapdsp.h b/libavutil/bswapdsp.h
similarity index 71%
rename from libavcodec/bswapdsp.h
rename to libavutil/bswapdsp.h
index 6f4db66115..b540560d6a 100644
--- a/libavcodec/bswapdsp.h
+++ b/libavutil/bswapdsp.h
@@ -16,18 +16,16 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#ifndef AVCODEC_BSWAPDSP_H

-#define AVCODEC_BSWAPDSP_H
+#ifndef AVUTIL_BSWAPDSP_H
+#define AVUTIL_BSWAPDSP_H
 
 #include 
 
-typedef struct BswapDSPContext {

-void (*bswap_buf)(uint32_t *dst, const uint32_t *src, int w);
+typedef struct AVBSwapDSPContext {
+void (*bswap32_buf)(uint32_t *dst, const uint32_t *src, int len);
 void (*bswap16_buf)(uint16_t *dst, const uint16_t *src, int len);
-} BswapDSPContext;
+} AVBSwapDSPContext;
 
-void ff_bswapdsp_init(BswapDSPContext *c);

-void ff_bswapdsp_init_riscv(BswapDSPContext *c);
-void ff_bswapdsp_init_x86(BswapDSPContext *c);
+void av_bswapdsp_init(AVBSwapDSPContext *c);
 
-#endif /* AVCODEC_BSWAPDSP_H */

+#endif /* AVUTIL_BSWAPDSP_H */


For what's supposed to become an installer header, this is barebones in 
the documentation department.


Also, does this have any real use for API users? If you want to access 
these functions from swscale as well as lavc, you could either duplicate 
the code, or use the avpriv prefix.
I'm not a fan of adding public API for something that has no use outside 
of our own libraries.

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

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


Re: [FFmpeg-devel] [PATCH v2 1/2] avutil: move bswapdsp from avcodec to avutil

2022-12-06 Thread Michael Niedermayer
On Mon, Dec 05, 2022 at 02:16:40PM -0800, mindm...@gmail.com wrote:
> From: Mark Reid 
> 
> Also renamed bswap_buf to bswap32_buf
> ---
>  configure | 56 ---
>  libavcodec/4xm.c  | 14 ++---
>  libavcodec/Makefile   |  1 -
>  libavcodec/ac3dec.c   |  4 +-
>  libavcodec/ac3dec.h   |  4 +-
>  libavcodec/alsdec.c   | 12 ++--
>  libavcodec/apedec.c   | 10 ++--
>  libavcodec/asv.c  |  4 +-
>  libavcodec/asv.h  |  4 +-
>  libavcodec/asvdec.c   |  4 +-
>  libavcodec/asvenc.c   |  4 +-
>  libavcodec/cllc.c |  6 +-
>  libavcodec/eamad.c|  6 +-
>  libavcodec/eatqi.c| 10 ++--
>  libavcodec/exr.c  |  6 +-
>  libavcodec/flacenc.c  |  6 +-
>  libavcodec/fraps.c| 10 ++--
>  libavcodec/hevcdec.c  |  4 +-
>  libavcodec/hevcdec.h  |  4 +-
>  libavcodec/huffyuvdec.c   | 14 ++---
>  libavcodec/huffyuvenc.c   |  8 +--
>  libavcodec/imc.c  |  6 +-
>  libavcodec/imm4.c | 12 ++--
>  libavcodec/mdec.c |  6 +-
>  libavcodec/mimic.c| 12 ++--
>  libavcodec/mobiclip.c |  6 +-
>  libavcodec/motionpixels.c | 10 ++--
>  libavcodec/mpc.h  |  4 +-
>  libavcodec/mpc7.c |  8 +--
>  libavcodec/rawdec.c   |  8 +--
>  libavcodec/riscv/Makefile |  3 -
>  libavcodec/shorten.c  |  7 ++-
>  libavcodec/truemotion2.c  | 11 ++--
>  libavcodec/truespeech.c   |  8 +--
>  libavcodec/utvideo.h  |  4 +-
>  libavcodec/utvideodec.c   | 16 +++---
>  libavcodec/utvideoenc.c   | 10 ++--
>  libavcodec/x86/Makefile   |  2 -
>  libavcodec/ylc.c  | 18 +++---
>  libavutil/Makefile|  2 +
>  {libavcodec => libavutil}/bswapdsp.c  | 17 +++---
>  {libavcodec => libavutil}/bswapdsp.h  | 16 +++---
>  libavutil/riscv/Makefile  |  7 ++-
>  .../riscv/bswapdsp_init.c |  9 +--
>  .../riscv/bswapdsp_rvb.S  |  0
>  .../riscv/bswapdsp_rvv.S  |  0
>  libavutil/version.h   |  2 +-
>  libavutil/x86/Makefile|  8 ++-
>  {libavcodec => libavutil}/x86/bswapdsp.asm|  4 +-
>  {libavcodec => libavutil}/x86/bswapdsp_init.c | 17 +++---
>  tests/checkasm/Makefile   |  2 +-
>  tests/checkasm/bswapdsp.c |  8 +--
>  tests/checkasm/checkasm.c |  4 +-
>  53 files changed, 216 insertions(+), 222 deletions(-)
>  rename {libavcodec => libavutil}/bswapdsp.c (80%)
>  rename {libavcodec => libavutil}/bswapdsp.h (71%)
>  rename {libavcodec => libavutil}/riscv/bswapdsp_init.c (85%)
>  rename {libavcodec => libavutil}/riscv/bswapdsp_rvb.S (100%)
>  rename {libavcodec => libavutil}/riscv/bswapdsp_rvv.S (100%)
>  rename {libavcodec => libavutil}/x86/bswapdsp.asm (97%)
>  rename {libavcodec => libavutil}/x86/bswapdsp_init.c (80%)
> 
> diff --git a/configure b/configure
> index f4eedfc207..03b502ea37 100755
> --- a/configure
> +++ b/configure
> @@ -2421,7 +2421,6 @@ CONFIG_EXTRA="
>  audio_frame_queue
>  audiodsp
>  blockdsp
> -bswapdsp
>  cabac
>  cbs
>  cbs_av1
> @@ -2749,8 +2748,8 @@ aac_decoder_select="adts_header mpeg4audio sinewin"
>  aac_fixed_decoder_select="adts_header mpeg4audio"
>  aac_encoder_select="audio_frame_queue iirfilter lpc sinewin"
>  aac_latm_decoder_select="aac_decoder aac_latm_parser"
> -ac3_decoder_select="ac3_parser ac3dsp bswapdsp fmtconvert"
> -ac3_fixed_decoder_select="ac3_parser ac3dsp bswapdsp"
> +ac3_decoder_select="ac3_parser ac3dsp fmtconvert"
> +ac3_fixed_decoder_select="ac3_parser ac3dsp"
>  ac3_encoder_select="ac3dsp audiodsp me_cmp"
>  ac3_fixed_encoder_select="ac3dsp audiodsp me_cmp"
>  acelp_kelvin_decoder_select="audiodsp"
> @@ -2759,20 +2758,20 @@ adpcm_g722_encoder_select="g722dsp"
>  agm_decoder_select="idctdsp"
>  aic_decoder_select="golomb idctdsp"
>  alac_encoder_select="lpc"
> -als_decoder_select="bswapdsp mpeg4audio"
> +als_decoder_select="mpeg4audio"
>  amrnb_decoder_select="lsp"
>  amrwb_decoder_select="lsp"
>  amv_decoder_select="sp5x_decoder exif"
>  amv_encoder_select="jpegtables mpegvideoenc"
> -ape_decoder_select="bswapdsp 

Re: [FFmpeg-devel] [PATCH v2 2/2] libswscale: add AVBSwapDSPContext and use

2022-12-06 Thread Michael Niedermayer
On Mon, Dec 05, 2022 at 02:16:41PM -0800, mindm...@gmail.com wrote:
> From: Mark Reid 
> 
> There are some places in input.c that could use it too
> but they aren't currently being pass the SwsContext
> ---
>  libswscale/output.c   | 36 +++
>  libswscale/swscale_internal.h |  3 +++
>  libswscale/swscale_unscaled.c | 26 +
>  libswscale/utils.c|  2 ++
>  4 files changed, 29 insertions(+), 38 deletions(-)

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


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/videotoolbox: validate vt context in the decoder callback

2022-12-06 Thread Alessandro Di Nepi
Got you; giving some context here, and you can find all the details in the 
ticket #10079 (http://trac.ffmpeg.org/ticket/10079).

The issue has been introduced with the commit 
d7f4ad88a0df3c1339e142957bf2c40cd056b8ce.
This patch basically changed:

• In the function `videotoolbox_start(AVCodecContext *avctx)`,

```
-    decoder_cb.decompressionOutputRefCon   = avctx;
+    decoder_cb.decompressionOutputRefCon   = 
avctx->internal->hwaccel_priv_data;
```

•  The context is retrieved in the function, 
`videotoolbox_decoder_callback(...)`

```
-    AVCodecContext *avctx = opaque;
-    VTContext *vtctx = avctx->internal->hwaccel_priv_data;
+    VTContext *vtctx = opaque;
```

Having said that, I see that when the `videotoolbox_start` is called,

• `avctx` is not NULL,
• `avctx->internal->hwaccel_priv_data` is NULL

The first time the `videotoolbox_decoder_callback` is called, 
`avctx->internal->hwaccel_priv_data` now has a value, so before d7f4ad88a 
`vtctx` has a value.
After the change, since `avctx->internal->hwaccel_priv_data` is captured in 
`video toolbox_start`, is NULL and `vtctx` is also NULL.

Again, this happens just the first time the callback is called; from the second 
time, vtctx has a proper value, and everything proceeds as expected.

I'm willing to change the patch if you think there is a better way, but 
something needs to be done because the library simply crashes in the current 
state.
From what I see from the original change, reverting is not an option.

Looking forward to hear feedback on this.

Best Regards
Alessandro
On 6 Dec 2022, 7:20 +0200, "zhilizhao(赵志立)" , wrote:
>
> > On Dec 5, 2022, at 21:36, Rick Kern  wrote:
> >
> > On Sun, Dec 4, 2022 at 12:51 PM Alessandro Di Nepi <
> > alessandro.din...@gmail.com> wrote:
> >
> > > On 4 Dec 2022, 17:01 +0200, FFmpeg development discussions and patches <
> > > ffmpeg-devel@ffmpeg.org>, wrote:
> > > > When this happens, does it continue happening, or is it transient? My
> > > main
> > > > concern is log spamming.
> > > Good question: this is just a transient state, so that it won't continue
> > > happening.
> > > To give you some context: when the decoding start, the value of `vtctx` is
> > > captured "too" early so that the first time the callback is called, it's
> > > still NULL.
> > > The next time it will have a proper value.
> > >
> > If the code isn't setting a variable in time, that issue should be fixed.
> > Otherwise the decoder will drop frames.
>
> Yes, null pointer check doesn’t looks like a resolution to a race
> condition. I’m not sure how the race condition happened in the first
> place.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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/thread: add support for frame threading receive_frame based decoders

2022-12-06 Thread Anton Khirnov
Quoting Timo Rothenpieler (2022-12-06 16:08:49)
> On 06/12/2022 15:43, Anton Khirnov wrote:
> > Quoting Timo Rothenpieler (2022-12-06 15:39:50)
> >> On 06/12/2022 15:37, Anton Khirnov wrote:
> >>> Quoting Timo Rothenpieler (2022-12-05 14:39:37)
>  This is fairly basic and makes a lot of assumptions, but it works
>  for the most simple cases.
> 
>  For one, it only ever fetches exactly one packet per call to 
>  receive_frame.
>  Right now it's impossible for there to ever be more than one, but the API
>  allows for more, which might need handled in the future.
> 
>  It also basically translates the new API back to the old, since that's 
>  how
>  the frame threading code operates. Which feels backwards in regards to
>  the new API, but it was the path with least resistance in implementing 
>  this.
> >>>
> >>> If it only supports one packet to one frame, then it goes against the
> >>> whole point of using the receive_frame API.
> >>
> >> Otherwise the entirety of pthread_frame.c would need rewritten from
> >> scratch. It has that assumption coded into it.
> > 
> > I told you on IRC I already have a mostly-finished branch that
> > implements threading with receive_frame(), so I don't really understand
> > what's the point of your writing this patch.
> > 
> 
> You said it wasn't even in a state to be tested.
> Do you have a link to it? Happy to help finishing it up.

Sure, see branch 'thread_receive' in git://git.khirnov.net/libav
IIRC it was only missing some allocations for frames or packets in
AVCodecInternal.

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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders

2022-12-06 Thread Timo Rothenpieler

On 06/12/2022 15:43, Anton Khirnov wrote:

Quoting Timo Rothenpieler (2022-12-06 15:39:50)

On 06/12/2022 15:37, Anton Khirnov wrote:

Quoting Timo Rothenpieler (2022-12-05 14:39:37)

This is fairly basic and makes a lot of assumptions, but it works
for the most simple cases.

For one, it only ever fetches exactly one packet per call to receive_frame.
Right now it's impossible for there to ever be more than one, but the API
allows for more, which might need handled in the future.

It also basically translates the new API back to the old, since that's how
the frame threading code operates. Which feels backwards in regards to
the new API, but it was the path with least resistance in implementing this.


If it only supports one packet to one frame, then it goes against the
whole point of using the receive_frame API.


Otherwise the entirety of pthread_frame.c would need rewritten from
scratch. It has that assumption coded into it.


I told you on IRC I already have a mostly-finished branch that
implements threading with receive_frame(), so I don't really understand
what's the point of your writing this patch.



You said it wasn't even in a state to be tested.
Do you have a link to it? Happy to help finishing it up.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/rawdec: remove redundant code setting frame properties

2022-12-06 Thread James Almer
These same values were already set in the ff_decode_frame_props() call above.

Signed-off-by: James Almer 
---
 libavcodec/rawdec.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 72cdd13916..c20c317fed 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -233,9 +233,6 @@ static int raw_decode(AVCodecContext *avctx, AVFrame *frame,
 if (res < 0)
 return res;
 
-frame->pkt_pos  = avctx->internal->last_pkt_props->pos;
-frame->duration = avctx->internal->last_pkt_props->duration;
-
 if (context->tff >= 0) {
 frame->interlaced_frame = 1;
 frame->top_field_first  = context->tff;
-- 
2.38.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] A question about http connections

2022-12-06 Thread Basel Sayeh
Hello

I'm thinking of implementing code to check the server response for the hls/dash 
encoders (incase the output was a URL).

Is it ok to implement it inside hlsenc_io_close/dashenc_io_close, and using 
blocking ffurl_read?

___
ffmpeg-devel mailing list
ffmpeg-devel@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/thread: add support for frame threading receive_frame based decoders

2022-12-06 Thread Anton Khirnov
Quoting Timo Rothenpieler (2022-12-06 15:39:50)
> On 06/12/2022 15:37, Anton Khirnov wrote:
> > Quoting Timo Rothenpieler (2022-12-05 14:39:37)
> >> This is fairly basic and makes a lot of assumptions, but it works
> >> for the most simple cases.
> >>
> >> For one, it only ever fetches exactly one packet per call to receive_frame.
> >> Right now it's impossible for there to ever be more than one, but the API
> >> allows for more, which might need handled in the future.
> >>
> >> It also basically translates the new API back to the old, since that's how
> >> the frame threading code operates. Which feels backwards in regards to
> >> the new API, but it was the path with least resistance in implementing 
> >> this.
> > 
> > If it only supports one packet to one frame, then it goes against the
> > whole point of using the receive_frame API.
> 
> Otherwise the entirety of pthread_frame.c would need rewritten from 
> scratch. It has that assumption coded into it.

I told you on IRC I already have a mostly-finished branch that
implements threading with receive_frame(), so I don't really understand
what's the point of your writing this patch.

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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/thread: add support for frame threading receive_frame based decoders

2022-12-06 Thread Timo Rothenpieler

On 06/12/2022 15:37, Anton Khirnov wrote:

Quoting Timo Rothenpieler (2022-12-05 14:39:37)

This is fairly basic and makes a lot of assumptions, but it works
for the most simple cases.

For one, it only ever fetches exactly one packet per call to receive_frame.
Right now it's impossible for there to ever be more than one, but the API
allows for more, which might need handled in the future.

It also basically translates the new API back to the old, since that's how
the frame threading code operates. Which feels backwards in regards to
the new API, but it was the path with least resistance in implementing this.


If it only supports one packet to one frame, then it goes against the
whole point of using the receive_frame API.


Otherwise the entirety of pthread_frame.c would need rewritten from 
scratch. It has that assumption coded into it.


It also raises question as to how it'd distribute those packets accross 
threads.
Does it just try to read packets until it either runs out of ready 
threads or encounters EAGAIN?

Or does it read until EAGAIN and then passes all those to the same threads?
___
ffmpeg-devel mailing list
ffmpeg-devel@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/thread: add support for frame threading receive_frame based decoders

2022-12-06 Thread Anton Khirnov
Quoting Timo Rothenpieler (2022-12-05 14:39:37)
> This is fairly basic and makes a lot of assumptions, but it works
> for the most simple cases.
> 
> For one, it only ever fetches exactly one packet per call to receive_frame.
> Right now it's impossible for there to ever be more than one, but the API
> allows for more, which might need handled in the future.
> 
> It also basically translates the new API back to the old, since that's how
> the frame threading code operates. Which feels backwards in regards to
> the new API, but it was the path with least resistance in implementing this.

If it only supports one packet to one frame, then it goes against the
whole point of using the receive_frame API.

-- 
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 v5 2/2] libavformat/dashenc: Enable HTTP persistent connections for dashenc_delete_file

2022-12-06 Thread Basel Sayeh
Signed-off-by: Basel Sayeh 
---
 libavformat/dashenc.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 9c1bcad9e3..ba0eb913a1 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -179,6 +179,7 @@ typedef struct DASHContext {
 int master_playlist_created;
 AVIOContext *mpd_out;
 AVIOContext *m3u8_out;
+AVIOContext *http_delete;
 int streaming;
 int64_t timeout;
 int index_correction;
@@ -642,6 +643,7 @@ static void dash_free(AVFormatContext *s)
 
 ff_format_io_close(s, >mpd_out);
 ff_format_io_close(s, >m3u8_out);
+ff_format_io_close(s, >http_delete);
 }
 
 static void output_segment_list(OutputStream *os, AVIOContext *out, 
AVFormatContext *s,
@@ -1855,18 +1857,22 @@ static void dashenc_delete_file(AVFormatContext *s, 
char *filename) {
 int http_base_proto = ff_is_http_proto(filename);
 
 if (http_base_proto) {
-AVIOContext *out = NULL;
 AVDictionary *http_opts = NULL;
 
 set_http_options(_opts, c);
 av_dict_set(_opts, "method", "DELETE", 0);
 
-if (dashenc_io_open(s, , filename, _opts) < 0) {
+if (dashenc_io_open(s, >http_delete, filename, _opts) < 0) {
 av_log(s, AV_LOG_ERROR, "failed to delete %s\n", filename);
+} else {
+//Nothing to write
+avio_flush(c->http_delete);
+dashenc_io_close(s, >http_delete, filename);
 }
-
 av_dict_free(_opts);
-ff_format_io_close(s, );
+
+if (!c->http_persistent)
+ff_format_io_close(s, >http_delete);
 } else {
 int res = ffurl_delete(filename);
 if (res < 0) {
-- 
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 v5 1/2] libavformat/hlsenc: Enable HTTP persistent connections for hls_delete_file

2022-12-06 Thread Basel Sayeh
V5
hls_delete_file and dashenc_delete_file functions open a
new HTTP connection regardless of the http_persistent value,
So change their behaviour to keep http connections open
if http_persistent is set

Signed-off-by: Basel Sayeh 
---
 libavformat/hlsenc.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index a86fc8907f..9781ed1ceb 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -252,6 +252,7 @@ typedef struct HLSContext {
 int http_persistent;
 AVIOContext *m3u8_out;
 AVIOContext *sub_m3u8_out;
+AVIOContext *http_delete;
 int64_t timeout;
 int ignore_io_errors;
 char *headers;
@@ -569,15 +570,21 @@ static int hls_delete_file(HLSContext *hls, 
AVFormatContext *avf,
 {
 if (hls->method || (proto && !av_strcasecmp(proto, "http"))) {
 AVDictionary *opt = NULL;
-AVIOContext  *out = NULL;
 int ret;
+
 set_http_options(avf, , hls);
 av_dict_set(, "method", "DELETE", 0);
-ret = avf->io_open(avf, , path, AVIO_FLAG_WRITE, );
+ret = hlsenc_io_open(avf, >http_delete, path, );
 av_dict_free();
 if (ret < 0)
 return hls->ignore_io_errors ? 1 : ret;
-ff_format_io_close(avf, );
+
+//Nothing to write
+avio_flush(hls->http_delete);
+hlsenc_io_close(avf, >http_delete, path);
+
+if (!hls->http_persistent)
+ff_format_io_close(avf, >http_delete);
 } else if (unlink(path) < 0) {
 av_log(hls, AV_LOG_ERROR, "failed to delete old segment %s: %s\n",
path, strerror(errno));
@@ -662,7 +669,7 @@ static int hls_delete_old_segments(AVFormatContext *s, 
HLSContext *hls,
 }
 
 proto = avio_find_protocol_name(s->url);
-if (ret = hls_delete_file(hls, vs->avf, path.str, proto))
+if (ret = hls_delete_file(hls, s, path.str, proto))
 goto fail;
 
 if ((segment->sub_filename[0] != '\0')) {
@@ -679,7 +686,7 @@ static int hls_delete_old_segments(AVFormatContext *s, 
HLSContext *hls,
 goto fail;
 }
 
-if (ret = hls_delete_file(hls, vs->vtt_avf, path.str, proto))
+if (ret = hls_delete_file(hls, s, path.str, proto))
 goto fail;
 }
 av_bprint_clear();
@@ -2707,6 +2714,7 @@ static void hls_deinit(AVFormatContext *s)
 
 ff_format_io_close(s, >m3u8_out);
 ff_format_io_close(s, >sub_m3u8_out);
+ff_format_io_close(s, >http_delete);
 av_freep(>key_basename);
 av_freep(>var_streams);
 av_freep(>cc_streams);
-- 
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 v4 1/2] libavformat/hlsenc: Enable HTTP persistent connections for for hls_delete_file

2022-12-06 Thread Basel Sayeh
mistakes keep on happening, please use v5


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

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


[FFmpeg-devel] [PATCH v4 2/2] libavformat/dashenc: Enable HTTP persistent connections for for dashenc_delete_file

2022-12-06 Thread Basel Sayeh
Signed-off-by: Basel Sayeh 
---
 libavformat/dashenc.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 9c1bcad9e3..ba0eb913a1 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -179,6 +179,7 @@ typedef struct DASHContext {
 int master_playlist_created;
 AVIOContext *mpd_out;
 AVIOContext *m3u8_out;
+AVIOContext *http_delete;
 int streaming;
 int64_t timeout;
 int index_correction;
@@ -642,6 +643,7 @@ static void dash_free(AVFormatContext *s)
 
 ff_format_io_close(s, >mpd_out);
 ff_format_io_close(s, >m3u8_out);
+ff_format_io_close(s, >http_delete);
 }
 
 static void output_segment_list(OutputStream *os, AVIOContext *out, 
AVFormatContext *s,
@@ -1855,18 +1857,22 @@ static void dashenc_delete_file(AVFormatContext *s, 
char *filename) {
 int http_base_proto = ff_is_http_proto(filename);
 
 if (http_base_proto) {
-AVIOContext *out = NULL;
 AVDictionary *http_opts = NULL;
 
 set_http_options(_opts, c);
 av_dict_set(_opts, "method", "DELETE", 0);
 
-if (dashenc_io_open(s, , filename, _opts) < 0) {
+if (dashenc_io_open(s, >http_delete, filename, _opts) < 0) {
 av_log(s, AV_LOG_ERROR, "failed to delete %s\n", filename);
+} else {
+//Nothing to write
+avio_flush(c->http_delete);
+dashenc_io_close(s, >http_delete, filename);
 }
-
 av_dict_free(_opts);
-ff_format_io_close(s, );
+
+if (!c->http_persistent)
+ff_format_io_close(s, >http_delete);
 } else {
 int res = ffurl_delete(filename);
 if (res < 0) {
-- 
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 v4 1/2] libavformat/hlsenc: Enable HTTP persistent connections for for hls_delete_file

2022-12-06 Thread Basel Sayeh
V4
hls_delete_file and dashenc_delete_file functions open a
new HTTP connection regardless of the http_persistent value,
So change their behaviour to keep http connections open
if http_persistent is set

Signed-off-by: Basel Sayeh 
---
 libavformat/hlsenc.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index a86fc8907f..9781ed1ceb 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -252,6 +252,7 @@ typedef struct HLSContext {
 int http_persistent;
 AVIOContext *m3u8_out;
 AVIOContext *sub_m3u8_out;
+AVIOContext *http_delete;
 int64_t timeout;
 int ignore_io_errors;
 char *headers;
@@ -569,15 +570,21 @@ static int hls_delete_file(HLSContext *hls, 
AVFormatContext *avf,
 {
 if (hls->method || (proto && !av_strcasecmp(proto, "http"))) {
 AVDictionary *opt = NULL;
-AVIOContext  *out = NULL;
 int ret;
+
 set_http_options(avf, , hls);
 av_dict_set(, "method", "DELETE", 0);
-ret = avf->io_open(avf, , path, AVIO_FLAG_WRITE, );
+ret = hlsenc_io_open(avf, >http_delete, path, );
 av_dict_free();
 if (ret < 0)
 return hls->ignore_io_errors ? 1 : ret;
-ff_format_io_close(avf, );
+
+//Nothing to write
+avio_flush(hls->http_delete);
+hlsenc_io_close(avf, >http_delete, path);
+
+if (!hls->http_persistent)
+ff_format_io_close(avf, >http_delete);
 } else if (unlink(path) < 0) {
 av_log(hls, AV_LOG_ERROR, "failed to delete old segment %s: %s\n",
path, strerror(errno));
@@ -662,7 +669,7 @@ static int hls_delete_old_segments(AVFormatContext *s, 
HLSContext *hls,
 }
 
 proto = avio_find_protocol_name(s->url);
-if (ret = hls_delete_file(hls, vs->avf, path.str, proto))
+if (ret = hls_delete_file(hls, s, path.str, proto))
 goto fail;
 
 if ((segment->sub_filename[0] != '\0')) {
@@ -679,7 +686,7 @@ static int hls_delete_old_segments(AVFormatContext *s, 
HLSContext *hls,
 goto fail;
 }
 
-if (ret = hls_delete_file(hls, vs->vtt_avf, path.str, proto))
+if (ret = hls_delete_file(hls, s, path.str, proto))
 goto fail;
 }
 av_bprint_clear();
@@ -2707,6 +2714,7 @@ static void hls_deinit(AVFormatContext *s)
 
 ff_format_io_close(s, >m3u8_out);
 ff_format_io_close(s, >sub_m3u8_out);
+ff_format_io_close(s, >http_delete);
 av_freep(>key_basename);
 av_freep(>var_streams);
 av_freep(>cc_streams);
-- 
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 1/2] libavformat/hlsenc: Enable HTTP persistent connections

2022-12-06 Thread Basel Sayeh
another mistake, Please see v4

___
ffmpeg-devel mailing list
ffmpeg-devel@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/6] avcodec/wmadec: clear pts when returning a frame during flush

2022-12-06 Thread James Almer

On 12/6/2022 5:27 AM, Paul B Mahol wrote:

On 12/6/22, James Almer  wrote:

This will be needed for the following commit, after which ff_get_buffer()
will
stop setting frame->pts to AV_NOPTS_VALUE.


This can not be put into generic code?


Decoders can set pts manually for frames returned after eof (which is 
essentially what I'm doing here), and the generic code can't know the 
decoder was done flushing in order to force something into a frame until 
it effectively gets no frame.

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

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


Re: [FFmpeg-devel] [PATCH 5/5] avcodec/mpeg4videodec: duplicate the last decoded frame when the last coded frame was skipped

2022-12-06 Thread James Almer

On 12/6/2022 6:17 AM, Andreas Rheinhardt wrote:

James Almer:

This ensures the video stream duration is not lost after decoding.

Signed-off-by: James Almer 
---
  libavcodec/h263dec.c   | 13 +
  libavcodec/mpegvideo.h |  1 +
  2 files changed, 14 insertions(+)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index ac7a8521e5..0a2d7487a8 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -430,6 +430,18 @@ int ff_h263_decode_frame(AVCodecContext *avctx, AVFrame 
*pict,
  return ret;
  s->next_picture_ptr = NULL;
  
+*got_frame = 1;

+} else if (s->skipped_last_frame && s->current_picture_ptr) {
+/* Output the last picture we decoded again if the stream ended 
with
+ * an NVOP */
+if ((ret = av_frame_ref(pict, s->current_picture_ptr->f)) < 0)
+return ret;
+/* Copy props from the last input packet. Otherwise, props from 
the last
+ * returned picture would be reused */
+if ((ret = ff_decode_frame_props(avctx, pict)) < 0)
+return ret;
+s->current_picture_ptr = NULL;
+
  *got_frame = 1;
  }
  
@@ -500,6 +512,7 @@ retry:

  s->extradata_parsed = 1;
  }
  ret = ff_mpeg4_decode_picture_header(avctx->priv_data, >gb, 0, 0);
+s->skipped_last_frame = (ret == FRAME_SKIPPED);
  } else if (CONFIG_H263I_DECODER && s->codec_id == AV_CODEC_ID_H263I) {
  ret = ff_intel_h263_decode_picture_header(s);
  } else if (CONFIG_FLV_DECODER && s->h263_flv) {
diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
index 6440b906b1..42275953b9 100644
--- a/libavcodec/mpegvideo.h
+++ b/libavcodec/mpegvideo.h
@@ -175,6 +175,7 @@ typedef struct MpegEncContext {
  Picture *last_picture_ptr; ///< pointer to the previous picture.
  Picture *next_picture_ptr; ///< pointer to the next picture (for 
bidir pred)
  Picture *current_picture_ptr;  ///< pointer to the current picture
+int skipped_last_frame;
  int last_dc[3];///< last DC values for MPEG-1
  int16_t *dc_val_base;
  int16_t *dc_val[3];///< used for MPEG-4 DC prediction, all 3 
arrays must be continuous


Can you give an example where this matters? And what does the spec say
about this? Is "output the last frame again" really the appropriate
response upon encountering a NVOP?



The reference decoder returns a frame for every packet, nvop or 
otherwise. If nvop, it will be the last decoded frame. Doing that here 
was rejected some years ago as it would make the decoder unconditionally 
cfr, and that's undesired.


Say you have a video stream that's 6 minutes and 30 seconds long, where 
the last thirty seconds worth of packets are NVOPs. The decoder will 
consume them and generate nothing, as expected, but then at EOF the last 
returned frame was that with a pts at the 6 minutes mark, resulting in 
the decoded stream being 6 minutes, and as such stream length 
information is lost.
By returning the last frame again at the end with the last input 
packet's pts, you will get the correct stream length with no difference 
in video output while remaining vfr.

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

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


Re: [FFmpeg-devel] [PATCH 5/5] avcodec/mpeg4videodec: duplicate the last decoded frame when the last coded frame was skipped

2022-12-06 Thread Andreas Rheinhardt
James Almer:
> This ensures the video stream duration is not lost after decoding.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/h263dec.c   | 13 +
>  libavcodec/mpegvideo.h |  1 +
>  2 files changed, 14 insertions(+)
> 
> diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
> index ac7a8521e5..0a2d7487a8 100644
> --- a/libavcodec/h263dec.c
> +++ b/libavcodec/h263dec.c
> @@ -430,6 +430,18 @@ int ff_h263_decode_frame(AVCodecContext *avctx, AVFrame 
> *pict,
>  return ret;
>  s->next_picture_ptr = NULL;
>  
> +*got_frame = 1;
> +} else if (s->skipped_last_frame && s->current_picture_ptr) {
> +/* Output the last picture we decoded again if the stream ended 
> with
> + * an NVOP */
> +if ((ret = av_frame_ref(pict, s->current_picture_ptr->f)) < 0)
> +return ret;
> +/* Copy props from the last input packet. Otherwise, props from 
> the last
> + * returned picture would be reused */
> +if ((ret = ff_decode_frame_props(avctx, pict)) < 0)
> +return ret;
> +s->current_picture_ptr = NULL;
> +
>  *got_frame = 1;
>  }
>  
> @@ -500,6 +512,7 @@ retry:
>  s->extradata_parsed = 1;
>  }
>  ret = ff_mpeg4_decode_picture_header(avctx->priv_data, >gb, 0, 0);
> +s->skipped_last_frame = (ret == FRAME_SKIPPED);
>  } else if (CONFIG_H263I_DECODER && s->codec_id == AV_CODEC_ID_H263I) {
>  ret = ff_intel_h263_decode_picture_header(s);
>  } else if (CONFIG_FLV_DECODER && s->h263_flv) {
> diff --git a/libavcodec/mpegvideo.h b/libavcodec/mpegvideo.h
> index 6440b906b1..42275953b9 100644
> --- a/libavcodec/mpegvideo.h
> +++ b/libavcodec/mpegvideo.h
> @@ -175,6 +175,7 @@ typedef struct MpegEncContext {
>  Picture *last_picture_ptr; ///< pointer to the previous picture.
>  Picture *next_picture_ptr; ///< pointer to the next picture (for 
> bidir pred)
>  Picture *current_picture_ptr;  ///< pointer to the current picture
> +int skipped_last_frame;
>  int last_dc[3];///< last DC values for MPEG-1
>  int16_t *dc_val_base;
>  int16_t *dc_val[3];///< used for MPEG-4 DC prediction, all 3 
> arrays must be continuous

Can you give an example where this matters? And what does the spec say
about this? Is "output the last frame again" really the appropriate
response upon encountering a NVOP?

- Andreas

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

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


Re: [FFmpeg-devel] [PATCH v5 2/2] lavc/vaapi_decode: add support for HWACCEL_CAP_RESET_WITHOUT_UNINIT

2022-12-06 Thread Wang, Fei W
On Thu, 2022-12-01 at 09:55 +0800, Fei Wang wrote:
> On Mon, 2022-11-28 at 13:20 +, Mark Thompson wrote:
> > On 14/11/2022 01:16, Fei Wang wrote:
> > > This can fix vp9 decode image corruption when the frame size is
> > > change,
> > > but the pervious frames still be referenced.
> > > 
> > > Surfaces don't need to be bound to vaContext only after VAAPI
> > > 1.0.0:
> > > https://github.com/intel/libva/commit/492b692005ccd0d8da190209d5b3ae7b7825f4b8
> > > 
> > > Signed-off-by: Fei Wang 
> > > ---
> > >   libavcodec/vaapi_decode.c | 11 ---
> > >   libavcodec/vaapi_decode.h |  1 +
> > >   libavcodec/vaapi_vp9.c|  4 
> > >   3 files changed, 13 insertions(+), 3 deletions(-)
> > 
> > This always segfaults immediately on anything unsupported.  E.g.
> > with
> > fate/hevc/paramchange_yuv420p_yuv420p10.hevc:
> > 
> > [hevc @ 0x57c0e7c0] Format vaapi chosen by get_format().
> > [hevc @ 0x57c0e7c0] Format vaapi requires hwaccel
> > initialisation.
> > [hevc @ 0x57c0e7c0] Hardware does not support image size
> > 1056x8440 (constraints: width 0-4096 height 0-4096).
> > 
> > Thread 20 "av:hevc:df0" received signal SIGSEGV, Segmentation
> > fault.
> > [Switching to Thread 0x7fffb4ff9700 (LWP 509456)]
> > ff_vaapi_decode_uninit (avctx=0x57c0e7c0) at
> > src/libavcodec/vaapi_decode.c:714
> > 714 vas = vaDestroyContext(ctx->hwctx->display, ctx-
> > > va_context);
> > (gdb) bt
> > #0  ff_vaapi_decode_uninit (avctx=0x57c0e7c0) at
> > src/libavcodec/vaapi_decode.c:714
> > #1  0x563073d7 in ff_vaapi_decode_init
> > (avctx=0x57c0e7c0)
> > at src/libavcodec/vaapi_decode.c:704
> > #2  0x55e62fee in hwaccel_init (avctx=0x57c0e7c0,
> > hw_config=0x5728f770 <__compound_literal.0>) at
> > src/libavcodec/decode.c:1121
> > #3  0x55e634ec in ff_get_format (avctx=0x57c0e7c0,
> > fmt=0x7fffb4ff8ccc) at src/libavcodec/decode.c:1261
> > #4  0x561ca829 in ff_thread_get_format
> > (avctx=0x57c0e7c0,
> > fmt=0x7fffb4ff8ccc) at src/libavcodec/pthread_frame.c:1048
> > #5  0x55f68f37 in get_format (s=0x57c3e6c0,
> > sps=0x57c21f80) at src/libavcodec/hevcdec.c:505
> > #6  0x55f69621 in hls_slice_header (s=0x57c3e6c0) at
> > src/libavcodec/hevcdec.c:618
> > #7  0x55f7472d in decode_nal_unit (s=0x57c3e6c0,
> > nal=0x7fff8802e920) at src/libavcodec/hevcdec.c:3173
> > #8  0x55f7508a in decode_nal_units (s=0x57c3e6c0,
> > buf=0x7637c010 "", length=159280) at
> > src/libavcodec/hevcdec.c:3355
> > #9  0x55f756d6 in hevc_decode_frame (avctx=0x57c0e7c0,
> > rframe=0x57c0ecc0, got_output=0x57c0d690,
> > avpkt=0x57c0ef40) at src/libavcodec/hevcdec.c:3497
> > #10 0x561c839c in frame_worker_thread (arg=0x57c0d580)
> > at
> > src/libavcodec/pthread_frame.c:241
> > #11 0x768ccea7 in start_thread (arg=) at
> > pthread_create.c:477
> > #12 0x767ecaef in clone () at
> > ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
> > (gdb)
> 
> Thanks, will fix this in next version.
> 
> > 
> > Also, I don't see how this is testing whether the driver supports
> > changing the resolution at runtime?  The note in libva that you
> > cite
> > allows new switching render targets in the context, but I don't see
> > why different resolution would be allowed given that it's a
> > parameter
> > passed to vaCreateContext()?
> > 
> > Looking at the Mesa driver it appears that the internally-allocated
> > references are not going to allow size changes (where does the
> > template width get updated?).  I don't have any hardware to test
> > that, though - are you able to try this on recent AMD hardware with
> > VP9 support?
> 
> I checked on AMD RX6700XT, it can get correct output when decoding
> multi-resolution vp9 clips only after apply this patchset. For
> example,
> by using clip from:
> https://storage.googleapis.com/downloads.webmproject.org/vp9/decoder-test-streams/Profile_0_8bit.zip
> 
> VP9 native decode result:
> ffmpeg -i
> Profile_0_8bit/frm_resize/crowd_run_1080X512_fr30_bd8_frm_resize_l3.w
> eb
> m -pix_fmt yuv420p -autoscale 0 -f md5 -y -
> [...]
> MD5=51b3393fa98ad9ab99c0b45ef705ebc4
> [...]
> 
> Without this patchset:
> ffmpeg -v verbose -hwaccel vaapi -i
> Profile_0_8bit/frm_resize/crowd_run_1080X512_fr30_bd8_frm_resize_l3.w
> eb
> m -pix_fmt yuv420p -autoscale 0 -f md5 -y -
> [...]
> [AVHWDeviceContext @ 0x56526336a000] VAAPI driver: Mesa Gallium
> driver
> 22.3.0-rc4 for AMD Radeon RX 6700 XT (navi22, LLVM 11.0.0, DRM 3.44,
> 5.13.0-40-generic).
> [...]
> MD5=2e799f0f916195f86a356907f7e4eae1 (change from time to time, but
> never same with native decode result)
> [...]
> 
> With this patchset:
> ffmpeg -v verbose -hwaccel vaapi -i
> Profile_0_8bit/frm_resize/crowd_run_1080X512_fr30_bd8_frm_resize_l3.w
> eb
> m -pix_fmt yuv420p -autoscale 0 -f md5 -y -
> [...]
> [AVHWDeviceContext @ 0x561c08e7a000] VAAPI driver: Mesa Gallium
> driver
> 22.3.0-rc4 for AMD Radeon RX 

Re: [FFmpeg-devel] Developer online meeting tomorrow Dec 2 16:00

2022-12-06 Thread Paul B Mahol
On 12/6/22, Anton Khirnov  wrote:
> Quoting Jean-Baptiste Kempf (2022-12-03 13:08:00)
>> Thanks for all who attended online and in real life.
>
> Thank you for organizing it.
> The work involved in making this happen is annoying and largely
> thankless, and almost nobody wants to do it, even though these meetings
> are IMO very valuable and we should have more of them.
> So - thank you, your efforts are very much appreciated.
>


Where are meeting logs?

> --
> 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 mailing list
ffmpeg-devel@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] Developer online meeting tomorrow Dec 2 16:00

2022-12-06 Thread Anton Khirnov
Quoting Jean-Baptiste Kempf (2022-12-03 13:08:00)
> Thanks for all who attended online and in real life.

Thank you for organizing it.
The work involved in making this happen is annoying and largely
thankless, and almost nobody wants to do it, even though these meetings
are IMO very valuable and we should have more of them.
So - thank you, your efforts are very much appreciated.

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


Re: [FFmpeg-devel] [PATCH 2/6] avcodec/wmadec: clear pts when returning a frame during flush

2022-12-06 Thread Paul B Mahol
On 12/6/22, James Almer  wrote:
> This will be needed for the following commit, after which ff_get_buffer()
> will
> stop setting frame->pts to AV_NOPTS_VALUE.

This can not be put into generic code?

>
> Signed-off-by: James Almer 
> ---
> This one goes before '[PATCH 2/5] Revert "avcodec/decode: use a packet list
> to
> store packet properties"'
>
>  libavcodec/wmadec.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/wmadec.c b/libavcodec/wmadec.c
> index 15d6fb42b2..bc18d18222 100644
> --- a/libavcodec/wmadec.c
> +++ b/libavcodec/wmadec.c
> @@ -845,6 +845,7 @@ static int wma_decode_superframe(AVCodecContext *avctx,
> AVFrame *frame,
>  if ((ret = ff_get_buffer(avctx, frame, 0)) < 0)
>  return ret;
>
> +frame->pts = AV_NOPTS_VALUE;
>  for (i = 0; i < s->avctx->ch_layout.nb_channels; i++)
>  memcpy(frame->extended_data[i], >frame_out[i][0],
> frame->nb_samples * sizeof(s->frame_out[i][0]));
> --
> 2.38.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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