Re: [FFmpeg-devel] [PATCH] configure: Fix typo

[Eoff, Ullysses A]

> 
> From: Haihao Xiang 
> 
> Otherwise there are link errors:
> LD  ffprobe_g
> /usr/bin/ld: libavcodec/libavcodec.so: undefined reference to
> `ff_dovi_rpu_generate'
> /usr/bin/ld: libavcodec/libavcodec.so: undefined reference to
> `ff_dovi_configure'
> collect2: error: ld returned 1 exit status
> 
> Signed-off-by: Haihao Xiang 
> ---
>  configure | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/configure b/configure
> index b101ed9256..02711bf930 100755
> --- a/configure
> +++ b/configure
> @@ -3534,7 +3534,7 @@ libspeex_decoder_deps="libspeex"
>  libspeex_encoder_deps="libspeex"
>  libspeex_encoder_select="audio_frame_queue"
>  libsvtav1_encoder_deps="libsvtav1"
> -libsvtav1_encoder_select="dovi_rpueenc"
> +libsvtav1_encoder_select="dovi_rpuenc"
>  libtheora_encoder_deps="libtheora"
>  libtwolame_encoder_deps="libtwolame"
>  libuavs3d_decoder_deps="libuavs3d"
> @@ -3554,7 +3554,7 @@ libx264_encoder_select="atsc_a53 golomb"
>  libx264rgb_encoder_deps="libx264"
>  libx264rgb_encoder_select="libx264_encoder"
>  libx265_encoder_deps="libx265"
> -libx265_encoder_select="atsc_a53 dovi_rpueenc"
> +libx265_encoder_select="atsc_a53 dovi_rpuenc"
>  libxavs_encoder_deps="libxavs"
>  libxavs2_encoder_deps="libxavs2"
>  libxevd_decoder_deps="libxevd"
> --

LGTM
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v1 3/3] lavfi/{denoise, procamp, scale, sharpness}_vaapi: Add passthrough mode

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Fei Wang
> Sent: Monday, May 29, 2023 8:30 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v1 3/3] lavfi/{denoise, procamp, scale, 
> sharpness}_vaapi: Add passthrough mode

> @@ -188,11 +194,14 @@ static av_cold int denoise_vaapi_init(AVFilterContext 
> *avctx)
>  static av_cold int sharpness_vaapi_init(AVFilterContext *avctx)
>  {
>  VAAPIVPPContext *vpp_ctx = avctx->priv;
> +SharpnessVAAPIContext *ctx = avctx->priv;
> 
>  ff_vaapi_vpp_ctx_init(avctx);
>  vpp_ctx->pipeline_uninit = ff_vaapi_vpp_pipeline_uninit;
>  vpp_ctx->build_filter_params = sharpness_vaapi_build_filter_params;
>  vpp_ctx->output_format   = AV_PIX_FMT_NONE;
> +if (!ctx->sharpness)
> +vpp_ctx->passthrough = 1;

[UAE] It should be passthrough for the default value.  SHARPNESS_DEFAULT = 44 

___
ffmpeg-devel mailing list
ffmpeg-devel@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] qsvenc: fix typo

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Haihao Xiang
> Sent: Thursday, April 7, 2022 3:01 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Xiang, Haihao 
> Subject: [FFmpeg-devel] [PATCH] qsvenc: fix typo
> 
> ---
>  libavcodec/qsvenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 2514d5b256..fbb22ca436 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1003,7 +1003,7 @@ static int init_video_param(AVCodecContext *avctx, 
> QSVEncContext *q)
>  q->extco3.LowDelayBRC = q->low_delay_brc ? 
> MFX_CODINGOPTION_ON : MFX_CODINGOPTION_OFF;
>  #endif
>  #if QSV_VERSION_ATLEAST(1, 19)
> -if (q->max_frame_size_p >= 0)
> +if (q->max_frame_size_i >= 0)
>  q->extco3.MaxFrameSizeI = q->max_frame_size_i;
>  if (q->max_frame_size_p >= 0)
>  q->extco3.MaxFrameSizeP = q->max_frame_size_p;
> --
> 2.17.1
> 

LGTM

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

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

Re: [FFmpeg-devel] [PATCH 1/2] lavfi/qsvpp: fix after 85c938fa28

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Anton 
> Khirnov
> Sent: Tuesday, February 8, 2022 10:27 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 1/2] lavfi/qsvpp: fix after 85c938fa28
> 
> ---
>  libavfilter/qsvvpp.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index 35769dfd60..954f882637 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -796,7 +796,7 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s, AVFilterLink 
> *inlink, AVFrame *picr
>  AVFilterLink *outlink = ctx->outputs[0];
>  QSVAsyncFrame aframe;
>  mfxSyncPoint  sync;
> -QSVFrame *in_frame, *out_frame, *tmp;
> +QSVFrame *in_frame, *out_frame;
>  int   ret, filter_ret;
> 
>  while (s->eof && av_fifo_read(s->async_fifo, , 1) >= 0) {
> @@ -857,15 +857,15 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s, 
> AVFilterLink *inlink, AVFrame *picr
>  ret = MFXVideoCORE_SyncOperation(s->session, aframe.sync, 
> 1000);
>  } while (ret == MFX_WRN_IN_EXECUTION);
> 
> -filter_ret = s->filter_frame(outlink, tmp->frame);
> +filter_ret = s->filter_frame(outlink, aframe.frame->frame);
>  if (filter_ret < 0) {
> -av_frame_free(>frame);
> +av_frame_free(>frame);
>  return filter_ret;
>  }
> 
> -tmp->queued--;
> +aframe.frame->queued--;
>  s->got_frame = 1;
> -tmp->frame = NULL;
> +aframe.frame->frame = NULL;
>  }
>  } while(ret == MFX_ERR_MORE_SURFACE);
> 
> --
> 2.34.1
> 

Fixes https://trac.ffmpeg.org/ticket/9629 for me.
LGTM

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] lavu/fifo: fix regression

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Xiang, 
> Haihao
> Sent: Monday, February 7, 2022 9:48 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Xiang, Haihao 
> Subject: [FFmpeg-devel] [PATCH] lavu/fifo: fix regression
> 
> From: Haihao Xiang 
> 
> offset_w might be updated after growing the FIFO
> 
> Fix ticket #9630
> 
> Tested-by: U. Artie Eoff 
> Reviewed-by: mkver
> Reviewed-by: U. Artie Eoff 
> Signed-off-by: Haihao Xiang 
> ---
>  libavutil/fifo.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/fifo.c b/libavutil/fifo.c
> index 0af0154945..02e0ec3f0d 100644
> --- a/libavutil/fifo.c
> +++ b/libavutil/fifo.c
> @@ -147,13 +147,15 @@ static int fifo_write_common(AVFifo *f, const uint8_t 
> *buf, size_t *nb_elems,
>   AVFifoCB read_cb, void *opaque)
>  {
>  size_t to_write = *nb_elems;
> -size_t offset_w = f->offset_w;
> +size_t offset_w;
>  int ret = 0;
> 
>  ret = fifo_check_space(f, to_write);
>  if (ret < 0)
>  return ret;
> 
> +offset_w = f->offset_w;
> +
>  while (to_write > 0) {
>  size_tlen = FFMIN(f->nb_elems - offset_w, to_write);
>  uint8_t *wptr = f->buffer + offset_w * f->elem_size;
> --
> 2.17.1
> 

LGTM

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] MAINTAINERS: Add Haihao Xiang for qsv

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Eoff, 
> Ullysses A
> Sent: Tuesday, December 14, 2021 8:41 AM
> To: FFmpeg development discussions and patches 
> Cc: Mark Thompson ; zhongli_...@126.com
> Subject: Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for qsv
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Eoff, 
> > Ullysses A
> > Sent: Tuesday, December 14, 2021 8:00 AM
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for qsv
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of Eoff, 
> > > Ullysses A
> > > Sent: Thursday, December 09, 2021 9:25 AM
> > > To: FFmpeg development discussions and patches 
> > > Subject: Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for qsv
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel  On Behalf Of Zhong 
> > > > Li
> > > > Sent: Tuesday, June 08, 2021 7:12 AM
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Cc: Zhong Li 
> > > > Subject: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for qsv
> > > >
> > > > Signed-off-by: Zhong Li 
> > > > ---
> > > >  MAINTAINERS | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index dcac46003e..39ce91b755 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -226,7 +226,7 @@ Codecs:
> > > >ptx.c Ivo van Poorten
> > > >qcelp*Reynaldo H. Verdejo Pinochet
> > > >qdm2.c, qdm2data.hRoberto Togni
> > > > -  qsv*  Mark Thompson, Zhong Li
> > > > +  qsv*  Mark Thompson, Zhong Li, 
> > > > Haihao Xiang
> > > >qtrle.c   Mike Melanson
> > > >ra144.c, ra144.h, ra288.c, ra288.hRoberto Togni
> > > >resample2.c   Michael Niedermayer
> > > > --
> > > > 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".
> > >
> > > [UAE] +1, LGTM
> > >
> > >
> >
> > *bump*
> >
> 
> CC Mark and LiZhong

CC LiZhong again with [hopefully] correct email contact.
(previous email contact bounced)

> 
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@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] MAINTAINERS: Add Haihao Xiang for vaapi

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Michael 
> Niedermayer
> Sent: Tuesday, December 14, 2021 8:30 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for vaapi
> 
> On Tue, Dec 14, 2021 at 04:04:39PM +, Eoff, Ullysses A wrote:
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of Soft 
> > > Works
> > > Sent: Monday, December 13, 2021 10:56 PM
> > > To: FFmpeg development discussions and patches 
> > > Subject: Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for 
> > > vaapi
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel  On Behalf Of U. 
> > > > Artie
> > > > Eoff
> > > > Sent: Tuesday, December 14, 2021 5:08 AM
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Cc: U. Artie Eoff 
> > > > Subject: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for vaapi
> > > >
> > > > Current listed maintainers for vaapi plugin are
> > > > not reponsive and/or currently active in the
> > > > ffmpeg community.  Thus, vaapi plugin patches
> > > > (and qsv plugin) have generally gone ignored or
> > > > lost in the ether for too long.
> > > >
> > > > Remove Gwenole Beauchesne from vaapi maintainer
> > > > who has not been active since 2016.
> > > >
> > > > Current alternative maintainer for vaapi is Mark
> > > > Thompson whom has not been active since
> > > > March/April 2021.
> > > >
> > > > Therefore, add Haihao Xiang to vaapi maintainer
> > > > who's primary role is FFmpeg development with a
> > > > focus on the vaapi and qsv plugins.  Haihao has
> > > > over a decade of media experience and many years
> > > > of FFmpeg development experience, amongst other
> > > > media frameworks.
> > > >
> > > > The additional patch for adding Haihao as qsv
> > > > plugin maintainer has been submitted previously:
> > > >
> > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210608141134.27448-1-
> > > > zhongli_...@126.com/
> > > >
> > > > This will help FFmpeg to continue to be the leading
> > > > multimedia framework by allowing these plugins to be
> > > > actively improved, enhanced, and maintained for existing
> > > > and future HW platforms.
> > > >
> > > > Signed-off-by: U. Artie Eoff 
> > > > ---
> > > >  MAINTAINERS | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index dcac46003ecd..fddf065a3abb 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -274,8 +274,8 @@ Hardware acceleration:
> > > >dxva2*Hendrik Leppkes, Laurent Aimar,
> > > > Steve Lhomme
> > > >d3d11va*  Steve Lhomme
> > > >mediacodec*   Matthieu Bouron, Aman Gupta
> > > > -  vaapi*Gwenole Beauchesne
> > > > -  vaapi_encode* Mark Thompson
> > > > +  vaapi*Haihao Xiang
> > > > +  vaapi_encode* Mark Thompson, Haihao Xiang
> > > >vdpau*Philip Langdale, Carl Eugen 
> > > > Hoyos
> > > >videotoolbox* Rick Kern, Aman Gupta
> > > >
> > > > --
> > >
> > > Whatever it might count: This has my support. Haihao is the
> > > most suitable candidate from all who I've been working with on
> > > QSV issues (on and off-list) in the past two years.
> > >
> > > The current situation is far from ideal. In other areas, commits are
> > > pushed timely and frequently, while there's hardly any progress made
> > > in the Intel area, despite the amount of developer resources they
> > > are providing.
> > > Even the most trivial and straightforward patches are lying around
> > > for months without action. It really shouldn't be like that.
> > >
> > > @Artie - you might want to update the patch and also add him for QSV.
> > >
> >
> > @softworkz, thank you for yo

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for qsv

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Eoff, 
> Ullysses A
> Sent: Tuesday, December 14, 2021 8:00 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for qsv
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Eoff, 
> > Ullysses A
> > Sent: Thursday, December 09, 2021 9:25 AM
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for qsv
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of Zhong Li
> > > Sent: Tuesday, June 08, 2021 7:12 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Zhong Li 
> > > Subject: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for qsv
> > >
> > > Signed-off-by: Zhong Li 
> > > ---
> > >  MAINTAINERS | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index dcac46003e..39ce91b755 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -226,7 +226,7 @@ Codecs:
> > >ptx.c Ivo van Poorten
> > >qcelp*Reynaldo H. Verdejo Pinochet
> > >qdm2.c, qdm2data.hRoberto Togni
> > > -  qsv*  Mark Thompson, Zhong Li
> > > +  qsv*  Mark Thompson, Zhong Li, Haihao 
> > > Xiang
> > >qtrle.c   Mike Melanson
> > >ra144.c, ra144.h, ra288.c, ra288.hRoberto Togni
> > >resample2.c   Michael Niedermayer
> > > --
> > > 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".
> >
> > [UAE] +1, LGTM
> >
> >
> 
> *bump*
> 

CC Mark and LiZhong

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

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

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for vaapi

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Soft Works
> Sent: Monday, December 13, 2021 10:56 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for vaapi
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of U. Artie
> > Eoff
> > Sent: Tuesday, December 14, 2021 5:08 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: U. Artie Eoff 
> > Subject: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for vaapi
> >
> > Current listed maintainers for vaapi plugin are
> > not reponsive and/or currently active in the
> > ffmpeg community.  Thus, vaapi plugin patches
> > (and qsv plugin) have generally gone ignored or
> > lost in the ether for too long.
> >
> > Remove Gwenole Beauchesne from vaapi maintainer
> > who has not been active since 2016.
> >
> > Current alternative maintainer for vaapi is Mark
> > Thompson whom has not been active since
> > March/April 2021.
> >
> > Therefore, add Haihao Xiang to vaapi maintainer
> > who's primary role is FFmpeg development with a
> > focus on the vaapi and qsv plugins.  Haihao has
> > over a decade of media experience and many years
> > of FFmpeg development experience, amongst other
> > media frameworks.
> >
> > The additional patch for adding Haihao as qsv
> > plugin maintainer has been submitted previously:
> >
> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210608141134.27448-1-
> > zhongli_...@126.com/
> >
> > This will help FFmpeg to continue to be the leading
> > multimedia framework by allowing these plugins to be
> > actively improved, enhanced, and maintained for existing
> > and future HW platforms.
> >
> > Signed-off-by: U. Artie Eoff 
> > ---
> >  MAINTAINERS | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index dcac46003ecd..fddf065a3abb 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -274,8 +274,8 @@ Hardware acceleration:
> >dxva2*Hendrik Leppkes, Laurent Aimar,
> > Steve Lhomme
> >d3d11va*  Steve Lhomme
> >mediacodec*   Matthieu Bouron, Aman Gupta
> > -  vaapi*Gwenole Beauchesne
> > -  vaapi_encode* Mark Thompson
> > +  vaapi*Haihao Xiang
> > +  vaapi_encode* Mark Thompson, Haihao Xiang
> >vdpau*Philip Langdale, Carl Eugen Hoyos
> >videotoolbox* Rick Kern, Aman Gupta
> >
> > --
> 
> Whatever it might count: This has my support. Haihao is the
> most suitable candidate from all who I've been working with on
> QSV issues (on and off-list) in the past two years.
> 
> The current situation is far from ideal. In other areas, commits are
> pushed timely and frequently, while there's hardly any progress made
> in the Intel area, despite the amount of developer resources they
> are providing.
> Even the most trivial and straightforward patches are lying around
> for months without action. It really shouldn't be like that.
> 
> @Artie - you might want to update the patch and also add him for QSV.
> 

@softworkz, thank you for your kind support.  There is already another
patch submitted to add Haihao for QSV... see link in my commit
message.  I have also just bumped that patch again.

We're looking forward to seeing some progress here .

> Kind regards,
> softworkz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] MAINTAINERS: Add Haihao Xiang for qsv

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Eoff, 
> Ullysses A
> Sent: Thursday, December 09, 2021 9:25 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for qsv
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Zhong Li
> > Sent: Tuesday, June 08, 2021 7:12 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Zhong Li 
> > Subject: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for qsv
> >
> > Signed-off-by: Zhong Li 
> > ---
> >  MAINTAINERS | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index dcac46003e..39ce91b755 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -226,7 +226,7 @@ Codecs:
> >ptx.c Ivo van Poorten
> >qcelp*Reynaldo H. Verdejo Pinochet
> >qdm2.c, qdm2data.hRoberto Togni
> > -  qsv*  Mark Thompson, Zhong Li
> > +  qsv*  Mark Thompson, Zhong Li, Haihao 
> > Xiang
> >qtrle.c   Mike Melanson
> >ra144.c, ra144.h, ra288.c, ra288.hRoberto Togni
> >resample2.c   Michael Niedermayer
> > --
> > 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".
> 
> [UAE] +1, LGTM
> 
> 

