| Message ID | 20201221060710.12230-6-nuomi2021@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [FFmpeg-devel,1/6] avcodec/h266: add shared header for h266 | expand |
| Context | Check | Description |
|---|---|---|
| andriy/x86_make | success | Make finished |
| andriy/x86_make_fate | success | Make fate finished |
| andriy/PPC64_make | success | Make finished |
| andriy/PPC64_make_fate | success | Make fate finished |
On Mon, Dec 21, 2020 at 7:08 AM Nuo Mi <nuomi2021@gmail.com> wrote: > you can download test clips here: > > https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-11.0/ > > 68.48% (163/238) clips are md5 matched with VTM 11: > > passed: > 10b400_A_Bytedance_2.bit > 10b400_B_Bytedance_2.bit > 8b400_A_Bytedance_2.bit > 8b400_B_Bytedance_2.bit > 8b420_A_Bytedance_2.bit > 8b420_B_Bytedance_2.bit > ACTPIC_A_Huawei_3.bit > ACTPIC_B_Huawei_3.bit > ACTPIC_C_Huawei_3.bit > AFF_A_HUAWEI_2.bit > AFF_B_HUAWEI_2.bit > ALF_A_Huawei_3.bit > ALF_B_Huawei_3.bit > ALF_C_KDDI_2.bit > ALF_D_Qualcomm_2.bit > AMVR_A_HHI_3.bit > AMVR_B_HHI_3.bit > APSALF_A_Qualcomm_2.bit > APSLMCS_A_Dolby_3.bit > APSLMCS_B_Dolby_3.bit > APSLMCS_C_Dolby_2.bit > APSMULT_A_MediaTek_3.bit > APSMULT_B_MediaTek_3.bit > AUD_A_Broadcom_3.bit > BCW_A_MediaTek_3.bit > BDOF_A_MediaTek_3.bit > BDPCM_A_Orange_2.bit > CCALF_A_Sharp_3.bit > CCALF_B_Sharp_3.bit > CCALF_C_Sharp_3.bit > CCALF_D_Sharp_3.bit > CCLM_A_KDDI_1.bit > CIIP_A_MediaTek_3.bit > CodingToolsSets_A_Tencent_2.bit > CodingToolsSets_B_Tencent_2.bit > CodingToolsSets_C_Tencent_2.bit > CodingToolsSets_D_Tencent_2.bit > CROP_A_Panasonic_3.bit > CROP_B_Panasonic_4.bit > CST_A_MediaTek_3.bit > CTU_A_MediaTek_3.bit > CTU_B_MediaTek_3.bit > CTU_C_MediaTek_3.bit > CUBEMAP_A_MediaTek_3.bit > CUBEMAP_B_MediaTek_3.bit > CUBEMAP_C_MediaTek_3.bit > DEBLOCKING_A_Sharp_3.bit > DEBLOCKING_B_Sharp_2.bit > DEBLOCKING_C_Huawei_3.bit > DEBLOCKING_E_Ericsson_2.bit > DMVR_A_Huawei_3.bit > DMVR_B_KDDI_3.bit > DPB_A_Sharplabs_2.bit > DPB_B_Sharplabs_2.bit > DQ_A_HHI_3.bit > ENT444HIGHTIER_A_Sony_3.bit > ENT444HIGHTIER_B_Sony_3.bit > ENT444HIGHTIER_C_Sony_3.bit > ENT444HIGHTIER_D_Sony_3.bit > ENT444MAINTIER_A_Sony_3.bit > ENT444MAINTIER_B_Sony_3.bit > ENT444MAINTIER_C_Sony_3.bit > ENT444MAINTIER_D_Sony_3.bit > ENTHIGHTIER_A_Sony_3.bit > ENTHIGHTIER_B_Sony_3.bit > ENTHIGHTIER_C_Sony_3.bit > ENTHIGHTIER_D_Sony_3.bit > ENTMAINTIER_A_Sony_3.bit > ENTMAINTIER_B_Sony_3.bit > ENTMAINTIER_C_Sony_3.bit > ENTMAINTIER_D_Sony_3.bit > ENTROPY_A_Chipsnmedia_2.bit > ENTROPY_A_Qualcomm_2.bit > ENTROPY_B_Sharp_2.bit > ERP_A_MediaTek_3.bit > FILLER_A_Bytedance_1.bit > GPM_A_Alibaba_3.bit > IBC_A_Tencent_2.bit > IBC_B_Tencent_2.bit > IBC_C_Tencent_2.bit > IBC_D_Tencent_2.bit > IP_B_Nokia_1.bit > ISP_A_HHI_3.bit > ISP_B_HHI_3.bit > JCCR_A_Nokia_2.bit > JCCR_B_Nokia_2.bit > JCCR_C_HHI_3.bit > JCCR_E_Nokia_1.bit > JCCR_F_Nokia_1.bit > LFNST_A_LGE_3.bit > LFNST_B_LGE_3.bit > LFNST_C_HHI_3.bit > LMCS_A_Dolby_3.bit > LOSSLESS_B_HHI_3.bit > LTRP_A_ERICSSON_2.bit > MERGE_A_Qualcomm_2.bit > MERGE_B_Qualcomm_2.bit > MERGE_C_Qualcomm_2.bit > MERGE_D_Qualcomm_2.bit > MERGE_E_Qualcomm_2.bit > MERGE_F_Qualcomm_2.bit > MERGE_G_Qualcomm_2.bit > MERGE_H_Qualcomm_2.bit > MERGE_I_Qualcomm_2.bit > MERGE_J_Qualcomm_2.bit > MIP_A_HHI_3.bit > MIP_B_HHI_3.bit > MPM_A_LGE_3.bit > MRLP_A_HHI_2.bit > MRLP_B_HHI_2.bit > MTS_A_LGE_3.bit > MTS_B_LGE_3.bit > MTS_LFNST_A_LGE_3.bit > MTS_LFNST_B_LGE_3.bit > MVCOMP_A_Sharp_2.bit > PDPC_A_Qualcomm_3.bit > PDPC_B_Qualcomm_3.bit > PDPC_C_Qualcomm_2.bit > PHSH_B_Sharp_1.bit > POC_A_Nokia_1.bit > POUT_A_Sharplabs_2.bit > PROF_A_Interdigital_3.bit > PROF_B_Interdigital_3.bit > QTBTT_A_MediaTek_3.bit > QUANT_A_Huawei_2.bit > QUANT_B_Huawei_2.bit > QUANT_C_Huawei_2.bit > RPL_A_ERICSSON_2.bit > SAO_A_SAMSUNG_3.bit > SAO_B_SAMSUNG_3.bit > SAO_C_SAMSUNG_3.bit > SbTMVP_A_Bytedance_3.bit > SbTMVP_B_Bytedance_3.bit > SBT_A_HUAWEI_2.bit > SCALING_A_InterDigital_1.bit > SCALING_B_InterDigital_1.bit > SCALING_C_InterDigital_1.bit > SDH_A_Dolby_2.bit > SMVD_A_HUAWEI_2.bit > TEMPSCAL_A_Panasonic_4.bit > TEMPSCAL_C_Panasonic_3.bit > TILE_A_Nokia_2.bit > TILE_B_Nokia_2.bit > TILE_C_Nokia_2.bit > TILE_D_Nokia_2.bit > TILE_E_Nokia_2.bit > TILE_F_Nokia_2.bit > TMVP_A_Chipsnmedia_3.bit > TMVP_B_Chipsnmedia_3.bit > TMVP_C_Chipsnmedia_3.bit > TMVP_D_Chipsnmedia_3.bit > TRANS_A_Chipsnmedia_2.bit > TRANS_B_Chipsnmedia_2.bit > TRANS_C_Chipsnmedia_2.bit > TRANS_D_Chipsnmedia_2.bit > WPP_A_Sharp_3.bit > WPP_B_Sharp_2.bit > WP_A_InterDigital_3.bit > WP_B_InterDigital_3.bit > WRAP_A_InterDigital_4.bit > WRAP_B_InterDigital_4.bit > WRAP_C_InterDigital_4.bit > --- > configure | 5 +- > libavcodec/Makefile | 1 + > libavcodec/allcodecs.c | 1 + > libavcodec/libvvdec.cpp | 244 ++++++++++++++++++++++++++++++++++++++++ > 4 files changed, 250 insertions(+), 1 deletion(-) > create mode 100644 libavcodec/libvvdec.cpp > > diff --git a/configure b/configure > index 77272948e3..1e9a44db31 100755 > --- a/configure > +++ b/configure > @@ -285,6 +285,7 @@ External library support: > --enable-libvorbis enable Vorbis en/decoding via libvorbis, > native implementation exists [no] > --enable-libvpx enable VP8 and VP9 de/encoding via libvpx [no] > + --enable-libvvdec enable VVC video encoding via libvvdec [no] > I do not think this one is correct. > --enable-libwebp enable WebP encoding via libwebp [no] > --enable-libx264 enable H.264 encoding via x264 [no] > --enable-libx265 enable HEVC encoding via x265 [no] > @@ -1816,6 +1817,7 @@ EXTERNAL_LIBRARY_LIST=" > libvmaf > libvorbis > libvpx > + libvvdec > libwebp > libxml2 > libzimg > @@ -3281,6 +3283,7 @@ libvpx_vp8_decoder_deps="libvpx" > libvpx_vp8_encoder_deps="libvpx" > libvpx_vp9_decoder_deps="libvpx" > libvpx_vp9_encoder_deps="libvpx" > +libvvdec_decoder_deps="libvvdec" > libwebp_encoder_deps="libwebp" > libwebp_anim_encoder_deps="libwebp" > libx262_encoder_deps="libx262" > @@ -6455,7 +6458,7 @@ enabled libvpx && { > die "libvpx enabled but no supported decoders found" > fi > } > - > +enabled libvvdec && require_pkg_config libvvdec "libvvdec >= > 0.1.2" vvdec/version.h VVDEC_VERSION_MAJOR > enabled libwebp && { > enabled libwebp_encoder && require_pkg_config libwebp "libwebp > >= 0.2.0" webp/encode.h WebPGetEncoderVersion > enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder > "libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; } > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > index 82cc9b8b93..ebd3781982 100644 > --- a/libavcodec/Makefile > +++ b/libavcodec/Makefile > @@ -1059,6 +1059,7 @@ OBJS-$(CONFIG_LIBVPX_VP8_DECODER) += > libvpxdec.o > OBJS-$(CONFIG_LIBVPX_VP8_ENCODER) += libvpxenc.o > OBJS-$(CONFIG_LIBVPX_VP9_DECODER) += libvpxdec.o libvpx.o > OBJS-$(CONFIG_LIBVPX_VP9_ENCODER) += libvpxenc.o libvpx.o > +OBJS-$(CONFIG_LIBVVDEC_DECODER) += libvvdec.o > OBJS-$(CONFIG_LIBWEBP_ENCODER) += libwebpenc_common.o > libwebpenc.o > OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER) += libwebpenc_common.o > libwebpenc_animencoder.o > OBJS-$(CONFIG_LIBX262_ENCODER) += libx264.o > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c > index f00d524747..545c38f541 100644 > --- a/libavcodec/allcodecs.c > +++ b/libavcodec/allcodecs.c > @@ -752,6 +752,7 @@ extern AVCodec ff_libvpx_vp8_encoder; > extern AVCodec ff_libvpx_vp8_decoder; > extern AVCodec ff_libvpx_vp9_encoder; > extern AVCodec ff_libvpx_vp9_decoder; > +extern AVCodec ff_libvvdec_decoder; > /* preferred over libwebp */ > extern AVCodec ff_libwebp_anim_encoder; > extern AVCodec ff_libwebp_encoder; > diff --git a/libavcodec/libvvdec.cpp b/libavcodec/libvvdec.cpp > new file mode 100644 > index 0000000000..73fe13f61e > --- /dev/null > +++ b/libavcodec/libvvdec.cpp > @@ -0,0 +1,244 @@ > +/* > + * vvdec H.266/VVC decoder > + * Copyright (c) 2020 Nuo Mi <nuomi2021@gmail.com> > + * > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with FFmpeg; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > 02110-1301 USA > + */ > + > +/** > + * @file > + * AV1 decoder support via libaom > Huh? > + */ > + > +#include "vvdec/vvdec.h" > + > +extern "C" { > + > +#include "libavutil/common.h" > +#include "libavutil/imgutils.h" > +#include "libavutil/internal.h" > + > +#include "avcodec.h" > +#include "h2645_parse.h" > +#include "internal.h" > +#include "profiles.h" > + > +typedef struct VVdecContext { > + AVCodecContext *avctx; > + vvdec::VVDec* vvdec; > + > + H2645Packet pkt; > + int is_nalff; ///< this flag is != 0 if bitstream is > encapsulated > + ///< as a format defined in 14496-15 > + int nal_length_size; ///< Number of bytes used for nal length (1, > 2 or 4) > +} VVdecContext; > + > +} > + > +static int map_error(int vret) > +{ > + switch(vret) > + { > + case vvdec::VVDEC_OK : return 0; > + case vvdec::VVDEC_ERR_UNSPECIFIED: return AVERROR_UNKNOWN; > + case vvdec::VVDEC_ERR_INITIALIZE: return AVERROR_BUG; > + case vvdec::VVDEC_ERR_ALLOCATE: return AVERROR(ENOMEM); > + case vvdec::VVDEC_NOT_ENOUGH_MEM: return AVERROR(ENOMEM); > + case vvdec::VVDEC_ERR_PARAMETER: return AVERROR(EINVAL); > + case vvdec::VVDEC_ERR_NOT_SUPPORTED: return AVERROR(ENOSYS); > + case vvdec::VVDEC_ERR_RESTART_REQUIRED: return AVERROR_BUG; > + case vvdec::VVDEC_ERR_CPU: return AVERROR(ENOSYS); > + case vvdec::VVDEC_TRY_AGAIN: return AVERROR(EAGAIN); > + case vvdec::VVDEC_EOF: return AVERROR(EOF); > + default: return AVERROR_UNKNOWN; > + } > +} > + > +static int check_vret(VVdecContext* s, int vret) { > + vvdec::VVDec* vvdec = s->vvdec; > + if (vret && vret != vvdec::VVDEC_EOF) { > + av_log(s->avctx, AV_LOG_ERROR, "vvdec returns error: %s\n", > vvdec->getErrorMsg(vret)); > + } > + return map_error(vret); > +} > + > +static const enum AVPixelFormat pix_fmts_8bit[] = { > + AV_PIX_FMT_GRAY8, AV_PIX_FMT_YUV420P, > + AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P > +}; > + > +static const enum AVPixelFormat pix_fmts_10bit[] = { > + AV_PIX_FMT_GRAY10, AV_PIX_FMT_YUV420P10, > + AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10 > +}; > + > +static AVPixelFormat get_format(const vvdec::Frame* frame) > +{ > + if (frame->m_eColorFormat != vvdec::VVC_CF_INVALID) { > + switch (frame->m_uiBitDepth) { > + case 8: > + return pix_fmts_8bit[frame->m_eColorFormat]; > + case 10: > + return pix_fmts_10bit[frame->m_eColorFormat]; > + } > + } > + return AV_PIX_FMT_NONE; > +} > + > +static int set_pix_fmt(VVdecContext* s, const vvdec::Frame* frame) > +{ > + AVPixelFormat format = get_format(frame); > + if (format == AV_PIX_FMT_NONE) { > + av_log(s->avctx, AV_LOG_ERROR, > + "unsupported, depth = %d, color format = %d.\n", > frame->m_uiBitDepth, frame->m_eColorFormat); > + return AVERROR_INVALIDDATA; > + } > + s->avctx->pix_fmt = format; > + return 0; > +} > + > +static int copy_to_avframe(VVdecContext* s, const vvdec::Frame* src, > AVFrame *dest) > +{ > + AVCodecContext* avctx = s->avctx; > + int i, ret, width, height; > + uint8_t *data[4]; > + int linesize[4]; > + > + ret = set_pix_fmt(s, src); > + if (ret < 0) > + return ret; > + width = (int)src->m_uiWidth; > + height = (int)src->m_uiHeight; > + if (width != avctx->width || height != avctx->height) { > + av_log(avctx, AV_LOG_INFO, "dimension change! %dx%d -> %dx%d\n", > + avctx->width, avctx->height, width, height); > + if ((ret = ff_set_dimensions(avctx, width, height)) < 0) > + return ret; > + } > + if ((ret = ff_get_buffer(avctx, dest, 0)) < 0) > + return ret; > + > + for (i = 0; i < 3; i++) { > + const vvdec::Component& plane = src->m_cComponent[i]; > + data[i] = plane.m_pucBuffer; > + linesize[i] = plane.m_iStride; > + } > + data[3] = 0; linesize[3] = 0; > + > + //TODO: conformance window? > + av_image_copy(dest->data, dest->linesize, (const uint8_t **)data, > linesize, > + avctx->pix_fmt, width, height); > + return 0; > +} > + > +static int vvdec_decode(AVCodecContext *avctx, void *data, int *got_frame, > + AVPacket *avpkt) > +{ > + VVdecContext *s = (VVdecContext *)avctx->priv_data; > + vvdec::VVDec* vvdec = s->vvdec; > + AVFrame *picture = (AVFrame*)data; > + int vret, ret = 0; > + vvdec::Frame* frame = NULL; > + > + if (!avpkt->size) { > + vret = vvdec->flush(&frame); > + if ((ret = check_vret(s, vret)) < 0) { > + goto error_out; > + } > + } else { > + uint8_t *new_extradata; > + int new_extradata_size; > + new_extradata = av_packet_get_side_data(avpkt, > AV_PKT_DATA_NEW_EXTRADATA, > + &new_extradata_size); > + if (new_extradata && new_extradata_size > 0) { > + return AVERROR_PATCHWELCOME; > + } > + > + vvdec::AccessUnit au; > + au.m_pucBuffer = (unsigned char*)avpkt->data; > + au.m_iUsedSize = avpkt->size; > + au.m_uiCts = avpkt->pts; > + au.m_bCtsValid = true; > + vret = vvdec->decode(au, &frame); > + if (vret && vret != vvdec::VVDEC_TRY_AGAIN) { > + if ((ret = check_vret(s, vret)) < 0) { > + goto error_out; > + } > + } > + > + } > + if (frame) { > + ret = copy_to_avframe(s, frame, picture); > + if (ret < 0) > + goto error_out; > + *got_frame = 1; > + } > + return 0; > +error_out: > + if (frame) { > + vvdec->objectUnref(frame); > + } > + return ret; > +} > + > +static av_cold int vvdec_free(AVCodecContext *avctx) > +{ > + VVdecContext *ctx = (VVdecContext *)avctx->priv_data; > + vvdec::VVDec* vvdec = ctx->vvdec; > + if (vvdec) { > + vvdec->uninit(); > + delete vvdec; > + } > + return 0; > +} > + > +static av_cold int vvdec_init(AVCodecContext *avctx) > +{ > + VVdecContext *s = (VVdecContext *)avctx->priv_data; > + vvdec::VVDecParameter param; > + vvdec::VVDec* vvdec = new vvdec::VVDec; > + int vret, ret = 0; > + > + av_log(avctx, AV_LOG_INFO, "VVDec version: %s\n", > vvdec->getVersionNumber()); > + > + s->avctx = avctx; > + s->vvdec = vvdec; > + vret = vvdec->init(param); > + if ((ret = check_vret(s, vret)) < 0) { > + delete vvdec; > + s->vvdec = NULL; > + } > + return ret; > +} > + > +extern "C" { > + > +AVCodec ff_libvvdec_decoder = { > + .name = "vvdec", > Please name it "libvvdec" > + .long_name = NULL_IF_CONFIG_SMALL("vvdec vvc decoder"), > This is simply wrong. Use full, official codec name. > + .type = AVMEDIA_TYPE_VIDEO, > + .id = AV_CODEC_ID_H266, > + .capabilities = AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_DR1 | > AV_CODEC_CAP_DELAY, > + .profiles = NULL_IF_CONFIG_SMALL(ff_h266_profiles), > + .wrapper_name = "libvvdec", > + .priv_data_size = sizeof(VVdecContext), > + .init = vvdec_init, > + .decode = vvdec_decode, > + .close = vvdec_free, > +}; > + > +} > -- > 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-request@ffmpeg.org with subject "unsubscribe".
A little update The sequence passed only 163 because they are not update their CMakeLists.txt. I had been updated CMakeLists.txt and these patches in my github tree as well, I can found 81.93% (195/238) passed, Moreover, there have two of Field video clips, the decoder works, but output as separate of Top/Bottom Fields, so the hash mismatch to VTM-11.0. Overall, we can expect totally 82.77% (195+2/238) matched. At 2020-12-22 01:40:43, "Paul B Mahol" <onemda@gmail.com> wrote: >On Mon, Dec 21, 2020 at 7:08 AM Nuo Mi <nuomi2021@gmail.com> wrote: > >> you can download test clips here: >> >> https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-11.0/ >> >> 68.48% (163/238) clips are md5 matched with VTM 11: >>
Hi Chen, Glad you can try it. Since hevc, the interlaced encoder is not supported. Encoder always encoder a frame, use an SEI to tell the user it's top/bottom filed or it's a frame. It's named Adaptive Frame Field (SAFF). Current ffmpeg can't support this very well for even hevc, I think we can put this later. On Tue, Dec 22, 2020 at 3:10 AM chen <chenm003@163.com> wrote: > A little update > The sequence passed only 163 because they are not update their > CMakeLists.txt. > I had been updated CMakeLists.txt and these patches in my github tree as > well, I can found 81.93% (195/238) passed, > > > Moreover, there have two of Field video clips, the decoder works, but > output as separate of Top/Bottom Fields, > so the hash mismatch to VTM-11.0. > > > Overall, we can expect totally 82.77% (195+2/238) matched. > > > At 2020-12-22 01:40:43, "Paul B Mahol" <onemda@gmail.com> wrote: > >On Mon, Dec 21, 2020 at 7:08 AM Nuo Mi <nuomi2021@gmail.com> wrote: > > > >> you can download test clips here: > >> > >> > https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-11.0/ > >> > >> 68.48% (163/238) clips are md5 matched with VTM 11: > >> > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Dec 21, 2020, 07:07 by nuomi2021@gmail.com: > you can download test clips here: > https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-11.0/ > Honestly, I'm not sure about this patch. Its an external library decoder, which doesn't help us very much, and its for a codec competing with another codec (AV1) for which we don't really have a native decoder for yet. Not to mention some of us were involved with the effort to standardize and/or write a decoder for AV1, so there's also a personal element to not wanting VVC to have any success. So I'm kind of against this particular patch as-is. I'd be okay with it being a native decoder built into our codebase. But as-is, this serves nothing to help the project, but only corporations who invested into the codec and want to see some return on their investment from enforcing licensing on our users. And no one is even really using this codec at the moment.
Hi Lynne, Thanks for the comments. We only have a small patch for the vvdec wrapper. All other codes (raw demuxer, cbs reader, parser, and cbs writer in the future) will benefit the native decoder and the vvc ecosystem. I do not think av1 is the savior. No matter how it promised you, if we only have one codec to choose from, it will be a disaster for all of us. But, if you and the ffmpeg tech committee decided to reject all vvc patches in the future, I can accept it and stop work on this. BTW, do you know the detailed plan for av1 native decoder? will we port dav1d back or implement a new one? thanks On Wed, Dec 23, 2020 at 12:10 AM Lynne <dev@lynne.ee> wrote: > Dec 21, 2020, 07:07 by nuomi2021@gmail.com: > > > you can download test clips here: > > > https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-11.0/ > > > > Honestly, I'm not sure about this patch. Its an external library decoder, > which > doesn't help us very much, and its for a codec competing with another codec > (AV1) for which we don't really have a native decoder for yet. Not to > mention > some of us were involved with the effort to standardize and/or write a > decoder > for AV1, so there's also a personal element to not wanting VVC to have any > success. > > So I'm kind of against this particular patch as-is. I'd be okay with it > being a native > decoder built into our codebase. But as-is, this serves nothing to help the > project, but only corporations who invested into the codec and want to see > some return on their investment from enforcing licensing on our users. > And no one is even really using this codec at the moment. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On 12/22/2020 2:02 PM, Nuo Mi wrote: > Hi Lynne, > Thanks for the comments. > We only have a small patch for the vvdec wrapper. All other codes (raw > demuxer, cbs reader, parser, and cbs writer in the future) will benefit the > native decoder and the vvc ecosystem. Yes. > > I do not think av1 is the savior. No matter how it promised you, if we only > have one codec to choose from, it will be a disaster for all of us. > But, if you and the ffmpeg tech committee decided to reject all vvc patches > in the future, I can accept it and stop work on this. No one is going to forbid or reject vvc work in general. I don't agree with Lynne's stance, but in any case adding a wrapper for an external library is secondary to the rest. It can be discussed properly later. > > BTW, do you know the detailed plan for av1 native decoder? will we port > dav1d back or implement a new one? > > thanks > > > > On Wed, Dec 23, 2020 at 12:10 AM Lynne <dev@lynne.ee> wrote: > >> Dec 21, 2020, 07:07 by nuomi2021@gmail.com: >> >>> you can download test clips here: >>> >> https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-11.0/ >>> >> >> Honestly, I'm not sure about this patch. Its an external library decoder, >> which >> doesn't help us very much, and its for a codec competing with another codec >> (AV1) for which we don't really have a native decoder for yet. Not to >> mention >> some of us were involved with the effort to standardize and/or write a >> decoder >> for AV1, so there's also a personal element to not wanting VVC to have any >> success. >> >> So I'm kind of against this particular patch as-is. I'd be okay with it >> being a native >> decoder built into our codebase. But as-is, this serves nothing to help the >> project, but only corporations who invested into the codec and want to see >> some return on their investment from enforcing licensing on our users. >> And no one is even really using this codec at the moment. >> >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-request@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-request@ffmpeg.org with subject "unsubscribe". >
Dec 22, 2020, 18:02 by nuomi2021@gmail.com: > Hi Lynne, > Thanks for the comments. > We only have a small patch for the vvdec wrapper. All other codes (raw > demuxer, cbs reader, parser, and cbs writer in the future) will benefit the > native decoder and the vvc ecosystem. > My problem was with this patch in particular. The rest are all fine. > I do not think av1 is the savior. No matter how it promised you, if we only > have one codec to choose from, it will be a disaster for all of us. > Well, no. Look at Opus. It was the best by far, became widely standardized, and in the meanwhile AAC USAC has been nothing but laughed at and isn't even supported by anyone except Fraunhofer. > But, if you and the ffmpeg tech committee decided to reject all vvc patches > in the future, I can accept it and stop work on this. > I'm not rejecting all patches. I have concerns about this patch in particular. I think we as a community should discuss whether we want to merge this patch as-is as an external wrapper or not, which is why I posted this. I'd rather have this discussion now rather than after this is merged, since after that there's no room to change anything. > BTW, do you know the detailed plan for av1 native decoder? will we port > dav1d back or implement a new one? > We'll port dav1d once either dav1d gets 10bit x86 SIMD or until someone gets disappointed enough and starts doing the work. I'm somewhat motivated to write some SIMD myself, but I'd rather write it under an LGPL license if I don't get paid, which would mean it would have to be ported.
On Tue, 22 Dec 2020, Lynne wrote: > Dec 21, 2020, 07:07 by nuomi2021@gmail.com: > >> you can download test clips here: >> https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-11.0/ >> > > Honestly, I'm not sure about this patch. Its an external library decoder, which > doesn't help us very much, and its for a codec competing with another codec > (AV1) for which we don't really have a native decoder for yet. Not to mention > some of us were involved with the effort to standardize and/or write a decoder > for AV1, so there's also a personal element to not wanting VVC to have any > success. I don't think it is a good idea to reject features in the project based on personal preference against a codec/format/company. Regards, Marton
Dec 22, 2020, 19:24 by cus@passwd.hu: > > > On Tue, 22 Dec 2020, Lynne wrote: > >> Dec 21, 2020, 07:07 by nuomi2021@gmail.com: >> >>> you can download test clips here: >>> https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-11.0/ >>> >> >> Honestly, I'm not sure about this patch. Its an external library decoder, which >> doesn't help us very much, and its for a codec competing with another codec >> (AV1) for which we don't really have a native decoder for yet. Not to mention >> some of us were involved with the effort to standardize and/or write a decoder >> for AV1, so there's also a personal element to not wanting VVC to have any >> success. >> > > I don't think it is a good idea to reject features in the project based on personal preference against a codec/format/company. > That was an insignificant part of my argument against it. I wouldn't even have mentioned this if I was the only one who was involved with AV1. Also its no so much "personal" as it is "political". My main point is accepting this wrapper doesn't help the project directly, instead it would result in a yet-another-libdav1d which might for real never actually get merged as VVC doesn't reach anywhere near the ubiquity the companies involved would have liked it to. We already have a dozen I-can't-believe-its-not-H264 library-only decoders.
Hi Lynne & James, Do not worry about the dav1d things that happened on vvcdec. It just a reference code like libaom. We will not have a useable native vvc decoder in 0.5~1 years. During this time, the wrapper can help us build many things, like container demuxer, hls/dash/rtsp network streaming... How about we flag the decoder as experimental, and declare we will retire it after the native codec is ready. Hi Marton, Fully agree with you, all codecs are created equal, only the market can decide which one is the winner. Regards. On Wed, Dec 23, 2020 at 4:14 AM Lynne <dev@lynne.ee> wrote: > Dec 22, 2020, 19:24 by cus@passwd.hu: > > > > > > > On Tue, 22 Dec 2020, Lynne wrote: > > > >> Dec 21, 2020, 07:07 by nuomi2021@gmail.com: > >> > >>> you can download test clips here: > >>> > https://www.itu.int/wftp3/av-arch/jvet-site/bitstream_exchange/VVC/under_test/VTM-11.0/ > >>> > >> > >> Honestly, I'm not sure about this patch. Its an external library > decoder, which > >> doesn't help us very much, and its for a codec competing with another > codec > >> (AV1) for which we don't really have a native decoder for yet. Not to > mention > >> some of us were involved with the effort to standardize and/or write a > decoder > >> for AV1, so there's also a personal element to not wanting VVC to have > any > >> success. > >> > > > > I don't think it is a good idea to reject features in the project based > on personal preference against a codec/format/company. > > > > That was an insignificant part of my argument against it. I wouldn't even > have mentioned this if I was the only one who was involved with AV1. > Also its no so much "personal" as it is "political". > > My main point is accepting this wrapper doesn't help the project directly, > instead it would result in a yet-another-libdav1d which might for real > never > actually get merged as VVC doesn't reach anywhere near the ubiquity the > companies involved would have liked it to. > We already have a dozen I-can't-believe-its-not-H264 library-only decoders. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
Dec 23, 2020, 14:07 by nuomi2021@gmail.com: > Hi Lynne & James, > Do not worry about the dav1d things that happened on vvcdec. It just a > reference code like libaom. > libaom does encoding and decoding. And most people only use it for encoding, as its not a very fast decoder. As-is, this patch only does decoding. > We will not have a useable native vvc decoder in 0.5~1 years. > Then why merge this if its not usable and won't stick once a usable decoder is written? > During this > time, the wrapper can help us build many things, like container demuxer, > hls/dash/rtsp network streaming... > How about we flag the decoder as experimental, and declare we will retire > it after the native codec is ready. > We don't do experimental decoders in general. > Hi Marton, > Fully agree with you, all codecs are created equal, only the market can > decide which one is the winner. > I don't believe Matron said anything like this. Also did you steal this line from the Bible or something :)
On Wed, Dec 23, 2020 at 10:00 PM Lynne <dev@lynne.ee> wrote: > Dec 23, 2020, 14:07 by nuomi2021@gmail.com: > > > Hi Lynne & James, > > Do not worry about the dav1d things that happened on vvcdec. It just a > > reference code like libaom. > > > > libaom does encoding and decoding. And most people only use > it for encoding, as its not a very fast decoder. As-is, this patch > only does decoding. > how about we replace vvdec with vtm. I guess it's not faster than vvdec, but it has an encoder. > > > > We will not have a useable native vvc decoder in 0.5~1 years. > > > > Then why merge this if its not usable and won't stick once a usable > decoder is written? > decoder just one block, to make vvc usable, we still work on other things. Have a workable decoder will speed up the work. > > > During this > > time, the wrapper can help us build many things, like container demuxer, > > hls/dash/rtsp network streaming... > > How about we flag the decoder as experimental, and declare we will retire > > it after the native codec is ready. > > > > We don't do experimental decoders in general. > > > > Hi Marton, > > Fully agree with you, all codecs are created equal, only the market can > > decide which one is the winner. > > > > I don't believe Matron said anything like this. > Also did you steal this line from the Bible or something :) > yeah, from a famous American bible. :) > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
On 12/23/2020 12:38 PM, Nuo Mi wrote: > On Wed, Dec 23, 2020 at 10:00 PM Lynne <dev@lynne.ee> wrote: > >> Dec 23, 2020, 14:07 by nuomi2021@gmail.com: >> >>> Hi Lynne & James, >>> Do not worry about the dav1d things that happened on vvcdec. It just a >>> reference code like libaom. >>> >> >> libaom does encoding and decoding. And most people only use >> it for encoding, as its not a very fast decoder. As-is, this patch >> only does decoding. >> > how about we replace vvdec with vtm. I guess it's not faster than vvdec, > but it has an encoder. Lets focus on getting the public defines, CBS module, parser and raw bitstream demuxer in first. Then we can see if an external decoder library should be added, and which one. Thanks.
At 2020-12-23 23:38:18, "Nuo Mi" <nuomi2021@gmail.com> wrote: >On Wed, Dec 23, 2020 at 10:00 PM Lynne <dev@lynne.ee> wrote: > >> Dec 23, 2020, 14:07 by nuomi2021@gmail.com: >> >> > Hi Lynne & James, >> > Do not worry about the dav1d things that happened on vvcdec. It just a >> > reference code like libaom. >> > >> >> libaom does encoding and decoding. And most people only use >> it for encoding, as its not a very fast decoder. As-is, this patch >> only does decoding. >> >how about we replace vvdec with vtm. I guess it's not faster than vvdec, >but it has an encoder. > there have project vvenc for encoder, it is a subset of vtm
Dec 23, 2020, 16:48 by jamrial@gmail.com: > On 12/23/2020 12:38 PM, Nuo Mi wrote: > >> On Wed, Dec 23, 2020 at 10:00 PM Lynne <dev@lynne.ee> wrote: >> >>> Dec 23, 2020, 14:07 by nuomi2021@gmail.com: >>> >>>> Hi Lynne & James, >>>> Do not worry about the dav1d things that happened on vvcdec. It just a >>>> reference code like libaom. >>>> >>> >>> libaom does encoding and decoding. And most people only use >>> it for encoding, as its not a very fast decoder. As-is, this patch >>> only does decoding. >>> >> how about we replace vvdec with vtm. I guess it's not faster than vvdec, >> but it has an encoder. >> > > Lets focus on getting the public defines, CBS module, parser and raw bitstream demuxer in first. Then we can see if an external decoder library should be added, and which one. > +1 This patch can be pinged or resubmitted later on. (as an aside, I'd rather not have the reference implementation, the MPEG ones like HM or JM have never ever been packaged by any distribution, and with good reason, they're very unusable)
sure, thanks all for the suggestions. On Thu, Dec 24, 2020 at 12:24 AM Lynne <dev@lynne.ee> wrote: > Dec 23, 2020, 16:48 by jamrial@gmail.com: > > > On 12/23/2020 12:38 PM, Nuo Mi wrote: > > > >> On Wed, Dec 23, 2020 at 10:00 PM Lynne <dev@lynne.ee> wrote: > >> > >>> Dec 23, 2020, 14:07 by nuomi2021@gmail.com: > >>> > >>>> Hi Lynne & James, > >>>> Do not worry about the dav1d things that happened on vvcdec. It just a > >>>> reference code like libaom. > >>>> > >>> > >>> libaom does encoding and decoding. And most people only use > >>> it for encoding, as its not a very fast decoder. As-is, this patch > >>> only does decoding. > >>> > >> how about we replace vvdec with vtm. I guess it's not faster than vvdec, > >> but it has an encoder. > >> > > > > Lets focus on getting the public defines, CBS module, parser and raw > bitstream demuxer in first. Then we can see if an external decoder library > should be added, and which one. > > > > +1 > This patch can be pinged or resubmitted later on. > (as an aside, I'd rather not have the reference implementation, the MPEG > ones like HM or JM have never ever been packaged by any distribution, > and with good reason, they're very unusable) > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
diff --git a/configure b/configure index 77272948e3..1e9a44db31 100755 --- a/configure +++ b/configure @@ -285,6 +285,7 @@ External library support: --enable-libvorbis enable Vorbis en/decoding via libvorbis, native implementation exists [no] --enable-libvpx enable VP8 and VP9 de/encoding via libvpx [no] + --enable-libvvdec enable VVC video encoding via libvvdec [no] --enable-libwebp enable WebP encoding via libwebp [no] --enable-libx264 enable H.264 encoding via x264 [no] --enable-libx265 enable HEVC encoding via x265 [no] @@ -1816,6 +1817,7 @@ EXTERNAL_LIBRARY_LIST=" libvmaf libvorbis libvpx + libvvdec libwebp libxml2 libzimg @@ -3281,6 +3283,7 @@ libvpx_vp8_decoder_deps="libvpx" libvpx_vp8_encoder_deps="libvpx" libvpx_vp9_decoder_deps="libvpx" libvpx_vp9_encoder_deps="libvpx" +libvvdec_decoder_deps="libvvdec" libwebp_encoder_deps="libwebp" libwebp_anim_encoder_deps="libwebp" libx262_encoder_deps="libx262" @@ -6455,7 +6458,7 @@ enabled libvpx && { die "libvpx enabled but no supported decoders found" fi } - +enabled libvvdec && require_pkg_config libvvdec "libvvdec >= 0.1.2" vvdec/version.h VVDEC_VERSION_MAJOR enabled libwebp && { enabled libwebp_encoder && require_pkg_config libwebp "libwebp >= 0.2.0" webp/encode.h WebPGetEncoderVersion enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder "libwebpmux >= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; } diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 82cc9b8b93..ebd3781982 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -1059,6 +1059,7 @@ OBJS-$(CONFIG_LIBVPX_VP8_DECODER) += libvpxdec.o OBJS-$(CONFIG_LIBVPX_VP8_ENCODER) += libvpxenc.o OBJS-$(CONFIG_LIBVPX_VP9_DECODER) += libvpxdec.o libvpx.o OBJS-$(CONFIG_LIBVPX_VP9_ENCODER) += libvpxenc.o libvpx.o +OBJS-$(CONFIG_LIBVVDEC_DECODER) += libvvdec.o OBJS-$(CONFIG_LIBWEBP_ENCODER) += libwebpenc_common.o libwebpenc.o OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER) += libwebpenc_common.o libwebpenc_animencoder.o OBJS-$(CONFIG_LIBX262_ENCODER) += libx264.o diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index f00d524747..545c38f541 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -752,6 +752,7 @@ extern AVCodec ff_libvpx_vp8_encoder; extern AVCodec ff_libvpx_vp8_decoder; extern AVCodec ff_libvpx_vp9_encoder; extern AVCodec ff_libvpx_vp9_decoder; +extern AVCodec ff_libvvdec_decoder; /* preferred over libwebp */ extern AVCodec ff_libwebp_anim_encoder; extern AVCodec ff_libwebp_encoder; diff --git a/libavcodec/libvvdec.cpp b/libavcodec/libvvdec.cpp new file mode 100644 index 0000000000..73fe13f61e --- /dev/null +++ b/libavcodec/libvvdec.cpp @@ -0,0 +1,244 @@ +/* + * vvdec H.266/VVC decoder + * Copyright (c) 2020 Nuo Mi <nuomi2021@gmail.com> + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. + * + * FFmpeg is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. + * + * You should have received a copy of the GNU Lesser General Public + * License along with FFmpeg; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +/** + * @file + * AV1 decoder support via libaom + */ + +#include "vvdec/vvdec.h" + +extern "C" { + +#include "libavutil/common.h" +#include "libavutil/imgutils.h" +#include "libavutil/internal.h" + +#include "avcodec.h" +#include "h2645_parse.h" +#include "internal.h" +#include "profiles.h" + +typedef struct VVdecContext { + AVCodecContext *avctx; + vvdec::VVDec* vvdec; + + H2645Packet pkt; + int is_nalff; ///< this flag is != 0 if bitstream is encapsulated + ///< as a format defined in 14496-15 + int nal_length_size; ///< Number of bytes used for nal length (1, 2 or 4) +} VVdecContext; + +} + +static int map_error(int vret) +{ + switch(vret) + { + case vvdec::VVDEC_OK : return 0; + case vvdec::VVDEC_ERR_UNSPECIFIED: return AVERROR_UNKNOWN; + case vvdec::VVDEC_ERR_INITIALIZE: return AVERROR_BUG; + case vvdec::VVDEC_ERR_ALLOCATE: return AVERROR(ENOMEM); + case vvdec::VVDEC_NOT_ENOUGH_MEM: return AVERROR(ENOMEM); + case vvdec::VVDEC_ERR_PARAMETER: return AVERROR(EINVAL); + case vvdec::VVDEC_ERR_NOT_SUPPORTED: return AVERROR(ENOSYS); + case vvdec::VVDEC_ERR_RESTART_REQUIRED: return AVERROR_BUG; + case vvdec::VVDEC_ERR_CPU: return AVERROR(ENOSYS); + case vvdec::VVDEC_TRY_AGAIN: return AVERROR(EAGAIN); + case vvdec::VVDEC_EOF: return AVERROR(EOF); + default: return AVERROR_UNKNOWN; + } +} + +static int check_vret(VVdecContext* s, int vret) { + vvdec::VVDec* vvdec = s->vvdec; + if (vret && vret != vvdec::VVDEC_EOF) { + av_log(s->avctx, AV_LOG_ERROR, "vvdec returns error: %s\n", vvdec->getErrorMsg(vret)); + } + return map_error(vret); +} + +static const enum AVPixelFormat pix_fmts_8bit[] = { + AV_PIX_FMT_GRAY8, AV_PIX_FMT_YUV420P, + AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P +}; + +static const enum AVPixelFormat pix_fmts_10bit[] = { + AV_PIX_FMT_GRAY10, AV_PIX_FMT_YUV420P10, + AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10 +}; + +static AVPixelFormat get_format(const vvdec::Frame* frame) +{ + if (frame->m_eColorFormat != vvdec::VVC_CF_INVALID) { + switch (frame->m_uiBitDepth) { + case 8: + return pix_fmts_8bit[frame->m_eColorFormat]; + case 10: + return pix_fmts_10bit[frame->m_eColorFormat]; + } + } + return AV_PIX_FMT_NONE; +} + +static int set_pix_fmt(VVdecContext* s, const vvdec::Frame* frame) +{ + AVPixelFormat format = get_format(frame); + if (format == AV_PIX_FMT_NONE) { + av_log(s->avctx, AV_LOG_ERROR, + "unsupported, depth = %d, color format = %d.\n", frame->m_uiBitDepth, frame->m_eColorFormat); + return AVERROR_INVALIDDATA; + } + s->avctx->pix_fmt = format; + return 0; +} + +static int copy_to_avframe(VVdecContext* s, const vvdec::Frame* src, AVFrame *dest) +{ + AVCodecContext* avctx = s->avctx; + int i, ret, width, height; + uint8_t *data[4]; + int linesize[4]; + + ret = set_pix_fmt(s, src); + if (ret < 0) + return ret; + width = (int)src->m_uiWidth; + height = (int)src->m_uiHeight; + if (width != avctx->width || height != avctx->height) { + av_log(avctx, AV_LOG_INFO, "dimension change! %dx%d -> %dx%d\n", + avctx->width, avctx->height, width, height); + if ((ret = ff_set_dimensions(avctx, width, height)) < 0) + return ret; + } + if ((ret = ff_get_buffer(avctx, dest, 0)) < 0) + return ret; + + for (i = 0; i < 3; i++) { + const vvdec::Component& plane = src->m_cComponent[i]; + data[i] = plane.m_pucBuffer; + linesize[i] = plane.m_iStride; + } + data[3] = 0; linesize[3] = 0; + + //TODO: conformance window? + av_image_copy(dest->data, dest->linesize, (const uint8_t **)data, linesize, + avctx->pix_fmt, width, height); + return 0; +} + +static int vvdec_decode(AVCodecContext *avctx, void *data, int *got_frame, + AVPacket *avpkt) +{ + VVdecContext *s = (VVdecContext *)avctx->priv_data; + vvdec::VVDec* vvdec = s->vvdec; + AVFrame *picture = (AVFrame*)data; + int vret, ret = 0; + vvdec::Frame* frame = NULL; + + if (!avpkt->size) { + vret = vvdec->flush(&frame); + if ((ret = check_vret(s, vret)) < 0) { + goto error_out; + } + } else { + uint8_t *new_extradata; + int new_extradata_size; + new_extradata = av_packet_get_side_data(avpkt, AV_PKT_DATA_NEW_EXTRADATA, + &new_extradata_size); + if (new_extradata && new_extradata_size > 0) { + return AVERROR_PATCHWELCOME; + } + + vvdec::AccessUnit au; + au.m_pucBuffer = (unsigned char*)avpkt->data; + au.m_iUsedSize = avpkt->size; + au.m_uiCts = avpkt->pts; + au.m_bCtsValid = true; + vret = vvdec->decode(au, &frame); + if (vret && vret != vvdec::VVDEC_TRY_AGAIN) { + if ((ret = check_vret(s, vret)) < 0) { + goto error_out; + } + } + + } + if (frame) { + ret = copy_to_avframe(s, frame, picture); + if (ret < 0) + goto error_out; + *got_frame = 1; + } + return 0; +error_out: + if (frame) { + vvdec->objectUnref(frame); + } + return ret; +} + +static av_cold int vvdec_free(AVCodecContext *avctx) +{ + VVdecContext *ctx = (VVdecContext *)avctx->priv_data; + vvdec::VVDec* vvdec = ctx->vvdec; + if (vvdec) { + vvdec->uninit(); + delete vvdec; + } + return 0; +} + +static av_cold int vvdec_init(AVCodecContext *avctx) +{ + VVdecContext *s = (VVdecContext *)avctx->priv_data; + vvdec::VVDecParameter param; + vvdec::VVDec* vvdec = new vvdec::VVDec; + int vret, ret = 0; + + av_log(avctx, AV_LOG_INFO, "VVDec version: %s\n", vvdec->getVersionNumber()); + + s->avctx = avctx; + s->vvdec = vvdec; + vret = vvdec->init(param); + if ((ret = check_vret(s, vret)) < 0) { + delete vvdec; + s->vvdec = NULL; + } + return ret; +} + +extern "C" { + +AVCodec ff_libvvdec_decoder = { + .name = "vvdec", + .long_name = NULL_IF_CONFIG_SMALL("vvdec vvc decoder"), + .type = AVMEDIA_TYPE_VIDEO, + .id = AV_CODEC_ID_H266, + .capabilities = AV_CODEC_CAP_AUTO_THREADS | AV_CODEC_CAP_DR1 | AV_CODEC_CAP_DELAY, + .profiles = NULL_IF_CONFIG_SMALL(ff_h266_profiles), + .wrapper_name = "libvvdec", + .priv_data_size = sizeof(VVdecContext), + .init = vvdec_init, + .decode = vvdec_decode, + .close = vvdec_free, +}; + +}