Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: expose low_power option in H264 QSV

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Tuesday, March 26, 2019 12:02
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH] lavc/qsvenc: expose low_power option
> in H264 QSV
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Monday, March 25, 2019 9:32 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH] lavc/qsvenc: expose low_power option
> in
> > H264 QSV
> >
> > Always exposes low_power option for h264 qsv, and reports a warning if
> > VDENC is not supported with current version of MSDK.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/qsvenc.c  | 11 ++-
> >  libavcodec/qsvenc_h264.c |  2 --
> >  2 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> > 5aa020d47b..8264d0a413 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -495,9 +495,18 @@ static int init_video_param(AVCodecContext
> *avctx,
> > QSVEncContext *q)
> >  }
> >  }
> >
> > +if (q->low_power) {
> >  #if QSV_HAVE_VDENC
> > -q->param.mfx.LowPower   = q->low_power ?
> > MFX_CODINGOPTION_ON : MFX_CODINGOPTION_OFF;
> > +q->param.mfx.LowPower = MFX_CODINGOPTION_ON; #else
> > +av_log(avctx, AV_LOG_WARNING, "The QSV VDENC option is "
> > +"not supported with this MSDK
> > version.\n");
> 
> VDEnc is driver and hardware scope should not be exposed in FFmpeg level.
> Lower power is easier for user to understand, and it is the option user set. 
> So
> I believe the would be better to change the log to be
> "low power mode is not supported ..."
> 
It's true "low power" is better, will update.
> > +q->low_power = 0;
> > +q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
> >  #endif
> > +} else
> > +q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
> 
> The rest 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 3/3] doc/examples: add QSV decode GPU copy sample

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Li, Zhong
> Sent: Wednesday, March 27, 2019 11:17
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] doc/examples: add QSV decode
> GPU copy sample
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Michael Niedermayer
> > Sent: Wednesday, March 27, 2019 12:05 AM
> > To: FFmpeg development discussions and patches
> > 
> > Subject: Re: [FFmpeg-devel] [PATCH 3/3] doc/examples: add QSV decode
> > GPU copy sample
> >
> > On Tue, Mar 26, 2019 at 01:39:49PM +0800, Linjie Fu wrote:
> > > Usage is:
> > >   ./qsvdec_gpucopy on/off input_stream output_stream
> > >
> > > For example:
> > >  - enable/disable gpu copy:
> > >   ./qsvdec_gpucopy on input.h264 output.yuv
> > >   ./qsvdec_gpucopy off input.h264 output.yuv
> > >
> > > Generate fps per second.
> > >
> > > Signed-off-by: Linjie Fu 
> > > ---
> > >  configure |   2 +
> > >  doc/examples/Makefile |   1 +
> > >  doc/examples/qsvdec_gpucopy.c | 276
> > > ++
> > >  3 files changed, 279 insertions(+)
> > >  create mode 100644 doc/examples/qsvdec_gpucopy.c
> >
> > breaks examples build on arm
> >
> > In file included from src/doc/examples/qsvdec_gpucopy.c:43:0:
> > src/libavcodec/qsv.h:24:26: fatal error: mfx/mfxvideo.h: No such file or
> > directory compilation terminated.
> > make: *** [doc/examples/qsvdec_gpucopy.o] Error 1
> > make: *** Waiting for unfinished jobs
> 
> It is caused by libmfx is not checked to configure this example in configure
> file.
> It is checked for doc/examples/qsvdec.c: qsvdec_example_deps="avcodec
> avutil libmfx h264_qsv_decoder"
> Similar checking is needed for this example.

Thanks, will update and check.

> However, I would like to suggestion to add gpu_copy option based on
> current qsvdec.c example (working in system memory path should be added
> too).

I'm not quite sure whether the example of qsvdec.c can enable the system memory 
path
without hwdownload.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: add va_profile format map support for HEVC_REXT

[Fu, Linjie]