*bump*

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] libavutil/hwcontext_qsv: clean padding when upload qsv frames

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Chen, Wenbin
> Sent: Monday, December 13, 2021 6:24 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: clean padding 
> when upload qsv frames
> 
> > On Thu, 2021-12-02 at 15:40 +0800, Wenbin Chen wrote:
> > > When we upload a frame that is not padded as MSDK requires, we create a
> > > new AVFrame to copy data. The frame's padding data is uninitialized so
> > > it brings run to run problem. For example, If we run the following
> > > command serveral times we will get different outputs.
> > >
> > > ffmpeg -init_hw_device qsv=qsv:hw -qsv_device /dev/dri/renderD128
> > > -filter_hw_device qsv -f rawvideo -s 192x200 -pix_fmt p010
> > > -i 192x200_P010.yuv -vf "format=nv12,hwupload=extra_hw_frames=16"
> > > -c:v hevc_qsv output.265
> > >
> > > According to
> > > https://github.com/Intel-Media-
> > SDK/MediaSDK/blob/master/doc/mediasdk-man.md#encoding-procedures
> > > "Note: It is the application's responsibility to fill pixels outside
> > > of crop window when it is smaller than frame to be encoded. Especially
> > > in cases when crops are not aligned to minimum coding block size (16
> > > for AVC, 8 for HEVC and VP9)"
> > >
> > > I add a function to fill padding area with border pixel to fix this
> > > run2run problem, and also move the new AVFrame to global structure
> > > to reduce redundant allocation operation to increase preformance.
> > >
> > > Signed-off-by: Wenbin Chen 
> > > ---
> > >  libavutil/hwcontext_qsv.c | 96 +-
> > -
> > >  1 file changed, 83 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> > > index 268be9f8a1..983494666b 100644
> > > --- a/libavutil/hwcontext_qsv.c
> > > +++ b/libavutil/hwcontext_qsv.c
> > > @@ -47,6 +47,7 @@
> > >  #include "pixfmt.h"
> > >  #include "pixdesc.h"
> > >  #include "time.h"
> > > +#include "imgutils.h"
> > >
> > >  #define QSV_VERSION_ATLEAST(MAJOR, MINOR)   \
> > >  (MFX_VERSION_MAJOR > (MAJOR) || \
> > > @@ -90,6 +91,7 @@ typedef struct QSVFramesContext {
> > >
> > >  mfxExtOpaqueSurfaceAlloc opaque_alloc;
> > >  mfxExtBuffer *ext_buffers[1];
> > > +AVFrame realigned_tmp_frame;
> > >  } QSVFramesContext;
> > >
> > >  static const struct {
> > > @@ -137,6 +139,54 @@ static uint32_t qsv_get_d3d11va_bind_flags(int
> > mem_type)
> > >  }
> > >  #endif
> > >
> > > +static int qsv_fill_border(AVFrame *dst, const AVFrame *src)
> > > +{
> > > +const AVPixFmtDescriptor *desc;
> > > +int i, planes_nb = 0;
> > > +if (dst->format != src->format)
> > > +return AVERROR(EINVAL);
> > > +
> > > +desc = av_pix_fmt_desc_get(dst->format);
> > > +
> > > +for (i = 0; i < desc->nb_components; i++)
> > > +planes_nb = FFMAX(planes_nb, desc->comp[i].plane + 1);
> > > +
> > > +for (i = 0; i < planes_nb; i++) {
> > > +int sheight, dheight, y;
> > > +ptrdiff_t swidth = av_image_get_linesize(src->format,
> > > + src->width,
> > > + i);
> > > +ptrdiff_t dwidth = av_image_get_linesize(dst->format,
> > > + dst->width,
> > > + i);
> > > +const AVComponentDescriptor comp = desc->comp[i];
> > > +if (swidth < 0 || dwidth < 0) {
> > > +av_log(NULL, AV_LOG_ERROR, "av_image_get_linesize failed\n");
> > > +return AVERROR(EINVAL);
> > > +}
> > > +sheight = src->height;
> > > +dheight = dst->height;
> > > +if (i) {
> > > +sheight = AV_CEIL_RSHIFT(src->height, desc->log2_chroma_h);
> > > +dheight = AV_CEIL_RSHIFT(dst->height, desc->log2_chroma_h);
> > > +}
> > > +//fill right padding
> > > +for (y = 0; y < sheight; y++) {
> > > +void *line_ptr = dst->data[i] + y*dst->linesize[i] + swidth;
> > > +av_memcpy_backptr(line_ptr,
> > > +   comp.depth > 8 ? 2 : 1,
> > > +   dwidth - swidth);
> > > +}
> > > +//fill bottom padding
> > > +for (y = sheight; y < dheight; y++) {
> > > +memcpy(dst->data[i]+y*dst->linesize[i],
> > > +   dst->data[i]+(sheight-1)*dst->linesize[i],
> > > +   dwidth);
> > > +}
> > > +}
> > > +return 0;
> > > +}
> > > +
> > >  static int qsv_device_init(AVHWDeviceContext *ctx)
> > >  {
> > >  AVQSVDeviceContext *hwctx = ctx->hwctx;
> > > @@ -220,6 +270,7 @@ static void
> > qsv_frames_uninit(AVHWFramesContext *ctx)
> > >  av_freep(>surface_ptrs);
> > >  av_freep(>surfaces_internal);
> > >  av_freep(>handle_pairs_internal);
> > > +av_frame_unref(>realigned_tmp_frame);
> > >  av_buffer_unref(>child_frames_ref);
> > >  

Re: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for qsv

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Zhong Li
> Sent: Tuesday, June 08, 2021 7:12 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zhong Li 
> Subject: [FFmpeg-devel] [PATCH] MAINTAINERS: Add Haihao Xiang for qsv
> 
> Signed-off-by: Zhong Li 
> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index dcac46003e..39ce91b755 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -226,7 +226,7 @@ Codecs:
>ptx.c Ivo van Poorten
>qcelp*Reynaldo H. Verdejo Pinochet
>qdm2.c, qdm2data.hRoberto Togni
> -  qsv*  Mark Thompson, Zhong Li
> +  qsv*  Mark Thompson, Zhong Li, Haihao Xiang
>qtrle.c   Mike Melanson
>ra144.c, ra144.h, ra288.c, ra288.hRoberto Togni
>resample2.c   Michael Niedermayer
> --
> 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".

[UAE] +1, LGTM


___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavutil/hwcontext_qsv: clean padding when upload qsv frames

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Eoff, 
> Ullysses A
> Sent: Thursday, December 09, 2021 12:01 AM
> To: FFmpeg development discussions and patches 
> Cc: Chen, Wenbin 
> Subject: Re: [FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: clean padding 
> when upload qsv frames
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Wenbin 
> > Chen
> > Sent: Wednesday, December 01, 2021 11:41 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Chen, Wenbin 
> > Subject: [FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: clean padding when 
> > upload qsv frames
> >
> > When we upload a frame that is not padded as MSDK requires, we create a
> > new AVFrame to copy data. The frame's padding data is uninitialized so
> > it brings run to run problem. For example, If we run the following
> > command serveral times we will get different outputs.
> >
> > ffmpeg -init_hw_device qsv=qsv:hw -qsv_device /dev/dri/renderD128
> > -filter_hw_device qsv -f rawvideo -s 192x200 -pix_fmt p010
> > -i 192x200_P010.yuv -vf "format=nv12,hwupload=extra_hw_frames=16"
> > -c:v hevc_qsv output.265
> >
> > According to 
> > https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#encoding-procedures
> > "Note: It is the application's responsibility to fill pixels outside
> > of crop window when it is smaller than frame to be encoded. Especially
> > in cases when crops are not aligned to minimum coding block size (16
> > for AVC, 8 for HEVC and VP9)"
> >
> > I add a function to fill padding area with border pixel to fix this
> > run2run problem, and also move the new AVFrame to global structure
> > to reduce redundant allocation operation to increase preformance.
> >
> > Signed-off-by: Wenbin Chen 
> 
> [UAE] *bump*... Reviews encouraged!  This run-to-run issue has been
> around for way too long and causes a lot of intermittent noise/failures
> in some automated regression testing.  Let's get it fixed, please!
> Gstreamer has not had this issue and/or fixed it a long time ago!

[UAE] FWIW, you can find some preliminary patch reviews on our
pre-check/review mirror here https://github.com/intel-media-ci/ffmpeg/pull/453.
Now we just need some upstream "maintainer" reviews and sign-off, please!

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] libavutil/hwcontext_qsv: clean padding when upload qsv frames

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Wenbin Chen
> Sent: Wednesday, December 01, 2021 11:41 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Chen, Wenbin 
> Subject: [FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: clean padding when 
> upload qsv frames
> 
> When we upload a frame that is not padded as MSDK requires, we create a
> new AVFrame to copy data. The frame's padding data is uninitialized so
> it brings run to run problem. For example, If we run the following
> command serveral times we will get different outputs.
> 
> ffmpeg -init_hw_device qsv=qsv:hw -qsv_device /dev/dri/renderD128
> -filter_hw_device qsv -f rawvideo -s 192x200 -pix_fmt p010
> -i 192x200_P010.yuv -vf "format=nv12,hwupload=extra_hw_frames=16"
> -c:v hevc_qsv output.265
> 
> According to 
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/mediasdk-man.md#encoding-procedures
> "Note: It is the application's responsibility to fill pixels outside
> of crop window when it is smaller than frame to be encoded. Especially
> in cases when crops are not aligned to minimum coding block size (16
> for AVC, 8 for HEVC and VP9)"
> 
> I add a function to fill padding area with border pixel to fix this
> run2run problem, and also move the new AVFrame to global structure
> to reduce redundant allocation operation to increase preformance.
> 
> Signed-off-by: Wenbin Chen 

[UAE] *bump*... Reviews encouraged!  This run-to-run issue has been
around for way too long and causes a lot of intermittent noise/failures
in some automated regression testing.  Let's get it fixed, please!
Gstreamer has not had this issue and/or fixed it a long time ago!
___
ffmpeg-devel mailing list
ffmpeg-devel@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] ffmpeg_filter: don't try to autorotate frames with hwaccel pixel formats

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of James Almer
> Sent: Tuesday, September 21, 2021 5:33 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] ffmpeg_filter: don't try to autorotate frames 
> with hwaccel pixel formats
> 
> The transpose, rotate, hflip, and vflip filters don't support them.
> Fixes ticket #9432.
> 
> Signed-off-by: James Almer 
> ---
> I'm surprised nobody tried to decode an mp4 video like those coming from a
> cellphone camera using a hwaccel decoder. This would have been noticed much
> earlier.
> 
>  fftools/ffmpeg_filter.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index da0d4faf54..cc3dc33246 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -699,6 +699,7 @@ static int configure_input_video_filter(FilterGraph *fg, 
> InputFilter *ifilter,
>  {
>  AVFilterContext *last_filter;
>  const AVFilter *buffer_filt = avfilter_get_by_name("buffer");
> +const AVPixFmtDescriptor *desc;
>  InputStream *ist = ifilter->ist;
>  InputFile *f = input_files[ist->file_index];
>  AVRational tb = ist->framerate.num ? av_inv_q(ist->framerate) :
> @@ -756,7 +757,9 @@ static int configure_input_video_filter(FilterGraph *fg, 
> InputFilter *ifilter,
>  av_freep();
>  last_filter = ifilter->filter;
> 
> -if (ist->autorotate) {
> +desc = av_pix_fmt_desc_get(ifilter->format);
> +// TODO: insert hwaccel enabled filters like transpose_vaapi into the 
> graph
> +if (ist->autorotate && desc && !(desc->flags & AV_PIX_FMT_FLAG_HWACCEL)) 
> {
>  int32_t *displaymatrix = ifilter->displaymatrix;
>  double theta;
> 
> --
> 2.33.0
> 

LGTM and verified WFM with vaapi hwaccel.

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

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

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mjpegdec: export display matrix frame side data when available

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of James Almer
> Sent: Wednesday, September 08, 2021 11:34 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 1/4] avcodec/mjpegdec: export display matrix 
> frame side data when available
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/mjpegdec.c | 53 +++
>  1 file changed, 53 insertions(+)
> 
> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> index 2a5868fe1d..7bec5ce221 100644
> --- a/libavcodec/mjpegdec.c
> +++ b/libavcodec/mjpegdec.c
> @@ -30,6 +30,7 @@
>   * MJPEG decoder.
>   */
> 
> +#include "libavutil/display.h"
>  #include "libavutil/imgutils.h"
>  #include "libavutil/avassert.h"
>  #include "libavutil/opt.h"
> @@ -2406,6 +2407,7 @@ int ff_mjpeg_receive_frame(AVCodecContext *avctx, 
> AVFrame *frame)
>  int i, index;
>  int ret = 0;
>  int is16bit;
> +AVDictionaryEntry *e = NULL;
> 
>  s->force_pal8 = 0;
> 
> @@ -2864,6 +2866,57 @@ the_end:
>  }
>  }
> 
> +if (e = av_dict_get(s->exif_metadata, "Orientation", e, 
> AV_DICT_IGNORE_SUFFIX)) {
> +char *value = e->value + strspn(e->value, " \n\t\r"), *endptr;
> +int orientation = strtol(value, , 0);
> +
> +if (!*endptr) {
> +AVFrameSideData *sd = NULL;
> +
> +if (orientation >= 2 && orientation <= 8) {
> +int32_t *matrix;
> +
> +sd = av_frame_new_side_data(frame, 
> AV_FRAME_DATA_DISPLAYMATRIX, sizeof(int32_t) * 9);
> +if (!sd) {
> +av_log(s->avctx, AV_LOG_ERROR, "Could not allocate frame 
> side data\n");
> +return AVERROR(ENOMEM);
> +}
> +
> +matrix = (int32_t *)sd->data;
> +
> +switch (orientation) {
> +case 2:
> +av_display_rotation_set(matrix, 0.0);
> +av_display_matrix_flip(matrix, 1, 0);
> +break;
> +case 3:
> +av_display_rotation_set(matrix, 180.0);
> +break;
> +case 4:
> +av_display_rotation_set(matrix, 180.0);
> +av_display_matrix_flip(matrix, 1, 0);
> +break;
> +case 5:
> +av_display_rotation_set(matrix, 90.0);
> +av_display_matrix_flip(matrix, 0, 1);
> +break;
> +case 6:
> +av_display_rotation_set(matrix, 90.0);
> +break;
> +case 7:
> +av_display_rotation_set(matrix, -90.0);
> +av_display_matrix_flip(matrix, 0, 1);
> +break;
> +case 8:
> +av_display_rotation_set(matrix, -90.0);
> +break;
> +default:
> +av_assert0(0);
> +}
> +}
> +}
> +}
> +
>  av_dict_copy(>metadata, s->exif_metadata, 0);
>  av_dict_free(>exif_metadata);
> 

James, please see regression reported in https://trac.ffmpeg.org/ticket/9432

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

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

Re: [FFmpeg-devel] [PATCH v3] avcodec/h264dec: apply H.274 film grain

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Niklas Haas
> Sent: Tuesday, August 17, 2021 12:55 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Niklas Haas 
> Subject: [FFmpeg-devel] [PATCH v3] avcodec/h264dec: apply H.274 film grain
> 
> From: Niklas Haas 
> 
> Because we need access to ref frames without film grain applied, we have
> to add an extra AVFrame to H264Picture to avoid messing with the
> original. This requires some amount of overhead to make the reference
> moves work out, but it allows us to benefit from frame multithreading
> for film grain application "for free".
> 
> Unfortunately, this approach requires twice as much RAM to be constantly
> allocated for ref frames, due to the need for an extra buffer per
> H264Picture. In theory, we could get away with freeing up this memory as
> soon as it's no longer needed (since ref frames do not need film grain
> buffers any longer), but trying to call ff_thread_release_buffer() from
> output_frame() conflicts with possible later accesses to that same frame
> and I'm not sure how to synchronize that well.
> 
> Tested on all three cases of (no fg), (fg present but exported) and (fg
> present and not exported), with and without threading.
> 
> Signed-off-by: Niklas Haas 
> ---
>  libavcodec/h264_picture.c | 35 +++--
>  libavcodec/h264_slice.c   | 16 ++--
>  libavcodec/h264dec.c  | 55 ++-
>  libavcodec/h264dec.h  |  6 +
>  4 files changed, 90 insertions(+), 22 deletions(-)
> 
> diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> index ff30166b4d..5944798394 100644
> --- a/libavcodec/h264_picture.c
> +++ b/libavcodec/h264_picture.c
> @@ -43,13 +43,14 @@
> 
>  void ff_h264_unref_picture(H264Context *h, H264Picture *pic)
>  {
> -int off = offsetof(H264Picture, tf) + sizeof(pic->tf);
> +int off = offsetof(H264Picture, tf_grain) + sizeof(pic->tf_grain);
>  int i;
> 
>  if (!pic->f || !pic->f->buf[0])
>  return;
> 
>  ff_thread_release_buffer(h->avctx, >tf);
> +ff_thread_release_buffer(h->avctx, >tf_grain);
>  av_buffer_unref(>hwaccel_priv_buf);
> 
>  av_buffer_unref(>qscale_table_buf);
> @@ -93,6 +94,7 @@ static void h264_copy_picture_params(H264Picture *dst, 
> const H264Picture *src)
>  dst->mb_width  = src->mb_width;
>  dst->mb_height = src->mb_height;
>  dst->mb_stride = src->mb_stride;
> +dst->needs_fg  = src->needs_fg;
>  }
> 
>  int ff_h264_ref_picture(H264Context *h, H264Picture *dst, H264Picture *src)
> @@ -108,6 +110,14 @@ int ff_h264_ref_picture(H264Context *h, H264Picture 
> *dst, H264Picture *src)
>  if (ret < 0)
>  goto fail;
> 
> +if (src->needs_fg) {
> +av_assert0(src->tf_grain.f == src->f_grain);
> +dst->tf_grain.f = dst->f_grain;
> +ret = ff_thread_ref_frame(>tf_grain, >tf_grain);
> +if (ret < 0)
> +goto fail;
> +}
> +
>  dst->qscale_table_buf = av_buffer_ref(src->qscale_table_buf);
>  dst->mb_type_buf  = av_buffer_ref(src->mb_type_buf);
>  dst->pps_buf  = av_buffer_ref(src->pps_buf);
> @@ -159,6 +169,15 @@ int ff_h264_replace_picture(H264Context *h, H264Picture 
> *dst, const H264Picture
>  if (ret < 0)
>  goto fail;
> 
> +if (src->needs_fg) {
> +av_assert0(src->tf_grain.f == src->f_grain);
> +dst->tf_grain.f = dst->f_grain;
> +ff_thread_release_buffer(h->avctx, >tf_grain);
> +ret = ff_thread_ref_frame(>tf_grain, >tf_grain);
> +if (ret < 0)
> +goto fail;
> +}
> +
>  ret  = av_buffer_replace(>qscale_table_buf, src->qscale_table_buf);
>  ret |= av_buffer_replace(>mb_type_buf, src->mb_type_buf);
>  ret |= av_buffer_replace(>pps_buf, src->pps_buf);
> @@ -212,6 +231,7 @@ void ff_h264_set_erpic(ERPicture *dst, H264Picture *src)
>  int ff_h264_field_end(H264Context *h, H264SliceContext *sl, int in_setup)
>  {
>  AVCodecContext *const avctx = h->avctx;
> +H264Picture *cur = h->cur_pic_ptr;
>  int err = 0;
>  h->mb_y = 0;
> 
> @@ -230,10 +250,21 @@ int ff_h264_field_end(H264Context *h, H264SliceContext 
> *sl, int in_setup)
>  if (err < 0)
>  av_log(avctx, AV_LOG_ERROR,
> "hardware accelerator failed to decode picture\n");
> +} else if (!in_setup && cur->needs_fg) {
> +AVFrameSideData *sd = av_frame_get_side_data(cur->f, 
> AV_FRAME_DATA_FILM_GRAIN_PARAMS);
> +av_assert0(sd); // always present if `cur->needs_fg`
> +err = ff_h274_apply_film_grain(cur->f_grain, cur->f, >h274db,
> +   (AVFilmGrainParams *) sd->data);
> +if (err < 0) {
> +av_log(h->avctx, AV_LOG_WARNING, "Failed synthesizing film "
> +   "grain, ignoring: %s\n", av_err2str(err));
> +cur->needs_fg = 0;
> +err = 0;
> +}
>  }
> 
>  if (!in_setup && 

Re: [FFmpeg-devel] [PATCH v2 3/3] avcodec/h264dec: apply H.274 film grain

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Niklas Haas
> Sent: Tuesday, August 17, 2021 12:26 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Niklas Haas 
> Subject: [FFmpeg-devel] [PATCH v2 3/3] avcodec/h264dec: apply H.274 film grain
> 
> From: Niklas Haas 
> 
> Because we need access to ref frames without film grain applied, we have
> to add an extra AVFrame to H264Picture to avoid messing with the
> original. This requires some amount of overhead to make the reference
> moves work out, but it allows us to benefit from frame multithreading
> for film grain application "for free".
> 
> Unfortunately, this approach requires twice as much RAM to be constantly
> allocated for ref frames, due to the need for an extra buffer per
> H264Picture. In theory, we could get away with freeing up this memory as
> soon as it's no longer needed (since ref frames do not need film grain
> buffers any longer), but trying to call ff_thread_release_buffer() from
> output_frame() conflicts with possible later accesses to that same frame
> and I'm not sure how to synchronize that well.
> 
> Tested on all three cases of (no fg), (fg present but exported) and (fg
> present and not exported), with and without threading.
> 
> Signed-off-by: Niklas Haas 
> ---
>  libavcodec/h264_picture.c | 35 +--
>  libavcodec/h264_slice.c   | 16 ++--
>  libavcodec/h264dec.c  | 39 +++
>  libavcodec/h264dec.h  |  6 ++
>  4 files changed, 80 insertions(+), 16 deletions(-)
> 
> diff --git a/libavcodec/h264_picture.c b/libavcodec/h264_picture.c
> index ff30166b4d..5944798394 100644
> --- a/libavcodec/h264_picture.c
> +++ b/libavcodec/h264_picture.c
> @@ -43,13 +43,14 @@
> 
>  void ff_h264_unref_picture(H264Context *h, H264Picture *pic)
>  {
> -int off = offsetof(H264Picture, tf) + sizeof(pic->tf);
> +int off = offsetof(H264Picture, tf_grain) + sizeof(pic->tf_grain);
>  int i;
> 
>  if (!pic->f || !pic->f->buf[0])
>  return;
> 
>  ff_thread_release_buffer(h->avctx, >tf);
> +ff_thread_release_buffer(h->avctx, >tf_grain);
>  av_buffer_unref(>hwaccel_priv_buf);
> 
>  av_buffer_unref(>qscale_table_buf);
> @@ -93,6 +94,7 @@ static void h264_copy_picture_params(H264Picture *dst, 
> const H264Picture *src)
>  dst->mb_width  = src->mb_width;
>  dst->mb_height = src->mb_height;
>  dst->mb_stride = src->mb_stride;
> +dst->needs_fg  = src->needs_fg;
>  }
> 
>  int ff_h264_ref_picture(H264Context *h, H264Picture *dst, H264Picture *src)
> @@ -108,6 +110,14 @@ int ff_h264_ref_picture(H264Context *h, H264Picture 
> *dst, H264Picture *src)
>  if (ret < 0)
>  goto fail;
> 
> +if (src->needs_fg) {
> +av_assert0(src->tf_grain.f == src->f_grain);
> +dst->tf_grain.f = dst->f_grain;
> +ret = ff_thread_ref_frame(>tf_grain, >tf_grain);
> +if (ret < 0)
> +goto fail;
> +}
> +
>  dst->qscale_table_buf = av_buffer_ref(src->qscale_table_buf);
>  dst->mb_type_buf  = av_buffer_ref(src->mb_type_buf);
>  dst->pps_buf  = av_buffer_ref(src->pps_buf);
> @@ -159,6 +169,15 @@ int ff_h264_replace_picture(H264Context *h, H264Picture 
> *dst, const H264Picture
>  if (ret < 0)
>  goto fail;
> 
> +if (src->needs_fg) {
> +av_assert0(src->tf_grain.f == src->f_grain);
> +dst->tf_grain.f = dst->f_grain;
> +ff_thread_release_buffer(h->avctx, >tf_grain);
> +ret = ff_thread_ref_frame(>tf_grain, >tf_grain);
> +if (ret < 0)
> +goto fail;
> +}
> +
>  ret  = av_buffer_replace(>qscale_table_buf, src->qscale_table_buf);
>  ret |= av_buffer_replace(>mb_type_buf, src->mb_type_buf);
>  ret |= av_buffer_replace(>pps_buf, src->pps_buf);
> @@ -212,6 +231,7 @@ void ff_h264_set_erpic(ERPicture *dst, H264Picture *src)
>  int ff_h264_field_end(H264Context *h, H264SliceContext *sl, int in_setup)
>  {
>  AVCodecContext *const avctx = h->avctx;
> +H264Picture *cur = h->cur_pic_ptr;
>  int err = 0;
>  h->mb_y = 0;
> 
> @@ -230,10 +250,21 @@ int ff_h264_field_end(H264Context *h, H264SliceContext 
> *sl, int in_setup)
>  if (err < 0)
>  av_log(avctx, AV_LOG_ERROR,
> "hardware accelerator failed to decode picture\n");
> +} else if (!in_setup && cur->needs_fg) {
> +AVFrameSideData *sd = av_frame_get_side_data(cur->f, 
> AV_FRAME_DATA_FILM_GRAIN_PARAMS);
> +av_assert0(sd); // always present if `cur->needs_fg`
> +err = ff_h274_apply_film_grain(cur->f_grain, cur->f, >h274db,
> +   (AVFilmGrainParams *) sd->data);
> +if (err < 0) {
> +av_log(h->avctx, AV_LOG_WARNING, "Failed synthesizing film "
> +   "grain, ignoring: %s\n", av_err2str(err));
> +cur->needs_fg = 0;
> +err = 0;
> +}
>  }
> 
>  if 

Re: [FFmpeg-devel] [PATCH 08/12] fate/demux: convert flv-demux to ffprobe

[Eoff, Ullysses A]

TYVM Anton!  I will test it and close the Trac ticket if success on my end.

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Anton 
> Khirnov
> Sent: Wednesday, May 12, 2021 11:22 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 08/12] fate/demux: convert flv-demux to 
> ffprobe
> 
> Hey,
> Quoting Eoff, Ullysses A (2021-05-12 19:16:09)
> > *bump*
> >
> > Is anyone actively fixing this?  Anton?  Please.
> 
> Sorry about the delay, the patch was on the ML since Monday, but people
> had comments.
> 
> Just pushed it, the rest can be resolved later.
> 
> --
> 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] [PATCH 08/12] fate/demux: convert flv-demux to ffprobe

[Eoff, Ullysses A]

*bump*

Is anyone actively fixing this?  Anton?  Please.

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Eoff, 
> Ullysses A
> Sent: Tuesday, May 11, 2021 8:44 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 08/12] fate/demux: convert flv-demux to 
> ffprobe
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Anton 
> > Khirnov
> > Sent: Sunday, April 25, 2021 12:03 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH 08/12] fate/demux: convert flv-demux to 
> > ffprobe
> >
> > It can handle side data cleanly.
> > ---
> 
> This patch breaks FATE (http://trac.ffmpeg.org/ticket/9235).
> Please fix.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 08/12] fate/demux: convert flv-demux to ffprobe

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Anton 
> Khirnov
> Sent: Sunday, April 25, 2021 12:03 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 08/12] fate/demux: convert flv-demux to ffprobe
> 
> It can handle side data cleanly.
> ---

This patch breaks FATE (http://trac.ffmpeg.org/ticket/9235).
Please fix.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] fftools/ffmpeg_filter: Fix check for mjpeg encoder

[Eoff, Ullysses A]

Fixes #9186 for me.

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Andreas 
> Rheinhardt
> Sent: Tuesday, April 13, 2021 10:32 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt 
> Subject: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: Fix check for mjpeg 
> encoder
> 
> The MJPEG encoder supports some pixel format/color range combinations
> only when strictness is set to unofficial or less. Before commit
> 059fc2d9da5364627613fb3e6424079e14dbdfd3 said encoder's pix_fmts array
> only included the pixel formats supported with default strictness.
> When strictness was <= unofficial, fftools/ffmpeg_filter.c used
> an extended list of pixel formats instead of the encoder's including
> the pixel formats only supported when strictness <= unofficial.
> 
> Said commit turned the logic around: The encoder's pix_fmts array now
> included all pixel formats and fftools/ffmpeg_filter.c instead used
> a small list of all pixel formats supported when strictness is >
> unofficial and the encoder's pixel formats instead. In particular,
> the codec's pix_fmt is not used when strictness is normal.
> 
> This works for the mjpeg encoder; yet it did not work for other
> (hardware-based) mjpeg encoders, because the check for whether one is
> using the MJPEG encoder is wrong: It just checks the codec id.
> So if one used strict unofficial with a hardware-accelerated MJPEG
> encoder before commit 059fc2d9da53, the unofficial (non-hardware)
> pixel formats of the MJPEG encoder would be used; since said commit
> the codec's pixel formats are overridden at ordinary strictness
> by the ordinary MJPEG pixel formats. This leads to format conversion
> errors lateron which were reported in #9186.
> 
> The solution to this is to check AVCodec.name instead of its id.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  fftools/ffmpeg_filter.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 400f5a4188..e7c05eb3f9 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -41,13 +41,13 @@
> 
>  // FIXME: YUV420P etc. are actually supported with full color range,
>  // yet the latter information isn't available here.
> -static const enum AVPixelFormat *get_compliance_normal_pix_fmts(enum 
> AVCodecID codec_id, const enum AVPixelFormat
> default_formats[])
> +static const enum AVPixelFormat *get_compliance_normal_pix_fmts(const 
> AVCodec *codec, const enum AVPixelFormat
> default_formats[])
>  {
>  static const enum AVPixelFormat mjpeg_formats[] =
>  { AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
>AV_PIX_FMT_NONE };
> 
> -if (codec_id == AV_CODEC_ID_MJPEG) {
> +if (!strcmp(codec->name, "mjpeg")) {
>  return mjpeg_formats;
>  } else {
>  return default_formats;
> @@ -65,7 +65,7 @@ static enum AVPixelFormat choose_pixel_fmt(AVStream *st, 
> AVCodecContext *enc_ctx
>  enum AVPixelFormat best= AV_PIX_FMT_NONE;
> 
>  if (enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
> -p = get_compliance_normal_pix_fmts(enc_ctx->codec_id, p);
> +p = get_compliance_normal_pix_fmts(codec, p);
>  }
>  for (; *p != AV_PIX_FMT_NONE; p++) {
>  best = av_find_best_pix_fmt_of_2(best, *p, target, has_alpha, 
> NULL);
> @@ -113,7 +113,7 @@ static char *choose_pix_fmts(OutputFilter *ofilter)
> 
>  p = ost->enc->pix_fmts;
>  if (ost->enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
> -p = get_compliance_normal_pix_fmts(ost->enc_ctx->codec_id, p);
> +p = get_compliance_normal_pix_fmts(ost->enc, p);
>  }
> 
>  for (; *p != AV_PIX_FMT_NONE; p++) {
> --
> 2.27.0
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 6/9] avcodec/mjpegenc: Include all supported pix_fmts in mpegenc pix_fmts

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Andreas 
> Rheinhardt
> Sent: Tuesday, April 13, 2021 10:34 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 6/9] avcodec/mjpegenc: Include all 
> supported pix_fmts in mpegenc pix_fmts
> 
> Eoff, Ullysses A:
> > This commit breaks mjpeg_vaapi and mjpeg_qsv encoders.
> >
> > https://trac.ffmpeg.org/ticket/9186
> >
> > ...please fix.
> >
> 
> Please test this patch:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-April/279028.html
> It should now work on all strictness levels (it was broken before said
> commit when using -strict unofficial and is broken now on default
> strictness).
> 

Yes, that patch fixes it for me.  Thanks for the quick response!

> - Andreas
> 
> > Thanks,
> > U. Artie
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of Andreas 
> >> Rheinhardt
> >> Sent: Monday, April 05, 2021 10:40 PM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Cc: Andreas Rheinhardt 
> >> Subject: [FFmpeg-devel] [PATCH 6/9] avcodec/mjpegenc: Include all 
> >> supported pix_fmts in mpegenc pix_fmts
> >>
> >> Currently said list contains only the pixel formats that are always
> >> supported irrespective of the range and the value of
> >> strict_std_compliance. This makes the MJPEG encoder an outlier as all
> >> other codecs put all potentially supported pixel formats into said list
> >> and error out if the chosen pixel format is unsupported. This commit
> >> brings it therefore in line with the other encoders.
> >>
> >> The behaviour of fftools/ffmpeg_filter.c has been preserved. A more
> >> informed decision would be possible if colour range were available
> >> at this point, but it isn't.
> >>
> >> Signed-off-by: Andreas Rheinhardt 
> >> ---
> >>  fftools/ffmpeg_filter.c  | 20 +++-
> >>  libavcodec/encode.c  |  4 +---
> >>  libavcodec/ljpegenc.c| 14 +++---
> >>  libavcodec/mjpegenc.c| 11 ++-
> >>  libavcodec/mjpegenc_common.c | 16 
> >>  libavcodec/mjpegenc_common.h |  2 ++
> >>  libavcodec/mpegvideo_enc.c   | 28 +---
> >>  7 files changed, 40 insertions(+), 55 deletions(-)
> >>
> >> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> >> index 4ab769c07b..5c44b75eff 100644
> >> --- a/fftools/ffmpeg_filter.c
> >> +++ b/fftools/ffmpeg_filter.c
> >> @@ -39,22 +39,16 @@
> >>  #include "libavutil/imgutils.h"
> >>  #include "libavutil/samplefmt.h"
> >>
> >> -static const enum AVPixelFormat *get_compliance_unofficial_pix_fmts(enum 
> >> AVCodecID codec_id, const enum AVPixelFormat
> >> default_formats[])
> >> +// FIXME: YUV420P etc. are actually supported with full color range,
> >> +// yet the latter information isn't available here.
> >> +static const enum AVPixelFormat *get_compliance_normal_pix_fmts(enum 
> >> AVCodecID codec_id, const enum AVPixelFormat
> >> default_formats[])
> >>  {
> >>  static const enum AVPixelFormat mjpeg_formats[] =
> >>  { AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
> >> -  AV_PIX_FMT_YUV420P,  AV_PIX_FMT_YUV422P,  AV_PIX_FMT_YUV444P,
> >>AV_PIX_FMT_NONE };
> >> -static const enum AVPixelFormat ljpeg_formats[] =
> >> -{ AV_PIX_FMT_BGR24   , AV_PIX_FMT_BGRA, AV_PIX_FMT_BGR0,
> >> -  AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P,
> >> -  AV_PIX_FMT_YUV420P , AV_PIX_FMT_YUV444P , AV_PIX_FMT_YUV422P,
> >> -  AV_PIX_FMT_NONE};
> >>
> >>  if (codec_id == AV_CODEC_ID_MJPEG) {
> >>  return mjpeg_formats;
> >> -} else if (codec_id == AV_CODEC_ID_LJPEG) {
> >> -return ljpeg_formats;
> >>  } else {
> >>  return default_formats;
> >>  }
> >> @@ -70,8 +64,8 @@ static enum AVPixelFormat choose_pixel_fmt(AVStream *st, 
> >> AVCodecContext *enc_ctx
> >>  int has_alpha = desc ? desc->nb_components % 2 == 0 : 0;
> >>  enum AVPixelFormat best= AV_PIX_FMT_NONE;
> >>
> >> -if (enc_ctx->strict_std_compliance <= FF_COMPLIANCE_UNOFFICIAL) {
> >> -p = get_compliance_unofficial_pix_fmts(enc_ctx->codec_id, p);
> >> +if (enc_c

Re: [FFmpeg-devel] [PATCH 6/9] avcodec/mjpegenc: Include all supported pix_fmts in mpegenc pix_fmts

[Eoff, Ullysses A]

This commit breaks mjpeg_vaapi and mjpeg_qsv encoders.

https://trac.ffmpeg.org/ticket/9186

...please fix.

Thanks,
U. Artie

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Andreas 
> Rheinhardt
> Sent: Monday, April 05, 2021 10:40 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Andreas Rheinhardt 
> Subject: [FFmpeg-devel] [PATCH 6/9] avcodec/mjpegenc: Include all supported 
> pix_fmts in mpegenc pix_fmts
> 
> Currently said list contains only the pixel formats that are always
> supported irrespective of the range and the value of
> strict_std_compliance. This makes the MJPEG encoder an outlier as all
> other codecs put all potentially supported pixel formats into said list
> and error out if the chosen pixel format is unsupported. This commit
> brings it therefore in line with the other encoders.
> 
> The behaviour of fftools/ffmpeg_filter.c has been preserved. A more
> informed decision would be possible if colour range were available
> at this point, but it isn't.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  fftools/ffmpeg_filter.c  | 20 +++-
>  libavcodec/encode.c  |  4 +---
>  libavcodec/ljpegenc.c| 14 +++---
>  libavcodec/mjpegenc.c| 11 ++-
>  libavcodec/mjpegenc_common.c | 16 
>  libavcodec/mjpegenc_common.h |  2 ++
>  libavcodec/mpegvideo_enc.c   | 28 +---
>  7 files changed, 40 insertions(+), 55 deletions(-)
> 
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 4ab769c07b..5c44b75eff 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -39,22 +39,16 @@
>  #include "libavutil/imgutils.h"
>  #include "libavutil/samplefmt.h"
> 
> -static const enum AVPixelFormat *get_compliance_unofficial_pix_fmts(enum 
> AVCodecID codec_id, const enum AVPixelFormat
> default_formats[])
> +// FIXME: YUV420P etc. are actually supported with full color range,
> +// yet the latter information isn't available here.
> +static const enum AVPixelFormat *get_compliance_normal_pix_fmts(enum 
> AVCodecID codec_id, const enum AVPixelFormat
> default_formats[])
>  {
>  static const enum AVPixelFormat mjpeg_formats[] =
>  { AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
> -  AV_PIX_FMT_YUV420P,  AV_PIX_FMT_YUV422P,  AV_PIX_FMT_YUV444P,
>AV_PIX_FMT_NONE };
> -static const enum AVPixelFormat ljpeg_formats[] =
> -{ AV_PIX_FMT_BGR24   , AV_PIX_FMT_BGRA, AV_PIX_FMT_BGR0,
> -  AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P,
> -  AV_PIX_FMT_YUV420P , AV_PIX_FMT_YUV444P , AV_PIX_FMT_YUV422P,
> -  AV_PIX_FMT_NONE};
> 
>  if (codec_id == AV_CODEC_ID_MJPEG) {
>  return mjpeg_formats;
> -} else if (codec_id == AV_CODEC_ID_LJPEG) {
> -return ljpeg_formats;
>  } else {
>  return default_formats;
>  }
> @@ -70,8 +64,8 @@ static enum AVPixelFormat choose_pixel_fmt(AVStream *st, 
> AVCodecContext *enc_ctx
>  int has_alpha = desc ? desc->nb_components % 2 == 0 : 0;
>  enum AVPixelFormat best= AV_PIX_FMT_NONE;
> 
> -if (enc_ctx->strict_std_compliance <= FF_COMPLIANCE_UNOFFICIAL) {
> -p = get_compliance_unofficial_pix_fmts(enc_ctx->codec_id, p);
> +if (enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
> +p = get_compliance_normal_pix_fmts(enc_ctx->codec_id, p);
>  }
>  for (; *p != AV_PIX_FMT_NONE; p++) {
>  best = av_find_best_pix_fmt_of_2(best, *p, target, has_alpha, 
> NULL);
> @@ -118,8 +112,8 @@ static char *choose_pix_fmts(OutputFilter *ofilter)
>  exit_program(1);
> 
>  p = ost->enc->pix_fmts;
> -if (ost->enc_ctx->strict_std_compliance <= FF_COMPLIANCE_UNOFFICIAL) 
> {
> -p = get_compliance_unofficial_pix_fmts(ost->enc_ctx->codec_id, 
> p);
> +if (ost->enc_ctx->strict_std_compliance > FF_COMPLIANCE_UNOFFICIAL) {
> +p = get_compliance_normal_pix_fmts(ost->enc_ctx->codec_id, p);
>  }
> 
>  for (; *p != AV_PIX_FMT_NONE; p++) {
> diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> index 89df5235da..9a4140f91a 100644
> --- a/libavcodec/encode.c
> +++ b/libavcodec/encode.c
> @@ -564,9 +564,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  for (i = 0; avctx->codec->pix_fmts[i] != AV_PIX_FMT_NONE; i++)
>  if (avctx->pix_fmt == avctx->codec->pix_fmts[i])
>  break;
> -if (avctx->codec->pix_fmts[i] == AV_PIX_FMT_NONE
> -&& !(avctx->codec_id == AV_CODEC_ID_MJPEG
> - && avctx->strict_std_compliance <= 
> FF_COMPLIANCE_UNOFFICIAL)) {
> +if (avctx->codec->pix_fmts[i] == AV_PIX_FMT_NONE) {
>  char buf[128];
>  snprintf(buf, sizeof(buf), "%d", avctx->pix_fmt);
>  av_log(avctx, AV_LOG_ERROR, "Specified pixel format %s is 
> invalid or not supported\n",
> diff --git 

Re: [FFmpeg-devel] [PATCH 1/3] vaapi_encode_h264: Fix setting colour properties

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Jan Ekström
> Sent: Tuesday, November 03, 2020 3:17 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] vaapi_encode_h264: Fix setting colour 
> properties
> 
> On Tue, Nov 3, 2020 at 12:59 AM Mark Thompson  wrote:
> >
> > The properties should always be set; only the presence flags want to be
> > conditional.
> >
> > Fixes #8959.
> > ---
> 
> Thanks for this on such short notice. Patch set LGTM, and simplifies
> the logic nicely for these values (always set, only set flags if
> required).
> 
> Tested the H.264 and MPEG-2 encoders locally with my X230, with and
> without additional color space info with the general command mentioned
> in #8959. Unfortunately I lack the hardware to test HEVC for now.
> 
> Jan

Thanks.  Also...

Tested-By: Xu, Yefeng 

...whom also tested these patches with one of our quick internal test
suites covering 170 AVC, 73 HEVC and 30 MPEG2 cases on an ICL
platform.  With the patches, tests are fixed and no new regressions
detected.

Regards,
U. Artie


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

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

Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the multi-thread HWAccel decode error

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Eoff, 
> Ullysses A
> Sent: Wednesday, September 23, 2020 10:33 AM
> To: Xiang, Haihao ; ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the 
> multi-thread HWAccel decode error
> 
> I tested:
> 
> PASS: make THREADS=2 THREAD_TYPE=frame fate-vp8
> PASS: make THREADS=1 THREAD_TYPE=frame fate-vp8
> PASS: make THREADS=8 THREAD_TYPE=frame fate-vp8
> PASS: make THREADS=6 THREAD_TYPE=frame fate-vp8
> 
> FAIL: make THREADS=2 THREAD_TYPE=tile fate-vp8
> FAIL: make THREADS=1 THREAD_TYPE=tile fate-vp8
> FAIL: make THREADS=8 THREAD_TYPE=tile fate-vp8
> FAIL: make THREADS=6 THREAD_TYPE=tile fate-vp8
> 
> The vp8-2451 case fails, above, for tile thread type *without* this patch, 
> too.
> 
> This patch also fixes the issues reported at:
> 
> https://github.com/intel/media-driver/issues/1028 and
> https://github.com/intel/media-driver/issues/1028#issuecomment-695033952
> 
> Regards,
> U. Artie
> 

Oops, it is "slice" not "tile" (thanks BBB for your help), so:

PASS: make THREADS=2 THREAD_TYPE=slice fate-vp8
PASS: make THREADS=1 THREAD_TYPE=slice fate-vp8
PASS: make THREADS=8 THREAD_TYPE=slice fate-vp8
PASS: make THREADS=6 THREAD_TYPE=slice fate-vp8

Cheers,
U. Artie
___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavcodec/vp8dec: fix the multi-thread HWAccel decode error

[Eoff, Ullysses A]

I tested:

PASS: make THREADS=2 THREAD_TYPE=frame fate-vp8
PASS: make THREADS=1 THREAD_TYPE=frame fate-vp8
PASS: make THREADS=8 THREAD_TYPE=frame fate-vp8
PASS: make THREADS=6 THREAD_TYPE=frame fate-vp8

FAIL: make THREADS=2 THREAD_TYPE=tile fate-vp8
FAIL: make THREADS=1 THREAD_TYPE=tile fate-vp8
FAIL: make THREADS=8 THREAD_TYPE=tile fate-vp8
FAIL: make THREADS=6 THREAD_TYPE=tile fate-vp8

The vp8-2451 case fails, above, for tile thread type *without* this patch, too.

This patch also fixes the issues reported at:

https://github.com/intel/media-driver/issues/1028 and
https://github.com/intel/media-driver/issues/1028#issuecomment-695033952

Regards,
U. Artie

> -Original Message-
> From: Xiang, Haihao 
> Sent: Monday, September 21, 2020 8:09 PM
> To: ffmpeg-devel@ffmpeg.org; Eoff, Ullysses A 
> Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the 
> multi-thread HWAccel decode error
> 
> 
> > *bump*
> >
> > This patch fixes vp8d output corruption in multi-thread mode.  This bug has
> > existed for way too long.
> 
> This patch works fine for me too, could someone in MAINTAINERS take a look at
> this patch and merge it if no problem?
> 
> Thanks
> Haihao
> 
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of Wang,
> > > Shaofei
> > > Sent: Monday, July 01, 2019 1:22 AM
> > > To: FFmpeg development discussions and patches 
> > > Cc: Xiang, Haihao 
> > > Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the multi-
> > > thread HWAccel decode error
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > > > myp...@gmail.com
> > > > Sent: Monday, July 1, 2019 3:28 PM
> > > > To: FFmpeg development discussions and patches 
> > > > Cc: Xiang, Haihao 
> > > > Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the
> > > > multi-thread HWAccel decode error
> > > >
> > > > On Mon, Jul 1, 2019 at 2:38 PM Wang, Shaofei 
> > > > wrote:
> > > > Is it this patch https://patchwork.ffmpeg.org/patch/13723/ fix the same
> > > > issue?
> > >
> > > It won't fix this issue in vp8.
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the multi-thread HWAccel decode error

[Eoff, Ullysses A]

*bump*

This patch fixes vp8d output corruption in multi-thread mode.  This bug has 
existed for way too long.

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Wang, 
> Shaofei
> Sent: Monday, July 01, 2019 1:22 AM
> To: FFmpeg development discussions and patches 
> Cc: Xiang, Haihao 
> Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the 
> multi-thread HWAccel decode error
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > myp...@gmail.com
> > Sent: Monday, July 1, 2019 3:28 PM
> > To: FFmpeg development discussions and patches 
> > Cc: Xiang, Haihao 
> > Subject: Re: [FFmpeg-devel] [PATCH v3] libavcodec/vp8dec: fix the
> > multi-thread HWAccel decode error
> >
> > On Mon, Jul 1, 2019 at 2:38 PM Wang, Shaofei 
> > wrote:
> > Is it this patch https://patchwork.ffmpeg.org/patch/13723/ fix the same
> > issue?
> It won't fix this issue in vp8.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Fu, Linjie
> Sent: Friday, March 13, 2020 8:18 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: add -autoscale to 
> disable/enable the default scale
> 
> > From: ffmpeg-devel  On Behalf Of
> > Nicolas George
> > Sent: Tuesday, February 18, 2020 03:02
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: add -autoscale
> > to disable/enable the default scale
> >
> > Gyan Doshi (12020-02-18):
> > > Protection in the command line tool will help steer the user towards
> > > choosing an accommodating encoder, which is possible once the flag and a
> > > check is added.
> >
> > True, but minor and should not block the patch.
> >
> 
> Ping, thanks.
> 
> - Linjie

Are all of the reviews addressed for this patch?  Is it ready to be merged, yet?

Cheers,
U. Artie

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 v5] avfilter/vaapi: add overlay_vaapi filter

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Eoff, 
> Ullysses A
> Sent: Tuesday, October 22, 2019 9:00 PM
> To: FFmpeg development discussions and patches 
> Cc: Zhou, Zachary 
> Subject: Re: [FFmpeg-devel] [PATCH v5] avfilter/vaapi: add overlay_vaapi 
> filter
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of Zachary 
> > Zhou
> > Sent: Sunday, September 08, 2019 11:51 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Zhou, Zachary 
> > Subject: [FFmpeg-devel] [PATCH v5] avfilter/vaapi: add overlay_vaapi filter
> >
> 
> Do you need to set params.pipeline_flags = VA_PROC_PIPELINE_SUBPICTURES
> somewhere for this to work?

Nevermind... this vaapi vpp pipeline flag is not needed (i.e. your method 
doesn't
use surface subpictures).

Sorry for the noise.

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 v5] avfilter/vaapi: add overlay_vaapi filter

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Zachary Zhou
> Sent: Sunday, September 08, 2019 11:51 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zhou, Zachary 
> Subject: [FFmpeg-devel] [PATCH v5] avfilter/vaapi: add overlay_vaapi filter
> 

Do you need to set params.pipeline_flags = VA_PROC_PIPELINE_SUBPICTURES
somewhere for this 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".

Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale

[Eoff, Ullysses A]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Michael Niedermayer
> On Mon, Jul 15, 2019 at 06:38:35PM +0800, Linjie Fu wrote:
> > +{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
> > +  OPT_EXPERT | OPT_INPUT,  
> >   { .off = OFFSET(autoscale) },
> > +"automatically insert correct scale filters" },
> 
> I think this description is inadequate to understand what the option does.
> Scale filters are inserted at various places (for example within a filter
> graph). This option here affects a specific case.
> 

Would this be sufficient?

"automatically insert a scale filter to scale the output of all frames to
  match the resolution of the initial frame"

If not, any other suggestions?

Thanks,
U. Artie
___
ffmpeg-devel mailing list
ffmpeg-devel@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] doc/ffmpeg.texi: update docs for autoscale/autorotate

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Nicolas George
> Sent: Thursday, July 18, 2019 2:01 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] doc/ffmpeg.texi: update docs for 
> autoscale/autorotate
> 
> Fu, Linjie (12019-07-18):
> > Yes, will update as Artie had suggested if no more comments:
> >
> > When autoscale is disabled, all output frames might not be in the
> > same resolution and may require some additional explicit processing
> > according to your final rendering/output destination.
> 
> That is not enough. You have to tell the user that this option will most
> likely not work at all, and why.
> 

@Nicolas, do you have any "examples" of what you might add to this?

Maybe something additional like this is enough:

Disabling autoscale may not work in all situations.  Therefore, it is not
recommended to disable it unless you really know what you are doing.
Disable autoscale at your own risk.

> Regards,
> 
> --
>   Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH, v2 2/2] doc/ffmpeg.texi: update docs for autoscale/autorotate

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Linjie Fu
> Sent: Tuesday, July 16, 2019 4:20 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [FFmpeg-devel] [PATCH, v2 2/2] doc/ffmpeg.texi: update docs for 
> autoscale/autorotate
> 
> Add docs for autoscale.
> 
> Update information for autorotate according to ffplay.
> 
> Signed-off-by: Linjie Fu 
> ---
>  doc/ffmpeg.texi | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index cd35eb49c8..b91da2b2b4 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -734,10 +734,6 @@ ffmpeg -dump_attachment:t "" -i INPUT
>  Technical note -- attachments are implemented as codec extradata, so this
>  option can actually be used to extract extradata from any stream, not just
>  attachments.
> -
> -@item -noautorotate
> -Disable automatically rotating video based on file metadata.
> -
>  @end table
> 
>  @section Video Options
> @@ -819,6 +815,16 @@ Create the filtergraph specified by @var{filtergraph} 
> and use it to
>  filter the stream.
> 
>  This is an alias for @code{-filter:v}, see the @ref{filter_option,,-filter 
> option}.
> +
> +@item -autorotate
> +Automatically rotate the video according to file metadata. Enabled by
> +default, use @option{-noautorotate} to disable it.
> +
> +@item -autoscale
> +Automatically scale the video according to the resolution of first frame.
> +Enabled by default, use @option{-noautoscale} to disable it. Each frame of
> +the output raw video can be in different resolutions and is in need to be
> +handled next.

This last sentence has strange grammar.  Here's my shot at it:

"When autoscale is disabled, all output frames might not be in the
same resolution and may require some additional explicit processing
according to your final rendering/output destination."

>  @end table
> 
>  @section Advanced Video options
> --
> 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 mailing list
ffmpeg-devel@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] fftools/ffmpeg_filter: use -reinit_filter to disable/enable auto scale

[Eoff, Ullysses A]

> > > Add an option to disable/enable "auto insert" is Ok for me, but I
> > > think if you reuse the -reinit_filter option, you need to update doc
> > > part at the same time.
> >
> > I prefer to add a separate option, too.
> > Depending on the comments, I'll either update doc for reinit_filter, or add 
> > a
> > new option and related doc.
> 
> Since there is an existed option named "autorotate", add an new option 
> "autoscale" looks can keep tune.

I like the idea of having a new option, too.  The option name "reinit_filter" 
doesn't imply anything
about "scaling"... it's just a side-effect.  That is, reinit_filter could cause 
other filters to behave
differently too, right?  So an explicit option to enable/disable auto scale 
would imply a more
obvious expectation to the user.

U. Artie

___
ffmpeg-devel mailing list
ffmpeg-devel@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] avfilter: add rawdump filter

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Michael Niedermayer
> Sent: Friday, July 12, 2019 11:21 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> 
> > On Wed, Jul 10, 2019 at 07:54:32PM +, Eoff, Ullysses A wrote:
> > Although -reinit_filter 0 works in some cases, it is quite
> > verbose.  And I have found many other cases where it
> > doesn't work when we need to specify additional filters
> > (e.g. hwupload, hwdownload when doing qsv or vaapi
> > accelerated decoding with hw output formats).
> 
> can you fix the cases which do not work so the code works with
> -reinit_filter 0 ?
> 

 Linjie's patch should fix it: https://patchwork.ffmpeg.org/patch/13905/

> Thanks
> 
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Democracy is the form of government in which you can choose your dictator
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avfilter: add rawdump filter

[Eoff, Ullysses A]

> -Original Message-
> From: Eoff, Ullysses A
> Sent: Tuesday, July 09, 2019 6:45 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Eoff, Ullysses A 
> Subject: [PATCH] avfilter: add rawdump filter
> 
> This filter enables raw frames to be dumped to a
> file before they are sent through the auto-inserted
> scaler filter and useful when you want unscaled
> raw frames in an output file.
> 

The primary goal that I'm trying to achieve here is
dump raw "unscaled" yuv to an output file while 
decoding a multi-resolution video.  Unfortunately,
the ffmpeg utility auto-inserts a scaler into the filter
graph, so -f rawvideo doesn't suffice here since the
decoded data passes through the scaler before it's
handed off to the rawvideo filter.

I experimented with the alternative methods suggested
in earlier feedback.  More specifically, "reinit_filter"
and "split" were suggested.

For "split" filter, I couldn't find a way that it could bypass
the auto-inserted scaler.

Although -reinit_filter 0 works in some cases, it is quite
verbose.  And I have found many other cases where it
doesn't work when we need to specify additional filters
(e.g. hwupload, hwdownload when doing qsv or vaapi
accelerated decoding with hw output formats).

So, afaict, this patch is the only reliable method I can
find to intercept the decoded data before it reaches
the scaler for various use-cases (although the patch still
needs a little bit of work as pointed out in previous
replies).

For added context, my organizations team and I contribute
to both msdk/qsv and vaapi plugins for ffmpeg and
gstreamer development.  The idea is we want a way to
validate that direct decoder output is an exact bitmatch
across every decoder solution that we contribute
to (to provide a better and more consistent end-user
experience regardless of end-user choice).  But since
ffmpeg auto-inserts this "scaler" and not all scaling
algo's are equal, it poses a challenge to verify.

Regards,
U. Artie

___
ffmpeg-devel mailing list
ffmpeg-devel@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] avfilter: add rawdump filter

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Gyan
> Sent: Wednesday, July 10, 2019 7:33 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> 
> 
> 
> On 10-07-2019 07:51 PM, Eoff, Ullysses A wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> >> Hendrik Leppkes
> >> Sent: Wednesday, July 10, 2019 4:13 AM
> >> To: FFmpeg development discussions and patches 
> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> >>
> >> ...
> >> I believe using -reinit_filter 0 with ffmpeg can achieve such a
> >> result., as long as you make sure all filtering done (preferably none)
> >> is capable of on-the-fly changes.
> >>
> > Excellent!  I wouldn't have thought to try -reinit_filter 0 for such a 
> > scenario.  I
> > just tried it and it achieves the exact result we're looking for.  But it's 
> > unfortunate
> > that it generates a warning message for every frame processed.  Is there a 
> > simple
> > way to silence that message, yet still get other verbose logging (I don't 
> > want to
> > flood our automation logs)?
> 
> No. You'll have to upgrade the level in libavfilter/buffersrc.c
> 

I see.  Would anyone object if I sent a patch to upgrade the level to 
AV_LOG_DEBUG?

> Gyan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] avfilter: add rawdump filter

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Nicolas George
> Sent: Wednesday, July 10, 2019 7:53 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> 
> Eoff, Ullysses A (12019-07-10):
> > For the record, this "static" is a problem if multiple rawdump filters are
> > specified in the graph.  The initial reason for this was to open the file 
> > for
> > writing on the first init (to overwrite any pre-existing file), then open 
> > for
> > appending on successive reinit's (e.g. frame resolution changes).  Thus,
> > would need a better solution to achieve the same result without
> > influencing other instances of the filter.
> 
> The variable needs to be in the filter's private context, nothing more.
> 

Each time init is called (i.e. for reinit on resolution change), the private 
context is a
new instance.  On first init we want mode="w" for each rawdump filter in the
graph, but on reinit we want mode="a".  How do we achieve this when every
call to init passes a new private context instance.  I am not very familiar with
ffmpeg's programming API's, so maybe I'm missing something?

> Regards,
> 
> --
>   Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Nicolas George
> Sent: Wednesday, July 10, 2019 8:05 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> 
> Eoff, Ullysses A (12019-07-10):
> > Agree.  There are many ways to specify format.  But there are some formats
> > which one might want to dump that some hw drivers can't output directly
> > without conversion.
> 
> In that case, your goal to avoid conversion is moot.
> 

The goal is to avoid scaling ;-)

> Regards,
> 
> --
>   Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Lynne
> Sent: Wednesday, July 10, 2019 7:52 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> 
> 
> 
> 
> Jul 10, 2019, 3:26 PM by ullysses.a.e...@intel.com:
> 
> >> -Original Message-
> >> From: Paul B Mahol [mailto:one...@gmail.com]
> >> Sent: Wednesday, July 10, 2019 7:20 AM
> >> To: Eoff, Ullysses A 
> >> Cc: FFmpeg development discussions and patches 
> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> >>
> >> On 7/10/19, Eoff, Ullysses A  wrote:
> >> >> -Original Message-
> >> >> From: Paul B Mahol [mailto:one...@gmail.com]
> >> >> Sent: Wednesday, July 10, 2019 3:25 AM
> >> >> To: FFmpeg development discussions and patches 
> >> >> Cc: Eoff, Ullysses A 
> >> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> >> >>
> >> >> On 7/10/19, Fu, Linjie  wrote:
> >> >> >> -Original Message-
> >> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> >> >> >> Of Paul B Mahol
> >> >> >> Sent: Wednesday, July 10, 2019 15:55
> >> >> >> To: FFmpeg development discussions and patches  >> >> >> de...@ffmpeg.org>
> >> >> >> Cc: Eoff, Ullysses A 
> >> >> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> >> >> >>
> >> >> >> On 7/10/19, U. Artie Eoff  wrote:
> >> >> >> > This filter enables raw frames to be dumped to a
> >> >> >> > file before they are sent through the auto-inserted
> >> >> >> > scaler filter and useful when you want unscaled
> >> >> >> > raw frames in an output file.
> >> >> >> >
> >> >> >>
> >> >> >> Why?
> >> >> >>
> >> >> >> -f rawvideo doesn't work for you?
> >> >> >
> >> >> > unscaled raw video could be dumped through this filter in resolution
> >> >> > changing cases.
> >> >> >
> >> >>
> >> >> Maybe, I still fail how this filter is useful, when user can use split
> >> >> filter to dump video
> >> >> at any point in graph.
> >> >>
> >> >
> >> > If there are already other ways to achieve the same result without this
> >> > filter then that's great!  Essentially, I'm trying to achieve exactly 
> >> > what
> >> > Linjie stated so we can compare raw results across different decoder
> >> > solutions.  And the forced insertion of the auto scaler in ffmpeg makes
> >> > that difficult for multi-resolution cases.
> >>
> >> Please provide examples of filtergraph where you are supposed to use
> >> this "filter".
> >>
> >
> > ffmpeg -v verbose -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \
> >  -i input.h264 -vf 'format=nv12,rawdump=file=./ffdump.yuv' -f null -
> >
> 
> You can make the decoder output nv12 directly via -hwaccel_output_format nv12

Agree.  There are many ways to specify format.  But there are some formats
which one might want to dump that some hw drivers can't output directly
without conversion. 

> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] avfilter: add rawdump filter

[Eoff, Ullysses A]

> -Original Message-
> From: Nicolas George [mailto:geo...@nsup.org]
> Sent: Wednesday, July 10, 2019 7:37 AM
> To: FFmpeg development discussions and patches 
> Cc: Eoff, Ullysses A 
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> 
> U. Artie Eoff (12019-07-09):
> > +FILE *rawdump_file;
> 
> Independently from the question of whether this filter is useful or not,
> I think the dump should have used AVIO.
> 

Thanks for the tip!  Even though this patch is redundant and
unnecessary (based on feedback)... I will have a look at AVIO for
future changes/patches.

Cheers,
U. Artie

> Regards,
> 
> --
>   Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter

[Eoff, Ullysses A]

> From: Eoff, Ullysses A
> +static av_cold int rawdump_init(AVFilterContext *avctx)
> +{
> +RawDumpContext *ctx = avctx->priv;
> +static char *mode = "w";

For the record, this "static" is a problem if multiple rawdump filters are
specified in the graph.  The initial reason for this was to open the file for
writing on the first init (to overwrite any pre-existing file), then open for
appending on successive reinit's (e.g. frame resolution changes).  Thus,
would need a better solution to achieve the same result without
influencing other instances of the filter.

> +
> +ctx->rawdump_file = fopen(ctx->rawdump_file_str, mode);
> +
> +if (ctx->rawdump_file == NULL) {
> +int err = AVERROR(errno);
> +char buf[128];
> +av_strerror(err, buf, sizeof(buf));
> +av_log(ctx, AV_LOG_ERROR, "Failed to open %s for dumping: %s\n",
> +   ctx->rawdump_file_str, buf);
> +return err;
> +}
> +
> +av_log(ctx, AV_LOG_DEBUG, "Opened %s (mode:%s) for dumping.\n",
> +   ctx->rawdump_file_str, mode);
> +
> +mode = "a";
> +
> +return 0;
> +}
> +
> +static av_cold void rawdump_uninit(AVFilterContext *avctx)
> +{
> +RawDumpContext *ctx = avctx->priv;
> +
> +if (ctx->rawdump_file != NULL)
> +fclose(ctx->rawdump_file);
> +}
> +
> +#define OFFSET(x) offsetof(RawDumpContext, x)
> +#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
> +static const AVOption rawdump_options[] = {
> +{"file", "Set file where to dump raw frames", OFFSET(rawdump_file_str), 
> AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, FLAGS },
> +{ NULL }
> +};
> +
> +AVFILTER_DEFINE_CLASS(rawdump);
> +
> +static const AVFilterPad rawdump_inputs[] = {
> +{
> +.name = "default",
> +.type = AVMEDIA_TYPE_VIDEO,
> +.filter_frame = rawdump_filter_frame,
> +},
> +{ NULL }
> +};
> +
> +static const AVFilterPad rawdump_outputs[] = {
> +{
> +.name = "default",
> +.type = AVMEDIA_TYPE_VIDEO,
> +},
> +{ NULL }
> +};
> +
> +AVFilter ff_vf_rawdump = {
> +.name  = "rawdump",
> +.description   = NULL_IF_CONFIG_SMALL("Dump frames to file"),
> +.init  = rawdump_init,
> +.uninit= rawdump_uninit,
> +.query_formats = rawdump_query_formats,
> +.priv_size = sizeof(RawDumpContext),
> +.priv_class= _class,
> +.inputs= rawdump_inputs,
> +.outputs   = rawdump_outputs,
> +};
> --
> 2.20.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] avfilter: add rawdump filter

[Eoff, Ullysses A]

> -Original Message-
> From: Paul B Mahol [mailto:one...@gmail.com]
> Sent: Wednesday, July 10, 2019 7:20 AM
> To: Eoff, Ullysses A 
> Cc: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> 
> On 7/10/19, Eoff, Ullysses A  wrote:
> >> -Original Message-
> >> From: Paul B Mahol [mailto:one...@gmail.com]
> >> Sent: Wednesday, July 10, 2019 3:25 AM
> >> To: FFmpeg development discussions and patches 
> >> Cc: Eoff, Ullysses A 
> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> >>
> >> On 7/10/19, Fu, Linjie  wrote:
> >> >> -Original Message-
> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> >> >> Of Paul B Mahol
> >> >> Sent: Wednesday, July 10, 2019 15:55
> >> >> To: FFmpeg development discussions and patches  >> >> de...@ffmpeg.org>
> >> >> Cc: Eoff, Ullysses A 
> >> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> >> >>
> >> >> On 7/10/19, U. Artie Eoff  wrote:
> >> >> > This filter enables raw frames to be dumped to a
> >> >> > file before they are sent through the auto-inserted
> >> >> > scaler filter and useful when you want unscaled
> >> >> > raw frames in an output file.
> >> >> >
> >> >>
> >> >> Why?
> >> >>
> >> >> -f rawvideo doesn't work for you?
> >> >
> >> > unscaled raw video could be dumped through this filter in resolution
> >> > changing cases.
> >> >
> >>
> >> Maybe, I still fail how this filter is useful, when user can use split
> >> filter to dump video
> >> at any point in graph.
> >>
> >
> > If there are already other ways to achieve the same result without this
> > filter then that's great!  Essentially, I'm trying to achieve exactly what
> > Linjie stated so we can compare raw results across different decoder
> > solutions.  And the forced insertion of the auto scaler in ffmpeg makes
> > that difficult for multi-resolution cases.
> 
> Please provide examples of filtergraph where you are supposed to use
> this "filter".
> 

ffmpeg -v verbose -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \
  -i input.h264 -vf 'format=nv12,rawdump=file=./ffdump.yuv' -f null -

> >
> > Could you point me to an example of using split to achieve this?
> 
> See documentation of split filter.

Thanks.  I will take a look and experiment with it.

> 
> >
> > U. Artie
> >
> >>
> >> > IMHO, it will be great if there are some options available to
> >> > disable/enable
> >> > the auto scaling filter
> >> > in pipeline, thus the whole stream doesn't need to be scaled into the
> >> > same
> >> > size of the first frame.
> >> > The difference in scale algorithms will make it hard to compare the
> >> > output
> >> > with other decoder.
> >> >
> >> > - linjie
> >> > ___
> >> > ffmpeg-devel mailing list
> >> > ffmpeg-devel@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] avfilter: add rawdump filter

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Hendrik Leppkes
> Sent: Wednesday, July 10, 2019 4:13 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> 
> On Wed, Jul 10, 2019 at 12:13 PM Fu, Linjie  wrote:
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > > Of Paul B Mahol
> > > Sent: Wednesday, July 10, 2019 15:55
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Cc: Eoff, Ullysses A 
> > > Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> > >
> > > On 7/10/19, U. Artie Eoff  wrote:
> > > > This filter enables raw frames to be dumped to a
> > > > file before they are sent through the auto-inserted
> > > > scaler filter and useful when you want unscaled
> > > > raw frames in an output file.
> > > >
> > >
> > > Why?
> > >
> > > -f rawvideo doesn't work for you?
> >
> > unscaled raw video could be dumped through this filter in resolution 
> > changing cases.
> >
> > IMHO, it will be great if there are some options available to 
> > disable/enable the auto scaling filter
> > in pipeline, thus the whole stream doesn't need to be scaled into the same 
> > size of the first frame.
> > The difference in scale algorithms will make it hard to compare the output 
> > with other decoder.
> >
> 
> I believe using -reinit_filter 0 with ffmpeg can achieve such a
> result., as long as you make sure all filtering done (preferably none)
> is capable of on-the-fly changes.
> 

Excellent!  I wouldn't have thought to try -reinit_filter 0 for such a 
scenario.  I
just tried it and it achieves the exact result we're looking for.  But it's 
unfortunate
that it generates a warning message for every frame processed.  Is there a 
simple
way to silence that message, yet still get other verbose logging (I don't want 
to
flood our automation logs)?

U. Artie

> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avfilter: add rawdump filter

[Eoff, Ullysses A]

> -Original Message-
> From: Paul B Mahol [mailto:one...@gmail.com]
> Sent: Wednesday, July 10, 2019 3:25 AM
> To: FFmpeg development discussions and patches 
> Cc: Eoff, Ullysses A 
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> 
> On 7/10/19, Fu, Linjie  wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> >> Of Paul B Mahol
> >> Sent: Wednesday, July 10, 2019 15:55
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Cc: Eoff, Ullysses A 
> >> Subject: Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> >>
> >> On 7/10/19, U. Artie Eoff  wrote:
> >> > This filter enables raw frames to be dumped to a
> >> > file before they are sent through the auto-inserted
> >> > scaler filter and useful when you want unscaled
> >> > raw frames in an output file.
> >> >
> >>
> >> Why?
> >>
> >> -f rawvideo doesn't work for you?
> >
> > unscaled raw video could be dumped through this filter in resolution
> > changing cases.
> >
> 
> Maybe, I still fail how this filter is useful, when user can use split
> filter to dump video
> at any point in graph.
> 

If there are already other ways to achieve the same result without this
filter then that's great!  Essentially, I'm trying to achieve exactly what
Linjie stated so we can compare raw results across different decoder
solutions.  And the forced insertion of the auto scaler in ffmpeg makes
that difficult for multi-resolution cases.

Could you point me to an example of using split to achieve this?

U. Artie

> 
> > IMHO, it will be great if there are some options available to disable/enable
> > the auto scaling filter
> > in pipeline, thus the whole stream doesn't need to be scaled into the same
> > size of the first frame.
> > The difference in scale algorithms will make it hard to compare the output
> > with other decoder.
> >
> > - linjie
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@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 v4] vaapi_encode_mjpeg: fix bad component id bug

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Andreas Rheinhardt
> Sent: Thursday, June 13, 2019 2:11 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v4] vaapi_encode_mjpeg: fix bad component 
> id bug
> 
> Dominik 'Rathann' Mierzejewski:
> > On Friday, 07 June 2019 at 23:45, U. Artie Eoff wrote:
> >> The compound literals assigned to "components"
> >> only exist within the scope of the if/else
> >> block (thanks Mark Thompson for the better
> >> explanation).
> >>
> >> Thus, after this if/else block, "components"
> >> ends up pointing to an arbitrary/undefined
> >> array.  With some compilers and depending on
> >> optimization settings, these arbitrary values
> >> may end up being the same value (i.e. 0 with
> >> GNU GCC 9.x).  Unfortunately, the GNU GCC
> >> compiler, at least, never prints any warnings
> >> about this.
> >>
> >> This patch fixes this issue by assigning the
> >> constant arrays to local variables at function
> >> scope and then pointing "components" to those
> >> as necessary.
> >>
> >> Fixes #7915
> >
> > Brilliant detective work, Artie. Could you open a bug report with gcc
> > upstream? A case like this should get an explicit warning from gcc like
> > you pointed out.
> >
> > Regards,
> > Dominik
> >
> A request for this has already been opened [1].
> It seems that this is also responsible for filesystem corruption on
> linux when using a SSD cache + HDD combination (see [2]).
> 

According to comments in the gcc request, it looks like we
could use " -fsanitize=address".  Anyone care to test it
out to see if it will work?

> - Andreas
> 
> [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89990
> [2]: https://bugzilla.kernel.org/show_bug.cgi?id=203573
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 v4] vaapi_encode_mjpeg: fix bad component id bug

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Reimar Döffinger
> Sent: Friday, June 07, 2019 11:07 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH v4] vaapi_encode_mjpeg: fix bad component 
> id bug
> 
> On 07.06.2019, at 23:45, "U. Artie Eoff"  wrote:
> 
> > The compound literals assigned to "components"
> > only exist within the scope of the if/else
> > block (thanks Mark Thompson for the better
> > explanation).
> >
> > Thus, after this if/else block, "components"
> > ends up pointing to an arbitrary/undefined
> > array.  With some compilers and depending on
> > optimization settings, these arbitrary values
> > may end up being the same value (i.e. 0 with
> > GNU GCC 9.x).  Unfortunately, the GNU GCC
> > compiler, at least, never prints any warnings
> > about this.
> >
> > This patch fixes this issue by assigning the
> > constant arrays to local variables at function
> > scope and then pointing "components" to those
> > as necessary.
> >
> > Fixes #7915
> >
> > Signed-off-by: U. Artie Eoff 
> > ---
> > libavcodec/vaapi_encode_mjpeg.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode_mjpeg.c 
> > b/libavcodec/vaapi_encode_mjpeg.c
> > index 4dcdc3d16bb0..bd029cc90315 100644
> > --- a/libavcodec/vaapi_encode_mjpeg.c
> > +++ b/libavcodec/vaapi_encode_mjpeg.c
> > @@ -227,6 +227,8 @@ static int 
> > vaapi_encode_mjpeg_init_picture_params(AVCodecContext *avctx,
> > JPEGRawScanHeader *sh = >scan.header;
> > VAEncPictureParameterBufferJPEG *vpic = pic->codec_picture_params;
> > const AVPixFmtDescriptor *desc;
> > +const uint8_t components_rgb[3] = { 'R', 'G', 'B' };
> > +const uint8_t components_yuv[3] = {  1,   2,   3  };
> 
> Not sure what the necessary scope is for these, but maybe safest to go for 
> "static const"?

I don't think these need scope beyond this function since the values are just
"copied" into the frame header here.  So static would just be an [barely 
detectable]
optimization.  Unless I am missing something?

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

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

Re: [FFmpeg-devel] [PATCH v3] vaapi_encode_mjpeg: fix bad component id bug

[Eoff, Ullysses A]

> -Original Message-
> From: Eoff, Ullysses A
> Sent: Friday, June 07, 2019 2:42 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Eoff, Ullysses A 
> Subject: [PATCH v3] vaapi_encode_mjpeg: fix bad component id bug
> 
> The compound literals assigned to "components"
> only exist within the scope of the if/else
> block (thanks Mike Thompson for the better

Oh crap, I got your name wrong.  It must be a Friday!  V4 coming up!

> explanation).
> 
> Thus, after this if/else block, "components"
> ends up pointing to an arbitrary/undefined
> array.  With some compilers and depending on
> optimization settings, these arbitrary values
> may end up being the same value (i.e. 0 with
> GNU GCC 9.x).  Unfortunately, the GNU GCC
> compiler, at least, never prints any warnings
> about this.
> 
> This patch fixes this issue by assigning the
> constant arrays to local variables at function
> scope and then pointing "components" to those
> as necessary.
> 
> Fixes #7915
> 
> Signed-off-by: U. Artie Eoff 
> ---
>  libavcodec/vaapi_encode_mjpeg.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode_mjpeg.c b/libavcodec/vaapi_encode_mjpeg.c
> index 4dcdc3d16bb0..bd029cc90315 100644
> --- a/libavcodec/vaapi_encode_mjpeg.c
> +++ b/libavcodec/vaapi_encode_mjpeg.c
> @@ -227,6 +227,8 @@ static int 
> vaapi_encode_mjpeg_init_picture_params(AVCodecContext *avctx,
>  JPEGRawScanHeader *sh = >scan.header;
>  VAEncPictureParameterBufferJPEG *vpic = pic->codec_picture_params;
>  const AVPixFmtDescriptor *desc;
> +const uint8_t components_rgb[3] = { 'R', 'G', 'B' };
> +const uint8_t components_yuv[3] = {  1,   2,   3  };
>  const uint8_t *components;
>  int t, i, quant_scale, len;
> 
> @@ -235,9 +237,9 @@ static int 
> vaapi_encode_mjpeg_init_picture_params(AVCodecContext *avctx,
>  desc = av_pix_fmt_desc_get(priv->common.input_frames->sw_format);
>  av_assert0(desc);
>  if (desc->flags & AV_PIX_FMT_FLAG_RGB)
> -components = (uint8_t[3]) { 'R', 'G', 'B' };
> +components = components_rgb;
>  else
> -components = (uint8_t[3]) {  1,   2,   3  };
> +components = components_yuv;
> 
>  // Frame header.
> 
> --
> 2.20.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] vaapi_encode_mjpeg: fix bad component id bug

[Eoff, Ullysses A]

> -Original Message-
> From: Eoff, Ullysses A
> Sent: Friday, June 07, 2019 2:11 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Eoff, Ullysses A 
> Subject: [PATCH v2] vaapi_encode_mjpeg: fix bad component id bug
> 
> When compile time optimizations are enabled and
> compiling with GNU GCC 9.x, the pointer assignment
> to the inline brace-enclosed list initialized
> array does not work and "component" ends up pointing
> to an empty/undefined array.  Thus, all of the
> frame header component id's get assigned the
> same value of 0.
> 
> As Mark Thompson described, this is caused by
> "...the compound literals only exist in the tiny
> scope of the if/else branches..." which strangely
> is not producing a compiler warning.
> 
> This patch fixes this issue by assigning the constant
> arrays to local variables at function scope and then
> pointing "component" to those as necessary.
> 
> Fixes #7915
> 

Hmmm... now I don't like this commit message.  Let me revise in a V3 ;)

> Signed-off-by: U. Artie Eoff 
> ---
>  libavcodec/vaapi_encode_mjpeg.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode_mjpeg.c b/libavcodec/vaapi_encode_mjpeg.c
> index 4dcdc3d16bb0..bd029cc90315 100644
> --- a/libavcodec/vaapi_encode_mjpeg.c
> +++ b/libavcodec/vaapi_encode_mjpeg.c
> @@ -227,6 +227,8 @@ static int 
> vaapi_encode_mjpeg_init_picture_params(AVCodecContext *avctx,
>  JPEGRawScanHeader *sh = >scan.header;
>  VAEncPictureParameterBufferJPEG *vpic = pic->codec_picture_params;
>  const AVPixFmtDescriptor *desc;
> +const uint8_t components_rgb[3] = { 'R', 'G', 'B' };
> +const uint8_t components_yuv[3] = {  1,   2,   3  };
>  const uint8_t *components;
>  int t, i, quant_scale, len;
> 
> @@ -235,9 +237,9 @@ static int 
> vaapi_encode_mjpeg_init_picture_params(AVCodecContext *avctx,
>  desc = av_pix_fmt_desc_get(priv->common.input_frames->sw_format);
>  av_assert0(desc);
>  if (desc->flags & AV_PIX_FMT_FLAG_RGB)
> -components = (uint8_t[3]) { 'R', 'G', 'B' };
> +components = components_rgb;
>  else
> -components = (uint8_t[3]) {  1,   2,   3  };
> +components = components_yuv;
> 
>  // Frame header.
> 
> --
> 2.20.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] vaapi_encode_mjpeg: WA: fix bad component id bug

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Friday, June 07, 2019 1:47 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] vaapi_encode_mjpeg: WA: fix bad component 
> id bug
> 
> On 07/06/2019 21:28, U. Artie Eoff wrote:
> > When compile time optimizations are enabled and
> > compiling with GNU GCC 9.x, the pointer assignment
> > to the inline brace-enclosed list initialized
> > array does not work and "component" ends up pointing
> > to an empty array.  This is probably a bug in GCC
> > 9.x.
> >
> > This patch works around this issue by assigning
> > the constant arrays to local variables and then
> > pointing "component" to those as necessary.
> >
> > Fixes #7915
> >
> > Signed-off-by: U. Artie Eoff 
> > ---
> >  libavcodec/vaapi_encode_mjpeg.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> Huh.  No, the compiler is right - the compound literals only exist in the 
> tiny scope of the branches of the if.  I'm somewhat
> disappointed it isn't warning you about those variables having worked out 
> enough to eliminate them, though - it clearly knows that it's
> going to generate something undefined.
> 

Ah yes, that explanation makes sense.

> Good catch, in any case!
> 
> > diff --git a/libavcodec/vaapi_encode_mjpeg.c 
> > b/libavcodec/vaapi_encode_mjpeg.c
> > index 4dcdc3d16bb0..3e8cbb7c9bf9 100644
> > --- a/libavcodec/vaapi_encode_mjpeg.c
> > +++ b/libavcodec/vaapi_encode_mjpeg.c
> > @@ -227,6 +227,8 @@ static int 
> > vaapi_encode_mjpeg_init_picture_params(AVCodecContext *avctx,
> >  JPEGRawScanHeader *sh = >scan.header;
> >  VAEncPictureParameterBufferJPEG *vpic = pic->codec_picture_params;
> >  const AVPixFmtDescriptor *desc;
> > +const uint8_t components_rgb[3] = { 'R', 'G', 'B' };
> > +const uint8_t components_123[3] = {  1,   2,   3  };
> 
> It would probably make more sense to call this components_yuv?
> 

Sure.  V2 coming up.

> >  const uint8_t *components;
> >  int t, i, quant_scale, len;
> >
> > @@ -235,9 +237,9 @@ static int 
> > vaapi_encode_mjpeg_init_picture_params(AVCodecContext *avctx,
> >  desc = av_pix_fmt_desc_get(priv->common.input_frames->sw_format);
> >  av_assert0(desc);
> >  if (desc->flags & AV_PIX_FMT_FLAG_RGB)
> > -components = (uint8_t[3]) { 'R', 'G', 'B' };
> > +components = components_rgb;
> >  else
> > -components = (uint8_t[3]) {  1,   2,   3  };
> > +components = components_123;
> >
> >  // Frame header.
> >
> >
> 
> Thanks,
> 
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] ffmpeg: Add option to force a specific decode format

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
> Eugen Hoyos
> Sent: Wednesday, May 01, 2019 2:59 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg: Add option to force a specific 
> decode format
> 
> 2019-04-30 19:48 GMT+02:00, Eoff, Ullysses A :
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> >> Carl Eugen Hoyos
> >> Sent: Tuesday, April 23, 2019 12:48 PM
> >> To: FFmpeg development discussions and patches 
> >> Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg: Add option to force a specific
> >> decode format
> >>
> >> 2018-11-11 15:54 GMT+01:00, Mark Thompson :
> >> > Fixes #7519.
> >>
> >> > +{ "decode_format",  OPT_VIDEO | OPT_STRING | HAS_ARG | OPT_EXPERT
> >> > |
> >> > +OPT_SPEC | OPT_INPUT,
> >> >  { .off = OFFSET(decode_formats) },
> >> > +"set output format used by decoder, fail if this format is not
> >> > available", "format" },
> >>
> >> Sorry if this was already asked:
> >> Why can't you use the input option "pix_fmt"?
> >
> > Are you saying that pix_fmt is already supported as in input option
> 
> I assume the reason that you sent the patch is that this is not
> the case.
> 
> > for decode or, instead, that this patch should enable pix_fmt to be
> > used as such instead of adding a new option name?
> 
> I believe this would make user's life easier, yes.
> 

I agree.  Mark, can you update your patch?

> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] ffmpeg: Add option to force a specific decode format

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
> Eugen Hoyos
> Sent: Tuesday, April 23, 2019 12:48 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] ffmpeg: Add option to force a specific 
> decode format
> 
> 2018-11-11 15:54 GMT+01:00, Mark Thompson :
> > Fixes #7519.
> 
> > +{ "decode_format",  OPT_VIDEO | OPT_STRING | HAS_ARG | OPT_EXPERT |
> > +OPT_SPEC | OPT_INPUT,
> >  { .off = OFFSET(decode_formats) },
> > +"set output format used by decoder, fail if this format is not
> > available", "format" },
> 
> Sorry if this was already asked:
> Why can't you use the input option "pix_fmt"?
> 

Are you saying that pix_fmt is already supported as in input option
for decode or, instead, that this patch should enable pix_fmt to be
used as such instead of adding a new option name?

> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] ffmpeg: Add option to force a specific decode format

[Eoff, Ullysses A]

*bump*

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Wednesday, February 20, 2019 1:52 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH v2] ffmpeg: Add option to force a specific 
> decode format
> 
> On 18/02/2019 05:05, Fu, Linjie wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> >> Of Fu, Linjie
> >> Sent: Friday, November 16, 2018 16:37
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH v2] ffmpeg: Add option to force a
> >> specific decode format
> >>
> >>> -Original Message-
> >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> >> Behalf
> >>> Of Mark Thompson
> >>> Sent: Thursday, November 15, 2018 05:48
> >>> To: ffmpeg-devel@ffmpeg.org
> >>> Subject: Re: [FFmpeg-devel] [PATCH v2] ffmpeg: Add option to force a
> >>> specific decode format
> >>>
> >>> On 14/11/18 01:35, Fu, Linjie wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> >>> Behalf
> > Of Mark Thompson
> > Sent: Wednesday, November 14, 2018 09:11
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2] ffmpeg: Add option to force a
> > specific decode format
> >
> > On 14/11/18 00:50, Fu, Linjie wrote:
> >>> -Original Message-
> >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> >>> Of Mark Thompson
> >>> Sent: Wednesday, November 14, 2018 07:44
> >>> To: ffmpeg-devel@ffmpeg.org
> >>> Subject: [FFmpeg-devel] [PATCH v2] ffmpeg: Add option to force a
> > specific
> >>> decode format
> >>>
> >>> Fixes #7519.
> >>> ---
> >>>  doc/ffmpeg.texi  | 13 
> >>>  fftools/ffmpeg.c | 10 ++
> >>>  fftools/ffmpeg.h |  4 
> >>>  fftools/ffmpeg_opt.c | 47
> >>> 
> >>>  4 files changed, 74 insertions(+)
> >>>
> >>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> >>> index 3717f22d42..d127bc0f0d 100644
> >>> --- a/doc/ffmpeg.texi
> >>> +++ b/doc/ffmpeg.texi
> >>> @@ -920,6 +920,19 @@ would be more efficient.
> >>>  When doing stream copy, copy also non-key frames found at the
> >>>  beginning.
> >>>
> >>> +@item -decode_format[:@var{stream_specifier}]
> >>> @var{pixfmt}[,@var{pixfmt}...] (@emph{input,per-stream})
> >>> +Set the possible output formats to be used by the decoder for this
> > stream.
> >>> +If the decoder does not natively support any format in the given list
> >>> for
> >>> +the input stream then decoding will fail rather than continuing with 
> >>> a
> >>> +different format.
> >>> +
> >>> +In general this should not be set - the decoder will select an output
> >>> +format based on the input stream parameters and available
> >>> components,
> >>> and
> >>> +that will be automatically converted to whatever the output
> >> requires.
> >>> It
> >>> +may be useful to force a hardware decoder supporting output in
> > multiple
> >>> +different memory types to pick a desired one, or to ensure that a
> > hardware
> >>> +decoder is used when software fallback is also available.
> >>> +
> >>>  @item -init_hw_device
> >>> @var{type}[=@var{name}][:@var{device}[,@var{key=value}...]]
> >>>  Initialise a new hardware device of type @var{type} called
> >>> @var{name},
> >>> using the
> >>>  given device parameters.
> >>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> >>> index 38c21e944a..c651c8d3a8 100644
> >>> --- a/fftools/ffmpeg.c
> >>> +++ b/fftools/ffmpeg.c
> >>> @@ -598,6 +598,7 @@ static void ffmpeg_cleanup(int ret)
> >>>  avsubtitle_free(>prev_sub.subtitle);
> >>>  av_frame_free(>sub2video.frame);
> >>>  av_freep(>filters);
> >>> +av_freep(>decode_formats);
> >>>  av_freep(>hwaccel_device);
> >>>  av_freep(>dts_buffer);
> >>>
> >>> @@ -2800,6 +2801,15 @@ static enum AVPixelFormat
> >>> get_format(AVCodecContext *s, const enum AVPixelFormat
> >>>  const AVCodecHWConfig  *config = NULL;
> >>>  int i;
> >>>
> >>> +if (ist->decode_formats) {
> >>> +for (i = 0; ist->decode_formats[i] != AV_PIX_FMT_NONE; 
> >>> i++)
> >> {
> >>> +if (ist->decode_formats[i] == *p)
> >>> +break;
> >>> +}
> >>> +if (ist->decode_formats[i] != *p)
> >>> +continue;
> >>> +}
> >>> +
> >>>  if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL))
> >>>  break;
> >>>
> >>> diff --git 

Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Sunday, February 10, 2019 11:51 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC 
> modes
> 
> On 05/02/2019 16:51, Eoff, Ullysses A wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> >> Mark Thompson
> >> Sent: Monday, February 04, 2019 1:26 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC 
> >> modes
> >>
> >> On 28/01/2019 04:23, Eoff, Ullysses A wrote:
> >>>> -Original Message-
> >>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> >>>> Mark Thompson
> >>>> Sent: Sunday, January 27, 2019 3:47 PM
> >>>> To: ffmpeg-devel@ffmpeg.org
> >>>> Subject: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC 
> >>>> modes
> >>>>
> >>>> Allow setting the mode explicitly, and try to make a sensible choice
> >>>> given the available parameters if not.
> >>>> ---
> >>>>  doc/encoders.texi |  24 +++
> >>>>  libavcodec/vaapi_encode.c | 370 +++---
> >>>>  libavcodec/vaapi_encode.h |  65 +++
> >>>>  3 files changed, 351 insertions(+), 108 deletions(-)
> >>>>
> >>>> ...
> >>>>  if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> >>>>  av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
> >>>> -   "supported rate control modes: assuming 
> >>>> constant-quality.\n");
> >>>> -ctx->va_rc_mode = VA_RC_CQP;
> >>>> -return 0;
> >>>> ...
> >>>
> >>> With this patch series, mjpeg_vaapi encoder breaks with iHD driver:
> >>>
> >>> LIBVA_DRIVER_NAME=iHD ffmpeg -hwaccel vaapi \
> >>>   -vaapi_device /dev/dri/renderD128 -v debug \
> >>>   -f rawvideo -pix_fmt yuv420p -s:v 1920x1080 \
> >>>   -i input.yuv -vf 'format=nv12,hwupload' -c:v mjpeg_vaapi \
> >>>   -global_quality 100 -vframes 10 -y output.mjpg
> >>>
> >>> 
> >>> [AVHWDeviceContext @ 0x193c580] Opened VA display via DRM device 
> >>> /dev/dri/renderD128.
> >>> [AVHWDeviceContext @ 0x193c580] libva: VA-API version 1.4.0
> >>> [AVHWDeviceContext @ 0x193c580] libva: va_getDriverName() returns 0
> >>> [AVHWDeviceContext @ 0x193c580] libva: User requested driver 'iHD'
> >>> [AVHWDeviceContext @ 0x193c580] libva: Trying to open
> /home/uaeoff/Work/workspace/media/install/lib/dri/iHD_drv_video.so
> >>> [AVHWDeviceContext @ 0x193c580] libva: Found init function 
> >>> __vaDriverInit_1_4
> >>> [AVHWDeviceContext @ 0x193c580] libva: va_openDriver() returns 0
> >>> [AVHWDeviceContext @ 0x193c580] Initialised VAAPI connection: version 1.4
> >>> 
> >>> [mjpeg_vaapi @ 0x19847c0] Input surface format is nv12.
> >>> [mjpeg_vaapi @ 0x19847c0] Using VAAPI profile VAProfileJPEGBaseline (12).
> >>> [mjpeg_vaapi @ 0x19847c0] Using VAAPI entrypoint VAEntrypointEncPicture 
> >>> (7).
> >>> [mjpeg_vaapi @ 0x19847c0] Using VAAPI render target format YUV420 (0x1).
> >>> [mjpeg_vaapi @ 0x19847c0] Driver does not report any supported rate 
> >>> control modes: assuming CQP only.
> >>> [mjpeg_vaapi @ 0x19847c0] RC mode: CQP.
> >>> [mjpeg_vaapi @ 0x19847c0] RC quality: 100.
> >>> [mjpeg_vaapi @ 0x19847c0] RC framerate (CFR mode): 25/1 (25.00 fps).
> >>> [mjpeg_vaapi @ 0x19847c0] Using intra frames only.
> >>> [mjpeg_vaapi @ 0x19847c0] All wanted packed headers available (wanted 
> >>> 0x10, found 0x10).
> >>> [mjpeg_vaapi @ 0x19847c0] Failed to create encode pipeline configuration: 
> >>> 10 (attribute not supported).
> >>> Error initializing output stream 0:0 -- Error while opening encoder for 
> >>> output stream #0:0 - maybe incorrect parameters such as
> >> bit_rate, rate, width or height
> >>> [AVIOContext @ 0x1987000] Statistics: 0 seeks, 0 writeouts
> >>> [AVIOContext @ 0x19802c0] Statistics: 3110400 bytes read, 0 seeks
> >>> Conversion failed!
> >>>
> >>> ... it works fine on i965 driver.
> >>
> >> Right, the specific workaround to not set any options on drivers which 
> >> report no supported RC modes (highlighted above) needs to
> be
> >> carried forward to this.  Added.
> >>
> >> Thank you for testing!
> >>
> >
> > Is there a v3 I can test?  Thanks.
> 
> New version sent.  It now doesn't bail out from that function early because 
> it does want to do some other setup there; instead it just
> avoids setting that particular attribute at the end if the driver has 
> declared that it doesn't support it.
> 

