Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: Fix bitrate_limit to allow AVC encode in limited bitrate
> -Original Message- > From: ffmpeg-devel On Behalf Of Fu, > Linjie > Sent: Friday, October 18, 2019 16:50 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: Fix bitrate_limit to allow > AVC encode in limited bitrate > > > -Original Message- > > From: Fu, Linjie > > Sent: Tuesday, October 15, 2019 15:56 > > To: ffmpeg-devel@ffmpeg.org > > Cc: Fu, Linjie > > Subject: [PATCH] lavc/qsvenc: Fix bitrate_limit to allow AVC encode in > limited > > bitrate > > > > MFXVideoENCODE_Query calls CheckVideoParamQueryLike in MSDK and > > will determine whether to set param.mfx.TargetKbps to the allowed > > minTargetKbps according to the bitrate_limit in extco2 buffer. > > > > Thus q->param.ExtParam must be set before MFXVideoENCODE_Query in > > case > > minTargetKbps is written to TargetKbps by default. > > > > 1080P AVC encoding with option "-bitrate_limit 0 -b:v 100k": > > Before patch: > > 902 kbps > > After patch: > > 156 kbps > > Signed-off-by: Linjie Fu > > --- > > libavcodec/qsvenc.c | 38 +++--- > > 1 file changed, 19 insertions(+), 19 deletions(-) > > Ping. > This is reported by Mann, J in: > https://software.intel.com/en-us/forums/intel-media-sdk/topic/815938 > > - linjie 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] ffmpeg-qsv: Is opaque memory allocation path used in ffmpeg-qsv?
> -Original Message- > From: ffmpeg-devel On Behalf Of > Rogozhkin, Dmitry V > Sent: Friday, October 25, 2019 05:17 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] ffmpeg-qsv: Is opaque memory allocation path > used in ffmpeg-qsv? > > On Thu, 2019-10-24 at 17:12 +0200, Max Dmitrichenko wrote: > > Hi, > > > > Just have a look at any usage as: ffmpeg -hwaccel qsv ... > > I looked into these 3 command lines on Linux: > > ffmpeg -hwaccel qsv -c:v h264_qsv -i AUD_MW_E.264 \ >-vf hwdownload,format=nv12 -pix_fmt yuv420p \ >AUD_MW.yuv > > ffmpeg -hwaccel qsv -c:v h264_qsv -i AUD_MW_E.264 \ >-c:v hevc_qsv -b:v 5M AUD_MW_E.hevc > > ffmpeg -init_hw_device qsv=hw \ >-filter_hw_device hw -f rawvideo -pix_fmt \ >yuv420p -s:v 176x144 -i AUD_MW.yuv -vf \ >hwupload=extra_hw_frames=64,format=qsv \ >-c:v h264_qsv -b:v 5M -frames:v 10 \ >-y ./AUD_MW_E.h264 > > For what I see, none of the them is using QSV opaque memory. For the > first 2 command lines ffmpeg explicitly prints (w/ -loglevel debug): > > [h264_qsv @ 0x34f6980] Decoder: output is video memory surface > > Besides, I checked w/ manual printfs from the code - opaque is not > used. > > Hence, this question: is actually qsv opaque memory path used anywhere > in ffmpeg.exe sample or in other libavcodec/libavfilter based > applications? Is there Linux/Windows difference which I don't notice in > code review? > I didn't see MFX_MEMTYPE_OPAQUE_FRAME set for frames_hwctx->frame_type in mainline ffmpeg application. BTW, in the frame_allocator used for MFXVideoCORE_SetFrameAllocator(), https://github.com/FFmpeg/FFmpeg/blob/6f2a3958cfac135c60b509a61a4fd39432d8f9a9/libavcodec/qsv.c#L562 only MFX_MEMTYPE_INTERNAL_FRAME and MFX_MEMTYPE_EXTERNAL_FRAME is supported as an allocation request since commit: 4ab61cd983b539749bd621ea271624ddb5196a8e (For VPP, MFX_MEMTYPE_FROM_VPPIN is supported) - 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/qsvenc: Fix bitrate_limit to allow AVC encode in limited bitrate
> -Original Message- > From: Fu, Linjie > Sent: Tuesday, October 15, 2019 15:56 > To: ffmpeg-devel@ffmpeg.org > Cc: Fu, Linjie > Subject: [PATCH] lavc/qsvenc: Fix bitrate_limit to allow AVC encode in limited > bitrate > > MFXVideoENCODE_Query calls CheckVideoParamQueryLike in MSDK and > will determine whether to set param.mfx.TargetKbps to the allowed > minTargetKbps according to the bitrate_limit in extco2 buffer. > > Thus q->param.ExtParam must be set before MFXVideoENCODE_Query in > case > minTargetKbps is written to TargetKbps by default. > > 1080P AVC encoding with option "-bitrate_limit 0 -b:v 100k": > Before patch: > 902 kbps > After patch: > 156 kbps > Signed-off-by: Linjie Fu > --- > libavcodec/qsvenc.c | 38 +++--- > 1 file changed, 19 insertions(+), 19 deletions(-) Ping. This is reported by Mann, J in: https://software.intel.com/en-us/forums/intel-media-sdk/topic/815938 - 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
> -Original Message-
> From: ffmpeg-devel On Behalf Of Fu,
> Linjie
> Sent: Sunday, September 29, 2019 09:19
> To: Li, Zhong ; FFmpeg development discussions and
> patches
> Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> vaMapBuffer returns multiple buffers
>
> > -Original Message-
> > From: Li, Zhong
> > Sent: Friday, September 13, 2019 00:05
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Cc: Fu, Linjie
> > Subject: RE: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> > vaMapBuffer returns multiple buffers
> >
> > > From: ffmpeg-devel On Behalf Of
> > Linjie Fu
> > > Sent: Friday, May 31, 2019 8:35 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Fu, Linjie
> > > Subject: [FFmpeg-devel] [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
> >
> > LGTM
>
> Thanks for review.
> A kindly ping.
>
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/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> -Original Message- > From: ffmpeg-devel On Behalf Of Fu, > Linjie > Sent: Wednesday, September 11, 2019 15:12 > 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 > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > Of Fu, Linjie > > Sent: Saturday, August 31, 2019 12:40 > > 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 > > > > > -Original Message----- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > Behalf > > > Of Fu, Linjie > > > Sent: Thursday, August 1, 2019 22:51 > > > 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 > > > > > > > -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? > > > > Ping for this patch set? > > https://patchwork.ffmpeg.org/patch/14122/ > > https://patchwork.ffmpeg.org/patch/14139/ > > https://patchwork.ffmpeg.org/patch/14140/ > > > Anything I could do for this patch set? Another kindly 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] avcodec/qsv: polling free synchronization
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Dmitry Rogozhkin
> Sent: Wednesday, October 9, 2019 21:28
> To: ffmpeg-devel@ffmpeg.org
> Cc: Orlov, Andrey
> Subject: [FFmpeg-devel] [PATCH] avcodec/qsv: polling free synchronization
>
> From: Andrey Orlov
>
> synchronization by sync point after DEVICE_BUSY
>
> Fixes: CPU usage on AVC decode cases (18% -> 9%)
> ---
> libavcodec/qsv.c | 17 +
> libavcodec/qsv_internal.h | 2 ++
> libavcodec/qsvdec.c | 12
> libavcodec/qsvdec.h | 2 ++
> libavcodec/qsvenc.c | 13 +
> libavcodec/qsvenc.h | 2 ++
> 6 files changed, 40 insertions(+), 8 deletions(-)
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -457,8 +457,12 @@ static int qsv_decode(AVCodecContext *avctx,
> QSVContext *q,
>
> ret = MFXVideoDECODE_DecodeFrameAsync(q->session, avpkt->size ?
> : NULL,
>insurf, , sync);
> +
> +if (ret == MFX_ERR_NONE)
> +q->last_dec_sync = *sync;
> +
> if (ret == MFX_WRN_DEVICE_BUSY)
> -av_usleep(500);
Since av_usleep is removed, "libavutil/time.h" is redundant and should be
removed as well.
> +ff_qsv_handle_device_busy(>session, >last_dec_sync, ,
> 500);
If the value of sleep is hardcode to 500, is it still necessary to pass it as a
parameter?
>
> } while (ret == MFX_WRN_DEVICE_BUSY || ret ==
> MFX_ERR_MORE_SURFACE);
>
> @@ -510,9 +514,9 @@ static int qsv_decode(AVCodecContext *avctx,
> QSVContext *q,
> out_frame->queued = 0;
>
> if (avctx->pix_fmt != AV_PIX_FMT_QSV) {
> -do {
> -ret = MFXVideoCORE_SyncOperation(q->session, *sync, 1000);
> -} while (ret == MFX_WRN_IN_EXECUTION);
> +ret = MFXVideoCORE_SyncOperation(q->session, *sync,
> MFX_INFINITE);
> +if (ret < 0)
> +return ret;
> }
>
> av_freep();
> diff --git a/libavcodec/qsvdec.h b/libavcodec/qsvdec.h
> index dec1f61..d27ea68 100644
> --- a/libavcodec/qsvdec.h
> +++ b/libavcodec/qsvdec.h
> @@ -72,6 +72,8 @@ typedef struct QSVContext {
>
> mfxExtBuffer **ext_buffers;
> int nb_ext_buffers;
> +
> +mfxSyncPoint last_dec_sync;
> } QSVContext;
>
> extern const AVCodecHWConfigInternal *ff_qsv_hw_configs[];
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index ba85d64..bd5dd75 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1368,8 +1368,13 @@ static int encode_frame(AVCodecContext *avctx,
> QSVEncContext *q,
>
> do {
> ret = MFXVideoENCODE_EncodeFrameAsync(q->session, enc_ctrl, surf,
> bs, sync);
> +
> +if (ret == MFX_ERR_NONE)
> +q->last_enc_sync = *sync;
> +
> if (ret == MFX_WRN_DEVICE_BUSY)
> -av_usleep(500);
Same here.
- 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] lavc/vaapi_encode: add support for maxframesize
Ping for the patch set: https://patchwork.ffmpeg.org/patch/13949/ https://patchwork.ffmpeg.org/patch/13950/ linjie binDZvhyPLKen.bin Description: FFmpeg-devel-v3-1-2-lavc-vaapi_encode-add-support-for-maxframesize.patch binrlGxg22TJb.bin Description: FFmpeg-devel-2-2-doc-vaapi_encode-add-documentations-for-max_frame_size.patch ___ ffmpeg-devel mailing list ffmpeg-devel@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/qsv: remove vaapi device free function
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Zhong Li
> Sent: Tuesday, October 8, 2019 12:55
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong
> Subject: [FFmpeg-devel] [PATCH] lavc/qsv: remove vaapi device free
> function
>
> It is not needed since av_buffer_unref() will call it internally
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsv.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index a43f0d5..81fa4a8 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -835,10 +835,6 @@ int ff_qsv_close_internal_session(QSVSession *qs)
> qs->session = NULL;
> }
> #ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE
> -if (qs->va_device_ctx) {
> -qs->va_device_ctx->free(qs->va_device_ctx);
> -}
> -
> av_buffer_unref(>va_device_ref);
> #endif
> return 0;
> --
> 2.7.4
LGTM.
Also addressed some unexpected crashes when "vframes" is set.
- 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 v1] avcodec/h264_parse: decode sps before pps
> -Original Message-
> From: ffmpeg-devel On Behalf Of Jun
> Li
> Sent: Tuesday, October 8, 2019 05:42
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v1] avcodec/h264_parse: decode sps
> before pps
>
> Fix ticket #6422
> The content put pps before sps, which is not a common case. The change
> just put decoding sps before pps, just for compability.
>
> Signed-off-by: Jun Li
> ---
> libavcodec/h264_parse.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
> index 352ffea948..26aaa751ad 100644
> --- a/libavcodec/h264_parse.c
> +++ b/libavcodec/h264_parse.c
> @@ -373,35 +373,36 @@ static int decode_extradata_ps(const uint8_t *data,
> int size, H264ParamSets *ps,
> goto fail;
> }
>
> -for (i = 0; i < pkt.nb_nals; i++) {
> +/* decode sps before pps, just in case some bitstream put pps before sps.
> */
> +for(i = 0; i < pkt.nb_nals; i++) {
Nit: Missing space here.
- 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: remove consistency check of depth for each component
Please ignore this patch, will send a new one.
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Linjie Fu
> Sent: Tuesday, September 24, 2019 17:29
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: remove consistency
> check of depth for each component
>
> Previously, consistency check of depth is introduced to make sure
> each component of the pixel format has the same depth.
>
> Since Y410(with a different depth in alpha channel) is supported for
> ICL+, this check should be removed to make the encoder work.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/vaapi_encode.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index cb598d5..ba7a432 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1236,14 +1236,6 @@ static av_cold int
> vaapi_encode_profile_entrypoint(AVCodecContext *avctx)
> ctx->input_frames->sw_format);
> return AVERROR(EINVAL);
> }
> -depth = desc->comp[0].depth;
> -for (i = 1; i < desc->nb_components; i++) {
> -if (desc->comp[i].depth != depth) {
> -av_log(avctx, AV_LOG_ERROR, "Invalid input pixfmt (%s).\n",
> - desc->name);
> -return AVERROR(EINVAL);
> -}
> -}
> av_log(avctx, AV_LOG_VERBOSE, "Input surface format is %s.\n",
> desc->name);
>
> --
> 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".
___
ffmpeg-devel mailing list
ffmpeg-devel@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/qsvdec: Add GPU-accelerated memory copy support
> -Original Message-
> From: Li, Zhong
> Sent: Sunday, September 29, 2019 11:57
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: ChaoX A Liu ; Fu, Linjie
> Subject: RE: [FFmpeg-devel] [PATCH, v2] lavc/qsvdec: Add GPU-accelerated
> memory copy support
>
> > From: ffmpeg-devel On Behalf Of
> Linjie Fu
> > Sent: Friday, September 27, 2019 1:47 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: ChaoX A Liu ; Fu, Linjie
> > Subject: [FFmpeg-devel] [PATCH, v2] lavc/qsvdec: Add GPU-accelerated
> memory
> > copy support
> >
> > GPU copy enables or disables GPU accelerated copying between video and
> > system memory. This may lead to a notable performance improvement.
> > Memory must be sequent and aligned with 128x64.
> > (first introduced in FFmpeg 3.3.1)
>
> This line should be removed. FFmpeg 3.3.1 mainline never support GPU copy.
>
Double confirmed and removed.
> >
> > CMD:
> > ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -c:v h264_qsv
> > -gpu_copy on -i input.h264 -f null -
> > or:
> > ffmpeg -c:v h264_qsv -gpu_copy on -i input.h264 -f null -
> >
> > Signed-off-by: Linjie Fu
> > Signed-off-by: ChaoX A Liu
> > ---
> > Rebased and send again.
> >
> > libavcodec/qsv.c | 31 +---
> > libavcodec/qsv_internal.h | 7 +++---
> > libavcodec/qsvdec.c | 50 ++--
> ---
> > libavcodec/qsvdec.h | 2 ++
> > libavcodec/qsvdec_h2645.c | 10 libavcodec/qsvdec_other.c | 5
>
> > libavcodec/qsvenc.c | 8 ---
> > 7 files changed, 92 insertions(+), 21 deletions(-)
> >
> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c index
> 994c9ebcb0..9e66fbc9da
> > 100644
> > --- a/libavcodec/qsv.c
> > +++ b/libavcodec/qsv.c
> > @@ -412,15 +412,19 @@ static int
> ff_qsv_set_display_handle(AVCodecContext
> > *avctx, QSVSession *qs) #endif
> //AVCODEC_QSV_LINUX_SESSION_HANDLE
> >
> > int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs,
> > - 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, , >session);
> > +init_par.GPUCopy= gpu_copy;
>
> GPUCopy field is introduced from API 1.16, would better to check it to avoid
> compile issue with old API.
> > @@ -802,8 +811,12 @@ int ff_qsv_init_session_frames(AVCodecContext
> *avctx,
> > mfxSession *psession,
> >
> > int ret;
> >
> > +if (gpu_copy == MFX_GPUCOPY_ON)
> > +av_log(avctx, AV_LOG_WARNING, "GPU-accelerated memory copy "
> > +"only works in
> > + MFX_IOPATTERN_OUT_SYSTEM_MEMORY.\n");
>
> This looks weird：
> 1. the waring log will always turn on if gpu_copy is true no matter what
> iopattern.
> So would be better:
> if (gpu_copy == MFX_GPUCOPY_ON && iopattern != system memory)
> print a warning.
>
> 2. It is only added for ff_qsv_init_session_frames(), but looks like should be
> apply for qsv_init_session()
>
Thanks, will update and resend the patch soon.
> >
> > +static int ff_qsv_get_continuous_buffer(AVCodecContext *avctx,
> AVFrame
> > +*frame, AVBufferPool *pool) {
> > +int ret = 0;
> > +
> > +ff_decode_frame_props(avctx, frame);
> > +
> > +frame->width = avctx->width;
> > +frame->height = avctx->height;
> > +frame->linesize[0] = FFALIGN(avctx->width, 128);
> > +frame->linesize[1] = frame->linesize[0];
> > +frame->buf[0] = av_buffer_pool_get(pool);
> > +if (!frame->buf[0])
> > +return AVERROR(ENOMEM);
> > +
> > +frame->data[0] = frame->buf[0]->data;
> > +frame->data[1] = frame->data[0] +
> > +frame->linesize[0] * FFALIGN(avctx->height,
> > + 64);
> > +
> > +ret = ff_attach_decode_data(frame);
>
> Could you please explain why need this function? I don't see private_ref is
> needed from qsv decoding.
private_ref is required if a decoder declares the capability of
AV_CODEC_CAP_DR1.
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/decode.c#L654
- 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
> -Original Message-
> From: Li, Zhong
> Sent: Friday, September 13, 2019 00:05
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: RE: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> vaMapBuffer returns multiple buffers
>
> > From: ffmpeg-devel On Behalf Of
> Linjie Fu
> > Sent: Friday, May 31, 2019 8:35 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie
> > Subject: [FFmpeg-devel] [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
>
> LGTM
Thanks for review.
A kindly 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 4/6] lavu/hwcontext_vaapi: add vaapi_format_map support for AYUV/Y210/Y410
> -Original Message- > From: ffmpeg-devel On Behalf Of > Carl Eugen Hoyos > Sent: Wednesday, September 25, 2019 07:34 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 4/6] lavu/hwcontext_vaapi: add > vaapi_format_map support for AYUV/Y210/Y410 > > Am Do., 19. Sept. 2019 um 09:11 Uhr schrieb Fu, Linjie : > > > > 4:2:2: > > > * 8-bit: YUYV or similar? > > > > Supported FourCC is YUY2, and supported decode format is YUYV422; > > Why is this not AV_PIX_FMT_YUYV422? No new pixel format is needed for 4:2:2 8 bit, here what I mean by "YUYV422" is AV_PIX_FMT_YUYV422. - 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 4/6] lavu/hwcontext_vaapi: add vaapi_format_map support for AYUV/Y210/Y410
> -Original Message- > From: ffmpeg-devel On Behalf Of > Carl Eugen Hoyos > Sent: Wednesday, September 25, 2019 07:33 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 4/6] lavu/hwcontext_vaapi: add > vaapi_format_map support for AYUV/Y210/Y410 > > Am Mi., 25. Sept. 2019 um 00:45 Uhr schrieb Mark Thompson > : > > From what you've said so far, I get the impression that the alpha channel in > your AYUV and Y410 formats is not actually supported at all in the hardware > you have? (That is, there is no support for decoding video with an alpha > channel, such as two-layer H.265.) > > The way I understand it is that there is a bug outside of FFmpeg that > is supposed to be fixed in the future as hevc rext is supposed to > provide an alpha channel (or can provide an alpha channel). > Thanks Carl. Yes, that's exactly what current situation is. See https://github.com/intel/media-driver/issues/719 - 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 4/6] lavu/hwcontext_vaapi: add vaapi_format_map support for AYUV/Y210/Y410
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Mark Thompson
> Sent: Friday, September 13, 2019 07:48
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 4/6] lavu/hwcontext_vaapi: add
> vaapi_format_map support for AYUV/Y210/Y410
>
> On 10/09/2019 17:07, Linjie Fu wrote:
> > 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.
>
> That doesn't make sense - VA_RT_FORMAT_* is a bit mask, so using
> VA_FOURCC_AYUV looks like a random combination of other values.
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index cf11764..724bbeb 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -116,6 +116,15 @@ 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,Y210, 0),
> > +#endif
> > +#define VA_RT_FORMAT_AYUV VA_FOURCC_AYUV
> > +MAP(AYUV, AYUV, AYUV, 0),
> > +#undef VA_RT_FORMAT_AYUV
> > +#ifdef VA_FOURCC_Y410
> > +MAP(Y410, YUV444_10,Y410, 0),
>
> That looks suspicious - you've defined Y410 as having an alpha channel, but
> that render target format doesn't have one.
>
Reconsider about these concerns and collect some information in driver.
1. VA_RT_FORMAT describes the sampling format, several fourcc may have the
Same VA_RT_FORMAT. (NV12, YV12, I420 have VA_RT_FORMAT_YUV420)
so YUV444 is good for AYUV, and YUV444_10 is good for Y410.
(alpha channel is not relevant with the sampling format)
2. In media driver, mediaFMT is actually used for decode which is decided by
expected_fourcc.
DDI_MEDIA_FORMAT mediaFmt =
DdiMedia_OsFormatToMediaFormat(expected_fourcc,format);
https://github.com/intel/media-driver/blob/cf80fa0e3c81361696ada1285ea17a417114be47/media_driver/linux/common/ddi/media_libva.cpp#L
No declaring for a RT_FORMAT with alpha channel won't do harm to the decode
procedure since mediaFMT
is actually mapped by FourCC.
3. in CreateDecAttributes and MediaLibvaCaps::CheckEncRTFormat,
VA_RT_FORMAT_YUV444 and VA_RT_FORMAT_YUV444_10 are used for MAIN444 and
MAIN444_10
https://github.com/intel/media-driver/blob/cf80fa0e3c81361696ada1285ea17a417114be47/media_driver/linux/gen11/ddi/media_libva_caps_g11.cpp#L1189
https://github.com/intel/media-driver/blob/cf80fa0e3c81361696ada1285ea17a417114be47/media_driver/linux/common/ddi/media_libva_caps.cpp#L350
3. If no against, I would like to refine the patch for AYUV and Y410 as follow,
and resend the patch.
+MAP(AYUV, YUV444, AYUV, 0),
+#ifdef VA_FOURCC_Y410
+MAP(Y410, YUV444_10, Y410, 0),
+#endif
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
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Fu, Linjie > Sent: Wednesday, September 11, 2019 00:02 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate > hw_frames_ctx for vp9 without destroy va_context > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > Of Mark Thompson > > Sent: Tuesday, September 10, 2019 08:02 > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate > > hw_frames_ctx for vp9 without destroy va_context > > > > On 09/09/2019 16:40, Fu, Linjie wrote: > > >> -Original Message- > > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > Behalf > > >> Of Fu, Linjie > > >> Sent: Friday, August 30, 2019 16:05 > > >> 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 > > >> > > >>> -Original Message- > > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > >> Behalf > > >>> Of Fu, Linjie > > >>> Sent: Friday, August 9, 2019 19:47 > > >>> 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 > > >>> > > >>>> -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 > > >>
Re: [FFmpeg-devel] [PATCH 4/6] lavu/hwcontext_vaapi: add vaapi_format_map support for AYUV/Y210/Y410
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Friday, September 13, 2019 07:48
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 4/6] lavu/hwcontext_vaapi: add
> vaapi_format_map support for AYUV/Y210/Y410
>
> On 10/09/2019 17:07, Linjie Fu wrote:
> > 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.
>
> That doesn't make sense - VA_RT_FORMAT_* is a bit mask, so using
> VA_FOURCC_AYUV looks like a random combination of other values.
> > Another patch could be sent to refine the code after this issue is
> > addressed:
> > https://github.com/intel/libva/issues/335
> >
> > Signed-off-by: Linjie Fu
> > ---
> > libavutil/hwcontext_vaapi.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > index cf11764..724bbeb 100644
> > --- a/libavutil/hwcontext_vaapi.c
> > +++ b/libavutil/hwcontext_vaapi.c
> > @@ -116,6 +116,15 @@ 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,Y210, 0),
> > +#endif
> > +#define VA_RT_FORMAT_AYUV VA_FOURCC_AYUV
> > +MAP(AYUV, AYUV, AYUV, 0),
> > +#undef VA_RT_FORMAT_AYUV
> > +#ifdef VA_FOURCC_Y410
> > +MAP(Y410, YUV444_10,Y410, 0),
>
> That looks suspicious - you've defined Y410 as having an alpha channel, but
> that render target format doesn't have one.
Also mentioned this in https://github.com/intel/libva/issues/335.
>
> > +#endif
> > MAP(411P, YUV411, YUV411P, 0),
> > MAP(422V, YUV422, YUV440P, 0),
> > MAP(444P, YUV444, YUV444P, 0),
>
> To try to clarify the intent here, the formats you are intending to use for
> this
> new decoder are:
>
> 4:2:0:
> * 8-bit: NV12.
> * 10-bit: P010.
> * With alpha: not supported.
>
> 4:2:2:
> * 8-bit: YUYV or similar?
Supported FourCC is YUY2, and supported decode format is YUYV422;
> * 10-bit: Y210.
> * With alpha: not supported.
>
> 4:4:4:
> * 8-bit: the existing 444P, or not supported?
> * 10-bit: not supported.
The planar format for decoder output is not supported in driver/hardware.
> * 8-bit + alpha: AYUV.
> * 10-bit + alpha: Y410? (With the alpha channel truncated?)
The 10-bit+alpha format is Y410, and the alpha channel data is truncated to 2
bits.
- 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 1/4] hevc_mp4toannexb: Insert correct parameter sets before IRAP
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Andriy Gelman > Sent: Thursday, September 19, 2019 03:32 > To: ffmpeg-devel@ffmpeg.org > Cc: Andriy Gelman > Subject: [FFmpeg-devel] [PATCH v4 1/4] hevc_mp4toannexb: Insert correct > parameter sets before IRAP > > From: Andriy Gelman > > Fixes #7799 > > Currently, the mp4toannexb filter always inserts the same extradata at > the start of the first IRAP unit. As in ticket #7799, this can lead to > decoding errors if modified parameter sets are signalled in-band. > > This commit keeps track of the VPS/SPS/PPS parameter sets during the > conversion. The correct combination is inserted at the start of the > first IRAP. SEIs from extradata are inserted before each IRAP. > > This commit also makes an update to the hevc-bsf-mp4toannexb fate test > since the result before this patch contained duplicate parameter sets > in-band. > --- > libavcodec/hevc_mp4toannexb_bsf.c | 490 > +++--- > tests/fate/hevc.mak | 2 +- > 2 files changed, 457 insertions(+), 35 deletions(-) > > --- a/tests/fate/hevc.mak > +++ b/tests/fate/hevc.mak > @@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER > MOV_DEMUXER HEVC_MP4TOANNEXB_BSF MOV_MUXER > fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov > fate-hevc-bsf-mp4toannexb: CMD = md5 -i > $(TARGET_PATH)/tests/data/hevc-mp4.mov -c:v copy -fflags +bitexact -f > hevc > fate-hevc-bsf-mp4toannexb: CMP = oneline > -fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9 > +fate-hevc-bsf-mp4toannexb: REF = 3c9d998a3aa2b9e0fb1c1f434952bf8b I kind of remember some discussions about 3 or 4 bit start code for hevc: https://ffmpeg.org/pipermail/ffmpeg-devel/2018-November/236899.html Since this patch intends to modify the md5 in fate, maybe it's a good time to have this fixed as well. - 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] swscale: Add swscale input support for Y210
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Wednesday, September 18, 2019 16:44 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH, v2 3/3] swscale: Add swscale input > support for Y210 > > > > > Am 18.09.2019 um 10:20 schrieb Linjie Fu : > > > > Add swscale input support for Y210, output support and fate > > test could be added later if there is requirement for software > > CSC to this packed format. > > Is the patch missing support for 16bit output or does the infrastructure not > allow this? > Verified with "-pix_fmt yuv420p16le", the output image is good as expected. Verified with HEVC QSV decode + software CSC: ffmpeg -hwaccel qsv -hwaccel_device /dev/dri/renderD128 -v verbose -c:v hevc_qsv -load_plugin hevc_hw -i ./Main_422_10_A_RExt_Sony_2.bin -vf hwdownload,format=y210le -pix_fmt yuv420p16le out.yuv This v2 version is for the missing chrToYV12/ lumToYV12 entry for y210. - 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
> -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? For DeinterlacingBob mode with rate=field, the frame number of output should equal 2x input total since only intra deinterlace is used. Currently for "pipeline_caps.num_backward_references, rate = field", extra_delay is introduced. Due to the async without flush, frame number of output is [expected_number - 2]. Specifically, if the input only has 1 frame, the output will be empty. For 1 frame input in Bob mode with rate=field, before patch: 0 frame; after patch: 2 frames; > > I already get the expected number of frames out with both rate settings > (input total - forward references - backward references, all multiplied by 2 > for field rate output). E.g. for 100 frames/field-pairs of input: > > $ ./ffmpeg_g -hwaccel vaapi -hwaccel_device /dev/dri/renderD129 - > hwaccel_output_format vaapi -i f100.mp4 -an -vf > deinterlace_vaapi=rate=frame -f null - > ... > frame= 97 > > $ ./ffmpeg_g -hwaccel vaapi -hwaccel_device /dev/dri/renderD129 - > hwaccel_output_format vaapi -i f100.mp4 -an -vf > deinterlace_vaapi=rate=field -f null - > ... > frame= 194 > > (With forward = 2, backward = 1.) Which driver is used for this test? I've verified with i965 and iHD on linux and failed to find the matched pipeline_cap with num_forward_reference = 2, num_backward_reference = 1; For iHD: #define DDI_CODEC_NUM_FWD_REF 0; #define DDI_CODEC_NUM_BK_REF 0; num_forward_reference = DDI_CODEC_NUM_FWD_REF; num_backward_reference = DDI_CODEC_NUM_BK_REF; https://github.com/intel/media-driver/blob/b9606584bf3dc6937047b4f19e08c75f88bd95a4/media_driver/linux/common/ddi/media_libva.cpp#L5687 For i965: num_forward_reference ++; (if working on MotionAdaptive or MotionCompensated) num_backward_reference = 0; https://github.com/intel/intel-vaapi-driver/blob/9bc30a0231e55f17afed50589669d11e844d0bb9/src/i965_drv_video.c#L7158 > > With this patch applied, the filter always segfaults for me at the end of the > stream when set to field rate: > > $ 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 > #1 0x557565d2 in deint_vaapi_request_frame > (link=0x590928c0) at src/libavfilter/vf_deinterlace_vaapi.c:342 > #2 0x556ce950 in ff_request_frame_to_filter (link=0x590928c0) > at src/libavfilter/avfilter.c:458 > #3 0x556d0cd0 in forward_status_change (filter=0x59088940, > in=0x59092300) at src/libavfilter/avfilter.c:1243 > #4 0x556d0eaf in ff_filter_activate_default (filter=0x59088940) > at src/libavfilter/avfilter.c:1274 > #5 0x556d0fec in ff_filter_activate (filter=0x59088940) at > src/libavfilter/avfilter.c:1430 > #6 0x556d5d29 in ff_filter_graph_run_once (graph=0x5908ff00) > at src/libavfilter/avfiltergraph.c:1456 > #7 0x556d71d8 in push_frame (graph=0x5908ff00) at > src/libavfilter/buffersrc.c:187 > #8 0x556d77a9 in av_buffersrc_close (ctx=0x59091ac0, > pts=300300, flags=4) at src/libavfilter/buffersrc.c:275 > #9 0x5569356a in ifilter_send_eof (ifilter=0x580d0e40, > pts=300300) at src/fftools/ffmpeg.c:2213 > #10 0x556949fd in send_filter_eof (ist=0x580f3ac0) at > src/fftools/ffmpeg.c:2562 > #11 0x55695336 in process_input_packet (ist=0x580f3ac0, > pkt=0x0, no_eof=0) at src/fftools/ffmpeg.c:2701 > #12 0x5569a9db in process_input (file_index=0) at > src/fftools/ffmpeg.c:4313 > #13
Re: [FFmpeg-devel] [PATCH 4/5] lavc/vaapi_decode: add profile_parser and format map support for HEVC REXT
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Monday, September 16, 2019 18:14 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 4/5] lavc/vaapi_decode: add > profile_parser and format map support for HEVC REXT > > Am Mo., 16. Sept. 2019 um 09:36 Uhr schrieb Linjie Fu : > > > > Add function pointer field in vaapi_profile_map[], set profile_parser > > for HEVC_REXT to find the exact va_profile. > > > > Also add format map support. > > Please remove all cosmetic changes from this patch. > Did the "cosmetic changes" refer to the elimination of a blank line in the file header? #include "vaapi_decode.h" - +#include "vaapi_hevc.h" Yes, this could be avoided. And is there anything else I missed? - 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/5] lavc/hevc_ps: parse constraint flags for HEVC REXT
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Monday, September 16, 2019 18:06 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/5] lavc/hevc_ps: parse constraint flags > for HEVC REXT > > Am Mo., 16. Sept. 2019 um 09:35 Uhr schrieb Linjie Fu : > > > > Parse all the constraint flags according to ITU-T Rec. H.265 (02/2018). > > > It can be passed to hw decoders to determine the exact profile for > > Range Extension HEVC. > > I am not a native speaker but I believe this should be more like: > They are needed at least for some hw decoders > or > They have to be passed to hw decoders > > Or are the flags not really "needed" for vaapi? > These flags are needed for VAAPI. And it could be emphasized in the commit message to make it more clear. - 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/6] lavu/pixfmt: add new pixel format ayuv/y210/y410
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Saturday, September 14, 2019 00:31 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH, v2 1/6] lavu/pixfmt: add new pixel > format ayuv/y210/y410 > > Am Fr., 13. Sept. 2019 um 18:13 Uhr schrieb Fu, Linjie : > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > > Of Michael Niedermayer > > > Sent: Friday, September 13, 2019 23:11 > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH, v2 1/6] lavu/pixfmt: add new pixel > > > format ayuv/y210/y410 > > > > > > On Thu, Sep 12, 2019 at 12:28:41AM +0800, Linjie Fu wrote: > > > > Previously, media driver provided planar format(like 420 8 bit), > > > > but for HEVC Range Extension (422/444 8/10 bit), the decoded image > > > > is produced in packed format because Windows expects it. > > > > > > > > Add some packed pixel formats for hardware decode support in VAAPI > > > > and QSV: > > > > > > > > 4:2:2 10 bit: Y210 > > > > 4:4:4 8 bit: AYUV > > > > 4:4:4 10 bit: Y410 > > > > > > > > Signed-off-by: Linjie Fu > > > > --- > > > > libavutil/pixdesc.c | 62 > > > +++ > > > > libavutil/pixfmt.h| 9 +++ > > > > libavutil/tests/pixfmt_best.c | 1 + > > > > libavutil/version.h | 2 +- > > > > 4 files changed, 73 insertions(+), 1 deletion(-) > > > > > > breaks fate > > > > > > --- ./tests/ref/fate/pixfmt_best 2019-09-11 20:36:09.435012759 +0200 > > > +++ tests/data/fate/pixfmt_best 2019-09-13 17:09:53.430392453 +0200 > > > @@ -1 +1 @@ > > > -73 tests passed, 0 tests failed. > > > +74 tests passed, 0 tests failed. > > > Test pixfmt_best failed. Look at tests/data/fate/pixfmt_best.err for > details. > > > make: *** [fate-pixfmt_best] Error 1 > > > > > > > If I didn't get anything missed in the upstream patch, this patch set has > passed > > the pre-patch check in https://github.com/intel-media-ci/ffmpeg/pull/88, > > which includes the fate check. > > Apparently not. > > > Above fate breaking will gone after applying patch 3/6 in the patch set: > > https://patchwork.ffmpeg.org/patch/15007/ > > This indicates you have to merge part(s) of the patches. > The idea is of course that no patch breaks fate. > Thanks, no single patch breaks fate is reasonable, will include the pixel format query support in this patch and move the pixfmt_best modification to the fate patch. 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/6] lavu/pixfmt: add new pixel format ayuv/y210/y410
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Michael Niedermayer > Sent: Friday, September 13, 2019 23:11 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH, v2 1/6] lavu/pixfmt: add new pixel > format ayuv/y210/y410 > > On Thu, Sep 12, 2019 at 12:28:41AM +0800, Linjie Fu wrote: > > Previously, media driver provided planar format(like 420 8 bit), > > but for HEVC Range Extension (422/444 8/10 bit), the decoded image > > is produced in packed format because Windows expects it. > > > > Add some packed pixel formats for hardware decode support in VAAPI > > and QSV: > > > > 4:2:2 10 bit: Y210 > > 4:4:4 8 bit: AYUV > > 4:4:4 10 bit: Y410 > > > > Signed-off-by: Linjie Fu > > --- > > libavutil/pixdesc.c | 62 > +++ > > libavutil/pixfmt.h| 9 +++ > > libavutil/tests/pixfmt_best.c | 1 + > > libavutil/version.h | 2 +- > > 4 files changed, 73 insertions(+), 1 deletion(-) > > breaks fate > > --- ./tests/ref/fate/pixfmt_best 2019-09-11 20:36:09.435012759 +0200 > +++ tests/data/fate/pixfmt_best 2019-09-13 17:09:53.430392453 +0200 > @@ -1 +1 @@ > -73 tests passed, 0 tests failed. > +74 tests passed, 0 tests failed. > Test pixfmt_best failed. Look at tests/data/fate/pixfmt_best.err for details. > make: *** [fate-pixfmt_best] Error 1 > If I didn't get anything missed in the upstream patch, this patch set has passed the pre-patch check in https://github.com/intel-media-ci/ffmpeg/pull/88, which includes the fate check. Above fate breaking will gone after applying patch 3/6 in the patch set: https://patchwork.ffmpeg.org/patch/15007/ diff --git a/tests/ref/fate/pixfmt_best b/tests/ref/fate/pixfmt_best index 5f51e2d..1da1846 100644 --- a/tests/ref/fate/pixfmt_best +++ b/tests/ref/fate/pixfmt_best @@ -1 +1 @@ -73 tests passed, 0 tests failed. +74 tests passed, 0 tests failed. Thanks for the kindly verify. - 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
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Monday, August 19, 2019 10:04
> 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, 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
>
ping x 4?
This fixes vp8/vp9 encoding.
- 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/6] lavu/pixfmt: add new pixel format ayuv/y210/y410
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Michael Niedermayer > Sent: Wednesday, September 11, 2019 23:06 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/6] lavu/pixfmt: add new pixel format > ayuv/y210/y410 > > > Content-Type: text/plain; charset=y > > error: cannot convert from y to UTF-8 > fatal: could not parse patch Occasionally meet this prompt while sending out the patch: "The following files are 8bit, but do not declare a Content-Transfer-Encoding. 0001-lavu-pixfmt-add-new-pixel-format-ayuv-y210-y410.patch Which 8bit encoding should I declare [UTF-8]?" Seems I should press enter to choose the default [UTF-8] charset instead of pressing "y". This patch has been resent, 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/6] lavu/pixfmt: add new pixel format ayuv/y210/y410
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Hendrik Leppkes > Sent: Wednesday, September 11, 2019 15:28 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/6] lavu/pixfmt: add new pixel format > ayuv/y210/y410 > > On Wed, Sep 11, 2019 at 5:20 AM Fu, Linjie wrote: > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > > Of Carl Eugen Hoyos > > > Sent: Wednesday, September 11, 2019 03:25 > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH 1/6] lavu/pixfmt: add new pixel > format > > > ayuv/y210/y410 > > > > > > Am Di., 10. Sept. 2019 um 18:08 Uhr schrieb Linjie Fu > : > > > > > > > > Add some packed pixel formats for hardware decode support > > > > in VAAPI and QSV: > > > > > > > > 4:2:2 10 bit: Y210 > > > > 4:4:4 8 bit: AYUV > > > > 4:4:4 10 bit: Y410 > > > > > > Please add a short explanation (either in the commit message or > > > only in this thread) for which kind of samples these pixel formats > > > are needed. > > > > > > Or to say it differently: Why is the hardware outputting planar > > > formats for some samples and packed for others? > > > > I kind of remember that it was discussed in previous patch thread: > > Previously, media driver provided planar format(like 420 8 bit), > > but for HEVC Range Extension (422/444 8/10 bit), the decoded image > > is produced in packed format. And the reason is " because Windows > > expects it" as you have pointed. > > > > It could be updated in the commit message if this is good enough. > > > > > I see you added LE and BE versions: Why are both needed? > > > And if they are needed, why is there only AYUV and not AYUV > > > and VUYA? > > > > I noticed LE and BE versions are added for some of the added pixel > > format, out of the compatibility for big-endian and little-endian(IMHO). > > And that's the reason I add it for Y210 and Y410. > > > > I'm not sure I understood it correctly, LE/BE version is necessary for > > newly added pixel format right? > > > > It depends on the definition of the pixel format. AYUV is defined as > 4 consecutive BYTEs, which means its identical on LE and BE. > Y210 is defined as being stored as an array of 4 WORDs (Y0, U, Y1, V). > For a WORD, the difference of LE/BE matters. > Y410 is defined as being stored as a single DWORD, again LE/BE matters here. Got it. > Obviously the differences in LE/BE need to be implemented properly as > well, for Y210 for each WORD, and for Y410 for the entire DWORD. Thanks Hendrik, for the detailed explanation. It seems AV_RL16 should be used for Y210LE, but for Y410LE, AV_RL32 is needed instead. 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
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Fu, Linjie > Sent: Saturday, August 31, 2019 12:40 > 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 > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > Of Fu, Linjie > > Sent: Thursday, August 1, 2019 22:51 > > 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 > > > > > -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? > > Ping for this patch set? > https://patchwork.ffmpeg.org/patch/14122/ > https://patchwork.ffmpeg.org/patch/14139/ > https://patchwork.ffmpeg.org/patch/14140/ > Anything I could do for 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 v4 1/2] libavuitl: add A2R10G10B10 & A2B10G10R10
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Zachary Zhou > Sent: Wednesday, September 11, 2019 13:40 > To: ffmpeg-devel@ffmpeg.org > Cc: Zhou, Zachary > Subject: [FFmpeg-devel] [PATCH v4 1/2] libavuitl: add A2R10G10B10 & > A2B10G10R10 > > --- > libavutil/hwcontext_vaapi.c | 6 ++ > libavutil/pixfmt.h | 3 +++ > 2 files changed, 9 insertions(+) Didn't see the difference compared with your V1 patch: https://patchwork.ffmpeg.org/patch/14998/ Is there something mixed up? - 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/6] swscale: add swscale support for 422/444 decode outputs
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Wednesday, September 11, 2019 03:32
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/6] swscale: add swscale support for
> 422/444 decode outputs
>
> Am Di., 10. Sept. 2019 um 18:09 Uhr schrieb Linjie Fu :
>
> > --- a/libswscale/output.c
> > +++ b/libswscale/output.c
> > @@ -2403,6 +2403,53 @@ yuv2ya8_X_c(SwsContext *c, const int16_t
> *lumFilter,
> > }
> >
> > static void
> > +yuv2ayuv_X_c(SwsContext *c, const int16_t *lumFilter,
> > + const int16_t **lumSrc, int lumFilterSize,
> > + const int16_t *chrFilter, const int16_t **chrUSrc,
> > + const int16_t **chrVSrc, int chrFilterSize,
> > + const int16_t **alpSrc, uint8_t *dest, int dstW, int y)
>
> The commit message does not match this change.
> Do I understand correctly that encoding is expected from AYUV
> but not from the other formats?
> Or is this the result of an earlier comment?
+[AV_PIX_FMT_Y210BE] = { 1, 0 },
+[AV_PIX_FMT_Y210LE] = { 1, 0 },
+[AV_PIX_FMT_AYUV]= { 1, 1 },
This patch aims at adding swscale input support for Y210/AYUV and
output/encoding support for AYUV only.
IMHO swscale input support for these packed pixel format is good
at current stage.(since there is no requirement for software
CSC to these packed pixel formats)
For Y410, it's kind of different:
https://docs.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#y410
Bits 0-9 contain the U sample, bits 10-19 contain the Y sample, bits 20-29
contain the V sample, and bits 30-31 contain the alpha value.
Some attempts have been made locally to support swscale input for Y410:
https://github.com/fulinjie/ffmpeg/commits/pr-y410
And I think the swscale input support for Y410 could be held.
> I don't know if splitting the patch would make it clearer.
Sure, will split it for each pixel format.
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 1/6] lavu/pixfmt: add new pixel format ayuv/y210/y410
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Wednesday, September 11, 2019 03:25
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/6] lavu/pixfmt: add new pixel format
> ayuv/y210/y410
>
> Am Di., 10. Sept. 2019 um 18:08 Uhr schrieb Linjie Fu :
> >
> > Add some packed pixel formats for hardware decode support
> > in VAAPI and QSV:
> >
> > 4:2:2 10 bit: Y210
> > 4:4:4 8 bit: AYUV
> > 4:4:4 10 bit: Y410
>
> Please add a short explanation (either in the commit message or
> only in this thread) for which kind of samples these pixel formats
> are needed.
>
> Or to say it differently: Why is the hardware outputting planar
> formats for some samples and packed for others?
I kind of remember that it was discussed in previous patch thread:
Previously, media driver provided planar format(like 420 8 bit),
but for HEVC Range Extension (422/444 8/10 bit), the decoded image
is produced in packed format. And the reason is " because Windows
expects it" as you have pointed.
It could be updated in the commit message if this is good enough.
> I see you added LE and BE versions: Why are both needed?
> And if they are needed, why is there only AYUV and not AYUV
> and VUYA?
I noticed LE and BE versions are added for some of the added pixel
format, out of the compatibility for big-endian and little-endian(IMHO).
And that's the reason I add it for Y210 and Y410.
I'm not sure I understood it correctly, LE/BE version is necessary for
newly added pixel format right?
> > Signed-off-by: Linjie Fu
> > ---
> > libavutil/pixdesc.c | 62
> +++
> > libavutil/pixfmt.h| 9 +++
> > libavutil/tests/pixfmt_best.c | 1 +
> > libavutil/version.h | 2 +-
> > 4 files changed, 73 insertions(+), 1 deletion(-)
>
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index d78e863..0176a2a 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -348,6 +348,12 @@ enum AVPixelFormat {
> > AV_PIX_FMT_NV24, ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and 1
> plane for the UV components, which are interleaved (first byte U and the
> following byte V)
> > AV_PIX_FMT_NV42, ///< as above, but U and V bytes are swapped
> >
> > +AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr, big-
> endian
> > +AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
> > little-
> endian
>
> I believe they are 16bpp.
Thanks for pointing out this, and since Y210 is a 10 bit 4:2:2 format, IMHO
20bpp
is expected information. (see AV_PIX_FMT_YUV422P10LE,///< planar YUV 4:2:2,
20bpp)
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
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Mark Thompson > Sent: Tuesday, September 10, 2019 08:02 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate > hw_frames_ctx for vp9 without destroy va_context > > On 09/09/2019 16:40, Fu, Linjie wrote: > >> -Original Message- > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > >> Of Fu, Linjie > >> Sent: Friday, August 30, 2019 16:05 > >> 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 > >> > >>> -Original Message- > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > >> Behalf > >>> Of Fu, Linjie > >>> Sent: Friday, August 9, 2019 19:47 > >>> 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 > >>> > >>>> -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(-) > >>>
Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Friday, August 30, 2019 16:05
> 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
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Fu, Linjie
> > Sent: Friday, August 9, 2019 19:47
> > 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
> >
> > > -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
> > > > > >
Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Sunday, September 1, 2019 01:57 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format > > Am Sa., 31. Aug. 2019 um 19:25 Uhr schrieb Fu, Linjie : > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > > Of Mark Thompson > > > Sent: Saturday, August 31, 2019 23:10 > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel > format > > > > > > On 31/08/2019 05:22, Fu, Linjie wrote: > > > >> -Original Message- > > > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > > Behalf > > > >> Of Carl Eugen Hoyos > > > >> Sent: Friday, August 30, 2019 00:12 > > > >> To: FFmpeg development discussions and patches > > >> de...@ffmpeg.org> > > > >> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel > > > format > > > >> > > > >> Am Do., 29. Aug. 2019 um 16:16 Uhr schrieb Fu, Linjie > > > : > > > >> > > > >>> Thus AYUV will make more sense. > > > >> > > > >> If your hardware decoding does not produce valid alpha data (0xFF > > > >> for opaque, 0x00 for completely transparent), you cannot use an > > > >> FFmpeg pix_fmt that defines alpha for decoding. > > > >> If you define a pix_fmt that does not contain alpha information (as > > > >> needed for your hardware decoder), please do not use "A" in its > > > >> name. > > > > > > > > The hardware decode output is in packed 4:4:4:4 8 bit(32 bits in total). > Apart> > > > from Y/U/V channel, there is an additional need for a channel to store the > > > > zero byte in surfaces(nb_components = 4). And it is designed in > > > hardware/driver > > > > for VA_FourCC_AYUV and AYUV format. > > > > > > > > It's not quite proper to use something like "0YUV" directly which > indicates > > > that > > > > there is no Alpha channel data like"RGB0" or "0RGB"(nb_components = > 3). > > > > > > > > "0YUV": YUV0/YUV0/... > > > > "RGB0":RGB/RGB/... > > > > > > I think you've misread what RGB0 is. The component step is 4, not 3 (see > > > libavutil/pixdesc.c) - the format with a step of 3 is RGB24. > > > > > > RGBA: R G B A R G B A ... > > > RGB0: R G B 0 R G B 0 ... > > > RGB24: R G B R G B R G ... > > > > Thanks for pointing out this. > > Just took the nb_components into account and misread the step info at > first. > > > > > Following the same pattern we would have: > > > > > > AYUV: A Y U V A Y U V ... > > > 0YUV: 0 Y U V 0 Y U V ... > > > > > > To me it looks like 0YUV is exactly what you want here. > > > > Will update the patch if 0YUV is more acceptable. > > Could you double-check if there is no bug in the decoder? > I ask because transparency is possible with hevc and the > relevant Windows format does support transparency from > how I read the specification. > Hi, Rethink about this, hardware decoder should support a valid alpha data. Default 0x00 or 0xFF for alpha channel doesn't make sense in HEVC Rext decoding. Filed an issue in media driver: https://github.com/intel/media-driver/issues/719 Will rebase and resend the patch set for QSV HEVC REXT decoding, basing on AYUV,Y410, Y210. 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/qsv: Fix MSDK initialization failure in system memory mode
> -Original Message-
> From: Li, Zhong
> Sent: Thursday, September 5, 2019 11:14
> To: Fu, Linjie ; FFmpeg development discussions and
> patches
> Subject: RE: [FFmpeg-devel] [PATCH 1/2] lavc/qsv: Fix MSDK initialization
> failure in system memory mode
>
> > From: Fu, Linjie
> > Sent: Thursday, September 5, 2019 10:54 AM
> > To: FFmpeg development discussions and patches de...@ffmpeg.org>
> > Cc: Li, Zhong
> > Subject: RE: [FFmpeg-devel] [PATCH 1/2] lavc/qsv: Fix MSDK initialization
> failure
> > in system memory mode
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > > Of Zhong Li
> > > Sent: Wednesday, September 4, 2019 23:41
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Li, Zhong
> > > Subject: [FFmpeg-devel] [PATCH 1/2] lavc/qsv: Fix MSDK initialization
> > > failure in system memory mode
> > >
> > > MSDK does not create internal acceleration device on Linux, So
> > > MFXVideoCORE_SetHandle() is necessary.
> > > It has been added for ff_qsv_init_session_device().
> > > But missed for ff_qsv_init_internal_session() due to commit
> > > 1f26a23 overwrited commit db89f45
> > >
> > > Fix #7030
> > >
> > > Signed-off-by: Zhong Li
> > > ---
> > > libavcodec/qsv.c | 105
> > > --
> > > libavcodec/qsv_internal.h | 27 +++-
> > > libavcodec/qsvdec.c | 29 +++--
> > > libavcodec/qsvdec.h | 2 +-
> > > libavcodec/qsvenc.c | 17
> > > libavcodec/qsvenc.h | 2 +-
> > > 6 files changed, 151 insertions(+), 31 deletions(-)
> > >
> > > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c index
> > > 65ad070..126182b 100644
> > > --- a/libavcodec/qsv.c
> > > +++ b/libavcodec/qsv.c
> > > @@ -348,7 +348,79 @@ load_plugin_fail:
> > >
> > > }
> > >
> > > -int ff_qsv_init_internal_session(AVCodecContext *avctx, mfxSession
> > > *session,
> > > +//This code is only required for Linux since a display handle is
> > > required.
> > > +//For Windows the session is complete and ready to use.
> > > +//For releases of Media Server Studio >= 2015 R4 the //render nodes
> > > +interface is preferred (/dev/dri/renderD).
> > > +//Using Media Server Studio 2015 R4 or newer is recommended //but
> the
> > > +older /dev/dri/card interface is also searched for broader
> > > compatibility.
> > > +
> > > +#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE static int
> > > +ff_qsv_set_display_handle(AVCodecContext *avctx, QSVSession
> > > *qs)
> > > +{
> > > +// VAAPI display handle
> > > +int ret = 0;
> > > +VADisplay va_dpy = NULL;
> > > +VAStatus va_res = VA_STATUS_SUCCESS;
> > > +int major_version = 0, minor_version = 0;
> > > +int fd = -1;
> > > +char adapterpath[256];
> > > +int adapter_num;
> > > +
> > > +qs->fd_display = -1;
> > > +qs->va_display = NULL;
> > > +
> > > +//search for valid graphics device
> > > +for (adapter_num = 0;adapter_num < 6;adapter_num++) {
> > > +
> > > +if (adapter_num<3) {
> > > +snprintf(adapterpath,sizeof(adapterpath),
> > > +"/dev/dri/renderD%d", adapter_num+128);
> > > +} else {
> > > +snprintf(adapterpath,sizeof(adapterpath),
> > > +"/dev/dri/card%d", adapter_num-3);
> > > +}
> > > +
> > > +fd = open(adapterpath, O_RDWR);
> > > +if (fd < 0) {
> > > +av_log(avctx, AV_LOG_ERROR,
> > > +"mfx init: %s fd open failed\n", adapterpath);
> > > +continue;
> > > +}
> > > +
> > > +va_dpy = vaGetDisplayDRM(fd);
> > > +if (!va_dpy) {
> > > +av_log(avctx, AV_LOG_ERROR,
> > > +"mfx init: %s vaGetDisplayDRM failed\n", adapterpath);
> > > +close(fd);
> > > +continue;
> > > +}
> > > +
> > > +va_res = vaInitialize(va_dpy, _version, _version);
> > > +if (VA_STATUS_SUCCESS != va_res) {
> > > +av_log(avctx, A
Re: [FFmpeg-devel] [PATCH 1/2] lavc/qsv: Fix MSDK initialization failure in system memory mode
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Zhong Li
> Sent: Wednesday, September 4, 2019 23:41
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong
> Subject: [FFmpeg-devel] [PATCH 1/2] lavc/qsv: Fix MSDK initialization failure
> in system memory mode
>
> MSDK does not create internal acceleration device on Linux,
> So MFXVideoCORE_SetHandle() is necessary.
> It has been added for ff_qsv_init_session_device().
> But missed for ff_qsv_init_internal_session() due to commit
> 1f26a23 overwrited commit db89f45
>
> Fix #7030
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsv.c | 105
> --
> libavcodec/qsv_internal.h | 27 +++-
> libavcodec/qsvdec.c | 29 +++--
> libavcodec/qsvdec.h | 2 +-
> libavcodec/qsvenc.c | 17
> libavcodec/qsvenc.h | 2 +-
> 6 files changed, 151 insertions(+), 31 deletions(-)
>
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index 65ad070..126182b 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -348,7 +348,79 @@ load_plugin_fail:
>
> }
>
> -int ff_qsv_init_internal_session(AVCodecContext *avctx, mfxSession
> *session,
> +//This code is only required for Linux since a display handle is required.
> +//For Windows the session is complete and ready to use.
> +//For releases of Media Server Studio >= 2015 R4 the
> +//render nodes interface is preferred (/dev/dri/renderD).
> +//Using Media Server Studio 2015 R4 or newer is recommended
> +//but the older /dev/dri/card interface is also searched for broader
> compatibility.
> +
> +#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE
> +static int ff_qsv_set_display_handle(AVCodecContext *avctx, QSVSession
> *qs)
> +{
> +// VAAPI display handle
> +int ret = 0;
> +VADisplay va_dpy = NULL;
> +VAStatus va_res = VA_STATUS_SUCCESS;
> +int major_version = 0, minor_version = 0;
> +int fd = -1;
> +char adapterpath[256];
> +int adapter_num;
> +
> +qs->fd_display = -1;
> +qs->va_display = NULL;
> +
> +//search for valid graphics device
> +for (adapter_num = 0;adapter_num < 6;adapter_num++) {
> +
> +if (adapter_num<3) {
> +snprintf(adapterpath,sizeof(adapterpath),
> +"/dev/dri/renderD%d", adapter_num+128);
> +} else {
> +snprintf(adapterpath,sizeof(adapterpath),
> +"/dev/dri/card%d", adapter_num-3);
> +}
> +
> +fd = open(adapterpath, O_RDWR);
> +if (fd < 0) {
> +av_log(avctx, AV_LOG_ERROR,
> +"mfx init: %s fd open failed\n", adapterpath);
> +continue;
> +}
> +
> +va_dpy = vaGetDisplayDRM(fd);
> +if (!va_dpy) {
> +av_log(avctx, AV_LOG_ERROR,
> +"mfx init: %s vaGetDisplayDRM failed\n", adapterpath);
> +close(fd);
> +continue;
> +}
> +
> +va_res = vaInitialize(va_dpy, _version, _version);
> +if (VA_STATUS_SUCCESS != va_res) {
> +av_log(avctx, AV_LOG_ERROR,
> +"mfx init: %s vaInitialize failed\n", adapterpath);
> +close(fd);
> +fd = -1;
> +continue;
> +} else {
> +av_log(avctx, AV_LOG_VERBOSE,
> +"mfx initialization: %s vaInitialize successful\n",adapterpath);
> +qs->fd_display = fd;
> +qs->va_display = va_dpy;
> +ret = MFXVideoCORE_SetHandle(qs->session,
> + (mfxHandleType)MFX_HANDLE_VA_DISPLAY, (mfxHDL)va_dpy);
> +if (ret < 0) {
> +return ff_qsv_print_error(avctx, ret, "Error %d during set
> display
> handle\n");
> +}
> +break;
> +}
> +}
> +return 0;
> +}
> +#endif //AVCODEC_QSV_LINUX_SESSION_HANDLE
> +
> +int ff_qsv_init_internal_session(AVCodecContext *avctx, QSVSession *qs,
> const char *load_plugins)
> {
> mfxIMPL impl = MFX_IMPL_AUTO_ANY;
> @@ -357,18 +429,24 @@ int ff_qsv_init_internal_session(AVCodecContext
> *avctx, mfxSession *session,
> const char *desc;
> int ret;
>
> -ret = MFXInit(impl, , session);
> +ret = MFXInit(impl, , >session);
> if (ret < 0)
> return ff_qsv_print_error(avctx, ret,
>"Error initializing an internal MFX
> session");
>
> -ret = qsv_load_plugins(*session, load_plugins, avctx);
> +#ifdef AVCODEC_QSV_LINUX_SESSION_HANDLE
> +ret = ff_qsv_set_display_handle(avctx, qs);
> +if (ret < 0)
> +return ret;
> +#endif
I think one "#ifdef" check may be good enough for ff_qsv_set_display_handle,
but current version is also ok.
Patch LGTM referring to commit 1f26a23.
And also verified it works on both Linux and Windows.
- linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Re: [FFmpeg-devel] [PATCH] lavc/qsvdec: fix the regression on linux for init_hw_device
> -Original Message-
> From: Li, Zhong
> Sent: Tuesday, September 3, 2019 18:18
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: RE: [FFmpeg-devel] [PATCH] lavc/qsvdec: fix the regression on linux
> for init_hw_device
>
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index
> eef4fe7..319b549
> > 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -46,6 +46,7 @@ const AVCodecHWConfigInternal
> *ff_qsv_hw_configs[] = {
> > .public = {
> > .pix_fmt = AV_PIX_FMT_QSV,
> > .methods =
> AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX |
> > + AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX |
>
> AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX means we can
> support AV_PIX_FMT_QSV by AVCodecContext.hw_device_ctx
> This is not supported for qsv now.
> And even if it is supported, there is no business of system memory frame,
> just means output AV_PIX_FMT_QSV format frame created by
> hw_device_ctx.
Thanks for the explanation of this flag.
>
> > AV_CODEC_HW_CONFIG_METHOD_AD_HOC,
> > .device_type = AV_HWDEVICE_TYPE_QSV,
> > },
> > --
> > 2.7.4
>
> Probably we need to add MFXVideoCORE_SetHandle() function for system
> memory output path, which is removed by
> 1f26a231bb065276cd80ce02957c759f3197edfa.
Yes, that's another possibility to fix this issue.
This patch aims at matching the behavior before the regression happened since
currently qsv is working on different session_init path compared with previous
version.
If ff_qsv_init_session_device() should not be called, it's good to set handle in
ff_qsv_init_internal_session (), since MSDK won't do such implementation on
Linux
internally:
https://github.com/Intel-Media-SDK/MediaSDK/issues/1611#issuecomment-527359911
> I will try to give a patch to fix it ASAP.
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] lavu/hwcontext_vaapi: cope with race map for YUV420P
> -Original Message-
> From: Fu, Linjie
> Sent: Thursday, August 15, 2019 12:33
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [PATCH 1/2] 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 found 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
>
> Reviewed-by: Zhong Li
> 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 = >formats[i].image_format;
> +if (ctx->formats[i].fourcc == desc->fourcc) {
> +*image_format = >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
Ping?
Apart from the CSC issue, this also enables directly hwmap for yuv420p
in ffmpeg vaapi and is able to improve the performance by eliminating
redundant memory copy.
Tested on local KBL environment, from 45 fps to 70 fps
hwdownload hwmap=mode=direct
YUV420P 45 fps 70 fps (1.5x)
Cmdline:
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -v verbose
-hwaccel_output_format vaapi -i Nature.h264 -vf
scale_vaapi=format=yuv420p,hwmap=mode=direct,format=yuv420p -f null -
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Sunday, September 1, 2019 01:57 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format > > Am Sa., 31. Aug. 2019 um 19:25 Uhr schrieb Fu, Linjie : > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > > Of Mark Thompson > > > Sent: Saturday, August 31, 2019 23:10 > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel > format > > > > > > On 31/08/2019 05:22, Fu, Linjie wrote: > > > >> -Original Message- > > > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > > Behalf > > > >> Of Carl Eugen Hoyos > > > >> Sent: Friday, August 30, 2019 00:12 > > > >> To: FFmpeg development discussions and patches > > >> de...@ffmpeg.org> > > > >> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel > > > format > > > >> > > > >> Am Do., 29. Aug. 2019 um 16:16 Uhr schrieb Fu, Linjie > > > : > > > >> > > > >>> Thus AYUV will make more sense. > > > >> > > > >> If your hardware decoding does not produce valid alpha data (0xFF > > > >> for opaque, 0x00 for completely transparent), you cannot use an > > > >> FFmpeg pix_fmt that defines alpha for decoding. > > > >> If you define a pix_fmt that does not contain alpha information (as > > > >> needed for your hardware decoder), please do not use "A" in its > > > >> name. > > > > > > > > The hardware decode output is in packed 4:4:4:4 8 bit(32 bits in total). > Apart> > > > from Y/U/V channel, there is an additional need for a channel to store the > > > > zero byte in surfaces(nb_components = 4). And it is designed in > > > hardware/driver > > > > for VA_FourCC_AYUV and AYUV format. > > > > > > > > It's not quite proper to use something like "0YUV" directly which > indicates > > > that > > > > there is no Alpha channel data like"RGB0" or "0RGB"(nb_components = > 3). > > > > > > > > "0YUV": YUV0/YUV0/... > > > > "RGB0":RGB/RGB/... > > > > > > I think you've misread what RGB0 is. The component step is 4, not 3 (see > > > libavutil/pixdesc.c) - the format with a step of 3 is RGB24. > > > > > > RGBA: R G B A R G B A ... > > > RGB0: R G B 0 R G B 0 ... > > > RGB24: R G B R G B R G ... > > > > Thanks for pointing out this. > > Just took the nb_components into account and misread the step info at > first. > > > > > Following the same pattern we would have: > > > > > > AYUV: A Y U V A Y U V ... > > > 0YUV: 0 Y U V 0 Y U V ... > > > > > > To me it looks like 0YUV is exactly what you want here. > > > > Will update the patch if 0YUV is more acceptable. > > Could you double-check if there is no bug in the decoder? > I ask because transparency is possible with hevc and the > relevant Windows format does support transparency from > how I read the specification. > Double confirmed. The alpha channel is configurable on HCP_SURFACE_STATE command, currently driver(iHD) set zero as default value. "0YUV" is good enough, "AYUV" could be hold on. - 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
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Mark Thompson > Sent: Saturday, August 31, 2019 23:10 > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format > > On 31/08/2019 05:22, Fu, Linjie wrote: > >> -Original Message- > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > >> Of Carl Eugen Hoyos > >> Sent: Friday, August 30, 2019 00:12 > >> To: FFmpeg development discussions and patches >> de...@ffmpeg.org> > >> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel > format > >> > >> Am Do., 29. Aug. 2019 um 16:16 Uhr schrieb Fu, Linjie > : > >> > >>> Thus AYUV will make more sense. > >> > >> If your hardware decoding does not produce valid alpha data (0xFF > >> for opaque, 0x00 for completely transparent), you cannot use an > >> FFmpeg pix_fmt that defines alpha for decoding. > >> If you define a pix_fmt that does not contain alpha information (as > >> needed for your hardware decoder), please do not use "A" in its > >> name. > > > > The hardware decode output is in packed 4:4:4:4 8 bit(32 bits in total). > > Apart> > from Y/U/V channel, there is an additional need for a channel to store the > > zero byte in surfaces(nb_components = 4). And it is designed in > hardware/driver > > for VA_FourCC_AYUV and AYUV format. > > > > It's not quite proper to use something like "0YUV" directly which indicates > that > > there is no Alpha channel data like"RGB0" or "0RGB"(nb_components = 3). > > > > "0YUV": YUV0/YUV0/... > > "RGB0":RGB/RGB/... > > I think you've misread what RGB0 is. The component step is 4, not 3 (see > libavutil/pixdesc.c) - the format with a step of 3 is RGB24. > > RGBA: R G B A R G B A ... > RGB0: R G B 0 R G B 0 ... > RGB24: R G B R G B R G ... Thanks for pointing out this. Just took the nb_components into account and misread the step info at first. > Following the same pattern we would have: > > AYUV: A Y U V A Y U V ... > 0YUV: 0 Y U V 0 Y U V ... > > To me it looks like 0YUV is exactly what you want here. Will update the patch if 0YUV is more acceptable. And thanks Carl. - 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
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Fu, Linjie > Sent: Thursday, August 1, 2019 22:51 > 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 > > > -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? Ping for this patch set? https://patchwork.ffmpeg.org/patch/14122/ https://patchwork.ffmpeg.org/patch/14139/ https://patchwork.ffmpeg.org/patch/14140/ ___ ffmpeg-devel mailing list ffmpeg-devel@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
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Friday, August 30, 2019 00:12 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format > > Am Do., 29. Aug. 2019 um 16:16 Uhr schrieb Fu, Linjie : > > > Thus AYUV will make more sense. > > If your hardware decoding does not produce valid alpha data (0xFF > for opaque, 0x00 for completely transparent), you cannot use an > FFmpeg pix_fmt that defines alpha for decoding. > If you define a pix_fmt that does not contain alpha information (as > needed for your hardware decoder), please do not use "A" in its > name. The hardware decode output is in packed 4:4:4:4 8 bit(32 bits in total). Apart from Y/U/V channel, there is an additional need for a channel to store the zero byte in surfaces(nb_components = 4). And it is designed in hardware/driver for VA_FourCC_AYUV and AYUV format. It's not quite proper to use something like "0YUV" directly which indicates that there is no Alpha channel data like"RGB0" or "0RGB"(nb_components = 3). "0YUV": YUV0/YUV0/... "RGB0":RGB/RGB/... It's true that we could only map Y/U/V data from surface to frame in ffmpeg and use a 3-components pixel format like "0YUV", but IMHO it's kind of improper because the output from hardware/driver is forced changed in Application level even if user didn't call for a CSC: - hardware/driver output (in AYUV): YUV0/YUV0/... - ffmpeg output (in 0YUV): YUV/YUV/... Please feel free to offer your opinions on this question(AYUV or 0YUV) and let me know how to push it step-further. 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/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Friday, August 9, 2019 19:47
> 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
>
> > -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 (!avc
Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format
> -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".
Re: [FFmpeg-devel] [PATCH 2/2] swscale: Add swscale and fate support for AYUV
> -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
> -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
> -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
> -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] lavf/vf_deinterlace_vaapi: flush queued frame in field mode
> -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, 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, 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
> -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(AVFi
Re: [FFmpeg-devel] [PATCH] lavu/hwcontext_vaapi: provide detailed warning if directly mapping fails
> -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
> -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 = _vaapi_config_output,
> +.name = "default",
> +.type = AVMEDIA_TYPE_VIDEO,
> +.request_frame = _vaapi_request_frame,
> +.config_props = _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: cope with race map for YUV420P
> -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 = >formats[i].image_format;
> +if (ctx->formats[i].fourcc == desc->fourcc) {
> +*image_format = >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, RFC, v2 3/3] lavc/libvpxenc: add dynamic resolution encode support for libvpx
> -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(_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 v2 2/2] vaapi_encode: fix VBR mode generating low bitrates
> -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, v2 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context
> -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_
Re: [FFmpeg-devel] [PATCH 1/2] Revert "lavf/vf_vpp_qsv: add support for QSV transpose filter"
> -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
> -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, 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?
- 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
> -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] avcodec/vaapi_encode_h264: add support for a/53 closed caption sei
> -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(>sei_a53cc_data);
Is this necessary?
> +err = ff_alloc_a53_sei(pic->input_image, 0, >sei_a53cc_data,
> _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/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> -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 3/3] lavc/libvpxenc: add dynamic resolution encode support for libvpx
> -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
> -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 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> -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 3/4] fftools/ffmpeg: support variable dimension encode
> -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, v4 1/2] 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 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, RFC 2/2] fftools/ffmpeg: add dynamic resolution encode support for libvpx-vp9
> -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, 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 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] lavc/phtread_frame: update hwaccel_priv_data in time for multithread
> -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(_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(>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 = >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
> -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, 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: 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
> -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
> -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
> -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 2/2] doc/ffmpeg.texi: update docs for autoscale/autorotate
> -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] 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(_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(>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 = >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, v2 2/2] doc/ffmpeg.texi: update docs for autoscale/autorotate
> -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, v2 2/2] doc/ffmpeg.texi: update docs for autoscale/autorotate
> -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 2/2] doc/ffmpeg.texi: update docs for autoscale/autorotate
> -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 2/2] doc/ffmpeg.texi: update docs for autoscale/autorotate
> -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
> -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] fftools/ffmpeg_filter: use -reinit_filter to disable/enable auto scale
> -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, v3] lavf/vf_vpp_qsv: add support for QSV transpose filter
> -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
> -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] fftools/ffmpeg_filter: use -reinit_filter to disable/enable auto scale
> -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, v3] lavc/pthread_frame: update context in child thread in multi-thread mode
> -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 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 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 new VAAPI context will
onl
Re: [FFmpeg-devel] [PATCH] avfilter: add rawdump filter
> -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] lavf/vf_vpp_qsv: add support for QSV transpose filter
> -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",
> > 0, AV_OPT_TYPE_CONST
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.
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] 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 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 100644
> > > --
Re: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add vaapi_format_map for Y210/AYUV/Y410
> -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
> -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/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 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 =
Re: [FFmpeg-devel] [PATCH 2/5] lavu/hwcontext_vaapi: add vaapi_format_map for Y210/AYUV/Y410
> -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 4/5] lavc/qsvdec: add ChromaFormat support for YUV422/YUV444
> -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 4/5] lavc/qsvdec: add ChromaFormat support for YUV422/YUV444
> -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 2/5] lavu/hwcontext_vaapi: add vaapi_format_map for Y210/AYUV/Y410
> -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".