> -Original Message-
> From: myp...@gmail.com [mailto:myp...@gmail.com]
> Sent: Thursday, March 28, 2019 13:03
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: add va_profile
> format map support for HEVC_REXT
> 
> On Thu, Mar 28, 2019 at 12:03 PM Linjie Fu  wrote:
> >
> > HEVC_REXT will be map to {VAProfileHEVCMain422_10,
> VAProfileHEVCMain444,
> > VAProfileHEVCMain444_10} in vaapi_profile_map[], since need to be
> distinguished
> > to select the exact va_profile.
> >
> > Add va_profile -> AV_PIX_FMT map for FF_PROFILE_HEVC_REXT to match
> the
> > exact va_profile.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/vaapi_decode.c | 29 +
> >  1 file changed, 25 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index 015154b879..1cb8683b7c 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -414,6 +414,18 @@ static const struct {
> >  #undef MAP
> >  };
> >
> > +static const struct {
> > +VAProfile va_profile;
> > +enum AVPixelFormat pix_fmt;
> > +} rext_format_map[] = {
> > +#define MAP(vp, av) { VAProfileHEVCMain ## vp, AV_PIX_FMT_ ## av }
> > +MAP(422_10,  YUYV422),
> > +MAP(422_10,  YUV422P10LE),
> > +MAP(444, YUV444P),
> > +MAP(444_10,  YUV444P10LE),
> > +#undef MAP
> > +};
> > +
> >  /*
> >   * Set *va_config and the frames_ref fields from the current codec
> parameters
> >   * in avctx.
> > @@ -426,7 +438,7 @@ static int
> vaapi_decode_make_config(AVCodecContext *avctx,
> >  AVVAAPIHWConfig   *hwconfig= NULL;
> >  AVHWFramesConstraints *constraints = NULL;
> >  VAStatus vas;
> > -int err, i, j;
> > +int err, i, j, k;
> >  const AVCodecDescriptor *codec_desc;
> >  VAProfile *profile_list = NULL, matched_va_profile;
> >  int profile_count, exact_match, matched_ff_profile;
> > @@ -467,13 +479,22 @@ static int
> vaapi_decode_make_config(AVCodecContext *avctx,
> >  if (avctx->profile == vaapi_profile_map[i].codec_profile ||
> >  vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN)
> >  profile_match = 1;
> > -for (j = 0; j < profile_count; j++) {
> > -if (vaapi_profile_map[i].va_profile == profile_list[j]) {
> > +if (avctx->profile == FF_PROFILE_HEVC_REXT) {
> > +/* find the exact va_profile for HEVC_REXT */
> > +for (j = 0; j < FF_ARRAY_ELEMS(rext_format_map); j++) {
> > +if (avctx->pix_fmt == rext_format_map[j].pix_fmt)
> > +   break;
> > +}
> > +if (vaapi_profile_map[i].va_profile !=
> rext_format_map[j].va_profile)
> > +continue;
> > +}
> > +for (k = 0; k < profile_count; k++) {
> > +if (vaapi_profile_map[i].va_profile == profile_list[k]) {
> >  exact_match = profile_match;
> >  break;
> >  }
> >  }
> > -if (j < profile_count) {
> > +if (k < profile_count) {
> >  matched_va_profile = vaapi_profile_map[i].va_profile;
> >  matched_ff_profile = vaapi_profile_map[i].codec_profile;
> >  if (exact_match)
> > --
> 
> What  intel platform supported HEVCMain422 or 444?
Will be supported [ICE LAKE+].
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: add va_profile format map support for HEVC_REXT

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Friday, March 29, 2019 01:48
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: add va_profile
> format map support for HEVC_REXT
> 
> On Thu, Mar 28, 2019 at 12:03:53PM +0800, Linjie Fu wrote:
> > HEVC_REXT will be map to {VAProfileHEVCMain422_10,
> VAProfileHEVCMain444,
> > VAProfileHEVCMain444_10} in vaapi_profile_map[], since need to be
> distinguished
> > to select the exact va_profile.
> >
> > Add va_profile -> AV_PIX_FMT map for FF_PROFILE_HEVC_REXT to match
> the
> > exact va_profile.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/vaapi_decode.c | 29 +
> >  1 file changed, 25 insertions(+), 4 deletions(-)
> 
> breaks build
> 
> libavcodec/vaapi_decode.c:409:7: error: ‘VAProfileHEVCMain422_10’
> undeclared here (not in a function)
>  MAP(422_10,  YUYV422),
>^
> libavcodec/vaapi_decode.c:411:7: error: ‘VAProfileHEVCMain444’ undeclared
> here (not in a function)
>  MAP(444, YUV444P),
>^
> libavcodec/vaapi_decode.c:412:7: error: ‘VAProfileHEVCMain444_10’
> undeclared here (not in a function)
>  MAP(444_10,  YUV444P10LE),
>^
> make: *** [libavcodec/vaapi_decode.o] Error 1

I'm not quite sure why it happens.
In va/va.h,  VAProfile for Main422_10, Main444, Main444_10 is declared:
VAProfileHEVCMain422_10 = 24,
VAProfileHEVCMain422_12 = 25,
VAProfileHEVCMain444 = 26,
VAProfileHEVCMain444_10  = 27,
https://github.com/intel/libva/blob/c98b06d2b8c00dc4df628488b672711b3f0eb118/va/va.h#L380

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

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: add va_profile format map support for HEVC_REXT

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Friday, March 29, 2019 07:34
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_decode: add va_profile
> format map support for HEVC_REXT
> 
> On 28/03/2019 04:03, Linjie Fu wrote:
> > HEVC_REXT will be map to {VAProfileHEVCMain422_10,
> VAProfileHEVCMain444,
> > VAProfileHEVCMain444_10} in vaapi_profile_map[], since need to be
> distinguished
> > to select the exact va_profile.
> >
> > Add va_profile -> AV_PIX_FMT map for FF_PROFILE_HEVC_REXT to match
> the
> > exact va_profile.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/vaapi_decode.c | 29 +
> >  1 file changed, 25 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index 015154b879..1cb8683b7c 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -414,6 +414,18 @@ static const struct {
> >  #undef MAP
> >  };
> >
> > +static const struct {
> > +VAProfile va_profile;
> > +enum AVPixelFormat pix_fmt;
> > +} rext_format_map[] = {
> > +#define MAP(vp, av) { VAProfileHEVCMain ## vp, AV_PIX_FMT_ ## av }
> > +MAP(422_10,  YUYV422),
> > +MAP(422_10,  YUV422P10LE),
> > +MAP(444, YUV444P),
> > +MAP(444_10,  YUV444P10LE),
> 
> This doesn't work - you can't guess the rext profile from the chroma format
> and bit depth information, because the profiles are all overlapping (see table
> A.1).
> 
> You need to use the profile constraint flags to determine it - this lookup is
> implemented by ff_h265_get_profile(), but you'll need to extract all the flags
> to put into it.
> 
Thanks for the advice Mark, and I think these constraint flags should be parsed 
firstly in decode_profile_tier_level():
https://github.com/FFmpeg/FFmpeg/blob/9dece050ef01c70df1ac74a04da3548b3c0d79a9/libavcodec/hevc_ps.c#L265

Currently, they are skipped when parsing the sps:
skip_bits(gb, 16); // XXX_reserved_zero_44bits[0..15]
skip_bits(gb, 16); // XXX_reserved_zero_44bits[16..31]
skip_bits(gb, 12); // XXX_reserved_zero_44bits[32..43]
Will it be acceptable to add these flags in common hevc parser function for the 
usage in VAAPI decode? 

> > +#undef MAP
> > +};
> > +
> >  /*
> >   * Set *va_config and the frames_ref fields from the current codec
> parameters
> >   * in avctx.
> > @@ -426,7 +438,7 @@ static int
> vaapi_decode_make_config(AVCodecContext *avctx,
> >  AVVAAPIHWConfig   *hwconfig= NULL;
> >  AVHWFramesConstraints *constraints = NULL;
> >  VAStatus vas;
> > -int err, i, j;
> > +int err, i, j, k;
> >  const AVCodecDescriptor *codec_desc;
> >  VAProfile *profile_list = NULL, matched_va_profile;
> >  int profile_count, exact_match, matched_ff_profile;
> > @@ -467,13 +479,22 @@ static int
> vaapi_decode_make_config(AVCodecContext *avctx,
> >  if (avctx->profile == vaapi_profile_map[i].codec_profile ||
> >  vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN)
> >  profile_match = 1;
> > -for (j = 0; j < profile_count; j++) {
> > -if (vaapi_profile_map[i].va_profile == profile_list[j]) {
> > +if (avctx->profile == FF_PROFILE_HEVC_REXT) {
> > +/* find the exact va_profile for HEVC_REXT */
> > +for (j = 0; j < FF_ARRAY_ELEMS(rext_format_map); j++) {
> > +if (avctx->pix_fmt == rext_format_map[j].pix_fmt)
> > +   break;
> > +}
> > +if (vaapi_profile_map[i].va_profile !=
> rext_format_map[j].va_profile)
> > +continue;
> > +}
> 
> Codec-specific stuff probably shouldn't be hidden in the middle of the
> generic code like this.

Got your point and I add this to avoid redundant map query, for other codecs, 
codec_id and codec_profile are enough to determine the exact va_profile.
Any advice for coping with this situation?
(Did you mean finding some other methods to modify in vaapi_hevc.c, because all
 vaapi decoders are sharing same init funcion)

> > +for (k = 0; k < profile_count; k++) {
> > +if (vaapi_profile_map[i].va_profile == profile_list[k]) {
> >  exact_match = profile_match;
> >  break;
> >  }
> >  }
> > -if (j < profile_count) {
> > +if (k < profile_count) {
> >  matched_va_profile = vaapi_profile_map[i].va_profile;
> >  matched_ff_profile = vaapi_profile_map[i].codec_profile;
> >  if (exact_match)
> >
> 
> When will it be possible to get hardware which supports these profiles?
> 

Honestly, I don't know when the hardware (ICL) will be available, either.

Thanks very much.
linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, 

Re: [FFmpeg-devel] [PATCH] lavc/hevc_ps: parse constraint flags for HEVC REXT

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Tuesday, April 2, 2019 06:24
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/hevc_ps: parse constraint flags for
> HEVC REXT
> 
> On 01/04/2019 22:38, James Almer wrote:
> > On 4/1/2019 6:43 AM, Linjie Fu wrote:
> >> Parse all the constraint flags.
> >>
> >> It can be passed to hw decoders to detemine the exact profile for Range
> >> Extension HEVC.
> >>
> >> Signed-off-by: Linjie Fu 
> >> ---
> >>  libavcodec/hevc_ps.c | 18 +++---
> >>  libavcodec/hevc_ps.h | 10 ++
> >>  2 files changed, 25 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> >> index 80df417e4f..1365a9d640 100644
> >> --- a/libavcodec/hevc_ps.c
> >> +++ b/libavcodec/hevc_ps.c
> >> @@ -295,9 +295,21 @@ static int
> decode_profile_tier_level(GetBitContext *gb, AVCodecContext *avctx,
> >>  ptl->non_packed_constraint_flag = get_bits1(gb);
> >>  ptl->frame_only_constraint_flag = get_bits1(gb);
> >>
> >> -skip_bits(gb, 16); // XXX_reserved_zero_44bits[0..15]
> >> -skip_bits(gb, 16); // XXX_reserved_zero_44bits[16..31]
> >> -skip_bits(gb, 12); // XXX_reserved_zero_44bits[32..43]
> >> +ptl->max_12bit_constraint_flag= get_bits1(gb);
> >> +ptl->max_10bit_constraint_flag= get_bits1(gb);
> >> +ptl->max_8bit_constraint_flag = get_bits1(gb);
> >> +ptl->max_422chroma_constraint_flag= get_bits1(gb);
> >> +ptl->max_420chroma_constraint_flag= get_bits1(gb);
> >> +ptl->max_monochrome_constraint_flag   = get_bits1(gb);
> >> +ptl->intra_constraint_flag= get_bits1(gb);
> >> +ptl->one_picture_only_constraint_flag = get_bits1(gb);
> >> +ptl->lower_bit_rate_constraint_flag   = get_bits1(gb);
> >> +
> >> +skip_bits(gb, 16); // XXX_reserved_zero_34bits[0..15]
> >
> > The first of these bits can be general_max_14bit_constraint_flag. I
> > suppose no hardware really supports it?
> 
> I think it's worth getting these right anyway.
> 
> From the set of flags you've ended up with here I'm guessing you're working
> from a pre-2018 version of the standard?  Try the 201802 version -
> .
> 
> >> +skip_bits(gb, 16); // XXX_reserved_zero_34bits[16..31]
> >> +skip_bits(gb, 2);  // XXX_reserved_zero_34bits[32..33]
> >> +
> >> +ptl->inbld_flag = get_bits1(gb);
> >
> > Strictly speaking, you should be checking ptl->profile_idc and
> > ptl->profile_compatibility_flag to parse these, as per section 7.3.3 in
> > the spec.
> > Despite the amount of bits being fixed and the default value being 0, it
> > would be ideal to prevent misparsing damaged samples.
> 
> +1.  Future profiles which could assign completely different meanings to
> these bits are also a possibility, though I would hope the standard people
> would avoid doing that.

Thanks for the suggestions,  refined patch has been sent.
___
ffmpeg-devel mailing list
ffmpeg-devel@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, RFC 2/2] lavc/vaapi_decode: find exact va_profile for HEVC_REXT

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Thursday, April 4, 2019 06:38
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, RFC 2/2] lavc/vaapi_decode: find exact
> va_profile for HEVC_REXT
> 
> On Wed, Apr 03, 2019 at 12:10:22PM +0800, Linjie Fu wrote:
> > Use the profile constraint flags to determine the exact va_profile for
> > HEVC_REXT.
> >
> > Directly cast PTLCommon to H265RawProfileTierLevel, and use
> ff_h265_get_profile
> > to get the exact profile.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > [v2]: use constraint flags to determine the exact profile, expose the
> > codec-specific stuff at the beginning.
> > [RFC]: is it acceptable to cast PTLCommon to H265RawProfileTierLevel for
> > convenience? The members in PTLCommon should be strictly matched in
> > H265RawProfileTierLevel.
> >
> >  libavcodec/vaapi_decode.c | 74 +++--
> --
> >  1 file changed, 59 insertions(+), 15 deletions(-)
> 
> breaks build:
> 
> CClibavcodec/vaapi_decode.o
> libavcodec/vaapi_decode.c: In function ‘vaapi_decode_find_exact_profile’:
> libavcodec/vaapi_decode.c:421:16: error: ‘VAProfileHEVCMain422_10’
> undeclared (first use in this function)
>  return VAProfileHEVCMain422_10;
> ^
> libavcodec/vaapi_decode.c:421:16: note: each undeclared identifier is
> reported only once for each function it appears in
> libavcodec/vaapi_decode.c:423:16: error: ‘VAProfileHEVCMain444’
> undeclared (first use in this function)
>  return VAProfileHEVCMain444;
> ^
> libavcodec/vaapi_decode.c:425:16: error: ‘VAProfileHEVCMain444_10’
> undeclared (first use in this function)
>  return VAProfileHEVCMain444_10;
> ^
> libavcodec/vaapi_decode.c: At top level:
> libavcodec/vaapi_decode.c:409:18: warning:
> ‘vaapi_decode_find_exact_profile’ defined but not used [-Wunused-
> function]
>  static VAProfile vaapi_decode_find_exact_profile(AVCodecContext *avctx)
>   ^
> make: *** [libavcodec/vaapi_decode.o] Error 1
> make: Target `all' not remade because of errors.
> 
Thanks, will move the VA version check into the 
vaapi_decode_find_exact_profile()
to fix the compile issue and avoid function not used warning.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 RFC 2/2] lavc/vaapi_decode: find exact va_profile for HEVC_REXT

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Friday, April 5, 2019 00:52
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3 RFC 2/2] lavc/vaapi_decode: find
> exact va_profile for HEVC_REXT
> 
> On Thu, Apr 04, 2019 at 04:10:35PM +0800, Linjie Fu wrote:
> > Use the profile constraint flags to determine the exact va_profile for
> > HEVC_REXT.
> >
> > Directly cast PTLCommon to H265RawProfileTierLevel, and use
> ff_h265_get_profile
> > to get the exact profile.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > [v2]: use constraint flags to determine the exact profile, expose the
> > codec-specific stuff at the beginning.
> > [v3]: move the VA version check to fix the compile issue.
> > [RFC]: is it acceptable to cast PTLCommon to H265RawProfileTierLevel for
> > convenience? The members in PTLCommon should be strictly matched in
> > H265RawProfileTierLevel.
> >
> >  libavcodec/vaapi_decode.c | 73 +++--
> --
> >  1 file changed, 58 insertions(+), 15 deletions(-)
> 
> breaks build with shared libs:
> 
> libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile'
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make: *** [ffmpeg_g] Error 1
> make: *** Waiting for unfinished jobs
> libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile'
> libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile'
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make: *** [ffplay_g] Error 1
> clang: error: linker command failed with exit code 1 (use -v to see 
> invocation)
> make: *** [ffprobe_g] Error 1
> 
> 

Hi Michael,

Thanks for the build check and compile error messages.
Actually, I also did the compile check locally and through pre-patch system.

We do shared libs compile with gcc and latest libva and msdk master deps, and 
it passes the check.
It seems this error occurs with clang.

 Could you provide some details on how to reproduce it? (e.g. compiler, distro, 
deps, flags, etc.).

Thus we can add into the system to refine the pre-patch check and have this 
clang compile issue fixed?

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

Re: [FFmpeg-devel] [PATCH 1/3] lavc/qsvdec: add support for gpu_copy

[Fu, Linjie]

> -Original Message-
> From: Fu, Linjie
> Sent: Tuesday, March 26, 2019 13:38
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie ; ChaoX A Liu 
> Subject: [PATCH 1/3] lavc/qsvdec: add support for gpu_copy
> 
> Add support for GPU copy when QSV decoders works in system memory
> mode.
> However, memory must be sequent and aligned with 128x64 to enable this
> feature.(first introduced in FFmpeg 3.3.1)
> 
> GPUCopy = MFX_GPUCOPY_ON leads to performance improvement up to
> x10.
> 
> CMD:
> ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -c:v h264_qsv
> -gpu_copy on -i input.h264 -pix_fmt yuv420p out.yuv
> 
> 
> Signed-off-by: Linjie Fu 
> Signed-off-by: ChaoX A Liu 
> ---
>  libavcodec/qsv.c  | 27 +---
>  libavcodec/qsv_internal.h |  6 ++---
>  libavcodec/qsvdec.c   | 53 ++
> -
>  libavcodec/qsvdec.h   |  2 ++
>  libavcodec/qsvdec_h2645.c | 10 
>  libavcodec/qsvdec_other.c |  5 
>  libavcodec/qsvenc.c   |  7 +++---
>  7 files changed, 89 insertions(+), 21 deletions(-)
> 
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index bb0d79588c..40e6c677cb 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -277,15 +277,19 @@ load_plugin_fail:
>  }
> 
>  int ff_qsv_init_internal_session(AVCodecContext *avctx, mfxSession
> *session,
> - const char *load_plugins)
> + const char *load_plugins, int gpu_copy)
>  {
> -mfxIMPL impl   = MFX_IMPL_AUTO_ANY;
> -mfxVersion ver = { { QSV_VERSION_MINOR, QSV_VERSION_MAJOR } };
> +mfxIMPL  impl = MFX_IMPL_AUTO_ANY;
> +mfxVersionver = { { QSV_VERSION_MINOR,
> QSV_VERSION_MAJOR } };
> +mfxInitParam init_par = { MFX_IMPL_AUTO_ANY };
> 
>  const char *desc;
>  int ret;
> 
> -ret = MFXInit(impl, &ver, session);
> +init_par.GPUCopy= gpu_copy;
> +init_par.Implementation = impl;
> +init_par.Version= ver;
> +ret = MFXInitEx(init_par, session);
>  if (ret < 0)
>  return ff_qsv_print_error(avctx, ret,
>"Error initializing an internal MFX 
> session");
> @@ -571,7 +575,8 @@ static mfxStatus qsv_frame_get_hdl(mfxHDL pthis,
> mfxMemId mid, mfxHDL *hdl)
>  }
> 
>  int ff_qsv_init_session_device(AVCodecContext *avctx, mfxSession
> *psession,
> -   AVBufferRef *device_ref, const char 
> *load_plugins)
> +   AVBufferRef *device_ref, const char 
> *load_plugins,
> +   int gpu_copy)
>  {
>  static const mfxHandleType handle_types[] = {
>  MFX_HANDLE_VA_DISPLAY,
> @@ -581,11 +586,12 @@ int ff_qsv_init_session_device(AVCodecContext
> *avctx, mfxSession *psession,
>  AVHWDeviceContext*device_ctx = (AVHWDeviceContext*)device_ref-
> >data;
>  AVQSVDeviceContext *device_hwctx = device_ctx->hwctx;
>  mfxSessionparent_session = device_hwctx->session;
> +mfxInitParaminit_par = { MFX_IMPL_AUTO_ANY };
> +mfxHDLhandle = NULL;
> 
>  mfxSessionsession;
>  mfxVersionver;
>  mfxIMPL   impl;
> -mfxHDLhandle = NULL;
>  mfxHandleType handle_type;
>  mfxStatus err;
> 
> @@ -611,7 +617,10 @@ int ff_qsv_init_session_device(AVCodecContext
> *avctx, mfxSession *psession,
> "from the session\n");
>  }
> 
> -err = MFXInit(impl, &ver, &session);
> +init_par.GPUCopy= gpu_copy;
> +init_par.Implementation = impl;
> +init_par.Version= ver;
> +err = MFXInitEx(init_par, &session);
>  if (err != MFX_ERR_NONE)
>  return ff_qsv_print_error(avctx, err,
>"Error initializing a child MFX session");
> @@ -642,7 +651,7 @@ int ff_qsv_init_session_device(AVCodecContext
> *avctx, mfxSession *psession,
> 
>  int ff_qsv_init_session_frames(AVCodecContext *avctx, mfxSession
> *psession,
> QSVFramesContext *qsv_frames_ctx,
> -   const char *load_plugins, int opaque)
> +   const char *load_plugins, int opaque, int 
> gpu_copy)
>  {
>  mfxFrameAllocator frame_allocator = {
>  .pthis  = qsv_frames_ctx,
> @@ -662,7 +671,7 @@ int ff_qsv_init_session_frames(AVCodecContext
> *avctx, mfxSession *psession,
>  int ret;
> 
>  ret = ff_qsv_init_session_device(avctx, &session,
> - 

Re: [FFmpeg-devel] [PATCH, v3 RFC 2/2] lavc/vaapi_decode: find exact va_profile for HEVC_REXT

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Almer
> Sent: Monday, April 8, 2019 21:56
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v3 RFC 2/2] lavc/vaapi_decode: find
> exact va_profile for HEVC_REXT
> 
> On 4/7/2019 11:02 PM, Fu, Linjie wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Michael Niedermayer
> >> Sent: Friday, April 5, 2019 00:52
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH, v3 RFC 2/2] lavc/vaapi_decode: find
> >> exact va_profile for HEVC_REXT
> >>
> >> On Thu, Apr 04, 2019 at 04:10:35PM +0800, Linjie Fu wrote:
> >>> Use the profile constraint flags to determine the exact va_profile for
> >>> HEVC_REXT.
> >>>
> >>> Directly cast PTLCommon to H265RawProfileTierLevel, and use
> >> ff_h265_get_profile
> >>> to get the exact profile.
> >>>
> >>> Signed-off-by: Linjie Fu 
> >>> ---
> >>> [v2]: use constraint flags to determine the exact profile, expose the
> >>> codec-specific stuff at the beginning.
> >>> [v3]: move the VA version check to fix the compile issue.
> >>> [RFC]: is it acceptable to cast PTLCommon to H265RawProfileTierLevel for
> >>> convenience? The members in PTLCommon should be strictly matched
> in
> >>> H265RawProfileTierLevel.
> >>>
> >>>  libavcodec/vaapi_decode.c | 73
> +++--
> >> --
> >>>  1 file changed, 58 insertions(+), 15 deletions(-)
> >>
> >> breaks build with shared libs:
> >>
> >> libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile'
> >> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> >> make: *** [ffmpeg_g] Error 1
> >> make: *** Waiting for unfinished jobs
> >> libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile'
> >> libavcodec/libavcodec.so: undefined reference to `ff_h265_get_profile'
> >> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> >> make: *** [ffplay_g] Error 1
> >> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
> >> make: *** [ffprobe_g] Error 1
> >>
> >>
> >
> > Hi Michael,
> >
> > Thanks for the build check and compile error messages.
> > Actually, I also did the compile check locally and through pre-patch system.
> >
> > We do shared libs compile with gcc and latest libva and msdk master deps,
> and it passes the check.
> > It seems this error occurs with clang.
> >
> >  Could you provide some details on how to reproduce it? (e.g. compiler,
> distro, deps, flags, etc.).
> >
> > Thus we can add into the system to refine the pre-patch check and have
> this clang compile issue fixed?
> >
> > Thanks,
> > Linjie
> 
> You need to add h265_profile_level.o to the build objects related to
> this module in libavcodec/Makefile. It's currently only being built for
> the hevc vaapi encoder, so if that's disabled, linking will fail.
> 
> It's most likely not an issue with shared builds. I'm guessing Michael's
> environment for that build had the hevc vaapi encoder disabled.

Yes, that's the problem and thanks for the comments.
I disabled hevc_vaapi encoder and reproduced this build issue.

With h265_profile_level.o added to the build objects of vaapi_decode,
this issue can be fixed.

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

Re: [FFmpeg-devel] [PATCH, v4] lavc/vaapi_decode: find exact va_profile for HEVC_REXT

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, April 10, 2019 07:20
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v4] lavc/vaapi_decode: find exact
> va_profile for HEVC_REXT
> 
> On 09/04/2019 03:33, Linjie Fu wrote:
> > Use the profile constraint flags to determine the exact va_profile for
> > HEVC_REXT.
> >
> > Directly cast PTLCommon to H265RawProfileTierLevel,
> 
> Please don't.  The two structures aren't really connected, they shouldn't be
> assumed to be compatible.
I'm trying to avoid the repeated value passing code from these two structures, 
and wonder if it's acceptable in community.
Well,  will find some other ways to pass the flags.
> 
> > and use 
> > ff_h265_get_profile
> > to get the exact profile.
> >
> > Add h265_profile_level.o to build objects for vaapi_decode to fix the
> compile
> > dependency issue.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > [v2]: use constraint flags to determine the exact profile, expose the
> > codec-specific stuff at the beginning.
> > [v3]: move the VA version check to fix the compile issue.
> > [v4]: fix the build issue.
> >
> >  libavcodec/Makefile   |  2 +-
> >  libavcodec/vaapi_decode.c | 73 +++--
> --
> >  2 files changed, 59 insertions(+), 16 deletions(-)
> >
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 15c43a8a6a..c0df0ad90a 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -857,7 +857,7 @@ OBJS-$(CONFIG_ADPCM_YAMAHA_ENCODER)
> += adpcmenc.o adpcm_data.o
> >  OBJS-$(CONFIG_D3D11VA)+= dxva2.o
> >  OBJS-$(CONFIG_DXVA2)  += dxva2.o
> >  OBJS-$(CONFIG_NVDEC)  += nvdec.o
> > -OBJS-$(CONFIG_VAAPI)  += vaapi_decode.o
> > +OBJS-$(CONFIG_VAAPI)  += vaapi_decode.o
> h265_profile_level.o
> >  OBJS-$(CONFIG_VIDEOTOOLBOX)   += videotoolbox.o
> >  OBJS-$(CONFIG_VDPAU)  += vdpau.o
> >
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index 69512e1d45..47db6c874a 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -24,6 +24,8 @@
> >  #include "decode.h"
> >  #include "internal.h"
> >  #include "vaapi_decode.h"
> > +#include "hevcdec.h"
> > +#include "h265_profile_level.h"
> >
> >
> >  int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
> > @@ -401,6 +403,33 @@ static const struct {
> >  #undef MAP
> >  };
> >
> > +/*
> > + * Find exact va_profile for HEVC Range Extension
> > + */
> > +static VAProfile vaapi_decode_find_exact_profile(AVCodecContext
> *avctx)
> > +{
> > +const HEVCContext *h = avctx->priv_data;
> > +const HEVCSPS *sps = h->ps.sps;
> > +const PTL *ptl = &(sps->ptl);
> > +const PTLCommon *general_ptl = &(ptl->general_ptl);
> > +const H265ProfileDescriptor *profile;
> > +
> > +/* PTLCommon should match the member sequence in
> H265RawProfileTierLevel*/
> > +profile = ff_h265_get_profile((H265RawProfileTierLevel *)general_ptl);
> 
> This can return NULL.

Opus, this should be checked, thanks.

> > +
> > +#if VA_CHECK_VERSION(1, 2, 0)
> > +if (!strcmp(profile->name, "Main 4:2:2 10"))
> > +return VAProfileHEVCMain422_10;
> > +else if (!strcmp(profile->name, "Main 4:4:4"))
> > +return VAProfileHEVCMain444;
> > +else if (!strcmp(profile->name, "Main 4:4:4 10"))
> > +return VAProfileHEVCMain444_10;
> > +#else
> > +av_log(avctx, AV_LOG_WARNING, "HEVC profile %s is "
> > +"not supported with this VA version.\n", 
> > profile->name);
> > +#endif
> > +return VAProfileNone;
> > +}
> >  /*
> >   * Set *va_config and the frames_ref fields from the current codec
> parameters
> >   * in avctx.
> > @@ -447,24 +476,38 @@ static int
> vaapi_decode_make_config(AVCodecContext *avctx,
> >  matched_va_profile = VAProfileNone;
> >  exact_match = 0;
> >
> > -for (i = 0; i < FF_ARRAY_ELEMS(vaapi_profile_map); i++) {
> > -int profile_match = 0;
> > -if (avctx->codec_id != vaapi_profile_map[i].codec_id)
> > -continue;
> > -if (avctx->profile == vaapi_profile_map[i].codec_profile ||
> > -vaapi_profile_map[i].codec_profile == FF_PROFILE_UNKNOWN)
> > -profile_match = 1;
> > -for (j = 0; j < profile_count; j++) {
> > -if (vaapi_profile_map[i].va_profile == profile_list[j]) {
> > -exact_match = profile_match;
> > +if (avctx->profile == FF_PROFILE_HEVC_REXT) {
> > +/* find the exact va_profile for HEVC_REXT */
> > +VAProfile va_profile = vaapi_decode_find_exact_profile(avctx);
> > +for (i = 0; i < profile_count; i++) {
> > +if (va_profile == profile_list[i]) {
> > +exact_match = 1;
> > + 

Re: [FFmpeg-devel] [PATCH] lavu/hwcontext_qsv: Fix the realign check for hwupload

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Wednesday, April 10, 2019 19:35
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavu/hwcontext_qsv: Fix the realign
> check for hwupload
> 
> 2019-04-10 13:26 GMT+02:00, Linjie Fu :
> > Fix the aligned check in hwupload, input surface should be 16 aligned
> > too.
> >
> > Fix #7830.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavutil/hwcontext_qsv.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> > index b6d8bfe2bf..bc6236f25d 100644
> > --- a/libavutil/hwcontext_qsv.c
> > +++ b/libavutil/hwcontext_qsv.c
> > @@ -892,7 +892,8 @@ static int
> qsv_transfer_data_to(AVHWFramesContext *ctx,
> > AVFrame *dst,
> >  return ret;
> >
> >
> > -if (src->height & 16 || src->linesize[0] & 16) {
> > +if (src->height % 16 || src->width % 16 ||
> > +src->linesize[0] % 16) {
> 
> & 15?

& 15 seems to be better, thanks.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: Fix the memory leak for enc_ctrl.Payload

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Thursday, April 11, 2019 11:14
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: Fix the memory leak
> for enc_ctrl.Payload
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Wednesday, April 10, 2019 7:27 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: Fix the memory leak for
> > enc_ctrl.Payload
> >
> > frame->enc_ctrl.Payload is malloced in get_free_frame, directly memset
> > the whole structure of enc_ctrl to zero will cause the memory leak for
> > enc_ctrl.Payload.
> >
> > Fix the memory leak issue and reset other members in mfxEncodeCtrl.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/qsvenc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> > 5aa020d47b..029bb562d6 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -1254,7 +1254,7 @@ static int encode_frame(AVCodecContext *avctx,
> > QSVEncContext *q,
> >  if (qsv_frame) {
> >  surf = &qsv_frame->surface;
> >  enc_ctrl = &qsv_frame->enc_ctrl;
> > -memset(enc_ctrl, 0, sizeof(mfxEncodeCtrl));
> > +memset(enc_ctrl, 0, sizeof(mfxEncodeCtrl) - sizeof(mfxPayload
> > + **));
> 
> Looks a little tricky, if someone didn't read carefully the sequence of
> mfxPayload usages, they can't know why this change happening.
> And potential risk for other elements such as "mfxExtBuffer** ExtParam" is
> still existed.
> 
> IMHO, one good habit is that is you want to memset a buffer, would better
> memset it when you allocate it.
> So I believe the correct fix should be: memset mfxEncodeCtrl at the start of
> qsv frame allocated: the place should be in the function get_free_frame()
> 
Aware of the risk of mfxExtBuffer too, and move the memset at the start of the 
allocation is great, will modify.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: Fix the memory leak for enc_ctrl.Payload

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Wednesday, April 10, 2019 19:35
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: Fix the memory leak
> for enc_ctrl.Payload
> 
> 2019-04-10 13:27 GMT+02:00, Linjie Fu :
> > frame->enc_ctrl.Payload is malloced in get_free_frame, directly memset
> > the whole structure of enc_ctrl to zero will cause the memory leak for
> > enc_ctrl.Payload.
> >
> > Fix the memory leak issue and reset other members in mfxEncodeCtrl.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/qsvenc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> > index 5aa020d47b..029bb562d6 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -1254,7 +1254,7 @@ static int encode_frame(AVCodecContext *avctx,
> > QSVEncContext *q,
> >  if (qsv_frame) {
> >  surf = &qsv_frame->surface;
> >  enc_ctrl = &qsv_frame->enc_ctrl;
> > -memset(enc_ctrl, 0, sizeof(mfxEncodeCtrl));
> > +memset(enc_ctrl, 0, sizeof(mfxEncodeCtrl) - sizeof(mfxPayload **));
> 
> Am I correct that this assumes a particular order of
> contents in a struct not defined within FFmpeg?
> Maybe saving the pointer in a variable and writing
> it back is more future proof?
> 
Yes it's a structure defined in MediaSDK, and will move the memset to the
start of the allocation to avoid this.

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

Re: [FFmpeg-devel] [PATCH, v2] lavu/hwcontext_qsv: Fix the realign check for hwupload

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Thursday, April 11, 2019 10:51
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH, v2] lavu/hwcontext_qsv: Fix the realign
> check for hwupload
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Wednesday, April 10, 2019 7:56 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH, v2] lavu/hwcontext_qsv: Fix the realign
> > check for hwupload
> >
> > Fix the aligned check in hwupload, input surface should be 16 aligned too.
> >
> > Fix #7830.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >
> >  libavutil/hwcontext_qsv.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c index
> > b6d8bfe2bf..8b000fe636 100644
> > --- a/libavutil/hwcontext_qsv.c
> > +++ b/libavutil/hwcontext_qsv.c
> > @@ -892,7 +892,8 @@ static int
> > qsv_transfer_data_to(AVHWFramesContext *ctx, AVFrame *dst,
> >  return ret;
> >
> >
> > -if (src->height & 16 || src->linesize[0] & 16) {
> > +if (src->height & 15 || src->width & 15 ||
> > +src->linesize[0] & 15) {
> 
> Should be better to use FFALIGN()
> 
> Another question is it really necessary to check width alignment if we already
> checked linesize to fix this issue?
> (I guess it it not necessary, and if it is needed, many other places probably
> needed to be changed too.)

Checked the code in qsvvpp.c and qsvenc.c, it has the same check using &:

libavcodec/qsvenc.c: if ((frame->height & 31 || frame->linesize[0] & 
(q->width_align - 1)) ||
libavfilter/qsvvpp.c:if (picref->height & 31 || picref->linesize[0] & 
31) {

These should be matched, so the FFALIGN is better for all?

For the width check, added for redundant check, can be removed to match the 
whole behavior.

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

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

Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: Fix the memory leak for enc_ctrl.Payload

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Thursday, April 11, 2019 11:14
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: Fix the memory leak
> for enc_ctrl.Payload
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Wednesday, April 10, 2019 7:27 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH 1/2] lavc/qsvenc: Fix the memory leak for
> > enc_ctrl.Payload
> >
> > frame->enc_ctrl.Payload is malloced in get_free_frame, directly memset
> > the whole structure of enc_ctrl to zero will cause the memory leak for
> > enc_ctrl.Payload.
> >
> > Fix the memory leak issue and reset other members in mfxEncodeCtrl.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/qsvenc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> > 5aa020d47b..029bb562d6 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -1254,7 +1254,7 @@ static int encode_frame(AVCodecContext *avctx,
> > QSVEncContext *q,
> >  if (qsv_frame) {
> >  surf = &qsv_frame->surface;
> >  enc_ctrl = &qsv_frame->enc_ctrl;
> > -memset(enc_ctrl, 0, sizeof(mfxEncodeCtrl));
> > +memset(enc_ctrl, 0, sizeof(mfxEncodeCtrl) - sizeof(mfxPayload
> > + **));
> 
> Looks a little tricky, if someone didn't read carefully the sequence of
> mfxPayload usages, they can't know why this change happening.
> And potential risk for other elements such as "mfxExtBuffer** ExtParam" is
> still existed.
> 
> IMHO, one good habit is that is you want to memset a buffer, would better
> memset it when you allocate it.
> So I believe the correct fix should be: memset mfxEncodeCtrl at the start of
> qsv frame allocated: the place should be in the function get_free_frame()

frame->enc_ctrl  as a structure will be malloc and init to zero by calling 
frame = av_mallocz(sizeof(*frame)),
the memset may be redundant and can be removed in my opinion.
 

___
ffmpeg-devel mailing list
ffmpeg-devel@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 5/6] vaapi_encode: Add ROI support

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, March 13, 2019 08:18
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2 5/6] vaapi_encode: Add ROI support
> 
> ---
>  libavcodec/vaapi_encode.c   | 128
> 
>  libavcodec/vaapi_encode.h   |  11 +++
>  libavcodec/vaapi_encode_h264.c  |   2 +
>  libavcodec/vaapi_encode_h265.c  |   2 +
>  libavcodec/vaapi_encode_mpeg2.c |   2 +
>  libavcodec/vaapi_encode_vp8.c   |   2 +
>  libavcodec/vaapi_encode_vp9.c   |   2 +
>  7 files changed, 149 insertions(+)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 2dda451882..03a7f5ce3e 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -143,6 +143,7 @@ static int vaapi_encode_issue(AVCodecContext
> *avctx,
>  int err, i;
>  char data[MAX_PARAM_BUFFER_SIZE];
>  size_t bit_len;
> +AVFrameSideData *sd;
> 
>  av_log(avctx, AV_LOG_DEBUG, "Issuing encode for
> pic %"PRId64"/%"PRId64" "
> "as type %s.\n", pic->display_order, pic->encode_order,
> @@ -412,6 +413,91 @@ static int vaapi_encode_issue(AVCodecContext
> *avctx,
>  }
>  }
> 
> +sd = av_frame_get_side_data(pic->input_image,
> +AV_FRAME_DATA_REGIONS_OF_INTEREST);
> +
> +#if VA_CHECK_VERSION(1, 0, 0)
> +if (sd && ctx->roi_allowed) {
> +const AVRegionOfInterest *roi;
> +int nb_roi;
> +VAEncMiscParameterBuffer param_misc = {
> +.type = VAEncMiscParameterTypeROI,
> +};
> +VAEncMiscParameterBufferROI param_roi;
> +// VAAPI requires the second structure to immediately follow the
> +// first in the parameter buffer, but they have different natural
> +// alignment on 64-bit architectures (4 vs. 8, since the ROI
> +// structure contains a pointer).  This means we can't make a
> +// single working structure, nor can we make the buffer
> +// separately and map it because dereferencing the second pointer
> +// would be undefined.  Therefore, construct the two parts
> +// separately and combine them into a single character buffer
> +// before uploading.
> +char param_buffer[sizeof(param_misc) + sizeof(param_roi)];
> +int i, v;

How about using packed attribute to cope with this? Like:
struct {
VAEncMiscParameterBuffer misc;
VAEncMiscParameterBufferROI param_roi;
 } __attribute__((packed)) mfs_params;

This happens a lot during vaapi feature development, like 
MaxFrameSize:
struct {
VAEncMiscParameterBuffer misc;
VAEncMiscParameterBufferMultiPassFrameSize mfs;
} __attribute__((packed)) mfs_params;
Trellis: (currently waiting for bug fix in libva)
 https://patchwork.ffmpeg.org/patch/11733/

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add support for maxframesize

[Fu, Linjie]

> -Original Message-
> From: myp...@gmail.com [mailto:myp...@gmail.com]
> Sent: Tuesday, April 23, 2019 13:42
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h264: add support
> for maxframesize
> 
> On Tue, Apr 23, 2019 at 11:29 AM Linjie Fu  wrote:
> >
> > Add support for max frame size:
> > - max_frame_size (bytes) to indicate the allowed max frame size.
> > - pass_num to indicate number of passes.
> > - delta_qp to indicate adjust qp value.
> >
> > Currently only AVC encoder can support this settings in multiple pass case.
> > If the frame size exceeds, the encoder will do more pak passes to adjust
> the
> > QP value to control the frame size.
> >
> > Set Default num_passes to 4 (1~4), set delta_qp[4] = {1, 1, 1, 1}, use
> > new_qp for encoder if frame size exceeds the limitation:
> > new_qp = base_qp + delta_qp[0] + delta_qp[1] + ...
> >
> > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
> > -v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
> > -c:v h264_vaapi -profile:v main -g 30 -bf 3 -max_frame_size 4 \
> > -pass_num 2 -delta_qp 2 -vframes 100 -y ./max_frame_size.h264
> >
> Some question list as follow：
> 
> 1. Can I change delta_qp per pass, e,g, 4 pass 1, 2, 3, 4, use
> delta_qp[4] like: 1, 2, 4, 8?

Yes, it's available. 
Actually I considered this whether to expose the detailed settings for the user,
And end up with current solution:
- setting max_frame_size only
will use default 4 passes with delta_qp = {1, 1, 1, 1}
- setting max_frame_size with detailed pass_num and delta_qp
Can be customized by user.
Not splitting delta_qp setting for each pass is trying to make it easier for 
users.

> 2. So let's think about the limiting case, if we setting
> max_frame_size = 1 for 1080P, what's the action for this driver?

Maybe the commit message is a little bit confusing,
driver will adjust add delta_qp to original qp to decrease the frame size for 
each pass:
new_qp = base_qp + delta_qp[0]
If the frame size is still too big, will try 2 passes
new_qp = base_qp + delta_qp[0] + delta_qp[1]
If the frame size is still too big  after 4 passes qp modification, driver will 
use max qp allowed by the sum of delta_qp;
new_qp = base_qp + delta_qp[0] + delta_qp[1] + delta_qp[2] + 
delta_qp[3] 

> 3. Maybe we can hide the pass_num and delta_qp, only export the
> max_frame_size for this case?  I don't think export the driver QP
> adjustment detail  logic to user space is good idea, user will
> confused about to how to set/adjust pass_num/delta_qp per pass.

Similar with 1, I think a  default path with a valuable set of parameters(Needs 
advice), together with a customizing method is good.

> 4. Missing docs

Will refine the commit message, and a doc if still needed.

> 5. What's the relationship about other bit rate control like VBR or MBBRC ?

IMHO, max frame size will modify the qp value set by bit rate control methods, 
and trying to meet the size limitation for each frame.

> 6. Only 264 encoder support this feature? What platform have you tested?

Yes, only AVC encoder can be supported by iHD driver, and tested in KBL.
 

Thanks for the comment.
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".

Re: [FFmpeg-devel] [PATCH 3/3, v5] lavc/vaapi_decode: add profile_parser to find the exact va_profile

[Fu, Linjie]

> -Original Message-
> From: Fu, Linjie
> Sent: Monday, April 29, 2019 01:53
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [PATCH 3/3,v5] lavc/vaapi_decode: add profile_parser to find the
> exact va_profile
> 
> Add function pointer field in vaapi_profile_map[], set profile_parser
> for HEVC_REXT to find the exact va_profile.
> 
> Signed-off-by: Linjie Fu 
> ---
> SPS range extension fields should be passed to decoder, will use
> VAPictureParameterBufferHEVCExtension consist of base and rext.
> 
>  libavcodec/vaapi_decode.c | 71 ++-
>  1 file changed, 41 insertions(+), 30 deletions(-)
> 
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index 69512e1d45..7c9cfbc0ed 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -24,7 +24,7 @@
>  #include "decode.h"
>  #include "internal.h"
>  #include "vaapi_decode.h"
> -
> +#include "vaapi_hevc.h"
> 
>  int ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
>VAAPIDecodePicture *pic,
> @@ -364,39 +364,44 @@ static const struct {
>  enum AVCodecID codec_id;
>  int codec_profile;
>  VAProfile va_profile;
> +VAProfile (*profile_parser)(AVCodecContext *avctx);
>  } vaapi_profile_map[] = {
> -#define MAP(c, p, v) { AV_CODEC_ID_ ## c, FF_PROFILE_ ## p, VAProfile ##
> v }
> -MAP(MPEG2VIDEO,  MPEG2_SIMPLE,MPEG2Simple ),
> -MAP(MPEG2VIDEO,  MPEG2_MAIN,  MPEG2Main   ),
> -MAP(H263,UNKNOWN, H263Baseline),
> -MAP(MPEG4,   MPEG4_SIMPLE,MPEG4Simple ),
> +#define MAP(c, p, v, f) { AV_CODEC_ID_ ## c, FF_PROFILE_ ## p, VAProfile
> ## v, f}
> +MAP(MPEG2VIDEO,  MPEG2_SIMPLE,MPEG2Simple , NULL ),
> +MAP(MPEG2VIDEO,  MPEG2_MAIN,  MPEG2Main   , NULL ),
> +MAP(H263,UNKNOWN, H263Baseline, NULL ),
> +MAP(MPEG4,   MPEG4_SIMPLE,MPEG4Simple , NULL ),
>  MAP(MPEG4,   MPEG4_ADVANCED_SIMPLE,
> -   MPEG4AdvancedSimple),
> -MAP(MPEG4,   MPEG4_MAIN,  MPEG4Main   ),
> +   MPEG4AdvancedSimple, NULL ),
> +MAP(MPEG4,   MPEG4_MAIN,  MPEG4Main   , NULL ),
>  MAP(H264,H264_CONSTRAINED_BASELINE,
> -   H264ConstrainedBaseline),
> -MAP(H264,H264_MAIN,   H264Main),
> -MAP(H264,H264_HIGH,   H264High),
> +   H264ConstrainedBaseline, NULL ),
> +MAP(H264,H264_MAIN,   H264Main, NULL ),
> +MAP(H264,H264_HIGH,   H264High, NULL ),
>  #if VA_CHECK_VERSION(0, 37, 0)
> -MAP(HEVC,HEVC_MAIN,   HEVCMain),
> -MAP(HEVC,HEVC_MAIN_10,HEVCMain10  ),
> +MAP(HEVC,HEVC_MAIN,   HEVCMain, NULL ),
> +MAP(HEVC,HEVC_MAIN_10,HEVCMain10  , NULL ),
> +#endif
> +#if VA_CHECK_VERSION(1, 2, 0)
> +MAP(HEVC,HEVC_REXT,   None,
> +  ff_vaapi_parse_rext_profile),
>  #endif
>  MAP(MJPEG,   MJPEG_HUFFMAN_BASELINE_DCT,
> -  JPEGBaseline),
> -MAP(WMV3,VC1_SIMPLE,  VC1Simple   ),
> -MAP(WMV3,VC1_MAIN,VC1Main ),
> -MAP(WMV3,VC1_COMPLEX, VC1Advanced ),
> -MAP(WMV3,VC1_ADVANCED,VC1Advanced ),
> -MAP(VC1, VC1_SIMPLE,  VC1Simple   ),
> -MAP(VC1, VC1_MAIN,VC1Main ),
> -MAP(VC1, VC1_COMPLEX, VC1Advanced ),
> -MAP(VC1, VC1_ADVANCED,VC1Advanced ),
> -MAP(VP8, UNKNOWN,   VP8Version0_3 ),
> +  JPEGBaseline, NULL ),
> +MAP(WMV3,VC1_SIMPLE,  VC1Simple   , NULL ),
> +MAP(WMV3,VC1_MAIN,VC1Main , NULL ),
> +MAP(WMV3,VC1_COMPLEX, VC1Advanced , NULL ),
> +MAP(WMV3,VC1_ADVANCED,VC1Advanced , NULL ),
> +MAP(VC1, VC1_SIMPLE,  VC1Simple   , NULL ),
> +MAP(VC1, VC1_MAIN,VC1Main , NULL ),
> +MAP(VC1, VC1_COMPLEX, VC1Advanced , NULL ),
> +MAP(VC1, VC1_ADVANCED,VC1Advanced , NULL ),
> +MAP(VP8, UNKNOWN,   VP8Version0_3 , NULL ),
>  #if VA_CHECK_VERSION(0, 38, 0)
> -MAP(VP9, VP9_0,   VP9Profile0 ),
> +MAP(VP9, VP9_0,   VP9Profile0 , NULL ),
>  #endif
>  #if VA_CHECK_VERSION(0, 39, 0)
> -MAP(VP9, VP9_2,   VP9Profile2 ),
> +MAP(VP9, VP9_2,   VP9Profile2 , NULL ),
>  #endif
&g

Re: [FFmpeg-devel] [PATCH] vaapi_encode: Refactor encode misc parameter buffer creation

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Monday, May 6, 2019 23:21
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: [FFmpeg-devel] [PATCH] vaapi_encode: Refactor encode misc
> parameter buffer creation
> 
> This removes the use of the nonstandard combined structures, which
> generated some warnings with clang and will cause alignment problems
> with some parameter buffer types.
> ---
> On 27/03/2019 14:18, Carl Eugen Hoyos wrote:
> > Attached patch fixes many warnings when compiling vaapi with clang.
> > Also tested with clang-3.4.
> > ...
> 
> How about this approach instead?  I think something like it is going to be
> needed anyway because of alignment problems with parameter structures
> which aren't yet used.
> 
> - Mark
> 
> 
>  libavcodec/vaapi_encode.c  | 71 --
>  libavcodec/vaapi_encode.h  | 23 +++
>  libavcodec/vaapi_encode_h264.c |  8 ++--
>  3 files changed, 60 insertions(+), 42 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 2dda451882..95031187df 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -103,6 +103,29 @@ static int
> vaapi_encode_make_param_buffer(AVCodecContext *avctx,
>  return 0;
>  }
> 
> +static int vaapi_encode_make_misc_param_buffer(AVCodecContext
> *avctx,
> +   VAAPIEncodePicture *pic,
> +   int type,
> +   const void *data, size_t len)
> +{
> +// Construct the buffer on the stack - 1KB is much larger than any
> +// current misc parameter buffer type (the largest is EncQuality at
> +// 224 bytes).
> +uint8_t buffer[1024];
> +VAEncMiscParameterBuffer header = {
> +.type = type,
> +};
> +size_t buffer_size = sizeof(header) + len;
> +av_assert0(buffer_size <= sizeof(buffer));
> +
> +memcpy(buffer, &header, sizeof(header));
> +memcpy(buffer + sizeof(header), data, len);
> +
> +return vaapi_encode_make_param_buffer(avctx, pic,
> +  VAEncMiscParameterBufferType,
> +  buffer, buffer_size);
> +}
> +
>  static int vaapi_encode_wait(AVCodecContext *avctx,
>   VAAPIEncodePicture *pic)
>  {
> @@ -212,10 +235,10 @@ static int vaapi_encode_issue(AVCodecContext
> *avctx,
> 
>  if (pic->type == PICTURE_TYPE_IDR) {
>  for (i = 0; i < ctx->nb_global_params; i++) {
> -err = vaapi_encode_make_param_buffer(avctx, pic,
> - 
> VAEncMiscParameterBufferType,
> - 
> (char*)ctx->global_params[i],
> - ctx->global_params_size[i]);
> +err = vaapi_encode_make_misc_param_buffer(avctx, pic,
> +  
> ctx->global_params_type[i],
> +  ctx->global_params[i],
> +  
> ctx->global_params_size[i]);
>  if (err < 0)
>  goto fail;
>  }
> @@ -1034,14 +1057,14 @@ int ff_vaapi_encode2(AVCodecContext *avctx,
> AVPacket *pkt,
>  return AVERROR(ENOSYS);
>  }
> 
> -static av_cold void vaapi_encode_add_global_param(AVCodecContext
> *avctx,
> -  VAEncMiscParameterBuffer 
> *buffer,
> -  size_t size)
> +static av_cold void vaapi_encode_add_global_param(AVCodecContext
> *avctx, int type,
> +  void *buffer, size_t size)
>  {
>  VAAPIEncodeContext *ctx = avctx->priv_data;
> 
>  av_assert0(ctx->nb_global_params < MAX_GLOBAL_PARAMS);
> 
> +ctx->global_params_type[ctx->nb_global_params] = type;
>  ctx->global_params [ctx->nb_global_params] = buffer;
>  ctx->global_params_size[ctx->nb_global_params] = size;
> 
> @@ -1575,8 +1598,7 @@ rc_mode_found:
> rc_bits_per_second, rc_window_size);
>  }
> 
> -ctx->rc_params.misc.type = VAEncMiscParameterTypeRateControl;
> -ctx->rc_params.rc = (VAEncMiscParameterRateControl) {
> +ctx->rc_params = (VAEncMiscParameterRateControl) {
>  .bits_per_second= rc_bits_per_second,
>  .target_percentage  = rc_target_percentage,
>  .window_size= rc_window_size,
> @@ -1591,7 +1613,9 @@ rc_mode_found:
>  .quality_factor = rc_quality,
>  #endif
>  };
> -vaapi_encode_add_global_param(avctx, &ctx->rc_params.misc,
> +vaapi_encode_add_global_param(avctx,
> +  VAEncMiscParameterTypeRateCo

Re: [FFmpeg-devel] [PATCH 1/3] avutil: Add NV24 and NV42 pixel formats

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Sunday, May 12, 2019 06:25
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] avutil: Add NV24 and NV42 pixel
> formats
> 
> Am Sa., 11. Mai 2019 um 20:32 Uhr schrieb Philip Langdale
> :
> >
> > These are the 4:4:4 variants of the semi-planar NV12/NV21 formats.
> >
> > These formats are not used much, so we've never had a reason to add
> > them until now. VDPAU recently added support HEVC 4:4:4 content
> > and when you use the OpenGL interop, the returned surfaces are in
> 
> I wonder if there is an "only" missing somewhere.
> 
> > NV24 format, so we need the pixel format for media players, even
> > if there's no direct use within ffmpeg.
> 
> Thank you!
> 
> > Separately, there are apparently webcams that use NV24, but I've
> > never seen one.
> 
> [...]
> 
> > diff --git a/libavutil/version.h b/libavutil/version.h
> > index c0968de621..4922e267cc 100644
> > --- a/libavutil/version.h
> > +++ b/libavutil/version.h
> > @@ -80,7 +80,7 @@
> >
> >  #define LIBAVUTIL_VERSION_MAJOR  56
> >  #define LIBAVUTIL_VERSION_MINOR  26
> > -#define LIBAVUTIL_VERSION_MICRO 101
> > +#define LIBAVUTIL_VERSION_MICRO 102
> 
> We typically raise minor for new pix_fmts, resetting
> micro was forgotten the last times afaict.
> 

Hi,

I'm working on adding support for HEVC 4:2:2/ 4:4:4, 8/10 bit, in vaapi 
decoding.
And I'm aslo thinking of add some new pix_fmt for packed FourCC:
444 8 bit :  AYUV
444 10 bit: Y410 
422 10 bit: Y210

So if I'd like to add these new pix_fmts, some modification is necessary too as 
far as I got from relevant threads:
1. add support in swscale for being able to convert to and from a format, 
including up and down scale;
2. add test.(maybe a query is needed too)
3. bump a new minor version.
Any other concerns should be followed?

I'm trying to make sure I understood this correctly.
Thanks in advance.

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

Re: [FFmpeg-devel] [PATCH 1/3] avutil: Add NV24 and NV42 pixel formats

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Sunday, May 12, 2019 18:45
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] avutil: Add NV24 and NV42 pixel
> formats
> 
> Am So., 12. Mai 2019 um 05:38 Uhr schrieb Fu, Linjie :
> 
> > I'm working on adding support for HEVC 4:2:2/ 4:4:4, 8/10 bit, in vaapi
> decoding.
> > And I'm aslo thinking of add some new pix_fmt for packed FourCC:
> > 444 8 bit :  AYUV
> > 444 10 bit: Y410
> > 422 10 bit: Y210
> 
> Do I understand correctly that for 420 8 bit, vaapi produces the
> decoded image in a planar format but for 444 8 bit (and 10 bit),
> you decided that a packed format makes more sense?
> (Aren't luma and chroma stored independently in hevc?)
> 

It's true that for 420 8 bit, the decoded image is in planar format.
But as to 444 8 bit(and 10 bit), as far as I know in  media driver , the 
decoded image is produced in packed format.
See:
https://github.com/intel/media-driver/blob/8773ef5e82e8a151e1bcfef317f7808f319c91c2/media_driver/linux/gen11/ddi/media_libva_caps_g11.cpp#L842

else if(profile == VAProfileHEVCMain444 || profile == 
VAProfileVP9Profile1)
{
attribs[i].type = VASurfaceAttribPixelFormat;
attribs[i].value.type = VAGenericValueTypeInteger;
attribs[i].flags = VA_SURFACE_ATTRIB_GETTABLE | 
VA_SURFACE_ATTRIB_SETTABLE;
attribs[i].value.value.i = VA_FOURCC_AYUV;
i++;
}

> Note that no matter what you do with the decoded image, there
> will be a (measurable) performance hit because of the needed
> transformation into something (planar) that other filters and
> encoders understand.

Agree, the directly decoded format is better. 
And it's also one of the reasons I'd like to add these packed formats.

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] [PATCH] lavc/vaapi_hevc: extend parameter buffer to ParameterBufferHEVCExtension

[Fu Linjie]

Extend ParameterBufferHEVC to ParameterBufferHEVCExtension for both
VAPicture and VASlice.

Pass Range Extension flags to support the decode for HEVC REXT.

Separate the behaviour of ff_vaapi_decode_make_slice_buffer for base and
rext to avoid potential regression.

Signed-off-by: Fu Linjie 
---
 libavcodec/vaapi_hevc.c | 134 
 1 file changed, 112 insertions(+), 22 deletions(-)

diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
index c69d63d..f0b6f8e 100644
--- a/libavcodec/vaapi_hevc.c
+++ b/libavcodec/vaapi_hevc.c
@@ -29,8 +29,13 @@
 #include "vaapi_decode.h"
 
 typedef struct VAAPIDecodePictureHEVC {
+#if VA_CHECK_VERSION(1, 2, 0)
+VAPictureParameterBufferHEVCExtension pic_param;
+VASliceParameterBufferHEVCExtension last_slice_param;
+#else
 VAPictureParameterBufferHEVC pic_param;
 VASliceParameterBufferHEVC last_slice_param;
+#endif
 const uint8_t *last_buffer;
 size_t last_size;
 
@@ -116,12 +121,17 @@ static int vaapi_hevc_start_frame(AVCodecContext  
*avctx,
 const HEVCSPS  *sps = h->ps.sps;
 const HEVCPPS  *pps = h->ps.pps;
 
+#if VA_CHECK_VERSION(1, 2, 0)
+VAPictureParameterBufferHEVC *pic_param = &pic->pic_param.base;
+#else
+VAPictureParameterBufferHEVC *pic_param = &pic->pic_param;
+#endif
+
 const ScalingList *scaling_list = NULL;
 int err, i;
 
 pic->pic.output_surface = ff_vaapi_get_surface_id(h->ref->frame);
-
-pic->pic_param = (VAPictureParameterBufferHEVC) {
+*pic_param = (VAPictureParameterBufferHEVC) {
 .pic_width_in_luma_samples= sps->width,
 .pic_height_in_luma_samples   = sps->height,
 .log2_min_luma_coding_block_size_minus3   = sps->log2_min_cb_size 
- 3,
@@ -188,26 +198,54 @@ static int vaapi_hevc_start_frame(AVCodecContext  
*avctx,
 },
 };
 
-fill_vaapi_pic(&pic->pic_param.CurrPic, h->ref, 0);
-fill_vaapi_reference_frames(h, &pic->pic_param);
+fill_vaapi_pic(&pic_param->CurrPic, h->ref, 0);
+fill_vaapi_reference_frames(h, pic_param);
 
 if (pps->tiles_enabled_flag) {
-pic->pic_param.num_tile_columns_minus1 = pps->num_tile_columns - 1;
-pic->pic_param.num_tile_rows_minus1= pps->num_tile_rows - 1;
+pic_param->num_tile_columns_minus1 = pps->num_tile_columns - 1;
+pic_param->num_tile_rows_minus1= pps->num_tile_rows - 1;
 
 for (i = 0; i < pps->num_tile_columns; i++)
-pic->pic_param.column_width_minus1[i] = pps->column_width[i] - 1;
-
+pic_param->column_width_minus1[i] = pps->column_width[i] - 1;
 for (i = 0; i < pps->num_tile_rows; i++)
-pic->pic_param.row_height_minus1[i] = pps->row_height[i] - 1;
+pic_param->row_height_minus1[i] = pps->row_height[i] - 1;
 }
 
 if (h->sh.short_term_ref_pic_set_sps_flag == 0 && h->sh.short_term_rps) {
-pic->pic_param.st_rps_bits = h->sh.short_term_ref_pic_set_size;
+pic_param->st_rps_bits = h->sh.short_term_ref_pic_set_size;
 } else {
-pic->pic_param.st_rps_bits = 0;
+pic_param->st_rps_bits = 0;
 }
 
+#if VA_CHECK_VERSION(1, 2, 0)
+if (sps->sps_range_extension_flag) {
+pic->pic_param.rext = (VAPictureParameterBufferHEVCRext) {
+.range_extension_pic_fields.bits  = {
+.transform_skip_rotation_enabled_flag   = 
sps->transform_skip_rotation_enabled_flag,
+.transform_skip_context_enabled_flag= 
sps->transform_skip_context_enabled_flag,
+.implicit_rdpcm_enabled_flag= 
sps->implicit_rdpcm_enabled_flag,
+.explicit_rdpcm_enabled_flag= 
sps->explicit_rdpcm_enabled_flag,
+.extended_precision_processing_flag = 
sps->extended_precision_processing_flag,
+.intra_smoothing_disabled_flag  = 
sps->intra_smoothing_disabled_flag,
+.high_precision_offsets_enabled_flag= 
sps->high_precision_offsets_enabled_flag,
+.persistent_rice_adaptation_enabled_flag= 
sps->persistent_rice_adaptation_enabled_flag,
+.cabac_bypass_alignment_enabled_flag= 
sps->cabac_bypass_alignment_enabled_flag,
+.cross_component_prediction_enabled_flag= 
pps->cross_component_prediction_enabled_flag,
+.chroma_qp_offset_list_enabled_flag = 
pps->chroma_qp_offset_list_enabled_flag,
+},
+.diff_cu_chroma_qp_offset_depth = 
pps->diff_cu_chroma_qp_offset_depth,
+.chroma_qp_offset_list_len_minus1   = 
pps->chroma_qp_

[FFmpeg-devel] [PATCH] lavc/vp9_superframe_bsf: avoid error messages in one line

[Fu Linjie]

Add "\n" to avoid continuous error messages in one line.

Signed-off-by: Fu Linjie 
---
 libavcodec/vp9_superframe_bsf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vp9_superframe_bsf.c b/libavcodec/vp9_superframe_bsf.c
index ea67507..23933d4 100644
--- a/libavcodec/vp9_superframe_bsf.c
+++ b/libavcodec/vp9_superframe_bsf.c
@@ -133,7 +133,7 @@ static int vp9_superframe_filter(AVBSFContext *ctx, 
AVPacket *out)
 
 if (uses_superframe_syntax && s->n_cache > 0) {
 av_log(ctx, AV_LOG_ERROR,
-   "Mixing of superframe syntax and naked VP9 frames not 
supported");
+   "Mixing of superframe syntax and naked VP9 frames not 
supported\n");
 res = AVERROR(ENOSYS);
 goto done;
 } else if ((!invisible || uses_superframe_syntax) && !s->n_cache) {
@@ -142,7 +142,7 @@ static int vp9_superframe_filter(AVBSFContext *ctx, 
AVPacket *out)
 goto done;
 } else if (s->n_cache + 1 >= MAX_CACHE) {
 av_log(ctx, AV_LOG_ERROR,
-   "Too many invisible frames");
+   "Too many invisible frames\n");
 res = AVERROR_INVALIDDATA;
 goto done;
 }
-- 
2.7.4

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

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

Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: reinit if the resolution changes little

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Friday, February 22, 2019 10:40
> To: Li, Zhong ; FFmpeg development discussions and
> patches 
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: reinit if the resolution
> changes little
> 
> > -Original Message-
> > From: Li, Zhong
> > Sent: Thursday, February 21, 2019 17:53
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Cc: Fu, Linjie 
> > Subject: RE: [FFmpeg-devel] [PATCH] lavc/qsvdec: reinit if the resolution
> > changes little
> >
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > > Of Linjie Fu
> > > Sent: Wednesday, February 13, 2019 6:00 PM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Fu, Linjie 
> > > Subject: [FFmpeg-devel] [PATCH] lavc/qsvdec: reinit if the resolution
> > changes
> > > little
> > >
> > > Currently, resolution change detection is based on 16 alignment, small
> > > resolution changes (same after FFALIGN 16) in coded width or coded
> height
> > > will not trigger the reinit and will lead to a decode failure.
> > >
> > > Modify to use last_coded_width and last_coded_height to detect the
> small
> > > resolution change.
> > >
> > > Signed-off-by: Linjie Fu 
> >
> > Is it still needed if https://patchwork.ffmpeg.org/patch/12112/ applied?
> 
> Garbage still exists after applying the patch set.
> Will comment under patch 12112.

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

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/vf_vpp_qsv: add transpose support for QSV VPP

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Monday, March 18, 2019 13:35
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Mark Thompson 
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavf/vf_vpp_qsv: add transpose
> support for QSV VPP
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Mark Thompson
> > Sent: Sunday, March 17, 2019 21:59
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavf/vf_vpp_qsv: add transpose
> > support for QSV VPP
> >
> > On 15/03/2019 16:34, Linjie Fu wrote:
> > > Add transpose support for qsv_vpp:
> > > - rotation: [0, 3] support clockwise rotation of 0, 90, 180, 270;
> > > - mirror:   [0, 1] support horizontal mirroring;
> > >
> > > ffmpeg -hwaccel qsv -v verbose -c:v h264_qsv -i input.h264
> > > -vf 'format=qsv,vpp_qsv=rotation=1' -c:v h264_qsv output.h264
> > > ffmpeg -hwaccel qsv -v verbose -c:v h264_qsv -i input.h264
> > > -vf 'format=qsv,vpp_qsv=mirror=1' -c:v h264_qsv output.h264
> > > ffmpeg -hwaccel qsv -v verbose -c:v h264_qsv -i input.h264
> > > -vf 'format=qsv,vpp_qsv=rotation=2,vpp_qsv=mirror=1' -c:v h264_qsv
> > output.h264
> > >
> > > Signed-off-by: Linjie Fu 
> > > ---
> > >  libavfilter/vf_vpp_qsv.c | 45
> > ++--
> > >  1 file changed, 43 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> > > index 41a9f38962..edbe944321 100644
> > > --- a/libavfilter/vf_vpp_qsv.c
> > > +++ b/libavfilter/vf_vpp_qsv.c
> > > @@ -41,7 +41,9 @@
> > >  #define FLAGS (AV_OPT_FLAG_VIDEO_PARAM |
> > AV_OPT_FLAG_FILTERING_PARAM)
> > >
> > >  /* number of video enhancement filters */
> > > -#define ENH_FILTERS_COUNT (5)
> > > +#define ENH_FILTERS_COUNT (7)
> > > +#define QSV_HAVE_ROTATION  QSV_VERSION_ATLEAST(1, 17)
> > > +#define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
> > >
> > >  typedef struct VPPContext{
> > >  const AVClass *class;
> > > @@ -54,6 +56,8 @@ typedef struct VPPContext{
> > >  mfxExtVPPDenoise denoise_conf;
> > >  mfxExtVPPDetail detail_conf;
> > >  mfxExtVPPProcAmp procamp_conf;
> > > +mfxExtVPPRotation rotation_conf;
> > > +mfxExtVPPMirroring mirroring_conf;
> > >
> > >  int out_width;
> > >  int out_height;
> > > @@ -70,6 +74,9 @@ typedef struct VPPContext{
> > >  int crop_x;
> > >  int crop_y;
> > >
> > > +int rotation;   /* rotation mode : 0=0, 1=90, 2=180, 
> > > 3=270 */
> > > +int mirror; /* mirror mode : 0=off, 1=HORIZONTAL */
> > > +
> > >  /* param for the procamp */
> > >  intprocamp;/* enable procamp */
> > >  float  hue;
> > > @@ -95,6 +102,9 @@ static const AVOption options[] = {
> > >  { "contrast","ProcAmp contrast", OFFSET(contrast),
> > AV_OPT_TYPE_FLOAT,{ .dbl = 1.0 }, 0.0, 10.0, .flags = FLAGS},
> > >  { "brightness",  "ProcAmp brightness",   OFFSET(brightness),
> > AV_OPT_TYPE_FLOAT,{ .dbl = 0.0 }, -100.0, 100.0, .flags = FLAGS},
> > >
> > > +{ "rotation","clockwise rotation: 90 * [0, 3]", OFFSET(rotation),
> > AV_OPT_TYPE_INT,  { .i64 = 0 }, 0, 3, .flags = FLAGS},
> > > +{ "mirror",  "horizontal mirror [0, 1]",OFFSET(mirror),
> > AV_OPT_TYPE_INT,  { .i64 = 0 }, 0, 1, .flags = FLAGS},
> >
> > Please use the same names as other filters doing transpose/rotate
> > operations.
> >
> Is it acceptable updating the names into "rotate" and "hflip" separately?
> Or they should be combined into "transpose" like vaapi_transpose does?
> >
> > I think there should be something to make the default behaviour for the
> > cases where you would expect the axes to be swapped to do that.  It
> would
> > be surprising for rotating a portait 1080x1920 input to produce a squashed
> > 1080x1920 output rather than 1920x1080.
> 
> Thanks, will add FFSWAP(int, vpp->out_width, vpp->out_height) to swap
> width
> and height for clock/cclock rotation.

Ping for the updated patch?
https://patchwork.ffmpeg.org/patch/12351/

___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavc/qsvenc: Fix the memory leak for enc_ctrl.Payload

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Monday, April 29, 2019 17:00
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: Fix the memory leak
> for enc_ctrl.Payload
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Monday, April 15, 2019 9:23 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH, v2] lavc/qsvenc: Fix the memory leak for
> > enc_ctrl.Payload
> >
> > frame->enc_ctrl.Payload is malloced in get_free_frame, directly memset
> > the whole structure of enc_ctrl to zero will cause the memory leak for
> > enc_ctrl.Payload.
> >
> > frame->enc_ctrl as a structure will be malloc and init to zero by
> > frame->calling
> > frame = av_mallocz(sizeof(*frame)), so the memset is redundant and can
> be
> > removed.
> >
> > Can be reproduced by #7830.
> 
> Patch LGTM now, but I can't see strong relationship between this patch and
> tikect #7830.
> IMHO this is a quite common issue even if you use qsv transcoding pipeline?

Yes, it's not strongly related with the issue. Remove this would be fine.
Thanks.

> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/qsvenc.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> > 5aa020d47b..19953bd4ea 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -1254,7 +1254,6 @@ static int encode_frame(AVCodecContext *avctx,
> > QSVEncContext *q,
> >  if (qsv_frame) {
> >  surf = &qsv_frame->surface;
> >  enc_ctrl = &qsv_frame->enc_ctrl;
> > -memset(enc_ctrl, 0, sizeof(mfxEncodeCtrl));
> >
> >  if (frame->pict_type == AV_PICTURE_TYPE_I) {
> >  enc_ctrl->FrameType = MFX_FRAMETYPE_I |
> > MFX_FRAMETYPE_REF;
> > --
> > 2.17.1

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

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: disable ICQ mode when enabling low power

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Wednesday, May 22, 2019 09:49
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: disable ICQ mode
> when enabling low power
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Wednesday, May 22, 2019 4:31 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: disable ICQ mode
> > when enabling low power
> >
> > ICQ mode is not supported in low power mode and should be disabled.
> >
> > For H264, Driver supports RC modes CQP, CBR, VBR, QVBR.
> > For HEVC, Driver supports RC modes CQP, CBR, VBR, ICQ, QVBR.
> >
> > ICQ is not exposed while working on low power mode for h264_vaapi, but
> > will trigger issues for hevc_vaapi.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > See https://github.com/intel/media-driver/issues/618 for details.
> > And patch for HEVC low power(ICL+):
> > https://github.com/intel-media-ci/ffmpeg/pull/42
> >
> >  libavcodec/vaapi_encode.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c index
> > 2dda451..55ab919 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -1371,6 +1371,7 @@ static av_cold int
> > vaapi_encode_init_rate_control(AVCodecContext *avctx)
> >  // * If bitrate and maxrate are set and have the same value, try CBR.
> >  // * If a bitrate is set, try AVBR, then VBR, then CBR.
> >  // * If no bitrate is set, try ICQ, then CQP.
> > +// * If low power is set, ICQ is not supported.
> >
> >  #define TRY_RC_MODE(mode, fail) do { \
> >  rc_mode = &vaapi_encode_rc_modes[mode]; \ @@ -1405,7
> > +1406,8 @@ static av_cold int
> > vaapi_encode_init_rate_control(AVCodecContext *avctx)
> >  TRY_RC_MODE(RC_MODE_QVBR, 0);
> >
> >  if (avctx->global_quality > 0) {
> > -TRY_RC_MODE(RC_MODE_ICQ, 0);
> > +if (!ctx->low_power)
> > +TRY_RC_MODE(RC_MODE_ICQ, 0);
> >  TRY_RC_MODE(RC_MODE_CQP, 0);
> >  }
> >
> > @@ -1417,7 +1419,8 @@ static av_cold int
> > vaapi_encode_init_rate_control(AVCodecContext *avctx)
> >  TRY_RC_MODE(RC_MODE_VBR, 0);
> >  TRY_RC_MODE(RC_MODE_CBR, 0);
> >  } else {
> > -TRY_RC_MODE(RC_MODE_ICQ, 0);
> > +if (!ctx->low_power)
> > +TRY_RC_MODE(RC_MODE_ICQ, 0);
> 
> Is it possible ICQ mode can be supported in future (new driver/HW version)?
> I would like to see avoid hard-coded workaround.
> If there is any driver limitation, would better to query driver capability 
> firstly
> and then disable a feature if it is not supported.

You are right, hard-coded should be avoided.
As to this, if ICQ mode is not supported by low_power mode, it shouldn't have
returned such support in the query for LP va_entrypoint.

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

Re: [FFmpeg-devel] [PATCH] lavf/qsvvpp: avoid the double-free when working in sys memory mode

[Fu, Linjie]

> -Original Message-
> From: Fu, Linjie
> Sent: Monday, April 15, 2019 21:24
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [PATCH] lavf/qsvvpp: avoid the double-free when working in sys
> memory mode
> 
> Currently, picref will be freed by calling av_frame_free(&picref) in
> submit_frame() in qsvvpp.c when working in system memory mode,and
> normally it
> is freed in filter_frame() in vf_vpp_qsv.c when working in other modes.
> 
> Double free happens when working in system memory mode, remove to
> fix the memory issue.
> 
> Signed-off-by: Linjie Fu 
> ---
> Can be reproduced by applying the system memory patch and qsvdec+vpp:
> ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -c:v h264_qsv -i
> input.mp4 \
> -vf "vpp_qsv=w=960:h=540,format=rgb32" -f 
> null -
>  libavfilter/qsvvpp.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index 06efdf5089..5cd1d5d345 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -316,7 +316,6 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
> AVFilterLink *inlink, AVFrame *p
>  }
> 
>  av_frame_copy_props(qsv_frame->frame, picref);
> -av_frame_free(&picref);
>  } else
>  qsv_frame->frame = av_frame_clone(picref);
> 
> --
> 2.17.1
Ping?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Thursday, May 30, 2019 07:17
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: grow packet if
> vaMapBuffer returns multiple buffers
> 
> On 29/05/2019 21:57, Linjie Fu wrote:
> > It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to
> map
> > buffer for each slice.
> >
> > Currently, assigning new buffer for pkt when multiple buffer returns
> > from vaMapBuffer will cover the previous encoded pkt data and lead
> > to encode issues.
> >
> > Using av_grow_packet to expand pkt if several buffers are returned.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/vaapi_encode.c | 12 ++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> What driver uses this?

It was found while enabling VP9 VDENC on ICL with iHD.
vaMapBuffer returns two bufs in the buf_list including a zero-sized buf.

IMHO, it should be fixed in driver level, but I guess ffmpeg should be able to 
cope with the multiple buf situation as well.

https://github.com/intel/media-driver/issues/624
> 
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index 2dda451..2812237 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -490,6 +490,7 @@ static int vaapi_encode_output(AVCodecContext
> *avctx,
> >  VACodedBufferSegment *buf_list, *buf;
> >  VAStatus vas;
> >  int err;
> > +uint8_t *ptr;
> >
> >  err = vaapi_encode_wait(avctx, pic);
> >  if (err < 0)
> > @@ -509,11 +510,18 @@ static int vaapi_encode_output(AVCodecContext
> *avctx,
> >  av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes "
> > "(status %08x).\n", buf->size, buf->status);
> >
> > -err = av_new_packet(pkt, buf->size);
> > +if (pkt->size)
> > +err = av_grow_packet(pkt, buf->size);
> 
> av_grow_packet() can reallocate the buffer, which will change its address.
> 
> To avoid repeated new allocations and copies, perhaps it would be better to
> iterate through the list first to find out how large the single packet needs 
> to
> be?

Avoiding repeated memcpy and reallocation sounds better to me.
Thanks Mark.

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

Re: [FFmpeg-devel] [PATCH] lavf/qsvvpp: avoid the double-free when working in sys memory mode

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Li, Zhong
> Sent: Thursday, May 30, 2019 13:15
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavf/qsvvpp: avoid the double-free
> when working in sys memory mode
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Fu, Linjie
> > Sent: Wednesday, May 29, 2019 5:08 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] lavf/qsvvpp: avoid the double-free
> > when working in sys memory mode
> >
> > > -Original Message-
> > > From: Fu, Linjie
> > > Sent: Monday, April 15, 2019 21:24
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Fu, Linjie 
> > > Subject: [PATCH] lavf/qsvvpp: avoid the double-free when working in
> > > sys memory mode
> > >
> > > Currently, picref will be freed by calling av_frame_free(&picref) in
> > > submit_frame() in qsvvpp.c when working in system memory mode,and
> > > normally it is freed in filter_frame() in vf_vpp_qsv.c when working in
> > > other modes.
> > >
> > > Double free happens when working in system memory mode, remove to
> fix
> > > the memory issue.
> > >
> > > Signed-off-by: Linjie Fu 
> > > ---
> > > Can be reproduced by applying the system memory patch and
> qsvdec+vpp:
> > > ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -c:v h264_qsv
> > > -i
> > > input.mp4 \
> > > -vf
> > "vpp_qsv=w=960:h=540,format=rgb32"
> 
> Is it possible to reproduce with another command line? It can work with
> mainline on Linux.

vpp_qsv with system software path could reproduce this with mainline version:

ffmpeg -init_hw_device qsv=foo -filter_hw_device foo -v debug -f rawvideo 
-pix_fmt nv12 -s:v 852x480 -i 852x480.nv12 -vf 'vpp_qsv=w=500:h=400' -f 
rawvideo -pix_fmt nv12 qsv.nv12

This happens when the size of the input stream is not 32 aligned and has more 
than 1 frames.

> > > -f null -  libavfilter/qsvvpp.c | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c index
> > > 06efdf5089..5cd1d5d345 100644
> > > --- a/libavfilter/qsvvpp.c
> > > +++ b/libavfilter/qsvvpp.c
> > > @@ -316,7 +316,6 @@ static QSVFrame *submit_frame(QSVVPPContext
> > *s,
> > > AVFilterLink *inlink, AVFrame *p
> > >  }
> > >
> > >  av_frame_copy_props(qsv_frame->frame, picref);
> > > -av_frame_free(&picref);
> > >  } else
> > >  qsv_frame->frame = av_frame_clone(picref);
> > >
> > > --
> > > 2.17.1
> > Ping?
> 
> Patch 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, v2 1/2] lavf/qsvvpp: allocate continuous memory

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Friday, May 31, 2019 17:20
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate
> continuous memory
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Thursday, May 30, 2019 1:01 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate continuous
> > memory
> >
> > Mediasdk calls CMRT to copy from video to system memory and requires
> > memory to be continuously allocated across Y and UV.
> >
> > Add a new path to allocate continuous memory when using system out.
> > Use av_image_fill_pointers to arrange data according to pixfmt.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > [v2]: use av_image_fill_pointers
> >
> >  libavfilter/qsvvpp.c | 32 +++-
> >  1 file changed, 27 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c index
> > 06efdf5089..6eeed7e632 100644
> > --- a/libavfilter/qsvvpp.c
> > +++ b/libavfilter/qsvvpp.c
> > @@ -27,6 +27,7 @@
> >  #include "libavutil/hwcontext_qsv.h"
> >  #include "libavutil/time.h"
> >  #include "libavutil/pixdesc.h"
> > +#include "libavutil/imgutils.h"
> >
> >  #include "internal.h"
> >  #include "qsvvpp.h"
> > @@ -51,6 +52,7 @@ struct QSVVPPContext {
> >  enum AVPixelFormat  out_sw_format;   /* Real output format */
> >  mfxVideoParam   vpp_param;
> >  mfxFrameInfo   *frame_infos; /* frame info for each
> > input */
> > +AVBufferPool   *pool;
> >
> >  /* members related to the input/output surface */
> >  int in_mem_mode;
> > @@ -375,10 +377,24 @@ static QSVFrame *query_frame(QSVVPPContext
> > *s, AVFilterLink *outlink)
> >  out_frame->surface = (mfxFrameSurface1
> > *)out_frame->frame->data[3];
> >  } else {
> >  /* Get a frame with aligned dimensions.
> > - * Libmfx need system memory being 128x64 aligned */
> > -out_frame->frame = ff_get_video_buffer(outlink,
> > -
> > FFALIGN(outlink->w, 128),
> > -
> > FFALIGN(outlink->h, 64));
> > + * Libmfx need system memory being 128x64 aligned
> > + * and continuously allocated across Y and UV */
> > +out_frame->frame = av_frame_alloc();
> > +if (!out_frame->frame) {
> > +return NULL;
> 
> Should be better to return AVERROR(ENOMEM)?

Will refine.

> 
> > +}
> > +
> > +out_frame->frame->linesize[0] = FFALIGN(outlink->w, 128);
> > +out_frame->frame->linesize[1] = out_frame->frame->linesize[0];
> > +out_frame->frame->buf[0]  = av_buffer_pool_get(s->pool);
> > +out_frame->frame->format  = outlink->format;
> > +
> > +if (!out_frame->frame->buf[0])
> > +return NULL;
> 
> Same as frame alloc.

Will refine.

> 
> > +
> > +av_image_fill_pointers(out_frame->frame->data,
> > out_frame->frame->format,
> > +FFALIGN(outlink->h, 64),
> > out_frame->frame->buf[0]->data,
> > +
> > + out_frame->frame->linesize);
> >  if (!out_frame->frame)
> >  return NULL;
> >
> > @@ -483,8 +499,13 @@ static int init_vpp_session(AVFilterContext *avctx,
> > QSVVPPContext *s)
> >
> >  av_buffer_unref(&outlink->hw_frames_ctx);
> >  outlink->hw_frames_ctx = out_frames_ref;
> > -} else
> > +} else {
> >  s->out_mem_mode = MFX_MEMTYPE_SYSTEM_MEMORY;
> > +s->pool =
> > av_buffer_pool_init(av_image_get_buffer_size(outlink->format,
> > +
> > FFALIGN(outlink->w, 128),
> > +
> > FFALIGN(outlink->h, 64), 1),
> > +av_buffer_allocz);
> 
> 1. What is the benefit to use a pool? Comparing with directly alloc a buffer
> use av_buffer_allocz()?
Directly allocate seems to be better.

> 2. av_buffer_allocz() will memset the whole buffer and make performance
> drop. Is it really necessary here?
>   If no (I believe so), just use av_buffer_alloc()
I' not quite sure whether the non-initialized padding data introduced by
the alignment will cause some potential run2run issues if we do encoding next.
But as the usages in lavu/frame.c and lavc/avpacket.c, av_buffer_alloc() is 
enough.

Will refine and send a new version today.

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

Re: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate continuous memory

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Monday, June 3, 2019 13:28
> To: Fu, Linjie ; FFmpeg development discussions and
> patches 
> Subject: RE: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate
> continuous memory
> 
> 
> 
> > -----Original Message-
> > From: Fu, Linjie
> > Sent: Monday, June 3, 2019 1:17 PM
> > To: Li, Zhong ; FFmpeg development discussions and
> > patches 
> > Subject: RE: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate
> > continuous memory
> >
> > > -Original Message-
> > > From: Li, Zhong
> > > Sent: Friday, May 31, 2019 17:20
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Cc: Fu, Linjie 
> > > Subject: RE: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate
> > > continuous memory
> > >
> > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > Behalf
> > > > Of Linjie Fu
> > > > Sent: Thursday, May 30, 2019 1:01 AM
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Cc: Fu, Linjie 
> > > > Subject: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate
> > > > continuous memory
> > > >
> > > > Mediasdk calls CMRT to copy from video to system memory and
> requires
> > > > memory to be continuously allocated across Y and UV.
> > > >
> > > > Add a new path to allocate continuous memory when using system out.
> > > > Use av_image_fill_pointers to arrange data according to pixfmt.
> > > >
> > > > Signed-off-by: Linjie Fu 
> > > > ---
> > > > [v2]: use av_image_fill_pointers
> > > >
> > > >  libavfilter/qsvvpp.c | 32 +++-
> > > >  1 file changed, 27 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c index
> > > > 06efdf5089..6eeed7e632 100644
> > > > --- a/libavfilter/qsvvpp.c
> > > > +++ b/libavfilter/qsvvpp.c
> > > > @@ -27,6 +27,7 @@
> > > >  #include "libavutil/hwcontext_qsv.h"
> > > >  #include "libavutil/time.h"
> > > >  #include "libavutil/pixdesc.h"
> > > > +#include "libavutil/imgutils.h"
> > > >
> > > >  #include "internal.h"
> > > >  #include "qsvvpp.h"
> > > > @@ -51,6 +52,7 @@ struct QSVVPPContext {
> > > >  enum AVPixelFormat  out_sw_format;   /* Real output format
> > */
> > > >  mfxVideoParam   vpp_param;
> > > >  mfxFrameInfo   *frame_infos; /* frame info for each
> > > > input */
> > > > +AVBufferPool   *pool;
> > > >
> > > >  /* members related to the input/output surface */
> > > >  int in_mem_mode;
> > > > @@ -375,10 +377,24 @@ static QSVFrame
> > *query_frame(QSVVPPContext *s,
> > > > AVFilterLink *outlink)
> > > >  out_frame->surface = (mfxFrameSurface1
> > > > *)out_frame->frame->data[3];
> > > >  } else {
> > > >  /* Get a frame with aligned dimensions.
> > > > - * Libmfx need system memory being 128x64 aligned */
> > > > -out_frame->frame = ff_get_video_buffer(outlink,
> > > > -
> > > > FFALIGN(outlink->w, 128),
> > > > -
> > > > FFALIGN(outlink->h, 64));
> > > > + * Libmfx need system memory being 128x64 aligned
> > > > + * and continuously allocated across Y and UV */
> > > > +out_frame->frame = av_frame_alloc();
> > > > +if (!out_frame->frame) {
> > > > +return NULL;
> > >
> > > Should be better to return AVERROR(ENOMEM)?
> >
> > Will refine.
> >
> > >
> > > > +}
> > > > +
> > > > +out_frame->frame->linesize[0] = FFALIGN(outlink->w, 128);
> > > > +out_frame->frame->linesize[1] =
> > out_frame->frame->linesize[0];
> > > > +out_frame->frame->buf[0]  =
> > av_buffer_pool_get(s->pool);
> > > > +out_frame->frame->format  = outlink->format;
> > > > +
> > > > +if (!out_frame->frame->buf[0])
> > > > +return NULL;
> > >
> > > Same as frame alloc.
> >
> > Will refine.

Thinking about this again, I see all return values for error handling in 
submit_frame
and query_frame is NULL.
So I prefer to keep this to match the whole behavior in qsvvpp.c, or we can send
another patch to replace them all.

> > > 1. What is the benefit to use a pool? Comparing with directly alloc a
> > > buffer use ()?
> > Directly allocate seems to be better.
> 
> I am thinking using av_frame_get_buffer() will make life easier or not.
> It can make sure memory continuous and call av_buffer_alloc() and
> av_image_fill_pointers() internally.

It works in continuously allocating memory,  but will the padded_height be a 
constraint? 
In get_video_buffer(), padded_height is aligned by 32 in hard-coded way,
But 64 alignment is needed.

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

Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers

[Fu, Linjie]

> -Original Message-
> From: Fu, Linjie
> Sent: Friday, May 31, 2019 08:35
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [PATCH,v2] lavc/vaapi_encode: grow packet if vaMapBuffer returns
> multiple buffers
> 
> It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to map
> buffer for each slice.
> 
> Currently, assigning new buffer for pkt when multiple buffer returns
> from vaMapBuffer will cover the previous encoded pkt data and lead
> to encode issues.
> 
> Iterate through the buf_list first to find out the total buffer size
> needed for the pkt, allocate the whole pkt to avoid repeated reallocation
> and memcpy, then copy data from each buf to pkt.
> 
> Signed-off-by: Linjie Fu 
> ---
> [v2]: allocate the whole pkt to avoid repeated reallocation
> and memcpy
> 
>  libavcodec/vaapi_encode.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 2dda451..9c9e5dd 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -489,6 +489,8 @@ static int vaapi_encode_output(AVCodecContext
> *avctx,
>  VAAPIEncodeContext *ctx = avctx->priv_data;
>  VACodedBufferSegment *buf_list, *buf;
>  VAStatus vas;
> +int total_size = 0;
> +uint8_t *ptr;
>  int err;
> 
>  err = vaapi_encode_wait(avctx, pic);
> @@ -505,15 +507,21 @@ static int vaapi_encode_output(AVCodecContext
> *avctx,
>  goto fail;
>  }
> 
> +for (buf = buf_list; buf; buf = buf->next)
> +total_size += buf->size;
> +
> +err = av_new_packet(pkt, total_size);
> +ptr = pkt->data;
> +
> +if (err < 0)
> +goto fail_mapped;
> +
>  for (buf = buf_list; buf; buf = buf->next) {
>  av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes "
> "(status %08x).\n", buf->size, buf->status);
> 
> -err = av_new_packet(pkt, buf->size);
> -if (err < 0)
> -goto fail_mapped;
> -
> -memcpy(pkt->data, buf->buf, buf->size);
> +memcpy(ptr, buf->buf, buf->size);
> +ptr += buf->size;
>  }
> 
>  if (pic->type == PICTURE_TYPE_IDR)
> --
> 2.7.4

Ping?
This can fix the encoding issue for vaapi_vp8:
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -v verbose -f rawvideo 
-pix_fmt yuv420p -s:v 1280x720 -i ./input_I420.yuv -vf 'format=nv12,hwupload' 
-c:v vp8_vaapi -rc_mode CQP -g 1 -global_quality 14 -loop_filter_sharpness 0 
-loop_filter_level 0 -vframes 10 -y out.ivf
___
ffmpeg-devel mailing list
ffmpeg-devel@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, RFC] lavc/vp9dec: fix the multi-thread HWAccel decode error

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Tuesday, June 11, 2019 15:50
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, RFC] lavc/vp9dec: fix the multi-thread
> HWAccel decode error
> 
> On Tue, Jun 11, 2019 at 9:20 AM Linjie Fu  wrote:
> >
> > Fix the multi-thread HWAccel decode error for vp9.
> >
> > VP9 supports the resolution changing. In multi-thread mode, worker-
> threads
> > destroy and free the first created VAAPIDecodeContext if resolution
> change
> > happens and create new one. Other threads still request to destroy
> previous
> > and demand for new context. This leads to decode failures and memory
> issue.
> >
> > Modify to call hwaccel_uninit/hwaccel_init by ff_thread_get_format only
> > when the first-come thread detected the resolution changing.
> >
> 
> s->gf_fmt, s->w and s->h are updated through
> vp9_decode_update_thread_context, wouldn't they prevent
> re-initialization already, as long as the size only changes once?
> If not, why not? Perhaps thats a better avenue to fix it, then hacky
> conditions like this one.
> 

Thanks Hendrik, need to reconsider this and seek for a better solution.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavc/vaapi_encode: add support for AVC Trellis

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Thursday, June 13, 2019 06:37
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: add support for
> AVC Trellis
> 
> On 12/06/2019 16:28, Linjie Fu wrote:
> > Add support for VAAPI AVC Trellis Quantization with limitation:
> > - VA-API version >= (1, 0, 0)
> >
> > Use option "-trellis off/I/P/B" to disable or enable Trellis
> > quantization for I/P/B frames.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > [v2]: Since nonstandard struct for VAEncMiscParameterQuantization is
> > fixed: https://github.com/intel/libva/issues/265
> 
> Should the version check be for the first release this fix is in rather than 
> for
> libva 2.0, then?

I've been thinking about the concerns before, too.
Since the nonstandard structure is supported more robustly, uint32_t data[]
in misc now can be point to the uint64_t quantization and make this feature
valid.
The remaining concern is that using  a uint32_t pointer to point a uint64_t one 
(should be uint32_t) which
is not functional. 
So I choose to check the version libva 2.0  which supported Trellis for the 
first time to support
more libva version.

Will update the version check to libva 2.5 to eliminate all concerns if it's 
more acceptable.

> 
> > update patch based on:
> >
> http://git.ffmpeg.org/gitweb/ffmpeg.git/commit/2880a32c668023bfee47450
> 95c885450d547ae45
> >  libavcodec/vaapi_encode.c  | 48
> ++
> >  libavcodec/vaapi_encode.h  |  9 +--
> >  libavcodec/vaapi_encode_h264.c |  9 +++
> >  3 files changed, 64 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index dd2a24de04..fbfbe78c6b 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -1671,6 +1671,48 @@ rc_mode_found:
> >  return 0;
> >  }
> >
> > +static av_cold int vaapi_encode_init_quantization(AVCodecContext
> *avctx)
> > +{
> > +#if VA_CHECK_VERSION(1, 0, 0)
> > +VAAPIEncodeContext *ctx = avctx->priv_data;
> > +VAStatus vas;
> > +VAConfigAttrib attr = { VAConfigAttribEncQuantization };
> > +int trellis = ctx->trellis;
> 
> This variable isn't really doing anything.
Yep, trying to match the behavior with quality but since this variable is not 
frequently
used, ctx->trellis seems to be enough.

> 
> > +
> > +vas = vaGetConfigAttributes(ctx->hwctx->display,
> > +ctx->va_profile,
> > +ctx->va_entrypoint,
> > +&attr, 1);
> > +if (vas != VA_STATUS_SUCCESS) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to query quantization "
> > +   "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> > +return AVERROR_EXTERNAL;
> > +}
> > +
> > +if (attr.value == VA_ATTRIB_NOT_SUPPORTED ||
> > +attr.value == VA_ENC_QUANTIZATION_NONE) {
> > +av_log(avctx, AV_LOG_WARNING, "Special Quantization attribute is
> not "
> > +"supported: will use default quantization.\n");
> > +} else if (attr.value == VA_ENC_QUANTIZATION_TRELLIS_SUPPORTED){
> > +av_log(avctx, AV_LOG_VERBOSE, "Quantization Trellis supported.\n");
> > +
> > +ctx->quantization_params = (VAEncMiscParameterQuantization) {
> > +.quantization_flags.value = trellis,
> > +};
> > +
> > +vaapi_encode_add_global_param(avctx,
> > +  VAEncMiscParameterTypeQuantization,
> > +  &ctx->quantization_params,
> > +  sizeof(ctx->quantization_params));
> > +}
> > +#else
> > +av_log(avctx, AV_LOG_WARNING, "The encode quantization option
> (Trellis) is "
> > +   "not supported with this VAAPI version.\n");
> > +#endif
> > +
> > +return 0;
> > +}
> > +
> >  static av_cold int vaapi_encode_init_gop_structure(AVCodecContext
> *avctx)
> >  {
> >  VAAPIEncodeContext *ctx = avctx->priv_data;
> > @@ -2132,6 +2174,12 @@ av_cold int
> ff_vaapi_encode_init(AVCodecContext *avctx)
> >  if (err < 0)
> >  goto fail;
> >
> > +if (ctx->trellis) {
> > +err = vaapi_encode_init_quantization(avctx);
> > +if (err < 0)
> > +goto fail;
> > +}
> > +
> >  if (avctx->compression_level >= 0) {
> >  err = vaapi_encode_init_quality(avctx);
> >  if (err < 0)
> > diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> > index eeec06036b..b24735da59 100644
> > --- a/libavcodec/vaapi_encode.h
> > +++ b/libavcodec/vaapi_encode.h
> > @@ -37,7 +37,7 @@ struct VAAPIEncodePicture;
> >
> >  enum {
> >  MAX_CONFIG_ATTRIBUTES  = 4,
> > -MAX_GLOBAL_PARAMS  = 4,
> > +MAX_GLOBAL_PARAMS  = 5,
> >  MAX_DPB_SIZE   = 16,
> >  MAX_PICTURE_REFERENCES = 2,
> >

Re: [FFmpeg-devel] [PATCH, v3] lavf/qsvvpp:allocate continuous memory

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Friday, June 14, 2019 11:34
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH,v3] lavf/qsvvpp:allocate continuous
> memory
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Tuesday, June 4, 2019 11:59 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH,v3] lavf/qsvvpp:allocate continuous
> > memory
> >
> > Mediasdk calls CMRT to copy from video to system memory and requires
> > memory to be continuously allocated across Y and UV.
> >
> > Add a new path to allocate continuous memory when using system out.
> > Use av_frame_get_buffer to arrange data according to pixfmt, and remove
> > the introduced plane_padding.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavfilter/qsvvpp.c | 26 --
> >  1 file changed, 20 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c index
> > 5cd1d5d345..c06171444f 100644
> > --- a/libavfilter/qsvvpp.c
> > +++ b/libavfilter/qsvvpp.c
> > @@ -350,7 +350,7 @@ static QSVFrame *query_frame(QSVVPPContext *s,
> > AVFilterLink *outlink)  {
> >  AVFilterContext *ctx = outlink->src;
> >  QSVFrame*out_frame;
> > -int  ret;
> > +int  i, ret;
> >
> >  clear_unused_frames(s->out_frame_list);
> >
> > @@ -374,12 +374,26 @@ static QSVFrame *query_frame(QSVVPPContext
> > *s, AVFilterLink *outlink)
> >  out_frame->surface = (mfxFrameSurface1
> > *)out_frame->frame->data[3];
> >  } else {
> >  /* Get a frame with aligned dimensions.
> > - * Libmfx need system memory being 128x64 aligned */
> > -out_frame->frame = ff_get_video_buffer(outlink,
> > -
> > FFALIGN(outlink->w, 128),
> > -
> > FFALIGN(outlink->h, 64));
> > -if (!out_frame->frame)
> > + * Libmfx need system memory being 128x64 aligned
> > + * and continuously allocated across Y and UV */
> > +out_frame->frame = av_frame_alloc();
> > +if (!out_frame->frame) {
> >  return NULL;
> > +}
> > +
> > +out_frame->frame->width  = FFALIGN(outlink->w, 128);
> > +out_frame->frame->height = FFALIGN(outlink->h, 64);
> > +out_frame->frame->format = outlink->format;
> > +
> > +ret = av_frame_get_buffer(out_frame->frame, 128);
> > +if (ret < 0)
> > +return NULL;
> > +
> > +/* remove plane_padding introduced by av_frame_get_buffer */
> Should be well explained in the comments why need to reomove.

Tried to explain that continuous memory is need for  libmfx in commit message
and before av_frame_get_buffer was called.

If that's not enough, would you please offer some advices on how to explain 
better?

> 
> > +for (i = 1; i < 4; i++) {
> > +if (out_frame->frame->data[i])
> > +out_frame->frame->data[i] -= i * 128;
> > +}
> 
> Looks like tricky workaround. If padding bytes size changed in
> av_frame_get_buffer, will break qsv vpp.

Calls av_frame_get_buffer-> get_video_buffer could allocate memory at one time 
and
make the code clearer, but will introduce plane_padding:

plane_padding = FFMAX(16 + 16/*STRIDE_ALIGN*/, align);

The padding bytes was initialized by variable "align", and "align" was set to 
128 as a requirement.
So the padding bytes will always be set to align and I think it won't break vpp 
pipeline.

In fact, it's a reverse action of padding_bytes being introduced in 
get_video_buffer():
for (i = 1; i < 4; i++) {
if (frame->data[i])
frame->data[i] += i * plane_padding;
}

To make it more clear and less tricky, I thought 128 can be replaced by 
variable or Macro like:
Int align = plane_padding = 128;
or
#define PLANE_PADDING 128

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

Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: add support for AVC Trellis

[Fu, Linjie]

> -Original Message-
> From: myp...@gmail.com [mailto:myp...@gmail.com]
> Sent: Wednesday, June 12, 2019 16:14
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: add support for
> AVC Trellis
> 
> On Wed, Jun 12, 2019 at 3:28 PM Linjie Fu  wrote:
> >
> > Add support for VAAPI AVC Trellis Quantization with limitation:
> > - VA-API version >= (1, 0, 0)
> >
> > Use option "-trellis off/I/P/B" to disable or enable Trellis
> > quantization for I/P/B frames.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > [v2]: Since nonstandard struct for VAEncMiscParameterQuantization is
> > fixed: https://github.com/intel/libva/issues/265
> > update patch based on:
> >
> http://git.ffmpeg.org/gitweb/ffmpeg.git/commit/2880a32c668023bfee47450
> 95c885450d547ae45
> >  libavcodec/vaapi_encode.c  | 48
> ++
> >  libavcodec/vaapi_encode.h  |  9 +--
> >  libavcodec/vaapi_encode_h264.c |  9 +++
> >  3 files changed, 64 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index dd2a24de04..fbfbe78c6b 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -1671,6 +1671,48 @@ rc_mode_found:
> >  return 0;
> >  }
> >
> > +static av_cold int vaapi_encode_init_quantization(AVCodecContext
> *avctx)
> > +{
> > +#if VA_CHECK_VERSION(1, 0, 0)
> > +VAAPIEncodeContext *ctx = avctx->priv_data;
> > +VAStatus vas;
> > +VAConfigAttrib attr = { VAConfigAttribEncQuantization };
> > +int trellis = ctx->trellis;
> > +
> > +vas = vaGetConfigAttributes(ctx->hwctx->display,
> > +ctx->va_profile,
> > +ctx->va_entrypoint,
> > +&attr, 1);
> > +if (vas != VA_STATUS_SUCCESS) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to query quantization "
> > +   "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> > +return AVERROR_EXTERNAL;
> > +}
> > +
> > +if (attr.value == VA_ATTRIB_NOT_SUPPORTED ||
> > +attr.value == VA_ENC_QUANTIZATION_NONE) {
> > +av_log(avctx, AV_LOG_WARNING, "Special Quantization attribute is
> not "
> > +"supported: will use default quantization.\n");
> > +} else if (attr.value == VA_ENC_QUANTIZATION_TRELLIS_SUPPORTED){
> > +av_log(avctx, AV_LOG_VERBOSE, "Quantization Trellis supported.\n");
> > +
> > +ctx->quantization_params = (VAEncMiscParameterQuantization) {
> > +.quantization_flags.value = trellis,
> > +};
> > +
> > +vaapi_encode_add_global_param(avctx,
> > +  VAEncMiscParameterTypeQuantization,
> > +  &ctx->quantization_params,
> > +  sizeof(ctx->quantization_params));
> > +}
> > +#else
> > +av_log(avctx, AV_LOG_WARNING, "The encode quantization option
> (Trellis) is "
> > +   "not supported with this VAAPI version.\n");
> > +#endif
> > +
> > +return 0;
> > +}
> > +
> >  static av_cold int vaapi_encode_init_gop_structure(AVCodecContext
> *avctx)
> >  {
> >  VAAPIEncodeContext *ctx = avctx->priv_data;
> > @@ -2132,6 +2174,12 @@ av_cold int
> ff_vaapi_encode_init(AVCodecContext *avctx)
> >  if (err < 0)
> >  goto fail;
> >
> > +if (ctx->trellis) {
> > +err = vaapi_encode_init_quantization(avctx);
> > +if (err < 0)
> > +goto fail;
> > +}
> > +
> >  if (avctx->compression_level >= 0) {
> >  err = vaapi_encode_init_quality(avctx);
> >  if (err < 0)
> > diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> > index eeec06036b..b24735da59 100644
> > --- a/libavcodec/vaapi_encode.h
> > +++ b/libavcodec/vaapi_encode.h
> > @@ -37,7 +37,7 @@ struct VAAPIEncodePicture;
> >
> >  enum {
> >  MAX_CONFIG_ATTRIBUTES  = 4,
> > -MAX_GLOBAL_PARAMS  = 4,
> > +MAX_GLOBAL_PARAMS  = 5,
> >  MAX_DPB_SIZE   = 16,
> >  MAX_PICTURE_REFERENCES = 2,
> >  MAX_REORDER_DELA

Re: [FFmpeg-devel] [PATCH, v4 1/2] lavf/qsvvpp:allocate continuous memory

[Fu, Linjie]

From: Max Dmitrichenko [mailto:maxim@gmail.com]
Sent: Tuesday, June 18, 2019 15:06
To: FFmpeg development discussions and patches 
Cc: Fu, Linjie 
Subject: Re: [FFmpeg-devel] [PATCH, v4 1/2] lavf/qsvvpp:allocate continuous 
memory



On Tue, Jun 18, 2019 at 9:52 AM Linjie Fu 
mailto:linjie...@intel.com>> wrote:
Mediasdk calls CMRT to copy from video to system memory and requires
memory to be continuously allocated across Y and UV.

Add a new path to allocate continuous memory when using system out.
Use get_continuous_buffer to arrange data according to pixfmt.

it would be good to keep such continuous allocations consistent with encoder's 
implementation,
see 
https://github.com/FFmpeg/FFmpeg/blob/8f6e65183354d1d402ae80c71cba2759fe152018/libavcodec/qsvenc.c#L1218

if needed, needs to be checked before re-allocation.

Thanks for the advice and I agree consistency is important.
And I’ve thought about the behavior in qsvenc.c as well to make sure the memory 
is continuous.

However, I got some concerns:

1.   av_frame_get_buffer() will introduce plane_padding, and it will lead 
to un-continuous data[0]/data[1];

And the paddings  will lead to wrong offset of U/V, and will cause garbage on 
chroma filed of image. (when using mirror methods)

So I choose to use get_continuous_buffer() which is similar but introduced no 
paddings.

2.   Since here is the first the position to allocate memory for output 
frame, directly allocate a continuous memory seems to be good IMHO.

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

Re: [FFmpeg-devel] [PATCH, RFC] lavc/phtread_frame: update context in child thread in multi-thread mode

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Wednesday, June 26, 2019 15:12
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, RFC] lavc/phtread_frame: update
> context in child thread in multi-thread mode
> 
> On Wed, Jun 26, 2019 at 9:06 AM Linjie Fu  wrote:
> >
> > Currently in ff_thread_decode_frame, context is updated from child
> thread
> > to main thread, and main thread releases the context in avcodec_close()
> > when decode finishes.
> >
> > However, when resolution/format change in vp9, ff_get_format was called,
> > and hwaccel_uninit() and hwaccel_init will be used to destroy and re-
> create
> > the context. Due to the async between main-thread and child-thread,
> > main-thread updated its context from child earlier than the context was
> > refreshed in child-thread. And it will lead to:
> > 1. memory leak in child-thread.
> > 2. double free in main-thread while calling avcodec_close().
> >
> > Can be reproduced with a resolution change case in vp9, and use -vframes
> > to terminate the decode between the dynamic resolution change frames:
> >
> > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v
> > verbose -i ./test2360_1672_4980.ivf -pix_fmt p010le -f rawvideo -vsync
> > passthrough -vframes 6 -y out.yuv
> >
> > Move update_context_from_thread from ff_thread_decode_frame(main
> thread)
> > to frame_worker_thread(child thread), update the context in child thread
> > right after the context was updated to avoid the async issue.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > Request for Comments, not quite familiar with the constraints.
> > Thanks in advance.
> >
> >  libavcodec/internal.h  |   5 ++
> >  libavcodec/pthread_frame.c | 164 --
> ---
> >  2 files changed, 91 insertions(+), 78 deletions(-)
> >
> > diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> > index 5096ffa..9f4ed0b 100644
> > --- a/libavcodec/internal.h
> > +++ b/libavcodec/internal.h
> > @@ -162,6 +162,11 @@ typedef struct AVCodecInternal {
> >
> >  void *thread_ctx;
> >
> > +/**
> > + * Main thread AVCodecContext pointer
> > + */
> > +void *main_thread;
> > +
> >  DecodeSimpleContext ds;
> >  DecodeFilterContext filter;
> >
> > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> > index 36ac0ac..be42e98 100644
> > --- a/libavcodec/pthread_frame.c
> > +++ b/libavcodec/pthread_frame.c
> > @@ -159,82 +159,6 @@ static void async_unlock(FrameThreadContext
> *fctx)
> >  }
> >
> >  /**
> > - * Codec worker thread.
> > - *
> > - * Automatically calls ff_thread_finish_setup() if the codec does
> > - * not provide an update_thread_context method, or if the codec returns
> > - * before calling it.
> > - */
> > -static attribute_align_arg void *frame_worker_thread(void *arg)
> > -{
> > -PerThreadContext *p = arg;
> > -AVCodecContext *avctx = p->avctx;
> > -const AVCodec *codec = avctx->codec;
> > -
> > -pthread_mutex_lock(&p->mutex);
> > -while (1) {
> > -while (atomic_load(&p->state) == STATE_INPUT_READY && !p->die)
> > -pthread_cond_wait(&p->input_cond, &p->mutex);
> > -
> > -if (p->die) break;
> > -
> > -if (!codec->update_thread_context &&
> THREAD_SAFE_CALLBACKS(avctx))
> > -ff_thread_finish_setup(avctx);
> > -
> > -/* If a decoder supports hwaccel, then it must call 
> > ff_get_format().
> > - * Since that call must happen before ff_thread_finish_setup(), the
> > - * decoder is required to implement update_thread_context() and 
> > call
> > - * ff_thread_finish_setup() manually. Therefore the above
> > - * ff_thread_finish_setup() call did not happen and 
> > hwaccel_serializing
> > - * cannot be true here. */
> > -av_assert0(!p->hwaccel_serializing);
> > -
> > -/* if the previous thread uses hwaccel then we take the lock to 
> > ensure
> > - * the threads don't run concurrently */
> > -if (avctx->hwaccel) {
> > -pthread_mutex_lock(&p->parent->hwaccel_mutex);
> > -p->hwaccel_serializing = 1;
> > -}
> > -
> > -av_frame_unref(p->frame);
> > -p->got_frame = 0;
> > -p->result = codec->decode(avctx, p->frame, &p->got_frame, &p-
> >avpkt);
> > -
> > -if ((p->result < 0 || !p->got_frame) && p->frame->buf[0]) {
> > -if (avctx->internal->allocate_progress)
> > -av_log(avctx, AV_LOG_ERROR, "A frame threaded decoder did
> not "
> > -   "free the frame on failure. This is a bug, please 
> > report it.\n");
> > -av_frame_unref(p->frame);
> > -}
> > -
> > -if (atomic_load(&p->state) == STATE_SETTING_UP)
> > -ff_thread_finish_setup(avctx);
> > -
> > -if (p->hwaccel_serializing) {
> > - 

Re: [FFmpeg-devel] [PATCH, RFC, v2] lavc/phtread_frame: update context in child thread in multi-thread mode

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Thursday, June 27, 2019 00:29
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, RFC, v2] lavc/phtread_frame: update
> context in child thread in multi-thread mode
> 
> On Wed, Jun 26, 2019 at 04:24:52PM -0400, Linjie Fu wrote:
> > Currently in ff_thread_decode_frame, context is updated from child
> thread
> > to main thread, and main thread releases the context in avcodec_close()
> > when decode finishes.
> >
> > However, when resolution/format change in vp9, ff_get_format was called,
> > and hwaccel_uninit() and hwaccel_init will be used to destroy and re-
> create
> > the context. Due to the async between main-thread and child-thread,
> > main-thread updated its context from child earlier than the context was
> > refreshed in child-thread. And it will lead to:
> > 1. memory leak in child-thread.
> > 2. double free in main-thread while calling avcodec_close().
> >
> > Can be reproduced with a resolution change case in vp9, and use -vframes
> > to terminate the decode between the dynamic resolution change frames:
> >
> > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v
> > verbose -i ./test2360_1672_4980.ivf -pix_fmt p010le -f rawvideo -vsync
> > passthrough -vframes 6 -y out.yuv
> >
> > Move update_context_from_thread from ff_thread_decode_frame(main
> thread)
> > to frame_worker_thread(child thread), update the context in child thread
> > right after the context was updated to avoid the async issue.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > Request for Comments, not quite familiar with the constraints.
> > Thanks in advance.
> 
> i dont think i fully understand the problem you are trying to fix but
> this patch looks like it writes into the users context without any
> lock while the user can access it.
> Thats looks like a race condition unless I am missing something

Yes that's what I'm concerned and seeking for advice.
One possible way I thought is to add a new lock, and lock in both 
frame_worker_thread
and submit_packet(user) wwhen it attmepts to update context from user to child 
thread.

> What is very noticable though is that you seem to talk about vp9
> why is this vp9 specific and does not affect other codecs ?

Actually it's not codec specific.
It happens as long as context refreshed because of resolution/format change in
child thread but failed to update in main thread correctly.
Same issue exists in h264 as well if decode terminate during resolution changing
(-vframes 45 in this example):

ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v verbose -i 
./reinit-large_420_8-to-small_420_8.h264 -pix_fmt nv12 -f rawvideo -vsync 
passthrough -vframes 45 -y md5.yuv

http://fate-suite.ffmpeg.org/h264/reinit-large_420_8-to-small_420_8.h264
And this patch fixed it as well.

It seems I should not restrict this issue to vp9 in commit message.

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

Re: [FFmpeg-devel] [PATCH 1/5] lavu/pixfmt: add Y210/AYUV/Y410 pixel formats

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Almer
> Sent: Thursday, June 27, 2019 22:33
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/5] lavu/pixfmt: add Y210/AYUV/Y410
> pixel formats
> 
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index 8b54c94..6a6a36a 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -209,6 +209,12 @@ enum AVPixelFormat {
> >
> >  AV_PIX_FMT_YVYU422,   ///< packed YUV 4:2:2, 16bpp, Y0 Cr Y1 Cb
> >
> > +AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr, 
> > little-
> endian
> > +AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr, big-
> endian
> > +AV_PIX_FMT_AYUV,  ///< packed YUV 4:4:4, 32bpp,  A Y Cb Cr
> > +AV_PIX_FMT_Y410LE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A, little-
> endian
> > +AV_PIX_FMT_Y410BE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A, big-
> endian
> 
> This is an ABI break, as you're shifting the enum values for every entry
> under these.
> 
> You need to add new values at the end, right above AV_PIX_FMT_NB.
> 
Oh yes ABI break.
will follow, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH, v3] lavc/pthread_frame: update context in child thread in multi-thread mode

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Thursday, June 27, 2019 20:32
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] lavc/pthread_frame: update
> context in child thread in multi-thread mode
> 
> Am Do., 27. Juni 2019 um 13:56 Uhr schrieb Linjie Fu :
> 
> >  libavcodec/internal.h  |  7 +++
> >  libavcodec/pthread_frame.c | 21 ++---
> >  2 files changed, 25 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> > index 5096ffa..a85 100644
> > --- a/libavcodec/internal.h
> > +++ b/libavcodec/internal.h
> > @@ -162,6 +162,13 @@ typedef struct AVCodecInternal {
> >
> >  void *thread_ctx;
> >
> > +/**
> > + * User thread AVCodecContext pointer and
> > + * context mutex
> > + */
> > +void *user_avctx;
> 
> Sorry if this was already answered:
> Why is this not an AVCodecContext* ?

Followed the behavior of :
void *thread_ctx;
void *frame_thread_encoder

Since it will only be used as AVCodecContext* (not like void *hwaccel_priv_data)
AVCodecContext *user_avctx seems to be more directly.
I'm not strongly insist on this unless there are some other concerns or 
differents.

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

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

Re: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add vaapi_format_map for Y210/AYUV/Y410

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Thursday, June 27, 2019 23:41
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> vaapi_format_map for Y210/AYUV/Y410
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Friday, June 28, 2019 10:27 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> > vaapi_format_map for Y210/AYUV/Y410
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavutil/hwcontext_vaapi.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c index
> > 4227c3c..6378d0e 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -116,6 +116,14 @@ static const VAAPIFormatDescriptor
> > vaapi_format_map[] = {  #endif
> >  MAP(UYVY, YUV422,  UYVY422, 0),
> >  MAP(YUY2, YUV422,  YUYV422, 0),
> > +#ifdef VA_FOURCC_Y210
> > +MAP(Y210, YUV422_10,Y210LE, 0),
> > +#endif
> > +#define VA_RT_FORMAT_AYUV VA_FOURCC_AYUV
> 
> Probably you want to add "#ifdef VA_FOURCC_AYUV" too.

Since VA_FOURCC_AYUV was defined in libva early (same with YUY2 and UYVY 
in commit bd592e38, 2009), I didn't add #ifdef query for AYUV.

> And would better to #undef VA_RT_FORMAT_AYUV here once map is done.
> (If you want to get a longer life cycle, would better define it outside)

I prefer to put the macro #define just ahead of the usage in vaapi_format_map
to make it more directly.
Will add #undef.

> > +MAP(AYUV,   AYUV, AYUV, 0),
> > +#ifdef VA_FOURCC_Y410
> > +MAP(Y410, YUV444_10,Y410LE, 0),
> > +#endif
> >  MAP(411P, YUV411,  YUV411P, 0),
> >  MAP(422V, YUV422,  YUV440P, 0),
> >  MAP(444P, YUV444,  YUV444P, 0),
> > --
> > 2.7.4

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

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

Re: [FFmpeg-devel] [PATCH 4/5] lavc/qsvdec: add ChromaFormat support for YUV422/YUV444

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, June 28, 2019 02:43
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] lavc/qsvdec: add ChromaFormat
> support for YUV422/YUV444
> 
> Am Do., 27. Juni 2019 um 16:31 Uhr schrieb Linjie Fu :
> >
> > Currently, ChromaFormat passed to libmfx is set to YUV42O by default.
> >
> > Modify to choose ChromaFormat according to fourCC.
> 
> Sorry if I misunderstand:
> Doesn't 3/5 depend on this patch?

The whole patch set enables HEVC Rext decode in QSV, and yes 3/5 won't take
effect without 4/5 or 5/5.
It seems I'd better adjust the patch sequence in the patch set according to 
dependency.

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

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

Re: [FFmpeg-devel] [PATCH 4/5] lavc/qsvdec: add ChromaFormat support for YUV422/YUV444

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Friday, June 28, 2019 09:09
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 4/5] lavc/qsvdec: add ChromaFormat
> support for YUV422/YUV444
> 
> On Thu, Jun 27, 2019 at 4:31 PM Linjie Fu  wrote:
> >
> > Currently, ChromaFormat passed to libmfx is set to YUV42O by default.
> >
> > Modify to choose ChromaFormat according to fourCC.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/qsvdec.c | 20 +++-
> >  1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> > index 46aa2d6..7650325 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -40,6 +40,7 @@
> >  #include "qsv.h"
> >  #include "qsv_internal.h"
> >  #include "qsvdec.h"
> > +#include 
> >
> >  const AVCodecHWConfigInternal *ff_qsv_hw_configs[] = {
> >  &(const AVCodecHWConfigInternal) {
> > @@ -211,7 +212,24 @@ static int qsv_decode_init(AVCodecContext *avctx,
> QSVContext *q)
> >  param.mfx.FrameInfo.FourCC = q->fourcc;
> >  param.mfx.FrameInfo.Width  = frame_width;
> >  param.mfx.FrameInfo.Height = frame_height;
> > -param.mfx.FrameInfo.ChromaFormat   =
> MFX_CHROMAFORMAT_YUV420;
> > +
> > +switch (q->fourcc) {
> > +case VA_FOURCC_YUY2:
> > +#ifdef VA_FOURCC_Y210
> > +case VA_FOURCC_Y210:
> > +#endif
> > +param.mfx.FrameInfo.ChromaFormat   =
> MFX_CHROMAFORMAT_YUV422;
> > +break;
> > +case VA_FOURCC_AYUV:
> > +#ifdef VA_FOURCC_Y410
> > +case VA_FOURCC_Y410:
> > +#endif
> > +param.mfx.FrameInfo.ChromaFormat   =
> MFX_CHROMAFORMAT_YUV444;
> > +break;
> > +default:
> > +param.mfx.FrameInfo.ChromaFormat   =
> MFX_CHROMAFORMAT_YUV420;
> > +break;
> > +}
> >
> >  switch (avctx->field_order) {
> >  case AV_FIELD_PROGRESSIVE:
> 
> VA_FOURCC_ sounds like VAAPI, that doesn't seem like it belongs in qsv
> code which is supposed to work on multiple platforms.

Yes,  it should be MFX_FOURCC_.
Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add vaapi_format_map for Y210/AYUV/Y410

[Fu, Linjie]

> -Original Message-
> From: Zhou, Zachary
> Sent: Friday, June 28, 2019 11:33
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> vaapi_format_map for Y210/AYUV/Y410

> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c index
> > 4227c3c..6378d0e 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -116,6 +116,14 @@ static const VAAPIFormatDescriptor
> > vaapi_format_map[] = {  #endif
> >  MAP(UYVY, YUV422,  UYVY422, 0),
> >  MAP(YUY2, YUV422,  YUYV422, 0),
> > +#ifdef VA_FOURCC_Y210
> > +MAP(Y210, YUV422_10,Y210LE, 0),
> > +#endif
> > +#define VA_RT_FORMAT_AYUV VA_FOURCC_AYUV
> > +MAP(AYUV,   AYUV, AYUV, 0),
> > +#ifdef VA_FOURCC_Y410
> > +MAP(Y410, YUV444_10,Y410LE, 0),
> > +#endif
> >  MAP(411P, YUV411,  YUV411P, 0),
> >  MAP(422V, YUV422,  YUV440P, 0),
> >  MAP(444P, YUV444,  YUV444P, 0),
> > --
> 
> are you also considering to add Y210/AYUV/Y410 support in
> vaapi_drm_format_map in libavutil/hwcontext_vaapi.c ?
> 
It could be added in vaapi_drm_format_map, however is not quite relevant with
the enabling of HEVC Rext decoding.
Maybe a separate patch can be sent and not include in this patch set.

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

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate hw_frames_ctx without destroy va_context

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Sunday, July 7, 2019 19:51
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate
> hw_frames_ctx without destroy va_context
> 
> On 07/07/2019 17:38, Linjie Fu wrote:
> > VP9 allows resolution changes per frame. Currently in VAAPI, resolution
> > changes leads to va context destroy and reinit.
> 
> Which is correct - it needs to remake the context because the old one is for
> the wrong resolution.

It seems that we don't need to remake context, remaking the surface is enough
for resolution changing.
Currently in libva, surface is able to be recreated separately without remaking 
context.
And this way is used in libyami to cope with resolution changing cases.

> 
> > This will cause
> > reference frame surface lost and produce garbage.
> 
> This isn't right - the reference frame surfaces aren't lost.  See
> VP9Context.s.refs[], which holds references to the frames (including their
> hardware frame contexts) until the stream indicates that they can be
> discarded by overwriting their reference frame slots.

I'm not quite sure about this, at least the result shows they are not used 
correctly
in current way. 
Will look deeper into it.

> 
> > As libva allows re-create surface separately without changing the
> > context, this issue could be handled by only recreating hw_frames_ctx.
> >
> > Could be verified by:
> > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
> > ./resolutions.ivf
> > -pix_fmt p010le -f rawvideo -vframes 20 -y vaapi.yuv
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/decode.c   |  8 
> >  libavcodec/vaapi_decode.c | 40 ++
> --
> >  2 files changed, 26 insertions(+), 22 deletions(-)
> >
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index 0863b82..a81b857 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -1254,7 +1254,6 @@ int
> ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
> >
> >  frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
> >
> > -
> >  if (frames_ctx->initial_pool_size) {
> >  // We guarantee 4 base work surfaces. The function above guarantees
> 1
> >  // (the absolute minimum), so add the missing count.
> > @@ -1333,7 +1332,7 @@ static int hwaccel_init(AVCodecContext *avctx,
> >  return AVERROR_PATCHWELCOME;
> >  }
> >
> > -if (hwaccel->priv_data_size) {
> > +if (hwaccel->priv_data_size && !avctx->internal->hwaccel_priv_data) {
> >  avctx->internal->hwaccel_priv_data =
> >  av_mallocz(hwaccel->priv_data_size);
> >  if (!avctx->internal->hwaccel_priv_data)
> > @@ -1397,8 +1396,9 @@ int ff_get_format(AVCodecContext *avctx, const
> enum AVPixelFormat *fmt)
> >
> >  for (;;) {
> >  // Remove the previous hwaccel, if there was one.
> > -hwaccel_uninit(avctx);
> > -
> > +// VAAPI allows reinit hw_frames_ctx only
> > +if (choices[0] != AV_PIX_FMT_VAAPI_VLD)
> 
> Including codec-specific conditions in the generic code suggests that
> something very shady is going on.

Yes, will try to avoid this.

> > +hwaccel_uninit(avctx);>  user_choice = avctx-
> >get_format(avctx, choices);
> >  if (user_choice == AV_PIX_FMT_NONE) {
> >  // Explicitly chose nothing, give up.
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index 69512e1..13f0cf0 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -613,8 +613,10 @@ int ff_vaapi_decode_init(AVCodecContext *avctx)
> >  VAStatus vas;
> >  int err;
> >
> > -ctx->va_config  = VA_INVALID_ID;
> > -ctx->va_context = VA_INVALID_ID;
> > +if (!ctx->va_config && !ctx->va_context){
> > +ctx->va_config  = VA_INVALID_ID;
> > +ctx->va_context = VA_INVALID_ID;
> > +}
> >
> >  #if FF_API_STRUCT_VAAPI_CONTEXT
> >  if (avctx->hwaccel_context) {
> > @@ -642,7 +644,6 @@ int ff_vaapi_decode_init(AVCodecContext *avctx)
> >  // present, so set it here to avoid the behaviour changing.
> >  ctx->hwctx->driver_quirks =
> >  AV_VAAPI_DRIVER_QUIRK_RENDER_PARAM_BUFFERS;
> > -
> >  }
> >  #endif
> >
> > @@ -655,7 +656,8 @@ int ff_vaapi_decode_init(AVCodecContext *avctx)
> > "context: %#x/%#x.\n", ctx->va_config, ctx->va_context);
> >  } else {
> >  #endif
> > -
> > +// Get a new hw_frames_ctx even if there is already one
> > +// recreate surface without reconstuct va_context
> >  err = ff_decode_get_hw_frames_ctx(avctx,
> AV_HWDEVICE_TYPE_VAAPI);
> >  if (err < 0)
> >  goto fail;
> > @@ -670,21 +672,23 @@ int ff_vaapi_decode_init(AVCodecContext *avctx)
> >  if (err)
> >  goto fail;
> >
> > -vas = vaCrea

Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate hw_frames_ctx without destroy va_context

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Sunday, July 7, 2019 15:39
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate
> hw_frames_ctx without destroy va_context
> 
> On Sun, Jul 7, 2019 at 6:41 AM Linjie Fu  wrote:
> >
> > VP9 allows resolution changes per frame. Currently in VAAPI, resolution
> > changes leads to va context destroy and reinit. This will cause
> > reference frame surface lost and produce garbage.
> >
> > As libva allows re-create surface separately without changing the
> > context, this issue could be handled by only recreating hw_frames_ctx.
> >
> > Could be verified by:
> > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
> > ./resolutions.ivf
> > -pix_fmt p010le -f rawvideo -vframes 20 -y vaapi.yuv
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/decode.c   |  8 
> >  libavcodec/vaapi_decode.c | 40 ++
> --
> >  2 files changed, 26 insertions(+), 22 deletions(-)
> >
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index 0863b82..a81b857 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -1254,7 +1254,6 @@ int
> ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
> >
> >  frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
> >
> > -
> >  if (frames_ctx->initial_pool_size) {
> >  // We guarantee 4 base work surfaces. The function above guarantees
> 1
> >  // (the absolute minimum), so add the missing count.
> > @@ -1333,7 +1332,7 @@ static int hwaccel_init(AVCodecContext *avctx,
> >  return AVERROR_PATCHWELCOME;
> >  }
> >
> > -if (hwaccel->priv_data_size) {
> > +if (hwaccel->priv_data_size && !avctx->internal->hwaccel_priv_data) {
> >  avctx->internal->hwaccel_priv_data =
> >  av_mallocz(hwaccel->priv_data_size);
> >  if (!avctx->internal->hwaccel_priv_data)
> > @@ -1397,8 +1396,9 @@ int ff_get_format(AVCodecContext *avctx, const
> enum AVPixelFormat *fmt)
> >
> >  for (;;) {
> >  // Remove the previous hwaccel, if there was one.
> > -hwaccel_uninit(avctx);
> > -
> > +// VAAPI allows reinit hw_frames_ctx only
> > +if (choices[0] != AV_PIX_FMT_VAAPI_VLD)
> > +hwaccel_uninit(avctx);
> >  user_choice = avctx->get_format(avctx, choices);
> 
> Having VAAPI specific code in this generic code path (or any hwaccel
> specific code) seems like a design flaw, and should perhaps be
> adressed by a generic improvement, instead of VAAPI specific hacks.
> 

Yes, a better solution(maybe a flag set by reinit in vaapi) should be applied.
Thanks for your response.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add vaapi_format_map for Y210/AYUV/Y410

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Sunday, July 7, 2019 20:13
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add
> vaapi_format_map for Y210/AYUV/Y410
> 
> On 28/06/2019 03:27, Linjie Fu wrote:
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavutil/hwcontext_vaapi.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index 4227c3c..6378d0e 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -116,6 +116,14 @@ static const VAAPIFormatDescriptor
> vaapi_format_map[] = {
> >  #endif
> >  MAP(UYVY, YUV422,  UYVY422, 0),
> >  MAP(YUY2, YUV422,  YUYV422, 0),
> > +#ifdef VA_FOURCC_Y210
> > +MAP(Y210, YUV422_10,Y210LE, 0),
> > +#endif
> > +#define VA_RT_FORMAT_AYUV VA_FOURCC_AYUV
> 
> VA_RT_FORMAT_* is a mask, VA_FOURCC_* is effectively a set of enum
> values.  They aren't usable as each other like this.
> 
> > +MAP(AYUV,   AYUV, AYUV, 0),
> 
> Is AYUV actually intended to support decoding alpha, or is it just a packed
> representation for YUV 4:4:4 data (like RGB0)?  If the former, you should
> probably add a new render target format to libva.  If the latter, you can use
> VA_RT_FORMAT_YUV444 with it.

There is no VA_RT_FORMAT_AYUV in defined in libva, and currently in 
media-driver,
VA_FOURCC_AYUV is used to represent VA_RT_FORMAT_AYUV in a hacky way.

Agreed there may be some hidden work in libva/media-driver to avoid hack.
Thanks for review.

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

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate hw_frames_ctx without destroy va_context

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Sunday, July 7, 2019 21:49
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Mark Thompson 
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate
> hw_frames_ctx without destroy va_context
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Mark Thompson
> > Sent: Sunday, July 7, 2019 19:51
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate
> > hw_frames_ctx without destroy va_context
> >
> > On 07/07/2019 17:38, Linjie Fu wrote:
> > > VP9 allows resolution changes per frame. Currently in VAAPI, resolution
> > > changes leads to va context destroy and reinit.
> >
> > Which is correct - it needs to remake the context because the old one is for
> > the wrong resolution.
> 
> It seems that we don't need to remake context, remaking the surface is
> enough
> for resolution changing.
> Currently in libva, surface is able to be recreated separately without
> remaking context.
> And this way is used in libyami to cope with resolution changing cases.
> 
> >
> > > This will cause
> > > reference frame surface lost and produce garbage.
> >
> > This isn't right - the reference frame surfaces aren't lost.  See
> > VP9Context.s.refs[], which holds references to the frames (including their
> > hardware frame contexts) until the stream indicates that they can be
> > discarded by overwriting their reference frame slots.
> 
> I'm not quite sure about this, at least the result shows they are not used
> correctly
> in current way.
> Will look deeper into it.
> 
> >
> > > As libva allows re-create surface separately without changing the
> > > context, this issue could be handled by only recreating hw_frames_ctx.
> > >
> > > Could be verified by:
> > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
> > > ./resolutions.ivf
> > > -pix_fmt p010le -f rawvideo -vframes 20 -y vaapi.yuv
> > >
> > > Signed-off-by: Linjie Fu 
> > > ---
> > >  libavcodec/decode.c   |  8 
> > >  libavcodec/vaapi_decode.c | 40 ++--
> --
> > --
> > >  2 files changed, 26 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > > index 0863b82..a81b857 100644
> > > --- a/libavcodec/decode.c
> > > +++ b/libavcodec/decode.c
> > > @@ -1254,7 +1254,6 @@ int
> > ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
> > >
> > >  frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
> > >
> > > -
> > >  if (frames_ctx->initial_pool_size) {
> > >  // We guarantee 4 base work surfaces. The function above
> guarantees
> > 1
> > >  // (the absolute minimum), so add the missing count.
> > > @@ -1333,7 +1332,7 @@ static int hwaccel_init(AVCodecContext *avctx,
> > >  return AVERROR_PATCHWELCOME;
> > >  }
> > >
> > > -if (hwaccel->priv_data_size) {
> > > +if (hwaccel->priv_data_size && !avctx->internal->hwaccel_priv_data)
> {
> > >  avctx->internal->hwaccel_priv_data =
> > >  av_mallocz(hwaccel->priv_data_size);
> > >  if (!avctx->internal->hwaccel_priv_data)
> > > @@ -1397,8 +1396,9 @@ int ff_get_format(AVCodecContext *avctx,
> const
> > enum AVPixelFormat *fmt)
> > >
> > >  for (;;) {
> > >  // Remove the previous hwaccel, if there was one.
> > > -hwaccel_uninit(avctx);
> > > -
> > > +// VAAPI allows reinit hw_frames_ctx only
> > > +if (choices[0] != AV_PIX_FMT_VAAPI_VLD)
> >
> > Including codec-specific conditions in the generic code suggests that
> > something very shady is going on.
> 
> Yes, will try to avoid this.
> 
> > > +hwaccel_uninit(avctx);>  user_choice = avctx-
> > >get_format(avctx, choices);
> > >  if (user_choice == AV_PIX_FMT_NONE) {
> > >  // Explicitly chose nothing, give up.
> > > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > > index 69512e1..13f0cf0 1006

Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate hw_frames_ctx without destroy va_context

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Yan Wang
> Sent: Monday, July 8, 2019 15:54
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate
> hw_frames_ctx without destroy va_context
> 
> 
> On 7/8/2019 2:45 PM, Yan Wang wrote:
> >
> > On 7/7/2019 9:49 PM, Fu, Linjie wrote:
> >>> -Original Message-
> >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >>> Of Mark Thompson
> >>> Sent: Sunday, July 7, 2019 19:51
> >>> To: ffmpeg-devel@ffmpeg.org
> >>> Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate
> >>> hw_frames_ctx without destroy va_context
> >>>
> >>> On 07/07/2019 17:38, Linjie Fu wrote:
> >>>> VP9 allows resolution changes per frame. Currently in VAAPI,
> >>>> resolution
> >>>> changes leads to va context destroy and reinit.
> >>> Which is correct - it needs to remake the context because the old
> >>> one is for
> >>> the wrong resolution.
> >> It seems that we don't need to remake context, remaking the surface
> >> is enough
> >> for resolution changing.
> >> Currently in libva, surface is able to be recreated separately
> >> without remaking context.
> >> And this way is used in libyami to cope with resolution changing cases.
> >>
> >>>> This will cause
> >>>> reference frame surface lost and produce garbage.
> >>> This isn't right - the reference frame surfaces aren't lost. See
> >>> VP9Context.s.refs[], which holds references to the frames (including
> >>> their
> >>> hardware frame contexts) until the stream indicates that they can be
> >>> discarded by overwriting their reference frame slots.
> >> I'm not quite sure about this, at least the result shows they are not
> >> used correctly
> >> in current way.
> >> Will look deeper into it.
> >
> > In vaapi_vp9_start_frame() of libavcodec/vaapi_vp9.c, it only passes
> > VASurfaceID into pic_param.reference_frames[i].
> >
> > But when destroy va_context, the surface/render target based on this
> > VASurfaceID has been destroyed.
> 
> Update: the surface isn't destroyed when destroy va_context. But every
> va_context maintains one independent map table: m_ddiDecodeCtx->RTtbl.
> 
> So the new context cannot find this surface in its map table.
> 
> My previous suggested solution should be available still.
>

Yes, tracing the code and could find that:

1.  surface is not destroyed until the decode finishes and calls avcodec_close;
2. refs[i] is passed to driver, however in DdiMediaBase::GetRenderTargetID, 
driver failed to
find the expected surface in the re-created m_ddiDecodeCtx->RTtbl, and returns 
invalid.
if(rtTbl->pRT[i] == surface) {
return i;
}
return DDI_CODEC_INVALID_FRAME_INDEX;

One possible way is to register the refs[] surfaces in the new created context 
->RTtbl and make it
findable.

Thanks for reviews and all comments.
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".

Re: [FFmpeg-devel] [PATCH 2/2] lavf/vf_vpp_qsv: add support for QSV transpose filter

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Monday, July 8, 2019 11:16
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH 2/2] lavf/vf_vpp_qsv: add support for
> QSV transpose filter
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Tuesday, June 18, 2019 10:53 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH 2/2] lavf/vf_vpp_qsv: add support for
> QSV
> > transpose filter
> >
> > Add transpose support for qsv_vpp with rotate and hflip:
> > - rotate: [0, 3] support clockwise rotation of 0, 90, 180, 270;
> > - hflip:  [0, 1] support horizontal flip;
> >
> > Configure with:
> > {"cclock_hflip","clock","cclock","clock_hflip","reversal","hflip","vflip"}
> >
> > Limitation:
> > If pipeline contains resize, mirroring and other, VPP skips other 
> > filters in
> > MSDK when IOPattern equals d3d->d3d. So "cclock_hflip, clock_hflip, vflip"
> > will not work in d3d->d3d condition.
> 
> How user can aware this if not check the log message? And any MSDK github
> issue created?

Yes, a PR has been sent to support  mirror when working on IOPattern equals 
d3d->d3d. 
https://github.com/Intel-Media-SDK/MediaSDK/pull/1491

> > CMD:
> > ffmpeg -hwaccel qsv -c:v h264_qsv -i input.h264
> > -vf 'format=qsv,vpp_qsv=transpose=clock' -c:v h264_qsv output.h264
> >
> > ffmpeg -init_hw_device qsv=foo -filter_hw_device foo -f rawvideo
> > -pix_fmt nv12 -s:v 1920x1080 -i input.nv12 -vf
> >
> >
> 'hwupload=extra_hw_frames=64,format=qsv,vpp_qsv=transpose=cclock_hf
> li
> > p'
> > -f rawvideo -pix_fmt nv12 -y ./transpose.yuv
> 
> What is the platform tested? Probably adding MFXVideoVPP_Query() to
> runtime capability checking is a good idea.

Tested on KBL, it should have been supported early.
Will think of adding MFXVideoVPP_Query() in a separate patch.

> > Signed-off-by: Linjie Fu 
> > ---
> >  libavfilter/vf_vpp_qsv.c | 95
> > +++-
> >  1 file changed, 93 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c index
> > dd05e8baff..974fc7a255 100644
> > --- a/libavfilter/vf_vpp_qsv.c
> > +++ b/libavfilter/vf_vpp_qsv.c
> > @@ -36,12 +36,15 @@
> >  #include "libavformat/avformat.h"
> >
> >  #include "qsvvpp.h"
> > +#include "transpose.h"
> >
> >  #define OFFSET(x) offsetof(VPPContext, x)  #define FLAGS
> > (AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_FILTERING_PARAM)
> >
> >  /* number of video enhancement filters */ -#define ENH_FILTERS_COUNT
> > (5)
> > +#define ENH_FILTERS_COUNT (7)
> > +#define QSV_HAVE_ROTATION  QSV_VERSION_ATLEAST(1, 17) #define
> > +QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19)
> >
> >  typedef struct VPPContext{
> >  const AVClass *class;
> > @@ -54,6 +57,8 @@ typedef struct VPPContext{
> >  mfxExtVPPDenoise denoise_conf;
> >  mfxExtVPPDetail detail_conf;
> >  mfxExtVPPProcAmp procamp_conf;
> > +mfxExtVPPRotation rotation_conf;
> > +mfxExtVPPMirroring mirroring_conf;
> >
> >  int out_width;
> >  int out_height;
> > @@ -70,6 +75,10 @@ typedef struct VPPContext{
> >  int crop_x;
> >  int crop_y;
> >
> > +int transpose;
> > +int rotate; /* rotate angle : [0, 90, 180, 270] */
> > +int hflip;  /* flip mode : 0 = off, 1 = HORIZONTAL
> > flip */
> > +
> >  /* param for the procamp */
> >  intprocamp;/* enable procamp */
> >  float  hue;
> > @@ -95,6 +104,15 @@ static const AVOption options[] = {
> >  { "contrast","ProcAmp contrast",
> > OFFSET(contrast),AV_OPT_TYPE_FLOAT,{ .dbl = 1.0 }, 0.0,
> > 10.0, .flags = FLAGS},
> >  { "brightness",  "ProcAmp brightness",
> > OFFSET(brightness),  AV_OPT_TYPE_FLOAT,{ .dbl = 0.0 }, -100.0,
> > 100.0, .flags = FLAGS},
> >
> > +{ "transpose",  "set transpose direction",   OFFSET(transpose),
> > AV_OPT_TYPE_INT,  { .i64 = -1 }, -1, 6, FLAGS, "transpose"},
> > +{ "cclock_hflip",  "rotate counter-clockwise with horizontal flip",
> > 

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

[Fu, Linjie]

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

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

Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate hw_frames_ctx without destroy va_context

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Monday, July 8, 2019 16:11
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate
> hw_frames_ctx without destroy va_context
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Yan Wang
> > Sent: Monday, July 8, 2019 15:54
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate
> > hw_frames_ctx without destroy va_context
> >
> >
> > On 7/8/2019 2:45 PM, Yan Wang wrote:
> > >
> > > On 7/7/2019 9:49 PM, Fu, Linjie wrote:
> > >>> -Original Message-
> > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > >>> Of Mark Thompson
> > >>> Sent: Sunday, July 7, 2019 19:51
> > >>> To: ffmpeg-devel@ffmpeg.org
> > >>> Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/vaapi_decode: recreate
> > >>> hw_frames_ctx without destroy va_context
> > >>>
> > >>> On 07/07/2019 17:38, Linjie Fu wrote:
> > >>>> VP9 allows resolution changes per frame. Currently in VAAPI,
> > >>>> resolution
> > >>>> changes leads to va context destroy and reinit.
> > >>> Which is correct - it needs to remake the context because the old
> > >>> one is for
> > >>> the wrong resolution.
> > >> It seems that we don't need to remake context, remaking the surface
> > >> is enough
> > >> for resolution changing.
> > >> Currently in libva, surface is able to be recreated separately
> > >> without remaking context.
> > >> And this way is used in libyami to cope with resolution changing cases.
> > >>
> > >>>> This will cause
> > >>>> reference frame surface lost and produce garbage.
> > >>> This isn't right - the reference frame surfaces aren't lost. See
> > >>> VP9Context.s.refs[], which holds references to the frames (including
> > >>> their
> > >>> hardware frame contexts) until the stream indicates that they can be
> > >>> discarded by overwriting their reference frame slots.
> > >> I'm not quite sure about this, at least the result shows they are not
> > >> used correctly
> > >> in current way.
> > >> Will look deeper into it.
> > >
> > > In vaapi_vp9_start_frame() of libavcodec/vaapi_vp9.c, it only passes
> > > VASurfaceID into pic_param.reference_frames[i].
> > >
> > > But when destroy va_context, the surface/render target based on this
> > > VASurfaceID has been destroyed.
> >
> > Update: the surface isn't destroyed when destroy va_context. But every
> > va_context maintains one independent map table: m_ddiDecodeCtx-
> >RTtbl.
> >
> > So the new context cannot find this surface in its map table.
> >
> > My previous suggested solution should be available still.
> >
> 
> Yes, tracing the code and could find that:
> 
> 1.  surface is not destroyed until the decode finishes and calls 
> avcodec_close;
> 2. refs[i] is passed to driver, however in DdiMediaBase::GetRenderTargetID,
> driver failed to
> find the expected surface in the re-created m_ddiDecodeCtx->RTtbl, and
> returns invalid.
>   if(rtTbl->pRT[i] == surface) {
>   return i;
>   }
>   return DDI_CODEC_INVALID_FRAME_INDEX;
> 
> One possible way is to register the refs[] surfaces in the new created context
> ->RTtbl and make it
> findable.

Attempt  to register refs[] surface when re-creating context, and observed that 
refs[] surface
has been registered into RTtbl and is able to accessed in driver.
https://github.com/fulinjie/ffmpeg/commit/9ed1a309786d2e395753ed327b511e6d9779986f

However, the decode still failed to get the correct image.

Working together with  Wang Yan to investigate more in driver.

And Yan found iHD driver will maintain some internal variables and reference 
link list
(CodeclhalDecodeVp9::m_vp9RefList) in Codec HAL layer which will be destroyed
when destroy VAAPI context.

CodechalDecodeVp9:SetFrameStates() will set resRefPic/dwFrameWidth/dwFrameHeight
of CodeclhalDecodeVp9::m_vp9RefList. And CodechalDecodeVp9::~ 
CodechalDecodeVp9()
will destroy it when VAAPI context is destroyed. So the ne

Re: [FFmpeg-devel] [PATCH, v3] lavc/pthread_frame: update context in child thread in multi-thread mode

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Friday, June 28, 2019 08:56
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] lavc/pthread_frame: update
> context in child thread in multi-thread mode
> 
> On Thu, Jun 27, 2019 at 1:56 PM Linjie Fu  wrote:
> >
> > Currently in ff_thread_decode_frame, context is updated from child
> thread
> > to user thread, and user thread releases the context in avcodec_close()
> > when decode finishes.
> >
> > However, when resolution/format changes, ff_get_format is called, and
> > hwaccel_uninit() and hwaccel_init will be used to destroy and re-create
> > the context. Due to the async between user-thread and child-thread,
> > user-thread updates its context from child earlier than the context
> > is refreshed in child-thread. And it will lead to:
> > 1. memory leak in child-thread.
> > 2. double free in user-thread while calling avcodec_close().
> >
> > Can be reproduced with a resolution change case, and use -vframes
> > to terminate the decode between the dynamic resolution changing frames:
> >
> > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v
> > verbose -i ./test2360_1672_4980.ivf -pix_fmt p010le -f rawvideo -vsync
> > passthrough -vframes 6 -y out.yuv
> >
> > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v verbose -i
> > ./reinit-large_420_8-to-small_420_8.h264 -pix_fmt nv12 -f rawvideo
> > -vsync passthrough -vframes 45 -y out.yuv
> >
> > Move update_context_from_thread from ff_thread_decode_frame(user
> thread)
> > to frame_worker_thread(child thread), update the context in child thread
> > right after the context is refreshed to avoid the async issue.
> >
> 
> I think the undelying issue that Michael mentioned remains - you are
> changing the user context from a worker thread, at which point the
> user might be accessing his context simultaneously. You cannot prevent
> that with a mutex, since the user does not use your mutex.

User context could be accessed everywhere in the user thread, so changing from
worker thread will always lead to a race condition.
Seems I didn't fully understood this before.

Async feature is designed on purpose, it's hard to capture the changes in worker
thread in time and get the context updated for user thread correctly.

As the async issue exists commonly for resolution changing, it is in need for 
fixing.

> Additionally, the user context should reflect the state of the last
> frame that was output to the user, if a worker thread changes it
> immediately as it sees the size change, wouldn't it be possible for
> frames of the old size to be output after the context was already
> updated? That sounds like trouble to me.

I didn't quite understand it, but as another patch for vp9 shows, output frame 
whose size
Is different from context can still be correct.

Anyway, since it's not easy(or possible) to modify in worker thread, this won't 
be a problem. 

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

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: use -reinit_filter to disable/enable auto scale

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of myp...@gmail.com
> Sent: Friday, July 12, 2019 13:28
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: use -reinit_filter
> to disable/enable auto scale
> 
> On Fri, Jul 12, 2019 at 1:19 PM Linjie Fu  wrote:
> >
> > Currently, ffmpeg inserts scale filter in the filter graph to force
> > the whole decoded stream to scale into the same size with the first
> > frame. It's not quite make sense in resolution changing cases if user
> > wants the rawvideo without any scale.
> >
> > Option -reinit_filter 0 could be used to realize similar function, but
> > it fails when ifilter has hw_frame_ctx.
> >
> > Add auto_scale flag set by -reinit_filter to indicate whether auto
> > inserting the scale filter in the filter graph.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > Request for comments.
> > As we have discussed in the rawdump filter patch, here is a simpler
> > solution based on -reinit_filter, and reuse this option.(maybe it's not
> > easy to be accepted to add a separate option)
> >
> >  fftools/ffmpeg.c| 2 +-
> >  fftools/ffmpeg.h| 1 +
> >  fftools/ffmpeg_filter.c | 2 +-
> >  3 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 01f04103cf..5305b87bd4 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -2133,6 +2133,7 @@ static int ifilter_send_frame(InputFilter *ifilter,
> AVFrame *frame)
> >
> >  /* determine if the parameters for this input changed */
> >  need_reinit = ifilter->format != frame->format;
> > +fg->auto_scale = ifilter->ist->reinit_filters;
> >
> >  switch (ifilter->ist->st->codecpar->codec_type) {
> >  case AVMEDIA_TYPE_AUDIO:
> > @@ -2145,7 +2146,6 @@ static int ifilter_send_frame(InputFilter *ifilter,
> AVFrame *frame)
> > ifilter->height != frame->height;
> >  break;
> >  }
> > -
> Unrelated change

Yep, this should be recalled. 

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

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

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

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: use -reinit_filter to disable/enable auto scale

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Friday, July 12, 2019 14:39
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: use -reinit_filter
> to disable/enable auto scale
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Friday, July 12, 2019 9:19 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: use -reinit_filter to
> > disable/enable auto scale
> >
> > Currently, ffmpeg inserts scale filter in the filter graph to force the 
> > whole
> > decoded stream to scale into the same size with the first frame. It's not
> quite
> > make sense in resolution changing cases if user wants the rawvideo
> without
> > any scale.
> >
> > Option -reinit_filter 0 could be used to realize similar function, but it 
> > fails
> > when ifilter has hw_frame_ctx.
> >
> > Add auto_scale flag set by -reinit_filter to indicate whether auto inserting
> > the scale filter in the filter graph.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > Request for comments.
> > As we have discussed in the rawdump filter patch, here is a simpler solution
> > based on -reinit_filter, and reuse this option.(maybe it's not easy to be
> > accepted to add a separate option)
> >
> >  fftools/ffmpeg.c| 2 +-
> >  fftools/ffmpeg.h| 1 +
> >  fftools/ffmpeg_filter.c | 2 +-
> >  3 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index
> > 01f04103cf..5305b87bd4 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -2133,6 +2133,7 @@ static int ifilter_send_frame(InputFilter *ifilter,
> > AVFrame *frame)
> >
> >  /* determine if the parameters for this input changed */
> >  need_reinit = ifilter->format != frame->format;
> > +fg->auto_scale = ifilter->ist->reinit_filters;
> >
> >  switch (ifilter->ist->st->codecpar->codec_type) {
> >  case AVMEDIA_TYPE_AUDIO:
> > @@ -2145,7 +2146,6 @@ static int ifilter_send_frame(InputFilter *ifilter,
> > AVFrame *frame)
> > ifilter->height != frame->height;
> >  break;
> >  }
> > -
> >  if (!ifilter->ist->reinit_filters && fg->graph)
> >  need_reinit = 0;
> >
> > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h index
> > 7b6f802082..0c289b439f 100644
> > --- a/fftools/ffmpeg.h
> > +++ b/fftools/ffmpeg.h
> > @@ -285,6 +285,7 @@ typedef struct FilterGraph {
> >
> >  AVFilterGraph *graph;
> >  int reconfiguration;
> > +int auto_scale;
> >
> >  InputFilter   **inputs;
> >  int  nb_inputs;
> > diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c index
> > 72838de1e2..856ba48de7 100644
> > --- a/fftools/ffmpeg_filter.c
> > +++ b/fftools/ffmpeg_filter.c
> > @@ -469,7 +469,7 @@ static int configure_output_video_filter(FilterGraph
> > *fg, OutputFilter *ofilter,
> >  if (ret < 0)
> >  return ret;
> >
> > -if (ofilter->width || ofilter->height) {
> > +if ((ofilter->width || ofilter->height) && fg->auto_scale) {
> >  char args[255];
> >  AVFilterContext *filter;
> >  AVDictionaryEntry *e = NULL;
> > --
> > 2.17.1
> 
> Is there any big difference with https://patchwork.ffmpeg.org/patch/8173/,
> especially for the purpose of disabling scaling for HWACCEL?

It's a bit different IMHO.

This patch enables disable/enable scale as user's purpose, both 
software/hardware
would obey and meet user's expectation.

And the attached patch seems to disable scale for hw encoder to make the 
transcode
pipeline work. But this will lead to different results between software deocde 
and
hardware decode.


___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavf/vf_vpp_qsv: add support for QSV transpose filter

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Sunday, July 14, 2019 19:33
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for
> QSV transpose filter
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Thursday, July 11, 2019 1:58 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH, v3] lavf/vf_vpp_qsv: add support for
> QSV
> > transpose filter
> >
> > Add transpose support for qsv_vpp with rotate and hflip:
> > - rotate: [0, 3] support clockwise rotation of 0, 90, 180, 270;
> > - hflip:  [0, 1] support horizontal flip;
> >
> > Configure with:
> > {"cclock_hflip","clock","cclock","clock_hflip","reversal","hflip","vflip"}
> >
> > Limitation:
> > If pipeline contains resize, mirroring and other, VPP skips other 
> > filters in
> > MSDK when IOPattern equals d3d->d3d. So "cclock_hflip, clock_hflip, vflip"
> > will not work in d3d->d3d condition.
> >
> > This pr is fixing this:
> > https://github.com/Intel-Media-SDK/MediaSDK/pull/1491
> >
> > CMD:
> > ffmpeg -hwaccel qsv -c:v h264_qsv -i input.h264
> > -vf 'format=qsv,vpp_qsv=transpose=clock' -c:v h264_qsv output.h264
> 
> Tested:
> ffmpeg -hwaccel qsv -c:v h264_qsv -i
> ~/bbb_sunflower_1080p_30fps_normal.mp4 -vframes 100 -vf
> 'format=qsv,vpp_qsv=transpose=cclock_hflip' -c:v h264_qsv ch.mp4
> Both Skylake and KBL failed:
> 
> [Parsed_vpp_qsv_1 @ 0x5581aaf16080] Failed to create a qsvvpp, ret = -15.
> [Parsed_vpp_qsv_1 @ 0x5581aaf16080] Failed to configure output pad on
> Parsed_vpp_qsv_1
> Error reinitializing filters!
> Failed to inject frame into filter network: Block device required
> Error while processing the decoded data for stream #0:0

It is due to the limitation in MSDK mentioned in commit message:
If pipeline contains resize, mirroring and other, VPP skips other filters in 
MSDK.

And specially for resize (also width/height swap caused  by rotate), 
MFXVideoVPP_Init
would fail directly, not simply skip the resize/rotate:
https://github.com/Intel-Media-SDK/MediaSDK/blob/master/_studio/mfx_lib/vpp/src/mfx_vpp_hw.cpp#L5546

This PR could handle this properly as suggested:
https://github.com/Intel-Media-SDK/MediaSDK/pull/1491

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

Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: use -reinit_filter to disable/enable auto scale

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Eoff, Ullysses A
> Sent: Saturday, July 13, 2019 12:26
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] fftools/ffmpeg_filter: use -reinit_filter
> to disable/enable auto scale
> 
> > > > 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.
> 

Thanks for the comments.
Will refine new patches with a separate option and doc.

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

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

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Moritz Barsnick
> Sent: Monday, July 15, 2019 20:02
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] doc/ffmpeg.texi: update docs for
> autoscale/autorotate
> 
> On Mon, Jul 15, 2019 at 18:39:14 +0800, Linjie Fu wrote:
> 
> Nit:
> 
> > +@item -noautoscale
> > +Disable automatically scale video based on first frame resolution.
>  ^ scaling
> 

Yes, scaling :)
Thanks.

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

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

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

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Monday, July 15, 2019 23:38
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] doc/ffmpeg.texi: update docs for
> autoscale/autorotate
> 
> Am Mo., 15. Juli 2019 um 12:39 Uhr schrieb Linjie Fu :
> >
> > Add docs for autoscale/noautoscale.
> >
> > Update information for autorotate according to ffplay.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  doc/ffmpeg.texi | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index cd35eb49c8..040a2b53cf 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -735,9 +735,20 @@ 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 -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.
> > +
> >  @item -noautorotate
> >  Disable automatically rotating video based on file metadata.
> >
> > +@item -noautoscale
> > +Disable automatically scale video based on first frame resolution.
> 
> Istn't there a "-no" option for most (all?) ffmpeg options but we only
> document one of them?

Options with OPT_BOOL flag (/* boolean -nofoo options */) can be used in this 
way.

> I believe "autorotate" and "autoscale" are sufficient if there counterparts
> are also described.
Agree, if there is docs for "-no"  option well explained. 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

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

[Fu, Linjie]

> -Original Message-
> From: Nicolas George [mailto:geo...@nsup.org]
> Sent: Monday, July 15, 2019 22:00
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] doc/ffmpeg.texi: update docs for
> autoscale/autorotate
> 
> Linjie Fu (12019-07-15):
> > Add docs for autoscale/noautoscale.
> 
> This belongs in the path that adds them.

A little bit confused on this.
Improper position in doc for these options or  I need to add docs together with
code in one patch?
 
> >
> > Update information for autorotate according to ffplay.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  doc/ffmpeg.texi | 11 +++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index cd35eb49c8..040a2b53cf 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -735,9 +735,20 @@ 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 -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.
> > +
> >  @item -noautorotate
> >  Disable automatically rotating video based on file metadata.
> >
> 
> > +@item -noautoscale
> > +Disable automatically scale video based on first frame resolution.
> 
> You neglected to explain the drawbacks.

Yes, can add something like:
"Each frame of the output raw video can in different resolutions
and is in need to be handled in following pipeline like vpp/encode."

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

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

[Fu, Linjie]

> -Original Message-
> From: Eoff, Ullysses A
> Sent: Wednesday, July 17, 2019 21:48
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH, v2 2/2] doc/ffmpeg.texi: update docs
> for autoscale/autorotate
> 
> > -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."
> 

This sounds much better, thanks a lot.
Will update.

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

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

[Fu, Linjie]

> -Original Message-
> From: Nicolas George [mailto:geo...@nsup.org]
> Sent: Thursday, July 18, 2019 03:07
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] doc/ffmpeg.texi: update docs
> for autoscale/autorotate
> 
> Linjie Fu (12019-07-16):
> > 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.
> 
> Since this is completely hackish in lavfi, I think it needs to warn the
> user much more strongly to expect problems.

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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavc/phtread_frame: update hwaccel_priv_data in time for multithread

[Fu, Linjie]

> -Original Message-
> From: Fu, Linjie
> Sent: Friday, July 19, 2019 05:35
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [PATCH] lavc/phtread_frame: update hwaccel_priv_data in time for
> multithread
> 
> When resolution/format changes, hwaccel_uninit/hwaccel_init will
> be called to destroy and re-create the hwaccel_priv_data. When output
> frame number meets the constraints for vframes, the hwaccel_priv_data
> modified in decoding thread won't be update to user-thread due to the
> delay mechanism. It will lead to:
> 1. memory leak in child-thread.
> 2. double free in user-thread while calling avcodec_close().
> 
> Can be reproduced with a resolution change case, and use -vframes
> to terminate the decode during dynamic resolution changing:
> 
> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v verbose
> -i ./reinit-large_420_8-to-small_420_8.h264 -pix_fmt nv12 -f rawvideo
> -vsync passthrough -vframes 45 -y out.yuv
> 
> The root cause is the conflict between delay mechanism and -vframes.
> FFmpeg won't output a frame if it's still receiving the initial packets,
> so there is async between decode process and output. hwaccel_priv_data
> in user thread won't be updated until the resolution changing
> frame is output.
> 
> As user context should reflect the state of the last frame that
> was output to the user, hwaccel_priv_data should be updated
> separately from decoding thread in time.
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/pthread_frame.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> index 36ac0ac..cf7a575 100644
> --- a/libavcodec/pthread_frame.c
> +++ b/libavcodec/pthread_frame.c
> @@ -282,7 +282,6 @@ static int
> update_context_from_thread(AVCodecContext *dst, AVCodecContext *src,
>  dst->sample_rate= src->sample_rate;
>  dst->sample_fmt = src->sample_fmt;
>  dst->channel_layout = src->channel_layout;
> -dst->internal->hwaccel_priv_data = src->internal->hwaccel_priv_data;
> 
>  if (!!dst->hw_frames_ctx != !!src->hw_frames_ctx ||
>  (dst->hw_frames_ctx && dst->hw_frames_ctx->data != src-
> >hw_frames_ctx->data)) {
> @@ -410,6 +409,7 @@ static int submit_packet(PerThreadContext *p,
> AVCodecContext *user_avctx,
>  pthread_mutex_unlock(&prev_thread->progress_mutex);
>  }
> 
> +p->avctx->internal->hwaccel_priv_data = prev_thread->avctx-
> >internal->hwaccel_priv_data;
>  err = update_context_from_thread(p->avctx, prev_thread->avctx, 0);
>  if (err) {
>  pthread_mutex_unlock(&p->mutex);
> @@ -476,7 +476,7 @@ int ff_thread_decode_frame(AVCodecContext
> *avctx,
>  FrameThreadContext *fctx = avctx->internal->thread_ctx;
>  int finished = fctx->next_finished;
>  PerThreadContext *p;
> -int err;
> +int err, cur_decoding;
> 
>  /* release the async lock, permitting blocked hwaccel threads to
>   * go forward while we are in this function */
> @@ -544,6 +544,13 @@ int ff_thread_decode_frame(AVCodecContext
> *avctx,
> 
>  if (fctx->next_decoding >= avctx->thread_count) fctx->next_decoding = 0;
> 
> +/* update hwaccel_priv_data from decoding thread */
> +cur_decoding = fctx->next_decoding - 1;
> +if (cur_decoding < 0) cur_decoding += avctx->thread_count;
> +
> +p = &fctx->threads[cur_decoding];
> +avctx->internal->hwaccel_priv_data = p->avctx->internal-
> >hwaccel_priv_data;
> +
>  fctx->next_finished = finished;
> 
>  /* return the size of the consumed packet if no error occurred */
> --
> 2.7.4


Since previous concerns in https://patchwork.ffmpeg.org/patch/13723/
could be  addressed in this version, ping for comments.

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

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

[Fu, Linjie]

> -Original Message-
> From: Nicolas George [mailto:geo...@nsup.org]
> Sent: Saturday, July 20, 2019 00:37
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie ; Eoff, Ullysses A
> 
> Subject: Re: [FFmpeg-devel] [PATCH, v3 2/2] doc/ffmpeg.texi: update docs
> for autoscale/autorotate
> 
> Linjie Fu (12019-07-20):
> > Add docs for autoscale.
> 
> In the same patch. Why would you want to separate?

Simply thought doc should be update separately.
Will follow.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Gyan
> Sent: Saturday, July 20, 2019 13:29
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale

> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index cd35eb49c8..99121b6981 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > +@item -autoscale
> > +Automatically scale the video according to the resolution of first frame.
> > +Enabled by default, use @option{-noautoscale} to disable 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. 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.
> 
> Since the auto scaling happens at the end of the graph, what may the
> "additional explicit processing" be?

Vpp processing may not be influenced,  a warning in transcode is needed.
The expression seems to be improper, how about:

"When autoscale is disabled, all output frames of filter graph might not be in 
the same
resolution and may be inadequate for encoder/muxer."

or other suggestions?

> > @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
> >   { "autorotate",   HAS_ARG | OPT_BOOL | OPT_SPEC |
> > OPT_EXPERT | OPT_INPUT, 
> >{ .off =
> OFFSET(autorotate) },
> >   "automatically insert correct rotate filters" },
> > +{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
> > +  OPT_EXPERT | OPT_INPUT,  
> >   { .off =
> OFFSET(autoscale) },
> > +"automatically insert a scale filter at the end of the filter 
> > graph if a
> resolution"
> > +"change is detected. This ensures all frames are the same 
> > resolution
> as the first frame"
> > +"when they leave the filter chain (this option is enabled by 
> > default)."
> > +"If disabled, some encoders/muxers may not support this mode."},
> Which muxers can detect or check for prop changes within coded
> bitstreams? Which encoders are known to be able to handle
> changing resolution?

It's not supported currently (even in libvpx-vp9, since vp9 supports dynamic 
resolution in spec).

I don't intend to be so absolutely in doc,  will it be better for you to modify 
like:
"If disabled, encoders/muxers won't support this mode currently."

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

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

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Monday, July 22, 2019 16:11
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Gyan
> > Sent: Saturday, July 20, 2019 13:29
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> > autoscale to disable/enable the default scale
> 
> > > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > > index cd35eb49c8..99121b6981 100644
> > > --- a/doc/ffmpeg.texi
> > > +++ b/doc/ffmpeg.texi
> > > +@item -autoscale
> > > +Automatically scale the video according to the resolution of first frame.
> > > +Enabled by default, use @option{-noautoscale} to disable 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. 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.
> >
> > Since the auto scaling happens at the end of the graph, what may the
> > "additional explicit processing" be?
> 
> Vpp processing may not be influenced,  a warning in transcode is needed.
> The expression seems to be improper, how about:
> 
> "When autoscale is disabled, all output frames of filter graph might not be in
> the same
> resolution and may be inadequate for encoder/muxer."
> 
> or other suggestions?
> 
> > > @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
> > >   { "autorotate",   HAS_ARG | OPT_BOOL | OPT_SPEC |
> > > OPT_EXPERT | OPT_INPUT,   
> > >  { .off =
> > OFFSET(autorotate) },
> > >   "automatically insert correct rotate filters" },
> > > +{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
> > > +  OPT_EXPERT | OPT_INPUT,
> > > { .off =
> > OFFSET(autoscale) },
> > > +"automatically insert a scale filter at the end of the filter 
> > > graph if a
> > resolution"
> > > +"change is detected. This ensures all frames are the same 
> > > resolution
> > as the first frame"
> > > +"when they leave the filter chain (this option is enabled by
> default)."
> > > +"If disabled, some encoders/muxers may not support this mode."},
> > Which muxers can detect or check for prop changes within coded
> > bitstreams? Which encoders are known to be able to handle
> > changing resolution?
> 
> It's not supported currently (even in libvpx-vp9, since vp9 supports dynamic
> resolution in spec).
> 
> I don't intend to be so absolutely in doc,  will it be better for you to 
> modify
> like:
> "If disabled, encoders/muxers won't support this mode currently."
> 
Are these modifications acceptable?
If no against, will update a new version. Thanks.

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

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

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Gyan
> Sent: Wednesday, July 24, 2019 00:49
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale
> 
> 
> 
> On 22-07-2019 01:40 PM, Fu, Linjie wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Gyan
> >> Sent: Saturday, July 20, 2019 13:29
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> >> autoscale to disable/enable the default scale
> >>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> >>> index cd35eb49c8..99121b6981 100644
> >>> --- a/doc/ffmpeg.texi
> >>> +++ b/doc/ffmpeg.texi
> >>> +@item -autoscale
> >>> +Automatically scale the video according to the resolution of first frame.
> >>> +Enabled by default, use @option{-noautoscale} to disable 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. 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.
> >> Since the auto scaling happens at the end of the graph, what may the
> >> "additional explicit processing" be?
> > Vpp processing may not be influenced,  a warning in transcode is needed.
> > The expression seems to be improper, how about:
> >
> > "When autoscale is disabled, all output frames of filter graph might not be
> in the same
> > resolution and may be inadequate for encoder/muxer."
> >
> > or other suggestions?
> >
> >>> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
> >>>{ "autorotate",   HAS_ARG | OPT_BOOL | OPT_SPEC |
> >>>  OPT_EXPERT | OPT_INPUT,  
> >>>   { .off =
> >> OFFSET(autorotate) },
> >>>"automatically insert correct rotate filters" },
> >>> +{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
> >>> +  OPT_EXPERT | OPT_INPUT,
> >>> { .off =
> >> OFFSET(autoscale) },
> >>> +"automatically insert a scale filter at the end of the filter 
> >>> graph if a
> >> resolution"
> >>> +"change is detected. This ensures all frames are the same
> resolution
> >> as the first frame"
> >>> +"when they leave the filter chain (this option is enabled by
> default)."
> >>> +"If disabled, some encoders/muxers may not support this mode."},
> >> Which muxers can detect or check for prop changes within coded
> >> bitstreams? Which encoders are known to be able to handle
> >> changing resolution?
> > It's not supported currently (even in libvpx-vp9, since vp9 supports
> dynamic resolution in spec).
> >
> > I don't intend to be so absolutely in doc,  will it be better for you to 
> > modify
> like:
> > "If disabled, encoders/muxers won't support this mode currently."
> 
> So other than    `-c:v rawvideo -f rawvideo`, there is no combination
> that supports changing frame sizes?

I didn't check all encoders.
But since the resolution changing is detectable, some additional reinit 
procedures
can be added to change resolution at IDR frame and make the encoder works.

___
ffmpeg-devel mailing list
ffmpeg-devel@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] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Gyan
> Sent: Wednesday, July 24, 2019 12:28
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale
> 
> 
> 
> On 24-07-2019 08:15 AM, Fu, Linjie wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Gyan
> >> Sent: Wednesday, July 24, 2019 00:49
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> >> autoscale to disable/enable the default scale
> >>
> >>
> >>
> >> On 22-07-2019 01:40 PM, Fu, Linjie wrote:
> >>>> -Original Message-
> >>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> >> Behalf
> >>>> Of Gyan
> >>>> Sent: Saturday, July 20, 2019 13:29
> >>>> To: ffmpeg-devel@ffmpeg.org
> >>>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> >>>> autoscale to disable/enable the default scale
> >>>>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> >>>>> index cd35eb49c8..99121b6981 100644
> >>>>> --- a/doc/ffmpeg.texi
> >>>>> +++ b/doc/ffmpeg.texi
> >>>>> +@item -autoscale
> >>>>> +Automatically scale the video according to the resolution of first
> frame.
> >>>>> +Enabled by default, use @option{-noautoscale} to disable 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. 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.
> >>>> Since the auto scaling happens at the end of the graph, what may the
> >>>> "additional explicit processing" be?
> >>> Vpp processing may not be influenced,  a warning in transcode is needed.
> >>> The expression seems to be improper, how about:
> >>>
> >>> "When autoscale is disabled, all output frames of filter graph might not
> be
> >> in the same
> >>> resolution and may be inadequate for encoder/muxer."
> >>>
> >>> or other suggestions?
> >>>
> >>>>> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
> >>>>> { "autorotate",   HAS_ARG | OPT_BOOL | OPT_SPEC |
> >>>>>   OPT_EXPERT | OPT_INPUT,   
> >>>>>  { .off =
> >>>> OFFSET(autorotate) },
> >>>>> "automatically insert correct rotate filters" },
> >>>>> +{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
> >>>>> +  OPT_EXPERT | OPT_INPUT,  
> >>>>>   { .off =
> >>>> OFFSET(autoscale) },
> >>>>> +"automatically insert a scale filter at the end of the filter 
> >>>>> graph if
> a
> >>>> resolution"
> >>>>> +"change is detected. This ensures all frames are the same
> >> resolution
> >>>> as the first frame"
> >>>>> +"when they leave the filter chain (this option is enabled by
> >> default)."
> >>>>> +"If disabled, some encoders/muxers may not support this
> mode."},
> >>>> Which muxers can detect or check for prop changes within coded
> >>>> bitstreams? Which encoders are known to be able to handle
> >>>> changing resolution?
> >>> It's not supported currently (even in libvpx-vp9, since vp9 supports
> >> dynamic resolution in spec).
> >>> I don't intend to be so absolutely in doc,  will it be better for you to
> modify
> >> like:
> >>> "If disabled, encoders/muxers won't support this mode currently."
> >> So other than    `-c:v rawvideo -f rawvideo`, there is no combination
> >> that supports changing frame sizes?
> > I didn't check all encoders.
> > But since the resolution changing is detectable, some additional reinit
> procedures
> > can be added to change resolution at IDR frame and make the encoder
> works.
> >
> They could, but as of now, which encoder + muxer combinations are
> **known** to work?
> 
As far as I tried, no.
(pipeline failed in libx264,  garbage exists in libx265 and libvpx-vp9 )
___
ffmpeg-devel mailing list
ffmpeg-devel@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] fftools/ffmpeg_filter: add -autoscale to disable/enable the default scale

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, July 24, 2019 17:42
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale
> 
> On 7/24/19, Fu, Linjie  wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Gyan
> >> Sent: Wednesday, July 24, 2019 12:28
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> >> autoscale to disable/enable the default scale
> >>
> >>
> >>
> >> On 24-07-2019 08:15 AM, Fu, Linjie wrote:
> >> >> -Original Message-
> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> >> Behalf
> >> >> Of Gyan
> >> >> Sent: Wednesday, July 24, 2019 00:49
> >> >> To: ffmpeg-devel@ffmpeg.org
> >> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> >> >> autoscale to disable/enable the default scale
> >> >>
> >> >>
> >> >>
> >> >> On 22-07-2019 01:40 PM, Fu, Linjie wrote:
> >> >>>> -Original Message-
> >> >>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org]
> On
> >> >> Behalf
> >> >>>> Of Gyan
> >> >>>> Sent: Saturday, July 20, 2019 13:29
> >> >>>> To: ffmpeg-devel@ffmpeg.org
> >> >>>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add
> -
> >> >>>> autoscale to disable/enable the default scale
> >> >>>>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> >> >>>>> index cd35eb49c8..99121b6981 100644
> >> >>>>> --- a/doc/ffmpeg.texi
> >> >>>>> +++ b/doc/ffmpeg.texi
> >> >>>>> +@item -autoscale
> >> >>>>> +Automatically scale the video according to the resolution of first
> >> frame.
> >> >>>>> +Enabled by default, use @option{-noautoscale} to disable 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. 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.
> >> >>>> Since the auto scaling happens at the end of the graph, what may
> the
> >> >>>> "additional explicit processing" be?
> >> >>> Vpp processing may not be influenced,  a warning in transcode is
> >> >>> needed.
> >> >>> The expression seems to be improper, how about:
> >> >>>
> >> >>> "When autoscale is disabled, all output frames of filter graph might
> >> >>> not
> >> be
> >> >> in the same
> >> >>> resolution and may be inadequate for encoder/muxer."
> >> >>>
> >> >>> or other suggestions?
> >> >>>
> >> >>>>> @@ -3640,6 +3642,12 @@ const OptionDef options[] = {
> >> >>>>> { "autorotate",   HAS_ARG | OPT_BOOL | OPT_SPEC |
> >> >>>>>   OPT_EXPERT | OPT_INPUT,
> >> >>>>> { .off =
> >> >>>> OFFSET(autorotate) },
> >> >>>>> "automatically insert correct rotate filters" },
> >> >>>>> +{ "autoscale",HAS_ARG | OPT_BOOL | OPT_SPEC |
> >> >>>>> +  OPT_EXPERT | OPT_INPUT,
> >> >>>>>  { .off =
> >> >>>> OFFSET(autoscale) },
> >> >>>>> +

Re: [FFmpeg-devel] [PATCH] lavc/phtread_frame: update hwaccel_priv_data in time for multithread

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Saturday, July 20, 2019 00:32
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/phtread_frame: update
> hwaccel_priv_data in time for multithread
> 
> > -Original Message-
> > From: Fu, Linjie
> > Sent: Friday, July 19, 2019 05:35
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [PATCH] lavc/phtread_frame: update hwaccel_priv_data in time
> for
> > multithread
> >
> > When resolution/format changes, hwaccel_uninit/hwaccel_init will
> > be called to destroy and re-create the hwaccel_priv_data. When output
> > frame number meets the constraints for vframes, the hwaccel_priv_data
> > modified in decoding thread won't be update to user-thread due to the
> > delay mechanism. It will lead to:
> > 1. memory leak in child-thread.
> > 2. double free in user-thread while calling avcodec_close().
> >
> > Can be reproduced with a resolution change case, and use -vframes
> > to terminate the decode during dynamic resolution changing:
> >
> > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v verbose
> > -i ./reinit-large_420_8-to-small_420_8.h264 -pix_fmt nv12 -f rawvideo
> > -vsync passthrough -vframes 45 -y out.yuv
> >
> > The root cause is the conflict between delay mechanism and -vframes.
> > FFmpeg won't output a frame if it's still receiving the initial packets,
> > so there is async between decode process and output. hwaccel_priv_data
> > in user thread won't be updated until the resolution changing
> > frame is output.
> >
> > As user context should reflect the state of the last frame that
> > was output to the user, hwaccel_priv_data should be updated
> > separately from decoding thread in time.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/pthread_frame.c | 11 +--
> >  1 file changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> > index 36ac0ac..cf7a575 100644
> > --- a/libavcodec/pthread_frame.c
> > +++ b/libavcodec/pthread_frame.c
> > @@ -282,7 +282,6 @@ static int
> > update_context_from_thread(AVCodecContext *dst, AVCodecContext
> *src,
> >  dst->sample_rate= src->sample_rate;
> >  dst->sample_fmt = src->sample_fmt;
> >  dst->channel_layout = src->channel_layout;
> > -dst->internal->hwaccel_priv_data = 
> > src->internal->hwaccel_priv_data;
> >
> >  if (!!dst->hw_frames_ctx != !!src->hw_frames_ctx ||
> >  (dst->hw_frames_ctx && dst->hw_frames_ctx->data != src-
> > >hw_frames_ctx->data)) {
> > @@ -410,6 +409,7 @@ static int submit_packet(PerThreadContext *p,
> > AVCodecContext *user_avctx,
> >  pthread_mutex_unlock(&prev_thread->progress_mutex);
> >  }
> >
> > +p->avctx->internal->hwaccel_priv_data = prev_thread->avctx-
> > >internal->hwaccel_priv_data;
> >  err = update_context_from_thread(p->avctx, prev_thread->avctx, 0);
> >  if (err) {
> >  pthread_mutex_unlock(&p->mutex);
> > @@ -476,7 +476,7 @@ int ff_thread_decode_frame(AVCodecContext
> > *avctx,
> >  FrameThreadContext *fctx = avctx->internal->thread_ctx;
> >  int finished = fctx->next_finished;
> >  PerThreadContext *p;
> > -int err;
> > +int err, cur_decoding;
> >
> >  /* release the async lock, permitting blocked hwaccel threads to
> >   * go forward while we are in this function */
> > @@ -544,6 +544,13 @@ int ff_thread_decode_frame(AVCodecContext
> > *avctx,
> >
> >  if (fctx->next_decoding >= avctx->thread_count) fctx->next_decoding =
> 0;
> >
> > +/* update hwaccel_priv_data from decoding thread */
> > +cur_decoding = fctx->next_decoding - 1;
> > +if (cur_decoding < 0) cur_decoding += avctx->thread_count;
> > +
> > +p = &fctx->threads[cur_decoding];
> > +avctx->internal->hwaccel_priv_data = p->avctx->internal-
> > >hwaccel_priv_data;
> > +
> >  fctx->next_finished = finished;
> >
> >  /* return the size of the consumed packet if no error occurred */
> > --
> > 2.7.4
> 
> 
> Since previous concerns in https://patchwork.ffmpeg.org/patch/13723/
> could be  addressed in this version, ping for comments.
> 
A kind ping, comments are welcome.

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

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

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, July 24, 2019 21:17
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale
> 
> On 7/24/19, Fu, Linjie  wrote:
> >> -Original Message-
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Paul B Mahol
> >> Sent: Wednesday, July 24, 2019 17:42
> >> To: FFmpeg development discussions and patches  >> de...@ffmpeg.org>
> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> >> autoscale to disable/enable the default scale
> >>
> >> On 7/24/19, Fu, Linjie  wrote:
> >> >> -Original Message-
> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> >> Behalf
> >> >> Of Gyan
> >> >> Sent: Wednesday, July 24, 2019 12:28
> >> >> To: ffmpeg-devel@ffmpeg.org
> >> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add -
> >> >> autoscale to disable/enable the default scale
> >> >>
> >> >>
> >> >>
> >> >> On 24-07-2019 08:15 AM, Fu, Linjie wrote:
> >> >> >> -Original Message-
> >> >> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org]
> On
> >> >> Behalf
> >> >> >> Of Gyan
> >> >> >> Sent: Wednesday, July 24, 2019 00:49
> >> >> >> To: ffmpeg-devel@ffmpeg.org
> >> >> >> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter: add
> >> >> >> -
> >> >> >> autoscale to disable/enable the default scale
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On 22-07-2019 01:40 PM, Fu, Linjie wrote:
> >> >> >>>> -Original Message-
> >> >> >>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org]
> >> On
> >> >> >> Behalf
> >> >> >>>> Of Gyan
> >> >> >>>> Sent: Saturday, July 20, 2019 13:29
> >> >> >>>> To: ffmpeg-devel@ffmpeg.org
> >> >> >>>> Subject: Re: [FFmpeg-devel] [PATCH, v3] fftools/ffmpeg_filter:
> >> >> >>>> add
> >> -
> >> >> >>>> autoscale to disable/enable the default scale
> >> >> >>>>> diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> >> >> >>>>> index cd35eb49c8..99121b6981 100644
> >> >> >>>>> --- a/doc/ffmpeg.texi
> >> >> >>>>> +++ b/doc/ffmpeg.texi
> >> >> >>>>> +@item -autoscale
> >> >> >>>>> +Automatically scale the video according to the resolution of
> >> >> >>>>> first
> >> >> frame.
> >> >> >>>>> +Enabled by default, use @option{-noautoscale} to disable 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. 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.
> >> >> >>>> Since the auto scaling happens at the end of the graph, what may
> >> the
> >> >> >>>> "additional explicit processing" be?
> >> >> >>> Vpp processing may not be influenced,  a warning in transcode is
> >> >> >>> needed.
> >> >> >>> The expression seems to 

Re: [FFmpeg-devel] [PATCH, RFC 2/2] fftools/ffmpeg: add dynamic resolution encode support for libvpx-vp9

[Fu, Linjie]

> -Original Message-
> From: Nicolas George [mailto:geo...@nsup.org]
> Sent: Sunday, July 28, 2019 17:58
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: Re: [FFmpeg-devel] [PATCH, RFC 2/2] fftools/ffmpeg: add dynamic
> resolution encode support for libvpx-vp9
> 
> Linjie Fu (12019-07-28):
> > +enc->internal->draining = 0;
> 
> "internal" means you should not be doing that.
> 
Sure,  will address this, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

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

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Monday, July 29, 2019 00:48
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v4 1/2] fftools/ffmpeg_filter: add -
> autoscale to disable/enable the default scale
> 
> On Sun, Jul 28, 2019 at 05:54:24PM +0800, Linjie Fu wrote:
> > Currently, ffmpeg inserts scale filter by default in the filter graph
> > to force the whole decoded stream to scale into the same size with the
> > first frame. It's not quite make sense in resolution changing cases if
> > user wants the rawvideo without any scale.
> >
> > Using autoscale/noautoscale to indicate whether auto inserting the scale
> > filter in the filter graph:
> > -noautoscale or -autoscale 0:
> > disable the default auto scale filter inserting.
> >
> > Update docs.
> >
> > Signed-off-by: U. Artie Eoff 
> > Signed-off-by: Linjie Fu 
> > ---
> >  doc/ffmpeg.texi | 16 
> >  fftools/ffmpeg.c|  1 +
> >  fftools/ffmpeg.h|  4 
> >  fftools/ffmpeg_filter.c |  2 +-
> >  fftools/ffmpeg_opt.c|  8 
> >  5 files changed, 26 insertions(+), 5 deletions(-)
> 
> I think this is ok-ish but it would be more robust if encoders would
> have a CODEC_CAP listing if they actually support changing resolution
> 

AV_CODEC_CAP_VARIABLE_DIMENSIONS is added,  and currently set for rawvideo and 
libvpx.
New patch set has been sent.

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

Re: [FFmpeg-devel] [PATCH 3/4] fftools/ffmpeg: support variable dimension encode

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Almer
> Sent: Tuesday, July 30, 2019 00:44
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 3/4] fftools/ffmpeg: support variable
> dimension encode
> 
> On 7/29/2019 11:44 AM, Linjie Fu wrote:
> > Flush encoders when dimension change happens, reset draining to resume
> > encode.
> >
> > If encoder doesn't support variable dimension, stop encoding and
> > report errors.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  fftools/ffmpeg.c| 13 +
> >  libavcodec/encode.c |  4 
> >  2 files changed, 17 insertions(+)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index 5d52430..8ceeaaa 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -130,6 +130,7 @@ static void do_video_stats(OutputStream *ost, int
> frame_size);
> >  static BenchmarkTimeStamps get_benchmark_time_stamps(void);
> >  static int64_t getmaxrss(void);
> >  static int ifilter_has_all_input_formats(FilterGraph *fg);
> > +static void flush_encoders(void);
> >
> >  static int run_as_daemon  = 0;
> >  static int nb_frames_dup = 0;
> > @@ -1067,6 +1068,18 @@ static void do_video_out(OutputFile *of,
> >  InputStream *ist = NULL;
> >  AVFilterContext *filter = ost->filter->filter;
> >
> > +/* flush encoders in dynamic resolution encode */
> > +if (next_picture && (enc->width != next_picture->width ||
> > + enc->height != next_picture->height)) {
> > +flush_encoders();
> > +
> > +if (!(enc->codec->capabilities &
> AV_CODEC_CAP_VARIABLE_DIMENSIONS)) {
> > +av_log(NULL, AV_LOG_ERROR, "Dynamic resolution encode "
> > +"is not supported by %s.\n", enc->codec->name);
> > +goto error;
> > +}
> > +}
> > +
> >  if (ost->source_index >= 0)
> >  ist = input_streams[ost->source_index];
> >
> > diff --git a/libavcodec/encode.c b/libavcodec/encode.c
> > index d12c425..9303bc9 100644
> > --- a/libavcodec/encode.c
> > +++ b/libavcodec/encode.c
> > @@ -389,6 +389,10 @@ int attribute_align_arg
> avcodec_send_frame(AVCodecContext *avctx, const AVFrame
> >  if (!avcodec_is_open(avctx) || !av_codec_is_encoder(avctx->codec))
> >  return AVERROR(EINVAL);
> >
> > +/* reset draining when encoder is flushed in variable dimensions
> encoding */
> > +if (frame)
> > +avctx->internal->draining = 0;
> 
> This is an API change that can break some workflows.
> 
> avcodec_flush_buffers() is the public function meant to flush an
> AVCodecContext.
> 

Thanks for the hint, updated.

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

Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Tuesday, July 30, 2019 16:06
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add
> AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> 
> Am Di., 30. Juli 2019 um 06:46 Uhr schrieb Linjie Fu :
> >
> > Add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag to indicate
> > whether encoder supports variable dimension encoding.
> 
> Isn't this about variable (or "changing") "resolutions" instead of dimensions?
> 

Comment is welcome and "variable resolutions" is good.
But is "dimension" not quite suitable for the meaning of "variable size"?

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

Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Almer
> Sent: Tuesday, July 30, 2019 21:27
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add
> AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> 
> On 7/30/2019 6:33 AM, Carl Eugen Hoyos wrote:
> > Am Di., 30. Juli 2019 um 11:25 Uhr schrieb Fu, Linjie :
> >>
> >>> -Original Message-
> >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >>> Of Carl Eugen Hoyos
> >>> Sent: Tuesday, July 30, 2019 16:06
> >>> To: FFmpeg development discussions and patches  >>> de...@ffmpeg.org>
> >>> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add
> >>> AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> >>>
> >>> Am Di., 30. Juli 2019 um 06:46 Uhr schrieb Linjie Fu 
> >>> :
> >>>>
> >>>> Add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag to indicate
> >>>> whether encoder supports variable dimension encoding.
> >>>
> >>> Isn't this about variable (or "changing") "resolutions" instead of
> dimensions?
> >>>
> >>
> >> Comment is welcome and "variable resolutions" is good.
> >
> >> But is "dimension" not quite suitable for the meaning of "variable size"?
> >
> > It took me some time to understand that "dimension" implies resolution,
> > especially since the FFmpeg documentation mentions resolution iirc.
> >
> > Carl Eugen
> 
> We have a AV_SIDE_DATA_PARAM_CHANGE_DIMENSIONS flag to signal
> resolution
> changes, so both words seem to be used interchangeably.
> 
> This also makes me think that the existing
> AV_CODEC_CAP_PARAM_CHANGE
> codec cap can be used for this already, without the need for a new one.
> It should a matter of using AV_PKT_DATA_PARAM_CHANGE packet side
> data
> afterwards in some form.

Thanks.
Saw the modification in fe75dc8583b65612f3a94144ee090e741dc926d5,
and it seems it was designed for decoder at first, like 
"rawdec/nellymoserdec/interplayvideo".

"Also define a codec capability for codecs that can handle
 parameters changed externally between decoded packets. "

Since currently no encoder is engaged with this flag, it's good for me to reuse 
this if there is no
other concern.

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

Re: [FFmpeg-devel] [PATCH, v2 3/3] lavc/libvpxenc: add dynamic resolution encode support for libvpx

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Zern
> Sent: Thursday, August 1, 2019 07:15
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2 3/3] lavc/libvpxenc: add dynamic
> resolution encode support for libvpx
> 
> Hi,
> 
> On Tue, Jul 30, 2019 at 10:06 PM Linjie Fu  wrote:
> > [...]
> > diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> > index feb52ea..800ba18 100644
> > --- a/libavcodec/libvpxenc.c
> > +++ b/libavcodec/libvpxenc.c
> > @@ -1067,6 +1067,15 @@ static int vpx_encode(AVCodecContext *avctx,
> AVPacket *pkt,
> >  int res, coded_size;
> >  vpx_enc_frame_flags_t flags = 0;
> >
> > +if (frame && (avctx->width != frame->width ||
> > +  avctx->height != frame->height)) {
> > +avctx->width  = frame->width;
> > +avctx->height = frame->height;
> > +
> > +avctx->codec->close(avctx);
> 
> You shouldn't need to destroy the encoder for a resolution change,
> unless I'm missing something. Take a look at resize_test.cc [1].
> 
> [1]
> https://chromium.googlesource.com/webm/libvpx/+/refs/heads/master/te
> st/resize_test.cc#305

Yes, IMHO vp8 supports resolution change in key frame, and for vp9,  resolution 
change
is supported per frame, thus current modification may lead to unnecessary Key 
frames.

Will find a better solution. Thanks.

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

Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Wednesday, July 31, 2019 14:04
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add
> AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> 
> On Tue, Jul 30, 2019 at 10:27:10AM -0300, James Almer wrote:
> > On 7/30/2019 6:33 AM, Carl Eugen Hoyos wrote:
> > > Am Di., 30. Juli 2019 um 11:25 Uhr schrieb Fu, Linjie 
> > > :
> > >>
> > >>> -Original Message-
> > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > >>> Of Carl Eugen Hoyos
> > >>> Sent: Tuesday, July 30, 2019 16:06
> > >>> To: FFmpeg development discussions and patches  > >>> de...@ffmpeg.org>
> > >>> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add
> > >>> AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> > >>>
> > >>> Am Di., 30. Juli 2019 um 06:46 Uhr schrieb Linjie Fu
> :
> > >>>>
> > >>>> Add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag to indicate
> > >>>> whether encoder supports variable dimension encoding.
> > >>>
> > >>> Isn't this about variable (or "changing") "resolutions" instead of
> dimensions?
> > >>>
> > >>
> > >> Comment is welcome and "variable resolutions" is good.
> > >
> > >> But is "dimension" not quite suitable for the meaning of "variable size"?
> > >
> > > It took me some time to understand that "dimension" implies resolution,
> > > especially since the FFmpeg documentation mentions resolution iirc.
> > >
> > > Carl Eugen
> >
> > We have a AV_SIDE_DATA_PARAM_CHANGE_DIMENSIONS flag to signal
> resolution
> > changes, so both words seem to be used interchangeably.
> >
> 
> > This also makes me think that the existing
> AV_CODEC_CAP_PARAM_CHANGE
> > codec cap can be used for this already, without the need for a new one.
> > It should a matter of using AV_PKT_DATA_PARAM_CHANGE packet side
> data
> > afterwards in some form.
> 
> if AV_PKT_DATA_PARAM_CHANGE is used then other parameters would
> need to
> be handled too i think.
> For example pixel format changes alongside width and height.
> And it leaves some areas of uncertanity which may require more flags
> like does a aspect ratio change or a change of one of the colorspace
> parameters need a encoder "flush/restart". (the flush is done from
> outside the encoder in the patch so the code would need to know)
> 
> Also for symmetry, if AV_PKT_DATA_PARAM_CHANGE expects sidedata on
> the input side of the decoder, something should produce matching
> side data on the encoder side.
> 
> encoder -> decoder should continue working. So only a demuxer
> generating the side data could be a problem.

Sounds like a new flag will be more robust?
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/vaapi_encode_h264: add support for a/53 closed caption sei

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Aman Gupta
> Sent: Friday, August 2, 2019 07:33
> To: ffmpeg-devel@ffmpeg.org
> Cc: Aman Gupta 
> Subject: [FFmpeg-devel] [PATCH v2] avcodec/vaapi_encode_h264: add
> support for a/53 closed caption sei
> 
> From: Aman Gupta 
> 
> Signed-off-by: Aman Gupta 
> ---
>  libavcodec/vaapi_encode_h264.c | 24 +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/vaapi_encode_h264.c
> b/libavcodec/vaapi_encode_h264.c
> index f4965d8b09..9860bacb91 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -39,6 +39,7 @@ enum {
>  SEI_TIMING = 0x01,
>  SEI_IDENTIFIER = 0x02,
>  SEI_RECOVERY_POINT = 0x04,
> +SEI_A53_CC = 0x08,
>  };
> 
>  // Random (version 4) ISO 11578 UUID.
> @@ -98,6 +99,8 @@ typedef struct VAAPIEncodeH264Context {
>  H264RawSEIRecoveryPointsei_recovery_point;
>  H264RawSEIUserDataUnregistered sei_identifier;
>  char  *sei_identifier_string;
> +H264RawSEIUserDataRegistered   sei_a53cc;
> +void  *sei_a53cc_data;
> 
>  int aud_needed;
>  int sei_needed;
> @@ -251,6 +254,11 @@ static int
> vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
>  sei->payload[i].payload.recovery_point = 
> priv->sei_recovery_point;
>  ++i;
>  }
> +if (priv->sei_needed & SEI_A53_CC) {
> +sei->payload[i].payload_type =
> H264_SEI_TYPE_USER_DATA_REGISTERED;
> +sei->payload[i].payload.user_data_registered = priv->sei_a53cc;
> +++i;
> +}
> 
>  sei->payload_count = i;
>  av_assert0(sei->payload_count > 0);
> @@ -626,7 +634,8 @@ static int
> vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
>  VAAPIEncodePicture  *prev = pic->prev;
>  VAAPIEncodeH264Picture *hprev = prev ? prev->priv_data : NULL;
>  VAEncPictureParameterBufferH264 *vpic = pic->codec_picture_params;
> -int i;
> +int i, err;
> +size_t sei_a53cc_len;
> 
>  if (pic->type == PICTURE_TYPE_IDR) {
>  av_assert0(pic->display_order == pic->encode_order);
> @@ -700,6 +709,18 @@ static int
> vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
>  priv->sei_needed |= SEI_RECOVERY_POINT;
>  }
> 
> +av_freep(&priv->sei_a53cc_data);

Is this necessary?

> +err = ff_alloc_a53_sei(pic->input_image, 0, &priv->sei_a53cc_data,
> &sei_a53cc_len);

IMHO, an option "a53cc" is needed under "SEI", like 
identifier/timing/recovery_point does.
And check before setting a53_sei will be good.

> +if (err < 0)
> +return err;
> +if (priv->sei_a53cc_data != NULL) {

"If (priv->sei_a53cc_data)" can be enough.

Regards,

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

Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context

[Fu, Linjie]

> -Original Message-
> From: Fu, Linjie
> Sent: Friday, July 12, 2019 04:18
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [PATCH,v2 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9
> without destroy va_context
> 
> VP9 allows resolution changes per frame. Currently in VAAPI, resolution
> changes leads to va context destroy and reinit. This will cause
> reference frame surface lost and produce garbage.
> 
> Though refs surface id could be passed to media driver and found in
> RTtbl, vp9RefList[] in hal layer has already been destroyed. Thus the
> new created VaContext could only got an empty RefList.
> 
> As libva allows re-create surface separately without changing the
> context, this issue could be handled by only recreating hw_frames_ctx.
> 
> Set hwaccel_priv_data_keeping flag for vp9 to only recreating
> hw_frame_ctx when dynamic resolution changing happens.
> 
> Could be verified by:
> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
>   ./resolutions.ivf -pix_fmt p010le -f rawvideo -vframes 20 -y vaapi.yuv
> 
> Signed-off-by: Linjie Fu 
> ---
Ping?
This patch set fixes 1000+ dynamic resolution cases and makes great sense.
Please feel free to comment.

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

Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Tuesday, June 4, 2019 17:11
> To: ffmpeg-devel@ffmpeg.org
> Cc: Mark Thompson 
> Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> vaMapBuffer returns multiple buffers
> 
> > -Original Message-
> > From: Fu, Linjie
> > Sent: Friday, May 31, 2019 08:35
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [PATCH,v2] lavc/vaapi_encode: grow packet if vaMapBuffer
> returns
> > multiple buffers
> >
> > It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to
> map
> > buffer for each slice.
> >
> > Currently, assigning new buffer for pkt when multiple buffer returns
> > from vaMapBuffer will cover the previous encoded pkt data and lead
> > to encode issues.
> >
> > Iterate through the buf_list first to find out the total buffer size
> > needed for the pkt, allocate the whole pkt to avoid repeated reallocation
> > and memcpy, then copy data from each buf to pkt.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> > [v2]: allocate the whole pkt to avoid repeated reallocation
> > and memcpy
> >
> >  libavcodec/vaapi_encode.c | 18 +-
> >  1 file changed, 13 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index 2dda451..9c9e5dd 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -489,6 +489,8 @@ static int vaapi_encode_output(AVCodecContext
> > *avctx,
> >  VAAPIEncodeContext *ctx = avctx->priv_data;
> >  VACodedBufferSegment *buf_list, *buf;
> >  VAStatus vas;
> > +int total_size = 0;
> > +uint8_t *ptr;
> >  int err;
> >
> >  err = vaapi_encode_wait(avctx, pic);
> > @@ -505,15 +507,21 @@ static int vaapi_encode_output(AVCodecContext
> > *avctx,
> >  goto fail;
> >  }
> >
> > +for (buf = buf_list; buf; buf = buf->next)
> > +total_size += buf->size;
> > +
> > +err = av_new_packet(pkt, total_size);
> > +ptr = pkt->data;
> > +
> > +if (err < 0)
> > +goto fail_mapped;
> > +
> >  for (buf = buf_list; buf; buf = buf->next) {
> >  av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes "
> > "(status %08x).\n", buf->size, buf->status);
> >
> > -err = av_new_packet(pkt, buf->size);
> > -if (err < 0)
> > -goto fail_mapped;
> > -
> > -memcpy(pkt->data, buf->buf, buf->size);
> > +memcpy(ptr, buf->buf, buf->size);
> > +ptr += buf->size;
> >  }
> >
> >  if (pic->type == PICTURE_TYPE_IDR)
> > --
> > 2.7.4
> 
> Ping?
> This can fix the encoding issue for vaapi_vp8:
> ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -v verbose -f
> rawvideo -pix_fmt yuv420p -s:v 1280x720 -i ./input_I420.yuv -vf
> 'format=nv12,hwupload' -c:v vp8_vaapi -rc_mode CQP -g 1 -global_quality 14
> -loop_filter_sharpness 0 -loop_filter_level 0 -vframes 10 -y out.ivf

Media driver will return 2 buffers in fact. The first buffer is 
VACodedBufferSegment
buffer which includes encoded output. And the second buffer is extra 
VACodedBufferVP9Status.
https://github.com/intel/media-driver/issues/624

Fixes vp8 encoding issues for core platforms(Kaby Lake) and could be verified.
Ping?

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

Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Tuesday, August 6, 2019 16:27
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> hw_frames_ctx for vp9 without destroy va_context
> 
> On Thu, Jul 11, 2019 at 10:20 AM Linjie Fu  wrote:
> >
> > VP9 allows resolution changes per frame. Currently in VAAPI, resolution
> > changes leads to va context destroy and reinit. This will cause
> > reference frame surface lost and produce garbage.
> >
> > Though refs surface id could be passed to media driver and found in
> > RTtbl, vp9RefList[] in hal layer has already been destroyed. Thus the
> > new created VaContext could only got an empty RefList.
> >
> > As libva allows re-create surface separately without changing the
> > context, this issue could be handled by only recreating hw_frames_ctx.
> >
> > Set hwaccel_priv_data_keeping flag for vp9 to only recreating
> > hw_frame_ctx when dynamic resolution changing happens.
> >
> > Could be verified by:
> > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
> >   ./resolutions.ivf -pix_fmt p010le -f rawvideo -vframes 20 -y vaapi.yuv
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/decode.c| 10 +-
> >  libavcodec/internal.h  |  1 +
> >  libavcodec/pthread_frame.c |  2 ++
> >  libavcodec/vaapi_decode.c  | 40 ++
> --
> >  libavcodec/vaapi_vp9.c |  4 
> >  5 files changed, 34 insertions(+), 23 deletions(-)
> >
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index 0863b82..7b15fa5 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -1254,7 +1254,6 @@ int
> ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
> >
> >  frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
> >
> > -
> >  if (frames_ctx->initial_pool_size) {
> >  // We guarantee 4 base work surfaces. The function above guarantees
> 1
> >  // (the absolute minimum), so add the missing count.
> 
> Unrelated whitespace change

There is  a redundant whitespace here, so I removed it within this patch.

> > @@ -1333,7 +1332,7 @@ static int hwaccel_init(AVCodecContext *avctx,
> >  return AVERROR_PATCHWELCOME;
> >  }
> >
> > -if (hwaccel->priv_data_size) {
> > +if (hwaccel->priv_data_size && !avctx->internal->hwaccel_priv_data) {
> >  avctx->internal->hwaccel_priv_data =
> >  av_mallocz(hwaccel->priv_data_size);
> >  if (!avctx->internal->hwaccel_priv_data)
> > @@ -1396,9 +1395,10 @@ int ff_get_format(AVCodecContext *avctx,
> const enum AVPixelFormat *fmt)
> >  memcpy(choices, fmt, (n + 1) * sizeof(*choices));
> >
> >  for (;;) {
> > -// Remove the previous hwaccel, if there was one.
> > -hwaccel_uninit(avctx);
> > -
> > +// Remove the previous hwaccel, if there was one,
> > +// and no need for keeping.
> > +if (!avctx->internal->hwaccel_priv_data_keeping)
> > +hwaccel_uninit(avctx);
> >  user_choice = avctx->get_format(avctx, choices);
> >  if (user_choice == AV_PIX_FMT_NONE) {
> >  // Explicitly chose nothing, give up.
> 
> There could be a dozen special cases how stuff can go wrong here. What
> if get_format actually returns a different format then the one
> currently in use? Or a software format?
> Just removing this alone is not safe.

Didn't quite get your point.
IMHO,  avctx->internal->hwaccel_priv_data_keeping won't be set in other cases
other than vaapi_vp9, so this patch won't break the default pipeline, and
hwaccel_uninit(avctx) will always be called.

> > diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> > index 5096ffa..7adef08 100644
> > --- a/libavcodec/internal.h
> > +++ b/libavcodec/internal.h
> > @@ -188,6 +188,7 @@ typedef struct AVCodecInternal {
> >   * hwaccel-specific private data
> >   */
> >  void *hwaccel_priv_data;
> > +int hwaccel_priv_data_keeping;
> >
> >  /**
> >   * checks API usage: after codec draining, flush is required to resume
> operation
> > diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c
> > index 36ac0ac..6032818 100644
> > --- a/libavcodec/pthread_frame.c
> > +++ b/libavcodec/pthread_frame.c
> > @@ -283,6 +283,7 @@ static int
> update_context_from_thread(AVCodecContext *dst, AVCodecContext *src,
> >  dst->sample_fmt = src->sample_fmt;
> >  dst->channel_layout = src->channel_layout;
> >  dst->internal->hwaccel_priv_data = 
> > src->internal->hwaccel_priv_data;
> > +dst->internal->hwaccel_priv_data_keeping = src->internal-
> >hwaccel_priv_data_keeping;
> >
> >  if (!!dst->hw_frames_ctx != !!src->hw_frames_ctx ||
> >  (dst->hw_frames_ctx && dst->hw_frames_ctx->data != src-
> >hw_frames_ctx->data)) {
> > @@ -340,6 +341,7 @

Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add support for QSV transpose filter"

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Paul B Mahol
> Sent: Wednesday, August 7, 2019 22:36
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add
> support for QSV transpose filter"
> 
> On Wed, Aug 7, 2019 at 4:34 PM Li, Zhong  wrote:
> 
> > > From: Nicolas George [mailto:geo...@nsup.org]
> > > Sent: Wednesday, August 7, 2019 10:31 PM
> > > To: FFmpeg development discussions and patches
> > > 
> > > Cc: Li, Zhong 
> > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add
> > > support for QSV transpose filter"
> > >
> > > Zhong Li (12019-08-07):
> > > > This reverts commit af3ddd581faf2c3c4748ae589947c662b1a2271e.
> > > >
> > > > Revert it due to the uncorrect subject, should be: "lavf" -> "lavfi"
> > >
> > > The damage to the git log is done, this will just make it worse, IMHO.
> > >
> > > Regards,
> > >
> > > --
> > >   Nicolas George
> >
> > So your suggestion should be: just keep it and do nothing now?
> 
> 
> Please do nothing now, please do not forget it for next time, what is lavf
> and what is lavfi.

Thanks, will keep it in mind.

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

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

Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Friday, August 9, 2019 17:40
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> hw_frames_ctx for vp9 without destroy va_context
> 
> On Tue, Aug 6, 2019 at 10:55 AM Fu, Linjie  wrote:
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > > Of Hendrik Leppkes
> > > Sent: Tuesday, August 6, 2019 16:27
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> recreate
> > > hw_frames_ctx for vp9 without destroy va_context
> > >
> > > On Thu, Jul 11, 2019 at 10:20 AM Linjie Fu  wrote:
> > > >
> > > > VP9 allows resolution changes per frame. Currently in VAAPI, resolution
> > > > changes leads to va context destroy and reinit. This will cause
> > > > reference frame surface lost and produce garbage.
> > > >
> > > > Though refs surface id could be passed to media driver and found in
> > > > RTtbl, vp9RefList[] in hal layer has already been destroyed. Thus the
> > > > new created VaContext could only got an empty RefList.
> > > >
> > > > As libva allows re-create surface separately without changing the
> > > > context, this issue could be handled by only recreating hw_frames_ctx.
> > > >
> > > > Set hwaccel_priv_data_keeping flag for vp9 to only recreating
> > > > hw_frame_ctx when dynamic resolution changing happens.
> > > >
> > > > Could be verified by:
> > > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
> > > >   ./resolutions.ivf -pix_fmt p010le -f rawvideo -vframes 20 -y vaapi.yuv
> > > >
> > > > Signed-off-by: Linjie Fu 
> > > > ---
> > > >  libavcodec/decode.c| 10 +-
> > > >  libavcodec/internal.h  |  1 +
> > > >  libavcodec/pthread_frame.c |  2 ++
> > > >  libavcodec/vaapi_decode.c  | 40 ++---
> -
> > > --
> > > >  libavcodec/vaapi_vp9.c |  4 
> > > >  5 files changed, 34 insertions(+), 23 deletions(-)
> > > >
> > > > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > > > index 0863b82..7b15fa5 100644
> > > > --- a/libavcodec/decode.c
> > > > +++ b/libavcodec/decode.c
> > > > @@ -1254,7 +1254,6 @@ int
> > > ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
> > > >
> > > >  frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
> > > >
> > > > -
> > > >  if (frames_ctx->initial_pool_size) {
> > > >  // We guarantee 4 base work surfaces. The function above
> guarantees
> > > 1
> > > >  // (the absolute minimum), so add the missing count.
> > >
> > > Unrelated whitespace change
> >
> > There is  a redundant whitespace here, so I removed it within this patch.
> >
> > > > @@ -1333,7 +1332,7 @@ static int hwaccel_init(AVCodecContext
> *avctx,
> > > >  return AVERROR_PATCHWELCOME;
> > > >  }
> > > >
> > > > -if (hwaccel->priv_data_size) {
> > > > +if (hwaccel->priv_data_size && !avctx->internal-
> >hwaccel_priv_data) {
> > > >  avctx->internal->hwaccel_priv_data =
> > > >  av_mallocz(hwaccel->priv_data_size);
> > > >  if (!avctx->internal->hwaccel_priv_data)
> > > > @@ -1396,9 +1395,10 @@ int ff_get_format(AVCodecContext *avctx,
> > > const enum AVPixelFormat *fmt)
> > > >  memcpy(choices, fmt, (n + 1) * sizeof(*choices));
> > > >
> > > >  for (;;) {
> > > > -// Remove the previous hwaccel, if there was one.
> > > > -hwaccel_uninit(avctx);
> > > > -
> > > > +// Remove the previous hwaccel, if there was one,
> > > > +// and no need for keeping.
> > > > +if (!avctx->internal->hwaccel_priv_data_keeping)
> > > > +hwaccel_uninit(avctx);
> > > >  user_choice = avctx->get_format(avctx, choices);
> > > >  if (user_choic

Re: [FFmpeg-devel] [PATCH v2 2/2] vaapi_encode: fix VBR mode generating low bitrates

[Fu, Linjie]

> -Original Message-
> From: Aman Gupta [mailto:a...@tmm1.net] On Behalf Of Aman Gupta
> Sent: Tuesday, August 13, 2019 09:05
> To: ffmpeg-devel@ffmpeg.org
> Cc: s...@jkqxz.net; Fu, Linjie ; Aman Gupta
> 
> Subject: [PATCH v2 2/2] vaapi_encode: fix VBR mode generating low bitrates
> 
> From: Aman Gupta 
> 
> On some Intel chips, sending VAEncMiscParameterTypeRateControl multiple
> times causes the encoder to produce very low bitrates that do not match
> the requested rate controls.
> 
> This is a regression as of af532c921575eb8ee805cc2c64a914f6302442e1. Prior
> to that global params were sent only once at the start of the
> encoding session.
> 
> The broken VBR behavior was observed on:
> 
>   - i5-7260U Kaby Lake
>   - N3060 CherryView
>   - N3710 CherryView
>   - J3455 Broxton
> 
> /cc intel/intel-vaapi-driver#480

If it's a driver related issue, IMHO we'd better have it fixed in specific 
driver.
Also commented on #480.

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

Re: [FFmpeg-devel] [PATCH, RFC, v2 3/3] lavc/libvpxenc: add dynamic resolution encode support for libvpx

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Zern
> Sent: Wednesday, August 14, 2019 07:37
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, RFC, v2 3/3] lavc/libvpxenc: add
> dynamic resolution encode support for libvpx
> 
> Hi,
> 
> On Tue, Aug 13, 2019 at 2:30 AM Linjie Fu  wrote:
> >
> > According to spec, libvpx should support dynamic resolution changes.
> >
> > Add dynamic resolution encoding support in libvpx.
> >
> > Only single pass mode with no look ahead is supported for variable
> > resolution encoding without initialization.
> >
> 
> Do you mean /reinitialization/?

Yes, should be reinitialization exactly.

> 
> > cmdline:
> > ffmpeg -noautoscale -y -i ./reinit-large_420_8-to-small_420_8.h264
> >  -pix_fmt yuv420p -c:v libvpx-vp9 lena.ivf
> >
> 
> Do you have a reference command line for creating the source content?

This clips is accessible at
http://fate-suite.ffmpeg.org/h264/reinit-large_420_8-to-small_420_8.h264

However, mentioned issue could not be reproduced with above clips actually.

> 
> > Filed an issue in
> https://bugs.chromium.org/p/webm/issues/detail?id=1642
> > to fix some memory problem.
> >
> 
> It may be worth getting that bug resolved before landing this change
> if existing library versions are buggy.

Sure, this patch should be hold until bug is fixed in libvpx. 

> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/libvpxenc.c | 24 
> >  1 file changed, 24 insertions(+)
> >
> > diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> > index feb52ea..3d2295d 100644
> > --- a/libavcodec/libvpxenc.c
> > +++ b/libavcodec/libvpxenc.c
> > @@ -1067,6 +1067,28 @@ static int vpx_encode(AVCodecContext *avctx,
> AVPacket *pkt,
> >  int res, coded_size;
> >  vpx_enc_frame_flags_t flags = 0;
> >
> > +if (frame && (avctx->width != frame->width ||
> > +  avctx->height != frame->height)) {
> > +avctx->width  = frame->width;
> > +avctx->height = frame->height;
> > +
> > +struct vpx_codec_enc_cfg new_cfg = { 0 };
> > +memcpy(&new_cfg, ctx->encoder.config.enc,
> > +sizeof(struct vpx_codec_enc_cfg));
> > +
> > +new_cfg.g_w = frame->width;
> > +new_cfg.g_h = frame->height;
> > +if (new_cfg.g_lag_in_frames > 1 ||
> > +new_cfg.g_pass != VPX_RC_ONE_PASS) {
> > +av_log(avctx, AV_LOG_WARNING, "Only single pass mode "
> > +   "with no look ahead is supported for variable "
> > +   "resolution encoding without initialization.\n");
> 
> Would it be better to warn and reinitialize as in your earlier patch
> rather than changing the settings from the user?

Warn and reinitialize seems better for me.

Will resend after all concerns are addressed.
Thanks.

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

Re: [FFmpeg-devel] [PATCH] lavu/hwcontext_vaapi: cope with race map for YUV420P

[Fu, Linjie]

> -Original Message-
> From: Fu, Linjie
> Sent: Thursday, August 1, 2019 12:45
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [PATCH] lavu/hwcontext_vaapi: cope with race map for YUV420P
> 
> There is a race condition for AV_PIX_FMT_YUV420P when mapping from
> pix_fmt
> to fourcc, both VA_FOURCC_I420 and VA_FOURCC_YV12 could be find by
> pix_fmt.
> 
> Currently, vaapi_get_image_format will go through the query results of
> pix_fmt and returned the first matched result according to the declared
> order in driver.This may leads to a wrong image_format.
> 
> Modify to find image_format via fourcc.
> 
> Fix vaapi CSC to I420:
> ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo
> -pix_fmt nv12 -s:v 1280x720 -i NV12.yuv -vf
> 'format=nv12,hwupload,scale_vaapi=format=yuv420p,hwdownload,format=
> yuv420p'
> -f rawvideo -vsync passthrough -vframes 10 -y aa.yuv
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavutil/hwcontext_vaapi.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index cf11764..64f14de 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -63,6 +63,7 @@ typedef struct VAAPIDevicePriv {
>  typedef struct VAAPISurfaceFormat {
>  enum AVPixelFormat pix_fmt;
>  VAImageFormat image_format;
> +unsigned int fourcc;
>  } VAAPISurfaceFormat;
> 
>  typedef struct VAAPIDeviceContext {
> @@ -171,15 +172,21 @@ static int
> vaapi_get_image_format(AVHWDeviceContext *hwdev,
>VAImageFormat **image_format)
>  {
>  VAAPIDeviceContext *ctx = hwdev->internal->priv;
> +VAAPIFormatDescriptor *desc;
>  int i;
> 
> +desc = vaapi_format_from_pix_fmt(pix_fmt);
> +if (!desc || !image_format)
> +goto fail;
> +
>  for (i = 0; i < ctx->nb_formats; i++) {
> -if (ctx->formats[i].pix_fmt == pix_fmt) {
> -if (image_format)
> -*image_format = &ctx->formats[i].image_format;
> +if (ctx->formats[i].fourcc == desc->fourcc) {
> +*image_format = &ctx->formats[i].image_format;
>  return 0;
>  }
>  }
> +
> +fail:
>  return AVERROR(EINVAL);
>  }
> 
> @@ -368,6 +375,7 @@ static int vaapi_device_init(AVHWDeviceContext
> *hwdev)
>  av_log(hwdev, AV_LOG_DEBUG, "Format %#x -> %s.\n",
> fourcc, av_get_pix_fmt_name(pix_fmt));
>  ctx->formats[ctx->nb_formats].pix_fmt  = pix_fmt;
> +ctx->formats[ctx->nb_formats].fourcc   = fourcc;
>  ctx->formats[ctx->nb_formats].image_format = image_list[i];
>  ++ctx->nb_formats;
>  }
> --
> 2.7.4
A gentle ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavf/vf_deinterlace_vaapi: flush queued frame in field mode

[Fu, Linjie]

> -Original Message-
> From: Fu, Linjie
> Sent: Friday, August 2, 2019 17:54
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [PATCH] lavf/vf_deinterlace_vaapi: flush queued frame in field
> mode
> 
> Add deint_vaapi_request_frame for deinterlace_vaapi, send NULL frame
> to flush the queued frame.
> 
> Fix the frame drop issue in field mode:
> 
> ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -v verbose -c:v
> h264 -i ./input.h264 -vf 'format=nv12|vaapi,hwupload,
> deinterlace_vaapi=mode=bob:rate=field,hwdownload,format=nv12'
> -pix_fmt yuv420p -f rawvideo -vsync passthrough -y dump.yuv
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavfilter/vf_deinterlace_vaapi.c | 46
> --
>  1 file changed, 39 insertions(+), 7 deletions(-)
> 
> diff --git a/libavfilter/vf_deinterlace_vaapi.c
> b/libavfilter/vf_deinterlace_vaapi.c
> index 72d0349..c811327 100644
> --- a/libavfilter/vf_deinterlace_vaapi.c
> +++ b/libavfilter/vf_deinterlace_vaapi.c
> @@ -48,6 +48,9 @@ typedef struct DeintVAAPIContext {
>  intqueue_count;
>  AVFrame   *frame_queue[MAX_REFERENCES];
>  intextra_delay_for_timestamps;
> +
> +inteof;
> +intprev_pts;
>  } DeintVAAPIContext;
> 
>  static const char *deint_vaapi_mode_name(int mode)
> @@ -190,11 +193,16 @@ static int deint_vaapi_filter_frame(AVFilterLink
> *inlink, AVFrame *input_frame)
>  void *filter_params_addr = NULL;
>  int err, i, field, current_frame_index;
> 
> -av_log(avctx, AV_LOG_DEBUG, "Filter input: %s, %ux%u (%"PRId64").\n",
> -   av_get_pix_fmt_name(input_frame->format),
> -   input_frame->width, input_frame->height, input_frame->pts);
> +// NULL frame is used to flush the queue in field mode
> +if (input_frame)
> +av_log(avctx, AV_LOG_DEBUG, "Filter input: %s, %ux%u
> (%"PRId64").\n",
> +av_get_pix_fmt_name(input_frame->format),
> +input_frame->width, input_frame->height, input_frame->pts);
> +else if (ctx->field_rate == 1) {
> +return 0;
> +}
> 
> -if (ctx->queue_count < ctx->queue_depth) {
> +if (input_frame && ctx->queue_count < ctx->queue_depth) {
>  ctx->frame_queue[ctx->queue_count++] = input_frame;
>  if (ctx->queue_count < ctx->queue_depth) {
>  // Need more reference surfaces before we can continue.
> @@ -291,6 +299,8 @@ static int deint_vaapi_filter_frame(AVFilterLink *inlink,
> AVFrame *input_frame)
>  if (ctx->field_rate == 2) {
>  if (field == 0)
>  output_frame->pts = 2 * input_frame->pts;
> +else if (ctx->eof)
> +output_frame->pts = 3 * input_frame->pts - ctx->prev_pts;
>  else
>  output_frame->pts = input_frame->pts +
>  ctx->frame_queue[current_frame_index + 1]->pts;
> @@ -306,6 +316,8 @@ static int deint_vaapi_filter_frame(AVFilterLink *inlink,
> AVFrame *input_frame)
>  break;
>  }
> 
> +ctx->prev_pts = input_frame->pts;
> +
>  return err;
> 
>  fail:
> @@ -315,6 +327,25 @@ fail:
>  return err;
>  }
> 
> +static int deint_vaapi_request_frame(AVFilterLink *link)
> +{
> +AVFilterContext *avctx = link->src;
> +DeintVAAPIContext *ctx   = avctx->priv;
> +int ret;
> +
> +if (ctx->eof)
> +return AVERROR_EOF;
> +
> +ret = ff_request_frame(link->src->inputs[0]);
> +if (ret == AVERROR_EOF) {
> +ctx->eof = 1;
> +deint_vaapi_filter_frame(link->src->inputs[0], NULL);
> +} else if (ret < 0)
> +return ret;
> +
> +return 0;
> +}
> +
>  static av_cold int deint_vaapi_init(AVFilterContext *avctx)
>  {
>  VAAPIVPPContext *vpp_ctx = avctx->priv;
> @@ -376,9 +407,10 @@ static const AVFilterPad deint_vaapi_inputs[] = {
> 
>  static const AVFilterPad deint_vaapi_outputs[] = {
>  {
> -.name = "default",
> -.type = AVMEDIA_TYPE_VIDEO,
> -.config_props = &deint_vaapi_config_output,
> +.name   = "default",
> +.type   = AVMEDIA_TYPE_VIDEO,
> +.request_frame  = &deint_vaapi_request_frame,
> +.config_props   = &deint_vaapi_config_output,
>  },
>  { NULL }
>  };
> --
> 2.7.4
Ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavu/hwcontext_vaapi: provide detailed warning if directly mapping fails

[Fu, Linjie]

> -Original Message-
> From: Li, Zhong
> Sent: Wednesday, August 14, 2019 22:37
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH] lavu/hwcontext_vaapi: provide
> detailed warning if directly mapping fails
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Wednesday, August 14, 2019 5:25 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH] lavu/hwcontext_vaapi: provide detailed
> > warning if directly mapping fails
> >
> > Detailed message could be helpful when using
> > hwmap=mode=direct,format=xxx for both qsv and vaapi.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavutil/hwcontext_vaapi.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> >
> 
> Why just give a warning message when you need to return an error?

Previously these messages are hidden in the code, thus a warning info  could be
a more gentle improvement IMHO. (since there will be other error logs prompted
when av_hwframe_map() fails)

It sounds  an error message is necessary. 

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

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

Re: [FFmpeg-devel] [PATCH] lavf/vf_deinterlace_vaapi: flush queued frame in field mode

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Aman Gupta
> Sent: Wednesday, August 14, 2019 10:05
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] lavf/vf_deinterlace_vaapi: flush
> queued frame in field mode
> 
> On Tue, Aug 13, 2019 at 7:01 PM Fu, Linjie  wrote:
> 
> > > -Original Message-
> > > From: Fu, Linjie
> > > Sent: Friday, August 2, 2019 17:54
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Fu, Linjie 
> > > Subject: [PATCH] lavf/vf_deinterlace_vaapi: flush queued frame in field
> > > mode
> > >
> > > Add deint_vaapi_request_frame for deinterlace_vaapi, send NULL frame
> > > to flush the queued frame.
> > >
> > > Fix the frame drop issue in field mode:
> > >
> > > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -v verbose -
> c:v
> > > h264 -i ./input.h264 -vf 'format=nv12|vaapi,hwupload,
> > > deinterlace_vaapi=mode=bob:rate=field,hwdownload,format=nv12'
> > > -pix_fmt yuv420p -f rawvideo -vsync passthrough -y dump.yuv
> > >
> > > Signed-off-by: Linjie Fu 
> > > ---
> > >  libavfilter/vf_deinterlace_vaapi.c | 46
> > > --
> > >  1 file changed, 39 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/libavfilter/vf_deinterlace_vaapi.c
> > > b/libavfilter/vf_deinterlace_vaapi.c
> > > index 72d0349..c811327 100644
> > > --- a/libavfilter/vf_deinterlace_vaapi.c
> > > +++ b/libavfilter/vf_deinterlace_vaapi.c
> > > @@ -48,6 +48,9 @@ typedef struct DeintVAAPIContext {
> > >  intqueue_count;
> > >  AVFrame   *frame_queue[MAX_REFERENCES];
> > >  intextra_delay_for_timestamps;
> > > +
> > > +inteof;
> > > +intprev_pts;
> > >  } DeintVAAPIContext;
> > >
> > >  static const char *deint_vaapi_mode_name(int mode)
> > > @@ -190,11 +193,16 @@ static int deint_vaapi_filter_frame(AVFilterLink
> > > *inlink, AVFrame *input_frame)
> > >  void *filter_params_addr = NULL;
> > >  int err, i, field, current_frame_index;
> > >
> > > -av_log(avctx, AV_LOG_DEBUG, "Filter input: %s, %ux%u
> > (%"PRId64").\n",
> > > -   av_get_pix_fmt_name(input_frame->format),
> > > -   input_frame->width, input_frame->height, input_frame->pts);
> > > +// NULL frame is used to flush the queue in field mode
> > > +if (input_frame)
> > > +av_log(avctx, AV_LOG_DEBUG, "Filter input: %s, %ux%u
> > > (%"PRId64").\n",
> > > +av_get_pix_fmt_name(input_frame->format),
> > > +input_frame->width, input_frame->height, input_frame->pts);
> > > +else if (ctx->field_rate == 1) {
> > > +return 0;
> > > +}
> > >
> > > -if (ctx->queue_count < ctx->queue_depth) {
> > > +if (input_frame && ctx->queue_count < ctx->queue_depth) {
> > >  ctx->frame_queue[ctx->queue_count++] = input_frame;
> > >  if (ctx->queue_count < ctx->queue_depth) {
> > >  // Need more reference surfaces before we can continue.
> > > @@ -291,6 +299,8 @@ static int deint_vaapi_filter_frame(AVFilterLink
> > *inlink,
> > > AVFrame *input_frame)
> > >  if (ctx->field_rate == 2) {
> > >  if (field == 0)
> > >  output_frame->pts = 2 * input_frame->pts;
> > > +else if (ctx->eof)
> > > +output_frame->pts = 3 * input_frame->pts -
> > ctx->prev_pts;
> > >  else
> > >  output_frame->pts = input_frame->pts +
> > >  ctx->frame_queue[current_frame_index + 1]->pts;
> > > @@ -306,6 +316,8 @@ static int deint_vaapi_filter_frame(AVFilterLink
> > *inlink,
> > > AVFrame *input_frame)
> > >  break;
> > >  }
> > >
> > > +ctx->prev_pts = input_frame->pts;
> > > +
> > >  return err;
> > >
> > >  fail:
> > > @@ -315,6 +327,25 @@ fail:
> > >  return err;
> > >  }
> > >
> > > +static int deint_vaapi_request_frame(

Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Tuesday, August 6, 2019 16:12
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>; Mark Thompson 
> Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> vaMapBuffer returns multiple buffers
> 
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Fu, Linjie
> > Sent: Tuesday, June 4, 2019 17:11
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Mark Thompson 
> > Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet
> if
> > vaMapBuffer returns multiple buffers
> >
> > > -Original Message-
> > > From: Fu, Linjie
> > > Sent: Friday, May 31, 2019 08:35
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Fu, Linjie 
> > > Subject: [PATCH,v2] lavc/vaapi_encode: grow packet if vaMapBuffer
> > returns
> > > multiple buffers
> > >
> > > It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to
> > map
> > > buffer for each slice.
> > >
> > > Currently, assigning new buffer for pkt when multiple buffer returns
> > > from vaMapBuffer will cover the previous encoded pkt data and lead
> > > to encode issues.
> > >
> > > Iterate through the buf_list first to find out the total buffer size
> > > needed for the pkt, allocate the whole pkt to avoid repeated reallocation
> > > and memcpy, then copy data from each buf to pkt.
> > >
> > > Signed-off-by: Linjie Fu 
> > > ---
> > > [v2]: allocate the whole pkt to avoid repeated reallocation
> > > and memcpy
> > >
> > >  libavcodec/vaapi_encode.c | 18 +-
> > >  1 file changed, 13 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > > index 2dda451..9c9e5dd 100644
> > > --- a/libavcodec/vaapi_encode.c
> > > +++ b/libavcodec/vaapi_encode.c
> > > @@ -489,6 +489,8 @@ static int vaapi_encode_output(AVCodecContext
> > > *avctx,
> > >  VAAPIEncodeContext *ctx = avctx->priv_data;
> > >  VACodedBufferSegment *buf_list, *buf;
> > >  VAStatus vas;
> > > +int total_size = 0;
> > > +uint8_t *ptr;
> > >  int err;
> > >
> > >  err = vaapi_encode_wait(avctx, pic);
> > > @@ -505,15 +507,21 @@ static int
> vaapi_encode_output(AVCodecContext
> > > *avctx,
> > >  goto fail;
> > >  }
> > >
> > > +for (buf = buf_list; buf; buf = buf->next)
> > > +total_size += buf->size;
> > > +
> > > +err = av_new_packet(pkt, total_size);
> > > +ptr = pkt->data;
> > > +
> > > +if (err < 0)
> > > +goto fail_mapped;
> > > +
> > >  for (buf = buf_list; buf; buf = buf->next) {
> > >  av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes "
> > > "(status %08x).\n", buf->size, buf->status);
> > >
> > > -err = av_new_packet(pkt, buf->size);
> > > -if (err < 0)
> > > -goto fail_mapped;
> > > -
> > > -memcpy(pkt->data, buf->buf, buf->size);
> > > +memcpy(ptr, buf->buf, buf->size);
> > > +ptr += buf->size;
> > >  }
> > >
> > >  if (pic->type == PICTURE_TYPE_IDR)
> > > --
> > > 2.7.4
> >
> > Ping?
> > This can fix the encoding issue for vaapi_vp8:
> > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -v verbose -f
> > rawvideo -pix_fmt yuv420p -s:v 1280x720 -i ./input_I420.yuv -vf
> > 'format=nv12,hwupload' -c:v vp8_vaapi -rc_mode CQP -g 1 -global_quality
> 14
> > -loop_filter_sharpness 0 -loop_filter_level 0 -vframes 10 -y out.ivf
> 
> Media driver will return 2 buffers in fact. The first buffer is
> VACodedBufferSegment
> buffer which includes encoded output. And the second buffer is extra
> VACodedBufferVP9Status.
> https://github.com/intel/media-driver/issues/624
> 
> Fixes vp8 encoding issues for core platforms(Kaby Lake) and could be verified.
> Ping?
> 
Another ping?
Had passed the regression patch check in 
https://github.com/intel-media-ci/ffmpeg/pull/44

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

Re: [FFmpeg-devel] [PATCH] lavf/vf_deinterlace_vaapi: flush queued frame in field mode

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Wednesday, August 21, 2019 04:49
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavf/vf_deinterlace_vaapi: flush
> queued frame in field mode
> 
> On 02/08/2019 10:53, Linjie Fu wrote:
> > Add deint_vaapi_request_frame for deinterlace_vaapi, send NULL frame
> > to flush the queued frame.
> >
> > Fix the frame drop issue in field mode:
> >
> > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -v verbose -c:v
> > h264 -i ./input.h264 -vf 'format=nv12|vaapi,hwupload,
> > deinterlace_vaapi=mode=bob:rate=field,hwdownload,format=nv12'
> > -pix_fmt yuv420p -f rawvideo -vsync passthrough -y dump.yuv
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavfilter/vf_deinterlace_vaapi.c | 46
> --
> >  1 file changed, 39 insertions(+), 7 deletions(-)
> 
> Can you explain in more detail what the problem is here?  What frame is
> being dropped?


Would you please try this clips to see whether it could be reproduced on your 
side?
https://drive.google.com/open?id=11FZlT0vl_GoGjlEuihpZHgbwgVA7yGUV


$ ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 
-hwaccel_output_format vaapi -v verbose -c:v h264 -i ./input.h264 -vf 
'hwupload,deinterlace_vaapi=mode=bob:rate=frame' -f null -

2 frames

$ ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 
-hwaccel_output_format vaapi -v verbose -c:v h264 -i ./input.h264 -vf 
'hwupload,deinterlace_vaapi=mode=bob:rate=field' -f null -

Before applying:
2 frames

After applying:
4 frames 

> With this patch applied, the filter always segfaults for me at the end of the
> stream when set to field rate:

This patch just sends a NULL frame to deint_vaapi_request_frame() at the end.
Since the input_frame is not NULL in the log, it's kind of weird if it triggers 
a segfault.

Is it possible to share the clips to reproduce this?

> $ gdb --args ./ffmpeg_g -hwaccel vaapi -hwaccel_device
> /dev/dri/renderD129 -hwaccel_output_format vaapi -i f100.mp4 -an -vf
> deinterlace_vaapi=rate=field -f null -
> ...
> Thread 1 "ffmpeg_g" received signal SIGSEGV, Segmentation fault.
> 0x55755fb1 in deint_vaapi_filter_frame (inlink=0x59092300,
> input_frame=0x58d42000) at src/libavfilter/vf_deinterlace_vaapi.c:227
> 227 ctx->frame_queue[current_frame_index + i + 1]->data[3];
> (gdb) bt
> #0  0x55755fb1 in deint_vaapi_filter_frame (inlink=0x59092300,
> input_frame=0x58d42000) at src/libavfilter/vf_deinterlace_vaapi.c:227


Thanks for the response.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Wednesday, August 28, 2019 14:51
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format
> 
> 
> 
> > Am 28.08.2019 um 08:22 schrieb Linjie Fu :
> >
> > Add support for packed 4:4:4 pixel format AYUV.
> >
> > It is the format that VAAPI/QSV uses when coping with 4:4:4
> > surfaces.
> 
> > Alpha channel will be set to default value for HEVC REXT
> > hw decode.
> 
> What is the „default value“?
> 

Default zero. (and it should be 255 for display)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/2] swscale: Add swscale and fate support for AYUV

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Wednesday, August 28, 2019 14:58
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] swscale: Add swscale and fate
> support for AYUV
> 
> 
> 
> > Am 28.08.2019 um 08:22 schrieb Linjie Fu :
> >
> > Add swscale support for AYUV and make it more robust.
> 
> The path that converts from AYUV to planar YUV(A) seems to be missing the
> handling of alpha values.

Alpha channel information in AYUV are treated in the same way for RGBA/BGRA and
is reusing rgbaToA_c to handle the alpha values.

When converting AYUV to YUA/YUVA, two methods are acceptable:
- For YUV, just cut the alpha and discard the transparency 
- For format which also contains an alpha channel(YUV444P), copy the alpha 
information seems good.
 
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavu/pixfmt: add AYUV pixel format

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Thursday, August 29, 2019 05:17
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format
> 
> Am Mi., 28. Aug. 2019 um 09:34 Uhr schrieb Fu, Linjie :
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > > Of Carl Eugen Hoyos
> > > Sent: Wednesday, August 28, 2019 14:51
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel
> format
> > >
> > >
> > >
> > > > Am 28.08.2019 um 08:22 schrieb Linjie Fu :
> > > >
> > > > Add support for packed 4:4:4 pixel format AYUV.
> > > >
> > > > It is the format that VAAPI/QSV uses when coping with 4:4:4
> > > > surfaces.
> > >
> > > > Alpha channel will be set to default value for HEVC REXT
> > > > hw decode.
> > >
> > > What is the „default value“?
> > >
> >
> > Default zero. (and it should be 255 for display)
> 
> If this is not a bug in the driver, there is no alpha channel that can be 
> used.
> Rename it to 0YUV and remove the alpha usage.
> 

From the pixel format level, adding AYUV format is for a more 
fundamental/common usage.
It is valid no matter the alpha data is 0 or 255 or specific value to indicate 
the transparency.

And the hardware decode result is an AYUV format with fixed alpha values, so it 
should still be
an AYUV format IMHO.

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

Re: [FFmpeg-devel] [PATCH 2/2] swscale: Add swscale and fate support for AYUV

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Thursday, August 29, 2019 05:18
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] swscale: Add swscale and fate
> support for AYUV
> 
> Am Mi., 28. Aug. 2019 um 09:52 Uhr schrieb Fu, Linjie :
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > > Of Carl Eugen Hoyos
> > > Sent: Wednesday, August 28, 2019 14:58
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 2/2] swscale: Add swscale and fate
> > > support for AYUV
> > >
> > >
> > >
> > > > Am 28.08.2019 um 08:22 schrieb Linjie Fu :
> > > >
> > > > Add swscale support for AYUV and make it more robust.
> > >
> > > The path that converts from AYUV to planar YUV(A) seems to be missing
> the
> > > handling of alpha values.
> >
> > Alpha channel information in AYUV are treated in the same way for
> RGBA/BGRA and
> > is reusing rgbaToA_c to handle the alpha values.
> >
> > When converting AYUV to YUA/YUVA, two methods are acceptable:
> > - For YUV, just cut the alpha and discard the transparency
> > - For format which also contains an alpha channel(YUV444P), copy the
> > alpha information seems good.
> 
> But since the input does not contain (valid) alpha, this does not apply.

If we convert from a input with valid alpha, then it makes sense. (like ARGB to 
AYUV)

And IMHO, swscale function should focus on CSC itself and should be able to 
cope with
the color space convert even if the alpha data is kind of not valid.
The validation judgement for alpha may be better if it was implemented in the 
user level.

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

Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Thursday, August 29, 2019 21:31
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format
> 
> 
> 
> > Am 29.08.2019 um 14:30 schrieb Hendrik Leppkes :
> >
> >> On Thu, Aug 29, 2019 at 1:47 PM Carl Eugen Hoyos 
> wrote:
> >>
> >>
> >>
> >> Am 29.08.2019 um 03:34 schrieb Fu, Linjie :
> >>
> >>>> -Original Message-
> >>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >>>> Of Carl Eugen Hoyos
> >>>> Sent: Thursday, August 29, 2019 05:17
> >>>> To: FFmpeg development discussions and patches  >>>> de...@ffmpeg.org>
> >>>> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel
> format
> >>>>
> >>>>>> Am Mi., 28. Aug. 2019 um 09:34 Uhr schrieb Fu, Linjie
> :
> >>>>>>
> >>>>>> -Original Message-
> >>>>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org]
> On
> >>>> Behalf
> >>>>>> Of Carl Eugen Hoyos
> >>>>>> Sent: Wednesday, August 28, 2019 14:51
> >>>>>> To: FFmpeg development discussions and patches  >>>>>> de...@ffmpeg.org>
> >>>>>> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV
> pixel
> >>>> format
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Am 28.08.2019 um 08:22 schrieb Linjie Fu :
> >>>>>>>
> >>>>>>> Add support for packed 4:4:4 pixel format AYUV.
> >>>>>>>
> >>>>>>> It is the format that VAAPI/QSV uses when coping with 4:4:4
> >>>>>>> surfaces.
> >>>>>>
> >>>>>>> Alpha channel will be set to default value for HEVC REXT
> >>>>>>> hw decode.
> >>>>>>
> >>>>>> What is the „default value“?
> >>>>>
> >>>>> Default zero. (and it should be 255 for display)
> >>>>
> >>>> If this is not a bug in the driver, there is no alpha channel that can be
> used.
> >>>> Rename it to 0YUV and remove the alpha usage.
> >>>
> >>> From the pixel format level, adding AYUV format is for a more
> fundamental/common usage.
> >>
> >> Yes, but the new pixel format will only be accepted if it is needed for
> hardware compatibility.
> >> If the hardware only supports 0YUV, it cannot be used to argue in favour
> of a new AYUV format.
> >>
> >
> > AYUV is a standard format used on Windows and documented by Microsoft
> 
> > as the recommended 4:4:4 8-bit
> 
> Sorry, I missed this:
> This is not the format suggested in this posted patch.
> (It is the format I suggested.)
> 
> > format for all purposes. Its hardly a
> > niche format. Its perfectly appropriate to support it.

Got the concern.

If we need a reason to support this standard pixel format apart
from the hardware compatibility, it could be some requirements like CSC from
ARGB to YUV and don't want to lose the alpha channel information:
https://stackoverflow.com/questions/6023565/argb-to-yuv-color-spaces-in-net

"How to convert image beetween ARGB and YUV in c#?
I found formulas describing RGB to YUV conversion. So what should I do with 
alpha channel? "

Thus AYUV will make more sense.

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