[UAE] Yep, v3 works now.  Thanks. 

> Thanks,
> 
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Server upgrades

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Michael Niedermayer
> Sent: Wednesday, February 06, 2019 2:47 AM
> To: FFmpeg development discussions and patches 
> Cc: Reimar Döffinger 
> Subject: Re: [FFmpeg-devel] Server upgrades
> 
> On Tue, Feb 05, 2019 at 05:03:02PM +, Eoff, Ullysses A wrote:
> >
> > Was patchwork.ffmpeg.org included in this upgrade?
> 
> yes
> 
> > I'm getting an ssl error
> > with pwclient today.  This is the first time I've tried using pwclient 
> > since this
> > upgrade, so not sure if it's related.
> >
> > ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed 
> > (_ssl.c:726)
> 
> There is also a new lets encrypt certificate, these expire frequently
> The problem probably is that the server didnt sent the full chain of
> certificates
> ive manually made a certificate that works now but reimars script needs
> an update so it cats all the certs of the chain together. (ccing reimar
> for this) or maybe someone knows a cleaner way to make nginx use more than
> 1 as apache supports.
> 
> ive also fixed some other issue so our our https://www.ssllabs.com/ssltest
> score is now A (from previously B) for patchwork
> 
> thx
> 

Thanks.  It is working on my end now.

> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Into a blind darkness they enter who follow after the Ignorance,
> they as if into a greater darkness enter who devote themselves
> to the Knowledge alone. -- Isha Upanishad
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Eoff, Ullysses A
> Sent: Tuesday, February 05, 2019 8:51 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC 
> modes
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> > Mark Thompson
> > Sent: Monday, February 04, 2019 1:26 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC 
> > modes
> >
> > On 28/01/2019 04:23, Eoff, Ullysses A wrote:
> > >> -Original Message-
> > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> > >> Mark Thompson
> > >> Sent: Sunday, January 27, 2019 3:47 PM
> > >> To: ffmpeg-devel@ffmpeg.org
> > >> Subject: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC 
> > >> modes
> > >>
> > >> Allow setting the mode explicitly, and try to make a sensible choice
> > >> given the available parameters if not.
> > >> ---
> > >>  doc/encoders.texi |  24 +++
> > >>  libavcodec/vaapi_encode.c | 370 +++---
> > >>  libavcodec/vaapi_encode.h |  65 +++
> > >>  3 files changed, 351 insertions(+), 108 deletions(-)
> > >>
> > >> ...
> > >>  if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> > >>  av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
> > >> -   "supported rate control modes: assuming 
> > >> constant-quality.\n");
> > >> -ctx->va_rc_mode = VA_RC_CQP;
> > >> -return 0;
> > >> ...
> > >
> > > With this patch series, mjpeg_vaapi encoder breaks with iHD driver:
> > >
> > > LIBVA_DRIVER_NAME=iHD ffmpeg -hwaccel vaapi \
> > >   -vaapi_device /dev/dri/renderD128 -v debug \
> > >   -f rawvideo -pix_fmt yuv420p -s:v 1920x1080 \
> > >   -i input.yuv -vf 'format=nv12,hwupload' -c:v mjpeg_vaapi \
> > >   -global_quality 100 -vframes 10 -y output.mjpg
> > >
> > > 
> > > [AVHWDeviceContext @ 0x193c580] Opened VA display via DRM device 
> > > /dev/dri/renderD128.
> > > [AVHWDeviceContext @ 0x193c580] libva: VA-API version 1.4.0
> > > [AVHWDeviceContext @ 0x193c580] libva: va_getDriverName() returns 0
> > > [AVHWDeviceContext @ 0x193c580] libva: User requested driver 'iHD'
> > > [AVHWDeviceContext @ 0x193c580] libva: Trying to open 
> > > /home/uaeoff/Work/workspace/media/install/lib/dri/iHD_drv_video.so
> > > [AVHWDeviceContext @ 0x193c580] libva: Found init function 
> > > __vaDriverInit_1_4
> > > [AVHWDeviceContext @ 0x193c580] libva: va_openDriver() returns 0
> > > [AVHWDeviceContext @ 0x193c580] Initialised VAAPI connection: version 1.4
> > > 
> > > [mjpeg_vaapi @ 0x19847c0] Input surface format is nv12.
> > > [mjpeg_vaapi @ 0x19847c0] Using VAAPI profile VAProfileJPEGBaseline (12).
> > > [mjpeg_vaapi @ 0x19847c0] Using VAAPI entrypoint VAEntrypointEncPicture 
> > > (7).
> > > [mjpeg_vaapi @ 0x19847c0] Using VAAPI render target format YUV420 (0x1).
> > > [mjpeg_vaapi @ 0x19847c0] Driver does not report any supported rate 
> > > control modes: assuming CQP only.
> > > [mjpeg_vaapi @ 0x19847c0] RC mode: CQP.
> > > [mjpeg_vaapi @ 0x19847c0] RC quality: 100.
> > > [mjpeg_vaapi @ 0x19847c0] RC framerate (CFR mode): 25/1 (25.00 fps).
> > > [mjpeg_vaapi @ 0x19847c0] Using intra frames only.
> > > [mjpeg_vaapi @ 0x19847c0] All wanted packed headers available (wanted 
> > > 0x10, found 0x10).
> > > [mjpeg_vaapi @ 0x19847c0] Failed to create encode pipeline configuration: 
> > > 10 (attribute not supported).
> > > Error initializing output stream 0:0 -- Error while opening encoder for 
> > > output stream #0:0 - maybe incorrect parameters such as
> > bit_rate, rate, width or height
> > > [AVIOContext @ 0x1987000] Statistics: 0 seeks, 0 writeouts
> > > [AVIOContext @ 0x19802c0] Statistics: 3110400 bytes read, 0 seeks
> > > Conversion failed!
> > >
> > > ... it works fine on i965 driver.
> >
> > Right, the specific workaround to not set any options on drivers which 
> > report no supported RC modes (highlighted above) needs to
> be
> > carried forward to this.  Added.
&

