Re: [FFmpeg-devel] [PATCH v3 2/2] lavc/hevcdec: Update slice index before hwaccel decode slice
> -Original Message- > From: Anton Khirnov > Sent: Tuesday, June 25, 2024 3:45 PM > To: FFmpeg development discussions and patches > Cc: Wang, Fei W > Subject: Re: [FFmpeg-devel] [PATCH v3 2/2] lavc/hevcdec: Update slice index > before hwaccel decode slice > > Quoting fei.w.wang-at-intel@ffmpeg.org (2024-06-24 08:23:31) > > From: Fei Wang > > > > Otherwise, slice index will never update for hwaccel decode, and slice > > RPL will be always overlap into first one which use slice index to > > construct. > > > > Fixes hwaccel decoding after 47d34ba7fbb81 > > > > Signed-off-by: Fei Wang > > ok Will push the patchset in 3 days if no more objection. -- Fei > > -- > Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 3/3] lavc/vaapi_hevc: Don't require exact profiles
On Wed, 2024-06-05 at 20:59 +0100, Mark Thompson wrote:
> Rather than turning the constraint flags into a single profile and
> then
> searching for that profile (and failing if it doesn't match any
> profile
> exactly), instead search all supported profiles and use the first one
> which supports the given set of constraint flags.
> ---
> libavcodec/vaapi_decode.c | 45 +++---
> libavcodec/vaapi_hevc.c | 99 ++---
> --
> libavcodec/vaapi_hevc.h | 4 +-
> 3 files changed, 87 insertions(+), 61 deletions(-)
Test good for me. Thanks.
--
Fei
>
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index 7c91d50f7b..c9d8add69f 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -393,7 +393,9 @@ static const struct {
> enum AVCodecID codec_id;
> int codec_profile;
> VAProfile va_profile;
> - VAProfile (*profile_parser)(AVCodecContext *avctx);
> + VAProfile (*match_profile)(AVCodecContext *avctx,
> + const VAProfile *profile_list,
> + int profile_count);
> } vaapi_profile_map[] = {
> #define MAP(c, p, v, ...) { AV_CODEC_ID_ ## c, AV_PROFILE_ ## p,
> VAProfile ## v, __VA_ARGS__ }
> MAP(MPEG2VIDEO, MPEG2_SIMPLE, MPEG2Simple ),
> @@ -420,9 +422,9 @@ static const struct {
> #endif
> #if VA_CHECK_VERSION(1, 2, 0) && CONFIG_HEVC_VAAPI_HWACCEL
> MAP(HEVC, HEVC_REXT, None,
> - ff_vaapi_parse_hevc_rext_scc_profile ),
> + ff_vaapi_hevc_match_rext_scc_profile ),
> MAP(HEVC, HEVC_SCC, None,
> - ff_vaapi_parse_hevc_rext_scc_profile ),
> + ff_vaapi_hevc_match_rext_scc_profile ),
> #endif
> MAP(MJPEG, MJPEG_HUFFMAN_BASELINE_DCT,
> JPEGBaseline),
> @@ -505,22 +507,33 @@ static int
> vaapi_decode_make_config(AVCodecContext *avctx,
> vaapi_profile_map[i].codec_profile ==
> AV_PROFILE_UNKNOWN)
> profile_match = 1;
>
> - va_profile = vaapi_profile_map[i].profile_parser ?
> - vaapi_profile_map[i].profile_parser(avctx) :
> - vaapi_profile_map[i].va_profile;
> codec_profile = vaapi_profile_map[i].codec_profile;
> -
> - for (j = 0; j < profile_count; j++) {
> - if (va_profile == profile_list[j]) {
> - exact_match = profile_match;
> + if (vaapi_profile_map[i].match_profile) {
> + va_profile =
> + vaapi_profile_map[i].match_profile(avctx,
> profile_list,
> + profile_count);
> + if (va_profile != VAProfileNone) {
> + matched_va_profile = va_profile;
> + matched_ff_profile = codec_profile;
> + exact_match = 1;
> break;
> }
> - }
> - if (j < profile_count) {
> - matched_va_profile = va_profile;
> - matched_ff_profile = codec_profile;
> - if (exact_match)
> - break;
> + } else {
> + va_profile = vaapi_profile_map[i].va_profile;
> +
> + for (j = 0; j < profile_count; j++) {
> + if (va_profile == profile_list[j]) {
> + exact_match = profile_match;
> + break;
> + }
> + }
> +
> + if (j < profile_count) {
> + matched_va_profile = va_profile;
> + matched_ff_profile = codec_profile;
> + if (exact_match)
> + break;
> + }
> }
> }
> av_freep(_list);
> diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
> index 6164a1d223..716a4a4b43 100644
> --- a/libavcodec/vaapi_hevc.c
> +++ b/libavcodec/vaapi_hevc.c
> @@ -589,63 +589,74 @@ static int ptl_convert(const PTLCommon
> *general_ptl, H265RawProfileTierLevel *h2
> }
>
> /*
> - * Find exact va_profile for HEVC Range Extension and Screen Content
> Coding Extension
> + * Find compatible va_profile for HEVC Range Extension and Screen
> + * Content Coding Extension profiles.
> */
> -VAProfile ff_vaapi_parse_hevc_rext_scc_profile(AVCodecContext
> *avctx)
> +VAProfile ff_vaapi_hevc_match_rext_scc_profile(AVCodecContext
> *avctx,
> + const VAProfile
> *profile_list,
> + int profile_count)
> {
> const HEVCContext *h = avctx->priv_data;
> const HEVCSPS *sps = h->ps.sps;
> const PTL *ptl = >ptl;
> const PTLCommon *general_ptl = >general_ptl;
> - const H265ProfileDescriptor *profile;
> H265RawProfileTierLevel h265_raw_ptl = {0};
>
> + static const struct {
> + enum H265Profile profile;
> + VAProfile va_profile;
> + } map[] = {
> +#if VA_CHECK_VERSION(1, 2, 0)
> + {
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself to the general developers list
> -Original Message- > From: Wang, Fei W > Sent: Sunday, June 30, 2024 2:18 PM > To: ffmpeg-devel@ffmpeg.org > Cc: Wang, Fei W > Subject: [FFmpeg-devel][PATCH] MAINTAINERS: add myself to the general > developers list > > From: Fei Wang > > Signed-off-by: Fei Wang > --- > It has been 4.5 years since my 1st patch to FFmpeg. During the past years, I > have fully understand the rules of a committer. Because sometimes, patch > send to community will be stay there without review or patch get reviewed > and approved but can't be get merged. So to make the work more efficient > and to contribute some of my help as a committer, I'd like to apply to get > write access. Thanks. Ping. Thanks. -- Fei > > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index a82fa58c69..d794e58163 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -514,6 +514,7 @@ Benjamin Larsson > Bobby Bingham > Daniel Verkamp > Derek Buitenhuis > +Fei Wang > Ganesh Ajjanagadde > Henrik Gramner > Ivan Uskov > -- > 2.34.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] lavc/hevcdec: Update slice index before use it to construct slice RPL
On Fri, 2024-06-21 at 10:48 +0200, Anton Khirnov wrote: > Quoting fei.w.wang-at-intel@ffmpeg.org (2024-06-19 04:27:22) > > From: Fei Wang > > > > Fixes regression from 47d34ba7fbb81 > > "fix bug" is not a meaningful description of the problem Added more explanation in V3. Thanks. Fei > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/2] lavc/hevcdec: Put slice address checking after hwaccel decode slice
On Wed, 2024-06-19 at 10:27 +0800, fei.w.w...@intel.com wrote:
> From: Fei Wang
>
> Slice address tab only been updated in software decode slice data.
>
> Fixes hwaccel decoding after
> d725c737fe2a19091b481d4d115fd939e0a674b2.
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/hevc/hevcdec.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
> index 1d2e53afc3..39beb7e4dc 100644
> --- a/libavcodec/hevc/hevcdec.c
> +++ b/libavcodec/hevc/hevcdec.c
> @@ -2770,15 +2770,6 @@ static int decode_slice_data(HEVCContext *s,
> const H2645NAL *nal, GetBitContext
> const HEVCPPS *pps = s->pps;
> int ret;
>
> - if (s->sh.dependent_slice_segment_flag) {
> - int ctb_addr_ts = pps->ctb_addr_rs_to_ts[s-
> >sh.slice_ctb_addr_rs];
> - int prev_rs = pps->ctb_addr_ts_to_rs[ctb_addr_ts - 1];
> - if (s->tab_slice_address[prev_rs] != s->sh.slice_addr) {
> - av_log(s->avctx, AV_LOG_ERROR, "Previous slice segment
> missing\n");
> - return AVERROR_INVALIDDATA;
> - }
> - }
> -
> if (!s->sh.dependent_slice_segment_flag && s->sh.slice_type !=
> HEVC_SLICE_I) {
> ret = ff_hevc_slice_rpl(s);
> if (ret < 0) {
> @@ -2799,6 +2790,15 @@ static int decode_slice_data(HEVCContext *s,
> const H2645NAL *nal, GetBitContext
> return AVERROR_PATCHWELCOME;
> }
>
> + if (s->sh.dependent_slice_segment_flag) {
> + int ctb_addr_ts = pps->ctb_addr_rs_to_ts[s-
> >sh.slice_ctb_addr_rs];
> + int prev_rs = pps->ctb_addr_ts_to_rs[ctb_addr_ts - 1];
> + if (s->tab_slice_address[prev_rs] != s->sh.slice_addr) {
> + av_log(s->avctx, AV_LOG_ERROR, "Previous slice segment
> missing\n");
> + return AVERROR_INVALIDDATA;
> + }
> + }
> +
Ping for review/merge.
Thanks
Fei
> s->local_ctx[0].first_qp_group = !s-
> >sh.dependent_slice_segment_flag;
>
> if (!pps->cu_qp_delta_enabled_flag)
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavc/hevcdec: Put slice address checking after hwaccel decode slice
On Mon, 2024-06-17 at 10:05 +0200, Anton Khirnov wrote: > Quoting fei.w.wang-at-intel@ffmpeg.org (2024-06-14 10:18:19) > > From: Fei Wang > > > > Slice address tab only been updated in software decode slice data. > > > > Fixes hwaccel decoding after > > d725c737fe2a19091b481d4d115fd939e0a674b2. > > > > Signed-off-by: Fei Wang > > --- > > libavcodec/hevc/hevcdec.c | 18 +- > > 1 file changed, 9 insertions(+), 9 deletions(-) > > Looks ok Re-send in v2, together with the other fix which is base on this change. Fei 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 v1] lavc/qsvdec: Add VVC decoder
On Wed, 2024-06-12 at 20:12 +0800, Nuo Mi wrote:
> Hi Fei,
> Thank you for the patch.
> Which hardware supports this? Could you provide the link?
Lunar Lake will. Libvpl will update the supported HW in its code repo
later https://github.com/intel/libvpl. Here is a video on overview of
Lunar Lake:
https://www.youtube.com/watch?v=OGEdN2ahmBQ
>
> On Wed, Jun 12, 2024 at 9:03 AM
> wrote:
>
> > From: Fei Wang
> >
> > Signed-off-by: Fei Wang
> > ---
> > Changelog | 1 +
> > configure | 1 +
> > doc/decoders.texi | 2 +-
> > libavcodec/allcodecs.c | 1 +
> > libavcodec/qsv.c | 4
> > libavcodec/qsvdec.c| 7 ++-
> > libavcodec/version.h | 2 +-
> > 7 files changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/Changelog b/Changelog
> > index 03d6b29ad8..a238a1c1f3 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -12,6 +12,7 @@ version :
> > - qsv_params option added for QSV encoders
> > - VVC decoder compatible with DVB test content
> > - xHE-AAC decoder
> > +- Intel QSV-accelerated VVC decoding
> >
> >
> > version 7.0:
> > diff --git a/configure b/configure
> > index 6c5b8aab9a..b4cf12658d 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3423,6 +3423,7 @@ av1_qsv_encoder_deps="libvpl"
> > av1_amf_encoder_deps="amf"
> > av1_vaapi_encoder_deps="VAEncPictureParameterBufferAV1"
> > av1_vaapi_encoder_select="cbs_av1 vaapi_encode"
> > +vvc_qsv_decoder_select="qsvdec"
> >
> It's better to follow the alphabetical order.
> You can send another patch to fix av1
OK, will fix it in v2.
Thanks
Fei
>
> > # parsers
> > aac_parser_select="adts_header mpeg4audio"
> > diff --git a/doc/decoders.texi b/doc/decoders.texi
> > index 293c82c2ba..2fcc761d2f 100644
> > --- a/doc/decoders.texi
> > +++ b/doc/decoders.texi
> > @@ -157,7 +157,7 @@ Force to use a specific number of threads
> > @section QSV Decoders
> >
> > The family of Intel QuickSync Video decoders (VC1, MPEG-2, H.264,
> > HEVC,
> > -JPEG/MJPEG, VP8, VP9, AV1).
> > +JPEG/MJPEG, VP8, VP9, AV1, VVC).
> >
> > @subsection Common Options
> >
> > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > index b102a8069e..a73b4e1673 100644
> > --- a/libavcodec/allcodecs.c
> > +++ b/libavcodec/allcodecs.c
> > @@ -885,6 +885,7 @@ extern const FFCodec ff_vp9_mediacodec_encoder;
> > extern const FFCodec ff_vp9_qsv_decoder;
> > extern const FFCodec ff_vp9_vaapi_encoder;
> > extern const FFCodec ff_vp9_qsv_encoder;
> > +extern const FFCodec ff_vvc_qsv_decoder;
> >
> > // null codecs
> > extern const FFCodec ff_vnull_decoder;
> > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> > index 0c6fbd0dc0..221c1b24e5 100644
> > --- a/libavcodec/qsv.c
> > +++ b/libavcodec/qsv.c
> > @@ -73,6 +73,10 @@ int ff_qsv_codec_id_to_mfx(enum AVCodecID
> > codec_id)
> > case AV_CODEC_ID_AV1:
> > return MFX_CODEC_AV1;
> > #endif
> > +#if QSV_VERSION_ATLEAST(2, 11)
> > +case AV_CODEC_ID_VVC:
> > +return MFX_CODEC_VVC;
> > +#endif
> >
> > default:
> > break;
> > diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> > index f2cd6ae05c..9ad3439991 100644
> > --- a/libavcodec/qsvdec.c
> > +++ b/libavcodec/qsvdec.c
> > @@ -933,7 +933,8 @@ static int qsv_decode(AVCodecContext *avctx,
> > QSVContext *q,
> > frame->pict_type =
> > ff_qsv_map_pictype(aframe.frame->dec_info.FrameType);
> >
> > if (avctx->codec_id == AV_CODEC_ID_H264 ||
> > -avctx->codec_id == AV_CODEC_ID_HEVC) {
> > +avctx->codec_id == AV_CODEC_ID_HEVC ||
> > +avctx->codec_id == AV_CODEC_ID_VVC) {
> > if (aframe.frame->dec_info.FrameType &
> > MFX_FRAMETYPE_IDR)
> > frame->flags |= AV_FRAME_FLAG_KEY;
> > else
> > @@ -1300,3 +1301,7 @@ DEFINE_QSV_DECODER(vp9, VP9, NULL)
> > #if CONFIG_AV1_QSV_DECODER
> > DEFINE_QSV_DECODER(av1, AV1, NULL)
> > #endif
> > +
> > +#if CONFIG_VVC_QSV_DECODER
> > +DEFINE_QSV_DECODER(vvc, VVC, NULL)
> > +#endif
> > diff --git a/libavcodec/version.h b/libavcodec/version.h
> > index 7acb261bb3..37c4c39451 100644
> > --- a/libavcodec/version.h
> > +++ b/libavcodec/version.h
> > @@ -29,7 +29,7 @@
> >
> > #include "version_major.h"
> >
> > -#define LIBAVCODEC_VERSION_MINOR 7
> > +#define LIBAVCODEC_VERSION_MINOR 8
> > #define LIBAVCODEC_VERSION_MICRO 100
> >
> > #define
> > LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> > --
> > 2.25.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
>
Re: [FFmpeg-devel] [PATCH 37/39] lavc/hevcdec: move some frame-end code to hevc_frame_end()
On Fri, 2024-06-07 at 15:01 +0200, Anton Khirnov wrote:
> Specifically, calling hwaccel end_frame, verifying frame checksum,
> and printing the frame-was-decoded message.
> ---
> libavcodec/hevc/hevcdec.c | 187 +++-
> --
> libavcodec/hevc/hevcdec.h | 1 -
> 2 files changed, 91 insertions(+), 97 deletions(-)
>
> diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
> index 7263b80a24..a8c2172674 100644
> --- a/libavcodec/hevc/hevcdec.c
> +++ b/libavcodec/hevc/hevcdec.c
> @@ -2942,7 +2942,6 @@ static int hevc_frame_start(HEVCContext *s)
> ff_hevc_clear_refs(s);
> }
>
> -s->is_decoded= 0;
> s->slice_idx = 0;
> s->first_nal_type= s->nal_unit_type;
> s->poc = s->sh.poc;
> @@ -3038,6 +3037,75 @@ fail:
> return ret;
> }
>
> +static int verify_md5(HEVCContext *s, AVFrame *frame)
> +{
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame-
> >format);
> +char msg_buf[4 * (50 + 2 * 2 * 16 /* MD5-size */)];
> +int pixel_shift;
> +int err = 0;
> +int i, j;
> +
> +if (!desc)
> +return AVERROR(EINVAL);
> +
> +pixel_shift = desc->comp[0].depth > 8;
> +
> +/* the checksums are LE, so we have to byteswap for >8bpp
> formats
> + * on BE arches */
> +#if HAVE_BIGENDIAN
> +if (pixel_shift && !s->checksum_buf) {
> +av_fast_malloc(>checksum_buf, >checksum_buf_size,
> + FFMAX3(frame->linesize[0], frame-
> >linesize[1],
> + frame->linesize[2]));
> +if (!s->checksum_buf)
> +return AVERROR(ENOMEM);
> +}
> +#endif
> +
> +msg_buf[0] = '\0';
> +for (i = 0; frame->data[i]; i++) {
> +int width = s->avctx->coded_width;
> +int height = s->avctx->coded_height;
> +int w = (i == 1 || i == 2) ? (width >> desc->log2_chroma_w)
> : width;
> +int h = (i == 1 || i == 2) ? (height >> desc->log2_chroma_h)
> : height;
> +uint8_t md5[16];
> +
> +av_md5_init(s->md5_ctx);
> +for (j = 0; j < h; j++) {
> +const uint8_t *src = frame->data[i] + j * frame-
> >linesize[i];
> +#if HAVE_BIGENDIAN
> +if (pixel_shift) {
> +s->bdsp.bswap16_buf((uint16_t *) s->checksum_buf,
> +(const uint16_t *) src, w);
> +src = s->checksum_buf;
> +}
> +#endif
> +av_md5_update(s->md5_ctx, src, w << pixel_shift);
> +}
> +av_md5_final(s->md5_ctx, md5);
> +
> +#define MD5_PRI "%016" PRIx64 "%016" PRIx64
> +#define MD5_PRI_ARG(buf) AV_RB64(buf), AV_RB64((const uint8_t*)(buf)
> + 8)
> +
> +if (!memcmp(md5, s->sei.picture_hash.md5[i], 16)) {
> +av_strlcatf(msg_buf, sizeof(msg_buf),
> +"plane %d - correct " MD5_PRI "; ",
> +i, MD5_PRI_ARG(md5));
> +} else {
> +av_strlcatf(msg_buf, sizeof(msg_buf),
> + "mismatching checksum of plane %d - " MD5_PRI
> " != " MD5_PRI "; ",
> +i, MD5_PRI_ARG(md5), MD5_PRI_ARG(s-
> >sei.picture_hash.md5[i]));
> +err = AVERROR_INVALIDDATA;
> +}
> +}
> +
> +av_log(s->avctx, err < 0 ? AV_LOG_ERROR : AV_LOG_DEBUG,
> + "Verifying checksum for frame with POC %d: %s\n",
> + s->poc, msg_buf);
> +
> +return err;
> +}
> +
> static int hevc_frame_end(HEVCContext *s)
> {
> HEVCFrame *out = s->cur_frame;
> @@ -3062,6 +3130,28 @@ static int hevc_frame_end(HEVCContext *s)
> av_assert1(ret >= 0);
> }
>
> +if (s->avctx->hwaccel) {
> +ret = FF_HW_SIMPLE_CALL(s->avctx, end_frame);
Hwaccel will not decode slice data to get ctb count, frame_end will be
always missed for hwaccel. Maybe better to keep hwaccel frame_end in
its original location.
Thanks
Fei
> +if (ret < 0) {
> +av_log(s->avctx, AV_LOG_ERROR,
> + "hardware accelerator failed to decode
> picture\n");
> +ff_hevc_unref_frame(s->cur_frame, ~0);
> +return ret;
> +}
> +} else {
> +if (s->avctx->err_recognition & AV_EF_CRCCHECK &&
> +s->sei.picture_hash.is_md5) {
> +ret = verify_md5(s, s->cur_frame->f);
> +if (ret < 0 && s->avctx->err_recognition &
> AV_EF_EXPLODE) {
> +ff_hevc_unref_frame(s->cur_frame, ~0);
> +return ret;
> +}
> +}
> +}
> +s->sei.picture_hash.is_md5 = 0;
> +
> +av_log(s->avctx, AV_LOG_DEBUG, "Decoded frame with POC %d.\n",
> s->poc);
> +
> return 0;
> }
>
> @@ -3109,7 +3199,6 @@ static int decode_slice(HEVCContext *s, const
> H2645NAL *nal, GetBitContext *gb)
> ret = hevc_frame_end(s);
> if (ret < 0)
> return ret;
> -s->is_decoded = 1;
> }
>
> return 0;
> @@ -3290,75 +3379,6 @@ fail:
>
Re: [FFmpeg-devel] [PATCH v1] lavc/qsvdec: Add VVC decoder
On Wed, 2024-06-12 at 14:59 +0800, fei.w.w...@intel.com wrote:
> From: Fei Wang
Sorry for duplicate version. Please ignore this one.
Thanks
>
> Signed-off-by: Fei Wang
> ---
> Changelog | 1 +
> configure | 1 +
> doc/decoders.texi | 2 +-
> libavcodec/allcodecs.c | 1 +
> libavcodec/qsv.c | 4
> libavcodec/qsvdec.c| 7 ++-
> libavcodec/version.h | 2 +-
> 7 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/Changelog b/Changelog
> index 03d6b29ad8..a238a1c1f3 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -12,6 +12,7 @@ version :
> - qsv_params option added for QSV encoders
> - VVC decoder compatible with DVB test content
> - xHE-AAC decoder
> +- Intel QSV-accelerated VVC decoding
>
>
> version 7.0:
> diff --git a/configure b/configure
> index 6c5b8aab9a..b4cf12658d 100755
> --- a/configure
> +++ b/configure
> @@ -3423,6 +3423,7 @@ av1_qsv_encoder_deps="libvpl"
> av1_amf_encoder_deps="amf"
> av1_vaapi_encoder_deps="VAEncPictureParameterBufferAV1"
> av1_vaapi_encoder_select="cbs_av1 vaapi_encode"
> +vvc_qsv_decoder_select="qsvdec"
>
> # parsers
> aac_parser_select="adts_header mpeg4audio"
> diff --git a/doc/decoders.texi b/doc/decoders.texi
> index 293c82c2ba..2fcc761d2f 100644
> --- a/doc/decoders.texi
> +++ b/doc/decoders.texi
> @@ -157,7 +157,7 @@ Force to use a specific number of threads
> @section QSV Decoders
>
> The family of Intel QuickSync Video decoders (VC1, MPEG-2, H.264,
> HEVC,
> -JPEG/MJPEG, VP8, VP9, AV1).
> +JPEG/MJPEG, VP8, VP9, AV1, VVC).
>
> @subsection Common Options
>
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index b102a8069e..a73b4e1673 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -885,6 +885,7 @@ extern const FFCodec ff_vp9_mediacodec_encoder;
> extern const FFCodec ff_vp9_qsv_decoder;
> extern const FFCodec ff_vp9_vaapi_encoder;
> extern const FFCodec ff_vp9_qsv_encoder;
> +extern const FFCodec ff_vvc_qsv_decoder;
>
> // null codecs
> extern const FFCodec ff_vnull_decoder;
> diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> index 0c6fbd0dc0..221c1b24e5 100644
> --- a/libavcodec/qsv.c
> +++ b/libavcodec/qsv.c
> @@ -73,6 +73,10 @@ int ff_qsv_codec_id_to_mfx(enum AVCodecID
> codec_id)
> case AV_CODEC_ID_AV1:
> return MFX_CODEC_AV1;
> #endif
> +#if QSV_VERSION_ATLEAST(2, 11)
> +case AV_CODEC_ID_VVC:
> +return MFX_CODEC_VVC;
> +#endif
>
> default:
> break;
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index f2cd6ae05c..9ad3439991 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -933,7 +933,8 @@ static int qsv_decode(AVCodecContext *avctx,
> QSVContext *q,
> frame->pict_type = ff_qsv_map_pictype(aframe.frame-
> >dec_info.FrameType);
>
> if (avctx->codec_id == AV_CODEC_ID_H264 ||
> -avctx->codec_id == AV_CODEC_ID_HEVC) {
> +avctx->codec_id == AV_CODEC_ID_HEVC ||
> +avctx->codec_id == AV_CODEC_ID_VVC) {
> if (aframe.frame->dec_info.FrameType &
> MFX_FRAMETYPE_IDR)
> frame->flags |= AV_FRAME_FLAG_KEY;
> else
> @@ -1300,3 +1301,7 @@ DEFINE_QSV_DECODER(vp9, VP9, NULL)
> #if CONFIG_AV1_QSV_DECODER
> DEFINE_QSV_DECODER(av1, AV1, NULL)
> #endif
> +
> +#if CONFIG_VVC_QSV_DECODER
> +DEFINE_QSV_DECODER(vvc, VVC, NULL)
> +#endif
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 7acb261bb3..37c4c39451 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -29,7 +29,7 @@
>
> #include "version_major.h"
>
> -#define LIBAVCODEC_VERSION_MINOR 7
> +#define LIBAVCODEC_VERSION_MINOR 8
> #define LIBAVCODEC_VERSION_MICRO 100
>
> #define
> LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/2] lavc/vaapi_encode_h265: Map HEVC AV REXT profile to VA REXT profile
On Tue, 2024-04-16 at 04:57 +, Wang, Fei W wrote:
> On Mon, 2024-04-15 at 23:07 +0100, Mark Thompson wrote:
> > On 15/04/2024 02:21, Xiang, Haihao wrote:
> > > On Ma, 2024-03-18 at 12:21 +0800,
> > > fei.w.wang-at-intel@ffmpeg.org wrote:
> > > > From: Fei Wang
> > > >
> > > > There is no Main8/10 profile defined in HEVC REXT profiles. Use
> > > > Main12
> > > > which is compatible with 8/10bit.
> > > >
> > > > Signed-off-by: Fei Wang
> > > > ---
> > > > libavcodec/vaapi_encode_h265.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavcodec/vaapi_encode_h265.c
> > > > b/libavcodec/vaapi_encode_h265.c
> > > > index c4aabbf5ed..43755e2188 100644
> > > > --- a/libavcodec/vaapi_encode_h265.c
> > > > +++ b/libavcodec/vaapi_encode_h265.c
> > > > @@ -1305,12 +1305,12 @@ static av_cold int
> > > > vaapi_encode_h265_configure(AVCodecContext *avctx)
> > > >
> > > > static const VAAPIEncodeProfile vaapi_encode_h265_profiles[] =
> > > > {
> > > > { AV_PROFILE_HEVC_MAIN, 8, 3, 1, 1,
> > > > VAProfileHEVCMain },
> > > > -{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 1,
> > > > VAProfileHEVCMain },
> > > > #if VA_CHECK_VERSION(0, 37, 0)
> > > > { AV_PROFILE_HEVC_MAIN_10, 10, 3, 1, 1,
> > > > VAProfileHEVCMain10 },
> > > > -{ AV_PROFILE_HEVC_REXT,10, 3, 1, 1,
> > > > VAProfileHEVCMain10 },
> > > > #endif
> > > > #if VA_CHECK_VERSION(1, 2, 0)
> > > > +{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 1,
> > > > VAProfileHEVCMain12
> > > > },
> > > > +{ AV_PROFILE_HEVC_REXT,10, 3, 1, 1,
> > > > VAProfileHEVCMain12
> > > > },
> > > > { AV_PROFILE_HEVC_REXT,12, 3, 1, 1,
> > > > VAProfileHEVCMain12
> > > > },
> > > > { AV_PROFILE_HEVC_REXT, 8, 3, 1, 0,
> > > > VAProfileHEVCMain422_10 },
> > > > { AV_PROFILE_HEVC_REXT,10, 3, 1, 0,
> > > > VAProfileHEVCMain422_10 },
> > >
> > > Patchset LGTM, I'll push it if there are no comments.
> >
> > Why is this change helpful?
>
> Together with 2/2 fix on the hw support VAAPI main12 decode and
> encode:
>
> $ ffmpeg -hwaccel vaapi -f lavfi -i testsrc -vf
> 'format=nv12,hwupload'
> -c:v hevc_vaapi -profile:v rext -vframes 30 -y out.mp4
>
> $ ffmpeg -hwaccel vaapi -i out.mp4 -f null -
> ...
> [hevc @ 0x55b4fda0a780] HEVC profile is not found.
> [hevc @ 0x55b4fda0a780] No support for codec hevc profile 4.
> [hevc @ 0x55b4fda0a780] Failed setup for format vaapi: hwaccel
> initialisation returned error.
>
> Same for p010le as input of encoder.
Hi
Any further comments on this patchset?
Thanks
Fei
>
> Thanks
> Fei
> > We don't use the rext features allowed in these cases (unlike in
> > the
> > decoder where we have to support them), so Main / Main 10 encoders
> > will be able to produce a compatible stream without pointlessly
> > requiring Main 12 support which many devices do not have.
> >
> > Thanks,
> >
> > - Mark
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/2] lavc/vaapi_encode_h265: Map HEVC AV REXT profile to VA REXT profile
On Mon, 2024-04-15 at 23:07 +0100, Mark Thompson wrote:
> On 15/04/2024 02:21, Xiang, Haihao wrote:
> > On Ma, 2024-03-18 at 12:21 +0800,
> > fei.w.wang-at-intel@ffmpeg.org wrote:
> > > From: Fei Wang
> > >
> > > There is no Main8/10 profile defined in HEVC REXT profiles. Use
> > > Main12
> > > which is compatible with 8/10bit.
> > >
> > > Signed-off-by: Fei Wang
> > > ---
> > > libavcodec/vaapi_encode_h265.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/vaapi_encode_h265.c
> > > b/libavcodec/vaapi_encode_h265.c
> > > index c4aabbf5ed..43755e2188 100644
> > > --- a/libavcodec/vaapi_encode_h265.c
> > > +++ b/libavcodec/vaapi_encode_h265.c
> > > @@ -1305,12 +1305,12 @@ static av_cold int
> > > vaapi_encode_h265_configure(AVCodecContext *avctx)
> > >
> > > static const VAAPIEncodeProfile vaapi_encode_h265_profiles[] = {
> > > { AV_PROFILE_HEVC_MAIN, 8, 3, 1, 1,
> > > VAProfileHEVCMain },
> > > -{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 1,
> > > VAProfileHEVCMain },
> > > #if VA_CHECK_VERSION(0, 37, 0)
> > > { AV_PROFILE_HEVC_MAIN_10, 10, 3, 1, 1,
> > > VAProfileHEVCMain10 },
> > > -{ AV_PROFILE_HEVC_REXT,10, 3, 1, 1,
> > > VAProfileHEVCMain10 },
> > > #endif
> > > #if VA_CHECK_VERSION(1, 2, 0)
> > > +{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 1, VAProfileHEVCMain12
> > > },
> > > +{ AV_PROFILE_HEVC_REXT,10, 3, 1, 1, VAProfileHEVCMain12
> > > },
> > > { AV_PROFILE_HEVC_REXT,12, 3, 1, 1, VAProfileHEVCMain12
> > > },
> > > { AV_PROFILE_HEVC_REXT, 8, 3, 1, 0,
> > > VAProfileHEVCMain422_10 },
> > > { AV_PROFILE_HEVC_REXT,10, 3, 1, 0,
> > > VAProfileHEVCMain422_10 },
> >
> > Patchset LGTM, I'll push it if there are no comments.
>
> Why is this change helpful?
Together with 2/2 fix on the hw support VAAPI main12 decode and encode:
$ ffmpeg -hwaccel vaapi -f lavfi -i testsrc -vf 'format=nv12,hwupload'
-c:v hevc_vaapi -profile:v rext -vframes 30 -y out.mp4
$ ffmpeg -hwaccel vaapi -i out.mp4 -f null -
...
[hevc @ 0x55b4fda0a780] HEVC profile is not found.
[hevc @ 0x55b4fda0a780] No support for codec hevc profile 4.
[hevc @ 0x55b4fda0a780] Failed setup for format vaapi: hwaccel
initialisation returned error.
Same for p010le as input of encoder.
Thanks
Fei
>
> We don't use the rext features allowed in these cases (unlike in the
> decoder where we have to support them), so Main / Main 10 encoders
> will be able to produce a compatible stream without pointlessly
> requiring Main 12 support which many devices do not have.
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 7/7] lavc/vaapi_dec: Add VVC decoder
On Tue, 2024-04-02 at 20:48 +0800, Nuo Mi wrote:
>
>
> On Thu, Mar 28, 2024 at 9:27 AM
> wrote:
> > From: Fei Wang
> >
> > Signed-off-by: Fei Wang
> > ---
> > Changelog | 4 +
> > configure | 3 +
> > libavcodec/Makefile | 1 +
> > libavcodec/hwaccels.h | 1 +
> > libavcodec/vaapi_decode.c | 7 +
> > libavcodec/vaapi_vvc.c| 657
> > ++
> > libavcodec/version.h | 2 +-
> > libavcodec/vvc/vvcdec.c | 15 +-
> > 8 files changed, 688 insertions(+), 2 deletions(-)
> > create mode 100644 libavcodec/vaapi_vvc.c
> >
> > diff --git a/Changelog b/Changelog
> > index e83a00e35c..3108e65558 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -1,6 +1,10 @@
> > Entries are sorted chronologically from oldest to youngest within
> > each release,
> > releases are sorted from youngest to oldest.
> >
> > +version :
> > +- VVC VAAPI decoder
> > +
> > +
> > version 7.0:
> > - DXV DXT1 encoder
> > - LEAD MCMP decoder
> > diff --git a/configure b/configure
> > index 2a1d22310b..d902c9adc8 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3258,6 +3258,8 @@ vp9_vdpau_hwaccel_deps="vdpau
> > VdpPictureInfoVP9"
> > vp9_vdpau_hwaccel_select="vp9_decoder"
> > vp9_videotoolbox_hwaccel_deps="videotoolbox"
> > vp9_videotoolbox_hwaccel_select="vp9_decoder"
> > +vvc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferVVC"
> > +vvc_vaapi_hwaccel_select="vvc_decoder"
> > wmv3_d3d11va_hwaccel_select="vc1_d3d11va_hwaccel"
> > wmv3_d3d11va2_hwaccel_select="vc1_d3d11va2_hwaccel"
> > wmv3_d3d12va_hwaccel_select="vc1_d3d12va_hwaccel"
> > @@ -7250,6 +7252,7 @@ if enabled vaapi; then
> > check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0,
> > 0)"
> >
> > check_type "va/va.h va/va_dec_hevc.h"
> > "VAPictureParameterBufferHEVC"
> > +check_type "va/va.h va/va_dec_vvc.h"
> > "VAPictureParameterBufferVVC"
> > check_struct "va/va.h" "VADecPictureParameterBufferVP9"
> > bit_depth
> > check_struct "va/va.h" "VADecPictureParameterBufferAV1"
> > bit_depth_idx
> > check_type "va/va.h va/va_vpp.h"
> > "VAProcFilterParameterBufferHDRToneMapping"
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 9ce6d445c1..343b037636 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -1054,6 +1054,7 @@ OBJS-$(CONFIG_VP9_VAAPI_HWACCEL) +=
> > vaapi_vp9.o
> > OBJS-$(CONFIG_VP9_VDPAU_HWACCEL) += vdpau_vp9.o
> > OBJS-$(CONFIG_VP9_VIDEOTOOLBOX_HWACCEL) += videotoolbox_vp9.o
> > OBJS-$(CONFIG_VP8_QSV_HWACCEL)+= qsvdec.o
> > +OBJS-$(CONFIG_VVC_VAAPI_HWACCEL) += vaapi_vvc.o
> >
> > # Objects duplicated from other libraries for shared builds
> > SHLIBOBJS += log2_tab.o reverse.o
> > diff --git a/libavcodec/hwaccels.h b/libavcodec/hwaccels.h
> > index 5171e4c7d7..88d6b9a9b5 100644
> > --- a/libavcodec/hwaccels.h
> > +++ b/libavcodec/hwaccels.h
> > @@ -82,6 +82,7 @@ extern const struct FFHWAccel
> > ff_vp9_nvdec_hwaccel;
> > extern const struct FFHWAccel ff_vp9_vaapi_hwaccel;
> > extern const struct FFHWAccel ff_vp9_vdpau_hwaccel;
> > extern const struct FFHWAccel ff_vp9_videotoolbox_hwaccel;
> > +extern const struct FFHWAccel ff_vvc_vaapi_hwaccel;
> > extern const struct FFHWAccel ff_wmv3_d3d11va_hwaccel;
> > extern const struct FFHWAccel ff_wmv3_d3d11va2_hwaccel;
> > extern const struct FFHWAccel ff_wmv3_d3d12va_hwaccel;
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index 1b1972a2a9..ceeb1f1a12 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -455,6 +455,9 @@ static const struct {
> > MAP(AV1, AV1_MAIN,AV1Profile0),
> > MAP(AV1, AV1_HIGH,AV1Profile1),
> > #endif
> > +#if VA_CHECK_VERSION(1, 22, 0)
> > +MAP(H266,VVC_MAIN_10, VVCMain10),
> > +#endif
> >
> > #undef MAP
> > };
> > @@ -627,6 +630,10 @@ static int
> > vaapi_decode_make_config(AVCodecContext *avctx,
> > case AV_CODEC_ID_VP8:
> > frames->initial_pool_size += 3;
> > break;
> > +case AV_CODEC_ID_H266:
> > +// Add additional 16 for maximum 16 frames delay in
> > vvc native decode.
> > +frames->initial_pool_size += 32;
>
> One frame of 8k YUV444, 10 bits, is about 200MB. Thirty-two frames
> amount to approximately 6GB.Can we dynamically allocate the buffer
> pool?
It's processing in other thread:
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=11316
>
> The software decoder requires a delay of 16 frames to ensure full
> utilization of CPUs. In the future, we may consider increasing this
> to 32 or even 64 frames.
> However, for hardware decoding, given that all processing occurs on
> the GPU, we do not require any delay.
The delay can avoid sync hardware task immediately once it is
submitted, which can avoid hardware switch tasks
Re: [FFmpeg-devel] [PATCH v1 6/7] lavc/vvc_dec: Add hardware decode API
On Thu, 2024-03-28 at 03:04 +0100, Andreas Rheinhardt wrote:
> fei.w.wang-at-intel@ffmpeg.org:
> > From: Fei Wang
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/vvc/vvc_refs.c | 6
> > libavcodec/vvc/vvcdec.c | 67
> > +++
> > libavcodec/vvc/vvcdec.h | 5 +++
> > 3 files changed, 72 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/vvc/vvc_refs.c b/libavcodec/vvc/vvc_refs.c
> > index bf70777550..c9f89a5a0a 100644
> > --- a/libavcodec/vvc/vvc_refs.c
> > +++ b/libavcodec/vvc/vvc_refs.c
> > @@ -25,6 +25,7 @@
> > #include "libavutil/thread.h"
> > #include "libavcodec/refstruct.h"
> > #include "libavcodec/thread.h"
> > +#include "libavcodec/decode.h"
> >
> > #include "vvc_refs.h"
> >
> > @@ -56,6 +57,7 @@ void ff_vvc_unref_frame(VVCFrameContext *fc,
> > VVCFrame *frame, int flags)
> > ff_refstruct_unref(>rpl_tab);
> >
> > frame->collocated_ref = NULL;
> > +ff_refstruct_unref(>hwaccel_picture_private);
> > }
> > }
> >
> > @@ -138,6 +140,10 @@ static VVCFrame *alloc_frame(VVCContext *s,
> > VVCFrameContext *fc)
> > if (!frame->progress)
> > goto fail;
> >
> > +ret = ff_hwaccel_frame_priv_alloc(s->avctx,
> > >hwaccel_picture_private);
> > +if (ret < 0)
> > +goto fail;
> > +
> > return frame;
> > fail:
> > ff_vvc_unref_frame(fc, frame, ~0);
> > diff --git a/libavcodec/vvc/vvcdec.c b/libavcodec/vvc/vvcdec.c
> > index d5704aca25..f2e269ce76 100644
> > --- a/libavcodec/vvc/vvcdec.c
> > +++ b/libavcodec/vvc/vvcdec.c
> > @@ -24,6 +24,8 @@
> > #include "libavcodec/decode.h"
> > #include "libavcodec/profiles.h"
> > #include "libavcodec/refstruct.h"
> > +#include "libavcodec/hwconfig.h"
> > +#include "libavcodec/hwaccel_internal.h"
> > #include "libavutil/cpu.h"
> > #include "libavutil/thread.h"
> >
> > @@ -563,6 +565,8 @@ static int ref_frame(VVCFrame *dst, const
> > VVCFrame *src)
> >
> > ff_refstruct_replace(>rpl_tab, src->rpl_tab);
> > ff_refstruct_replace(>rpl, src->rpl);
> > +ff_refstruct_replace(>hwaccel_picture_private,
> > + src->hwaccel_picture_private);
> > dst->nb_rpl_elems = src->nb_rpl_elems;
> >
> > dst->poc = src->poc;
> > @@ -718,17 +722,41 @@ static int slice_start(SliceContext *sc,
> > VVCContext *s, VVCFrameContext *fc,
> > return 0;
> > }
> >
> > +static enum AVPixelFormat get_format(AVCodecContext *avctx, const
> > VVCSPS *sps)
> > +{
> > +#define HWACCEL_MAX 0
> > +
> > +enum AVPixelFormat pix_fmts[HWACCEL_MAX + 2], *fmt = pix_fmts;
> > +
> > +switch (sps->pix_fmt) {
> > +case AV_PIX_FMT_YUV420P:
> > +break;
> > +case AV_PIX_FMT_YUV420P10:
> > +break;
> > +}
> > +
> > +*fmt++ = sps->pix_fmt;
> > +*fmt = AV_PIX_FMT_NONE;
> > +
> > +return ff_get_format(avctx, pix_fmts);
> > +}
> > +
> > static void export_frame_params(VVCContext *s, const
> > VVCFrameContext *fc)
> > {
> > AVCodecContext *c = s->avctx;
> > const VVCSPS *sps = fc->ps.sps;
> > const VVCPPS *pps = fc->ps.pps;
> >
> > -c->pix_fmt = sps->pix_fmt;
> > -c->coded_width = pps->width;
> > -c->coded_height = pps->height;
> > -c->width= pps->width - ((pps->r-
> > >pps_conf_win_left_offset + pps->r->pps_conf_win_right_offset) <<
> > sps->hshift[CHROMA]);
> > -c->height = pps->height - ((pps->r-
> > >pps_conf_win_top_offset + pps->r->pps_conf_win_bottom_offset) <<
> > sps->vshift[CHROMA]);
> > +// Reset HW config if pix_fmt/w/h change.
> > +if (s->pix_fmt != sps->pix_fmt || c->coded_width != pps->width
> > || c->coded_height != pps->height) {
> > +c->coded_width = pps->width;
> > +c->coded_height = pps->height;
> > +c->pix_fmt = get_format(c, sps);
> > +s->pix_fmt = sps->pix_fmt;
> > +}
> > +
> > +c->width = pps->width - ((pps->r->pps_conf_win_left_offset +
> > pps->r->pps_conf_win_right_offset) << sps->hshift[CHROMA]);
> > +c->height = pps->height - ((pps->r->pps_conf_win_top_offset +
> > pps->r->pps_conf_win_bottom_offset) << sps->vshift[CHROMA]);
> > }
> >
> > static int frame_setup(VVCFrameContext *fc, VVCContext *s)
> > @@ -771,6 +799,20 @@ static int decode_slice(VVCContext *s,
> > VVCFrameContext *fc, const H2645NAL *nal,
> > ret = slice_init_entry_points(sc, fc, nal, unit);
> > if (ret < 0)
> > return ret;
> > +
> > +if (s->avctx->hwaccel) {
> > +if (is_first_slice) {
> > +ret = FF_HW_CALL(s->avctx, start_frame, NULL, 0);
> > +if (ret < 0)
> > +return ret;
> > +}
> > +
> > +ret = FF_HW_CALL(s->avctx, decode_slice,
> > + nal->raw_data, nal->raw_size);
> > +if (ret < 0)
> > +return ret;
> > +}
> > +
> > fc->nb_slices++;
> >
> > return 0;
> > @@ -885,9 +927,20 @@
Re: [FFmpeg-devel] [PATCH v1 1/7] lavc/vaapi_dec: Create VA parameters dynamically
On Mon, 2024-04-01 at 20:52 +0100, Mark Thompson wrote:
> On 28/03/2024 01:26, fei.w.wang-at-intel@ffmpeg.org wrote:
> > From: Fei Wang
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/vaapi_decode.c | 29 ++---
> > libavcodec/vaapi_decode.h | 7 ++-
> > 2 files changed, 24 insertions(+), 12 deletions(-)
>
> This is because the VVC code is going to want to make a lot more of
> these param buffers - can we just set a slightly larger fixed limit?
>
> If you always need 20 buffers (say), then this has turned 1
> allocation per picture into 3 and used more memory in the non-VVC
> case as well because of the overhead of that (but if you might
> variably need up to 200 then this is completely fair).
VVC support 1000 slices and 990 tile columns, and other buffer like
APS/tile_rows... So there will be 1990+ buffers needed at most in
theory.
For other non-VVC case, 16 buffers will be created which is same with
before.
>
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index cca94b5336..1b1972a2a9 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -38,12 +38,23 @@ int
> > ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
> > {
> > VAAPIDecodeContext *ctx = avctx->internal->hwaccel_priv_data;
> > VAStatus vas;
> > -VABufferID buffer;
> >
> > -av_assert0(pic->nb_param_buffers + 1 <= MAX_PARAM_BUFFERS);
> > +av_assert0(pic->nb_param_buffers <= pic->param_allocated);
> > +if (pic->nb_param_buffers == pic->param_allocated) {
> > +pic->param_buffers =
> > +av_realloc_array(pic->param_buffers,
> > + pic->param_allocated + 16,
> > + sizeof(*pic->param_buffers));
>
> Use av_reallocp_array() to avoid leaking the pointer on failure.
>
> > +if (!pic->param_buffers)
> > +return AVERROR(ENOMEM);
> > +
> > +pic->param_allocated += 16;
> > +}
> > +av_assert0(pic->nb_param_buffers + 1 <= pic->param_allocated);
> >
> > vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
> > - type, size, 1, (void*)data, );
> > + type, size, 1, (void*)data,
> > + >param_buffers[pic-
> > >nb_param_buffers]);
> > if (vas != VA_STATUS_SUCCESS) {
> > av_log(avctx, AV_LOG_ERROR, "Failed to create parameter "
> > "buffer (type %d): %d (%s).\n",
> > @@ -51,14 +62,14 @@ int
> > ff_vaapi_decode_make_param_buffer(AVCodecContext *avctx,
> > return AVERROR(EIO);
> > }
> >
> > -pic->param_buffers[pic->nb_param_buffers++] = buffer;
> > -
> > av_log(avctx, AV_LOG_DEBUG, "Param buffer (type %d, %zu
> > bytes) "
> > - "is %#x.\n", type, size, buffer);
> > + "is %#x.\n", type, size, pic->param_buffers[pic-
> > >nb_param_buffers]);
> > +
> > +++pic->nb_param_buffers;
> > +
> > return 0;
> > }
> >
> > -
> > int ff_vaapi_decode_make_slice_buffer(AVCodecContext *avctx,
> > VAAPIDecodePicture *pic,
> > const void *params_data,
> > @@ -215,6 +226,8 @@ fail:
> > fail_at_end:
> > exit:
> > pic->nb_param_buffers = 0;
> > +pic->param_allocated = 0;
> > +av_freep(>param_buffers);
> > pic->nb_slices= 0;
> > pic->slices_allocated = 0;
> > av_freep(>slice_buffers);
> > @@ -228,6 +241,8 @@ int ff_vaapi_decode_cancel(AVCodecContext
> > *avctx,
> > ff_vaapi_decode_destroy_buffers(avctx, pic);
> >
> > pic->nb_param_buffers = 0;
> > +pic->param_allocated = 0;
> > +av_freep(>param_buffers);
> > pic->nb_slices= 0;
> > pic->slices_allocated = 0;
> > av_freep(>slice_buffers);
> > diff --git a/libavcodec/vaapi_decode.h b/libavcodec/vaapi_decode.h
> > index 6beda14e52..a41d7ff2ff 100644
> > --- a/libavcodec/vaapi_decode.h
> > +++ b/libavcodec/vaapi_decode.h
> > @@ -32,15 +32,12 @@ static inline VASurfaceID
> > ff_vaapi_get_surface_id(AVFrame *pic)
> > return (uintptr_t)pic->data[3];
> > }
> >
> > -enum {
> > -MAX_PARAM_BUFFERS = 16,
> > -};
> > -
> > typedef struct VAAPIDecodePicture {
> > VASurfaceID output_surface;
> >
> > intnb_param_buffers;
> > -VABufferIDparam_buffers[MAX_PARAM_BUFFERS];
> > +VABufferID *param_buffers;
>
> Previously the array was zeroed at allocation but now it isn't. Can
> you confirm that that isn't a problem?
It is should not be a problem, all buffers visited and destroyed
through nb_param_buffers which record if the buffer is valid.
Thanks
Fei
>
> > +int param_allocated;
>
> Maybe "nb_param_buffers_allocated" would be clearer.
>
> >
> > intnb_slices;
> > VABufferID *slice_buffers;
>
>
Re: [FFmpeg-devel] [PATCH v3 2/2] lavc/vaapi_encode_h265: Set general_*_constriaint flags with profile
On Mon, 2024-04-01 at 21:02 +0100, Mark Thompson wrote:
> On 20/03/2024 08:44, Wang, Fei W wrote:
> > On Mon, 2024-03-18 at 21:22 +, Mark Thompson wrote:
> > > On 18/03/2024 04:21, fei.w.wang-at-intel@ffmpeg.org wrote:
> > > > From: Fei Wang
> > > >
> > > > According to Table A.2 in spec.
> > > >
> > > > Signed-off-by: Fei Wang
> > > > ---
> > > >libavcodec/vaapi_encode_h265.c | 176
> > > > +++-
> > > > -
> > > >1 file changed, 123 insertions(+), 53 deletions(-)
> > > >
> > > > diff --git a/libavcodec/vaapi_encode_h265.c
> > > > b/libavcodec/vaapi_encode_h265.c
> > > > index 43755e2188..5ed317ce11 100644
> > > > --- a/libavcodec/vaapi_encode_h265.c
> > > > +++ b/libavcodec/vaapi_encode_h265.c
> > > > @@ -258,6 +258,124 @@ fail:
> > > >return err;
> > > >}
> > > >
> > > > +static int vaapi_encode_h265_init_ptl(AVCodecContext *avctx)
> > > > +{
> > > > +VAAPIEncodeContext *ctx = avctx->priv_data;
> > > > +VAAPIEncodeH265Context *priv = avctx->priv_data;
> > > > +H265RawVPS *vps = >raw_vps;
> > > > +H265RawProfileTierLevel *ptl = >profile_tier_level;
> > > > +
> > > > +ptl->general_profile_space = 0;
> > > > +ptl->general_profile_idc = avctx->profile;
> > > > +ptl->general_tier_flag = priv->tier;
> > > > +
> > > > +ptl->general_profile_compatibility_flag[ptl-
> > > > > general_profile_idc] = 1;
> > > > +
> > > > +if (ptl->general_profile_compatibility_flag[1])
> > > > +ptl->general_profile_compatibility_flag[2] = 1;
> > > > +if (ptl->general_profile_compatibility_flag[3]) {
> > > > +ptl->general_profile_compatibility_flag[1] = 1;
> > > > +ptl->general_profile_compatibility_flag[2] = 1;
> > > > +}
> > > > +
> > > > +ptl->general_progressive_source_flag= 1;
> > > > +ptl->general_interlaced_source_flag = 0;
> > > > +ptl->general_non_packed_constraint_flag = 1;
> > > > +ptl->general_frame_only_constraint_flag = 1;
> > > > +
> > > > +if (avctx->profile >= 4) {
> > > > +ptl->general_intra_constraint_flag= ctx-
> > > > > gop_size == 1;
> > > > +ptl->general_one_picture_only_constraint_flag = 0;
> > > > +ptl->general_lower_bit_rate_constraint_flag = 1;
> > > > +ptl->general_max_14bit_constraint_flag= 0;
> > > > +
> > > > +switch (ctx->va_profile) {
> > > > +#if VA_CHECK_VERSION(1, 2, 0)
> > > > +case VAProfileHEVCMain12:
> > > > +// Main 12
> > > > +ptl->general_max_12bit_constraint_flag = 1;
> > > > +ptl->general_max_10bit_constraint_flag = 0;
> > > > +ptl->general_max_8bit_constraint_flag = 0;
> > > > +ptl->general_max_422chroma_constraint_flag = 1;
> > > > +ptl->general_max_420chroma_constraint_flag = 1;
> > > > +ptl->general_max_monochrome_constraint_flag = 0;
> > > > +break;
> > > > +case VAProfileHEVCMain422_10:
> > > > +// Main 4:2:2 10
> > > > +ptl->general_max_12bit_constraint_flag = 1;
> > > > +ptl->general_max_10bit_constraint_flag = 1;
> > > > +ptl->general_max_8bit_constraint_flag = 0;
> > > > +ptl->general_max_422chroma_constraint_flag = 1;
> > > > +ptl->general_max_420chroma_constraint_flag = 0;
> > > > +ptl->general_max_monochrome_constraint_flag = 0;
> > > > +break;
> > > > +case VAProfileHEVCMain422_12:
> > > > +// Main 4:2:2 12
> > > > +ptl->general_max_12bit_constraint_flag = 1;
> > > > +ptl->general_max_10bit_constraint_flag = 0;
> > > > +ptl->general_max_8bit_constraint_flag = 0;
> > > > +ptl->general_max_422chroma_constrai
Re: [FFmpeg-devel] [PATCH v3 2/2] lavc/vaapi_encode_h265: Set general_*_constriaint flags with profile
On Wed, 2024-03-20 at 16:44 +0800, Fei Wang wrote:
> On Mon, 2024-03-18 at 21:22 +, Mark Thompson wrote:
> > On 18/03/2024 04:21, fei.w.wang-at-intel@ffmpeg.org wrote:
> > > From: Fei Wang
> > >
> > > According to Table A.2 in spec.
> > >
> > > Signed-off-by: Fei Wang
> > > ---
> > > libavcodec/vaapi_encode_h265.c | 176 +++---
> > > --
> > > -
> > > 1 file changed, 123 insertions(+), 53 deletions(-)
> > >
> > > diff --git a/libavcodec/vaapi_encode_h265.c
> > > b/libavcodec/vaapi_encode_h265.c
> > > index 43755e2188..5ed317ce11 100644
> > > --- a/libavcodec/vaapi_encode_h265.c
> > > +++ b/libavcodec/vaapi_encode_h265.c
> > > @@ -258,6 +258,124 @@ fail:
> > > return err;
> > > }
> > >
> > > +static int vaapi_encode_h265_init_ptl(AVCodecContext *avctx)
> > > +{
> > > +VAAPIEncodeContext *ctx = avctx->priv_data;
> > > +VAAPIEncodeH265Context *priv = avctx->priv_data;
> > > +H265RawVPS *vps = >raw_vps;
> > > +H265RawProfileTierLevel *ptl = >profile_tier_level;
> > > +
> > > +ptl->general_profile_space = 0;
> > > +ptl->general_profile_idc = avctx->profile;
> > > +ptl->general_tier_flag = priv->tier;
> > > +
> > > +ptl->general_profile_compatibility_flag[ptl-
> > > > general_profile_idc] = 1;
> > > +
> > > +if (ptl->general_profile_compatibility_flag[1])
> > > +ptl->general_profile_compatibility_flag[2] = 1;
> > > +if (ptl->general_profile_compatibility_flag[3]) {
> > > +ptl->general_profile_compatibility_flag[1] = 1;
> > > +ptl->general_profile_compatibility_flag[2] = 1;
> > > +}
> > > +
> > > +ptl->general_progressive_source_flag= 1;
> > > +ptl->general_interlaced_source_flag = 0;
> > > +ptl->general_non_packed_constraint_flag = 1;
> > > +ptl->general_frame_only_constraint_flag = 1;
> > > +
> > > +if (avctx->profile >= 4) {
> > > +ptl->general_intra_constraint_flag= ctx-
> > > > gop_size == 1;
> > > +ptl->general_one_picture_only_constraint_flag = 0;
> > > +ptl->general_lower_bit_rate_constraint_flag = 1;
> > > +ptl->general_max_14bit_constraint_flag= 0;
> > > +
> > > +switch (ctx->va_profile) {
> > > +#if VA_CHECK_VERSION(1, 2, 0)
> > > +case VAProfileHEVCMain12:
> > > +// Main 12
> > > +ptl->general_max_12bit_constraint_flag = 1;
> > > +ptl->general_max_10bit_constraint_flag = 0;
> > > +ptl->general_max_8bit_constraint_flag = 0;
> > > +ptl->general_max_422chroma_constraint_flag = 1;
> > > +ptl->general_max_420chroma_constraint_flag = 1;
> > > +ptl->general_max_monochrome_constraint_flag = 0;
> > > +break;
> > > +case VAProfileHEVCMain422_10:
> > > +// Main 4:2:2 10
> > > +ptl->general_max_12bit_constraint_flag = 1;
> > > +ptl->general_max_10bit_constraint_flag = 1;
> > > +ptl->general_max_8bit_constraint_flag = 0;
> > > +ptl->general_max_422chroma_constraint_flag = 1;
> > > +ptl->general_max_420chroma_constraint_flag = 0;
> > > +ptl->general_max_monochrome_constraint_flag = 0;
> > > +break;
> > > +case VAProfileHEVCMain422_12:
> > > +// Main 4:2:2 12
> > > +ptl->general_max_12bit_constraint_flag = 1;
> > > +ptl->general_max_10bit_constraint_flag = 0;
> > > +ptl->general_max_8bit_constraint_flag = 0;
> > > +ptl->general_max_422chroma_constraint_flag = 1;
> > > +ptl->general_max_420chroma_constraint_flag = 0;
> > > +ptl->general_max_monochrome_constraint_flag = 0;
> > > +break;
> > > +case VAProfileHEVCMain444:
> > > +// Main 4:4:4
> > > +ptl->general_max_12bit_constraint_flag = 1;
> > > +ptl->general_max_10bit_constraint_flag = 1;
> > > +ptl->general_max_8bit_constraint_flag = 1;
> > > +ptl->general_max_422chroma_constraint_flag = 0;
> > > +ptl->general_max_420chroma_constraint_flag = 0;
> > > +ptl->general_max_monochrome_constraint_flag = 0;
> > > +break;
> > > +case VAProfileHEVCMain444_10:
> > > +// Main 4:4:4 10
> > > +ptl->general_max_12bit_constraint_flag = 1;
> > > +ptl->general_max_10bit_constraint_flag = 1;
> > > +ptl->general_max_8bit_constraint_flag = 0;
> > > +ptl->general_max_422chroma_constraint_flag = 0;
> > > +ptl->general_max_420chroma_constraint_flag = 0;
> > > +ptl->general_max_monochrome_constraint_flag = 0;
> > > +break;
> > > +case VAProfileHEVCMain444_12:
> > > +// Main 4:4:4 12
> > > +ptl->general_max_12bit_constraint_flag
Re: [FFmpeg-devel] [PATCH v3 2/2] lavc/vaapi_encode_h265: Set general_*_constriaint flags with profile
On Mon, 2024-03-18 at 21:22 +, Mark Thompson wrote:
> On 18/03/2024 04:21, fei.w.wang-at-intel@ffmpeg.org wrote:
> > From: Fei Wang
> >
> > According to Table A.2 in spec.
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/vaapi_encode_h265.c | 176 +++-
> > -
> > 1 file changed, 123 insertions(+), 53 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode_h265.c
> > b/libavcodec/vaapi_encode_h265.c
> > index 43755e2188..5ed317ce11 100644
> > --- a/libavcodec/vaapi_encode_h265.c
> > +++ b/libavcodec/vaapi_encode_h265.c
> > @@ -258,6 +258,124 @@ fail:
> > return err;
> > }
> >
> > +static int vaapi_encode_h265_init_ptl(AVCodecContext *avctx)
> > +{
> > +VAAPIEncodeContext *ctx = avctx->priv_data;
> > +VAAPIEncodeH265Context *priv = avctx->priv_data;
> > +H265RawVPS *vps = >raw_vps;
> > +H265RawProfileTierLevel *ptl = >profile_tier_level;
> > +
> > +ptl->general_profile_space = 0;
> > +ptl->general_profile_idc = avctx->profile;
> > +ptl->general_tier_flag = priv->tier;
> > +
> > +ptl->general_profile_compatibility_flag[ptl-
> > >general_profile_idc] = 1;
> > +
> > +if (ptl->general_profile_compatibility_flag[1])
> > +ptl->general_profile_compatibility_flag[2] = 1;
> > +if (ptl->general_profile_compatibility_flag[3]) {
> > +ptl->general_profile_compatibility_flag[1] = 1;
> > +ptl->general_profile_compatibility_flag[2] = 1;
> > +}
> > +
> > +ptl->general_progressive_source_flag= 1;
> > +ptl->general_interlaced_source_flag = 0;
> > +ptl->general_non_packed_constraint_flag = 1;
> > +ptl->general_frame_only_constraint_flag = 1;
> > +
> > +if (avctx->profile >= 4) {
> > +ptl->general_intra_constraint_flag= ctx-
> > >gop_size == 1;
> > +ptl->general_one_picture_only_constraint_flag = 0;
> > +ptl->general_lower_bit_rate_constraint_flag = 1;
> > +ptl->general_max_14bit_constraint_flag= 0;
> > +
> > +switch (ctx->va_profile) {
> > +#if VA_CHECK_VERSION(1, 2, 0)
> > +case VAProfileHEVCMain12:
> > +// Main 12
> > +ptl->general_max_12bit_constraint_flag = 1;
> > +ptl->general_max_10bit_constraint_flag = 0;
> > +ptl->general_max_8bit_constraint_flag = 0;
> > +ptl->general_max_422chroma_constraint_flag = 1;
> > +ptl->general_max_420chroma_constraint_flag = 1;
> > +ptl->general_max_monochrome_constraint_flag = 0;
> > +break;
> > +case VAProfileHEVCMain422_10:
> > +// Main 4:2:2 10
> > +ptl->general_max_12bit_constraint_flag = 1;
> > +ptl->general_max_10bit_constraint_flag = 1;
> > +ptl->general_max_8bit_constraint_flag = 0;
> > +ptl->general_max_422chroma_constraint_flag = 1;
> > +ptl->general_max_420chroma_constraint_flag = 0;
> > +ptl->general_max_monochrome_constraint_flag = 0;
> > +break;
> > +case VAProfileHEVCMain422_12:
> > +// Main 4:2:2 12
> > +ptl->general_max_12bit_constraint_flag = 1;
> > +ptl->general_max_10bit_constraint_flag = 0;
> > +ptl->general_max_8bit_constraint_flag = 0;
> > +ptl->general_max_422chroma_constraint_flag = 1;
> > +ptl->general_max_420chroma_constraint_flag = 0;
> > +ptl->general_max_monochrome_constraint_flag = 0;
> > +break;
> > +case VAProfileHEVCMain444:
> > +// Main 4:4:4
> > +ptl->general_max_12bit_constraint_flag = 1;
> > +ptl->general_max_10bit_constraint_flag = 1;
> > +ptl->general_max_8bit_constraint_flag = 1;
> > +ptl->general_max_422chroma_constraint_flag = 0;
> > +ptl->general_max_420chroma_constraint_flag = 0;
> > +ptl->general_max_monochrome_constraint_flag = 0;
> > +break;
> > +case VAProfileHEVCMain444_10:
> > +// Main 4:4:4 10
> > +ptl->general_max_12bit_constraint_flag = 1;
> > +ptl->general_max_10bit_constraint_flag = 1;
> > +ptl->general_max_8bit_constraint_flag = 0;
> > +ptl->general_max_422chroma_constraint_flag = 0;
> > +ptl->general_max_420chroma_constraint_flag = 0;
> > +ptl->general_max_monochrome_constraint_flag = 0;
> > +break;
> > +case VAProfileHEVCMain444_12:
> > +// Main 4:4:4 12
> > +ptl->general_max_12bit_constraint_flag = 1;
> > +ptl->general_max_10bit_constraint_flag = 0;
> > +ptl->general_max_8bit_constraint_flag = 0;
> > +ptl->general_max_422chroma_constraint_flag = 0;
> > +ptl->general_max_420chroma_constraint_flag =
Re: [FFmpeg-devel] [PATCH v3 1/2] lavc/vaapi_encode_h265: Map HEVC AV REXT profile to VA REXT profile
On Mon, 2024-03-18 at 21:11 +, Mark Thompson wrote:
> On 18/03/2024 04:21, fei.w.wang-at-intel@ffmpeg.org wrote:
> > From: Fei Wang
> >
> > There is no Main8/10 profile defined in HEVC REXT profiles. Use
> > Main12
> > which is compatible with 8/10bit.
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/vaapi_encode_h265.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode_h265.c
> > b/libavcodec/vaapi_encode_h265.c
> > index c4aabbf5ed..43755e2188 100644
> > --- a/libavcodec/vaapi_encode_h265.c
> > +++ b/libavcodec/vaapi_encode_h265.c
> > @@ -1305,12 +1305,12 @@ static av_cold int
> > vaapi_encode_h265_configure(AVCodecContext *avctx)
> >
> > static const VAAPIEncodeProfile vaapi_encode_h265_profiles[] = {
> > { AV_PROFILE_HEVC_MAIN, 8, 3, 1, 1,
> > VAProfileHEVCMain },
> > -{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 1,
> > VAProfileHEVCMain },
> > #if VA_CHECK_VERSION(0, 37, 0)
> > { AV_PROFILE_HEVC_MAIN_10, 10, 3, 1, 1,
> > VAProfileHEVCMain10 },
> > -{ AV_PROFILE_HEVC_REXT,10, 3, 1, 1,
> > VAProfileHEVCMain10 },
> > #endif
> > #if VA_CHECK_VERSION(1, 2, 0)
> > +{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 1, VAProfileHEVCMain12 },
> > +{ AV_PROFILE_HEVC_REXT,10, 3, 1, 1, VAProfileHEVCMain12 },
> > { AV_PROFILE_HEVC_REXT,12, 3, 1, 1, VAProfileHEVCMain12
> > },
> > { AV_PROFILE_HEVC_REXT, 8, 3, 1, 0,
> > VAProfileHEVCMain422_10 },
> > { AV_PROFILE_HEVC_REXT,10, 3, 1, 0,
> > VAProfileHEVCMain422_10 },
>
> What are you actually trying to do here?
>
> See 61aea246627787e80edd1f2eae01df63688dda68: these allow support for
> the Main Intra and Main 10 Intra profiles using Main and Main 10
> encoders respectively (since they need not use any additional rext
> features).
The hack blocks 420 8/10bit with inter frames to use REXT. Make them to
use VAProfileHEVCMain12 should be the best way, just like 422 8/10bit
all use VAProfileHEVCMain422_10.
Thanks
Fei
>
> Changing this to require a Main 12 encoder and marking the streams as
> requiring such a Main 12 decoder to decode when they don't does not
> seem helpful.
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] lavc/vaapi_encode_h265: Set general_*_constriaint flags with profile
On Fri, 2024-03-15 at 02:22 +, Xiang, Haihao wrote:
> On Vr, 2024-03-08 at 16:47 +0800, fei.w.wang-at-intel@ffmpeg.org
> wrote:
> > From: Fei Wang
> >
> > According to Table A.2 in spec.
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/vaapi_encode_h265.c | 181 +++
> > --
> > 1 file changed, 128 insertions(+), 53 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode_h265.c
> > b/libavcodec/vaapi_encode_h265.c
> > index 43755e2188..7c9916eac8 100644
> > --- a/libavcodec/vaapi_encode_h265.c
> > +++ b/libavcodec/vaapi_encode_h265.c
> > @@ -258,6 +258,129 @@ fail:
> > return err;
> > }
> >
> > +static int vaapi_encode_h265_init_ptl(AVCodecContext *avctx)
> > +{
> > +VAAPIEncodeContext *ctx = avctx->priv_data;
> > +VAAPIEncodeH265Context *priv = avctx->priv_data;
> > +H265RawVPS *vps = >raw_vps;
> > +H265RawProfileTierLevel *ptl = >profile_tier_level;
> > +
> > +ptl->general_profile_space = 0;
> > +ptl->general_profile_idc = avctx->profile;
> > +ptl->general_tier_flag = priv->tier;
> > +
> > +ptl->general_profile_compatibility_flag[ptl-
> > >general_profile_idc] = 1;
> > +
> > +if (ptl->general_profile_compatibility_flag[1])
> > +ptl->general_profile_compatibility_flag[2] = 1;
> > +if (ptl->general_profile_compatibility_flag[3]) {
> > +ptl->general_profile_compatibility_flag[1] = 1;
> > +ptl->general_profile_compatibility_flag[2] = 1;
> > +}
> > +
> > +ptl->general_progressive_source_flag= 1;
> > +ptl->general_interlaced_source_flag = 0;
> > +ptl->general_non_packed_constraint_flag = 1;
> > +ptl->general_frame_only_constraint_flag = 1;
> > +
> > +if (avctx->profile >= 4) {
> > +ptl->general_intra_constraint_flag= ctx-
> > >gop_size == 1;
> > +ptl->general_one_picture_only_constraint_flag = 0;
> > +ptl->general_lower_bit_rate_constraint_flag = 1;
> > +
> > +switch (ctx->va_profile) {
> > +#if VA_CHECK_VERSION(1, 2, 0)
> > +case VAProfileHEVCMain12:
> > +// Main 12
> > +ptl->general_max_14bit_constraint_flag = 0;
>
> There isn't a requirement about general_max_14bit_constraint_flag in
> Table A.2,
> it is unnecessary to set this flag here.
Fixed in V3. Thanks
Fei
>
> Thanks
> Haihao
>
> > +ptl->general_max_12bit_constraint_flag = 1;
> > +ptl->general_max_10bit_constraint_flag = 0;
> > +ptl->general_max_8bit_constraint_flag = 0;
> > +ptl->general_max_422chroma_constraint_flag = 1;
> > +ptl->general_max_420chroma_constraint_flag = 1;
> > +ptl->general_max_monochrome_constraint_flag = 0;
> > +break;
> > +case VAProfileHEVCMain422_10:
> > +// Main 4:2:2 10
> > +ptl->general_max_14bit_constraint_flag = 0;
> > +ptl->general_max_12bit_constraint_flag = 1;
> > +ptl->general_max_10bit_constraint_flag = 1;
> > +ptl->general_max_8bit_constraint_flag = 0;
> > +ptl->general_max_422chroma_constraint_flag = 1;
> > +ptl->general_max_420chroma_constraint_flag = 0;
> > +ptl->general_max_monochrome_constraint_flag = 0;
> > +break;
> > +case VAProfileHEVCMain422_12:
> > +// Main 4:2:2 12
> > +ptl->general_max_14bit_constraint_flag = 0;
> > +ptl->general_max_12bit_constraint_flag = 1;
> > +ptl->general_max_10bit_constraint_flag = 0;
> > +ptl->general_max_8bit_constraint_flag = 0;
> > +ptl->general_max_422chroma_constraint_flag = 1;
> > +ptl->general_max_420chroma_constraint_flag = 0;
> > +ptl->general_max_monochrome_constraint_flag = 0;
> > +break;
> > +case VAProfileHEVCMain444:
> > +// Main 4:4:4
> > +ptl->general_max_14bit_constraint_flag = 0;
> > +ptl->general_max_12bit_constraint_flag = 1;
> > +ptl->general_max_10bit_constraint_flag = 1;
> > +ptl->general_max_8bit_constraint_flag = 1;
> > +ptl->general_max_422chroma_constraint_flag = 0;
> > +ptl->general_max_420chroma_constraint_flag = 0;
> > +ptl->general_max_monochrome_constraint_flag = 0;
> > +break;
> > +case VAProfileHEVCMain444_10:
> > +// Main 4:4:4 10
> > +ptl->general_max_14bit_constraint_flag = 0;
> > +ptl->general_max_12bit_constraint_flag = 1;
> > +ptl->general_max_10bit_constraint_flag = 1;
> > +ptl->general_max_8bit_constraint_flag = 0;
> > +ptl->general_max_422chroma_constraint_flag = 0;
> > +ptl->general_max_420chroma_constraint_flag = 0;
> > +
Re: [FFmpeg-devel] [PATCH] lavc/vvc: AVERROR_PATCHWELCOME for subpictures
On Mon, 2024-03-11 at 21:57 -0300, James Almer wrote: > On 3/11/2024 9:49 PM, Michael Niedermayer wrote: > > On Mon, Mar 11, 2024 at 06:53:31PM +, Frank Plowman wrote: > > > VVC's subpictures feature is not yet implemented in the native > > > decoder. > > > Throw an AVERROR_PATCHWELCOME when trying to decode a bitstream > > > using > > > the feature. Fixes crashes when trying to decode bitstreams > > > which > > > use the feature. > > > > > > Signed-off-by: Frank Plowman > > > --- > > > libavcodec/vvc/vvc_ps.c | 15 +++ > > > 1 file changed, 15 insertions(+) > > > > This breaks fate-vvc-conformance-SUBPIC_A_3 > > > > make fate-vvc-conformance-SUBPIC_A_3 > > TESTvvc-conformance-SUBPIC_A_3 > > --- ./tests/ref/fate/vvc-conformance-SUBPIC_A_3 2024-03-05 > > 02:37:36.235300141 +0100 > > +++ tests/data/fate/vvc-conformance-SUBPIC_A_3 2024-03-12 > > 01:47:27.301593567 +0100 > > @@ -1,9 +0,0 @@ > > -#tb 0: 1/25 > > -#media_type 0: video > > -#codec_id 0: rawvideo > > -#dimensions 0: 1920x1080 > > -#sar 0: 0/1 > > -0, 0, 0,1, 6220800, 0xa419cfb6 > > -0, 1, 1,1, 6220800, 0xa419cfb6 > > -0, 2, 2,1, 6220800, 0xa419cfb6 > > -0, 3, 3,1, 6220800, 0xa419cfb6 > > Test vvc-conformance-SUBPIC_A_3 failed. Look at > > tests/data/fate/vvc-conformance-SUBPIC_A_3.err for details. > > tests/Makefile:318: recipe for target 'fate-vvc-conformance- > > SUBPIC_A_3' failed > > make: *** [fate-vvc-conformance-SUBPIC_A_3] Error 69 > > > > thx > > The sample appears to decode fine and doesn't crash, although all > four > frames are exactly the same (I don't know is that's intended). The result is correct. Assume native decode can handle subpic, at least a part of the feature. > Maybe the crashes can be fixed in some other form? And abort only if > FF_COMPLIANCE_STRICT is requested. Previous I made a patch to fix the crash in setup ps, but still get error in decoding slice, it's better to return AVERROR_PATCHWELCOME only in case of pps_single_slice_per_subpic_flag. https://github.com/intel-media-ci/ffmpeg/pull/723 Thanks Fei > ___ > ffmpeg-devel mailing list > ffmpeg-devel@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 v1 2/2] lavc/vvc_ps: Correct NoOutputBeforeRecoveryFlag of IDR
On Sat, 2024-03-09 at 19:59 +0800, Nuo Mi wrote:
Hi Fei,
Thank you fei,
Better provide more comments
Added in V2.
Is there any clip fail for this?
No, just notice the defect when I check why recovering frames been outputted in
GDR_D_ERICSSON_1.bit.
Thanks
Fei
On Fri, Mar 8, 2024 at 8:55 AM
mailto:fei.w.wang-at-intel@ffmpeg.org>>
wrote:
From: Fei Wang mailto:fei.w.w...@intel.com>>
Signed-off-by: Fei Wang mailto:fei.w.w...@intel.com>>
---
libavcodec/vvc/vvc_ps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
index e6e46d2039..7972803da6 100644
--- a/libavcodec/vvc/vvc_ps.c
+++ b/libavcodec/vvc/vvc_ps.c
@@ -742,7 +742,7 @@ static int decode_frame_ps(VVCFrameParamSets *fps, const
VVCParamSets *ps,
static void decode_recovery_flag(VVCContext *s)
{
if (IS_IDR(s))
-s->no_output_before_recovery_flag = 0;
+s->no_output_before_recovery_flag = 1;
else if (IS_CRA(s) || IS_GDR(s))
s->no_output_before_recovery_flag = s->last_eos;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@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 1/2] lavc/vvcdec: Add missed chroma sampling factor for crop offset
On Sat, 2024-03-09 at 19:57 +0800, Nuo Mi wrote: Thank you, Fei, Do you happen to know why the following clips are still failing? CROP_A_Panasonic_4.bit Ffmepg decode doesn't apply crop strictly. It will adjust crop for alignment, see av_frame_apply_cropping(). Thanks Fei CROP_B_Panasonic_4.bit https://github.com/ffvvc/tests/tree/main/conformance/failed/v1/CROP On Fri, Mar 8, 2024 at 8:54 AM mailto:fei.w.wang-at-intel@ffmpeg.org>> wrote: From: Fei Wang mailto:fei.w.w...@intel.com>> Signed-off-by: Fei Wang mailto:fei.w.w...@intel.com>> --- libavcodec/vvc/vvc_refs.c | 8 libavcodec/vvc/vvcdec.c | 4 ++-- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/libavcodec/vvc/vvc_refs.c b/libavcodec/vvc/vvc_refs.c index 99f2dcf3ec..afcfc09da7 100644 --- a/libavcodec/vvc/vvc_refs.c +++ b/libavcodec/vvc/vvc_refs.c @@ -185,10 +185,10 @@ int ff_vvc_set_new_ref(VVCContext *s, VVCFrameContext *fc, AVFrame **frame) ref->poc = poc; ref->sequence = s->seq_decode; -ref->frame->crop_left = fc->ps.pps->r->pps_conf_win_left_offset; -ref->frame->crop_right = fc->ps.pps->r->pps_conf_win_right_offset; -ref->frame->crop_top= fc->ps.pps->r->pps_conf_win_top_offset; -ref->frame->crop_bottom = fc->ps.pps->r->pps_conf_win_bottom_offset; +ref->frame->crop_left = fc->ps.pps->r->pps_conf_win_left_offset << fc->ps.sps->hshift[CHROMA]; +ref->frame->crop_right = fc->ps.pps->r->pps_conf_win_right_offset << fc->ps.sps->hshift[CHROMA]; +ref->frame->crop_top= fc->ps.pps->r->pps_conf_win_top_offset << fc->ps.sps->vshift[CHROMA]; +ref->frame->crop_bottom = fc->ps.pps->r->pps_conf_win_bottom_offset << fc->ps.sps->vshift[CHROMA]; return 0; } diff --git a/libavcodec/vvc/vvcdec.c b/libavcodec/vvc/vvcdec.c index 570e2aa513..a979ebd41c 100644 --- a/libavcodec/vvc/vvcdec.c +++ b/libavcodec/vvc/vvcdec.c @@ -727,8 +727,8 @@ static void export_frame_params(VVCContext *s, const VVCFrameContext *fc) c->pix_fmt = sps->pix_fmt; c->coded_width = pps->width; c->coded_height = pps->height; -c->width= pps->width - pps->r->pps_conf_win_left_offset - pps->r->pps_conf_win_right_offset; -c->height = pps->height - pps->r->pps_conf_win_top_offset - pps->r->pps_conf_win_bottom_offset; +c->width= pps->width - ((pps->r->pps_conf_win_left_offset + pps->r->pps_conf_win_right_offset) << sps->hshift[CHROMA]); +c->height = pps->height - ((pps->r->pps_conf_win_top_offset + pps->r->pps_conf_win_bottom_offset) << sps->vshift[CHROMA]); } static int frame_setup(VVCFrameContext *fc, VVCContext *s) ___ ffmpeg-devel mailing list ffmpeg-devel@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: Enable Macroblock based bitrate control
On Sun, 2024-02-25 at 19:15 +, Mark Thompson wrote:
> On 23/02/2024 07:14, fei.w.wang-at-intel@ffmpeg.org wrote:
> > From: Fei Wang
> >
> > Signed-off-by: Fei Wang
> > ---
> > update:
> > Print mbbrc status with "ON/OFF" instead of "0/1".
> >
> > doc/encoders.texi | 3 +++
> > libavcodec/vaapi_encode.c | 11 ++-
> > libavcodec/vaapi_encode.h | 9 -
> > 3 files changed, 21 insertions(+), 2 deletions(-)
>
> Can you explain what the option actually does? The current
> documentation doesn't really give any hint of whether a user would
> want it on or off.
>
> It also seems like this is a legacy name and maybe should have a more
> generic name to make sense - the iHD driver at least accepts the
> option for H.265 and VP9, neither of which have macroblocks.
How about BLBRC(Block level bitrate control)?
>
> > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > index 9f477d7c53..3f11a80039 100644
> > --- a/doc/encoders.texi
> > +++ b/doc/encoders.texi
> > @@ -4086,6 +4086,9 @@ Quality-defined variable-bitrate.
> > Average variable bitrate.
> > @end table
> >
> > +@item mbbrc
> > +Enable Macroblock based rate control. Invalid for CQP mode.
> > +
> > @end table
> >
> > Each encoder also has its own specific options:
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index 86f4110cd2..e4bf15fea0 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -1806,6 +1806,9 @@ static av_cold int
> > vaapi_encode_init_rate_control(AVCodecContext *avctx)
> > int i, first = 1, res;
> >
> > supported_va_rc_modes = rc_attr.value;
> > +if (ctx->mbbrc && !(supported_va_rc_modes & VA_RC_MB))
> > +ctx->mbbrc = 0;
>
> Probably not a good idea to silently disable what the user explicitly
> requested.
>
> > +
> > for (i = 0; i < FF_ARRAY_ELEMS(vaapi_encode_rc_modes);
> > i++) {
> > rc_mode = _encode_rc_modes[i];
> > if (supported_va_rc_modes & rc_mode->va_mode) {
> > @@ -2017,13 +2020,18 @@ rc_mode_found:
> > ctx->va_bit_rate = rc_bits_per_second;
> >
> > av_log(avctx, AV_LOG_VERBOSE, "RC mode: %s.\n", rc_mode-
> > >name);
> > +
> > +if (ctx->mbbrc && ctx->va_rc_mode == VA_RC_CQP)
> > +ctx->mbbrc = 0;
> > +av_log(avctx, AV_LOG_VERBOSE, "MB bitrate control: %s.\n",
> > ctx->mbbrc ? "ON" : "OFF");
> > +
> > if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> > // This driver does not want the RC mode attribute to be
> > set.
> > } else {
> > ctx->config_attributes[ctx->nb_config_attributes++] =
> > (VAConfigAttrib) {
> > .type = VAConfigAttribRateControl,
> > -.value = ctx->va_rc_mode,
> > +.value = ctx->mbbrc ? ctx->va_rc_mode | VA_RC_MB :
> > ctx->va_rc_mode,
> > };
> > }
> >
> > @@ -2052,6 +2060,7 @@ rc_mode_found:
> > #if VA_CHECK_VERSION(1, 1, 0)
> > .ICQ_quality_factor = av_clip(rc_quality, 1, 51),
> > .max_qp = (avctx->qmax > 0 ? avctx->qmax
> > : 0),
> > +.rc_flags.bits.mb_rate_control = ctx->mbbrc ? 1 : 2,
>
> What did the previous 0 "use default" do here?
0 means auto decide by driver. This feature may has impact on frame
psnr, so set it as off by default and expect user enable it explicitly.
Thanks
Fei
>
> > #endif
> > #if VA_CHECK_VERSION(1, 3, 0)
> > .quality_factor = rc_quality,
> > diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> > index 6964055b93..9774cc86b1 100644
> > --- a/libavcodec/vaapi_encode.h
> > +++ b/libavcodec/vaapi_encode.h
> > @@ -216,6 +216,9 @@ typedef struct VAAPIEncodeContext {
> > // available modes).
> > int explicit_rc_mode;
> >
> > +// Macroblock based rate control.
> > +int mbbrc;
> > +
> > // Explicitly-set QP, for use with the "qp" options.
> > // (Forces CQP mode when set, overriding everything else.)
> > int explicit_qp;
> > @@ -538,7 +541,11 @@ int ff_vaapi_encode_close(AVCodecContext
> > *avctx);
> > VAAPI_ENCODE_RC_MODE(VBR, "Variable-bitrate"), \
> > VAAPI_ENCODE_RC_MODE(ICQ, "Intelligent constant-quality"), \
> > VAAPI_ENCODE_RC_MODE(QVBR, "Quality-defined variable-
> > bitrate"), \
> > -VAAPI_ENCODE_RC_MODE(AVBR, "Average variable-bitrate")
> > +VAAPI_ENCODE_RC_MODE(AVBR, "Average variable-bitrate"), \
> > +{ "mbbrc", \
> > + "Macroblock based bitrate control",\
> > + OFFSET(common.mbbrc), AV_OPT_TYPE_BOOL, \
> > + { .i64 = 0 }, 0, 1, FLAGS }
> >
> >
> > #endif /* AVCODEC_VAAPI_ENCODE_H */
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
>
Re: [FFmpeg-devel] [PATCH v1] lavc/vaapi_encode: Enable Macroblock based bitrate control
On Fri, 2024-02-23 at 05:11 +, Xiang, Haihao wrote:
> On Wo, 2024-02-07 at 08:40 +0800, fei.w.wang-at-intel@ffmpeg.org
> wrote:
> > From: Fei Wang
> >
> > Signed-off-by: Fei Wang
> > ---
> > doc/encoders.texi | 3 +++
> > libavcodec/vaapi_encode.c | 11 ++-
> > libavcodec/vaapi_encode.h | 9 -
> > 3 files changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > index c9fe6d6143..b66d5da31f 100644
> > --- a/doc/encoders.texi
> > +++ b/doc/encoders.texi
> > @@ -4080,6 +4080,9 @@ Quality-defined variable-bitrate.
> > Average variable bitrate.
> > @end table
> >
> > +@item mbbrc
> > +Enable Macroblock based rate control. Invalid for CQP mode.
> > +
> > @end table
> >
> > Each encoder also has its own specific options:
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index 86f4110cd2..83eb881428 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -1806,6 +1806,9 @@ static av_cold int
> > vaapi_encode_init_rate_control(AVCodecContext *avctx)
> > int i, first = 1, res;
> >
> > supported_va_rc_modes = rc_attr.value;
> > +if (ctx->mbbrc && !(supported_va_rc_modes & VA_RC_MB))
> > +ctx->mbbrc = 0;
> > +
> > for (i = 0; i < FF_ARRAY_ELEMS(vaapi_encode_rc_modes);
> > i++) {
> > rc_mode = _encode_rc_modes[i];
> > if (supported_va_rc_modes & rc_mode->va_mode) {
> > @@ -2017,13 +2020,18 @@ rc_mode_found:
> > ctx->va_bit_rate = rc_bits_per_second;
> >
> > av_log(avctx, AV_LOG_VERBOSE, "RC mode: %s.\n", rc_mode-
> > >name);
> > +
> > +if (ctx->mbbrc && ctx->va_rc_mode == VA_RC_CQP)
> > +ctx->mbbrc = 0;
> > +av_log(avctx, AV_LOG_VERBOSE, "MB bitrate control: %d.\n",
> > ctx->mbbrc);
>
> Better to use a string representation of the boolean value, E.g.
> on/off, or
> enabled/disabled.
Fixed in V2.
Thanks
Fei
>
> Thanks
> Haihao
>
> > +
> > if (rc_attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> > // This driver does not want the RC mode attribute to be
> > set.
> > } else {
> > ctx->config_attributes[ctx->nb_config_attributes++] =
> > (VAConfigAttrib) {
> > .type = VAConfigAttribRateControl,
> > -.value = ctx->va_rc_mode,
> > +.value = ctx->mbbrc ? ctx->va_rc_mode | VA_RC_MB :
> > ctx-
> > > va_rc_mode,
> > };
> > }
> >
> > @@ -2052,6 +2060,7 @@ rc_mode_found:
> > #if VA_CHECK_VERSION(1, 1, 0)
> > .ICQ_quality_factor = av_clip(rc_quality, 1, 51),
> > .max_qp = (avctx->qmax > 0 ? avctx->qmax :
> > 0),
> > +.rc_flags.bits.mb_rate_control = ctx->mbbrc ? 1 : 2,
> > #endif
> > #if VA_CHECK_VERSION(1, 3, 0)
> > .quality_factor = rc_quality,
> > diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> > index d5d6d5eb1b..f2abfed459 100644
> > --- a/libavcodec/vaapi_encode.h
> > +++ b/libavcodec/vaapi_encode.h
> > @@ -216,6 +216,9 @@ typedef struct VAAPIEncodeContext {
> > // available modes).
> > int explicit_rc_mode;
> >
> > +// Macroblock based rate control.
> > +int mbbrc;
> > +
> > // Explicitly-set QP, for use with the "qp" options.
> > // (Forces CQP mode when set, overriding everything else.)
> > int explicit_qp;
> > @@ -538,7 +541,11 @@ int ff_vaapi_encode_close(AVCodecContext
> > *avctx);
> > VAAPI_ENCODE_RC_MODE(VBR, "Variable-bitrate"), \
> > VAAPI_ENCODE_RC_MODE(ICQ, "Intelligent constant-quality"), \
> > VAAPI_ENCODE_RC_MODE(QVBR, "Quality-defined variable-
> > bitrate"), \
> > -VAAPI_ENCODE_RC_MODE(AVBR, "Average variable-bitrate")
> > +VAAPI_ENCODE_RC_MODE(AVBR, "Average variable-bitrate"), \
> > +{ "mbbrc", \
> > + "Macroblock based bitrate control",\
> > + OFFSET(common.mbbrc), AV_OPT_TYPE_BOOL, \
> > + { .i64 = 0 }, 0, 1, FLAGS }
> >
> >
> > #endif /* AVCODEC_VAAPI_ENCODE_H */
___
ffmpeg-devel mailing list
ffmpeg-devel@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 1/2] avcodec/av1dec: Move message of OBU info back to the beginning
On Wed, 2023-12-27 at 05:35 +, Xiang, Haihao wrote:
> On Di, 2023-12-26 at 11:31 +0800, fei.w.wang-at-intel@ffmpeg.org
> wrote:
> > From: Fei Wang
> >
> > So that can show OBU info even it doesn't have decomposed content.
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/av1dec.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > index da05a0f039..e8041c1f58 100644
> > --- a/libavcodec/av1dec.c
> > +++ b/libavcodec/av1dec.c
> > @@ -1200,11 +1200,12 @@ static int
> > av1_receive_frame_internal(AVCodecContext
> > *avctx, AVFrame *frame)
> > AV1RawOBU *obu = unit->content;
> > const AV1RawOBUHeader *header;
> >
> > +av_log(avctx, AV_LOG_DEBUG, "Obu idx:%d, obu type:%d.\n",
> > i, unit-
> > > type);
>
> Could you add message to indicate the content of this unit is
> available or not ?
Added in V2.
Thanks
Fei
>
> Thanks
> Haihao
>
> > +
> > if (!obu)
> > continue;
> >
> > header = >header;
> > -av_log(avctx, AV_LOG_DEBUG, "Obu idx:%d, obu type:%d.\n",
> > i, unit-
> > > type);
> >
> > switch (unit->type) {
> > case AV1_OBU_SEQUENCE_HEADER:
___
ffmpeg-devel mailing list
ffmpeg-devel@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/av1dec: Add tile list OBU to decompose list
On Fri, 2023-12-22 at 08:41 +0100, Andreas Rheinhardt wrote:
> Wang, Fei W:
> > On Thu, 2023-12-21 at 20:14 +0100, Andreas Rheinhardt wrote:
> > > Wang, Fei W:
> > > > On Wed, 2023-12-20 at 17:11 +0100, Andreas Rheinhardt wrote:
> > > > > fei.w.wang-at-intel@ffmpeg.org:
> > > > > > From: Fei Wang
> > > > > >
> > > > > > Show the unsupported message and return unsupported for
> > > > > > clips
> > > > > > contain
> > > > > > tile list OBU since it hasn't been implemented. Otherwise,
> > > > > > decoding
> > > > > > maybe successful but result is incorrect.
> > > > > >
> > > > > > Signed-off-by: Fei Wang
> > > > > > ---
> > > > > > libavcodec/av1dec.c | 5 +
> > > > > > 1 file changed, 5 insertions(+)
> > > > > >
> > > > > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > > > > > index 4dcde234c6..629e37c3f8 100644
> > > > > > --- a/libavcodec/av1dec.c
> > > > > > +++ b/libavcodec/av1dec.c
> > > > > > @@ -805,6 +805,7 @@ static const CodedBitstreamUnitType
> > > > > > decompose_unit_types[] = {
> > > > > > AV1_OBU_SEQUENCE_HEADER,
> > > > > > AV1_OBU_TEMPORAL_DELIMITER,
> > > > > > AV1_OBU_TILE_GROUP,
> > > > > > +AV1_OBU_TILE_LIST,
> > > > >
> > > > > What do you need this for? Decomposing it would only change
> > > > > whether
> > > > > CodedBitstreamUnit.content is available, but you are only
> > > > > reading
> > > > > CodedBitstreamUnit.type.
> > > >
> > > > To show the unsupported error and let user know that there are
> > > > tile
> > > > list OBUs in bitstream that decoder can't handle them.
> > > > Otherwise,
> > > > like
> > > > my commit mentioned, tile list obu bitsteam may be decoded
> > > > 'successful'
> > > > according to log.
> > > >
> > >
> > > As I said: You do not need CodedBitstreamUnit.content for the
> > > error
> > > message.
> >
> > No, obu will be filtered if it is not listed in decompose, decoder
> > can't receive its type neither.
> >
>
> Did you test this? If so, this would be a violation of the
> documentation
> of decompose_unit_types: "Types not in this list will be available in
> bitstream form only." My reading of the code of
> cbs_read_fragment_content() in cbs.c is that it does what it is
> supposed
> to do.
I was misled by the incomplete log. Decoder can receive tile list OBU
bitstream. Fixed it together with another version. Sorry for the noise.
https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=10358
Thanks
Fei
>
> If you were right, it would also mean that the current case for
> AV1_OBU_TILE_LIST and AV1_OBU_PADDING is redundant (and that the
> default
> case will be used instead).
>
> - Andreas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@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/av1dec: Add tile list OBU to decompose list
On Thu, 2023-12-21 at 20:14 +0100, Andreas Rheinhardt wrote:
> Wang, Fei W:
> > On Wed, 2023-12-20 at 17:11 +0100, Andreas Rheinhardt wrote:
> > > fei.w.wang-at-intel@ffmpeg.org:
> > > > From: Fei Wang
> > > >
> > > > Show the unsupported message and return unsupported for clips
> > > > contain
> > > > tile list OBU since it hasn't been implemented. Otherwise,
> > > > decoding
> > > > maybe successful but result is incorrect.
> > > >
> > > > Signed-off-by: Fei Wang
> > > > ---
> > > > libavcodec/av1dec.c | 5 +
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > > > index 4dcde234c6..629e37c3f8 100644
> > > > --- a/libavcodec/av1dec.c
> > > > +++ b/libavcodec/av1dec.c
> > > > @@ -805,6 +805,7 @@ static const CodedBitstreamUnitType
> > > > decompose_unit_types[] = {
> > > > AV1_OBU_SEQUENCE_HEADER,
> > > > AV1_OBU_TEMPORAL_DELIMITER,
> > > > AV1_OBU_TILE_GROUP,
> > > > +AV1_OBU_TILE_LIST,
> > >
> > > What do you need this for? Decomposing it would only change
> > > whether
> > > CodedBitstreamUnit.content is available, but you are only reading
> > > CodedBitstreamUnit.type.
> >
> > To show the unsupported error and let user know that there are tile
> > list OBUs in bitstream that decoder can't handle them. Otherwise,
> > like
> > my commit mentioned, tile list obu bitsteam may be decoded
> > 'successful'
> > according to log.
> >
>
> As I said: You do not need CodedBitstreamUnit.content for the error
> message.
No, obu will be filtered if it is not listed in decompose, decoder
can't receive its type neither.
Thanks
Fei
>
> > > > };
> > > >
> > > > static av_cold int av1_decode_init(AVCodecContext *avctx)
> > > > @@ -1327,6 +1328,10 @@ static int
> > > > av1_receive_frame_internal(AVCodecContext *avctx, AVFrame
> > > > *frame)
> > > > }
> > > > break;
> > > > case AV1_OBU_TILE_LIST:
> > > > +av_log(avctx, AV_LOG_ERROR, "Large scale tile
> > > > decoding
> > > > is unsupported.\n");
> > > > +ret = AVERROR_PATCHWELCOME;
> > > > +goto end;
> > > > +break;
> > > > case AV1_OBU_TEMPORAL_DELIMITER:
> > > > case AV1_OBU_PADDING:
> > > > break;
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avcodec/av1dec: Add tile list OBU to decompose list
On Wed, 2023-12-20 at 17:11 +0100, Andreas Rheinhardt wrote:
> fei.w.wang-at-intel@ffmpeg.org:
> > From: Fei Wang
> >
> > Show the unsupported message and return unsupported for clips
> > contain
> > tile list OBU since it hasn't been implemented. Otherwise, decoding
> > maybe successful but result is incorrect.
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/av1dec.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > index 4dcde234c6..629e37c3f8 100644
> > --- a/libavcodec/av1dec.c
> > +++ b/libavcodec/av1dec.c
> > @@ -805,6 +805,7 @@ static const CodedBitstreamUnitType
> > decompose_unit_types[] = {
> > AV1_OBU_SEQUENCE_HEADER,
> > AV1_OBU_TEMPORAL_DELIMITER,
> > AV1_OBU_TILE_GROUP,
> > +AV1_OBU_TILE_LIST,
>
> What do you need this for? Decomposing it would only change whether
> CodedBitstreamUnit.content is available, but you are only reading
> CodedBitstreamUnit.type.
To show the unsupported error and let user know that there are tile
list OBUs in bitstream that decoder can't handle them. Otherwise, like
my commit mentioned, tile list obu bitsteam may be decoded 'successful'
according to log.
>
> > };
> >
> > static av_cold int av1_decode_init(AVCodecContext *avctx)
> > @@ -1327,6 +1328,10 @@ static int
> > av1_receive_frame_internal(AVCodecContext *avctx, AVFrame *frame)
> > }
> > break;
> > case AV1_OBU_TILE_LIST:
> > +av_log(avctx, AV_LOG_ERROR, "Large scale tile decoding
> > is unsupported.\n");
> > +ret = AVERROR_PATCHWELCOME;
> > +goto end;
> > +break;
> > case AV1_OBU_TEMPORAL_DELIMITER:
> > case AV1_OBU_PADDING:
> > break;
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 v1] lavc/vaapi_encode_av1: Add qp option explicitly to set base q index
On Tue, 2023-11-28 at 03:15 +, Xiang, Haihao wrote:
> On Ma, 2023-11-27 at 13:36 +, Mark Thompson wrote:
> > On 27/11/2023 00:58, fei.w.wang-at-intel@ffmpeg.org wrote:
> > > From: Fei Wang
> > >
> > > Keep same way with librav1e/libsvtav1/qsv_av1.. to make it more
> > > acceptable instead of using global option "-global_quality".
> > >
> > > Fix #10615
> > >
> > > Signed-off-by: Fei Wang
> > > ---
> > > doc/encoders.texi | 1 +
> > > libavcodec/vaapi_encode_av1.c | 6 ++
> > > 2 files changed, 7 insertions(+)
> > >
> > > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > > index 27a9acf076..2cffc32daf 100644
> > > --- a/doc/encoders.texi
> > > +++ b/doc/encoders.texi
> > > @@ -4079,6 +4079,7 @@ Each encoder also has its own specific
> > > options:
> > > @table @option
> > >
> > > @item av1_vaapi
> > > +@option{qp} sets the value of @emph{base_q_index}.
> > > @option{profile} sets the value of @emph{seq_profile}.
> > > @option{tier} sets the value of @emph{seq_tier}.
> > > @option{level} sets the value of @emph{seq_level_idx}.
> > > diff --git a/libavcodec/vaapi_encode_av1.c
> > > b/libavcodec/vaapi_encode_av1.c
> > > index 5a9ff0f798..2e327fec5a 100644
> > > --- a/libavcodec/vaapi_encode_av1.c
> > > +++ b/libavcodec/vaapi_encode_av1.c
> > > @@ -79,6 +79,7 @@ typedef struct VAAPIEncodeAV1Context {
> > > int cdef_param_size;
> > >
> > > /** user options */
> > > +int qp;
> > > int profile;
> > > int level;
> > > int tier;
> > > @@ -786,6 +787,9 @@ static av_cold int
> > > vaapi_encode_av1_init(AVCodecContext
> > > *avctx)
> > > return AVERROR(EINVAL);
> > > }
> > >
> > > +if (priv->qp > 0)
> > > +ctx->explicit_qp = priv->qp;
> > > +
> > > ret = ff_vaapi_encode_init(avctx);
> > > if (ret < 0)
> > > return ret;
> > > @@ -864,6 +868,8 @@ static av_cold int
> > > vaapi_encode_av1_close(AVCodecContext
> > > *avctx)
> > > static const AVOption vaapi_encode_av1_options[] = {
> > > VAAPI_ENCODE_COMMON_OPTIONS,
> > > VAAPI_ENCODE_RC_OPTIONS,
> > > +{ "qp", "Base q index (for P-frames; scaled by
> > > qfactor/qoffset for
> > > I/B)",
> > > + OFFSET(qp), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 255, FLAGS
> > > },
> > > { "profile", "Set profile (seq_profile)",
> > > OFFSET(profile), AV_OPT_TYPE_INT,
> > > { .i64 = AV_PROFILE_UNKNOWN }, AV_PROFILE_UNKNOWN, 0xff,
> > > FLAGS,
> > > "profile" },
> >
> > Disagree; QP is not a concept in AV1.
>
> Yes, it not a concept in AV1.
>
> nvenc h264/hevc/av1 encoders provide the same qp option:
>
> libavcodec/nvenc_av1.c:{ "qp", "Constant quantization
> parameter
> rate control method",
> libavcodec/nvenc_h264.c:{ "qp", "Constant quantization
> parameter
> rate control method",
> libavcodec/nvenc_hevc.c:{ "qp", "Constant quantization
> parameter
> rate control method",
>
> May we provide the same qp option for vaapi h264/hevc/av1 encoders
> too? User
> will be able to use same options when using these encoders.
>
> Thanks
> Haihao
>
>
> > Further, your examples from other encoders do not have a
> > consistent view of
> > what it should mean.
We may also assign different meaning for different VAAPI encoder in its
individual option description. And it may be more reasonable to use
"-qp" together with "-rc_mode CQP" and "-i/b_qfactor/qoffset" options.
Thanks
Fei
> >
> > librav1e.c:
> >
> > { "qp", "use constant quantizer mode", OFFSET(quantizer),
> > AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 255, VE },
> >
> > 0-255 is presumably the base_q_idx scale.
> >
> > libsvtav1.c:
> >
> > { "qp", "Initial Quantizer level value", OFFSET(qp),
> > AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 63, VE },
> >
> > 0-63 is presumably the H.26x-qp-ish scale used by some VP9/AV1
> > encoders which
> > maps nonlinearly to the internal scale.
> >
> > qsv_av1 doesn't seem to have such an option.
> >
> > Thanks,
> >
> > - Mark
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@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] cbs_av1: Make fake OBU size length field a write option
On Tue, 2023-09-26 at 21:30 +0100, Mark Thompson wrote:
> This is an option to modify the behaviour of the writer, not a syntax
> field.
> ---
> On 26/09/2023 03:34, Wang, Fei W wrote:
> > On Mon, 2023-09-25 at 14:53 +0100, Mark Thompson wrote:
> > > ...
> > > diff --git a/libavcodec/vaapi_encode_av1.c
> > > b/libavcodec/vaapi_encode_av1.c
> > > index 3ff1c47b53..861bf4a13b 100644
> > > --- a/libavcodec/vaapi_encode_av1.c
> > > +++ b/libavcodec/vaapi_encode_av1.c
> > > @@ -133,6 +133,9 @@ static av_cold int
> > > vaapi_encode_av1_configure(AVCodecContext *avctx)
> > >priv->cbc->trace_context = ctx;
> > >priv->cbc->trace_write_callback =
> > > vaapi_encode_av1_trace_write_log;
> > >
> > > +av_opt_set_int(priv->cbc->priv_data,
> > > "fixed_obu_size_length",
> > > + priv->attr_ext2.bits.obu_size_bytes_minus1 +
> > > 1,
> > > 0);
> > > +
> >
> > This should be put after querying priv.attr_ext2 in
> > vaapi_encode_av1_init().
>
> Ah, true - I got my init and configure mixed up, but don't have
> convenient hardware to test. Fixed in this version.
LGTM for this version.
Thanks
Fei
>
> Thanks,
>
> - Mark
>
> libavcodec/cbs_av1.c | 31 +--
> libavcodec/cbs_av1.h | 5 -
> libavcodec/vaapi_encode_av1.c | 4 +++-
> 3 files changed, 28 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
> index 4e687ace79..ed9a7b80d4 100644
> --- a/libavcodec/cbs_av1.c
> +++ b/libavcodec/cbs_av1.c
> @@ -138,19 +138,25 @@ static int
> cbs_av1_read_leb128(CodedBitstreamContext *ctx, GetBitContext *gbc,
> return 0;
> }
>
> -/** Minimum byte length will be used to indicate the len128 of value
> if byte_len is 0. */
> static int cbs_av1_write_leb128(CodedBitstreamContext *ctx,
> PutBitContext *pbc,
> -const char *name, uint64_t value,
> uint8_t byte_len)
> +const char *name, uint64_t value,
> int fixed_length)
> {
> int len, i;
> uint8_t byte;
>
> CBS_TRACE_WRITE_START();
>
> -if (byte_len)
> -av_assert0(byte_len >= (av_log2(value) + 7) / 7);
> +len = (av_log2(value) + 7) / 7;
>
> -len = byte_len ? byte_len : (av_log2(value) + 7) / 7;
> +if (fixed_length) {
> +if (fixed_length < len) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR, "OBU is too large for
> "
> + "fixed length size field (%d > %d).\n",
> + len, fixed_length);
> +return AVERROR(EINVAL);
> +}
> +len = fixed_length;
> +}
>
> for (i = 0; i < len; i++) {
> if (put_bits_left(pbc) < 8)
> @@ -1006,8 +1012,8 @@ static int
> cbs_av1_write_obu(CodedBitstreamContext *ctx,
>
> if (obu->header.obu_has_size_field) {
> pbc_tmp = *pbc;
> -if (obu->obu_size_byte_len) {
> -for (int i = 0; i < obu->obu_size_byte_len; i++)
> +if (priv->fixed_obu_size_length) {
> +for (int i = 0; i < priv->fixed_obu_size_length; i++)
> put_bits(pbc, 8, 0);
> } else {
> // Add space for the size field to fill later.
> @@ -1133,7 +1139,8 @@ static int
> cbs_av1_write_obu(CodedBitstreamContext *ctx,
> end_pos /= 8;
>
> *pbc = pbc_tmp;
> -err = cbs_av1_write_leb128(ctx, pbc, "obu_size", obu->obu_size,
> obu->obu_size_byte_len);
> +err = cbs_av1_write_leb128(ctx, pbc, "obu_size", obu->obu_size,
> + priv->fixed_obu_size_length);
> if (err < 0)
> goto error;
>
> @@ -1150,10 +1157,12 @@ static int
> cbs_av1_write_obu(CodedBitstreamContext *ctx,
> }
>
> if (obu->obu_size > 0) {
> -if (!obu->obu_size_byte_len) {
> -obu->obu_size_byte_len = start_pos - data_pos;
> +if (!priv->fixed_obu_size_length) {
> memmove(pbc->buf + data_pos,
> pbc->buf + start_pos, header_size);
> +} else {
> +// The size was fixed so the following data was
> +// already written in the correct place.
> }
> skip_put_bytes(pbc, header_size);
>
> @@ -1273,6 +1282,8 @@ static const CodedBitstreamUnitTypeDescriptor
> cbs_av1_unit_types[] = {
> static const AVOption cbs_av1_opti
Re: [FFmpeg-devel] [PATCH] cbs_av1: Make fake OBU size length field a write option
On Mon, 2023-09-25 at 14:53 +0100, Mark Thompson wrote:
> This is an option to modify the behaviour of the writer, not a syntax
> field.
> ---
> Tested by hacking av1_metadata. For example, adding:
>
> av_opt_set_int(ctx->common.output->priv_data,
> "fixed_obu_size_length", 7, 0);
>
> gets you OBU headers that look like:
>
> [trace_headers @ 0x55706fcb2880] OBU header
> [trace_headers @ 0x55706fcb2880]
> 0 obu_forbidden_bit
>0 = 0
> [trace_headers @ 0x55706fcb2880]
> 1 obu_type
> 0100 = 4
> [trace_headers @ 0x55706fcb2880]
> 5 obu_extension_flag
>0 = 0
> [trace_headers @ 0x55706fcb2880]
> 6 obu_has_size_field
>1 = 1
> [trace_headers @ 0x55706fcb2880]
> 7 obu_reserved_1bit
>0 = 0
> [trace_headers @ 0x55706fcb2880]
> 8 obu_size 1010111010001010100010001000100
> 0 = 1326
>
> It's not obvious that there is any value in exposing this option more
> generally, though? It could made a visible option of av1_metadata or
> others if there is any use-case for it.
>
> Thanks,
>
> - Mark
>
>
> libavcodec/cbs_av1.c | 31 +--
> libavcodec/cbs_av1.h | 5 -
> libavcodec/vaapi_encode_av1.c | 4 +++-
> 3 files changed, 28 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
> index 4e687ace79..ed9a7b80d4 100644
> --- a/libavcodec/cbs_av1.c
> +++ b/libavcodec/cbs_av1.c
> @@ -138,19 +138,25 @@ static int
> cbs_av1_read_leb128(CodedBitstreamContext *ctx, GetBitContext *gbc,
> return 0;
> }
>
> -/** Minimum byte length will be used to indicate the len128 of value
> if byte_len is 0. */
> static int cbs_av1_write_leb128(CodedBitstreamContext *ctx,
> PutBitContext *pbc,
> -const char *name, uint64_t value,
> uint8_t byte_len)
> +const char *name, uint64_t value,
> int fixed_length)
> {
> int len, i;
> uint8_t byte;
>
> CBS_TRACE_WRITE_START();
>
> -if (byte_len)
> -av_assert0(byte_len >= (av_log2(value) + 7) / 7);
> +len = (av_log2(value) + 7) / 7;
>
> -len = byte_len ? byte_len : (av_log2(value) + 7) / 7;
> +if (fixed_length) {
> +if (fixed_length < len) {
> +av_log(ctx->log_ctx, AV_LOG_ERROR, "OBU is too large for
> "
> + "fixed length size field (%d > %d).\n",
> + len, fixed_length);
> +return AVERROR(EINVAL);
> +}
> +len = fixed_length;
> +}
>
> for (i = 0; i < len; i++) {
> if (put_bits_left(pbc) < 8)
> @@ -1006,8 +1012,8 @@ static int
> cbs_av1_write_obu(CodedBitstreamContext *ctx,
>
> if (obu->header.obu_has_size_field) {
> pbc_tmp = *pbc;
> -if (obu->obu_size_byte_len) {
> -for (int i = 0; i < obu->obu_size_byte_len; i++)
> +if (priv->fixed_obu_size_length) {
> +for (int i = 0; i < priv->fixed_obu_size_length; i++)
> put_bits(pbc, 8, 0);
> } else {
> // Add space for the size field to fill later.
> @@ -1133,7 +1139,8 @@ static int
> cbs_av1_write_obu(CodedBitstreamContext *ctx,
> end_pos /= 8;
>
> *pbc = pbc_tmp;
> -err = cbs_av1_write_leb128(ctx, pbc, "obu_size", obu->obu_size,
> obu->obu_size_byte_len);
> +err = cbs_av1_write_leb128(ctx, pbc, "obu_size", obu->obu_size,
> + priv->fixed_obu_size_length);
> if (err < 0)
> goto error;
>
> @@ -1150,10 +1157,12 @@ static int
> cbs_av1_write_obu(CodedBitstreamContext *ctx,
> }
>
> if (obu->obu_size > 0) {
> -if (!obu->obu_size_byte_len) {
> -obu->obu_size_byte_len = start_pos - data_pos;
> +if (!priv->fixed_obu_size_length) {
> memmove(pbc->buf + data_pos,
> pbc->buf + start_pos, header_size);
> +} else {
> +// The size was fixed so the following data was
> +// already written in the correct place.
> }
> skip_put_bytes(pbc, header_size);
>
> @@ -1273,6 +1282,8 @@ static const CodedBitstreamUnitTypeDescriptor
> cbs_av1_unit_types[] = {
> static const AVOption cbs_av1_options[] = {
> { "operating_point", "Set operating point to select layers to
> parse from a scalable bitstream",
> OFFSET(operating_point), AV_OPT_TYPE_INT,
> { .i64 = -1 }, -1, AV1_MAX_OPERATING_POINTS - 1, 0 },
> +{ "fixed_obu_size_length", "Set fixed length of the obu_size
> field",
> + OFFSET(fixed_obu_size_length), AV_OPT_TYPE_INT, { .i64 = 0 },
> 0, 8, 0 },
> { NULL }
> };
>
> diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
Re: [FFmpeg-devel] [PATCH v4 7/8] lavc/vaapi_encode: Add VAAPI AV1 encoder
On Thu, 2023-08-31 at 15:21 +0800, fei.w.w...@intel.com wrote: > From: Fei Wang > > Signed-off-by: Fei Wang > --- > Fixed the discussions in V3. @Mark, any more comment on this version? Thanks > > Changelog | 1 + > configure | 3 + > doc/encoders.texi | 14 + > libavcodec/Makefile | 2 + > libavcodec/allcodecs.c| 1 + > libavcodec/av1_levels.c | 92 > libavcodec/av1_levels.h | 58 +++ > libavcodec/vaapi_encode.c | 198 +-- > libavcodec/vaapi_encode.h | 24 + > libavcodec/vaapi_encode_av1.c | 949 > ++ > libavcodec/version.h | 2 +- > 11 files changed, 1311 insertions(+), 33 deletions(-) > create mode 100644 libavcodec/av1_levels.c > create mode 100644 libavcodec/av1_levels.h > create mode 100644 libavcodec/vaapi_encode_av1.c ___ ffmpeg-devel mailing list ffmpeg-devel@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 6/6] lavc/vaapi_encode: Add VAAPI AV1 encoder
On Sun, 2023-08-13 at 22:43 +0100, Mark Thompson wrote:
> On 10/08/2023 03:54, Wang, Fei W wrote:
> > On Mon, 2023-08-07 at 22:21 +0100, Mark Thompson wrote:
> > > On 03/08/2023 07:01, fei.w.wang-at-intel@ffmpeg.org wrote:
> > > > From: Fei Wang
> > > >
> > > > Signed-off-by: Fei Wang
> > > > ---
> > > >Changelog |1 +
> > > >configure |3 +
> > > >doc/encoders.texi | 13 +
> > > >libavcodec/Makefile |1 +
> > > >libavcodec/allcodecs.c|1 +
> > > >libavcodec/vaapi_encode.c | 125 +++-
> > > >libavcodec/vaapi_encode.h | 12 +
> > > >libavcodec/vaapi_encode_av1.c | 1229
> > > > +
> > > >libavcodec/version.h |2 +-
> > > >9 files changed, 1368 insertions(+), 19 deletions(-)
> > > >create mode 100644 libavcodec/vaapi_encode_av1.c
> > >
> > > I assume this is tested on Intel hardware. Is it tested on AMD
> > > as
> > > well? (Apparently working in recent Mesa.)
> >
> > AMD tested the patchset months ago:
> > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22585
> >
> > This patch changed a little compare with the version in Cartwheel,
> > @Ruijing, Could you help to review this version in ML? To avoid the
> > diffs break you. Thanks.
> >
> > > > ...
> > > > @@ -669,6 +669,15 @@ static int
> > > > vaapi_encode_set_output_timestamp(AVCodecContext *avctx,
> > > >{
> > > >VAAPIEncodeContext *ctx = avctx->priv_data;
> > > >
> > > > +// AV1 packs P frame and next B frame into one pkt, and
> > > > uses
> > > > the other
> > > > +// repeat frame header pkt at the display order position
> > > > of
> > > > the P frame
> > > > +// to indicate its frame index. Each frame has a
> > > > corresponding
> > > > pkt in its
> > > > +// display order position. So don't need to consider delay
> > > > for
> > > > AV1 timestamp.
> > > > +if (avctx->codec_id == AV_CODEC_ID_AV1) {
> > > > +pkt->dts = pkt->pts - ctx->dts_pts_diff;
> > > > +return 0;
> > > > +}
> > >
> > > This doesn't get you the right result, though? The PTS and DTS
> > > on
> > > every AV1 packet want to be the same.
> >
> > The result tested good which can be played normally. Just aligned
> > with
> > other vaapi encoders that the 1st frame start with 0/-1 of PTS/DTS
> > if
> > have B frame. Set PTS/DTS to same also looks good.
>
> DTS != PTS should only be true when the stream has externally-visible
> frame reordering in, which AV1 doesn't.
>
> The other two AV1 encoders both output DTS == PTS; I think you should
> match that.
>
> > > In any case, please don't put tests for codec ID in the common
> > > code. I suggest that the timestamp behaviour wants to be a new
> > > FLAG_*.
> > >
> > > > +
> > > > ...
> > > > @@ -1128,9 +1182,19 @@ static int
> > > > vaapi_encode_pick_next(AVCodecContext *avctx,
> > > >
> > > >vaapi_encode_add_ref(avctx, pic, pic, 0, 1, 0);
> > > >if (pic->type != PICTURE_TYPE_IDR) {
> > > > -vaapi_encode_add_ref(avctx, pic, start,
> > > > - pic->type == PICTURE_TYPE_P,
> > > > - b_counter > 0, 0);
> > > > +// TODO: apply both previous and forward multi
> > > > reference
> > > > for all vaapi encoders.
> > > > +// And L0/L1 reference frame number can be set
> > > > dynamically
> > > > through query
> > > > +// VAConfigAttribEncMaxRefFrames attribute.
> > > > +if (avctx->codec_id == AV_CODEC_ID_AV1) {
> > > > +for (i = 0; i < ctx->nb_next_prev; i++)
> > > > +vaapi_encode_add_ref(avctx, pic, ctx-
> > > > > next_prev[i],
> > > > + pic->type ==
> > > > PICTURE_TYPE_P,
> > > > + b_counter > 0, 0);
> > >
> > > So an undisclosed aim of the previous patch was to
Re: [FFmpeg-devel] [PATCH v3 6/6] lavc/vaapi_encode: Add VAAPI AV1 encoder
On Mon, 2023-08-07 at 22:21 +0100, Mark Thompson wrote:
> On 03/08/2023 07:01, fei.w.wang-at-intel@ffmpeg.org wrote:
> > From: Fei Wang
> >
> > Signed-off-by: Fei Wang
> > ---
> > Changelog |1 +
> > configure |3 +
> > doc/encoders.texi | 13 +
> > libavcodec/Makefile |1 +
> > libavcodec/allcodecs.c|1 +
> > libavcodec/vaapi_encode.c | 125 +++-
> > libavcodec/vaapi_encode.h | 12 +
> > libavcodec/vaapi_encode_av1.c | 1229
> > +
> > libavcodec/version.h |2 +-
> > 9 files changed, 1368 insertions(+), 19 deletions(-)
> > create mode 100644 libavcodec/vaapi_encode_av1.c
>
> I assume this is tested on Intel hardware. Is it tested on AMD as
> well? (Apparently working in recent Mesa.)
AMD tested the patchset months ago:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22585
This patch changed a little compare with the version in Cartwheel,
@Ruijing, Could you help to review this version in ML? To avoid the
diffs break you. Thanks.
>
>
> > diff --git a/Changelog b/Changelog
> > index bbda4f4fd4..e86f742cd3 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -27,6 +27,7 @@ version :
> > - Bitstream filter for converting VVC from MP4 to Annex B
> > - scale_vt filter for videotoolbox
> > - transpose_vt filter for videotoolbox
> > +- VAAPI AV1 encoder
> >
> > version 6.0:
> > - Radiance HDR image support
> > diff --git a/configure b/configure
> > index 99388e7664..68a238a819 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3322,6 +3322,8 @@ av1_qsv_decoder_select="qsvdec"
> > av1_qsv_encoder_select="qsvenc"
> > av1_qsv_encoder_deps="libvpl"
> > av1_amf_encoder_deps="amf"
> > +av1_vaapi_encoder_deps="VAEncPictureParameterBufferAV1"
> > +av1_vaapi_encoder_select="cbs_av1 vaapi_encode"
> >
> > # parsers
> > aac_parser_select="adts_header mpeg4audio"
> > @@ -7106,6 +7108,7 @@ if enabled vaapi; then
> > check_type "va/va.h va/va_enc_jpeg.h"
> > "VAEncPictureParameterBufferJPEG"
> > check_type "va/va.h
> > va/va_enc_vp8.h" "VAEncPictureParameterBufferVP8"
> > check_type "va/va.h
> > va/va_enc_vp9.h" "VAEncPictureParameterBufferVP9"
> > +check_type "va/va.h
> > va/va_enc_av1.h" "VAEncPictureParameterBufferAV1"
> > fi
> >
> > if enabled_all opencl libdrm ; then
> > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > index 25d6b7f09e..fb331ebd8e 100644
> > --- a/doc/encoders.texi
> > +++ b/doc/encoders.texi
> > @@ -3991,6 +3991,19 @@ Average variable bitrate.
> > Each encoder also has its own specific options:
> > @table @option
> >
> > +@item av1_vaapi
> > +@option{profile} sets the value of @emph{seq_profile}.
> > +@option{tier} sets the value of @emph{seq_tier}.
> > +@option{level} sets the value of @emph{seq_level_idx}.
> > +
> > +@table @option
> > +@item tiles
> > +Set the number of tiles to encode the input video with, as columns
> > x rows.
> > +(default is 1x1).
>
> Probably needs some clarification that large resolutions must be
> split into tiles? Maybe an "auto" value for this (meaning use as few
> as possible), and let explicit "1x1" fail if the resolution is too
> large.
>
> > +@item tile_groups
> > +Set tile groups number (default is 1).
>
> Meaning what? It splits into tile group OBUs containing equal
> numbers of tiles, or of equal size in bits, or something else?
>
> > +@end table
> > +
> > @item h264_vaapi
> > @option{profile} sets the value of @emph{profile_idc} and the
> > @emph{constraint_set*_flag}s.
> > @option{level} sets the value of @emph{level_idc}.
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index a6b2ecbb22..473afb4471 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -258,6 +258,7 @@ OBJS-$(CONFIG_AV1_MEDIACODEC_DECODER) +=
> > mediacodecdec.o
> > OBJS-$(CONFIG_AV1_MEDIACODEC_ENCODER) += mediacodecenc.o
> > OBJS-$(CONFIG_AV1_NVENC_ENCODER) += nvenc_av1.o nvenc.o
> > OBJS-$(CONFIG_AV1_QSV_ENCODER) += qsvenc_av1.o
> > +OBJS-$(CONFIG_AV1_VAAPI_ENCODER) += vaapi_encode_av1.o
> > av1_levels.o
> > OBJS-$(CONFIG_AVRN_DECODER)+= avrndec.o
> > OBJS-$(CONFIG_AVRP_DECODER)+= r210dec.o
> > OBJS-$(CONFIG_AVRP_ENCODER)+= r210enc.o
> > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > index 8775d15a4f..c43c1d7b48 100644
> > --- a/libavcodec/allcodecs.c
> > +++ b/libavcodec/allcodecs.c
> > @@ -844,6 +844,7 @@ extern const FFCodec ff_av1_nvenc_encoder;
> > extern const FFCodec ff_av1_qsv_decoder;
> > extern const FFCodec ff_av1_qsv_encoder;
> > extern const FFCodec ff_av1_amf_encoder;
> > +extern const FFCodec ff_av1_vaapi_encoder;
> > extern const FFCodec ff_libopenh264_encoder;
> > extern const FFCodec ff_libopenh264_decoder;
> > extern const FFCodec ff_h264_amf_encoder;
> > diff --git
Re: [FFmpeg-devel] [PATCH v2 6/6] lavc/vaapi_encode: Add VAAPI AV1 encoder
On Mon, 2023-07-31 at 22:51 +0100, Neal Gompa wrote:
> On Mon, Jul 31, 2023 at 9:04 PM Neal Gompa
> wrote:
> > On Tue, Jul 18, 2023 at 4:13 AM Fei Wang
> > wrote:
> > > Signed-off-by: Fei Wang
> > > ---
> > > update
> > > 1. set color_range in sequence header.
> > >
> > > Changelog |1 +
> > > configure |3 +
> > > doc/encoders.texi | 13 +
> > > libavcodec/Makefile |1 +
> > > libavcodec/allcodecs.c|1 +
> > > libavcodec/vaapi_encode.c | 125 +++-
> > > libavcodec/vaapi_encode.h | 12 +
> > > libavcodec/vaapi_encode_av1.c | 1229
> > > +
> > > 8 files changed, 1367 insertions(+), 18 deletions(-)
> > > create mode 100644 libavcodec/vaapi_encode_av1.c
> > >
> > > diff --git a/Changelog b/Changelog
> > > index 3876082844..7ae9b85d52 100644
> > > --- a/Changelog
> > > +++ b/Changelog
> > > @@ -25,6 +25,7 @@ version :
> > > - Raw VVC bitstream parser, muxer and demuxer
> > > - Bitstream filter for editing metadata in VVC streams
> > > - Bitstream filter for converting VVC from MP4 to Annex B
> > > +- VAAPI AV1 encoder
> > >
> > > version 6.0:
> > > - Radiance HDR image support
> > > diff --git a/configure b/configure
> > > index b018abf139..fbc729b5c6 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -3323,6 +3323,8 @@ av1_qsv_decoder_select="qsvdec"
> > > av1_qsv_encoder_select="qsvenc"
> > > av1_qsv_encoder_deps="libvpl"
> > > av1_amf_encoder_deps="amf"
> > > +av1_vaapi_encoder_deps="VAEncPictureParameterBufferAV1"
> > > +av1_vaapi_encoder_select="cbs_av1 vaapi_encode"
> > >
> > > # parsers
> > > aac_parser_select="adts_header mpeg4audio"
> > > @@ -7104,6 +7106,7 @@ if enabled vaapi; then
> > > check_type "va/va.h va/va_enc_jpeg.h"
> > > "VAEncPictureParameterBufferJPEG"
> > > check_type "va/va.h
> > > va/va_enc_vp8.h" "VAEncPictureParameterBufferVP8"
> > > check_type "va/va.h
> > > va/va_enc_vp9.h" "VAEncPictureParameterBufferVP9"
> > > +check_type "va/va.h
> > > va/va_enc_av1.h" "VAEncPictureParameterBufferAV1"
> > > fi
> > >
> > > if enabled_all opencl libdrm ; then
> > > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > > index 25d6b7f09e..fb331ebd8e 100644
> > > --- a/doc/encoders.texi
> > > +++ b/doc/encoders.texi
> > > @@ -3991,6 +3991,19 @@ Average variable bitrate.
> > > Each encoder also has its own specific options:
> > > @table @option
> > >
> > > +@item av1_vaapi
> > > +@option{profile} sets the value of @emph{seq_profile}.
> > > +@option{tier} sets the value of @emph{seq_tier}.
> > > +@option{level} sets the value of @emph{seq_level_idx}.
> > > +
> > > +@table @option
> > > +@item tiles
> > > +Set the number of tiles to encode the input video with, as
> > > columns x rows.
> > > +(default is 1x1).
> > > +@item tile_groups
> > > +Set tile groups number (default is 1).
> > > +@end table
> > > +
> > > @item h264_vaapi
> > > @option{profile} sets the value of @emph{profile_idc} and the
> > > @emph{constraint_set*_flag}s.
> > > @option{level} sets the value of @emph{level_idc}.
> > > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > > index 3cd5997e64..fe1e6aa99d 100644
> > > --- a/libavcodec/Makefile
> > > +++ b/libavcodec/Makefile
> > > @@ -259,6 +259,7 @@ OBJS-$(CONFIG_AV1_MEDIACODEC_DECODER) +=
> > > mediacodecdec.o
> > > OBJS-$(CONFIG_AV1_MEDIACODEC_ENCODER) += mediacodecenc.o
> > > OBJS-$(CONFIG_AV1_NVENC_ENCODER) += nvenc_av1.o nvenc.o
> > > OBJS-$(CONFIG_AV1_QSV_ENCODER) += qsvenc_av1.o
> > > +OBJS-$(CONFIG_AV1_VAAPI_ENCODER) += vaapi_encode_av1.o
> > > av1_profile_level.o
> > > OBJS-$(CONFIG_AVRN_DECODER)+= avrndec.o
> > > OBJS-$(CONFIG_AVRP_DECODER)+= r210dec.o
> > > OBJS-$(CONFIG_AVRP_ENCODER)+= r210enc.o
> > > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > > index 8775d15a4f..c43c1d7b48 100644
> > > --- a/libavcodec/allcodecs.c
> > > +++ b/libavcodec/allcodecs.c
> > > @@ -844,6 +844,7 @@ extern const FFCodec ff_av1_nvenc_encoder;
> > > extern const FFCodec ff_av1_qsv_decoder;
> > > extern const FFCodec ff_av1_qsv_encoder;
> > > extern const FFCodec ff_av1_amf_encoder;
> > > +extern const FFCodec ff_av1_vaapi_encoder;
> > > extern const FFCodec ff_libopenh264_encoder;
> > > extern const FFCodec ff_libopenh264_decoder;
> > > extern const FFCodec ff_h264_amf_encoder;
> > > diff --git a/libavcodec/vaapi_encode.c
> > > b/libavcodec/vaapi_encode.c
> > > index 2604f12b9e..2907e159fb 100644
> > > --- a/libavcodec/vaapi_encode.c
> > > +++ b/libavcodec/vaapi_encode.c
> > > @@ -669,6 +669,15 @@ static int
> > > vaapi_encode_set_output_timestamp(AVCodecContext *avctx,
> > > {
> > > VAAPIEncodeContext *ctx = avctx->priv_data;
> > >
> > > +// AV1 packs P frame and next B frame into one pkt, and uses
> > > the other
> > > +// repeat frame header pkt at the display order position of
> > > the P frame
Re: [FFmpeg-devel] [PATCH v1 6/6] lavc/vaapi_encode: Add VAAPI AV1 encoder
On Mon, 2023-07-17 at 13:12 +0200, David Rosca wrote:
> On Mon, Jul 10, 2023 at 9:40 AM Fei Wang
> wrote:
> > Signed-off-by: Fei Wang
> > ---
> > Changelog |1 +
> > configure |3 +
> > doc/encoders.texi | 13 +
> > libavcodec/Makefile |1 +
> > libavcodec/allcodecs.c|1 +
> > libavcodec/vaapi_encode.c | 125 +++-
> > libavcodec/vaapi_encode.h | 12 +
> > libavcodec/vaapi_encode_av1.c | 1228
> > +
> > 8 files changed, 1366 insertions(+), 18 deletions(-)
> > create mode 100644 libavcodec/vaapi_encode_av1.c
> >
> > diff --git a/Changelog b/Changelog
> > index 3876082844..7ae9b85d52 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -25,6 +25,7 @@ version :
> > - Raw VVC bitstream parser, muxer and demuxer
> > - Bitstream filter for editing metadata in VVC streams
> > - Bitstream filter for converting VVC from MP4 to Annex B
> > +- VAAPI AV1 encoder
> >
> > version 6.0:
> > - Radiance HDR image support
> > diff --git a/configure b/configure
> > index 0ab0761011..6a1a30aaec 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3323,6 +3323,8 @@ av1_qsv_decoder_select="qsvdec"
> > av1_qsv_encoder_select="qsvenc"
> > av1_qsv_encoder_deps="libvpl"
> > av1_amf_encoder_deps="amf"
> > +av1_vaapi_encoder_deps="VAEncPictureParameterBufferAV1"
> > +av1_vaapi_encoder_select="cbs_av1 vaapi_encode"
> >
> > # parsers
> > aac_parser_select="adts_header mpeg4audio"
> > @@ -7106,6 +7108,7 @@ if enabled vaapi; then
> > check_type "va/va.h va/va_enc_jpeg.h"
> > "VAEncPictureParameterBufferJPEG"
> > check_type "va/va.h
> > va/va_enc_vp8.h" "VAEncPictureParameterBufferVP8"
> > check_type "va/va.h
> > va/va_enc_vp9.h" "VAEncPictureParameterBufferVP9"
> > +check_type "va/va.h
> > va/va_enc_av1.h" "VAEncPictureParameterBufferAV1"
> > fi
> >
> > if enabled_all opencl libdrm ; then
> > diff --git a/doc/encoders.texi b/doc/encoders.texi
> > index 25d6b7f09e..fb331ebd8e 100644
> > --- a/doc/encoders.texi
> > +++ b/doc/encoders.texi
> > @@ -3991,6 +3991,19 @@ Average variable bitrate.
> > Each encoder also has its own specific options:
> > @table @option
> >
> > +@item av1_vaapi
> > +@option{profile} sets the value of @emph{seq_profile}.
> > +@option{tier} sets the value of @emph{seq_tier}.
> > +@option{level} sets the value of @emph{seq_level_idx}.
> > +
> > +@table @option
> > +@item tiles
> > +Set the number of tiles to encode the input video with, as columns
> > x rows.
> > +(default is 1x1).
> > +@item tile_groups
> > +Set tile groups number (default is 1).
> > +@end table
> > +
> > @item h264_vaapi
> > @option{profile} sets the value of @emph{profile_idc} and the
> > @emph{constraint_set*_flag}s.
> > @option{level} sets the value of @emph{level_idc}.
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index 3cd5997e64..fe1e6aa99d 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -259,6 +259,7 @@ OBJS-$(CONFIG_AV1_MEDIACODEC_DECODER) +=
> > mediacodecdec.o
> > OBJS-$(CONFIG_AV1_MEDIACODEC_ENCODER) += mediacodecenc.o
> > OBJS-$(CONFIG_AV1_NVENC_ENCODER) += nvenc_av1.o nvenc.o
> > OBJS-$(CONFIG_AV1_QSV_ENCODER) += qsvenc_av1.o
> > +OBJS-$(CONFIG_AV1_VAAPI_ENCODER) += vaapi_encode_av1.o
> > av1_profile_level.o
> > OBJS-$(CONFIG_AVRN_DECODER)+= avrndec.o
> > OBJS-$(CONFIG_AVRP_DECODER)+= r210dec.o
> > OBJS-$(CONFIG_AVRP_ENCODER)+= r210enc.o
> > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > index 8775d15a4f..c43c1d7b48 100644
> > --- a/libavcodec/allcodecs.c
> > +++ b/libavcodec/allcodecs.c
> > @@ -844,6 +844,7 @@ extern const FFCodec ff_av1_nvenc_encoder;
> > extern const FFCodec ff_av1_qsv_decoder;
> > extern const FFCodec ff_av1_qsv_encoder;
> > extern const FFCodec ff_av1_amf_encoder;
> > +extern const FFCodec ff_av1_vaapi_encoder;
> > extern const FFCodec ff_libopenh264_encoder;
> > extern const FFCodec ff_libopenh264_decoder;
> > extern const FFCodec ff_h264_amf_encoder;
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index 2604f12b9e..2907e159fb 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -669,6 +669,15 @@ static int
> > vaapi_encode_set_output_timestamp(AVCodecContext *avctx,
> > {
> > VAAPIEncodeContext *ctx = avctx->priv_data;
> >
> > +// AV1 packs P frame and next B frame into one pkt, and uses
> > the other
> > +// repeat frame header pkt at the display order position of
> > the P frame
> > +// to indicate its frame index. Each frame has a corresponding
> > pkt in its
> > +// display order position. So don't need to consider delay for
> > AV1 timestamp.
> > +if (avctx->codec_id == AV_CODEC_ID_AV1) {
> > +pkt->dts = pkt->pts - ctx->dts_pts_diff;
> > +return 0;
> > +}
> > +
> > if (ctx->output_delay == 0)
Re: [FFmpeg-devel] [PATCH v1] fftools/ffmpeg_dec: Don't keep sending frame to filters in flushing
On Mon, 2023-06-26 at 05:01 +, Xiang, Haihao wrote: > On So, 2023-06-25 at 06:20 +, Xiang, Haihao wrote: > > On Ma, 2023-06-12 at 11:33 +0800, Fei Wang wrote: > > > Filter may has a limited frame pool size. Do not always send > > > frame to > > > filters without reaping. > > > > > > Fix the regression of commit 5fa00b38e6. > > > > > > Example cmd: > > > $ ffmpeg -threads 20 -init_hw_device > > > vaapi=hw:/dev/dri/renderD128 \ > > > -hwaccel_output_format vaapi -hwaccel vaapi -i > > > avc_1080P.mp4\ > > > -vf 'scale_vaapi=w=720:h=480' -f null - > > > > > > Signed-off-by: Fei Wang > > > --- > > > fftools/ffmpeg_dec.c | 6 ++ > > > 1 file changed, 6 insertions(+) > > > > > > diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c > > > index 799be63215..d6b34402f8 100644 > > > --- a/fftools/ffmpeg_dec.c > > > +++ b/fftools/ffmpeg_dec.c > > > @@ -531,6 +531,12 @@ int dec_packet(InputStream *ist, const > > > AVPacket *pkt, > > > int > > > no_eof) > > > av_frame_unref(frame); > > > if (ret < 0) > > > exit_program(1); > > > + > > > +// During flushing, break out to reap filter once send a > > > frame to > > > filters to > > > +// avoid drain out filter's output frame pool. > > > Especially for HW > > > filters which > > > +// always have a limited frame pool size. > > > +if (!pkt) > > > +return 0; > > > > Looks good and it works well for me. I'm going to push it if no > > objection > > > > There is a conflict when applying your patch to the latest FFmpeg, > could you > rebase the patch ? Rebased with V2. Thanks Fei > > Thanks > Haihao > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 3/3] lavfi/{denoise, procamp, scale, sharpness}_vaapi: Add passthrough mode
On Tue, 2023-06-13 at 16:17 +, Eoff, Ullysses A wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Fei Wang
> > Sent: Monday, May 29, 2023 8:30 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] [PATCH v1 3/3] lavfi/{denoise, procamp,
> > scale, sharpness}_vaapi: Add passthrough mode
> > @@ -188,11 +194,14 @@ static av_cold int
> > denoise_vaapi_init(AVFilterContext *avctx)
> > static av_cold int sharpness_vaapi_init(AVFilterContext *avctx)
> > {
> > VAAPIVPPContext *vpp_ctx = avctx->priv;
> > +SharpnessVAAPIContext *ctx = avctx->priv;
> >
> > ff_vaapi_vpp_ctx_init(avctx);
> > vpp_ctx->pipeline_uninit = ff_vaapi_vpp_pipeline_uninit;
> > vpp_ctx->build_filter_params =
> > sharpness_vaapi_build_filter_params;
> > vpp_ctx->output_format = AV_PIX_FMT_NONE;
> > +if (!ctx->sharpness)
> > +vpp_ctx->passthrough = 1;
>
> [UAE] It should be passthrough for the default
> value. SHARPNESS_DEFAULT = 44
Will fix in V2.
Thanks
Fei
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 v1 3/3] lavfi/{denoise, procamp, scale, sharpness}_vaapi: Add passthrough mode
On Mon, 2023-06-12 at 07:25 +, Xiang, Haihao wrote:
> On Di, 2023-05-30 at 08:29 +0800, Fei Wang wrote:
> > Signed-off-by: Fei Wang
> > ---
> > libavfilter/vaapi_vpp.c| 15 ---
> > libavfilter/vaapi_vpp.h| 2 ++
> > libavfilter/vf_misc_vaapi.c| 9 +
> > libavfilter/vf_procamp_vaapi.c | 10 ++
> > libavfilter/vf_scale_vaapi.c | 9 +
> > 5 files changed, 42 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
> > index 4de19564e9..cf2592e068 100644
> > --- a/libavfilter/vaapi_vpp.c
> > +++ b/libavfilter/vaapi_vpp.c
> > @@ -95,6 +95,7 @@ int ff_vaapi_vpp_config_input(AVFilterLink
> > *inlink)
> > int ff_vaapi_vpp_config_output(AVFilterLink *outlink)
> > {
> > AVFilterContext *avctx = outlink->src;
> > +AVFilterLink *inlink = avctx->inputs[0];
> > VAAPIVPPContext *ctx = avctx->priv;
> > AVVAAPIHWConfig *hwconfig = NULL;
> > AVHWFramesConstraints *constraints = NULL;
> > @@ -111,6 +112,17 @@ int ff_vaapi_vpp_config_output(AVFilterLink
> > *outlink)
> > if (!ctx->output_height)
> > ctx->output_height = avctx->inputs[0]->h;
> >
> > +outlink->w = ctx->output_width;
> > +outlink->h = ctx->output_height;
> > +
> > +if (ctx->passthrough) {
> > +if (inlink->hw_frames_ctx)
> > +outlink->hw_frames_ctx = av_buffer_ref(inlink-
> > >hw_frames_ctx);
> > +av_log(ctx, AV_LOG_VERBOSE, "Using VAAPI filter
> > passthrough
> > mode.\n");
> > +
> > +return 0;
> > +}
> > +
> > av_assert0(ctx->input_frames);
> > ctx->device_ref = av_buffer_ref(ctx->input_frames-
> > >device_ref);
> > if (!ctx->device_ref) {
> > @@ -214,9 +226,6 @@ int ff_vaapi_vpp_config_output(AVFilterLink
> > *outlink)
> > return AVERROR(EIO);
> > }
> >
> > -outlink->w = ctx->output_width;
> > -outlink->h = ctx->output_height;
> > -
> > if (ctx->build_filter_params) {
> > err = ctx->build_filter_params(avctx);
> > if (err < 0)
> > diff --git a/libavfilter/vaapi_vpp.h b/libavfilter/vaapi_vpp.h
> > index cc845b854c..6764ab0c39 100644
> > --- a/libavfilter/vaapi_vpp.h
> > +++ b/libavfilter/vaapi_vpp.h
> > @@ -56,6 +56,8 @@ typedef struct VAAPIVPPContext {
> > VABufferID filter_buffers[VAProcFilterCount];
> > intnb_filter_buffers;
> >
> > +int passthrough;
> > +
> > int (*build_filter_params)(AVFilterContext *avctx);
> >
> > void (*pipeline_uninit)(AVFilterContext *avctx);
> > diff --git a/libavfilter/vf_misc_vaapi.c
> > b/libavfilter/vf_misc_vaapi.c
> > index db3e69679a..0a4c174ab9 100644
> > --- a/libavfilter/vf_misc_vaapi.c
> > +++ b/libavfilter/vf_misc_vaapi.c
> > @@ -131,6 +131,9 @@ static int misc_vaapi_filter_frame(AVFilterLink
> > *inlink,
> > AVFrame *input_frame)
> > av_get_pix_fmt_name(input_frame->format),
> > input_frame->width, input_frame->height, input_frame-
> > >pts);
> >
> > +if (vpp_ctx->passthrough)
> > +return ff_filter_frame(outlink, input_frame);
> > +
> > if (vpp_ctx->va_context == VA_INVALID_ID)
> > return AVERROR(EINVAL);
> >
> > @@ -176,11 +179,14 @@ fail:
> > static av_cold int denoise_vaapi_init(AVFilterContext *avctx)
> > {
> > VAAPIVPPContext *vpp_ctx = avctx->priv;
> > +DenoiseVAAPIContext *ctx = avctx->priv;
> >
> > ff_vaapi_vpp_ctx_init(avctx);
> > vpp_ctx->pipeline_uninit = ff_vaapi_vpp_pipeline_uninit;
> > vpp_ctx->build_filter_params =
> > denoise_vaapi_build_filter_params;
> > vpp_ctx->output_format = AV_PIX_FMT_NONE;
> > +if (!ctx->denoise)
> > +vpp_ctx->passthrough = 1;
> >
> > return 0;
> > }
> > @@ -188,11 +194,14 @@ static av_cold int
> > denoise_vaapi_init(AVFilterContext
> > *avctx)
> > static av_cold int sharpness_vaapi_init(AVFilterContext *avctx)
> > {
> > VAAPIVPPContext *vpp_ctx = avctx->priv;
> > +SharpnessVAAPIContext *ctx = avctx->priv;
> >
> > ff_vaapi_vpp_ctx_init(avctx);
> > vpp_ctx->pipeline_uninit = ff_vaapi_vpp_pipeline_uninit;
> > vpp_ctx->build_filter_params =
> > sharpness_vaapi_build_filter_params;
> > vpp_ctx->output_format = AV_PIX_FMT_NONE;
> > +if (!ctx->sharpness)
> > +vpp_ctx->passthrough = 1;
> >
> > return 0;
> > }
> > diff --git a/libavfilter/vf_procamp_vaapi.c
> > b/libavfilter/vf_procamp_vaapi.c
> > index 4a3b9d0766..82c446dc76 100644
> > --- a/libavfilter/vf_procamp_vaapi.c
> > +++ b/libavfilter/vf_procamp_vaapi.c
> > @@ -136,6 +136,9 @@ static int
> > procamp_vaapi_filter_frame(AVFilterLink
> > *inlink, AVFrame *input_frame
> > av_get_pix_fmt_name(input_frame->format),
> > input_frame->width, input_frame->height, input_frame-
> > >pts);
> >
> > +if (vpp_ctx->passthrough)
> > +return ff_filter_frame(outlink, input_frame);
> > +
> > if
Re: [FFmpeg-devel] [PATCH 22/36] fftools/ffmpeg: drop an obsolete hack
On Wed, 2023-05-17 at 12:20 +0200, Anton Khirnov wrote: > This special handling for decoder flushing has not been needed since > af1761f7b5, as the filtergraph actually is drained after that commit. > --- > fftools/ffmpeg.c | 11 --- > 1 file changed, 11 deletions(-) > > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c > index 9d554e2fb0..49313edebc 100644 > --- a/fftools/ffmpeg.c > +++ b/fftools/ffmpeg.c > @@ -1418,17 +1418,6 @@ static int process_input_packet(InputStream > *ist, const AVPacket *pkt, int no_eo > if (!got_output) > break; > > -// During draining, we might get multiple output frames in > this loop. > -// ffmpeg.c does not drain the filter chain on configuration > changes, > -// which means if we send multiple frames at once to the > filters, and > -// one of those frames changes configuration, the buffered > frames will > -// be lost. This can upset certain FATE tests. > -// Decode only 1 frame per call on EOF to appease these FATE > tests. > -// The ideal solution would be to rewrite decoding to use > the new > -// decoding API in a better way. > -if (!pkt) > -break; > - Hi, This will drain out HW filter's output frames if it uses fixed number which is less than frame threads of decoder. Decoded frame keep sending to filter in flushing while filtered frames can't be reaped. An example cmd: ffmpeg -threads 20 -v verbose -init_hw_device vaapi=hw:/dev/dri/renderD128 -hwaccel_output_format vaapi -hwaccel vaapi -i avc.mp4 -vf 'scale_va api=w=720:h=480' -f null - ... Error while filtering: Cannot allocate memory Failed to inject frame into filter network: Cannot allocate memory Error while processing the decoded data for stream #0:0 Thanks > repeating = 1; > } > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 01/10] lavc/avcodec: Add HEVC Screen Content Coding Extensions profile
On Tue, 2023-02-14 at 11:11 +0100, Anton Khirnov wrote:
> Quoting Fei Wang (2023-02-06 06:44:49)
> > From: Linjie Fu
> >
> > Described in HEVC spec A.3.7.
> >
> > Signed-off-by: Linjie Fu
> > Signed-off-by: Fei Wang
> > ---
> > 1. fix compile warning with VAAPI version less than 1.2.0
> >
> > libavcodec/avcodec.h | 1 +
> > libavcodec/hevc_ps.c | 2 ++
> > libavcodec/profiles.c | 1 +
> > 3 files changed, 4 insertions(+)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 90b437ccbe..9e36d2402a 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -1672,6 +1672,7 @@ typedef struct AVCodecContext {
> > #define FF_PROFILE_HEVC_MAIN_10 2
> > #define FF_PROFILE_HEVC_MAIN_STILL_PICTURE 3
> > #define FF_PROFILE_HEVC_REXT4
> > +#define FF_PROFILE_HEVC_SCC 9
>
> This is an API addition and so needs a minor bump and an entry in
> APIchanges
Fixed in V6. Thanks.
Fei
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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 08/11] lavc/vaapi_hevc: Pass SCC parameters Through VA-API
> -Original Message-
> From: Wang, Fei W
> Sent: Tuesday, January 3, 2023 9:00 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Linjie Fu ; Linjie Fu ;
> Wang,
> Fei W
> Subject: [FFmpeg-devel][PATCH v3 08/11] lavc/vaapi_hevc: Pass SCC parameters
> Through VA-API
>
> From: Linjie Fu
>
> Including sps/pps/slice parameters.
>
> Signed-off-by: Linjie Fu
> Signed-off-by: Fei Wang
> ---
> libavcodec/vaapi_hevc.c | 52 +
> 1 file changed, 47 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c index
> 20fb36adfa..73a8f5b4ce 100644
> --- a/libavcodec/vaapi_hevc.c
> +++ b/libavcodec/vaapi_hevc.c
> @@ -124,7 +124,7 @@ static int vaapi_hevc_start_frame(AVCodecContext
> *avctx,
> const HEVCPPS *pps = h->ps.pps;
>
> const ScalingList *scaling_list = NULL;
> -int pic_param_size, err, i;
> +int pic_param_size, num_comps, pre_palette_size, err, i;
>
> VAPictureParameterBufferHEVC *pic_param =
> (VAPictureParameterBufferHEVC *)>pic_param;
>
> @@ -245,8 +245,46 @@ static int vaapi_hevc_start_frame(AVCodecContext
> *avctx,
> for (i = 0; i < 6; i++)
> pic->pic_param.rext.cr_qp_offset_list[i]=
> pps->cr_qp_offset_list[i];
> }
> +
> +pre_palette_size = pps->pps_palette_predictor_initializers_present_flag ?
> + pps->pps_num_palette_predictor_initializers :
> + (sps->sps_palette_predictor_initializers_present_flag
> ?
> + sps->sps_num_palette_predictor_initializers_minus1 +
> 1 :
> + 0);
> +
> +if (avctx->profile == FF_PROFILE_HEVC_SCC) {
> +pic->pic_param.scc = (VAPictureParameterBufferHEVCScc) {
> +.screen_content_pic_fields.bits = {
> +.pps_curr_pic_ref_enabled_flag = pps-
> >pps_curr_pic_ref_enabled_flag,
> +.palette_mode_enabled_flag = sps-
> >palette_mode_enabled_flag,
> +.motion_vector_resolution_control_idc = sps-
> >motion_vector_resolution_control_idc,
> +.intra_boundary_filtering_disabled_flag = sps-
> >intra_boundary_filtering_disabled_flag,
> +.residual_adaptive_colour_transform_enabled_flag
> += pps-
> >residual_adaptive_colour_transform_enabled_flag,
> +.pps_slice_act_qp_offsets_present_flag = pps-
> >pps_slice_act_qp_offsets_present_flag,
> +},
> +.palette_max_size =
> sps->palette_max_size,
> +.delta_palette_max_predictor_size = sps-
> >delta_palette_max_predictor_size,
> +.predictor_palette_size =
> pre_palette_size,
> +.pps_act_y_qp_offset_plus5 = pps-
> >residual_adaptive_colour_transform_enabled_flag ?
> +
> pps->pps_act_y_qp_offset + 5 : 0,
> +.pps_act_cb_qp_offset_plus5 = pps-
> >residual_adaptive_colour_transform_enabled_flag ?
> +
> pps->pps_act_cb_qp_offset + 5 : 0,
> +.pps_act_cr_qp_offset_plus3 = pps-
> >residual_adaptive_colour_transform_enabled_flag ?
> +
> pps->pps_act_cr_qp_offset + 3 : 0,
> +};
> +
> +num_comps = pps->monochrome_palette_flag ? 1 : 3;
> +for (int comp = 0; comp < num_comps; comp++)
> +for (int j = 0; j < pre_palette_size; j++)
> +pic->pic_param.scc.predictor_palette_entries[comp][j] =
> +pps->pps_palette_predictor_initializers_present_flag ?
> +pps->pps_palette_predictor_initializer[comp][j]:
> +sps->sps_palette_predictor_initializer[comp][j];
> +}
> +
> #endif
> -pic_param_size = avctx->profile == FF_PROFILE_HEVC_REXT ?
> +pic_param_size = avctx->profile >= FF_PROFILE_HEVC_REXT ?
> sizeof(pic->pic_param) :
> sizeof(VAPictureParameterBufferHEVC);
>
> err = ff_vaapi_decode_make_param_buffer(avctx, >pic, @@ -299,7
> +337,7 @@ static int vaapi_hevc_end_frame(AVCodecContext *avctx)
> VASliceParameterBufferHEVC *last_slice_param =
> (VASliceParameterBufferHEVC *)>last_slice_param;
> int ret;
>
> -int slice_pa
Re: [FFmpeg-devel] [PATCH v3 10/11] lavc/vaapi_hevc: Set correct rps type for scc
> -Original Message-
> From: Wang, Fei W
> Sent: Tuesday, January 3, 2023 9:00 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Linjie Fu ; Linjie Fu ;
> Wang,
> Fei W
> Subject: [FFmpeg-devel][PATCH v3 10/11] lavc/vaapi_hevc: Set correct rps type
> for scc
>
> From: Linjie Fu
>
> According to 8.1.3 and 8.3.2.
>
> Signed-off-by: Linjie Fu
> Signed-off-by: Fei Wang
> ---
> libavcodec/vaapi_hevc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c index
> c10617a81a..29c75e88f0 100644
> --- a/libavcodec/vaapi_hevc.c
> +++ b/libavcodec/vaapi_hevc.c
> @@ -71,6 +71,7 @@ static void fill_vaapi_pic(VAPictureHEVC *va_pic, const
> HEVCFrame *pic, int rps_ static int find_frame_rps_type(const HEVCContext *h,
> const HEVCFrame *pic) {
> VASurfaceID pic_surf = ff_vaapi_get_surface_id(pic->frame);
> +const HEVCFrame *current_picture = h->ref;
> int i;
>
> for (i = 0; i < h->rps[ST_CURR_BEF].nb_refs; i++) { @@ -88,6 +89,9 @@
> static
> int find_frame_rps_type(const HEVCContext *h, const HEVCFrame *pic)
> return VA_PICTURE_HEVC_RPS_LT_CURR;
> }
>
> +if (h->ps.pps->pps_curr_pic_ref_enabled_flag && current_picture->poc ==
> pic->poc)
> +return VA_PICTURE_HEVC_LONG_TERM_REFERENCE;
> +
FATE test report fail in patchwork:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230103125952.2707824-10-fei.w.w...@intel.com/
make: *** [fate-hevc-conformance-PS_A_VIDYO_3] Error 1
cpu_flags(raw) = 0x000813DB
cpu_flags_str(raw) = mmx mmxext sse sse2 sse3 ssse3 sse4.1 sse4.2 cmov aesni
cpu_flags(effective) = 0x000813DB
cpu_flags_str(effective) = mmx mmxext sse sse2 sse3 ssse3 sse4.1 sse4.2 cmov
aesni
threads = 1 (cpu_count = 5)
make: Target 'fate' not remade because of errors.
Checked locally, no this problem. The patch only change vaapi hevc decoder,
should not cause the FATE fail(Only native decoder will be used in FATE?).
Assume wrong report in patchwork.
Thanks
Fei
> return 0;
> }
>
> --
> 2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 09/13] lavc/vaapi_hevc: Add vaapi profile parse support for SCC
On Tue, 2023-01-03 at 07:08 +, Xiang, Haihao wrote:
> On Ma, 2022-12-05 at 14:09 +0800, Fei Wang wrote:
> > From: Linjie Fu
> >
> > Note that Screen-Extended Main 4:4:4 and 4:4:4 10 supports
> > chroma_format_idc from 0, 1 or 3, hence both 420 and 444 are
> > supported.
> >
> > Signed-off-by: Linjie Fu
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/vaapi_decode.c | 4 +++-
> > libavcodec/vaapi_hevc.c | 14 --
> > libavcodec/vaapi_hevc.h | 2 +-
> > 3 files changed, 16 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index 134f10eca5..29ac439b36 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -410,7 +410,9 @@ static const struct {
> > #endif
> > #if VA_CHECK_VERSION(1, 2, 0) && CONFIG_HEVC_VAAPI_HWACCEL
> > MAP(HEVC,HEVC_REXT, None,
> > - ff_vaapi_parse_hevc_rext_profile ),
> > + ff_vaapi_parse_hevc_profile ),
> > +MAP(HEVC,HEVC_SCC,None,
> > + ff_vaapi_parse_hevc_profile ),
> > #endif
> > MAP(MJPEG, MJPEG_HUFFMAN_BASELINE_DCT,
> >JPEGBaseline),
> > diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
> > index 750738d36e..6ce1e17fa8 100644
> > --- a/libavcodec/vaapi_hevc.c
> > +++ b/libavcodec/vaapi_hevc.c
> > @@ -586,9 +586,9 @@ static int ptl_convert(const PTLCommon
> > *general_ptl,
> > H265RawProfileTierLevel *h2
> > }
> >
> > /*
> > - * Find exact va_profile for HEVC Range Extension
> > + * Find exact va_profile for HEVC Range Extension and Screen
> > Content Coding
> > Extension
> > */
> > -VAProfile ff_vaapi_parse_hevc_rext_profile(AVCodecContext *avctx)
> > +VAProfile ff_vaapi_parse_hevc_profile(AVCodecContext *avctx)
>
> It sounds to me the new function is for all hevc profiles, how about
> to use
> ff_vaapi_parse_hevc_rext_scc_profile instead ?
Fixed in V3. Thanks.
Fei
>
> Thanks
> Haihao
>
>
> > @@ -627,6 +627,16 @@ VAProfile
> > ff_vaapi_parse_hevc_rext_profile(AVCodecContext
> > *avctx)
> > else if (!strcmp(profile->name, "Main 4:4:4 12") ||
> > !strcmp(profile->name, "Main 4:4:4 12 Intra"))
> > return VAProfileHEVCMain444_12;
> > +else if (!strcmp(profile->name, "Screen-Extended Main"))
> > +return VAProfileHEVCSccMain;
> > +else if (!strcmp(profile->name, "Screen-Extended Main 10"))
> > +return VAProfileHEVCSccMain10;
> > +else if (!strcmp(profile->name, "Screen-Extended Main 4:4:4"))
> > +return VAProfileHEVCSccMain444;
> > +#if VA_CHECK_VERSION(1, 8, 0)
> > +else if (!strcmp(profile->name, "Screen-Extended Main 4:4:4
> > 10"))
> > +return VAProfileHEVCSccMain444_10;
> > +#endif
> > #else
> > av_log(avctx, AV_LOG_WARNING, "HEVC profile %s is "
> > "not supported with this VA version.\n", profile-
> > >name);
> > diff --git a/libavcodec/vaapi_hevc.h b/libavcodec/vaapi_hevc.h
> > index b3b0e6fc1e..7662dca510 100644
> > --- a/libavcodec/vaapi_hevc.h
> > +++ b/libavcodec/vaapi_hevc.h
> > @@ -22,6 +22,6 @@
> > #include
> > #include "avcodec.h"
> >
> > -VAProfile ff_vaapi_parse_hevc_rext_profile(AVCodecContext *avctx);
> > +VAProfile ff_vaapi_parse_hevc_profile(AVCodecContext *avctx);
> >
> > #endif /* AVCODEC_VAAPI_HEVC_H */
___
ffmpeg-devel mailing list
ffmpeg-devel@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 13/13] lavc/vaapi_hevc: Remove duplicate code
On Mon, 2022-12-05 at 14:09 +0800, Fei Wang wrote:
> Signed-off-by: Fei Wang
> ---
> libavcodec/vaapi_hevc.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c
> index ca14052d56..b3ff2f7344 100644
> --- a/libavcodec/vaapi_hevc.c
> +++ b/libavcodec/vaapi_hevc.c
> @@ -538,12 +538,6 @@ static int
> vaapi_hevc_decode_slice(AVCodecContext *avctx,
> pic->last_slice_param.rext.ChromaOffsetL0[i][1] = sh-
> >chroma_offset_l0[i][1];
> }
>
> -for (i = 0; i < 15 && i < sh->nb_refs[L0]; i++) {
> -pic->last_slice_param.rext.luma_offset_l0[i] = sh-
> >luma_offset_l0[i];
> -pic->last_slice_param.rext.ChromaOffsetL0[i][0] = sh-
> >chroma_offset_l0[i][0];
> -pic->last_slice_param.rext.ChromaOffsetL0[i][1] = sh-
> >chroma_offset_l0[i][1];
> -}
> -
Confirmed locally, FATE test pass without any error.
Thanks
Fei
> if (sh->slice_type == HEVC_SLICE_B) {
> for (i = 0; i < 15 && i < sh->nb_refs[L1]; i++) {
> pic->last_slice_param.rext.luma_offset_l1[i] = sh-
> >luma_offset_l1[i];
___
ffmpeg-devel mailing list
ffmpeg-devel@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 01/13] lavc/hevc_ps: remove profile limitation of pps_range_extensions()
On Mon, 2022-12-05 at 14:09 +0800, Fei Wang wrote:
> Follow spec 7.3.2.3.1.
>
> Signed-off-by: Fei Wang
> ---
> update:
> 1. fix uninitialized variable which may cause segment fault.
Ping for review this patchset.
Confirmed with Qemu locally for Loongarch64 with:
https://github.com/sunhaiyong1978/CLFS-for-LoongArch/releases/tag/7.0
The FATE test hevc-conformance-PS_A_VIDYO_3 pass without any error.
Thanks
Fei
>
> libavcodec/hevc_ps.c | 2 +-
> tests/ref/fate/hevc-conformance-PS_A_VIDYO_3 | 50 ++--
>
> 2 files changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index 5fe62ec35b..537a3ff99b 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -1658,7 +1658,7 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
> AVCodecContext *avctx,
> if (get_bits1(gb)) { // pps_extension_present_flag
> pps->pps_range_extensions_flag = get_bits1(gb);
> skip_bits(gb, 7); // pps_extension_7bits
> -if (sps->ptl.general_ptl.profile_idc == FF_PROFILE_HEVC_REXT
> && pps->pps_range_extensions_flag) {
> +if (pps->pps_range_extensions_flag) {
> if ((ret = pps_range_extensions(gb, avctx, pps, sps)) <
> 0)
> goto err;
> }
> diff --git a/tests/ref/fate/hevc-conformance-PS_A_VIDYO_3
> b/tests/ref/fate/hevc-conformance-PS_A_VIDYO_3
> index 59b82b72bb..d1d86b2dc9 100644
> --- a/tests/ref/fate/hevc-conformance-PS_A_VIDYO_3
> +++ b/tests/ref/fate/hevc-conformance-PS_A_VIDYO_3
> @@ -3,28 +3,28 @@
> #codec_id 0: rawvideo
> #dimensions 0: 416x240
> #sar 0: 0/1
> -0, 0, 0,1, 149760, 0x88619f80
> -0, 1, 1,1, 149760, 0x550bdaf0
> -0, 2, 2,1, 149760, 0x4121f7a2
> -0, 3, 3,1, 149760, 0x210b1d07
> -0, 4, 4,1, 149760, 0x731b7758
> -0, 5, 5,1, 149760, 0x17adb789
> -0, 6, 6,1, 149760, 0x98b2f080
> -0, 7, 7,1, 149760, 0xc0be1f2a
> -0, 8, 8,1, 149760, 0xc01e387a
> -0, 9, 9,1, 149760, 0xd932822b
> -0, 10, 10,1, 149760, 0x16c0a1df
> -0, 11, 11,1, 149760, 0x5aa6c005
> -0, 12, 12,1, 149760, 0xd3aab602
> -0, 13, 13,1, 149760, 0x4e6ecab1
> -0, 14, 14,1, 149760, 0x8a86f1f2
> -0, 15, 15,1, 149760, 0x2ed21e1b
> -0, 16, 16,1, 149760, 0x80892f24
> -0, 17, 17,1, 149760, 0xb8a952ef
> -0, 18, 18,1, 149760, 0x557e57fb
> -0, 19, 19,1, 149760, 0x2b825b2c
> -0, 20, 20,1, 149760, 0x30b69b5e
> -0, 21, 21,1, 149760, 0x802ebf08
> -0, 22, 22,1, 149760, 0x95aadc8e
> -0, 23, 23,1, 149760, 0x4d4c02b7
> -0, 24, 24,1, 149760, 0x3fdd1762
> +0, 0, 0,1, 149760, 0x5c4f70f4
> +0, 1, 1,1, 149760, 0xf4628e59
> +0, 2, 2,1, 149760, 0xa28e5bdc
> +0, 3, 3,1, 149760, 0xda0e53d7
> +0, 4, 4,1, 149760, 0x42dd334a
> +0, 5, 5,1, 149760, 0x25ba9dfe
> +0, 6, 6,1, 149760, 0x8854d8ca
> +0, 7, 7,1, 149760, 0xc04505d4
> +0, 8, 8,1, 149760, 0xd3fce146
> +0, 9, 9,1, 149760, 0x8bfd88bd
> +0, 10, 10,1, 149760, 0x33d965b2
> +0, 11, 11,1, 149760, 0x12746b7a
> +0, 12, 12,1, 149760, 0xb7642694
> +0, 13, 13,1, 149760, 0x32b5035f
> +0, 14, 14,1, 149760, 0x7bea0af1
> +0, 15, 15,1, 149760, 0x577d4fc8
> +0, 16, 16,1, 149760, 0x023a9c66
> +0, 17, 17,1, 149760, 0x9abe76c4
> +0, 18, 18,1, 149760, 0x2b14dba5
> +0, 19, 19,1, 149760, 0x7b8affcf
> +0, 20, 20,1, 149760, 0x21e4c323
> +0, 21, 21,1, 149760, 0xf0b7d9cd
> +0, 22, 22,1, 149760, 0x4db0c5bc
> +0, 23, 23,1, 149760, 0xf455f752
> +0, 24, 24,1, 149760, 0x569fec99
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 2/2] lavc/vaapi_decode: add support for HWACCEL_CAP_RESET_WITHOUT_UNINIT
On Thu, 2022-12-01 at 09:55 +0800, Fei Wang wrote: > On Mon, 2022-11-28 at 13:20 +, Mark Thompson wrote: > > On 14/11/2022 01:16, Fei Wang wrote: > > > This can fix vp9 decode image corruption when the frame size is > > > change, > > > but the pervious frames still be referenced. > > > > > > Surfaces don't need to be bound to vaContext only after VAAPI > > > 1.0.0: > > > https://github.com/intel/libva/commit/492b692005ccd0d8da190209d5b3ae7b7825f4b8 > > > > > > Signed-off-by: Fei Wang > > > --- > > > libavcodec/vaapi_decode.c | 11 --- > > > libavcodec/vaapi_decode.h | 1 + > > > libavcodec/vaapi_vp9.c| 4 > > > 3 files changed, 13 insertions(+), 3 deletions(-) > > > > This always segfaults immediately on anything unsupported. E.g. > > with > > fate/hevc/paramchange_yuv420p_yuv420p10.hevc: > > > > [hevc @ 0x57c0e7c0] Format vaapi chosen by get_format(). > > [hevc @ 0x57c0e7c0] Format vaapi requires hwaccel > > initialisation. > > [hevc @ 0x57c0e7c0] Hardware does not support image size > > 1056x8440 (constraints: width 0-4096 height 0-4096). > > > > Thread 20 "av:hevc:df0" received signal SIGSEGV, Segmentation > > fault. > > [Switching to Thread 0x7fffb4ff9700 (LWP 509456)] > > ff_vaapi_decode_uninit (avctx=0x57c0e7c0) at > > src/libavcodec/vaapi_decode.c:714 > > 714 vas = vaDestroyContext(ctx->hwctx->display, ctx- > > > va_context); > > (gdb) bt > > #0 ff_vaapi_decode_uninit (avctx=0x57c0e7c0) at > > src/libavcodec/vaapi_decode.c:714 > > #1 0x563073d7 in ff_vaapi_decode_init > > (avctx=0x57c0e7c0) > > at src/libavcodec/vaapi_decode.c:704 > > #2 0x55e62fee in hwaccel_init (avctx=0x57c0e7c0, > > hw_config=0x5728f770 <__compound_literal.0>) at > > src/libavcodec/decode.c:1121 > > #3 0x55e634ec in ff_get_format (avctx=0x57c0e7c0, > > fmt=0x7fffb4ff8ccc) at src/libavcodec/decode.c:1261 > > #4 0x561ca829 in ff_thread_get_format > > (avctx=0x57c0e7c0, > > fmt=0x7fffb4ff8ccc) at src/libavcodec/pthread_frame.c:1048 > > #5 0x55f68f37 in get_format (s=0x57c3e6c0, > > sps=0x57c21f80) at src/libavcodec/hevcdec.c:505 > > #6 0x55f69621 in hls_slice_header (s=0x57c3e6c0) at > > src/libavcodec/hevcdec.c:618 > > #7 0x55f7472d in decode_nal_unit (s=0x57c3e6c0, > > nal=0x7fff8802e920) at src/libavcodec/hevcdec.c:3173 > > #8 0x55f7508a in decode_nal_units (s=0x57c3e6c0, > > buf=0x7637c010 "", length=159280) at > > src/libavcodec/hevcdec.c:3355 > > #9 0x55f756d6 in hevc_decode_frame (avctx=0x57c0e7c0, > > rframe=0x57c0ecc0, got_output=0x57c0d690, > > avpkt=0x57c0ef40) at src/libavcodec/hevcdec.c:3497 > > #10 0x561c839c in frame_worker_thread (arg=0x57c0d580) > > at > > src/libavcodec/pthread_frame.c:241 > > #11 0x768ccea7 in start_thread (arg=) at > > pthread_create.c:477 > > #12 0x767ecaef in clone () at > > ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 > > (gdb) > > Thanks, will fix this in next version. > > > > > Also, I don't see how this is testing whether the driver supports > > changing the resolution at runtime? The note in libva that you > > cite > > allows new switching render targets in the context, but I don't see > > why different resolution would be allowed given that it's a > > parameter > > passed to vaCreateContext()? > > > > Looking at the Mesa driver it appears that the internally-allocated > > references are not going to allow size changes (where does the > > template width get updated?). I don't have any hardware to test > > that, though - are you able to try this on recent AMD hardware with > > VP9 support? > > I checked on AMD RX6700XT, it can get correct output when decoding > multi-resolution vp9 clips only after apply this patchset. For > example, > by using clip from: > https://storage.googleapis.com/downloads.webmproject.org/vp9/decoder-test-streams/Profile_0_8bit.zip > > VP9 native decode result: > ffmpeg -i > Profile_0_8bit/frm_resize/crowd_run_1080X512_fr30_bd8_frm_resize_l3.w > eb > m -pix_fmt yuv420p -autoscale 0 -f md5 -y - > [...] > MD5=51b3393fa98ad9ab99c0b45ef705ebc4 > [...] > > Without this patchset: > ffmpeg -v verbose -hwaccel vaapi -i > Profile_0_8bit/frm_resize/crowd_run_1080X512_fr30_bd8_frm_resize_l3.w > eb > m -pix_fmt yuv420p -autoscale 0 -f md5 -y - > [...] > [AVHWDeviceContext @ 0x56526336a000] VAAPI driver: Mesa Gallium > driver > 22.3.0-rc4 for AMD Radeon RX 6700 XT (navi22, LLVM 11.0.0, DRM 3.44, > 5.13.0-40-generic). > [...] > MD5=2e799f0f916195f86a356907f7e4eae1 (change from time to time, but > never same with native decode result) > [...] > > With this patchset: > ffmpeg -v verbose -hwaccel vaapi -i > Profile_0_8bit/frm_resize/crowd_run_1080X512_fr30_bd8_frm_resize_l3.w > eb > m -pix_fmt yuv420p -autoscale 0 -f md5 -y - > [...] > [AVHWDeviceContext @ 0x561c08e7a000] VAAPI driver: Mesa Gallium > driver > 22.3.0-rc4 for AMD Radeon RX
Re: [FFmpeg-devel] [PATCH v1 03/13] lavc/hevc_ps: Add SPS/PPS parse support for HEVC extension syntax
On Thu, 2022-12-01 at 22:52 -0300, James Almer wrote:
> On 12/1/2022 5:13 AM, Fei Wang wrote:
> > +static void colour_mapping_octants(GetBitContext *gb, HEVCPPS
> > *pps, int inp_depth,
> > + int idx_y, int idx_cb, int
> > idx_cr, int inp_length)
> > +{
> > +uint8_t split_octant_flag, coded_res_flag;
> > +uint16_t part_num_y, res_coeff_q, res_coeff_r;
>
> Use int or unsigned for scalar values in stack.
>
> > +int bit_depth_cm_input_y, bit_depth_cm_output_y, cm_res_bits;
> > +int k, m, n, c, i, j;
>
> You can reduce the scope of almost all the above variables.
>
> > +
> > +part_num_y = 1 << pps->cm_y_part_num_log2;
> > +
> > +if (inp_depth < pps->cm_octant_depth)
> > +split_octant_flag = get_bits1(gb);
> > +
> > +if (split_octant_flag)
>
> split_octant_flag may be undefined here. It should be initialized to
> 0.
> This is probably the source of the issue Michael reported.
>
> > +for (k = 0; k < 2; k++)
>
> for (int k = 0...)
>
> Same for the rest.
Fixed in V2.
Thanks
Fei
>
> > +for (m = 0; m < 2; m++)
> > +for (n = 0; n < 2; n++)
> > +colour_mapping_octants(gb, pps, inp_depth + 1,
> > + idx_y + part_num_y * k
> > * inp_length / 2,
> > + idx_cb + m * inp_length
> > / 2,
> > + idx_cr + n * inp_length
> > / 2,
> > + inp_length / 2);
> > +else
> > +for (i = 0; i < part_num_y; i++) {
> > +for (j = 0; j < 4; j++) {
> > +coded_res_flag = get_bits1(gb);
> > +if (coded_res_flag)
> > +for (c = 0; c < 3; c++) {
> > +res_coeff_q = get_ue_golomb_long(gb);
> > +bit_depth_cm_input_y = 8 + pps-
> > >luma_bit_depth_cm_input_minus8;
> > +bit_depth_cm_output_y = 8 + pps-
> > >luma_bit_depth_cm_output_minus8;
> > +cm_res_bits = FFMAX(0, 10 +
> > bit_depth_cm_input_y - bit_depth_cm_output_y -
> > +pps->cm_res_quant_bits
> > - (pps->cm_delta_flc_bits_minus1 + 1));
> > +res_coeff_r = get_bits(gb, cm_res_bits);
> > +if (res_coeff_q || res_coeff_r)
> > +skip_bits1(gb);
> > +}
> > +}
> > +}
> > +}
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 v1 03/13] lavc/hevc_ps: Add SPS/PPS parse support for HEVC extension syntax
On Fri, 2022-12-02 at 01:21 +0100, Michael Niedermayer wrote: > On Thu, Dec 01, 2022 at 04:13:58PM +0800, Fei Wang wrote: > > From: Linjie Fu > > > > 1. Add extension syntax according to 7.3.2.2.3/7.3.2.3.3 in T-REC- > > H.265-201911. > > 2. Keep using parsed PPS when bitstream overread for compatibility. > > For > > example, the clip PS_A_VIDYO_3.bit in FATE test has incomplete > > extension > > syntax which will be overread and un-decodable if without this > > change. > > 3. Format brace in pps_range_extensions(). > > > > Signed-off-by: Linjie Fu > > Signed-off-by: Haihao Xiang > > Signed-off-by: Fei Wang > > --- > > libavcodec/hevc.h| 3 + > > libavcodec/hevc_ps.c | 293 > > +-- > > libavcodec/hevc_ps.h | 69 ++ > > 3 files changed, 357 insertions(+), 8 deletions(-) > > This causes segfaults > > shortened stack trace looks like this, > seems like classic stack overflow from infinite recursion Thanks Michael, Could you send me the clip caused this issue? Fei > > #0 0x56403d10 in colour_mapping_octants () > #1 0x56403d15 in colour_mapping_octants () > #2 0x56403d15 in colour_mapping_octants () > #3 0x56403d15 in colour_mapping_octants () > #4 0x56403d15 in colour_mapping_octants () > #5 0x56403d15 in colour_mapping_octants () > #6 0x56403d15 in colour_mapping_octants () > #7 0x56403d15 in colour_mapping_octants () > #8 0x56403d15 in colour_mapping_octants () > #9 0x56403d15 in colour_mapping_octants () > #10 0x56403d15 in colour_mapping_octants () > #11 0x56403d15 in colour_mapping_octants () > #12 0x56403d15 in colour_mapping_octants () > ... > > > [...] > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 2/2] lavc/vaapi_decode: add support for HWACCEL_CAP_RESET_WITHOUT_UNINIT
On Mon, 2022-11-28 at 13:20 +, Mark Thompson wrote: > On 14/11/2022 01:16, Fei Wang wrote: > > This can fix vp9 decode image corruption when the frame size is > > change, > > but the pervious frames still be referenced. > > > > Surfaces don't need to be bound to vaContext only after VAAPI > > 1.0.0: > > https://github.com/intel/libva/commit/492b692005ccd0d8da190209d5b3ae7b7825f4b8 > > > > Signed-off-by: Fei Wang > > --- > > libavcodec/vaapi_decode.c | 11 --- > > libavcodec/vaapi_decode.h | 1 + > > libavcodec/vaapi_vp9.c| 4 > > 3 files changed, 13 insertions(+), 3 deletions(-) > > This always segfaults immediately on anything unsupported. E.g. with > fate/hevc/paramchange_yuv420p_yuv420p10.hevc: > > [hevc @ 0x57c0e7c0] Format vaapi chosen by get_format(). > [hevc @ 0x57c0e7c0] Format vaapi requires hwaccel initialisation. > [hevc @ 0x57c0e7c0] Hardware does not support image size > 1056x8440 (constraints: width 0-4096 height 0-4096). > > Thread 20 "av:hevc:df0" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffb4ff9700 (LWP 509456)] > ff_vaapi_decode_uninit (avctx=0x57c0e7c0) at > src/libavcodec/vaapi_decode.c:714 > 714 vas = vaDestroyContext(ctx->hwctx->display, ctx- > >va_context); > (gdb) bt > #0 ff_vaapi_decode_uninit (avctx=0x57c0e7c0) at > src/libavcodec/vaapi_decode.c:714 > #1 0x563073d7 in ff_vaapi_decode_init (avctx=0x57c0e7c0) > at src/libavcodec/vaapi_decode.c:704 > #2 0x55e62fee in hwaccel_init (avctx=0x57c0e7c0, > hw_config=0x5728f770 <__compound_literal.0>) at > src/libavcodec/decode.c:1121 > #3 0x55e634ec in ff_get_format (avctx=0x57c0e7c0, > fmt=0x7fffb4ff8ccc) at src/libavcodec/decode.c:1261 > #4 0x561ca829 in ff_thread_get_format (avctx=0x57c0e7c0, > fmt=0x7fffb4ff8ccc) at src/libavcodec/pthread_frame.c:1048 > #5 0x55f68f37 in get_format (s=0x57c3e6c0, > sps=0x57c21f80) at src/libavcodec/hevcdec.c:505 > #6 0x55f69621 in hls_slice_header (s=0x57c3e6c0) at > src/libavcodec/hevcdec.c:618 > #7 0x55f7472d in decode_nal_unit (s=0x57c3e6c0, > nal=0x7fff8802e920) at src/libavcodec/hevcdec.c:3173 > #8 0x55f7508a in decode_nal_units (s=0x57c3e6c0, > buf=0x7637c010 "", length=159280) at > src/libavcodec/hevcdec.c:3355 > #9 0x55f756d6 in hevc_decode_frame (avctx=0x57c0e7c0, > rframe=0x57c0ecc0, got_output=0x57c0d690, > avpkt=0x57c0ef40) at src/libavcodec/hevcdec.c:3497 > #10 0x561c839c in frame_worker_thread (arg=0x57c0d580) at > src/libavcodec/pthread_frame.c:241 > #11 0x768ccea7 in start_thread (arg=) at > pthread_create.c:477 > #12 0x767ecaef in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 > (gdb) Thanks, will fix this in next version. > > > Also, I don't see how this is testing whether the driver supports > changing the resolution at runtime? The note in libva that you cite > allows new switching render targets in the context, but I don't see > why different resolution would be allowed given that it's a parameter > passed to vaCreateContext()? > > Looking at the Mesa driver it appears that the internally-allocated > references are not going to allow size changes (where does the > template width get updated?). I don't have any hardware to test > that, though - are you able to try this on recent AMD hardware with > VP9 support? I checked on AMD RX6700XT, it can get correct output when decoding multi-resolution vp9 clips only after apply this patchset. For example, by using clip from: https://storage.googleapis.com/downloads.webmproject.org/vp9/decoder-test-streams/Profile_0_8bit.zip VP9 native decode result: ffmpeg -i Profile_0_8bit/frm_resize/crowd_run_1080X512_fr30_bd8_frm_resize_l3.web m -pix_fmt yuv420p -autoscale 0 -f md5 -y - [...] MD5=51b3393fa98ad9ab99c0b45ef705ebc4 [...] Without this patchset: ffmpeg -v verbose -hwaccel vaapi -i Profile_0_8bit/frm_resize/crowd_run_1080X512_fr30_bd8_frm_resize_l3.web m -pix_fmt yuv420p -autoscale 0 -f md5 -y - [...] [AVHWDeviceContext @ 0x56526336a000] VAAPI driver: Mesa Gallium driver 22.3.0-rc4 for AMD Radeon RX 6700 XT (navi22, LLVM 11.0.0, DRM 3.44, 5.13.0-40-generic). [...] MD5=2e799f0f916195f86a356907f7e4eae1 (change from time to time, but never same with native decode result) [...] With this patchset: ffmpeg -v verbose -hwaccel vaapi -i Profile_0_8bit/frm_resize/crowd_run_1080X512_fr30_bd8_frm_resize_l3.web m -pix_fmt yuv420p -autoscale 0 -f md5 -y - [...] [AVHWDeviceContext @ 0x561c08e7a000] VAAPI driver: Mesa Gallium driver 22.3.0-rc4 for AMD Radeon RX 6700 XT (navi22, LLVM 11.0.0, DRM 3.44, 5.13.0-40-generic). [...] MD5=51b3393fa98ad9ab99c0b45ef705ebc4 [...] That means both Intel and AMD driver implementation doesn't limit surface's resolution must be same with vacontext. So I think we can add some description to libva to declare that. > > What have you done to
Re: [FFmpeg-devel] [PATCH v5 1/2] lavc: add HWACCEL_CAP_RESET_WITHOUT_UNINIT capacity for hwaccel
On Mon, 2022-11-14 at 09:16 +0800, Fei Wang wrote:
> The capacity can avoid hwaccel being uninited when do the reset. It
> provides the method for hwaccel if it still want to use the previous
> initialized configuration after reset. And the configuration can be
> updated in AVHWAccel.init() if needed.
>
> For example, when use vaapi vp9 decode dynamic resolution clips, need
> to avoid changing vaContext in avctx->internal->hwaccel_priv_data if
> current frame resolution change and it reference a pervious frame
> with
> different resolution. Otherwise reference frame's information bound
> in vaContext will be lost, then corrupt current frame.
>
> Signed-off-by: Fei Wang
> ---
> update:
> 1. consider the case of va_config/va_context equal to 0.
Hi Mark,Haihao,
Any further comments on this version?
Thanks
Fei
>
> libavcodec/decode.c | 10 ++
> libavcodec/hwconfig.h | 7 +++
> 2 files changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 6be2d3d6ed..cfada048e8 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1109,7 +1109,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)
> @@ -1134,10 +1134,12 @@ static int hwaccel_init(AVCodecContext
> *avctx,
>
> static void hwaccel_uninit(AVCodecContext *avctx)
> {
> -if (avctx->hwaccel && avctx->hwaccel->uninit)
> -avctx->hwaccel->uninit(avctx);
> +if (avctx->hwaccel && !(avctx->hwaccel->caps_internal &
> HWACCEL_CAP_RESET_WITHOUT_UNINIT)) {
> +if (avctx->hwaccel->uninit)
> +avctx->hwaccel->uninit(avctx);
>
> -av_freep(>internal->hwaccel_priv_data);
> +av_freep(>internal->hwaccel_priv_data);
> +}
>
> avctx->hwaccel = NULL;
>
> diff --git a/libavcodec/hwconfig.h b/libavcodec/hwconfig.h
> index 721424912c..5fb4e06d5f 100644
> --- a/libavcodec/hwconfig.h
> +++ b/libavcodec/hwconfig.h
> @@ -25,6 +25,13 @@
>
> #define HWACCEL_CAP_ASYNC_SAFE (1 << 0)
>
> +/**
> + * The hwaccel supports reset without calling back
> AVHWAccel.uninit()
> + * and realloc avctx->internal->hwaccel_priv_data.
> + *
> + * New configuration can set up through AVHWAccel.init().
> + */
> +#define HWACCEL_CAP_RESET_WITHOUT_UNINIT (1 << 1)
>
> typedef struct AVCodecHWConfigInternal {
> /**
___
ffmpeg-devel mailing list
ffmpeg-devel@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 2/2] lavc/vaapi_decode: add support for HWACCEL_CAP_RESET_WITHOUT_UNINIT
On Fri, 2022-11-11 at 03:45 +, Xiang, Haihao wrote:
> On Tue, 2022-11-08 at 19:45 +0800, Fei Wang wrote:
> > This can fix vp9 decode image corruption when the frame size is
> > change,
> > but the pervious frames still be referenced.
> >
> > Surfaces don't need to be bound to vaContext only after VAAPI
> > 1.0.0:
> > https://github.com/intel/libva/commit/492b692005ccd0d8da190209d5b3ae7b7825f4b8
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/vaapi_decode.c | 41 ++-
> >
> > libavcodec/vaapi_vp9.c| 4
> > 2 files changed, 27 insertions(+), 18 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index 134f10eca5..618f3c3e0a 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -658,8 +658,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;
> > +}
>
> 0 is valid for VA config and context, it is possible the underlying
> driver
> creates VA config and context with id 0.
Fixed in V5. Thanks.
Fei
>
> Thanks
> Haihao
>
> >
> > err = ff_decode_get_hw_frames_ctx(avctx,
> > AV_HWDEVICE_TYPE_VAAPI);
> > if (err < 0)
> > @@ -670,24 +672,27 @@ int ff_vaapi_decode_init(AVCodecContext
> > *avctx)
> > ctx->device = ctx->frames->device_ctx;
> > ctx->hwctx = ctx->device->hwctx;
> >
> > -err = vaapi_decode_make_config(avctx, ctx->frames->device_ref,
> > - >va_config, NULL);
> > -if (err)
> > -goto fail;
> > -
> > -vas = vaCreateContext(ctx->hwctx->display, ctx->va_config,
> > - avctx->coded_width, avctx->coded_height,
> > - VA_PROGRESSIVE,
> > - ctx->hwfc->surface_ids,
> > - ctx->hwfc->nb_surfaces,
> > - >va_context);
> > -if (vas != VA_STATUS_SUCCESS) {
> > -av_log(avctx, AV_LOG_ERROR, "Failed to create decode "
> > - "context: %d (%s).\n", vas, vaErrorStr(vas));
> > -err = AVERROR(EIO);
> > -goto fail;
> > +if (ctx->va_config == VA_INVALID_ID) {
> > +err = vaapi_decode_make_config(avctx, ctx->frames-
> > >device_ref,
> > + >va_config, NULL);
> > +if (err)
> > +goto fail;
> > }
> >
> > +if (ctx->va_context == VA_INVALID_ID) {
> > +vas = vaCreateContext(ctx->hwctx->display, ctx->va_config,
> > + avctx->coded_width, avctx-
> > >coded_height,
> > + VA_PROGRESSIVE,
> > + ctx->hwfc->surface_ids,
> > + ctx->hwfc->nb_surfaces,
> > + >va_context);
> > +if (vas != VA_STATUS_SUCCESS) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to create decode "
> > + "context: %d (%s).\n", vas, vaErrorStr(vas));
> > +err = AVERROR(EIO);
> > +goto fail;
> > +}
> > +}
> > av_log(avctx, AV_LOG_DEBUG, "Decode context initialised: "
> > "%#x/%#x.\n", ctx->va_config, ctx->va_context);
> >
> > diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
> > index 776382f683..245b7a1b3a 100644
> > --- a/libavcodec/vaapi_vp9.c
> > +++ b/libavcodec/vaapi_vp9.c
> > @@ -181,5 +181,9 @@ const AVHWAccel ff_vp9_vaapi_hwaccel = {
> > .uninit = ff_vaapi_decode_uninit,
> > .frame_params = ff_vaapi_common_frame_params,
> > .priv_data_size = sizeof(VAAPIDecodeContext),
> > +#if VA_CHECK_VERSION(1, 0, 0)
> > +.caps_internal= HWACCEL_CAP_ASYNC_SAFE |
> > HWACCEL_CAP_RESET_WITHOUT_UNINIT,
> > +#else
> > .caps_internal= HWACCEL_CAP_ASYNC_SAFE,
> > +#endif
> > };
___
ffmpeg-devel mailing list
ffmpeg-devel@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/3] lavc/decode: Add internal surface re-allocate method for hwaccel
On Mon, 2022-09-19 at 14:08 +0800, Fei Wang wrote: > On Wed, 2022-09-07 at 22:56 +0100, Mark Thompson wrote: > > On 23/08/2022 09:19, Fei Wang wrote: > > > From: Linjie Fu > > > > > > Add HWACCEL_CAP_INTERNAL_ALLOC flag to indicate hwaccels are able > > > to > > > re-allocate surface internally through > > > ff_decode_get_hw_frames_ctx. > > > So that hwaccels don't need to reinitialize all hw related > > > configs > > > when decode resolution change, just need to re-allocate new > > > surface > > > by using new resolution. > > > > > > Signed-off-by: Linjie Fu > > > Signed-off-by: Fei Wang > > > --- > > > libavcodec/decode.c | 36 > > > libavcodec/hwconfig.h | 1 + > > > 2 files changed, 37 insertions(+) > > > > You can't just not call the user get_format callback and allocate > > your own surfaces - this breaks direct rendering and other cases > > where the user wanted to manage the surfaces. > > > > This is also missing any check that the hardware decoder supports > > the > > stream post-transition - if the decoder does not support the new > > size > > (or any other property of the new stream) then this will try to > > blindly decode it anyway and fail, where previously it would have > > correctly fallen back to software decoding. > > > > > > None of these patches say what the aim is, but from reading them > > and > > seeing that VP9 is the intended target then I am guessing that this > > is intended to support the case where the stream resizes while > > still > > using previous reference frames - is that right? > > Yes, this fixed some vp9 resize streams which reference frames has > different resolution. > > > If my guess is correct, I think you should (a) mention that fact in > > the patches, and (b) target the support at specifically that case, > > and not try to mess with any other reinit cases. > > > > Something like: if you know you are in that case (the decoder > > itself > > has this information and could pass it to ff_get_format somehow) > > and > > the context supports it (I am still unclear how this support can be > > determined - the libva documentation is very clear that a context > > is > > tied to a particular height/width), then remember the context > > across > > the user get_format call and if things match up then re-use it. > > Thanks, the logic looks good. I will check it later to see if any > blocks on the detail implementation. Current decode logis is hwaccel->uninit, get_format, hwaccel->init. While the avctx->internal->hwaccel_priv_data is freed in uninit and re-alloc in init, so it can't store and re-use vaContext in get_format. I have modified the other version of V4, which can keep current decode logic as much as possible and still put alloc surfaces in hwaccel.init() after call back get_foramt. Thanks Fei > > Thanks > Fei > > If for some reason you are in that case but it can't work (e.g. > > because the new size isn't supported by the hardware), then you > > need > > a better error message - the stream is actually broken because most > > frames are not decodable until you reach another recovery point > > (since the reference frames are in hardware surfaces so the > > software > > decoder can't use them). > > > > - Mark > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] avcodec/av1_vaapi: fixed a decoding corruption issue
On Wed, 2022-11-02 at 15:35 -0400, Ruijing Dong wrote:
> In av1_spec.pdf page 38/669, there is a sentence below:
>
> if ( frame_type == KEY_FRAME && show_frame ) {
>for ( i = 0; i < NUM_REF_FRAMES; i++) {
> RefValid[ i ] = 0
> ..
>}
>..
> }
>
> This shows that the condition of invalidating current
> DPB frames should be the coming frame_type is KEY_FRAME plus
> show_frame is equal to 1. Otherwise, some of the frames
> in sequence after KEY_FRAME still refer to the reference frames
> before KEY_FRAME, and if these before KEY_FRAME reference
> frames were invalidated, these frames could not find their
> reference frames, and it could cause image corruption.
>
> Mesa fix is in
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19386
>
> Signed-off-by: Ruijing Dong
> ---
> update: re-organize commit message and title
>
> libavcodec/vaapi_av1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
> index 63374c31c9..d0339b2705 100644
> --- a/libavcodec/vaapi_av1.c
> +++ b/libavcodec/vaapi_av1.c
> @@ -274,7 +274,7 @@ static int vaapi_av1_start_frame(AVCodecContext
> *avctx,
> };
>
> for (int i = 0; i < AV1_NUM_REF_FRAMES; i++) {
> -if (pic_param.pic_info_fields.bits.frame_type ==
> AV1_FRAME_KEY)
> +if (pic_param.pic_info_fields.bits.frame_type ==
> AV1_FRAME_KEY && frame_header->show_frame)
LGTM, Thanks.
Fei
> pic_param.ref_frame_map[i] = VA_INVALID_ID;
> else
> pic_param.ref_frame_map[i] = ctx->ref_tab[i].valid ?
> --
> 2.25.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/av1_vaapi: fixed a decoding corruption issue
On Mon, 2022-10-31 at 22:32 -0400, Ruijing Dong wrote:
> v2: update commit message
Updates shouldn't appear in commit message. You can use "--annotate" of
git send-email, then add your updates below "---" after sign-off. Thus
the patch can be applied without updates. For example:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200909033956.27248-1-fei.w.w...@intel.com/
BTW, please indicate your patch version in the title. You should use '-
-subject-prefix="PATCH v3"' in next time.
>
> In av1_spec.pdf page 38/669, there is a sentence below:
>
> if ( frame_type == KEY_FRAME && show_frame ) {
> for ( i = 0; i < NUM_REF_FRAMES; i++) {
>RefValid[ i ] = 0
>..
> }
> ..
> }
>
> This shows that the condition of invalidating current
> DPB frames should be the coming frame_type is KEY_FRAME plus
> show_frame is equal to 1. Otherwise, some of the frames
> in sequence after KEY_FRAME still refer to the reference frames
> before KEY_FRAME, and if these before KEY_FRAME reference
> frames were invalidated, these frames could not find their
> reference frames, and it could cause image corruption.
>
> Mesa fix is in
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19386
Don't need to reserve blank space at the beginning of each line.
Thanks
Fei
>
> cc: Fei Wang
> Signed-off-by: Ruijing Dong
> ---
> libavcodec/vaapi_av1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
> index 63374c31c9..d0339b2705 100644
> --- a/libavcodec/vaapi_av1.c
> +++ b/libavcodec/vaapi_av1.c
> @@ -274,7 +274,7 @@ static int vaapi_av1_start_frame(AVCodecContext
> *avctx,
> };
>
> for (int i = 0; i < AV1_NUM_REF_FRAMES; i++) {
> -if (pic_param.pic_info_fields.bits.frame_type ==
> AV1_FRAME_KEY)
> +if (pic_param.pic_info_fields.bits.frame_type ==
> AV1_FRAME_KEY && frame_header->show_frame)
> pic_param.ref_frame_map[i] = VA_INVALID_ID;
> else
> pic_param.ref_frame_map[i] = ctx->ref_tab[i].valid ?
___
ffmpeg-devel mailing list
ffmpeg-devel@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/av1: fixed an vaapi decoding corruption issue
On Mon, 2022-10-31 at 11:46 -0400, Ruijing Dong wrote:
The title should be "avcodec/av1_vaapi: ".
> [problem]
> When decoding an av1 bitstream, it shows image corruption
> in the middle of the bitstream around key frames.
>
> [analysis]
> In av1_spec.pdf page 38/669, there is a sentence below:
>
> if ( frame_type == KEY_FRAME && show_frame ) {
> for ( i = 0; i < NUM_REF_FRAMES; i++) {
>RefValid[ i ] = 0
>..
> }
> ..
> }
>
> This shows that the condition of invalidating current
> DPB frames should be the coming frame_type is KEY_FRAME plus
> show_frame is equal to 1. Otherwise, some of the frames
> in sequence after KEY_FRAME still refer to the reference frames
> before KEY_FRAME, and if these before KEY_FRAME reference
> frames were invalidated, these frames could not find their
> reference frames, and it could cause image corruption.
[problem] and [solution] part and title "[analysis]" can be removed in
the commit message. Content after [analysis] is clear enough.
Thanks
Fei
>
> [solution]
> Add show_frame flag as another condition to co-determine
> when to invalidate DPB reference frames.
>
> Mesa fix is in
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19386
>
> cc: Fei Wang
> Signed-off-by: Ruijing Dong
> ---
> libavcodec/vaapi_av1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
> index 63374c31c9..d0339b2705 100644
> --- a/libavcodec/vaapi_av1.c
> +++ b/libavcodec/vaapi_av1.c
> @@ -274,7 +274,7 @@ static int vaapi_av1_start_frame(AVCodecContext
> *avctx,
> };
>
> for (int i = 0; i < AV1_NUM_REF_FRAMES; i++) {
> -if (pic_param.pic_info_fields.bits.frame_type ==
> AV1_FRAME_KEY)
> +if (pic_param.pic_info_fields.bits.frame_type ==
> AV1_FRAME_KEY && frame_header->show_frame)
> pic_param.ref_frame_map[i] = VA_INVALID_ID;
> else
> pic_param.ref_frame_map[i] = ctx->ref_tab[i].valid ?
___
ffmpeg-devel mailing list
ffmpeg-devel@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/3] lavc/decode: Add internal surface re-allocate method for hwaccel
On Wed, 2022-09-07 at 22:56 +0100, Mark Thompson wrote: > On 23/08/2022 09:19, Fei Wang wrote: > > From: Linjie Fu > > > > Add HWACCEL_CAP_INTERNAL_ALLOC flag to indicate hwaccels are able > > to > > re-allocate surface internally through ff_decode_get_hw_frames_ctx. > > So that hwaccels don't need to reinitialize all hw related configs > > when decode resolution change, just need to re-allocate new surface > > by using new resolution. > > > > Signed-off-by: Linjie Fu > > Signed-off-by: Fei Wang > > --- > > libavcodec/decode.c | 36 > > libavcodec/hwconfig.h | 1 + > > 2 files changed, 37 insertions(+) > > You can't just not call the user get_format callback and allocate > your own surfaces - this breaks direct rendering and other cases > where the user wanted to manage the surfaces. > > This is also missing any check that the hardware decoder supports the > stream post-transition - if the decoder does not support the new size > (or any other property of the new stream) then this will try to > blindly decode it anyway and fail, where previously it would have > correctly fallen back to software decoding. > > > None of these patches say what the aim is, but from reading them and > seeing that VP9 is the intended target then I am guessing that this > is intended to support the case where the stream resizes while still > using previous reference frames - is that right? Yes, this fixed some vp9 resize streams which reference frames has different resolution. > > If my guess is correct, I think you should (a) mention that fact in > the patches, and (b) target the support at specifically that case, > and not try to mess with any other reinit cases. > > Something like: if you know you are in that case (the decoder itself > has this information and could pass it to ff_get_format somehow) and > the context supports it (I am still unclear how this support can be > determined - the libva documentation is very clear that a context is > tied to a particular height/width), then remember the context across > the user get_format call and if things match up then re-use it. Thanks, the logic looks good. I will check it later to see if any blocks on the detail implementation. Thanks Fei > > If for some reason you are in that case but it can't work (e.g. > because the new size isn't supported by the hardware), then you need > a better error message - the stream is actually broken because most > frames are not decodable until you reach another recovery point > (since the reference frames are in hardware surfaces so the software > decoder can't use them). > > - Mark > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/3] lavc/decode: Warp get_hw_config function
On Tue, 2022-08-23 at 16:19 +0800, Fei Wang wrote:
> From: Linjie Fu
>
> Wrap the procedure of getting the hardware config from a pixel format
> into a function.
>
> Signed-off-by: Linjie Fu
> Signed-off-by: Fei Wang
> ---
> libavcodec/decode.c | 31 +++
> 1 file changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 75373989c6..3b69426c09 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1156,6 +1156,24 @@ static void hwaccel_uninit(AVCodecContext
> *avctx)
> av_buffer_unref(>hw_frames_ctx);
> }
>
> +static const AVCodecHWConfigInternal *get_hw_config(AVCodecContext
> *avctx, enum AVPixelFormat fmt)
> +{
> +const AVCodecHWConfigInternal *hw_config;
> +
> +if (!ffcodec(avctx->codec)->hw_configs)
> +return NULL;
> +
> +for (int i = 0;; i++) {
> +hw_config = ffcodec(avctx->codec)->hw_configs[i];
> +if (!hw_config)
> +return NULL;
> +if (hw_config->public.pix_fmt == fmt)
> +return hw_config;
> +}
> +
> +return NULL;
> +}
> +
> int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat
> *fmt)
> {
> const AVPixFmtDescriptor *desc;
> @@ -1213,18 +1231,7 @@ int ff_get_format(AVCodecContext *avctx, const
> enum AVPixelFormat *fmt)
> break;
> }
>
> -if (ffcodec(avctx->codec)->hw_configs) {
> -for (i = 0;; i++) {
> -hw_config = ffcodec(avctx->codec)->hw_configs[i];
> -if (!hw_config)
> -break;
> -if (hw_config->public.pix_fmt == user_choice)
> -break;
> -}
> -} else {
> -hw_config = NULL;
> -}
> -
> +hw_config = get_hw_config(avctx, user_choice);
> if (!hw_config) {
> // No config available, so no extra setup required.
> ret = user_choice;
Ping, any more comments on V3?
Thanks
Fei
___
ffmpeg-devel mailing list
ffmpeg-devel@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 1/3] lavc/decode: Add get_hw_config function
On Tue, 2022-08-16 at 13:22 +0200, Anton Khirnov wrote:
> The commit message is misleading - you are not adding code, you are
> moving code.
>
> Quoting Fei Wang (2022-08-12 14:55:43)
> > From: Linjie Fu
> >
> > Wrap the procedure of getting the hardware config from a pixel
> > format
> > into a function.
> >
> > Signed-off-by: Linjie Fu
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/decode.c | 33 +
> > 1 file changed, 21 insertions(+), 12 deletions(-)
> >
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index 75373989c6..d66d5a4160 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -1156,6 +1156,26 @@ static void hwaccel_uninit(AVCodecContext
> > *avctx)
> > av_buffer_unref(>hw_frames_ctx);
> > }
> >
> > +static const AVCodecHWConfigInternal *get_hw_config(AVCodecContext
> > *avctx, enum AVPixelFormat fmt)
> > +{
> > +const AVCodecHWConfigInternal *hw_config;
> > +int i;
>
> Should be declared in the loop
>
> > +if (ffcodec(avctx->codec)->hw_configs) {
> > +for (i = 0;; i++) {
> > +hw_config = ffcodec(avctx->codec)->hw_configs[i];
> > +if (!hw_config)
> > +break;
>
> return NULL;
>
> > +if (hw_config->public.pix_fmt == fmt)
> > +break;
>
> return hw_config;
>
> > +}
> > +} else {
> > +hw_config = NULL;
> > +}
>
> You can save one level of indentation by starting with
>
> if (!ffcodec(avctx->codec)->hw_configs)
> return NULL;
Fix in V2.
Thanks
Fei
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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 2/2] lavfi/overlay_vaapi: Set defalut alpha value as 1.0
On Wed, 2022-07-27 at 18:51 +0530, Gyan Doshi wrote:
> Typo in title.
>
>
>
> On 2022-07-27 06:06 pm, Fei Wang wrote:
> > Previous default value 0.0 means 100% transparency for overlaid
> > video,
> > which make overlaid invisible. Change to 1.0 will let output video
> > much
> > more clear and less confuse if user doesn't specify alpha value.
>
> "
> The present default value of 0 will render the overlay video
> invisible.
> A default of 1.0 is consistent with
> most common use cases.
> "
Fixed in V2.
Thanks
Fei
>
>
> > Signed-off-by: Fei Wang
> > ---
> > doc/filters.texi | 2 +-
> > libavfilter/vf_overlay_vaapi.c | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 47ac4dc7f4..76168955c6 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -26119,7 +26119,7 @@ Default value is the height of input
> > overlay video.
> > @item alpha
> > Set transparency of overlaid video. Allowed range is 0.0 to 1.0,
> > higher value means lower transparency.
> > -Default value is @code{0.0}.
> > +Default value is @code{1.0}.
> >
> > @end table
> >
> > diff --git a/libavfilter/vf_overlay_vaapi.c
> > b/libavfilter/vf_overlay_vaapi.c
> > index b3a624ae15..3e6a0de13f 100644
> > --- a/libavfilter/vf_overlay_vaapi.c
> > +++ b/libavfilter/vf_overlay_vaapi.c
> > @@ -380,7 +380,7 @@ static const AVOption overlay_vaapi_options[] =
> > {
> > { "h", "Overlay height",
> > OFFSET(overlay_oh), AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
> > INT_MAX, .flags = FLAGS },
> > { "alpha", "Overlay global alpha",
> > - OFFSET(alpha), AV_OPT_TYPE_FLOAT, { .dbl = 0.0}, 0.0, 1.0,
> > .flags = FLAGS},
> > + OFFSET(alpha), AV_OPT_TYPE_FLOAT, { .dbl = 1.0}, 0.0, 1.0,
> > .flags = FLAGS},
> > { 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".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] lavc/vaapi_decode: add missing flag when picking best pixel format
On Thu, 2022-08-04 at 20:59 -0700, Philip Langdale wrote:
> vaapi_decode_find_best_format currently does not set the
> VA_SURFACE_ATTRIB_SETTABLE flag on the pixel format attribute that it
> returns.
>
> Without this flag, the attribute will be ignored by vaCreateSurfaces,
> meaning that the driver's default logic for picking a pixel format
> will
> kick in.
>
> So far, this hasn't produced visible problems, but when trying to
> decode 4:4:4 content, at least on Intel, the driver will pick the
> 444P planar format, even though the decoder can only return the AYUV
> packed format.
>
> The hwcontext_vaapi code that sets surface attributes when picking
> formats does not have this bug.
>
> Applications may use their own logic for finding the best format, and
> so may not hit this bug. eg: mpv is unaffected.
>
> Signed-off-by: Philip Langdale
> ---
> libavcodec/vaapi_decode.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index db48efc3ed..38813eb8e4 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -358,6 +358,7 @@ static int
> vaapi_decode_find_best_format(AVCodecContext *avctx,
>
> ctx->pixel_format_attribute = (VASurfaceAttrib) {
> .type = VASurfaceAttribPixelFormat,
> +.flags = VA_SURFACE_ATTRIB_SETTABLE,
Better to fill .value.type with VAGenericValueTypeInteger together:
https://github.com/intel/media-driver/blob/4c95e8ef1e98cac661412d02f108e4e1c94d3556/media_driver/linux/common/ddi/media_libva.cpp#L2780
Thanks
Fei
> .value.value.i = best_fourcc,
> };
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavc/hevcdec: do not let missing ref frames invovled in dpb process
On Thu, 2022-07-14 at 03:56 +, Xiang, Haihao wrote:
> On Tue, 2022-06-14 at 09:23 +0800, Fei Wang wrote:
> > From: Xu Guangxin
> >
> > We will generate a new frame for a missed reference. The frame can
> > only
> > be used for reference. We assign an invalid decode sequence to it,
> > so
> > it will not be involved in any dpb process.
> >
> > Tested-by: Fei Wang
> > Signed-off-by: Xu Guangxin
> > ---
> > libavcodec/hevc_refs.c | 14 +-
> > libavcodec/hevcdec.c | 4 ++--
> > libavcodec/hevcdec.h | 3 +++
> > 3 files changed, 18 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
> > index 3f8fe1ef18..89053fd1a2 100644
> > --- a/libavcodec/hevc_refs.c
> > +++ b/libavcodec/hevc_refs.c
> > @@ -172,6 +172,16 @@ int ff_hevc_set_new_ref(HEVCContext *s,
> > AVFrame **frame,
> > int poc)
> > return 0;
> > }
> >
> > +static void unref_missing_refs(HEVCContext *s)
> > +{
> > +for (int i = 0; i < FF_ARRAY_ELEMS(s->DPB); i++) {
> > + HEVCFrame *frame = >DPB[i];
> > + if (frame->sequence == HEVC_DECODE_SEQUENCE_INVALID) {
> > + ff_hevc_unref_frame(s, frame, ~0);
> > + }
> > +}
> > +}
> > +
> > int ff_hevc_output_frame(HEVCContext *s, AVFrame *out, int flush)
> > {
> > if (IS_IRAP(s) && s->no_rasl_output_flag == 1) {
> > @@ -418,7 +428,7 @@ static HEVCFrame
> > *generate_missing_ref(HEVCContext *s, int
> > poc)
> > }
> >
> > frame->poc = poc;
> > -frame->sequence = s->seq_decode;
> > +frame->sequence = HEVC_DECODE_SEQUENCE_INVALID;
> > frame->flags= 0;
> >
> > if (s->threads_type == FF_THREAD_FRAME)
> > @@ -462,6 +472,8 @@ int ff_hevc_frame_rps(HEVCContext *s)
> > return 0;
> > }
> >
> > +unref_missing_refs(s);
> > +
> > /* clear the reference flags on all frames except the current
> > one */
> > for (i = 0; i < FF_ARRAY_ELEMS(s->DPB); i++) {
> > HEVCFrame *frame = >DPB[i];
> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > index f782ea6394..99785aa5d1 100644
> > --- a/libavcodec/hevcdec.c
> > +++ b/libavcodec/hevcdec.c
> > @@ -569,7 +569,7 @@ static int hls_slice_header(HEVCContext *s)
> > }
> >
> > if ((IS_IDR(s) || IS_BLA(s)) && sh->first_slice_in_pic_flag) {
> > -s->seq_decode = (s->seq_decode + 1) & 0xff;
> > +s->seq_decode = (s->seq_decode + 1) &
> > HEVC_DECODE_SEQUENCE_MASK;
> > s->max_ra = INT_MAX;
> > if (IS_IDR(s))
> > ff_hevc_clear_refs(s);
> > @@ -614,7 +614,7 @@ static int hls_slice_header(HEVCContext *s)
> > return pix_fmt;
> > s->avctx->pix_fmt = pix_fmt;
> >
> > -s->seq_decode = (s->seq_decode + 1) & 0xff;
> > +s->seq_decode = (s->seq_decode + 1) &
> > HEVC_DECODE_SEQUENCE_MASK;
>
> I see 0xff is used in other places, could you replace it with
> HEVC_DECODE_SEQUENCE_MASK too ?
Fixed in V3. Thanks
Fei
>
> Thanks
> Haihao
>
>
> > s->max_ra = INT_MAX;
> > }
> >
> > diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
> > index de861b88b3..9c8bcefb48 100644
> > --- a/libavcodec/hevcdec.h
> > +++ b/libavcodec/hevcdec.h
> > @@ -390,6 +390,9 @@ typedef struct DBParams {
> > #define HEVC_FRAME_FLAG_LONG_REF (1 << 2)
> > #define HEVC_FRAME_FLAG_BUMPING (1 << 3)
> >
> > +#define HEVC_DECODE_SEQUENCE_MASK 0xff
> > +#define HEVC_DECODE_SEQUENCE_INVALID (HEVC_DECODE_SEQUENCE_MASK +
> > 1)
> > +
> > typedef struct HEVCFrame {
> > AVFrame *frame;
> > AVFrame *frame_grain;
___
ffmpeg-devel mailing list
ffmpeg-devel@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 2/4] lavc/hevcdec: do not let missing ref frames invovled in dpb process
> -Original Message- > From: ffmpeg-devel On Behalf Of > Michael Niedermayer > Sent: Thursday, June 9, 2022 10:05 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH v1 2/4] lavc/hevcdec: do not let missing > ref > frames invovled in dpb process > > On Thu, Jun 09, 2022 at 05:34:47AM +, Wang, Fei W wrote: > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Michael Niedermayer > > > Sent: Tuesday, June 7, 2022 8:07 PM > > > To: FFmpeg development discussions and patches > > > > > > Subject: Re: [FFmpeg-devel] [PATCH v1 2/4] lavc/hevcdec: do not let > > > missing ref frames invovled in dpb process > > > > > > On Tue, Jun 07, 2022 at 03:08:28PM +0800, Fei Wang wrote: > > > > From: Xu Guangxin > > > > > > > > We will generate a new frame for a missed reference. The frame can > > > > only be used for reference. We assign an invalid decode sequence > > > > to it, so it will not be involved in any dpb process. > > > > > > > > Tested-by: Fei Wang > > > > Signed-off-by: Xu Guangxin > > > > --- > > > > libavcodec/hevc_refs.c | 13 - > > > > libavcodec/hevcdec.c | 4 ++-- > > > > libavcodec/hevcdec.h | 3 +++ > > > > 3 files changed, 17 insertions(+), 3 deletions(-) > > > > > > This causes segfaults > > > > Thanks Michael, could you share your clip to me? I can't reproduce this > > with all > my clips. > > file sent by private mail Fixed in V2. Thanks Fei > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The smallest minority on earth is the individual. Those who deny individual > rights > cannot claim to be defenders of minorities. - Ayn Rand ___ ffmpeg-devel mailing list ffmpeg-devel@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] lavc/vaapi_hevc: fill rext luma/chroma offset in the right way
> -Original Message-
> From: Xiang, Haihao
> Sent: Friday, June 10, 2022 11:49 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Wang, Fei W ; Xu, Guangxin
> ; linjie.justin...@gmail.com
> Subject: Re: [FFmpeg-devel] [PATCH v1] lavc/vaapi_hevc: fill rext luma/chroma
> offset in the right way
>
> On Wed, 2022-06-01 at 22:58 +0800, Fei Wang wrote:
> > From: Xu Guangxin
> >
> > For range extension, the luma/chroma offset is larger than 8 bits, we
> > need fill the 16 bits version.
> >
> > Signed-off-by: Xu Guangxin
> > Signed-off-by: Linjie Fu
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/vaapi_hevc.c | 53
> > -
> > 1 file changed, 37 insertions(+), 16 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_hevc.c b/libavcodec/vaapi_hevc.c index
> > 9083331c45..59beb86650 100644
> > --- a/libavcodec/vaapi_hevc.c
> > +++ b/libavcodec/vaapi_hevc.c
> > @@ -322,10 +322,17 @@ fail:
> > return ret;
> > }
> >
> > -static void fill_pred_weight_table(const HEVCContext *h,
> > +static void fill_pred_weight_table(const AVCodecContext *avctx,
> > + const HEVCContext *h,
> > const SliceHeader *sh,
> > VASliceParameterBufferHEVC
> > *slice_param) {
> > +#if VA_CHECK_VERSION(1, 2, 0)
> > +int is_rext = avctx->profile >= FF_PROFILE_HEVC_REXT; #else
> > +int is_rext = 0;
>
> It will uses the wrong luma/offset for REXT stream when vaapi < 1.2 , right ?
> I
> think it would be better to add some warning text to remind user.
Thanks, fixed in v2.
Fei
>
> Thanks
> Haihao
>
>
> > +#endif
> > +
> > int i;
> >
> > memset(slice_param->delta_luma_weight_l0, 0, sizeof(slice_param-
> > >delta_luma_weight_l0));
> > @@ -353,21 +360,25 @@ static void fill_pred_weight_table(const
> > HEVCContext *h,
> >
> > for (i = 0; i < 15 && i < sh->nb_refs[L0]; i++) {
> > slice_param->delta_luma_weight_l0[i] = sh->luma_weight_l0[i]
> > - (1 <<
> > sh->luma_log2_weight_denom);
> > -slice_param->luma_offset_l0[i] = sh->luma_offset_l0[i];
> > slice_param->delta_chroma_weight_l0[i][0] = sh-
> > >chroma_weight_l0[i][0] - (1 << sh->chroma_log2_weight_denom);
> > slice_param->delta_chroma_weight_l0[i][1] = sh-
> > >chroma_weight_l0[i][1] - (1 << sh->chroma_log2_weight_denom);
> > -slice_param->ChromaOffsetL0[i][0] = sh->chroma_offset_l0[i][0];
> > -slice_param->ChromaOffsetL0[i][1] = sh->chroma_offset_l0[i][1];
> > +if (!is_rext) {
> > +slice_param->luma_offset_l0[i] = sh->luma_offset_l0[i];
> > +slice_param->ChromaOffsetL0[i][0] = sh->chroma_offset_l0[i][0];
> > +slice_param->ChromaOffsetL0[i][1] = sh->chroma_offset_l0[i][1];
> > +}
> > }
> >
> > if (sh->slice_type == HEVC_SLICE_B) {
> > for (i = 0; i < 15 && i < sh->nb_refs[L1]; i++) {
> > slice_param->delta_luma_weight_l1[i] =
> > sh->luma_weight_l1[i] - (1 << sh->luma_log2_weight_denom);
> > -slice_param->luma_offset_l1[i] = sh->luma_offset_l1[i];
> > slice_param->delta_chroma_weight_l1[i][0] = sh-
> > >chroma_weight_l1[i][0] - (1 << sh->chroma_log2_weight_denom);
> > slice_param->delta_chroma_weight_l1[i][1] = sh-
> > >chroma_weight_l1[i][1] - (1 << sh->chroma_log2_weight_denom);
> > -slice_param->ChromaOffsetL1[i][0] = sh->chroma_offset_l1[i][0];
> > -slice_param->ChromaOffsetL1[i][1] = sh->chroma_offset_l1[i][1];
> > +if (!is_rext) {
> > +slice_param->luma_offset_l1[i] = sh->luma_offset_l1[i];
> > +slice_param->ChromaOffsetL1[i][0] = sh-
> > >chroma_offset_l1[i][0];
> > +slice_param->ChromaOffsetL1[i][1] = sh-
> > >chroma_offset_l1[i][1];
> > +}
> > }
> > }
> > }
> > @@ -462,7 +473,7 @@ static int vaapi_hevc_decode_slice(AVCodecContext
> *avctx,
> > last_slice_param->RefPicList[list_idx][i] =
> > get_ref_pic_index(h,
> > rpl->ref[i]);
> > }
> >
> > -fill_pred_weight_table(h, sh, last_slice_param);
> > +fill_pred_w
Re: [FFmpeg-devel] [PATCH v1 2/4] lavc/hevcdec: do not let missing ref frames invovled in dpb process
> -Original Message- > From: ffmpeg-devel On Behalf Of > Michael Niedermayer > Sent: Tuesday, June 7, 2022 8:07 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH v1 2/4] lavc/hevcdec: do not let missing > ref > frames invovled in dpb process > > On Tue, Jun 07, 2022 at 03:08:28PM +0800, Fei Wang wrote: > > From: Xu Guangxin > > > > We will generate a new frame for a missed reference. The frame can > > only be used for reference. We assign an invalid decode sequence to > > it, so it will not be involved in any dpb process. > > > > Tested-by: Fei Wang > > Signed-off-by: Xu Guangxin > > --- > > libavcodec/hevc_refs.c | 13 - > > libavcodec/hevcdec.c | 4 ++-- > > libavcodec/hevcdec.h | 3 +++ > > 3 files changed, 17 insertions(+), 3 deletions(-) > > This causes segfaults Thanks Michael, could you share your clip to me? I can't reproduce this with all my clips. Thanks Fei > > Thread 9 "ffmpeg_g" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffcc5ad700 (LWP 14108)] > 0x564b88c0 in ff_emu_edge_vfix19_sse () > (gdb) bt > #0 0x564b88c0 in ff_emu_edge_vfix19_sse () > #1 0x561c515c in emulated_edge_mc_avx2 () > #2 0x55d21bc8 in hls_prediction_unit.isra () > #3 0x55d2420b in hls_coding_quadtree () > #4 0x55d2338d in hls_coding_quadtree () > #5 0x55d25371 in hls_decode_entry () > #6 0x55bd77e5 in avcodec_default_execute () > #7 0x55d2a00f in hevc_decode_frame () > #8 0x55edc5a3 in frame_worker_thread () > #9 0x775fc6db in start_thread (arg=0x7fffcc5ad700) at > pthread_create.c:463 > #10 0x7fffed17061f in clone () > at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I do not agree with what you have to say, but I'll defend to the death your > right > to say it. -- Voltaire ___ ffmpeg-devel mailing list ffmpeg-devel@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 v7 1/2] lavc/vaapi_encode: add support for maxframesize
> -Original Message-
> From: ffmpeg-devel On Behalf Of Fei
> Wang
> Sent: Thursday, May 5, 2022 5:07 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Wang, Fei W ; Linjie Fu
> Subject: [FFmpeg-devel] [PATCH v7 1/2] lavc/vaapi_encode: add support for
> maxframesize
>
> From: Linjie Fu
>
> Add support for max frame size:
> - max_frame_size (bytes) to indicate the max allowed size for frame.
>
> Control each encoded frame size into target limitation size by adjusting whole
> frame's average QP value. The driver will use multi passes to adjust average
> QP
> setp by step to achieve the target, and the result may not strictly
> guaranteed.
> Frame size may exceed target alone with using the maximum average QP value.
> The failure always happens on the intra(especially the first intra frame of a
> new
> GOP) frames or set max_frame_size with a very small number.
>
> example cmdline:
> ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
> -v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
> -c:v h264_vaapi -profile:v main -g 30 -rc_mode VBR -b:v 500k \
> -bf 3 -max_frame_size 4 -vframes 100 -y ./max_frame_size.h264
>
> Max frame size was enabled since VA-API version (0, 33, 0), but query is
> available
> since (1, 5, 0). It will be passed as a parameter in picParam and should be
> set for
> each frame.
>
> Signed-off-by: Linjie Fu
> Signed-off-by: Fei Wang
> ---
> update:
> 1. return error when fail to set max frame size.
> 2. refine commit and debug message.
>
> libavcodec/vaapi_encode.c | 74
> +++
> libavcodec/vaapi_encode.h | 10 +-
> 2 files changed, 83 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c index
> 0e2f5ed447..284ce29888 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -365,6 +365,17 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
> goto fail;
> }
>
> +#if VA_CHECK_VERSION(1, 5, 0)
> +if (ctx->max_frame_size) {
> +err = vaapi_encode_make_misc_param_buffer(avctx, pic,
> +
> VAEncMiscParameterTypeMaxFrameSize,
> + >mfs_params,
> + sizeof(ctx->mfs_params));
> +if (err < 0)
> +goto fail;
> +}
> +#endif
> +
> if (pic->type == PICTURE_TYPE_IDR) {
> if (ctx->va_packed_headers & VA_ENC_PACKED_HEADER_SEQUENCE &&
> ctx->codec->write_sequence_header) { @@ -1869,6 +1880,63 @@
> rc_mode_found:
> return 0;
> }
>
> +static av_cold int vaapi_encode_init_max_frame_size(AVCodecContext
> +*avctx) { #if VA_CHECK_VERSION(1, 5, 0)
> +VAAPIEncodeContext *ctx = avctx->priv_data;
> +VAConfigAttrib attr = { VAConfigAttribMaxFrameSize };
> +VAStatus vas;
> +
> +if (ctx->va_rc_mode == VA_RC_CQP) {
> +ctx->max_frame_size = 0;
> +av_log(avctx, AV_LOG_ERROR, "Max frame size is invalid in CQP rate "
> + "control mode.\n");
> +return AVERROR(EINVAL);
> +}
> +
> +vas = vaGetConfigAttributes(ctx->hwctx->display,
> +ctx->va_profile,
> +ctx->va_entrypoint,
> +, 1);
> +if (vas != VA_STATUS_SUCCESS) {
> +ctx->max_frame_size = 0;
> +av_log(avctx, AV_LOG_ERROR, "Failed to query max frame size "
> + "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> +return AVERROR_EXTERNAL;
> +}
> +
> +if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> +ctx->max_frame_size = 0;
> +av_log(avctx, AV_LOG_ERROR, "Max frame size attribute "
> + "is not supported.\n");
> +return AVERROR(EINVAL);
> +} else {
> +VAConfigAttribValMaxFrameSize attr_mfs;
> +attr_mfs.value = attr.value;
> +// Prefer to use VAEncMiscParameterTypeMaxFrameSize for max frame
> size.
> +if (!attr_mfs.bits.max_frame_size && attr_mfs.bits.multiple_pass) {
> +ctx->max_frame_size = 0;
> +av_log(avctx, AV_LOG_ERROR, "Driver only supports multiple pass "
> + "max frame size which has not been implemented in
> FFmpeg.\n");
> +return AVERROR(EINVAL);
> +}
> +
> +ctx->mfs_params = (VAEnc
Re: [FFmpeg-devel] [PATCH v6 1/2] lavc/vaapi_encode: add support for maxframesize
> -Original Message-
> From: ffmpeg-devel On Behalf Of Mark
> Thompson
> Sent: Saturday, April 30, 2022 10:56 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v6 1/2] lavc/vaapi_encode: add support for
> maxframesize
>
> On 29/04/2022 08:31, Fei Wang wrote:
> > From: Linjie Fu
> >
> > Add support for max frame size:
> > - max_frame_size (bytes) to indicate the max allowed size for frame.
> >
> > If the frame size exceeds the limitation, encoder will to control the
> > frame size by adjusting QP value.
> >
> > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
> > -v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
> > -c:v h264_vaapi -profile:v main -g 30 -rc_mode VBR -b:v 500k \
> > -bf 3 -max_frame_size 4 -vframes 100 -y
> > ./max_frame_size.h264
>
> Can you give some more explanation of the circumstances in which this is
> expected to work in?
>
> For example, I tried a simple test I gave the Intel (gen9, iHD) H.264 encoder
> white noise.
>
> At QP 51 I get:
>
> $ ./ffmpeg_g -v 55 -y -f rawvideo -video_size 1280x720 -pixel_format nv12 -
> framerate 30 -i /dev/urandom -an -init_hw_device vaapi:/dev/dri/renderD128 -
> vf hwupload -c:v h264_vaapi -g 0 -qp 51 -f null - 2>&1 | grep 'Output buffer:'
> [h264_vaapi @ 0x557de0809640] Output buffer: 190975 bytes (status
> 0133).
> [h264_vaapi @ 0x557de0809640] Output buffer: 191265 bytes (status
> 0133).
> [h264_vaapi @ 0x557de0809640] Output buffer: 191825 bytes (status
> 0133).
> [h264_vaapi @ 0x557de0809640] Output buffer: 191893 bytes (status
> 0133).
> [h264_vaapi @ 0x557de0809640] Output buffer: 191746 bytes (status
> 0133).
>
> So I should be able to set the max_frame_size to 20 (with a corresponding
> bitrate target of 30*20*8 = 48M) and it will respect that?
>
> $ ./ffmpeg_g -v 55 -y -f rawvideo -video_size 1280x720 -pixel_format nv12 -
> framerate 30 -i /dev/urandom -an -init_hw_device vaapi:/dev/dri/renderD128 -
> vf hwupload -c:v h264_vaapi -g 0 -b:v 48M -max_frame_size 20 -f null -
> 2>&1 | grep 'Output buffer:'
> [h264_vaapi @ 0x5566f49b7580] Output buffer: 204360 bytes (status 0433).
> [h264_vaapi @ 0x5566f49b7580] Output buffer: 201899 bytes (status 0433).
> [h264_vaapi @ 0x5566f49b7580] Output buffer: 194869 bytes (status 0233).
> [h264_vaapi @ 0x5566f49b7580] Output buffer: 191128 bytes (status 0133).
> [h264_vaapi @ 0x5566f49b7580] Output buffer: 191348 bytes (status 0133).
>
> But it still has some convergence delay, which really isn't what I expect
> from an
> absolute option like max_frame_size.
>
> (The 0400 in 0433 is
> VA_CODED_BUF_STATUS_NUMBER_PASSES_MASK (0xf00), indicating that
> it took four (!) passes across the frame and still didn't achieve the target
> we
> know is possible from the previous test.)
>
> For a less artificial setup, I tried some 4K test streams. For example:
>
> $ ./ffmpeg_g -v 55 -y -i ~/video/test/LG\ New\ York\ HDR\ UHD\ 4K\ Demo.ts -
> an -init_hw_device vaapi:/dev/dri/renderD128 -vf 'format=nv12,hwupload' -c:v
> h264_vaapi -b:v 24M -max_frame_size 10 out.mp4 2>&1 | grep 'Output
> buffer:' | nl | tee out ...
> $ cat out | awk '{ if ($7 > 10) { print } }'
> 308 [h264_vaapi @ 0x5653126613c0] Output buffer: 118390 bytes (status
> 0433).
> 361 [h264_vaapi @ 0x5653126613c0] Output buffer: 139404 bytes (status
> 042d).
> 481 [h264_vaapi @ 0x5653126613c0] Output buffer: 117728 bytes (status
> 0433).
> 601 [h264_vaapi @ 0x5653126613c0] Output buffer: 117328 bytes (status
> 0432).
> 721 [h264_vaapi @ 0x5653126613c0] Output buffer: 124737 bytes (status
> 042d).
> 841 [h264_vaapi @ 0x5653126613c0] Output buffer: 109479 bytes (status
> 042a).
> 961 [h264_vaapi @ 0x5653126613c0] Output buffer: 128128 bytes (status
> 042b).
>1081 [h264_vaapi @ 0x5653126613c0] Output buffer: 103071 bytes (status
> 0431).
>1201 [h264_vaapi @ 0x5653126613c0] Output buffer: 115270 bytes (status
> 0430).
>1321 [h264_vaapi @ 0x5653126613c0] Output buffer: 154613 bytes (status
> 0430).
>1406 [h264_vaapi @ 0x5653126613c0] Output buffer: 114548 bytes (status
> 0432).
>1441 [h264_vaapi @ 0x5653126613c0] Output buffer: 133374 bytes (status
> 0433).
>1561 [h264_vaapi @ 0x5653126613c0] Output buffer: 150675 bytes (status
> 042f).
>1681 [h264_vaapi @ 0x5653126613c0] Output buffer: 119443 bytes (status
> 042a).
>
> (With average QPs there indicating that it's usually nowhere near 51 when it
> misses the target. Most of those failures are on GOP-start intra frames
> (default
> GOP size is 120), but not all of them.)
>
> > Max frame size was enabled since VA-API version (0, 33, 0), but query
> > is available since (1, 5, 0). It will be passed as a parameter in
> > picParam and should be set for each frame.
> >
> > Signed-off-by: Linjie Fu
> >
Re: [FFmpeg-devel] [PATCH v5 1/2] lavc/vaapi_encode: add support for maxframesize
> -Original Message-
> From: Xiang, Haihao
> Sent: Friday, April 29, 2022 1:18 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Wang, Fei W ; linjie...@intel.com
> Subject: Re: [FFmpeg-devel] [PATCH v5 1/2] lavc/vaapi_encode: add support for
> maxframesize
>
> On Fri, 2022-04-22 at 13:36 +0800, Fei Wang wrote:
> > From: Linjie Fu
> >
> > Add support for max frame size:
> > - max_frame_size (bytes) to indicate the max allowed size for frame.
> >
> > If the frame size exceeds the limitation, encoder will to control the
> > frame size by adjusting QP value.
> >
> > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
> > -v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
> > -c:v h264_vaapi -profile:v main -g 30 -rc_mode VBR -b:v 500k \
> > -bf 3 -max_frame_size 4 -vframes 100 -y
> > ./max_frame_size.h264
> >
> > Max frame size was enabled since VA-API version (0, 33, 0), but query
> > is available since (1, 5, 0). It will be passed as a parameter in
> > picParam and should be set for each frame.
> >
> > Signed-off-by: Linjie Fu
> > Signed-off-by: Fei Wang
> > ---
> > Change:
> > 1. use VAEncMiscParameterTypeMaxFrameSize to set max frame
> > parameters, which is a more generic way.
> >
> > libavcodec/vaapi_encode.c | 65
> > +++
> > libavcodec/vaapi_encode.h | 10 +-
> > 2 files changed, 74 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index 0e2f5ed447..c2a39bc4ed 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -365,6 +365,17 @@ static int vaapi_encode_issue(AVCodecContext
> *avctx,
> > goto fail;
> > }
> >
> > +#if VA_CHECK_VERSION(1, 5, 0)
> > +if (ctx->max_frame_size) {
> > +err = vaapi_encode_make_misc_param_buffer(avctx, pic,
> > +
> > +VAEncMiscParameterTypeMaxFr
> > ameSize,
> > + >mfs_params,
> > + sizeof(ctx->mfs_params));
> > +if (err < 0)
> > +goto fail;
> > +}
> > +#endif
> > +
> > if (pic->type == PICTURE_TYPE_IDR) {
> > if (ctx->va_packed_headers & VA_ENC_PACKED_HEADER_SEQUENCE &&
> > ctx->codec->write_sequence_header) { @@ -1869,6 +1880,54
> > @@ rc_mode_found:
> > return 0;
> > }
> >
> > +static av_cold int vaapi_encode_init_max_frame_size(AVCodecContext
> > +*avctx) { #if VA_CHECK_VERSION(1, 5, 0)
> > +VAAPIEncodeContext *ctx = avctx->priv_data;
> > +VAConfigAttrib attr = { VAConfigAttribMaxFrameSize };
> > +VAStatus vas;
> > +
> > +vas = vaGetConfigAttributes(ctx->hwctx->display,
> > +ctx->va_profile,
> > +ctx->va_entrypoint,
> > +, 1);
> > +if (vas != VA_STATUS_SUCCESS) {
> > +ctx->max_frame_size = 0;
> > +av_log(avctx, AV_LOG_ERROR, "Failed to query max frame size "
> > + "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> > +return AVERROR_EXTERNAL;
> > +}
> > +
> > +if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> > +ctx->max_frame_size = 0;
> > +av_log(avctx, AV_LOG_WARNING, "Max frame size attribute "
> > + "is not supported.\n");
> > +} else {
> > +VAConfigAttribValMaxFrameSize attr_mfs;
> > +attr_mfs.value = attr.value;
> > +// Prefer to use VAEncMiscParameterTypeMaxFrameSize for max
> > + frame
> > size.
> > +if (!attr_mfs.bits.max_frame_size && attr_mfs.bits.multiple_pass) {
> > +ctx->max_frame_size = 0;
> > +av_log(avctx, AV_LOG_WARNING, "Driver only support
> > + multiple pass
> > "
> > + "max frame size which have not been implemented in
> > FFmpeg.\n");
> > +return 0;
> > +}
> > +
> > +ctx->mfs_params = (VAEncMiscParameterBufferMaxFrameSize){
> > +.max_frame_size = ctx->max_frame_size * 8,
> > +};
> > +
> > +av_log(avctx, AV_LOG_VERBOSE, "Max Frame Size: %d bytes.\n",
> > +
Re: [FFmpeg-devel] [PATCH v4 1/2] lavc/vaapi_encode: add support for maxframesize
> -Original Message-
> From: Xiang, Haihao
> Sent: Tuesday, March 29, 2022 8:07 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Wang, Fei W ; linjie...@intel.com
> Subject: Re: [FFmpeg-devel] [PATCH v4 1/2] lavc/vaapi_encode: add support for
> maxframesize
>
> On Tue, 2022-03-22 at 22:11 +0800, Fei Wang wrote:
> > From: Linjie Fu
> >
> > Add support for max frame size:
> > - max_frame_size (bytes) to indicate the max allowed size for frame.
> >
> > If the frame size exceeds the limitation, encoder will to control the
> > frame size by adjusting QP value.
> > - MFS_NUM_PASSES to indicate number of passes for QP adjust.
> > - MFS_DELTA_QP to indicate adjust qp value per pass.
> >
> > To simplify the usage, default QP adjust is set to delta_qp[4] = {1, 1, 1,
> > 1}.
> > Use new_qp for encoder if frame size exceeds the limitation:
> > new_qp = base_qp + delta_qp[0] + delta_qp[1] + ...
> >
> > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
> > -v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
> > -c:v h264_vaapi -profile:v main -g 30 -bf 3 -max_frame_size 4 \
> > -vframes 100 -y ./max_frame_size.h264
> >
> > Max frame size was enabled since VA-API version (1, 3, 0), but query
> > is available since (1, 5, 0). It will be passed as a parameter in
> > picParam and should be set for each frame.
> >
> > Signed-off-by: Linjie Fu
> > Signed-off-by: Fei Wang
> > ---
> > 1. re-send the 2 legacy patch:
> >
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20190715105936.4860-1-
> linjie...@intel.com/
> >
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/2019071511.5069-1-
> linjie...@intel.com/
> >
> > libavcodec/vaapi_encode.c | 67
> > +++
> > libavcodec/vaapi_encode.h | 19 +--
> > 2 files changed, 84 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index ffd6cb1c25..b2782e6f9e 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -365,6 +365,17 @@ static int vaapi_encode_issue(AVCodecContext
> *avctx,
> > goto fail;
> > }
> >
> > +#if VA_CHECK_VERSION(1, 5, 0)
> > +if (ctx->max_frame_size) {
> > +err = vaapi_encode_make_misc_param_buffer(avctx, pic,
> > +
> > +VAEncMiscParameterTypeMultiPassFr
> > ameSize,
> > +>mfs_params,
> > +sizeof(ctx->mfs_params));
> > +if (err < 0)
> > +goto fail;
> > +}
> > +#endif
> > +
> > if (pic->type == PICTURE_TYPE_IDR) {
> > if (ctx->va_packed_headers & VA_ENC_PACKED_HEADER_SEQUENCE &&
> > ctx->codec->write_sequence_header) { @@ -1869,6 +1880,54
> > @@ rc_mode_found:
> > return 0;
> > }
> >
> > +static av_cold int vaapi_encode_init_max_frame_size(AVCodecContext
> > +*avctx) { #if VA_CHECK_VERSION(1, 5, 0)
> > +VAAPIEncodeContext *ctx = avctx->priv_data;
> > +VAConfigAttrib attr = { VAConfigAttribMaxFrameSize };
> > +VAStatus vas;
> > +int i;
> > +
> > +vas = vaGetConfigAttributes(ctx->hwctx->display,
> > +ctx->va_profile,
> > +ctx->va_entrypoint,
> > +, 1);
> > +if (vas != VA_STATUS_SUCCESS) {
> > +ctx->max_frame_size = 0;
> > +av_log(avctx, AV_LOG_ERROR, "Failed to query max frame size "
> > + "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
> > +return AVERROR_EXTERNAL;
> > +}
> > +
> > +if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> > +ctx->max_frame_size = 0;
> > +av_log(avctx, AV_LOG_WARNING, "Max frame size attribute "
> > + "is not supported.\n");
> > +} else {
> > +ctx->delta_qp = av_calloc(MFS_NUM_PASSES, sizeof(uint8_t));
> > +if (!ctx->delta_qp) {
> > +return AVERROR(ENOMEM);
> > +}
> > +for (i = 0; i > +ctx->delta_qp[i] = MFS_DELTA_QP;
> > +
> > +ctx->mfs_params = (VAEncMiscParameterBufferMultiPassFrameSize){
> > +.max_frame_size = ctx->max_frame_size,
> >
Re: [FFmpeg-devel] [PATCH v4 1/2] lavc/vaapi_encode: add support for maxframesize
> -Original Message-
> From: Andriy Gelman
> Sent: Saturday, March 26, 2022 11:21 PM
> To: Wang, Fei W
> Cc: ffmpeg-devel@ffmpeg.org
> Subject: Re: [PATCH v4 1/2] lavc/vaapi_encode: add support for maxframesize
>
> On Wed, 23. Mar 08:51, Wang, Fei W wrote:
> > > -Original Message-
> > > From: Wang, Fei W
> > > Sent: Tuesday, March 22, 2022 10:11 PM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Linjie Fu ; Wang, Fei W
> > >
> > > Subject: [PATCH v4 1/2] lavc/vaapi_encode: add support for
> > > maxframesize
> > >
> > > From: Linjie Fu
> > >
> > > Add support for max frame size:
> > > - max_frame_size (bytes) to indicate the max allowed size for frame.
> > >
> > > If the frame size exceeds the limitation, encoder will to control
> > > the frame size by adjusting QP value.
> > > - MFS_NUM_PASSES to indicate number of passes for QP adjust.
> > > - MFS_DELTA_QP to indicate adjust qp value per pass.
> > >
> > > To simplify the usage, default QP adjust is set to delta_qp[4] = {1, 1,
> > > 1, 1}.
> > > Use new_qp for encoder if frame size exceeds the limitation:
> > > new_qp = base_qp + delta_qp[0] + delta_qp[1] + ...
> > >
> > > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
> > > -v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
> > > -c:v h264_vaapi -profile:v main -g 30 -bf 3 -max_frame_size 4
> > > \
> > > -vframes 100 -y ./max_frame_size.h264
> > >
> > > Max frame size was enabled since VA-API version (1, 3, 0), but query
> > > is available since (1, 5, 0). It will be passed as a parameter in
> > > picParam and should be set for each frame.
> > >
> > > Signed-off-by: Linjie Fu
> > > Signed-off-by: Fei Wang
> > > ---
> > > 1. re-send the 2 legacy patch:
> > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20190715105936.486
> > > 0-1-
> > > linjie...@intel.com/
> > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/2019071511.506
> > > 9-1-
> > > linjie...@intel.com/
> > >
> > > libavcodec/vaapi_encode.c | 67
> > > +++
> > > libavcodec/vaapi_encode.h | 19 +--
> > > 2 files changed, 84 insertions(+), 2 deletions(-)
>
> Hi,
>
> >
> > Hi Andriy,
> >
> > Is there any way to know the details of failure for this patch? Like
> > OS, configuration, gcc version, etc. It looks good on my local Ubuntu with
> > gcc
> 9.3, but show fails in patchwork checks:
> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220322141119.59562
> > 7-1-fei.w.w...@intel.com/
> >
>
> I don't think it was a real issue. I was upgrading the x86 runner at the time.
Thanks for your confirmation.
@Haihao, could you help to review this patchset? Thanks.
Thanks
Fei
>
> --
> Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@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] lavc/vaapi_encode: add support for maxframesize
> -Original Message-
> From: Wang, Fei W
> Sent: Tuesday, March 22, 2022 10:11 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Linjie Fu ; Wang, Fei W
> Subject: [PATCH v4 1/2] lavc/vaapi_encode: add support for maxframesize
>
> From: Linjie Fu
>
> Add support for max frame size:
> - max_frame_size (bytes) to indicate the max allowed size for frame.
>
> If the frame size exceeds the limitation, encoder will to control the frame
> size by
> adjusting QP value.
> - MFS_NUM_PASSES to indicate number of passes for QP adjust.
> - MFS_DELTA_QP to indicate adjust qp value per pass.
>
> To simplify the usage, default QP adjust is set to delta_qp[4] = {1, 1, 1, 1}.
> Use new_qp for encoder if frame size exceeds the limitation:
> new_qp = base_qp + delta_qp[0] + delta_qp[1] + ...
>
> ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
> -v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
> -c:v h264_vaapi -profile:v main -g 30 -bf 3 -max_frame_size 4 \
> -vframes 100 -y ./max_frame_size.h264
>
> Max frame size was enabled since VA-API version (1, 3, 0), but query is
> available
> since (1, 5, 0). It will be passed as a parameter in picParam and should be
> set for
> each frame.
>
> Signed-off-by: Linjie Fu
> Signed-off-by: Fei Wang
> ---
> 1. re-send the 2 legacy patch:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20190715105936.4860-1-
> linjie...@intel.com/
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/2019071511.5069-1-
> linjie...@intel.com/
>
> libavcodec/vaapi_encode.c | 67
> +++
> libavcodec/vaapi_encode.h | 19 +--
> 2 files changed, 84 insertions(+), 2 deletions(-)
Hi Andriy,
Is there any way to know the details of failure for this patch? Like OS,
configuration,
gcc version, etc. It looks good on my local Ubuntu with gcc 9.3, but show fails
in patchwork checks:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220322141119.595627-1-fei.w.w...@intel.com/
Fei
Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 1/4] lavc/vaapi_encode_h265: Add GPB frame support for hevc_vaapi
> -Original Message-
> From: ffmpeg-devel On Behalf Of Xiang,
> Haihao
> Sent: Monday, March 14, 2022 10:15 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v4 1/4] lavc/vaapi_encode_h265: Add GPB
> frame support for hevc_vaapi
>
> On Sun, 2022-03-13 at 20:45 +, Mark Thompson wrote:
> > On 11/03/2022 09:00, Fei Wang wrote:
> > > From: Linjie Fu
> > >
> > > Use GPB frames to replace regular P/B frames if backend driver does
> > > not support it.
> > >
> > > - GPB:
> > > Generalized P and B picture. Regular P/B frames replaced by B
> > > frames with previous-predict only, L0 == L1. Normal B frames
> > > still have 2 different ref_lists and allow bi-prediction
> > >
> > > Signed-off-by: Linjie Fu
> > > Signed-off-by: Fei Wang
> > > ---
> > > update:
> > > 1. Add b to gpb.
> > > 2. Optimise debug message.
> > >
> > > libavcodec/vaapi_encode.c | 74 +++--
> -
> > > libavcodec/vaapi_encode.h | 2 +
> > > libavcodec/vaapi_encode_h265.c | 24 ++-
> > > 3 files changed, 93 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > > index 3bf379b1a0..bdba9726b2 100644
> > > --- a/libavcodec/vaapi_encode.c
> > > +++ b/libavcodec/vaapi_encode.c
> > > @@ -848,9 +848,13 @@ static void
> > > vaapi_encode_set_b_pictures(AVCodecContext
> > > *avctx,
> > > pic->b_depth = current_depth;
> > >
> > > vaapi_encode_add_ref(avctx, pic, start, 1, 1, 0);
> > > -vaapi_encode_add_ref(avctx, pic, end, 1, 1, 0);
> > > vaapi_encode_add_ref(avctx, pic, prev, 0, 0, 1);
> > >
> > > +if (!ctx->b_to_gpb)
> > > +vaapi_encode_add_ref(avctx, pic, end, 1, 1, 0);
> > > +else
> > > +vaapi_encode_add_ref(avctx, pic, end, 0, 1, 0);
> >
> > This is doing something extremely dubious. If b-to-gpb is set, then
> > don't use the future reference?
>
> According to
> https://github.com/intel/media-
> driver/blob/master/media_driver/agnostic/common/codec/hal/codechal_vdenc
> _hevc.cpp#L3072-L3087
> , L0 and L1 should be the same for vdenc hevc on some platforms, so user can't
> use past and future reference together, which is why you experienced the
> failure
> after applying version 2
>
> Thanks
> Haihao
>
>
> > That means these pictures will only have the past reference, and the
> > coding efficiency will often be much worse.
> >
> > E.g. if you have the default structure (max_b_frames = 2, max_b_depth
> > = 1) then in a sequence of four pictures you get:
> >
> > 1 referring to something previous
> > 4 referring to 1
> > 2 referring to 1 and 4
> > 3 referring to 1 and 4
> >
> > and this change means you lose the 2 -> 4 and 3 -> 4 references.
> > Therefore, a change in the picture between 1 and 2 will end up coded
> > three times in 2, 3 and 4 rather than just being coded in 4 and then
> > referred to
> by the others.
If driver doesn't support B frames with two different reference lists, use gpb
instead
of regular B is a best way. In V3, I turned B frames to P, but this will break
gop structure.
If user set I/P/B frames, while the output only contains I/P frames will be
much confuse.
> >
> > > +
> > > for (ref = end->refs[1]; ref; ref = ref->refs[1])
> > > vaapi_encode_add_ref(avctx, pic, ref, 0, 1, 0);
> > > }
> > > @@ -871,8 +875,11 @@ static void
> > > vaapi_encode_set_b_pictures(AVCodecContext
> > > *avctx,
> > >
> > > vaapi_encode_add_ref(avctx, pic, pic, 0, 1, 0);
> > > vaapi_encode_add_ref(avctx, pic, start, 1, 1, 0);
> > > -vaapi_encode_add_ref(avctx, pic, end, 1, 1, 0);
> > > vaapi_encode_add_ref(avctx, pic, prev, 0, 0, 1);
> > > +if (!ctx->b_to_gpb)
> > > +vaapi_encode_add_ref(avctx, pic, end, 1, 1, 0);
> > > +else
> > > +vaapi_encode_add_ref(avctx, pic, end, 0, 1, 0);
> > >
> > > for (ref = end->refs[1]; ref; ref = ref->refs[1])
> > > vaapi_encode_add_ref(avctx, pic, ref, 0, 1, 0); @@
> > > -1845,6 +1852,51 @@ static av_cold int
> > > vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> > > ref_l1 = attr.value >> 16 & 0x;
> > > }
> > >
> > > +ctx->p_to_gpb = 0;
> > > +ctx->b_to_gpb = 0;
> > > +
> > > +#if VA_CHECK_VERSION(1, 9, 0)
> > > +if (!(ctx->codec->flags & FLAG_INTRA_ONLY ||
> > > +avctx->gop_size <= 1)) {
> > > +attr = (VAConfigAttrib) { VAConfigAttribPredictionDirection };
> > > +vas = vaGetConfigAttributes(ctx->hwctx->display,
> > > +ctx->va_profile,
> > > +ctx->va_entrypoint,
> > > +, 1);
> > > +if (vas != VA_STATUS_SUCCESS) {
> > > +av_log(avctx, AV_LOG_WARNING, "Failed to query
> > > +prediction
> > > direction "
> > >
Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi
On Wed, 2022-02-23 at 13:33 +, Wang, Fei W wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Wang, > > Fei W > > Sent: Tuesday, February 22, 2022 4:49 PM > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: > > Add P > > frame to GPB frame support for hevc_vaapi > > > > On Tue, 2022-02-22 at 05:46 +, Xiang, Haihao wrote: > > > On Mon, 2022-02-21 at 12:06 +, Mark Thompson wrote: > > > > On 21/02/2022 02:13, Fei Wang wrote: > > > > > From: Linjie Fu > > > > > > > > > > Use GPB frames to replace regular P frames if backend driver > > > > > does > > > > > not support it. > > > > > > > > > > - GPB: > > > > > Generalized P and B picture. P frames replaced by B > > > > > frames > > > > > with > > > > > forward-predict only, L0 == L1. Normal B frames still > > > > > have 2 > > > > > different ref_lists and allow bi-prediction > > > > > > > > > > Signed-off-by: Linjie Fu > > > > > Signed-off-by: Fei Wang > > > > > --- > > > > > libavcodec/vaapi_encode.c | 33 > > > > > +++-- > > > > > libavcodec/vaapi_encode.h | 1 + > > > > > libavcodec/vaapi_encode_h265.c | 15 +++ > > > > > 3 files changed, 47 insertions(+), 2 deletions(-) > > > > > > > > This always fails immediately on current iHD > > > > (7e357b4bea76b2fe2522e6af41ae02ea69cec49e): > > > > > > > > $ ./ffmpeg_g -v 44 -y -hwaccel vaapi -hwaccel_output_format > > > > vaapi -i > > > > in.mp4 -an -c:v hevc_vaapi -low_power 1 out.mp4 ... > > > > [hevc_vaapi @ 0x560e81d45e80] Using input frames context > > > > (format > > > > vaapi) with > > > > hevc_vaapi encoder. > > > > [hevc_vaapi @ 0x560e81d45e80] Input surface format is nv12. > > > > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI profile > > > > VAProfileHEVCMain > > > > (17). > > > > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI entrypoint > > > > VAEntrypointEncSliceLP (8). > > > > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI render target format > > > > YUV420 (0x1). > > > > [hevc_vaapi @ 0x560e81d45e80] Using CTU size 64x64, min CB size > > > > 8x8. > > > > [hevc_vaapi @ 0x560e81d45e80] No quality level set; using > > > > default > > > > (25). > > > > [hevc_vaapi @ 0x560e81d45e80] RC mode: CQP. > > > > [hevc_vaapi @ 0x560e81d45e80] RC quality: 25. > > > > [hevc_vaapi @ 0x560e81d45e80] RC framerate: 3/1001 (29.97 > > > > fps). > > > > [hevc_vaapi @ 0x560e81d45e80] Use GPB B frames to replace > > > > regular P > > > > frames. > > > > [hevc_vaapi @ 0x560e81d45e80] Using intra, GPB-B-frames and B- > > > > frames (supported references: 3 / 3). > > > > [hevc_vaapi @ 0x560e81d45e80] All wanted packed headers > > > > available > > > > (wanted 0xd, found 0x1f). > > > > [hevc_vaapi @ 0x560e81d45e80] Using level 4. > > > > ... > > > > [hevc_vaapi @ 0x560e81d45e80] Failed to end picture encode > > > > issue: > > > > 24 (internal > > > > encoding error). > > > > [hevc_vaapi @ 0x560e81d45e80] Encode failed: -5. > > > > Video encoding failed > > > > ... > > > > $ cat /proc/cpuinfo | grep 'model name' | head -1 > > > > model name : Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz > > > > $ uname -v > > > > #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) > > > > > > > > Do you get this too, or is your setup different somehow? > > > > > > Hi Mark, > > > > > > I tested this patchset with iHD > > > (7e357b4bea76b2fe2522e6af41ae02ea69cec49e) on CFL (low_power=0), > > > RKL > > > and DG1, i965 on SKL, and didn't see this issue before. > > > This day I reproduced this issue on ICL. It seems iHD driver > > > doesn't > > > return right values for ICL. > > > > Thanks Mark to report this issue on ICL. > > > > I tested on TGL and CFL before submitted this patch set, all looks > > good. I will > > check why this fail o
Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi
> -Original Message-
> From: ffmpeg-devel On Behalf Of Wang,
> Fei W
> Sent: Tuesday, February 22, 2022 4:49 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P
> frame to GPB frame support for hevc_vaapi
>
> On Tue, 2022-02-22 at 05:46 +, Xiang, Haihao wrote:
> > On Mon, 2022-02-21 at 12:06 +, Mark Thompson wrote:
> > > On 21/02/2022 02:13, Fei Wang wrote:
> > > > From: Linjie Fu
> > > >
> > > > Use GPB frames to replace regular P frames if backend driver does
> > > > not support it.
> > > >
> > > > - GPB:
> > > > Generalized P and B picture. P frames replaced by B frames
> > > > with
> > > > forward-predict only, L0 == L1. Normal B frames still have 2
> > > > different ref_lists and allow bi-prediction
> > > >
> > > > Signed-off-by: Linjie Fu
> > > > Signed-off-by: Fei Wang
> > > > ---
> > > > libavcodec/vaapi_encode.c | 33
> > > > +++--
> > > > libavcodec/vaapi_encode.h | 1 +
> > > > libavcodec/vaapi_encode_h265.c | 15 +++
> > > > 3 files changed, 47 insertions(+), 2 deletions(-)
> > >
> > > This always fails immediately on current iHD
> > > (7e357b4bea76b2fe2522e6af41ae02ea69cec49e):
> > >
> > > $ ./ffmpeg_g -v 44 -y -hwaccel vaapi -hwaccel_output_format vaapi -i
> > > in.mp4 -an -c:v hevc_vaapi -low_power 1 out.mp4 ...
> > > [hevc_vaapi @ 0x560e81d45e80] Using input frames context (format
> > > vaapi) with
> > > hevc_vaapi encoder.
> > > [hevc_vaapi @ 0x560e81d45e80] Input surface format is nv12.
> > > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI profile VAProfileHEVCMain
> > > (17).
> > > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI entrypoint
> > > VAEntrypointEncSliceLP (8).
> > > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI render target format
> > > YUV420 (0x1).
> > > [hevc_vaapi @ 0x560e81d45e80] Using CTU size 64x64, min CB size 8x8.
> > > [hevc_vaapi @ 0x560e81d45e80] No quality level set; using default
> > > (25).
> > > [hevc_vaapi @ 0x560e81d45e80] RC mode: CQP.
> > > [hevc_vaapi @ 0x560e81d45e80] RC quality: 25.
> > > [hevc_vaapi @ 0x560e81d45e80] RC framerate: 3/1001 (29.97 fps).
> > > [hevc_vaapi @ 0x560e81d45e80] Use GPB B frames to replace regular P
> > > frames.
> > > [hevc_vaapi @ 0x560e81d45e80] Using intra, GPB-B-frames and B-
> > > frames (supported references: 3 / 3).
> > > [hevc_vaapi @ 0x560e81d45e80] All wanted packed headers available
> > > (wanted 0xd, found 0x1f).
> > > [hevc_vaapi @ 0x560e81d45e80] Using level 4.
> > > ...
> > > [hevc_vaapi @ 0x560e81d45e80] Failed to end picture encode issue:
> > > 24 (internal
> > > encoding error).
> > > [hevc_vaapi @ 0x560e81d45e80] Encode failed: -5.
> > > Video encoding failed
> > > ...
> > > $ cat /proc/cpuinfo | grep 'model name' | head -1
> > > model name : Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
> > > $ uname -v
> > > #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09)
> > >
> > > Do you get this too, or is your setup different somehow?
> >
> > Hi Mark,
> >
> > I tested this patchset with iHD
> > (7e357b4bea76b2fe2522e6af41ae02ea69cec49e) on CFL (low_power=0), RKL
> > and DG1, i965 on SKL, and didn't see this issue before.
> > This day I reproduced this issue on ICL. It seems iHD driver doesn't
> > return right values for ICL.
>
> Thanks Mark to report this issue on ICL.
>
> I tested on TGL and CFL before submitted this patch set, all looks good. I
> will
> check why this fail on ICL.
>
> And will fix your other comments together in next version.
>
> Fei
> Thanks
>
>
> >
> > > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > > > index 3bf379b1a0..95eca7c288 100644
> > > > --- a/libavcodec/vaapi_encode.c
> > > > +++ b/libavcodec/vaapi_encode.c
> > > > @@ -1845,6 +1845,30 @@ static av_cold int
> > > > vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> > > > ref_l1 = attr.value >> 16 & 0x;
> > > > }
> > > >
> > > > +ctx->p_to_gpb = 0;
> > > > +
> > > > +#if VA_CHECK_VERSION(1, 9, 0)
> > > > +attr = (VAConfigAttrib) { VAConfigAttri
Re: [FFmpeg-devel] [PATCH v2 1/4] lavc/vaapi_encode_h265: Add P frame to GPB frame support for hevc_vaapi
On Tue, 2022-02-22 at 05:46 +, Xiang, Haihao wrote:
> On Mon, 2022-02-21 at 12:06 +, Mark Thompson wrote:
> > On 21/02/2022 02:13, Fei Wang wrote:
> > > From: Linjie Fu
> > >
> > > Use GPB frames to replace regular P frames if backend driver does
> > > not
> > > support it.
> > >
> > > - GPB:
> > > Generalized P and B picture. P frames replaced by B frames
> > > with
> > > forward-predict only, L0 == L1. Normal B frames still have 2
> > > different ref_lists and allow bi-prediction
> > >
> > > Signed-off-by: Linjie Fu
> > > Signed-off-by: Fei Wang
> > > ---
> > > libavcodec/vaapi_encode.c | 33
> > > +++--
> > > libavcodec/vaapi_encode.h | 1 +
> > > libavcodec/vaapi_encode_h265.c | 15 +++
> > > 3 files changed, 47 insertions(+), 2 deletions(-)
> >
> > This always fails immediately on current iHD
> > (7e357b4bea76b2fe2522e6af41ae02ea69cec49e):
> >
> > $ ./ffmpeg_g -v 44 -y -hwaccel vaapi -hwaccel_output_format vaapi
> > -i in.mp4
> > -an -c:v hevc_vaapi -low_power 1 out.mp4
> > ...
> > [hevc_vaapi @ 0x560e81d45e80] Using input frames context (format
> > vaapi) with
> > hevc_vaapi encoder.
> > [hevc_vaapi @ 0x560e81d45e80] Input surface format is nv12.
> > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI profile VAProfileHEVCMain
> > (17).
> > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI entrypoint
> > VAEntrypointEncSliceLP
> > (8).
> > [hevc_vaapi @ 0x560e81d45e80] Using VAAPI render target format
> > YUV420 (0x1).
> > [hevc_vaapi @ 0x560e81d45e80] Using CTU size 64x64, min CB size
> > 8x8.
> > [hevc_vaapi @ 0x560e81d45e80] No quality level set; using default
> > (25).
> > [hevc_vaapi @ 0x560e81d45e80] RC mode: CQP.
> > [hevc_vaapi @ 0x560e81d45e80] RC quality: 25.
> > [hevc_vaapi @ 0x560e81d45e80] RC framerate: 3/1001 (29.97 fps).
> > [hevc_vaapi @ 0x560e81d45e80] Use GPB B frames to replace regular P
> > frames.
> > [hevc_vaapi @ 0x560e81d45e80] Using intra, GPB-B-frames and B-
> > frames
> > (supported references: 3 / 3).
> > [hevc_vaapi @ 0x560e81d45e80] All wanted packed headers available
> > (wanted 0xd,
> > found 0x1f).
> > [hevc_vaapi @ 0x560e81d45e80] Using level 4.
> > ...
> > [hevc_vaapi @ 0x560e81d45e80] Failed to end picture encode issue:
> > 24 (internal
> > encoding error).
> > [hevc_vaapi @ 0x560e81d45e80] Encode failed: -5.
> > Video encoding failed
> > ...
> > $ cat /proc/cpuinfo | grep 'model name' | head -1
> > model name : Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz
> > $ uname -v
> > #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09)
> >
> > Do you get this too, or is your setup different somehow?
>
> Hi Mark,
>
> I tested this patchset with iHD
> (7e357b4bea76b2fe2522e6af41ae02ea69cec49e) on
> CFL (low_power=0), RKL and DG1, i965 on SKL, and didn't see this
> issue before.
> This day I reproduced this issue on ICL. It seems iHD driver doesn't
> return
> right values for ICL.
Thanks Mark to report this issue on ICL.
I tested on TGL and CFL before submitted this patch set, all looks
good. I will check why this fail on ICL.
And will fix your other comments together in next version.
Fei
Thanks
>
> > > diff --git a/libavcodec/vaapi_encode.c
> > > b/libavcodec/vaapi_encode.c
> > > index 3bf379b1a0..95eca7c288 100644
> > > --- a/libavcodec/vaapi_encode.c
> > > +++ b/libavcodec/vaapi_encode.c
> > > @@ -1845,6 +1845,30 @@ static av_cold int
> > > vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> > > ref_l1 = attr.value >> 16 & 0x;
> > > }
> > >
> > > +ctx->p_to_gpb = 0;
> > > +
> > > +#if VA_CHECK_VERSION(1, 9, 0)
> > > +attr = (VAConfigAttrib) { VAConfigAttribPredictionDirection
> > > };
> > > +vas = vaGetConfigAttributes(ctx->hwctx->display,
> > > +ctx->va_profile,
> > > +ctx->va_entrypoint,
> > > +, 1);
> >
> > This probably shouldn't be done at all if the user has selected a
> > codec
> > without B-frames or a configuration which is intra-only, because
> > the log
> > message is confusing:
> >
> > [mjpeg_vaapi @ 0x55b90d72ee00] Driver does not report whether
> > support GPB, use
> > regular P frames.
> > [mjpeg_vaapi @ 0x55b90d72ee00] Using intra frames only.
> >
> > > +if (vas != VA_STATUS_SUCCESS) {
> > > +av_log(avctx, AV_LOG_WARNING, "Failed to query
> > > prediction direction
> > > "
> > > + "attribute: %d (%s).\n", vas, vaErrorStr(vas));
> >
> > And fail?
>
> 4/4 also ignores the error. It would be better to handle the error in
> the same
> way and update 4/4 too.
>
> > > +} else if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
> > > +av_log(avctx, AV_LOG_VERBOSE, "Driver does not report
> > > whether "
> > > + "support GPB, use regular P frames.\n");
> >
> > "support GPB" is a strange thing to say. It's a constraint - any
> > driver which
> > supports B-frames will let you have the same thing in both
Re: [FFmpeg-devel] [PATCH v1 4/4] vaapi_encode_h265: Query encoding block sizes and features
On Fri, 2022-02-18 at 04:38 +, Xiang, Haihao wrote:
> On Fri, 2022-02-18 at 09:43 +0800, Fei Wang wrote:
> > From: Mark Thompson
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/vaapi_encode_h265.c | 107
> > +++--
> > 1 file changed, 102 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode_h265.c
> > b/libavcodec/vaapi_encode_h265.c
> > index 8319848e4a..e98502503d 100644
> > --- a/libavcodec/vaapi_encode_h265.c
> > +++ b/libavcodec/vaapi_encode_h265.c
> > @@ -56,6 +56,9 @@ typedef struct VAAPIEncodeH265Context {
> > VAAPIEncodeContext common;
> >
> > // Encoder features.
> > +uint32_t va_features;
> > +// Block size info.
> > +uint32_t va_bs;
> > uint32_t ctu_size;
> > uint32_t min_cb_size;
> >
> > @@ -427,9 +430,9 @@ static int
> > vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> > vps->vps_max_latency_increase_plus1[i];
> > }
> >
> > -// These have to come from the capabilities of the
> > encoder. We have no
> > -// way to query them, so just hardcode parameters which work
> > on the Intel
> > -// driver.
> > +// These values come from the capabilities of the first
> > encoder
> > +// implementation in the i965 driver on Intel Skylake. They
> > may
> > +// fail badly with other platforms or drivers.
> > // CTB size from 8x8 to 32x32.
> > sps->log2_min_luma_coding_block_size_minus3 = 0;
> > sps->log2_diff_max_min_luma_coding_block_size = 2;
> > @@ -447,6 +450,42 @@ static int
> > vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> >
> > sps->pcm_enabled_flag = 0;
> >
> > +// update sps setting according to queried result
> > +#if VA_CHECK_VERSION(1, 13, 0)
> > +if (priv->va_features) {
> > +VAConfigAttribValEncHEVCFeatures features = { .value =
> > priv-
> > > va_features };
> > +
> > +// Enable feature if get queried result is
> > VA_FEATURE_SUPPORTED |
> > VA_FEATURE_REQUIRED
> > +sps->amp_enabled_flag =
> > +!!features.bits.amp;
> > +sps->sample_adaptive_offset_enabled_flag =
> > +!!features.bits.sao;
> > +sps->sps_temporal_mvp_enabled_flag =
> > +!!features.bits.temporal_mvp;
> > +sps->pcm_enabled_flag =
> > +!!features.bits.pcm;
> > +}
> > +
> > +if (priv->va_bs) {
> > +VAConfigAttribValEncHEVCBlockSizes bs = { .value = priv-
> > >va_bs };
> > +sps->log2_min_luma_coding_block_size_minus3 =
> > +ff_ctz(priv->min_cb_size) - 3;
> > +sps->log2_diff_max_min_luma_coding_block_size =
> > +ff_ctz(priv->ctu_size) - ff_ctz(priv->min_cb_size);
> > +
> > +sps->log2_min_luma_transform_block_size_minus2 =
> > +bs.bits.log2_min_luma_transform_block_size_minus2;
> > +sps->log2_diff_max_min_luma_transform_block_size =
> > +bs.bits.log2_max_luma_transform_block_size_minus2 -
> > +bs.bits.log2_min_luma_transform_block_size_minus2;
> > +
> > +sps->max_transform_hierarchy_depth_inter =
> > +bs.bits.max_max_transform_hierarchy_depth_inter;
> > +sps->max_transform_hierarchy_depth_intra =
> > +bs.bits.max_max_transform_hierarchy_depth_intra;
> > +}
> > +#endif
> > +
> > // STRPSs should ideally be here rather than defined
> > individually in
> > // each slice, but the structure isn't completely fixed so for
> > now
> > // don't bother.
> > @@ -539,6 +578,23 @@ static int
> > vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> > pps->cu_qp_delta_enabled_flag = (ctx->va_rc_mode !=
> > VA_RC_CQP);
> > pps->diff_cu_qp_delta_depth = 0;
> >
> > +// update pps setting according to queried result
> > +#if VA_CHECK_VERSION(1, 13, 0)
> > +if (priv->va_features) {
> > +VAConfigAttribValEncHEVCFeatures features = { .value =
> > priv-
> > > va_features };
> > +if (ctx->va_rc_mode != VA_RC_CQP)
> > +pps->cu_qp_delta_enabled_flag =
> > +!!features.bits.cu_qp_delta;
>
> Please fix the indentation
Thanks Haihao to help review. Fixed in V2.
Thanks
Fei
>
> > +
> > +pps->transform_skip_enabled_flag =
> > +!!features.bits.transform_skip;
> > +// set diff_cu_qp_delta_depth as its max value if
> > cu_qp_delta
> > enabled. Otherwise
> > +// 0 will make cu_qp_delta invalid.
> > +if (pps->cu_qp_delta_enabled_flag)
> > +pps->diff_cu_qp_delta_depth = sps-
> > > log2_diff_max_min_luma_coding_block_size;
> > +}
> > +#endif
> > +
> > if (ctx->tile_rows && ctx->tile_cols) {
> > int uniform_spacing;
> >
> > @@ -640,8 +696,8 @@ static int
> > vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
> >
> > .coded_buf = VA_INVALID_ID,
> >
> > -.collocated_ref_pic_index = 0xff,
> > -
> > +.collocated_ref_pic_index =
Re: [FFmpeg-devel] [PATCH v1] avcodec/av1_parser: ensure only one show frame packed data parsered
On Fri, 2021-12-03 at 09:36 -0300, James Almer wrote:
> On Fri, Dec 3, 2021 at 5:12 AM Fei Wang wrote:
>
> > Split packed data when it contains multiple show frames in some
> > non-standard bitstream. This can benefit downstream decoder which
> > can
> > decode continuously instead of interrupt with unexpected error.
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/av1_parser.c | 19 +++
> > 1 file changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/av1_parser.c b/libavcodec/av1_parser.c
> > index d2dfdb3580..d6f5cace4b 100644
> > --- a/libavcodec/av1_parser.c
> > +++ b/libavcodec/av1_parser.c
> > @@ -59,11 +59,10 @@ static int
> > av1_parser_parse(AVCodecParserContext *ctx,
> > const CodedBitstreamAV1Context *av1 = s->cbc->priv_data;
> > const AV1RawSequenceHeader *seq;
> > const AV1RawColorConfig *color;
> > +int pic_found = 0;
> > +int next = 0;
> > int ret;
> >
> > -*out_data = data;
> > -*out_size = size;
> > -
> > ctx->key_frame = -1;
> > ctx->pict_type = AV_PICTURE_TYPE_NONE;
> > ctx->picture_structure = AV_PICTURE_STRUCTURE_UNKNOWN;
> > @@ -100,6 +99,8 @@ static int av1_parser_parse(AVCodecParserContext
> > *ctx,
> > const AV1RawOBU *obu = unit->content;
> > const AV1RawFrameHeader *frame;
> >
> > +next += unit->data_size;
> > +
> > if (unit->type == AV1_OBU_FRAME)
> > frame = >obu.frame.header;
> > else if (unit->type == AV1_OBU_FRAME_HEADER)
> > @@ -113,6 +114,12 @@ static int
> > av1_parser_parse(AVCodecParserContext *ctx,
> > if (!frame->show_frame && !frame->show_existing_frame)
> > continue;
> >
> > +/* split data if it contains multi show frames */
> > +if (pic_found) {
> > +next -= unit->data_size;
> > +break;
> > +}
> > +
> > ctx->width = frame->frame_width_minus_1 + 1;
> > ctx->height = frame->frame_height_minus_1 + 1;
> >
> > @@ -131,8 +138,12 @@ static int
> > av1_parser_parse(AVCodecParserContext *ctx,
> > break;
> > }
> > ctx->picture_structure = AV_PICTURE_STRUCTURE_FRAME;
> > +pic_found = 1;
> > }
> >
> > +*out_size = next;
> > +*out_data = data;
> > +
> > switch (av1->bit_depth) {
> > case 8:
> > ctx->format = color->mono_chrome ? AV_PIX_FMT_GRAY8
> > @@ -171,7 +182,7 @@ end:
> >
> > s->cbc->log_ctx = NULL;
> >
> > -return size;
> > +return next;
> > }
> >
> > static const CodedBitstreamUnitType decompose_unit_types[] = {
> > --
> > 2.25.1
> >
> >
> No, the parser must not split the packets. We used to do this with
> the VP9
> parser and the result was the creation of broken output files.
Any more information on failed case for vp9? I tested this patch by
decoding several av1 bitstream, all looks good.
And I checked wm4's change on vp9/vp9_parser, the commit only shows it
benefits on multi-thread decoding. So I guess if vp9 failed case is
related to multi-thread decodeing? If yes, then insert frame_split bsf
in av1 decoder will be a better choice. Even av1 decoder doesn't
support multi-threading decode now, it can avoid issue if it is
supported someday.
>
> What you could do instead is autoinsert the frame_split BSF in the
> decoder,
> same as we're doing for VP9. It should have the same effect.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 v1] avcodec/av1_parser: ensure only one show frame packed data parsered
On Fri, 2021-12-03 at 11:51 +0100, Michael Niedermayer wrote: > On Fri, Dec 03, 2021 at 04:09:20PM +0800, Fei Wang wrote: > > Split packed data when it contains multiple show frames in some > > non-standard bitstream. This can benefit downstream decoder which > > can > > decode continuously instead of interrupt with unexpected error. > > > > Signed-off-by: Fei Wang > > --- > > libavcodec/av1_parser.c | 19 +++ > > 1 file changed, 15 insertions(+), 4 deletions(-) > > This results in a infinite loop > > endlessly displaying > [av1 @ 0x55f62c2a6a00] Failed to parse temporal unit. > [av1 @ 0x55f62c2a6a00] Invalid OBU length: 1071323, but only 768 > bytes remaining in fragment. > [av1 @ 0x55f62c2a6a00] Failed to parse temporal unit. > [av1 @ 0x55f62c2a6a00] Invalid OBU length: 1071323, but only 768 > bytes remaining in fragment. > [av1 @ 0x55f62c2a6a00] Failed to parse temporal unit. > [av1 @ 0x55f62c2a6a00] Invalid OBU length: 1071323, but only 768 > bytes remaining in fragment. > [av1 @ 0x55f62c2a6a00] Failed to parse temporal unit. > [av1 @ 0x55f62c2a6a00] Invalid OBU length: 1071323, but only 768 > bytes remaining in fragment. > [av1 @ 0x55f62c2a6a00] Failed to parse temporal unit. > [av1 @ 0x55f62c2a6a00] Invalid OBU length: 1071323, but only 768 > bytes remaining in fragment. > [av1 @ 0x55f62c2a6a00] Failed to parse temporal unit. > [av1 @ 0x55f62c2a6a00] Invalid OBU length: 1071323, but only 768 > bytes remaining in fragment. > [av1 @ 0x55f62c2a6a00] Failed to parse temporal unit. > [av1 @ 0x55f62c2a6a00] Invalid OBU length: 1071323, but only 768 > bytes remaining in fragment. > [av1 @ 0x55f62c2a6a00] Failed to parse temporal unit. Thanks Michael to catch this. Will check it soon. Fei Thanks > > i will send you the testsample privatly > > thx > > [...] > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avfilter: add overlay vaapi filter
On Fri, 2021-11-19 at 15:14 +, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Wang, Fei W > > Sent: Friday, November 19, 2021 2:15 AM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Sun, Xinpeng ; Zhou, Zachary > > > > Subject: Re: [FFmpeg-devel] [PATCH v1] avfilter: add overlay vaapi > > filter > > > > On Thu, 2021-11-18 at 21:55 +, Soft Works wrote: > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf > > > > Of > > > > Fei > > > > Wang > > > > Sent: Tuesday, June 30, 2020 5:58 AM > > > > To: ffmpeg-devel@ffmpeg.org > > > > Cc: Xinpeng Sun ; Zachary Zhou > > > > ; Fei Wang > > > > Subject: [FFmpeg-devel] [PATCH v1] avfilter: add overlay vaapi > > > > filter > > > > > > > > From: Xinpeng Sun > > > > > > > > Overlay one video on the top of another. > > > > > > > > It takes two inputs and has one output. The first input is the > > > > "main" > > > > video on > > > > which the second input is overlaid. This filter requires same > > > > memory > > > > layout for > > > > all the inputs. > > > > > > > > An example command to use this filter to overlay an image LOGO > > > > at > > > > the > > > > top-left > > > > corner of the INPUT video and both inputs are h264 file: > > > > > > > > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \ > > > > -hwaccel_output_format vaapi -i INPUT.h264 -hwaccel vaapi \ > > > > -vaapi_device /dev/dri/renderD128 -hwaccel_output_format vaapi > > > > -i > > \ > > > > LOGO.h264 -filter_complex > > > > "[0:v][1:v]overlay_vaapi=w=50:h=50:alpha=0.5" \ > > > > -c:v h264_vaapi -y OUTPUT.h264 > > > > > > > > Signed-off-by: Xinpeng Sun > > > > Signed-off-by: Zachary Zhou > > > > Signed-off-by: Fei Wang > > > > --- > > > > > > Does anybody know why this filter hasn't been merged? > > > I always thought it would have been included for quite a while. > > > > > > Is there any problem with it? > > > > Because nobody helped to review/apply it. It works base on our > > local > > test. If anybody can help to apply it, I will submit a new version > > to > > port it to latest mater. > > I can't merge but I'm ready to review it. The patch from cartwheel > doesn't apply either, so when you could supply an updated patch, that > would be great. Thanks Softworkz! New version V2 base on master already submitted, please help to review. Also Ping anyone who can help to apply this patch after review. Thanks Fei > > Thanks, > softworkz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avfilter: add overlay vaapi filter
On Thu, 2021-11-18 at 21:55 +, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Fei > > Wang > > Sent: Tuesday, June 30, 2020 5:58 AM > > To: ffmpeg-devel@ffmpeg.org > > Cc: Xinpeng Sun ; Zachary Zhou > > ; Fei Wang > > Subject: [FFmpeg-devel] [PATCH v1] avfilter: add overlay vaapi > > filter > > > > From: Xinpeng Sun > > > > Overlay one video on the top of another. > > > > It takes two inputs and has one output. The first input is the > > "main" > > video on > > which the second input is overlaid. This filter requires same > > memory > > layout for > > all the inputs. > > > > An example command to use this filter to overlay an image LOGO at > > the > > top-left > > corner of the INPUT video and both inputs are h264 file: > > > > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 \ > > -hwaccel_output_format vaapi -i INPUT.h264 -hwaccel vaapi \ > > -vaapi_device /dev/dri/renderD128 -hwaccel_output_format vaapi -i \ > > LOGO.h264 -filter_complex > > "[0:v][1:v]overlay_vaapi=w=50:h=50:alpha=0.5" \ > > -c:v h264_vaapi -y OUTPUT.h264 > > > > Signed-off-by: Xinpeng Sun > > Signed-off-by: Zachary Zhou > > Signed-off-by: Fei Wang > > --- > > Does anybody know why this filter hasn't been merged? > I always thought it would have been included for quite a while. > > Is there any problem with it? Because nobody helped to review/apply it. It works base on our local test. If anybody can help to apply it, I will submit a new version to port it to latest mater. Thanks Fei > > Thanks, > softworkz > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5 1/9] cbs_av1: fix incorrect data type
On Tue, 2021-10-12 at 16:23 +0800, Fei Wang wrote: > Since order_hint_bits_minus_1 range is 0~7, cur_frame_hint can be > most 128. And similar return value for cbs_av1_get_relative_dist. > So if plus them and use int8_t for the result may lose its precision. > > Signed-off-by: Fei Wang > --- > update: > 1. move additional film grain frame from av1dec.c to vaapi_av1.c > 2. patch 3~5 can fix clip: > https://drive.google.com/file/d/1Qdx_18_BFcFf_5_XXSZOVohLpaAb-yIw/view?usp=sharing > > libavcodec/cbs_av1_syntax_template.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/cbs_av1_syntax_template.c > b/libavcodec/cbs_av1_syntax_template.c > index 6fe6e9a4f3..d98d3d42de 100644 > --- a/libavcodec/cbs_av1_syntax_template.c > +++ b/libavcodec/cbs_av1_syntax_template.c > @@ -355,7 +355,7 @@ static int > FUNC(set_frame_refs)(CodedBitstreamContext *ctx, RWContext *rw, > AV1_REF_FRAME_ALTREF2, AV1_REF_FRAME_ALTREF > }; > int8_t ref_frame_idx[AV1_REFS_PER_FRAME], > used_frame[AV1_NUM_REF_FRAMES]; > -int8_t shifted_order_hints[AV1_NUM_REF_FRAMES]; > +int16_t shifted_order_hints[AV1_NUM_REF_FRAMES]; > int cur_frame_hint, latest_order_hint, earliest_order_hint, ref; > int i, j; > Hi James, Could you help to review this version? This fixed your comments in V4. And we tested the 3th patch with DXVA, which can also fix the clip I shared. Fei 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 v1] avcodec/av1dec: check if hwaccel is specificed
On Fri, 2021-08-27 at 19:09 +0200, Hendrik Leppkes wrote:
> On Fri, Aug 27, 2021 at 1:54 PM Fei Wang
> wrote:
> >
> > Since av1 decoder is only available for hw acceleration. This will
> > gives out more accurate information if this decoder used but
> > doesn't
> > specificed a hwaccel.
> >
> > For example:
> > ffmpeg -c:v av1 -i INPUT OUTPUT
> >
> > Signed-off-by: Fei Wang
> > ---
> > 1. This is improvement of patch for:
> > https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=4660
> >
> > libavcodec/av1dec.c | 17 -
> > 1 file changed, 12 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > index a69808f7b6..58a9deeb4e 100644
> > --- a/libavcodec/av1dec.c
> > +++ b/libavcodec/av1dec.c
> > @@ -452,15 +452,22 @@ static int get_pixel_format(AVCodecContext
> > *avctx)
> > *fmtp++ = s->pix_fmt;
> > *fmtp = AV_PIX_FMT_NONE;
> >
> > -ret = ff_thread_get_format(avctx, pix_fmts);
> > -if (ret < 0)
> > -return ret;
> > -
> > /**
> > - * check if the HW accel is inited correctly. If not, return
> > un-implemented.
> > + * check if the HW accel is specificed. If not, return un-
> > implemented.
> > * Since now the av1 decoder doesn't support native decode, if
> > it will be
> > * implemented in the future, need remove this check.
> > */
> > +if (!avctx->hw_device_ctx) {
> > +av_log(avctx, AV_LOG_ERROR, "The AV1 decoder requires a hw
> > acceleration"
> > + " to be specified.\n");
> > +return AVERROR(ENOSYS);
> > +}
> > +
>
> Not every hwaccel uses a hw_device_ctx. Its still perfectly valid and
> supported to use the old setup which overrides get_format/get_buffer2
> and sets avctx->hwaccel_context directly.
> You will not know if this is the case before get_format was called,
> so
> you cannot pre-detect it.
If so, the only way to fix is keep previous check with avctx->hwaccel
but change its log context like "The AV1 decoder requires a hw acceleration to
be specified or the specified hw doesn't support AV1 decoding."
Btw, just for curious, which hwaccel are you using that doesn't set up
the hw_device_ctx?
>
> Or in other words, this patch breaks my application, so its not a
> valid solution.
>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error output
> -Original Message- > From: ffmpeg-devel On Behalf Of Soft > Works > Sent: Friday, August 27, 2021 1:25 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error > output > > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Wang, Fei W > > Sent: Friday, 27 August 2021 06:39 > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect > > error output > > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > Soft > > > Works > > > Sent: Friday, August 27, 2021 12:18 PM > > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust > > incorrect error > > > output > > > > > > > > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Wang, Fei W > > > > Sent: Friday, 27 August 2021 05:05 > > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org> > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust > > incorrect > > > > error output > > > > > > > > > -Original Message- > > > > > From: ffmpeg-devel On Behalf > > Of > > > > Soft > > > > > Works > > > > > Sent: Thursday, August 26, 2021 5:12 AM > > > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org> > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust > > > > incorrect error > > > > > output > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > From: ffmpeg-devel On > > Behalf Of > > > > > > Wang, Fei W > > > > > > Sent: Tuesday, 24 August 2021 07:32 > > > > > > To: ffmpeg-devel@ffmpeg.org > > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust > > > > incorrect > > > > > > error output > > > > > > > > > > > > On Tue, 2021-08-24 at 02:45 +, Soft Works wrote: > > > > > > > > -Original Message- > > > > > > > > From: ffmpeg-devel On > > > > Behalf Of > > > > > > > > Ronald S. Bultje > > > > > > > > Sent: Tuesday, 24 August 2021 04:34 > > > > > > > > To: FFmpeg development discussions and patches > > > > > > > de...@ffmpeg.org> > > > > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: > > Adjust > > > > > > > > incorrect error output > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > On Mon, Aug 23, 2021 at 9:39 PM Soft Works > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > The current message "Your platform doesn't suppport > > > > hardware > > > > > > > > > accelerated AV1 decoding." is inaccurate and > > misleading. > > > > When a > > > > > > > > > user doesn't specify a hwcaccel, this doesn't tell > > anything > > > > > > > > > about what is actually supported on that platform. > > > > > > > > > > > > > > > > > > Signed-off-by: softworkz > > > > > > > > > --- > > > > > > > > > libavcodec/av1dec.c | 4 ++-- > > > > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > > > > > > > > > > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c > > > > index > > > > > > > > > a75d6744d3..8dfcd26cb6 100644 > > > > > > > > > --- a/libavcodec/av1dec.c > > > > > > > > > +++ b/libavcodec/av1dec.c > > > > > > > > > @@ -462,8 +462,8 @@ static int > > > > get_pixel_format(AVCodecContext > > > > >
Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error output
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft
> Works
> Sent: Friday, August 27, 2021 12:18 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error
> output
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Wang, Fei W
> > Sent: Friday, 27 August 2021 05:05
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect
> > error output
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > Soft
> > > Works
> > > Sent: Thursday, August 26, 2021 5:12 AM
> > > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > incorrect error
> > > output
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel On Behalf Of
> > > > Wang, Fei W
> > > > Sent: Tuesday, 24 August 2021 07:32
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > incorrect
> > > > error output
> > > >
> > > > On Tue, 2021-08-24 at 02:45 +, Soft Works wrote:
> > > > > > -Original Message-
> > > > > > From: ffmpeg-devel On
> > Behalf Of
> > > > > > Ronald S. Bultje
> > > > > > Sent: Tuesday, 24 August 2021 04:34
> > > > > > To: FFmpeg development discussions and patches > > > > > de...@ffmpeg.org>
> > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > > > > > incorrect error output
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Mon, Aug 23, 2021 at 9:39 PM Soft Works
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > The current message "Your platform doesn't suppport
> > hardware
> > > > > > > accelerated AV1 decoding." is inaccurate and misleading.
> > When a
> > > > > > > user doesn't specify a hwcaccel, this doesn't tell anything
> > > > > > > about what is actually supported on that platform.
> > > > > > >
> > > > > > > Signed-off-by: softworkz
> > > > > > > ---
> > > > > > > libavcodec/av1dec.c | 4 ++--
> > > > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > > >
> > > > > > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > index
> > > > > > > a75d6744d3..8dfcd26cb6 100644
> > > > > > > --- a/libavcodec/av1dec.c
> > > > > > > +++ b/libavcodec/av1dec.c
> > > > > > > @@ -462,8 +462,8 @@ static int
> > get_pixel_format(AVCodecContext
> > > > > >
> > > > > > *avctx)
> > > > > > > * implemented in the future, need remove this check.
> > > > > > > */
> > > > > > > if (!avctx->hwaccel) {
> > > > > > > -av_log(avctx, AV_LOG_ERROR, "Your platform doesn't
> > > > > >
> > > > > > suppport"
> > > > > > > - " hardware accelerated AV1 decoding.\n");
> > > > > > > +av_log(avctx, AV_LOG_ERROR, "AV1 decoding requires
> > a
> > > > hw
> > > > > > > acceleration"
> > > > > > > + " to be specified.\n");
> > > > > > >
> > > > > >
> > > > > > This is misleading.
> > > > > >
> > > > > > This error message (for me) happens when I accidentally
> > compile
> > > > > > FFmpeg without aom/dav1d support, and try to play AV1
> > content.
> > > > >
> > > > > It also happens to me when I specify:
> > > > >
> > > > > ffmpeg -c:v av1 -i INPUT OUTPUT
> > > > >
> > > > > (e.g. like when I'd have forgotten to specify the hwaccel)
> > > > >
> > > > > > AV1 decoding
> > > > > > does
Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error output
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft
> Works
> Sent: Thursday, August 26, 2021 5:12 AM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error
> output
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Wang, Fei W
> > Sent: Tuesday, 24 August 2021 07:32
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect
> > error output
> >
> > On Tue, 2021-08-24 at 02:45 +, Soft Works wrote:
> > > > -Original Message-
> > > > From: ffmpeg-devel On Behalf Of
> > > > Ronald S. Bultje
> > > > Sent: Tuesday, 24 August 2021 04:34
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > > > incorrect error output
> > > >
> > > > Hi,
> > > >
> > > > On Mon, Aug 23, 2021 at 9:39 PM Soft Works
> >
> > > > wrote:
> > > >
> > > > > The current message "Your platform doesn't suppport hardware
> > > > > accelerated AV1 decoding." is inaccurate and misleading. When a
> > > > > user doesn't specify a hwcaccel, this doesn't tell anything
> > > > > about what is actually supported on that platform.
> > > > >
> > > > > Signed-off-by: softworkz
> > > > > ---
> > > > > libavcodec/av1dec.c | 4 ++--
> > > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c index
> > > > > a75d6744d3..8dfcd26cb6 100644
> > > > > --- a/libavcodec/av1dec.c
> > > > > +++ b/libavcodec/av1dec.c
> > > > > @@ -462,8 +462,8 @@ static int get_pixel_format(AVCodecContext
> > > >
> > > > *avctx)
> > > > > * implemented in the future, need remove this check.
> > > > > */
> > > > > if (!avctx->hwaccel) {
> > > > > -av_log(avctx, AV_LOG_ERROR, "Your platform doesn't
> > > >
> > > > suppport"
> > > > > - " hardware accelerated AV1 decoding.\n");
> > > > > +av_log(avctx, AV_LOG_ERROR, "AV1 decoding requires a
> > hw
> > > > > acceleration"
> > > > > + " to be specified.\n");
> > > > >
> > > >
> > > > This is misleading.
> > > >
> > > > This error message (for me) happens when I accidentally compile
> > > > FFmpeg without aom/dav1d support, and try to play AV1 content.
> > >
> > > It also happens to me when I specify:
> > >
> > > ffmpeg -c:v av1 -i INPUT OUTPUT
> > >
> > > (e.g. like when I'd have forgotten to specify the hwaccel)
> > >
> > > > AV1 decoding
> > > > does
> > > > not require hw decoding - it simply requires an external library.
> > > >
> > > > Will the hwaccel be autodetected when AV1 hw decoding is
> > supported
> > > > by
> > > > the
> > > > platform?
> > >
> > > No.
> > >
> > > How about this: "The AV1 decoder requires a hw acceleration to be
> > > specified." ?
> >
> > This will bring new misleading if user specify the hw acceleration but
> > the hardware itself doesn't support av1 dec.
>
> Such situations may happen, but this is not subject of this patch.
> This patch is about the error that is printed when no hw acceleration has been
> specified.
Yes, I understand your purpose. But here avctx->hwaccel==NULL does not
stands for hw acceleration has not been specified in a hundred percent. If
specificed hw
acceleration init fail in ff_thread_get_format which is just 1 line above your
modify,
then avctx->hwaccel will be NULL too. And even the hw init fail, return value
of
ff_thread_get_format may 0 with some error log printed. For example run the cmd
on Skylake:
$ ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -v verbose -i
av1.ivf -pix_fmt yuv420p -vsync passthrough -f null -
Output log will be:
[av1 @ 0x556613499fc0] No support for codec av1 profile 0.
[av1 @ 0x556613499fc0] Failed setup for format vaapi: hwaccel initialisation
returned error.
[av1 @ 0x556613499fc0] Your platform doesn
Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust incorrect error output
On Tue, 2021-08-24 at 02:45 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Ronald S. Bultje
> > Sent: Tuesday, 24 August 2021 04:34
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: Adjust
> > incorrect
> > error output
> >
> > Hi,
> >
> > On Mon, Aug 23, 2021 at 9:39 PM Soft Works
> > wrote:
> >
> > > The current message "Your platform doesn't suppport
> > > hardware accelerated AV1 decoding." is inaccurate and
> > > misleading. When a user doesn't specify a hwcaccel,
> > > this doesn't tell anything about what is actually
> > > supported on that platform.
> > >
> > > Signed-off-by: softworkz
> > > ---
> > > libavcodec/av1dec.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > > index a75d6744d3..8dfcd26cb6 100644
> > > --- a/libavcodec/av1dec.c
> > > +++ b/libavcodec/av1dec.c
> > > @@ -462,8 +462,8 @@ static int get_pixel_format(AVCodecContext
> >
> > *avctx)
> > > * implemented in the future, need remove this check.
> > > */
> > > if (!avctx->hwaccel) {
> > > -av_log(avctx, AV_LOG_ERROR, "Your platform doesn't
> >
> > suppport"
> > > - " hardware accelerated AV1 decoding.\n");
> > > +av_log(avctx, AV_LOG_ERROR, "AV1 decoding requires a hw
> > > acceleration"
> > > + " to be specified.\n");
> > >
> >
> > This is misleading.
> >
> > This error message (for me) happens when I accidentally compile
> > FFmpeg
> > without aom/dav1d support, and try to play AV1 content.
>
> It also happens to me when I specify:
>
> ffmpeg -c:v av1 -i INPUT OUTPUT
>
> (e.g. like when I'd have forgotten to specify the hwaccel)
>
> > AV1 decoding
> > does
> > not require hw decoding - it simply requires an external library.
> >
> > Will the hwaccel be autodetected when AV1 hw decoding is supported
> > by
> > the
> > platform?
>
> No.
>
> How about this: "The AV1 decoder requires a hw acceleration to be
> specified." ?
This will bring new misleading if user specify the hw acceleration but
the hardware itself doesn't support av1 dec.
Or like "The AV1 decoder requires a hw acceleration to be specified
or specified hw doesn't support av1 decoding." seems better.
Fei
Thanks
>
> softworkz
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_vpp_qsv: Don't overrun stack array
On Wed, 2021-08-04 at 02:27 +0200, Andreas Rheinhardt wrote: > 8b83dad82512a6948b63408f964463b063ad24c9 added another potentially > used > video enhancement filter without increasing a define for the number > of > such options which is used as the size of stack array. This can lead > to > a buffer overrun if all filters are used simultaneously. So increase > said number. > > Fixes Coverity ticket #1489775. > > Signed-off-by: Andreas Rheinhardt > --- > libavfilter/vf_vpp_qsv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c > index f2309ed9d9..70bd5310c3 100644 > --- a/libavfilter/vf_vpp_qsv.c > +++ b/libavfilter/vf_vpp_qsv.c > @@ -42,7 +42,7 @@ > #define FLAGS (AV_OPT_FLAG_VIDEO_PARAM | > AV_OPT_FLAG_FILTERING_PARAM) > > /* number of video enhancement filters */ > -#define ENH_FILTERS_COUNT (7) > +#define ENH_FILTERS_COUNT (8) LGTM, Thanks Andreas. > #define QSV_HAVE_ROTATION QSV_VERSION_ATLEAST(1, 17) > #define QSV_HAVE_MIRRORING QSV_VERSION_ATLEAST(1, 19) > #define QSV_HAVE_SCALING_CONFIG QSV_VERSION_ATLEAST(1, 19) ___ ffmpeg-devel mailing list ffmpeg-devel@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/9] cbs_av1: fix incorrect data type
On Fri, 2021-07-09 at 11:32 +0800, Fei Wang wrote: > Since order_hint_bits_minus_1 range is 0~7, cur_frame_hint can be > most 128. And similar return value for cbs_av1_get_relative_dist. > So if plus them and use int8_t for the result may lose its precision. > > Signed-off-by: Fei Wang > --- > libavcodec/cbs_av1_syntax_template.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/cbs_av1_syntax_template.c > b/libavcodec/cbs_av1_syntax_template.c > index 6fe6e9a4f3..d98d3d42de 100644 > --- a/libavcodec/cbs_av1_syntax_template.c > +++ b/libavcodec/cbs_av1_syntax_template.c > @@ -355,7 +355,7 @@ static int > FUNC(set_frame_refs)(CodedBitstreamContext *ctx, RWContext *rw, > AV1_REF_FRAME_ALTREF2, AV1_REF_FRAME_ALTREF > }; > int8_t ref_frame_idx[AV1_REFS_PER_FRAME], > used_frame[AV1_NUM_REF_FRAMES]; > -int8_t shifted_order_hints[AV1_NUM_REF_FRAMES]; > +int16_t shifted_order_hints[AV1_NUM_REF_FRAMES]; > int cur_frame_hint, latest_order_hint, earliest_order_hint, ref; > int i, j; > Hi James, This version fixed all comments from community, could you help to review? Thanks Fei ___ ffmpeg-devel mailing list ffmpeg-devel@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/9] avcodec/av1dec: support setup shear process
On Tue, 2021-07-06 at 18:19 +0200, Henrik Gramner wrote: > On Mon, Jul 5, 2021 at 4:32 AM Fei Wang wrote: > > +int64_t v, w; > > +int32_t *param = >cur_frame.gm_params[idx][0]; > > ... > > +v = param[4] * (1 << AV1_WARPEDMODEL_PREC_BITS); > > +w = param[3] * param[4]; > > Possible integer overflow? Might need some int64_t casting before the > multiplies. Thanks, Fixed in V4. Fei > ___ > ffmpeg-devel mailing list > ffmpeg-devel@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 3/9] avcodec/av1dec: support setup shear process
On Mon, 2021-07-05 at 07:12 +0200, Jean-Baptiste Kempf wrote:
> On Mon, 5 Jul 2021, at 04:29, Fei Wang wrote:
> > Defined in spec 7.11.3.6/7.11.3.7.
>
> ...
> > +static const uint16_t div_lut[AV1_DIV_LUT_NUM] = {
> > + 16384, 16320, 16257, 16194, 16132, 16070, 16009, 15948, 15888,
> > 15828, 15768,
>
> Where are those numbers coming from? From the spec? From an annex?
> Then add a comment in the code for this, and not just in the commit
> log.
It's defined in spec 7.11.3.7. I will add the comment into the code.
Thanks
Fei
___
ffmpeg-devel mailing list
ffmpeg-devel@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/9] cbs_av1: fix incorrect data type
On Fri, 2021-07-02 at 08:29 -0300, James Almer wrote: > On 7/2/2021 2:55 AM, Wang, Fei W wrote: > > On Thu, 2021-07-01 at 09:41 -0300, James Almer wrote: > > > On 6/17/2021 3:10 AM, Fei Wang wrote: > > > > shifted_order_hints is computed by data with int plus data with > > > > int. > > > > Switch to int8_t may lose its precision. > > > > > > > > Signed-off-by: Fei Wang > > > > --- > > > >libavcodec/cbs_av1_syntax_template.c | 2 +- > > > >1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/libavcodec/cbs_av1_syntax_template.c > > > > b/libavcodec/cbs_av1_syntax_template.c > > > > index 6fe6e9a4f3..956d45e132 100644 > > > > --- a/libavcodec/cbs_av1_syntax_template.c > > > > +++ b/libavcodec/cbs_av1_syntax_template.c > > > > @@ -355,7 +355,7 @@ static int > > > > FUNC(set_frame_refs)(CodedBitstreamContext *ctx, RWContext *rw, > > > >AV1_REF_FRAME_ALTREF2, AV1_REF_FRAME_ALTREF > > > >}; > > > >int8_t ref_frame_idx[AV1_REFS_PER_FRAME], > > > > used_frame[AV1_NUM_REF_FRAMES]; > > > > -int8_t shifted_order_hints[AV1_NUM_REF_FRAMES]; > > > > +int shifted_order_hints[AV1_NUM_REF_FRAMES]; > > > > > > Would int16_t be enough? If so, use that. > > > > int16_t can fixed my clip. But as I mentioned in commit message, > > this > > variable is get with int plus int, switch to int16_t may still has > > potential threat. > > It wont since seq->order_hint_bits_minus_1 has a range of 0-7, > meaning > cur_frame_hint can be at most 128. Similar situation for the return > value of cbs_av1_get_relative_dist(). That's make sense. Thanks James. I will submit V2 to use int16_t. Thanks Fei > > > > > Also when shifted_order_hints is called, it turns back to int > > again: > > > > int hint = shifted_order_hints[i]; > > For arrays we prefer fixed size types, whereas for scalars native > sizes > are better. > > > > > Thanks > > Fei > > > > > > > > LGTM either way. > > > > > > >int cur_frame_hint, latest_order_hint, > > > > earliest_order_hint, > > > > ref; > > > >int i, j; > > > > > > > > > > > > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > To unsubscribe, visit link above, or email > > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/9] avcodec/av1dec: support setup shear process
On Thu, 2021-07-01 at 09:39 -0300, James Almer wrote:
> On 6/17/2021 3:10 AM, Fei Wang wrote:
> > Defined in spec 7.11.3.6/7.11.3.7.
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/av1dec.c | 97
> > +
> > libavcodec/av1dec.h | 1 +
> > 2 files changed, 98 insertions(+)
> >
> > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > index 1dda0f9160..3fca17e84b 100644
> > --- a/libavcodec/av1dec.c
> > +++ b/libavcodec/av1dec.c
> > @@ -28,6 +28,33 @@
> > #include "internal.h"
> > #include "profiles.h"
> >
> > +static const uint16_t div_lut[AV1_DIV_LUT_NUM] = {
> > + 16384, 16320, 16257, 16194, 16132, 16070, 16009, 15948, 15888,
> > 15828, 15768,
> > + 15709, 15650, 15592, 15534, 15477, 15420, 15364, 15308, 15252,
> > 15197, 15142,
> > + 15087, 15033, 14980, 14926, 14873, 14821, 14769, 14717, 14665,
> > 14614, 14564,
> > + 14513, 14463, 14413, 14364, 14315, 14266, 14218, 14170, 14122,
> > 14075, 14028,
> > + 13981, 13935, 13888, 13843, 13797, 13752, 13707, 13662, 13618,
> > 13574, 13530,
> > + 13487, 13443, 13400, 13358, 13315, 13273, 13231, 13190, 13148,
> > 13107, 13066,
> > + 13026, 12985, 12945, 12906, 12866, 12827, 12788, 12749, 12710,
> > 12672, 12633,
> > + 12596, 12558, 12520, 12483, 12446, 12409, 12373, 12336, 12300,
> > 12264, 12228,
> > + 12193, 12157, 12122, 12087, 12053, 12018, 11984, 11950, 11916,
> > 11882, 11848,
> > + 11815, 11782, 11749, 11716, 11683, 11651, 11619, 11586, 11555,
> > 11523, 11491,
> > + 11460, 11429, 11398, 11367, 11336, 11305, 11275, 11245, 11215,
> > 11185, 11155,
> > + 11125, 11096, 11067, 11038, 11009, 10980, 10951, 10923, 10894,
> > 10866, 10838,
> > + 10810, 10782, 10755, 10727, 10700, 10673, 10645, 10618, 10592,
> > 10565, 10538,
> > + 10512, 10486, 10460, 10434, 10408, 10382, 10356, 10331, 10305,
> > 10280, 10255,
> > + 10230, 10205, 10180, 10156, 10131, 10107, 10082, 10058, 10034,
> > 10010, 9986,
> > + 9963, 9939, 9916, 9892, 9869, 9846, 9823, 9800, 9777, 9
> > 754, 9732,
> > + 9709, 9687, 9664, 9642, 9620, 9598, 9576, 9554, 9533, 9
> > 511, 9489,
> > + 9468, 9447, 9425, 9404, 9383, 9362, 9341, 9321, 9300, 9
> > 279, 9259,
> > + 9239, 9218, 9198, 9178, 9158, 9138, 9118, 9098, 9079, 9
> > 059, 9039,
> > + 9020, 9001, 8981, 8962, 8943, 8924, 8905, 8886, 8867, 8
> > 849, 8830,
> > + 8812, 8793, 8775, 8756, 8738, 8720, 8702, 8684, 8666, 8
> > 648, 8630,
> > + 8613, 8595, 8577, 8560, 8542, 8525, 8508, 8490, 8473, 8
> > 456, 8439,
> > + 8422, 8405, 8389, 8372, 8355, 8339, 8322, 8306, 8289, 8
> > 273, 8257,
> > + 8240, 8224, 8208, 8192
> > +};
> > +
> > static uint32_t inverse_recenter(int r, uint32_t v)
> > {
> > if (v > 2 * r)
> > @@ -97,6 +124,70 @@ static void read_global_param(AV1DecContext *s,
> > int type, int ref, int idx)
> > -mx, mx + 1, r) <<
> > prec_diff) + round;
> > }
> >
> > +static uint64_t round_two(uint64_t x, uint16_t n)
> > +{
> > +if (n == 0)
> > +return x;
> > +return ((x + (1 << (n - 1))) >> n);
> > +}
> > +
> > +static int64_t round_two_signed(int64_t x, uint16_t n)
> > +{
> > +return ((x<0) ? -round_two(-x, n) : round_two(x, n));
> > +}
> > +
> > +/**
> > + * Resolve divisor process.
> > + * see spec 7.11.3.7
> > + */
> > +static int16_t resolve_divisor(uint32_t d, uint16_t *shift)
> > +{
> > +int32_t e, f;
> > +
> > +*shift = av_log2(d);
> > +e = d - (1 << (*shift));
> > +if (*shift > AV1_DIV_LUT_BITS)
> > +f = round_two(e, *shift - AV1_DIV_LUT_BITS);
> > +else
> > +f = e << (AV1_DIV_LUT_BITS - (*shift));
> > +
> > +*shift += AV1_DIV_LUT_PREC_BITS;
> > +
> > +return div_lut[f];
> > +}
> > +
> > +/**
> > + * check if global motion params is valid.
> > + * see spec 7.11.3.6
> > + */
> > +static uint8_t get_shear_params_valid(AV1DecContext *s, int idx)
> > +{
> > +int16_t alpha, beta, gamma, delta, divf, divs;
> > +int64_t v, w;
> > +int32_t *param = >cur_frame.gm_params[idx][0];
> > +if (param[2] < 0)
> > +return 0;
> > +
> > +alpha = av_clip_int16(param[2] - (1 <<
> > AV1_WARPEDMODEL_PREC_BITS));
> > +beta = av_clip_int16(param[3]);
> > +divf = resolve_divisor(abs(param[2]), );
> > +v = param[4] * (1 << AV1_WARPEDMODEL_PREC_BITS);
> > +w = param[3] * param[4];
> > +gamma = av_clip_int16(round_two_signed((v * divf), divs));
> > +delta = av_clip_int16(param[5] - round_two_signed((w * divf),
> > divs) - (1 << AV1_WARPEDMODEL_PREC_BITS));
> > +
> > +alpha = round_two_signed(alpha, AV1_WARP_PARAM_REDUCE_BITS) <<
> > AV1_WARP_PARAM_REDUCE_BITS;
> > +beta = round_two_signed(beta, AV1_WARP_PARAM_REDUCE_BITS) <<
> > AV1_WARP_PARAM_REDUCE_BITS;
> > +gamma = round_two_signed(gamma, AV1_WARP_PARAM_REDUCE_BITS) <<
> > AV1_WARP_PARAM_REDUCE_BITS;
> > +delta = round_two_signed(delta,
Re: [FFmpeg-devel] [PATCH 1/9] cbs_av1: fix incorrect data type
On Thu, 2021-07-01 at 09:41 -0300, James Almer wrote: > On 6/17/2021 3:10 AM, Fei Wang wrote: > > shifted_order_hints is computed by data with int plus data with > > int. > > Switch to int8_t may lose its precision. > > > > Signed-off-by: Fei Wang > > --- > > libavcodec/cbs_av1_syntax_template.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/cbs_av1_syntax_template.c > > b/libavcodec/cbs_av1_syntax_template.c > > index 6fe6e9a4f3..956d45e132 100644 > > --- a/libavcodec/cbs_av1_syntax_template.c > > +++ b/libavcodec/cbs_av1_syntax_template.c > > @@ -355,7 +355,7 @@ static int > > FUNC(set_frame_refs)(CodedBitstreamContext *ctx, RWContext *rw, > > AV1_REF_FRAME_ALTREF2, AV1_REF_FRAME_ALTREF > > }; > > int8_t ref_frame_idx[AV1_REFS_PER_FRAME], > > used_frame[AV1_NUM_REF_FRAMES]; > > -int8_t shifted_order_hints[AV1_NUM_REF_FRAMES]; > > +int shifted_order_hints[AV1_NUM_REF_FRAMES]; > > Would int16_t be enough? If so, use that. int16_t can fixed my clip. But as I mentioned in commit message, this variable is get with int plus int, switch to int16_t may still has potential threat. Also when shifted_order_hints is called, it turns back to int again: int hint = shifted_order_hints[i]; Thanks Fei > > LGTM either way. > > > int cur_frame_hint, latest_order_hint, earliest_order_hint, > > ref; > > int i, j; > > > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/9] cbs_av1: fix incorrect data type
On Mon, 2021-06-21 at 09:38 +0800, Fei.Wang wrote: > On Thu, 2021-06-17 at 14:10 +0800, Fei Wang wrote: > > shifted_order_hints is computed by data with int plus data with > > int. > > Switch to int8_t may lose its precision. > > > > Signed-off-by: Fei Wang > > --- > > libavcodec/cbs_av1_syntax_template.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/cbs_av1_syntax_template.c > > b/libavcodec/cbs_av1_syntax_template.c > > index 6fe6e9a4f3..956d45e132 100644 > > --- a/libavcodec/cbs_av1_syntax_template.c > > +++ b/libavcodec/cbs_av1_syntax_template.c > > @@ -355,7 +355,7 @@ static int > > FUNC(set_frame_refs)(CodedBitstreamContext *ctx, RWContext *rw, > > AV1_REF_FRAME_ALTREF2, AV1_REF_FRAME_ALTREF > > }; > > int8_t ref_frame_idx[AV1_REFS_PER_FRAME], > > used_frame[AV1_NUM_REF_FRAMES]; > > -int8_t shifted_order_hints[AV1_NUM_REF_FRAMES]; > > +int shifted_order_hints[AV1_NUM_REF_FRAMES]; > > Hi, > Ping for review this patch set. Thanks. Hi James, Free to help review this patch set? This change improved VAAPI av1 decoder quality quite a lot base on our test result, and I believe it can benefit to all other HW av1 decoders too. Thanks > > Fei > > > int cur_frame_hint, latest_order_hint, earliest_order_hint, > > ref; > > int i, j; > > ___ ffmpeg-devel mailing list ffmpeg-devel@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/9] cbs_av1: fix incorrect data type
On Thu, 2021-06-17 at 14:10 +0800, Fei Wang wrote: > shifted_order_hints is computed by data with int plus data with int. > Switch to int8_t may lose its precision. > > Signed-off-by: Fei Wang > --- > libavcodec/cbs_av1_syntax_template.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/cbs_av1_syntax_template.c > b/libavcodec/cbs_av1_syntax_template.c > index 6fe6e9a4f3..956d45e132 100644 > --- a/libavcodec/cbs_av1_syntax_template.c > +++ b/libavcodec/cbs_av1_syntax_template.c > @@ -355,7 +355,7 @@ static int > FUNC(set_frame_refs)(CodedBitstreamContext *ctx, RWContext *rw, > AV1_REF_FRAME_ALTREF2, AV1_REF_FRAME_ALTREF > }; > int8_t ref_frame_idx[AV1_REFS_PER_FRAME], > used_frame[AV1_NUM_REF_FRAMES]; > -int8_t shifted_order_hints[AV1_NUM_REF_FRAMES]; > +int shifted_order_hints[AV1_NUM_REF_FRAMES]; Hi, Ping for review this patch set. Thanks. Fei > int cur_frame_hint, latest_order_hint, earliest_order_hint, ref; > int i, j; > ___ ffmpeg-devel mailing list ffmpeg-devel@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/vaapi_av1: correct data size when create slice data buffer
On Tue, 2021-05-18 at 12:26 +0300, Jan Ekström wrote:
> On Tue, May 18, 2021 at 5:55 AM Wang, Fei W
> wrote:
> >
> > On Mon, 2021-05-17 at 11:59 +0300, Jan Ekström wrote:
> > > On Mon, May 17, 2021 at 4:50 AM Fei Wang
> > > wrote:
> > > >
> > > > Set all tiles size to create slice data buffer, hardware will
> > > > use
> > > > slice_data_offset/slice_data_size in slice parameter buffer to
> > > > get
> > > > each tile's data.
> > > >
> > > > This change will let it success to decode clip which has multi
> > > > tiles data inside one OBU.
> > > >
> > > > Signed-off-by: Fei Wang
> > > > ---
> > > > libavcodec/vaapi_av1.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
> > > > index 1809b485aa..16b7e35747 100644
> > > > --- a/libavcodec/vaapi_av1.c
> > > > +++ b/libavcodec/vaapi_av1.c
> > > > @@ -292,7 +292,7 @@ static int
> > > > vaapi_av1_decode_slice(AVCodecContext *avctx,
> > > > err = ff_vaapi_decode_make_slice_buffer(avctx, pic,
> > > > _param,
> > > > sizeof(VASlice
> > > > Para
> > > > meterBufferAV1),
> > > > buffer,
> > > > -s-
> > > > > tile_group_info[i].tile_size);
> > > >
> > > > +size);
> > > > if (err) {
> > > > ff_vaapi_decode_cancel(avctx, pic);
> > > > return err;
> > > > --
> > > > 2.17.1
> > >
> > > So basically this fixes setting the size of the passed buffer to
> > > the
> > > whole size of the buffer (in which tile offset and tile size
> > > should
> > > always be located). As such it makes sense.
> > >
> > > It seems like at some point there was an idea to only pass
> > > "buffer +
> > > tile_offset", but that never materialized completely (and then
> > > setting
> > > VASliceParameterBufferAV1's tile_offset to 0)? Would that lead to
> > > smaller buffers being utilized? Or does libva already extract the
> > > tiles into their own buffers based on the information?
> >
> > Buffer+tile_offset can fix the issue too. I chose change the size
> > only
> > is to try to follow current logic and do the smallest change to fix
> > this.
> >
>
> Yes, and as I noted it makes sense. It was just interesting to see
> how
> these two things seemed to be intermixed.
>
> Functionally this patch is LGTM, maybe something a la
>
> """
> avcodec/vaapi_av1: pass full buffer size for each tile
>
> Previously, only the size of a given tile was passed, making the
> offset
> and size marked in VASliceParameterBufferAV1 invalid with multiple
> tiles.
> """
>
> for the commit message?
Thanks, I can update the commit message like this.
>
> This should probably then also be back-ported to release/4.4 as I
> think 3308bbf7761a2723f784fcd6bb921dcbadc18c6e (original addition of
> the vaapi AV1 hwaccel is included in it).
Yes, this is a important fix. Appreciate if you who has write access
can help back-port it to release/4.4.(The patch can be cherry-pick to
release/4.4 without any conflict)
Fei
Thanks
>
> Thanks.
>
> > With buffer+tile_offset way, the buffers will be smaller, but the
> > effect can be ignore, since bitstream size is small. For 8K
> > resolution
> > bitstream, its each frame size is only ~100KB.
> >
> > Fei
>
> Yup. Of course this depends on the bit rate of the stream, but I do
> not consider this a required change.
>
> Jan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 v1] avcodec/vaapi_av1: correct data size when create slice data buffer
On Mon, 2021-05-17 at 11:59 +0300, Jan Ekström wrote:
> On Mon, May 17, 2021 at 4:50 AM Fei Wang
> wrote:
> >
> > Set all tiles size to create slice data buffer, hardware will use
> > slice_data_offset/slice_data_size in slice parameter buffer to get
> > each tile's data.
> >
> > This change will let it success to decode clip which has multi
> > tiles data inside one OBU.
> >
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/vaapi_av1.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
> > index 1809b485aa..16b7e35747 100644
> > --- a/libavcodec/vaapi_av1.c
> > +++ b/libavcodec/vaapi_av1.c
> > @@ -292,7 +292,7 @@ static int
> > vaapi_av1_decode_slice(AVCodecContext *avctx,
> > err = ff_vaapi_decode_make_slice_buffer(avctx, pic,
> > _param,
> > sizeof(VASlicePara
> > meterBufferAV1),
> > buffer,
> > -s-
> > >tile_group_info[i].tile_size);
> > +size);
> > if (err) {
> > ff_vaapi_decode_cancel(avctx, pic);
> > return err;
> > --
> > 2.17.1
>
> So basically this fixes setting the size of the passed buffer to the
> whole size of the buffer (in which tile offset and tile size should
> always be located). As such it makes sense.
>
> It seems like at some point there was an idea to only pass "buffer +
> tile_offset", but that never materialized completely (and then
> setting
> VASliceParameterBufferAV1's tile_offset to 0)? Would that lead to
> smaller buffers being utilized? Or does libva already extract the
> tiles into their own buffers based on the information?
Buffer+tile_offset can fix the issue too. I chose change the size only
is to try to follow current logic and do the smallest change to fix
this.
With buffer+tile_offset way, the buffers will be smaller, but the
effect can be ignore, since bitstream size is small. For 8K resolution
bitstream, its each frame size is only ~100KB.
Fei
Thanks
>
> Jan
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] lavfi/qsvvpp: support async depth
On Sun, 2021-04-11 at 23:24 +0800, Zhong Li wrote: > Fei Wang 于2021年3月31日周三 上午10:11写道： > > > > Async depth will allow qsv filter cache few frames, and avoid force > > switch and end filter task frame by frame. This change will improve > > performance for some multi-task case, for example 1:N transcode( > > decode + vpp + encode) with all QSV plugins. > > > > Performance data test on my Coffee Lake Desktop(i7-8700K) by using > > the following 1:8 transcode test case improvement: > > 1. Fps improved from 55 to 130. > > 2. Render/Video usage improved from ~61%/~38% to ~100%/~70%.(Data > > get > > from intel_gpu_top) > > > > test CMD: > > ffmpeg -v verbose -init_hw_device qsv=hw:/dev/dri/renderD128 > > -filter_hw_device \ > > hw -hwaccel qsv -hwaccel_output_format qsv -c:v h264_qsv -i > > 1920x1080.264 \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \ > > -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30 > > -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - > > > > Signed-off-by: Fei Wang > > --- > > Change: > > 1. Add test data in commit message. > > 2. Rmove some duplicate code. > > LGTM and applied. Thanks. Thanks Zhong BTW, could you also help to review my another patch which support scale mode in vpp_qsv? This option is port from scale_qsv, and it will benefit to user whose pipeline already exists vpp_qsv, and don't need to involve another filter(scale_qsv). The link is: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210224014158.7302-1-fei.w.w...@intel.com/ Fei 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] lavfi/qsvvpp: support async depth
On Wed, 2021-03-31 at 10:07 +0800, Fei Wang wrote:
> Async depth will allow qsv filter cache few frames, and avoid force
> switch and end filter task frame by frame. This change will improve
> performance for some multi-task case, for example 1:N transcode(
> decode + vpp + encode) with all QSV plugins.
>
> Performance data test on my Coffee Lake Desktop(i7-8700K) by using
> the following 1:8 transcode test case improvement:
> 1. Fps improved from 55 to 130.
> 2. Render/Video usage improved from ~61%/~38% to ~100%/~70%.(Data get
> from intel_gpu_top)
>
> test CMD:
> ffmpeg -v verbose -init_hw_device qsv=hw:/dev/dri/renderD128
> -filter_hw_device \
> hw -hwaccel qsv -hwaccel_output_format qsv -c:v h264_qsv -i
> 1920x1080.264 \
> -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30
> -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \
> -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30
> -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \
> -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30
> -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \
> -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30
> -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \
> -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30
> -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \
> -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30
> -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null - \
> -vf 'vpp_qsv=w=1280:h=720:async_depth=4' -c:v h264_qsv -r:v 30
> -preset 7 -g 33 -refs 2 -bf 3 -q 24 -f null -
>
> Signed-off-by: Fei Wang
> ---
> Change:
> 1. Add test data in commit message.
> 2. Rmove some duplicate code.
Hi Linjie,
Appreciate if you can help to review this new version. Thanks.
Fei
>
> libavfilter/qsvvpp.c | 153 ++---
> --
> libavfilter/qsvvpp.h | 39 +++-
> libavfilter/vf_deinterlace_qsv.c | 14 +--
> libavfilter/vf_vpp_qsv.c | 75 ---
> 4 files changed, 191 insertions(+), 90 deletions(-)
>
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index f216b3f248..4768f6208b 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -37,37 +37,6 @@
> #define IS_OPAQUE_MEMORY(mode) (mode & MFX_MEMTYPE_OPAQUE_FRAME)
> #define IS_SYSTEM_MEMORY(mode) (mode & MFX_MEMTYPE_SYSTEM_MEMORY)
>
> -typedef struct QSVFrame {
> -AVFrame *frame;
> -mfxFrameSurface1 *surface;
> -mfxFrameSurface1 surface_internal; /* for system memory */
> -struct QSVFrame *next;
> -} QSVFrame;
> -
> -/* abstract struct for all QSV filters */
> -struct QSVVPPContext {
> -mfxSession session;
> -int (*filter_frame) (AVFilterLink *outlink, AVFrame *frame);/*
> callback */
> -enum AVPixelFormat out_sw_format; /* Real output format */
> -mfxVideoParam vpp_param;
> -mfxFrameInfo *frame_infos; /* frame info for each
> input */
> -
> -/* members related to the input/output surface */
> -int in_mem_mode;
> -int out_mem_mode;
> -QSVFrame *in_frame_list;
> -QSVFrame *out_frame_list;
> -int nb_surface_ptrs_in;
> -int nb_surface_ptrs_out;
> -mfxFrameSurface1 **surface_ptrs_in;
> -mfxFrameSurface1 **surface_ptrs_out;
> -
> -/* MFXVPP extern parameters */
> -mfxExtOpaqueSurfaceAlloc opaque_alloc;
> -mfxExtBuffer **ext_buffers;
> -int nb_ext_buffers;
> -};
> -
> static const mfxHandleType handle_types[] = {
> MFX_HANDLE_VA_DISPLAY,
> MFX_HANDLE_D3D9_DEVICE_MANAGER,
> @@ -336,9 +305,11 @@ static int fill_frameinfo_by_link(mfxFrameInfo
> *frameinfo, AVFilterLink *link)
> static void clear_unused_frames(QSVFrame *list)
> {
> while (list) {
> -if (list->surface && !list->surface->Data.Locked) {
> -list->surface = NULL;
> +/* list->queued==1 means the frame is not cached in VPP
> + * process any more, it can be released to pool. */
> +if ((list->queued == 1) && !list->surface.Data.Locked) {
> av_frame_free(>frame);
> +list->queued = 0;
> }
> list = list->next;
> }
> @@ -361,8 +332,10 @@ static QSVFrame *get_free_frame(QSVFrame **list)
> QSVFrame *out = *list;
>
> for (; out; out = out->next) {
> -if (!out->surface)
> +if (!out->queued) {
> +out->queued = 1;
> break;
> +}
> }
>
> if (!out) {
> @@ -371,8 +344,9 @@ static QSVFrame *get_free_frame(QSVFrame **list)
> av_log(NULL, AV_LOG_ERROR, "Can't alloc new output
> frame.\n");
> return NULL;
> }
> -out->next = *list;
> -*list = out;
> +out->queued = 1;
> +out->next = *list;
> +*list = out;
> }
>
> return out;
> @@ -402,7 +376,7 @@ static
Re: [FFmpeg-devel] [PATCH v2] lavfi/qsvvpp: support async depth
On Sun, 2021-03-21 at 18:10 +0800, Linjie Fu wrote:
> Hi Fei,
>
> On Mon, Mar 15, 2021 at 1:13 PM Fei Wang
> wrote:
> >
> > Async depth will allow qsv filter cache few frames, and avoid force
> > switch and end filter task frame by frame. This change will improve
> > performance for some multi-task case, for example 1:N transcode(
> > decode + vpp + encode) with all QSV plugins.
>
> Async depth support for qsv vpp is valuable for the performance of
> whole qsv pipeline, since both decoding/encoding have already
> supported the async_depth.
>
> Hence, would you please help to elaborate more about the details
> about
> the performance improvement for the whole pipeline?
> (For examples, before/after this patch, cmdline, platform and the
> fps ...)
Will add some data in my next version.
>
> > Signed-off-by: Fei Wang
> > ---
> > Change: combine used and queued into queued in QSVFrame.
> >
> > libavfilter/qsvvpp.c | 153 ++-
> >
> > libavfilter/qsvvpp.h | 41 -
> > libavfilter/vf_deinterlace_qsv.c | 14 +--
> > libavfilter/vf_vpp_qsv.c | 75 ---
> > 4 files changed, 193 insertions(+), 90 deletions(-)
> >
> > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> > index f216b3f248..e7c7a12cfa 100644
> > --- a/libavfilter/qsvvpp.c
> > +++ b/libavfilter/qsvvpp.c
> > @@ -27,6 +27,7 @@
> > #include "libavutil/hwcontext_qsv.h"
> > #include "libavutil/time.h"
> > #include "libavutil/pixdesc.h"
> > +#include "libavutil/fifo.h"
>
> This seems to be redundant, since you're adding fifo.h in qsvvpp.h as
> well.
Thanks, will remove this line.
>
> > #include "internal.h"
> > #include "qsvvpp.h"
> > @@ -37,37 +38,6 @@
> > #define IS_OPAQUE_MEMORY(mode) (mode & MFX_MEMTYPE_OPAQUE_FRAME)
> > #define IS_SYSTEM_MEMORY(mode) (mode & MFX_MEMTYPE_SYSTEM_MEMORY)
> >
> > -typedef struct QSVFrame {
> > -AVFrame *frame;
> > -mfxFrameSurface1 *surface;
> > -mfxFrameSurface1 surface_internal; /* for system memory */
> > -struct QSVFrame *next;
> > -} QSVFrame;
> > -
> > -/* abstract struct for all QSV filters */
> > -struct QSVVPPContext {
> > -mfxSession session;
> > -int (*filter_frame) (AVFilterLink *outlink, AVFrame *frame);/*
> > callback */
> > -enum AVPixelFormat out_sw_format; /* Real output format */
> > -mfxVideoParam vpp_param;
> > -mfxFrameInfo *frame_infos; /* frame info for each
> > input */
> > -
> > -/* members related to the input/output surface */
> > -int in_mem_mode;
> > -int out_mem_mode;
> > -QSVFrame *in_frame_list;
> > -QSVFrame *out_frame_list;
> > -int nb_surface_ptrs_in;
> > -int nb_surface_ptrs_out;
> > -mfxFrameSurface1 **surface_ptrs_in;
> > -mfxFrameSurface1 **surface_ptrs_out;
> > -
> > -/* MFXVPP extern parameters */
> > -mfxExtOpaqueSurfaceAlloc opaque_alloc;
> > -mfxExtBuffer **ext_buffers;
> > -int nb_ext_buffers;
> > -};
> > -
> > static const mfxHandleType handle_types[] = {
> > MFX_HANDLE_VA_DISPLAY,
> > MFX_HANDLE_D3D9_DEVICE_MANAGER,
> > @@ -336,9 +306,11 @@ static int fill_frameinfo_by_link(mfxFrameInfo
> > *frameinfo, AVFilterLink *link)
> > static void clear_unused_frames(QSVFrame *list)
> > {
> > while (list) {
> > -if (list->surface && !list->surface->Data.Locked) {
> > -list->surface = NULL;
> > +/* list->queued==1 means the frame is not cached in VPP
> > + * process any more, it can be released to pool. */
> > +if ((list->queued == 1) && !list->surface.Data.Locked) {
> > av_frame_free(>frame);
> > +list->queued = 0;
> > }
> > list = list->next;
> > }
> > @@ -361,8 +333,10 @@ static QSVFrame *get_free_frame(QSVFrame
> > **list)
> > QSVFrame *out = *list;
> >
> > for (; out; out = out->next) {
> > -if (!out->surface)
> > +if (!out->queued) {
> > +out->queued = 1;
> > break;
> > +}
> > }
> >
> > if (!out) {
> > @@ -371,8 +345,9 @@ static QSVFrame *get_free_frame(QSVFrame
> > **list)
> > av_log(NULL, AV_LOG_ERROR, "Can't alloc new output
> > frame.\n");
> > return NULL;
> > }
> > -out->next = *list;
> > -*list = out;
> > +out->queued = 1;
> > +out->next = *list;
> > +*list = out;
> > }
> >
> > return out;
> > @@ -402,7 +377,7 @@ static QSVFrame *submit_frame(QSVVPPContext *s,
> > AVFilterLink *inlink, AVFrame *p
> > return NULL;
> > }
> > qsv_frame->frame = av_frame_clone(picref);
> > -qsv_frame->surface = (mfxFrameSurface1 *)qsv_frame->frame-
> > >data[3];
> > +qsv_frame->surface = *(mfxFrameSurface1 *)qsv_frame-
> >