Re: [FFmpeg-devel] Server upgrades

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
> Eugen Hoyos
> Sent: Tuesday, February 05, 2019 4:57 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] Server upgrades
> 
> 2019-02-05 18:03 GMT+01:00, Eoff, Ullysses A :
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> >> Michael Niedermayer
> >> Sent: Friday, February 01, 2019 4:53 AM
> >> To: FFmpeg development discussions and patches 
> >> Subject: [FFmpeg-devel] Server upgrades
> >>
> >> Hi all
> >>
> >> The OS and related things on the host on which our servers live
> >> as VMs is being upgraded as it soon would reach end of support otherwise.
> >> The VMs may get similarly upgrades afterwards so there may be slight
> >> outages today. Work is being done by Raz.
> >>
> >> Thanks to Raz for doing this needed work btw
> >>
> >
> > Was patchwork.ffmpeg.org included in this upgrade?  I'm getting
> > an ssl error with pwclient today.  This is the first time I've tried
> > using pwclient since this upgrade, so not sure if it's related.
> >
> > ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate
> > verify failed (_ssl.c:726)
> 
> Works fine here now, probably didn't test since the server update.
> 
> Carl Eugen
> 

Ok. Thanks for checking.  Still not working here for me.  But I'm able
to work around it with "PYTHONHTTPSVERIFY=0 pwclient list" for now.

U. Artie
___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Server upgrades

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Michael Niedermayer
> Sent: Friday, February 01, 2019 4:53 AM
> To: FFmpeg development discussions and patches 
> Subject: [FFmpeg-devel] Server upgrades
> 
> Hi all
> 
> The OS and related things on the host on which our servers live
> as VMs is being upgraded as it soon would reach end of support otherwise.
> The VMs may get similarly upgrades afterwards so there may be slight
> outages today. Work is being done by Raz.
> 
> Thanks to Raz for doing this needed work btw
> 

Was patchwork.ffmpeg.org included in this upgrade?  I'm getting an ssl error
with pwclient today.  This is the first time I've tried using pwclient since 
this
upgrade, so not sure if it's related.

ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed 
(_ssl.c:726)

Thanks,
U. Artie

> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Monday, February 04, 2019 1:26 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC 
> modes
> 
> On 28/01/2019 04:23, Eoff, Ullysses A wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> >> Mark Thompson
> >> Sent: Sunday, January 27, 2019 3:47 PM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC 
> >> modes
> >>
> >> Allow setting the mode explicitly, and try to make a sensible choice
> >> given the available parameters if not.
> >> ---
> >>  doc/encoders.texi |  24 +++
> >>  libavcodec/vaapi_encode.c | 370 +++---
> >>  libavcodec/vaapi_encode.h |  65 +++
> >>  3 files changed, 351 insertions(+), 108 deletions(-)
> >>
> >> ...
> >>  if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> >>  av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
> >> -   "supported rate control modes: assuming 
> >> constant-quality.\n");
> >> -ctx->va_rc_mode = VA_RC_CQP;
> >> -return 0;
> >> ...
> >
> > With this patch series, mjpeg_vaapi encoder breaks with iHD driver:
> >
> > LIBVA_DRIVER_NAME=iHD ffmpeg -hwaccel vaapi \
> >   -vaapi_device /dev/dri/renderD128 -v debug \
> >   -f rawvideo -pix_fmt yuv420p -s:v 1920x1080 \
> >   -i input.yuv -vf 'format=nv12,hwupload' -c:v mjpeg_vaapi \
> >   -global_quality 100 -vframes 10 -y output.mjpg
> >
> > 
> > [AVHWDeviceContext @ 0x193c580] Opened VA display via DRM device 
> > /dev/dri/renderD128.
> > [AVHWDeviceContext @ 0x193c580] libva: VA-API version 1.4.0
> > [AVHWDeviceContext @ 0x193c580] libva: va_getDriverName() returns 0
> > [AVHWDeviceContext @ 0x193c580] libva: User requested driver 'iHD'
> > [AVHWDeviceContext @ 0x193c580] libva: Trying to open 
> > /home/uaeoff/Work/workspace/media/install/lib/dri/iHD_drv_video.so
> > [AVHWDeviceContext @ 0x193c580] libva: Found init function 
> > __vaDriverInit_1_4
> > [AVHWDeviceContext @ 0x193c580] libva: va_openDriver() returns 0
> > [AVHWDeviceContext @ 0x193c580] Initialised VAAPI connection: version 1.4
> > 
> > [mjpeg_vaapi @ 0x19847c0] Input surface format is nv12.
> > [mjpeg_vaapi @ 0x19847c0] Using VAAPI profile VAProfileJPEGBaseline (12).
> > [mjpeg_vaapi @ 0x19847c0] Using VAAPI entrypoint VAEntrypointEncPicture (7).
> > [mjpeg_vaapi @ 0x19847c0] Using VAAPI render target format YUV420 (0x1).
> > [mjpeg_vaapi @ 0x19847c0] Driver does not report any supported rate control 
> > modes: assuming CQP only.
> > [mjpeg_vaapi @ 0x19847c0] RC mode: CQP.
> > [mjpeg_vaapi @ 0x19847c0] RC quality: 100.
> > [mjpeg_vaapi @ 0x19847c0] RC framerate (CFR mode): 25/1 (25.00 fps).
> > [mjpeg_vaapi @ 0x19847c0] Using intra frames only.
> > [mjpeg_vaapi @ 0x19847c0] All wanted packed headers available (wanted 0x10, 
> > found 0x10).
> > [mjpeg_vaapi @ 0x19847c0] Failed to create encode pipeline configuration: 
> > 10 (attribute not supported).
> > Error initializing output stream 0:0 -- Error while opening encoder for 
> > output stream #0:0 - maybe incorrect parameters such as
> bit_rate, rate, width or height
> > [AVIOContext @ 0x1987000] Statistics: 0 seeks, 0 writeouts
> > [AVIOContext @ 0x19802c0] Statistics: 3110400 bytes read, 0 seeks
> > Conversion failed!
> >
> > ... it works fine on i965 driver.
> 
> Right, the specific workaround to not set any options on drivers which report 
> no supported RC modes (highlighted above) needs to be
> carried forward to this.  Added.
> 
> Thank you for testing!
> 

Is there a v3 I can test?  Thanks.

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

Re: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Sunday, January 27, 2019 3:47 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 01/11] vaapi_encode: Support more RC modes
> 
> Allow setting the mode explicitly, and try to make a sensible choice
> given the available parameters if not.
> ---
>  doc/encoders.texi |  24 +++
>  libavcodec/vaapi_encode.c | 370 +++---
>  libavcodec/vaapi_encode.h |  65 +++
>  3 files changed, 351 insertions(+), 108 deletions(-)
> 
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index e86ae69cc5..29625ba07c 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -2824,6 +2824,30 @@ Set the B-frame reference depth.  When set to one (the 
> default), all B-frames
>  will refer only to P- or I-frames.  When set to greater values multiple 
> layers
>  of B-frames will be present, frames in each layer only referring to frames in
>  higher layers.
> +
> +@item rc_mode
> +Set the rate control mode to use.  A given driver may only support a subset 
> of
> +modes.
> +
> +Possible modes:
> +@table @option
> +@item auto
> +Choose the mode automatically based on driver support and the other options.
> +This is the default.
> +@item CQP
> +Constant-quality.
> +@item CBR
> +Constant-bitrate.
> +@item VBR
> +Variable-bitrate.
> +@item ICQ
> +Intelligent constant-quality.
> +@item QVBR
> +Quality-defined variable-bitrate.
> +@item AVBR
> +Average variable bitrate.
> +@end table
> +
>  @end table
> 
>  Each encoder also has its own specific options:
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index b4e9fadaee..d0e101b118 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1283,17 +1283,42 @@ fail:
>  return err;
>  }
> 
> +static const VAAPIEncodeRCMode vaapi_encode_rc_modes[] = {
> +//  Bitrate   Quality
> +// | Maxrate | HRD/VBV
> +{ 0 }, //  ||||
> +{ RC_MODE_CQP,  "CQP",  1, VA_RC_CQP,  0,   0,   1,   0 },
> +{ RC_MODE_CBR,  "CBR",  1, VA_RC_CBR,  1,   0,   0,   1 },
> +{ RC_MODE_VBR,  "VBR",  1, VA_RC_VBR,  1,   1,   0,   1 },
> +#if VA_CHECK_VERSION(1, 1, 0)
> +{ RC_MODE_ICQ,  "ICQ",  1, VA_RC_ICQ,  0,   0,   1,   0 },
> +#else
> +{ RC_MODE_ICQ,  "ICQ",  0 },
> +#endif
> +#if VA_CHECK_VERSION(1, 3, 0)
> +{ RC_MODE_QVBR, "QVBR", 1, VA_RC_QVBR, 1,   1,   1,   1 },
> +{ RC_MODE_AVBR, "AVBR", 0, VA_RC_AVBR, 1,   0,   0,   0 },
> +#else
> +{ RC_MODE_QVBR, "QVBR", 0 },
> +{ RC_MODE_AVBR, "AVBR", 0 },
> +#endif
> +};
> +
>  static av_cold int vaapi_encode_init_rate_control(AVCodecContext *avctx)
>  {
>  VAAPIEncodeContext *ctx = avctx->priv_data;
> +uint32_t supported_va_rc_modes;
> +const VAAPIEncodeRCMode *rc_mode;
>  int64_t rc_bits_per_second;
>  int rc_target_percentage;
>  int rc_window_size;
> +int rc_quality;
>  int64_t hrd_buffer_size;
>  int64_t hrd_initial_buffer_fullness;
>  int fr_num, fr_den;
>  VAConfigAttrib rc_attr = { VAConfigAttribRateControl };
>  VAStatus vas;
> +char supported_rc_modes_string[64];
> 
>  vas = vaGetConfigAttributes(ctx->hwctx->display,
>  ctx->va_profile, ctx->va_entrypoint,
> @@ -1303,119 +1328,215 @@ static av_cold int 
> vaapi_encode_init_rate_control(AVCodecContext *avctx)
> "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
>  return AVERROR_EXTERNAL;
>  }
> -
>  if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
>  av_log(avctx, AV_LOG_VERBOSE, "Driver does not report any "
> -   "supported rate control modes: assuming constant-quality.\n");
> -ctx->va_rc_mode = VA_RC_CQP;
> -return 0;
> -}
> -if (ctx->codec->flags & FLAG_CONSTANT_QUALITY_ONLY ||
> -avctx->flags & AV_CODEC_FLAG_QSCALE ||
> -avctx->bit_rate <= 0) {
> -if (rc_attr.value & VA_RC_CQP) {
> -av_log(avctx, AV_LOG_VERBOSE, "Using constant-quality mode.\n");
> -ctx->va_rc_mode = VA_RC_CQP;
> -if (avctx->bit_rate > 0 || avctx->rc_max_rate > 0) {
> -av_log(avctx, AV_LOG_WARNING, "Bitrate target parameters "
> -   "ignored in constant-quality mode.\n");
> +   "supported rate control modes: assuming CQP only.\n");
> +supported_va_rc_modes = VA_RC_CQP;
> +strcpy(supported_rc_modes_string, "unknown");
> +} else {
> +char *str = supported_rc_modes_string;
> +size_t len = sizeof(supported_rc_modes_string);
> +int i, first = 1, res;
> +
> +supported_va_rc_modes = rc_attr.value;
> +
> +first = 1;
> +for (i = 0; i < FF_ARRAY_ELEMS(vaapi_encode_rc_modes); i++) {
> +rc_mode = 

Re: [FFmpeg-devel] [PATCH] vaapi_encode_h265: Ensure that ref pics are always in the RPS

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Friday, January 25, 2019 12:05 PM
> To: FFmpeg development discussions and patches 
> Subject: [FFmpeg-devel] [PATCH] vaapi_encode_h265: Ensure that ref pics are 
> always in the RPS
> 
> When making a new P-frame when B-frames are present the previous P-frame
> is normally in the DPB because it will be referred to by subsequent
> B-frames.  However, this is not true if there are no B-frames, or in edge
> cases where a GOP ends with two P-frames.  Fix this by adding the direct
> ref pics to the RPS explicitly.
> 
> Fixes #7699.

This patch fixes #7699 for me.  Thanks! :)

> ---
>  libavcodec/vaapi_encode_h265.c | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index 1d40e06667..19e7104e9e 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -902,6 +902,7 @@ static int 
> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
> 
>  if (pic->type != PICTURE_TYPE_IDR) {
>  H265RawSTRefPicSet *rps;
> +const VAAPIEncodeH265Picture *strp;
>  int rps_poc[MAX_DPB_SIZE];
>  int rps_used[MAX_DPB_SIZE];
>  int i, j, poc, rps_pics;
> @@ -912,16 +913,24 @@ static int 
> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
>  memset(rps, 0, sizeof(*rps));
> 
>  rps_pics = 0;
> +for (i = 0; i < pic->nb_refs; i++) {
> +strp = pic->refs[i]->priv_data;
> +rps_poc[rps_pics]  = strp->pic_order_cnt;
> +rps_used[rps_pics] = 1;
> +++rps_pics;
> +}
>  for (i = 0; i < pic->nb_dpb_pics; i++) {
> -VAAPIEncodeH265Picture *strp;
>  if (pic->dpb[i] == pic)
>  continue;
> +for (j = 0; j < pic->nb_refs; j++) {
> +if (pic->dpb[i] == pic->refs[j])
> +break;
> +}
> +if (j < pic->nb_refs)
> +continue;
>  strp = pic->dpb[i]->priv_data;
>  rps_poc[rps_pics]  = strp->pic_order_cnt;
>  rps_used[rps_pics] = 0;
> -for (j = 0; j < pic->nb_refs; j++)
> -if (pic->dpb[i] == pic->refs[j])
> -rps_used[rps_pics] = 1;
>  ++rps_pics;
>  }
> 
> --
> 2.19.2
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/5] Refact qsv decoder parser and add new decoders

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Zhong Li
> Sent: Monday, January 21, 2019 4:42 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong 
> Subject: [FFmpeg-devel] [PATCH 0/5] Refact qsv decoder parser and add new 
> decoders
> 
> Replace current parser with MFXVideoDECODE_DecodeHeader(),
> and add MJPEG/VP9 decoders.
> 
> Zhong Li (5):
>   lavc/qsvdec: add function ff_qsv_map_picstruct()
>   lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()
>   lavc/qsvdec: remove orignal parser code since not needed now
>   lavc/qsvdec: Add mjpeg decoder support
>   lavc/qsvdec: Add VP9 decoder support
> 
>  Changelog |   2 +
>  configure |  12 +++--
>  libavcodec/Makefile   |   1 +
>  libavcodec/allcodecs.c|   2 +
>  libavcodec/qsv.c  |  23 +
>  libavcodec/qsv_internal.h |   2 +
>  libavcodec/qsvdec.c   | 119 
> +-
>  libavcodec/qsvdec.h   |   4 +-
>  libavcodec/qsvdec_other.c |  72 ++--
>  9 files changed, 140 insertions(+), 97 deletions(-)
> 
> --
> 2.7.4
> 

[UAE] This series breaks hevc 10 bit decoder:

$ ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD128 -v verbose \
  -c:v hevc_qsv -load_plugin hevc_hw -I test-10bit.h265 \
  -vf 'hwdownload,format=p010le' -pix_fmt p010le \
  -f rawvideo -vsync passthrough -vframes 5 -y test.yuv


[hevc_qsv @ 0x1f39740] Error initializing the MFX video decoder: unsupported 
(-3)
Error while decoding stream #0:0: Function not implemented
[hevc_qsv @ 0x1f39740] Error decoding stream header: expect more data at input 
(-10)
Error while decoding stream #0:0: Unknown error occurred
[hevc_qsv @ 0x1f39740] video_get_buffer: image parameters invalid
[hevc_qsv @ 0x1f39740] get_buffer() failed
Error while decoding stream #0:0: Invalid argument
[hevc_qsv @ 0x1f39740] Too many errors when draining, this is a bug. Stop 
draining and force EOF.
Error while decoding stream #0:0: Internal bug, should not have happened

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

Re: [FFmpeg-devel] [PATCH]lavc/qsvenc: Clip the bitrate, Intel limits it to 65535k

[Eoff, Ullysses A]

We should use mfxInfoMFX::BRCParamMultiplier to handle high bitrate.  See my 
new comment in #7663

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
> Eugen Hoyos
> Sent: Thursday, January 10, 2019 12:53 PM
> To: FFmpeg development discussions and patches 
> Subject: [FFmpeg-devel] [PATCH]lavc/qsvenc: Clip the bitrate, Intel limits it 
> to 65535k
> 
> Hi!
> 
> Attached untested patch tries to limit the effects of setting a high
> bitrate for qsv.
> Works around ticket #7663.
> 
> Please comment, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: Add option to force a specific decode format

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Sunday, November 11, 2018 6:55 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] ffmpeg: Add option to force a specific decode 
> format
> 
> Fixes #7519.
> ---
> I've had this lying around for a bit with intent to use it to support 
> non-hwaccel hardware decoders (in particular, v4l2m2m), but it
> actually fixes the force-hwaccel use-case too in a sensible way.
> 
> 
>  doc/ffmpeg.texi  | 12 
>  fftools/ffmpeg.c |  4 
>  fftools/ffmpeg.h |  4 
>  fftools/ffmpeg_opt.c | 15 +++
>  4 files changed, 35 insertions(+)
> 
> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> index 3717f22d42..9f9e693898 100644
> --- a/doc/ffmpeg.texi
> +++ b/doc/ffmpeg.texi
> @@ -920,6 +920,18 @@ would be more efficient.
>  When doing stream copy, copy also non-key frames found at the
>  beginning.
> 
> +@item -decode_format[:@var{stream_specifier}] @var{pixfmt} 
> (@emph{input,per-stream})
> +Set the output format to be used by the decoder for this stream.  If the
> +decoder does not natively support this format for the input stream then
> +decoding will fail rather than continuing with a different format.
> +
> +In general this should not be set - the decoder will select an output
> +format based on the input stream parameters and available components, and
> +that will be automatically converted to whatever the output requires.  It
> +may be useful to force a hardware decoder supporting output in multiple
> +different memory types to pick the desired one, or to ensure that a
> +hardware decoder is used when software fallback is also available.
> +
>  @item -init_hw_device 
> @var{type}[=@var{name}][:@var{device}[,@var{key=value}...]]
>  Initialise a new hardware device of type @var{type} called @var{name}, using 
> the
>  given device parameters.
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 38c21e944a..73bed55e4d 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2800,6 +2800,10 @@ static enum AVPixelFormat get_format(AVCodecContext 
> *s, const enum AVPixelFormat
>  const AVCodecHWConfig  *config = NULL;
>  int i;
> 
> +if (ist->decode_format != AV_PIX_FMT_NONE &&
> +ist->decode_format != *p)
> +continue;
> +
>  if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL))
>  break;
> 
> diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> index eb1eaf6363..88e0aa60ea 100644
> --- a/fftools/ffmpeg.h
> +++ b/fftools/ffmpeg.h
> @@ -125,6 +125,8 @@ typedef struct OptionsContext {
>  intnb_ts_scale;
>  SpecifierOpt *dump_attachment;
>  intnb_dump_attachment;
> +SpecifierOpt *decode_formats;
> +intnb_decode_formats;
>  SpecifierOpt *hwaccels;
>  intnb_hwaccels;
>  SpecifierOpt *hwaccel_devices;
> @@ -334,6 +336,8 @@ typedef struct InputStream {
>  int top_field_first;
>  int guess_layout_max;
> 
> +enum AVPixelFormat decode_format;
> +
>  int autorotate;
> 
>  int fix_sub_duration;
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index d4851a2cd8..0e3e8b99fe 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -701,6 +701,7 @@ static void add_input_streams(OptionsContext *o, 
> AVFormatContext *ic)
>  AVStream *st = ic->streams[i];
>  AVCodecParameters *par = st->codecpar;
>  InputStream *ist = av_mallocz(sizeof(*ist));
> +char *decode_format = NULL;
>  char *framerate = NULL, *hwaccel_device = NULL;
>  const char *hwaccel = NULL;
>  char *hwaccel_output_format = NULL;
> @@ -797,6 +798,17 @@ static void add_input_streams(OptionsContext *o, 
> AVFormatContext *ic)
>  ist->top_field_first = -1;
>  MATCH_PER_STREAM_OPT(top_field_first, i, ist->top_field_first, 
> ic, st);
> 
> +MATCH_PER_STREAM_OPT(decode_formats, str, decode_format, ic, st);
> +if (decode_format) {
> +ist->decode_format = av_get_pix_fmt(decode_format);
> +if (ist->decode_format == AV_PIX_FMT_NONE) {
> +av_log(NULL, AV_LOG_FATAL, "Unrecognised decode format: 
> %s",
> +   decode_format);
> +}
> +} else {
> +ist->decode_format = AV_PIX_FMT_NONE;
> +}
> +
>  MATCH_PER_STREAM_OPT(hwaccels, str, hwaccel, ic, st);
>  if (hwaccel) {
>  // The NVDEC hwaccels use a CUDA device, so remap the name 
> here.
> @@ -3583,6 +3595,9 @@ const OptionDef options[] = {
>  "audio bitrate (please use -b:a)", "bitrate" },
>  { "b",OPT_VIDEO | HAS_ARG | OPT_PERFILE | OPT_OUTPUT,
> { .func_arg = opt_bitrate },
>  "video bitrate (please use -b:v)", "bitrate" },
> +{ "decode_format",  OPT_VIDEO | 

Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG decoding uninitialized huffman table

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Eoff, Ullysses A
> Sent: Thursday, November 08, 2018 9:27 PM
> To: FFmpeg development discussions and patches 
> Cc: Zhao, Jun ; Lin, Decai 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG decoding 
> uninitialized huffman table
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> > Eoff, Ullysses A
> > Sent: Tuesday, October 30, 2018 11:42 AM
> > To: FFmpeg development discussions and patches 
> > Cc: Zhao, Jun ; Lin, Decai 
> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG 
> > decoding uninitialized huffman table
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> > > myp...@gmail.com
> > > Sent: Monday, October 29, 2018 10:52 PM
> > > To: FFmpeg development discussions and patches 
> > > Cc: Zhao, Jun ; Lin, Decai 
> > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG 
> > > decoding uninitialized huffman table
> > >
> > > On Tue, Oct 30, 2018 at 11:41 AM Eoff, Ullysses A
> > >  wrote:
> > > >
> > > > > -Original Message-
> > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf 
> > > > > Of myp...@gmail.com
> > > > > Sent: Monday, October 29, 2018 8:10 PM
> > > > > To: FFmpeg development discussions and patches 
> > > > > 
> > > > > Cc: Zhao, Jun ; Lin, Decai 
> > > > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG 
> > > > > decoding uninitialized huffman table
> > > > >
> > > > > On Tue, Oct 30, 2018 at 10:41 AM Li, Zhong  wrote:
> > > > > >
> > > > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On 
> > > > > > > Behalf
> > > > > > > Of myp...@gmail.com
> > > > > > > Sent: Tuesday, October 30, 2018 9:02 AM
> > > > > > > To: FFmpeg development discussions and patches
> > > > > > > 
> > > > > > > Cc: Zhao, Jun ; Lin, Decai 
> > > > > > > 
> > > > > > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API 
> > > > > > > MJPEG
> > > > > > > decoding uninitialized huffman table
> > > > > > >
> > > > > > > On Mon, Oct 29, 2018 at 6:39 PM Li, Zhong  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > > > > > > > Behalf Of Jun Zhao
> > > > > > > > > Sent: Monday, October 29, 2018 6:26 PM
> > > > > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > > > > Cc: Zhao, Jun ; Lin, Decai 
> > > > > > > > > 
> > > > > > > > > Subject: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API 
> > > > > > > > > MJPEG
> > > > > > > > > decoding uninitialized huffman table
> > > > > > > > >
> > > > > > > > > From: Jun Zhao 
> > > > > > > > >
> > > > > > > > > Now VA-API HWAccel MJPEG decoding uninitialized huffman 
> > > > > > > > > table, it's
> > > > > > > > > will lead to the decoding error like"Failed to sync surface 
> > > > > > > > > 0x5: 23
> > > > > > > > > (internal decoding error)." in iHD open source driver.
> > > > > > > > >
> > > > > > > > > Signed-off-by: dlin2 
> > > > > > > > > Signed-off-by: Jun Zhao 
> > > > > > > > > ---
> > > > > > > > >  libavcodec/mjpegdec.c |   19 +++
> > > > > > > > >  1 files changed, 19 insertions(+), 0 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c 
> > > > > > > > > index
> > > > > > > > > b0cb3ff..89effb6 100644
> > > > > > > > &

Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG decoding uninitialized huffman table

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Eoff, Ullysses A
> Sent: Tuesday, October 30, 2018 11:42 AM
> To: FFmpeg development discussions and patches 
> Cc: Zhao, Jun ; Lin, Decai 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG decoding 
> uninitialized huffman table
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> > myp...@gmail.com
> > Sent: Monday, October 29, 2018 10:52 PM
> > To: FFmpeg development discussions and patches 
> > Cc: Zhao, Jun ; Lin, Decai 
> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG 
> > decoding uninitialized huffman table
> >
> > On Tue, Oct 30, 2018 at 11:41 AM Eoff, Ullysses A
> >  wrote:
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf 
> > > > Of myp...@gmail.com
> > > > Sent: Monday, October 29, 2018 8:10 PM
> > > > To: FFmpeg development discussions and patches 
> > > > Cc: Zhao, Jun ; Lin, Decai 
> > > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG 
> > > > decoding uninitialized huffman table
> > > >
> > > > On Tue, Oct 30, 2018 at 10:41 AM Li, Zhong  wrote:
> > > > >
> > > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On 
> > > > > > Behalf
> > > > > > Of myp...@gmail.com
> > > > > > Sent: Tuesday, October 30, 2018 9:02 AM
> > > > > > To: FFmpeg development discussions and patches
> > > > > > 
> > > > > > Cc: Zhao, Jun ; Lin, Decai 
> > > > > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG
> > > > > > decoding uninitialized huffman table
> > > > > >
> > > > > > On Mon, Oct 29, 2018 at 6:39 PM Li, Zhong  
> > > > > > wrote:
> > > > > > >
> > > > > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > > > > > > Behalf Of Jun Zhao
> > > > > > > > Sent: Monday, October 29, 2018 6:26 PM
> > > > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > > > Cc: Zhao, Jun ; Lin, Decai 
> > > > > > > > 
> > > > > > > > Subject: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG
> > > > > > > > decoding uninitialized huffman table
> > > > > > > >
> > > > > > > > From: Jun Zhao 
> > > > > > > >
> > > > > > > > Now VA-API HWAccel MJPEG decoding uninitialized huffman table, 
> > > > > > > > it's
> > > > > > > > will lead to the decoding error like"Failed to sync surface 
> > > > > > > > 0x5: 23
> > > > > > > > (internal decoding error)." in iHD open source driver.
> > > > > > > >
> > > > > > > > Signed-off-by: dlin2 
> > > > > > > > Signed-off-by: Jun Zhao 
> > > > > > > > ---
> > > > > > > >  libavcodec/mjpegdec.c |   19 +++
> > > > > > > >  1 files changed, 19 insertions(+), 0 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c index
> > > > > > > > b0cb3ff..89effb6 100644
> > > > > > > > --- a/libavcodec/mjpegdec.c
> > > > > > > > +++ b/libavcodec/mjpegdec.c
> > > > > > > > @@ -75,6 +75,25 @@ static int build_vlc(VLC *vlc, const uint8_t
> > > > > > > > *bits_table, static int 
> > > > > > > > build_basic_mjpeg_vlc(MJpegDecodeContext *s)
> > > > > > {
> > > > > > > >  int ret;
> > > > > > > > +int i;
> > > > > > > > +
> > > > > > > > +/* initialize default huffman tables */
> > > > > > > > +for (i = 0; i < 16; i++)
> > > > > > > > +s->raw_huffman_lengths[0][0][i] =
> > > > > > > > avpriv_mjpeg_bits_dc_luminance[i + 1];
> > > > > > > > +for (i = 0; i < 12; i++)
> 

Re: [FFmpeg-devel] [PATCH v2] fftools/ffmpeg: add an option to forbid the fallback to software path when hardware init fails

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Linjie Fu
> Sent: Thursday, November 08, 2018 7:14 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [FFmpeg-devel] [PATCH v2] fftools/ffmpeg: add an option to forbid 
> the fallback to software path when hardware init fails
> 
> Currently ff_get_format will go through all usable choices if the chosen
> format was not supported. It will fallback to software path if the hardware
> init fails.
> 
> Provided an option "-fallback_forbid 1" in user-code to detect frame->format 
> and
> hwaccel_get_buffer in get_buffer. If hardware init fails, returns an error.
> 

I'm not sure I like this option name ("-fallback_forbid").  How about 
"-disable_fallback",
"-hwaccel_or_die", "-require_hwaccel" or "-no_sw_fallback"?  I like the last 
two the most.
Or maybe someone has a better suggestion?

> Signed-off-by: Linjie Fu 
> ---
> 
> [v2] detect hardware init failures in get_buffer and modify in user-code
> 
>  fftools/ffmpeg.c | 2 ++
>  fftools/ffmpeg.h | 1 +
>  fftools/ffmpeg_opt.c | 3 +++
>  3 files changed, 6 insertions(+)
> 
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index da4259a9a8..45694fef57 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2890,6 +2890,8 @@ static int get_buffer(AVCodecContext *s, AVFrame 
> *frame, int flags)
> 
>  if (ist->hwaccel_get_buffer && frame->format == ist->hwaccel_pix_fmt)
>  return ist->hwaccel_get_buffer(s, frame, flags);
> +else if (ist->fallback_forbid)
> +return AVERROR(EINVAL);
> 
>  return avcodec_default_get_buffer2(s, frame, flags);
>  }
> diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> index eb1eaf6363..67ddaeaaee 100644
> --- a/fftools/ffmpeg.h
> +++ b/fftools/ffmpeg.h
> @@ -365,6 +365,7 @@ typedef struct InputStream {
>  enum AVHWDeviceType hwaccel_device_type;
>  char  *hwaccel_device;
>  enum AVPixelFormat hwaccel_output_format;
> +int fallback_forbid;
> 
>  /* hwaccel context */
>  void  *hwaccel_ctx;
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index d4851a2cd8..314e25565c 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -3600,6 +3600,9 @@ const OptionDef options[] = {
>  { "autorotate",   HAS_ARG | OPT_BOOL | OPT_SPEC |
>OPT_EXPERT | OPT_INPUT,
> { .off = OFFSET(autorotate) },
>  "automatically insert correct rotate filters" },
> +{ "fallback_forbid",  HAS_ARG | OPT_BOOL | OPT_SPEC |
> +  OPT_EXPERT | OPT_INPUT,
> { .off = OFFSET(fallback_forbid)},
> +  "forbid the fallback to default software path when hardware init 
> fails"},
> 
>  /* audio options */
>  { "aframes",OPT_AUDIO | HAS_ARG  | OPT_PERFILE | OPT_OUTPUT, 
>   { .func_arg = opt_audio_frames },
> --
> 2.17.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG decoding uninitialized huffman table

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> myp...@gmail.com
> Sent: Monday, October 29, 2018 10:52 PM
> To: FFmpeg development discussions and patches 
> Cc: Zhao, Jun ; Lin, Decai 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG decoding 
> uninitialized huffman table
> 
> On Tue, Oct 30, 2018 at 11:41 AM Eoff, Ullysses A
>  wrote:
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> > > myp...@gmail.com
> > > Sent: Monday, October 29, 2018 8:10 PM
> > > To: FFmpeg development discussions and patches 
> > > Cc: Zhao, Jun ; Lin, Decai 
> > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG 
> > > decoding uninitialized huffman table
> > >
> > > On Tue, Oct 30, 2018 at 10:41 AM Li, Zhong  wrote:
> > > >
> > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > > > > Of myp...@gmail.com
> > > > > Sent: Tuesday, October 30, 2018 9:02 AM
> > > > > To: FFmpeg development discussions and patches
> > > > > 
> > > > > Cc: Zhao, Jun ; Lin, Decai 
> > > > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG
> > > > > decoding uninitialized huffman table
> > > > >
> > > > > On Mon, Oct 29, 2018 at 6:39 PM Li, Zhong  wrote:
> > > > > >
> > > > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > > > > > Behalf Of Jun Zhao
> > > > > > > Sent: Monday, October 29, 2018 6:26 PM
> > > > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > > > Cc: Zhao, Jun ; Lin, Decai 
> > > > > > > 
> > > > > > > Subject: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG
> > > > > > > decoding uninitialized huffman table
> > > > > > >
> > > > > > > From: Jun Zhao 
> > > > > > >
> > > > > > > Now VA-API HWAccel MJPEG decoding uninitialized huffman table, 
> > > > > > > it's
> > > > > > > will lead to the decoding error like"Failed to sync surface 0x5: 
> > > > > > > 23
> > > > > > > (internal decoding error)." in iHD open source driver.
> > > > > > >
> > > > > > > Signed-off-by: dlin2 
> > > > > > > Signed-off-by: Jun Zhao 
> > > > > > > ---
> > > > > > >  libavcodec/mjpegdec.c |   19 +++
> > > > > > >  1 files changed, 19 insertions(+), 0 deletions(-)
> > > > > > >
> > > > > > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c index
> > > > > > > b0cb3ff..89effb6 100644
> > > > > > > --- a/libavcodec/mjpegdec.c
> > > > > > > +++ b/libavcodec/mjpegdec.c
> > > > > > > @@ -75,6 +75,25 @@ static int build_vlc(VLC *vlc, const uint8_t
> > > > > > > *bits_table, static int build_basic_mjpeg_vlc(MJpegDecodeContext 
> > > > > > > *s)
> > > > > {
> > > > > > >  int ret;
> > > > > > > +int i;
> > > > > > > +
> > > > > > > +/* initialize default huffman tables */
> > > > > > > +for (i = 0; i < 16; i++)
> > > > > > > +s->raw_huffman_lengths[0][0][i] =
> > > > > > > avpriv_mjpeg_bits_dc_luminance[i + 1];
> > > > > > > +for (i = 0; i < 12; i++)
> > > > > > > +s->raw_huffman_values[0][0][i] = avpriv_mjpeg_val_dc[i];
> > > > > > > +for (i = 0; i < 16; i++)
> > > > > > > +s->raw_huffman_lengths[0][1][i] =
> > > > > > > avpriv_mjpeg_bits_dc_chrominance[i + 1];
> > > > > > > +for (i = 0; i < 12; i++)
> > > > > > > +s->raw_huffman_values[0][1][i] = avpriv_mjpeg_val_dc[i];
> > > > > > > +for (i = 0; i < 16; i++)
> > > > > > > +s->raw_huffman_lengths[1][0][i] =
> > > > > > > avpriv_mjpeg_bits_ac_luminance[i + 1];
> > > > > > > +for (i = 0; i < 162; i++)
> > > > > &g

Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG decoding uninitialized huffman table

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> myp...@gmail.com
> Sent: Monday, October 29, 2018 8:10 PM
> To: FFmpeg development discussions and patches 
> Cc: Zhao, Jun ; Lin, Decai 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG decoding 
> uninitialized huffman table
> 
> On Tue, Oct 30, 2018 at 10:41 AM Li, Zhong  wrote:
> >
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > > Of myp...@gmail.com
> > > Sent: Tuesday, October 30, 2018 9:02 AM
> > > To: FFmpeg development discussions and patches
> > > 
> > > Cc: Zhao, Jun ; Lin, Decai 
> > > Subject: Re: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG
> > > decoding uninitialized huffman table
> > >
> > > On Mon, Oct 29, 2018 at 6:39 PM Li, Zhong  wrote:
> > > >
> > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > > > Behalf Of Jun Zhao
> > > > > Sent: Monday, October 29, 2018 6:26 PM
> > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > Cc: Zhao, Jun ; Lin, Decai 
> > > > > Subject: [FFmpeg-devel] [PATCH] lavc/mjpegdec: fix VA-API MJPEG
> > > > > decoding uninitialized huffman table
> > > > >
> > > > > From: Jun Zhao 
> > > > >
> > > > > Now VA-API HWAccel MJPEG decoding uninitialized huffman table, it's
> > > > > will lead to the decoding error like"Failed to sync surface 0x5: 23
> > > > > (internal decoding error)." in iHD open source driver.
> > > > >
> > > > > Signed-off-by: dlin2 
> > > > > Signed-off-by: Jun Zhao 
> > > > > ---
> > > > >  libavcodec/mjpegdec.c |   19 +++
> > > > >  1 files changed, 19 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c index
> > > > > b0cb3ff..89effb6 100644
> > > > > --- a/libavcodec/mjpegdec.c
> > > > > +++ b/libavcodec/mjpegdec.c
> > > > > @@ -75,6 +75,25 @@ static int build_vlc(VLC *vlc, const uint8_t
> > > > > *bits_table, static int build_basic_mjpeg_vlc(MJpegDecodeContext *s)
> > > {
> > > > >  int ret;
> > > > > +int i;
> > > > > +
> > > > > +/* initialize default huffman tables */
> > > > > +for (i = 0; i < 16; i++)
> > > > > +s->raw_huffman_lengths[0][0][i] =
> > > > > avpriv_mjpeg_bits_dc_luminance[i + 1];
> > > > > +for (i = 0; i < 12; i++)
> > > > > +s->raw_huffman_values[0][0][i] = avpriv_mjpeg_val_dc[i];
> > > > > +for (i = 0; i < 16; i++)
> > > > > +s->raw_huffman_lengths[0][1][i] =
> > > > > avpriv_mjpeg_bits_dc_chrominance[i + 1];
> > > > > +for (i = 0; i < 12; i++)
> > > > > +s->raw_huffman_values[0][1][i] = avpriv_mjpeg_val_dc[i];
> > > > > +for (i = 0; i < 16; i++)
> > > > > +s->raw_huffman_lengths[1][0][i] =
> > > > > avpriv_mjpeg_bits_ac_luminance[i + 1];
> > > > > +for (i = 0; i < 162; i++)
> > > > > +s->raw_huffman_values[1][0][i] =
> > > > > avpriv_mjpeg_val_ac_luminance[i];
> > > > > +for (i = 0; i < 16; i++)
> > > > > +s->raw_huffman_lengths[1][1][i] =
> > > > > avpriv_mjpeg_bits_ac_chrominance[i + 1];
> > > > > +for (i = 0; i < 162; i++)
> > > > > +s->raw_huffman_values[1][1][i] =
> > > > > + avpriv_mjpeg_val_ac_chrominance[i];
> > > > >
> > > > >  if ((ret = build_vlc(>vlcs[0][0],
> > > avpriv_mjpeg_bits_dc_luminance,
> > > > >   avpriv_mjpeg_val_dc, 12, 0, 0)) < 0)
> > > > > --
> > > > > 1.7.1
> > > >
> > > > Should this be fixed in iHD driver instead of ffmpeg?
> > > No, I don't think driver is a good place to initialize the huffman table.
> >
> > For the default Huffman table, thus should be initialized by driver itself.
> > For non-default case, thus should be passed from ffmpeg.
> > So, what is the case you want to fix? Both (if so, no need to mention iHD 
> > driver)?
> Both, now HWAccel MJPEG always setting the huffman table and
> can't distinguish the HWaccel JPEG whether default Huffman table.

If your VA-API HWAccel MJPEG decoding case(s) work with i965 driver
and not iHD then I would assume iHD needs fixing.

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

Re: [FFmpeg-devel] [PATCH] libavfilter/vaapi: enable vaapi rotation feature via call Intel iHD driver

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Eoff, Ullysses A
> Sent: Tuesday, October 23, 2018 1:50 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] libavfilter/vaapi: enable vaapi rotation 
> feature via call Intel iHD driver
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> > Michael Niedermayer
> > Sent: Tuesday, October 23, 2018 10:06 AM
> > To: FFmpeg development discussions and patches 
> > Subject: Re: [FFmpeg-devel] [PATCH] libavfilter/vaapi: enable vaapi 
> > rotation feature via call Intel iHD driver
> >
> > On Tue, Oct 23, 2018 at 03:52:40PM +0800, Zachary Zhou wrote:
> > > It supports clockwise rotation by 0/90/180/270 degrees defined in
> > > va/va_vpp.h, tested following command line on SKL platform
> > >
> > > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
> > > -hwaccel_output_format vaapi -i input.264 -vf "rotation_vaapi=angle=90"
> > > -c:v h264_vaapi output.h264
> > > ---
> > >  libavfilter/Makefile|   1 +
> > >  libavfilter/allfilters.c|   1 +
> > >  libavfilter/vaapi_vpp.h |   1 +
> > >  libavfilter/vf_misc_vaapi.c | 122 
> > >  4 files changed, 125 insertions(+)
> >
> > breaks build
> > make distclean ; ./configure && make -j12
> > ...
> > libavfilter/vf_misc_vaapi.c: In function 
> > ‘rotation_vaapi_build_filter_params’:
> > libavfilter/vf_misc_vaapi.c:165:23: error: ‘VAProcPipelineCaps’ has no 
> > member named ‘rotation_flags’
> >  if (!pipeline_caps.rotation_flags) {
> >^
> > libavfilter/vf_misc_vaapi.c:191:33: error: ‘VAProcPipelineCaps’ has no 
> > member named ‘rotation_flags’
> >  support_flag = pipeline_caps.rotation_flags &
> >  ^
> > libavfilter/vf_misc_vaapi.c: In function ‘misc_vaapi_filter_frame’:
> > libavfilter/vf_misc_vaapi.c:248:15: error: ‘VAProcPipelineParameterBuffer’ 
> > has no member named ‘rotation_state’
> >  params.rotation_state = vpp_ctx->rotation_state;
> >^
> > make: *** [libavfilter/vf_misc_vaapi.o] Error 1
> > make: *** Waiting for unfinished jobs
> >
> >
> 
> Looks like VPP rotation caps weren't introduced until libva 2.1.0 (in commit 
> cff70165e08ab).
> Perhaps, compilation of this feature should be guarded by VA_CHECK_VERSION 
> macro?
> 

That is, VA-API 1.1.0... VA_CHECK_VERSION(1, 1, 0)

> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > Asymptotically faster algorithms should always be preferred if you have
> > asymptotical amounts of data
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavfilter/vaapi: enable vaapi rotation feature via call Intel iHD driver

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Michael Niedermayer
> Sent: Tuesday, October 23, 2018 10:06 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] libavfilter/vaapi: enable vaapi rotation 
> feature via call Intel iHD driver
> 
> On Tue, Oct 23, 2018 at 03:52:40PM +0800, Zachary Zhou wrote:
> > It supports clockwise rotation by 0/90/180/270 degrees defined in
> > va/va_vpp.h, tested following command line on SKL platform
> >
> > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
> > -hwaccel_output_format vaapi -i input.264 -vf "rotation_vaapi=angle=90"
> > -c:v h264_vaapi output.h264
> > ---
> >  libavfilter/Makefile|   1 +
> >  libavfilter/allfilters.c|   1 +
> >  libavfilter/vaapi_vpp.h |   1 +
> >  libavfilter/vf_misc_vaapi.c | 122 
> >  4 files changed, 125 insertions(+)
> 
> breaks build
> make distclean ; ./configure && make -j12
> ...
> libavfilter/vf_misc_vaapi.c: In function ‘rotation_vaapi_build_filter_params’:
> libavfilter/vf_misc_vaapi.c:165:23: error: ‘VAProcPipelineCaps’ has no member 
> named ‘rotation_flags’
>  if (!pipeline_caps.rotation_flags) {
>^
> libavfilter/vf_misc_vaapi.c:191:33: error: ‘VAProcPipelineCaps’ has no member 
> named ‘rotation_flags’
>  support_flag = pipeline_caps.rotation_flags &
>  ^
> libavfilter/vf_misc_vaapi.c: In function ‘misc_vaapi_filter_frame’:
> libavfilter/vf_misc_vaapi.c:248:15: error: ‘VAProcPipelineParameterBuffer’ 
> has no member named ‘rotation_state’
>  params.rotation_state = vpp_ctx->rotation_state;
>^
> make: *** [libavfilter/vf_misc_vaapi.o] Error 1
> make: *** Waiting for unfinished jobs
> 
> 

Looks like VPP rotation caps weren't introduced until libva 2.1.0 (in commit 
cff70165e08ab).
Perhaps, compilation of this feature should be guarded by VA_CHECK_VERSION 
macro?

> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Asymptotically faster algorithms should always be preferred if you have
> asymptotical amounts of data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc_jpeg: add async_depth support

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
> Zhong Li
> Sent: Thursday, October 11, 2018 2:30 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong 
> Subject: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc_jpeg: add async_depth support
> 
> Currently qsv (m)jpeg encoding is broken.
> Regression introducing by the commit(id: c1bcd3): fix async support,
> which requires the minimum async_depth to be 1, instead previous zero.
> But the default async_depth of qsv (m)jpeg encoding is still initialized
> (mostly) as zero.
> 
> This patch also abviously improves qsv (m)jpeg encoding performance
> due to the default async_depth is changed to 4.
> 
> Signed-off-by: Zhong Li 
> ---
>  libavcodec/qsvenc_jpeg.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libavcodec/qsvenc_jpeg.c b/libavcodec/qsvenc_jpeg.c
> index c18fe91..01c10125 100644
> --- a/libavcodec/qsvenc_jpeg.c
> +++ b/libavcodec/qsvenc_jpeg.c
> @@ -64,6 +64,7 @@ static av_cold int qsv_enc_close(AVCodecContext *avctx)
>  #define OFFSET(x) offsetof(QSVMJPEGEncContext, x)
>  #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
>  static const AVOption options[] = {
> +{ "async_depth", "Maximum processing parallelism", 
> OFFSET(qsv.async_depth), AV_OPT_TYPE_INT, { .i64 =
> ASYNC_DEPTH_DEFAULT }, 1, INT_MAX, VE },
>  { NULL },
>  };
> 
> --
> 2.7.4
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This fixes it for me.  Please merge.


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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass VAConfigAttribEncPackedHeaders with value set to 0

[Eoff, Ullysses A]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Tuesday, February 13, 2018 11:54 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass 
> VAConfigAttribEncPackedHeaders with value set to 0
> 
> On 13/02/18 18:52, Mark Thompson wrote:
> > On 13/02/18 08:24, Haihao Xiang wrote:
> >> Recent Intel i965 driver commit strictly disallows application to set
> >> unsupported attribute values, VA_ENC_PACKED_HEADER_NONE (0) is not used
> >> in Intel i965 driver, so application shouldn't pass this value to the
> >> driver. On the other hand, VA_ENC_PACKED_HEADER_NONE (0) means the
> >> driver doesn't support any packed header mode, so application also
> >> shouldn't pass packed header to driver if a driver returns
> >> VA_ENC_PACKED_HEADER_NONE (0), the driver should work without
> >> VAConfigAttribEncPackedHeaders set for this case.
> >>
> >> In addition, VA_ATTRIB_NOT_SUPPORTED and VA_ENC_PACKED_HEADER_NONE make
> >> thing messy, we will deprecate VA_ENC_PACKED_HEADER_NONE in the
> >> future. See https://github.com/intel/libva/issues/178 for more information.
> >>
> >> This fixes broken vp9 encoder on Kably Lake with Intel I965 driver.
> >>
> >> Signed-off-by: Haihao Xiang 
> >> ---
> >>  libavcodec/vaapi_encode.c | 4 
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> >> index e371f5761ee..1d30aabed40 100644
> >> --- a/libavcodec/vaapi_encode.c
> >> +++ b/libavcodec/vaapi_encode.c
> >> @@ -,6 +,10 @@ static av_cold int 
> >> vaapi_encode_config_attributes(AVCodecContext *avctx)
> >> ctx->va_packed_headers, attr[i].value);
> >>  ctx->va_packed_headers &= attr[i].value;
> >>  }
> >> +
> >> +if (!ctx->va_packed_headers)
> >> +continue;
> >> +
> >>  ctx->config_attributes[ctx->nb_config_attributes++] =
> >>  (VAConfigAttrib) {
> >>  .type  = VAConfigAttribEncPackedHeaders,
> >>
> >
> > This seems wrong to me: the driver has indicated that packed headers are 
> > supported, so the user is providing this attribute to
> indicate to the driver that they will not use any of them.  Compare the VP8 
> case, where the driver does not support them and says so -
> there we correctly don't provide the attribute (though maybe the commentary 
> could be clearer on that).
> 
> Right, I hadn't realised you had already made a change so that encoding is 
> currently broken.  I've made
>  to revert the 
> API/ABI-breaking part of the change.
> 
> Thanks,
> 
> - Mark

I prefer this patch over the one for intel-vaapi-driver.

The va.h documentation for VA_ENC_PACKED_HEADER_NONE
says "Driver does not support any packed headers mode".
Hence, it's only valid for reporting to client that packed headers
are "unsupported".  Unfortunately, VA_ENC_PACKED_HEADER_NONE 
is redundant/ambiguous since there is also
VA_ATTRIB_NOT_SUPPORTED to relay the same information.
This is why we want to deprecate VA_ENC_PACKED_HEADER_NONE
in VAAPI.

I don't think it's correct for clients to send
VA_ENC_PACKED_HEADER_NONE attribute value to the driver
when the driver reports packed headers are "supported".  It
goes against VA_ENC_PACKED_HEADER_NONE's documented
purpose.  AFAIK, libavcodec is the only library that does this.  It
is better to just omit the attribute altogether if client does not
want to use any of the "supported" packed headers.  And this
patch solves that.

In the future, it's probably worth amending VAAPI to allow for
drivers to relay when packed headers are required vs. optional,
too.

U. Artie

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