Re: [FFmpeg-devel] [PATCH v2 09/13] lavc/vaapi_hevc: Add vaapi profile parse support for SCC
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 ?
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 08/13] lavc/vaapi_hevc: Pass SCC parameters Through VA-API
On Ma, 2022-12-05 at 14:09 +0800, Fei Wang wrote:
> 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..750738d36e 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 (i = 0; i < pre_palette_size; i++)
for (int i = 0; ..)
Thanks
Haihao
> +pic->pic_param.scc.predictor_palette_entries[comp][i] =
> +pps->pps_palette_predictor_initializers_present_flag ?
> +pps->pps_palette_predictor_initializer[comp][i]:
> +sps->sps_palette_predictor_initializer[comp][i];
> +}
> +
> #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_param_size = avctx->profile == FF_PROFILE_HEVC_REXT ?
> +int slice_param_size = avctx->profile >= FF_PROFILE_HEVC_REXT ?
> sizeof(pic->last_slice_param) :
> sizeof(VASliceParameterBufferHEVC);
>
> if (pic->last_size) {
> @@ -413,7 +451,7 @@ static int vaapi_hevc_decode_slice(AVCodecContext *avctx,
> VAAPIDecodePictureHEVC *pic = h->ref->hwaccel_picture_private;
> VASliceParameterBufferHEVC *last_slice_param =
> (VASliceParameterBufferHEVC *)>last_slice_param;
>
> -int slice_param_size = avctx->profile == FF_PROFILE_HEVC_REXT ?
> +int
[FFmpeg-devel] [PATCH] Doxygen: Ignore tableprint_vlc.h defines
[Note: Patch provided as an attachment to protect encoding/formatting.] The current official docs mistakenly pick up the override macros in libavcodec/tableprint_vlc.h as the canonical definitions of functions like av_free() and av_freep(), causing the docs to link to those #defines instead of the actual definitions of the functions (in libavutil/mem.c, for the examples given). Wrapping the rogue macros in a conditional documentation section (arbitrarily named DOXYGEN_IGNORE), which is then NOT added to the ENABLED_SECTIONS config in the Doxyfile, is the recommended method of telling Doxygen to ignore some piece of code. Ref: https://www.doxygen.nl/manual/faq.html#faq_code Ref: https://www.doxygen.nl/manual/commands.html#cmdcond Signed-off-by: FeRD (Frank Dana) From b7cce94eb92eccdd7b6d37770b4b994f8e3ef660 Mon Sep 17 00:00:00 2001 From: "FeRD (Frank Dana)" Date: Tue, 3 Jan 2023 00:29:02 -0500 Subject: [PATCH] Doxygen: Ignore tableprint_vlc.h defines The current official docs mistakenly pick up the override macros in libavcodec/tableprint_vlc.h as the canonical definitions of functions like av_free() and av_freep(), causing the docs to link to those #defines instead of the actual definitions of the functions (in libavutil/mem.c, for the examples given). Wrapping the rogue macros in a conditional documentation section (arbitrarily named DOXYGEN_IGNORE), which is then NOT added to the ENABLED_SECTIONS config in the Doxyfile, is the recommended method of telling Doxygen to ignore some piece of code. Ref: https://www.doxygen.nl/manual/faq.html#faq_code Ref: https://www.doxygen.nl/manual/commands.html#cmdcond Signed-off-by: FeRD (Frank Dana) --- libavcodec/tableprint_vlc.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/tableprint_vlc.h b/libavcodec/tableprint_vlc.h index b97c1f9cfb..ab32b91466 100644 --- a/libavcodec/tableprint_vlc.h +++ b/libavcodec/tableprint_vlc.h @@ -23,6 +23,7 @@ #ifndef AVCODEC_TABLEPRINT_VLC_H #define AVCODEC_TABLEPRINT_VLC_H +/** \cond DOXYGEN_IGNORE */ #define AVUTIL_LOG_H #define av_log(a, ...) while(0) #define ff_dlog(a, ...) while(0) @@ -34,6 +35,7 @@ #define av_freep(p) while(0) #define AVUTIL_INTERNAL_H #define avpriv_request_sample(...) +/** \endcond */ #include "tableprint.h" #include "vlc.h" #include "libavutil/reverse.c" -- 2.38.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 03/13] lavc/hevc_ps: Add SPS/PPS parse support for HEVC extension syntax
On Ma, 2022-12-05 at 14:09 +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 | 288 +--
> libavcodec/hevc_ps.h | 69 +++
> 3 files changed, 349 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
> index 1804755327..6b454a75c1 100644
> --- a/libavcodec/hevc.h
> +++ b/libavcodec/hevc.h
> @@ -154,6 +154,9 @@ enum {
> // get near that, though, so set a lower limit here with the maximum
> // possible value for 4K video (at most 135 16x16 Ctb rows).
> HEVC_MAX_ENTRY_POINT_OFFSETS = HEVC_MAX_TILE_COLUMNS * 135,
> +
> +// A.3.7: Screen content coding extensions
> +HEVC_MAX_PALETTE_PREDICTOR_SIZE = 128,
> };
>
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index ad92b6bcbc..3181962918 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -853,7 +853,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
> unsigned int *sps_id,
> HEVCWindow *ow;
> int ret = 0;
> int log2_diff_max_min_transform_block_size;
> -int bit_depth_chroma, start, vui_present, sublayer_ordering_info;
> +int bit_depth_chroma, start, vui_present, sublayer_ordering_info,
> num_comps;
> int i;
>
> // Coded parameters
> @@ -1074,8 +1074,12 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
> unsigned int *sps_id,
> decode_vui(gb, avctx, apply_defdispwin, sps);
>
> if (get_bits1(gb)) { // sps_extension_flag
> -sps->sps_range_extension_flag = get_bits1(gb);
> -skip_bits(gb, 7); //sps_extension_7bits = get_bits(gb, 7);
> +sps->sps_range_extension_flag = get_bits1(gb);
> +sps->sps_multilayer_extension_flag = get_bits1(gb);
> +sps->sps_3d_extension_flag = get_bits1(gb);
> +sps->sps_scc_extension_flag= get_bits1(gb);
> +skip_bits(gb, 4); // sps_extension_4bits
> +
> if (sps->sps_range_extension_flag) {
> sps->transform_skip_rotation_enabled_flag = get_bits1(gb);
> sps->transform_skip_context_enabled_flag = get_bits1(gb);
> @@ -1101,6 +1105,57 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
> unsigned int *sps_id,
> av_log(avctx, AV_LOG_WARNING,
> "cabac_bypass_alignment_enabled_flag not yet
> implemented\n");
> }
> +
> +if (sps->sps_multilayer_extension_flag) {
> +skip_bits1(gb); // inter_view_mv_vert_constraint_flag
> +av_log(avctx, AV_LOG_WARNING,
> + "sps_multilayer_extension_flag not yet implemented\n");
> +}
> +
> +if (sps->sps_3d_extension_flag) {
> +for (i = 0; i <= 1; i++) {
> +skip_bits1(gb); // iv_di_mc_enabled_flag
> +skip_bits1(gb); // iv_mv_scal_enabled_flag
> +if (i == 0) {
> +get_ue_golomb_long(gb); // log2_ivmc_sub_pb_size_minus3
> +skip_bits1(gb); // iv_res_pred_enabled_flag
> +skip_bits1(gb); // depth_ref_enabled_flag
> +skip_bits1(gb); // vsp_mc_enabled_flag
> +skip_bits1(gb); // dbbp_enabled_flag
> +} else {
> +skip_bits1(gb); // tex_mc_enabled_flag
> +get_ue_golomb_long(gb); // log2_ivmc_sub_pb_size_minus3
> +skip_bits1(gb); // intra_contour_enabled_flag
> +skip_bits1(gb); // intra_dc_only_wedge_enabled_flag
> +skip_bits1(gb); // cqt_cu_part_pred_enabled_flag
> +skip_bits1(gb); // inter_dc_only_enabled_flag
> +skip_bits1(gb); // skip_intra_enabled_flag
> +}
> +}
> +av_log(avctx, AV_LOG_WARNING,
> + "sps_3d_extension_flag not yet implemented\n");
> +}
> +
> +if (sps->sps_scc_extension_flag) {
> +sps->sps_curr_pic_ref_enabled_flag = get_bits1(gb);
> +sps->palette_mode_enabled_flag = get_bits1(gb);
> +if (sps->palette_mode_enabled_flag) {
> +sps->palette_max_size = get_ue_golomb_long(gb);
> +sps->delta_palette_max_predictor_size =
> get_ue_golomb_long(gb);
> +sps->sps_palette_predictor_initializers_present_flag =
> get_bits1(gb);
> +
> +if (sps->sps_palette_predictor_initializers_present_flag) {
> +
[FFmpeg-devel] [PATCH] libavcodec/qsvenc: Enable 444 encoding for RGB input
From: Wenbin Chen MSDK/VPL uses 420 chroma format as default to encode RGB, and this is not a proper usage. Now enable 444 encoding for RGB input by default. RGB is encoded using 444 chroma format when user doesn't specify the profile or uses rext profile, otherwise, 420 is used. Signed-off-by: Wenbin Chen --- libavcodec/qsvenc.c | 4 1 file changed, 4 insertions(+) diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index 514a1e8148..150fc9c729 100644 --- a/libavcodec/qsvenc.c +++ b/libavcodec/qsvenc.c @@ -1088,6 +1088,10 @@ static int init_video_param(AVCodecContext *avctx, QSVEncContext *q) q->extco3.MaxFrameSizeI = q->max_frame_size_i; if (q->max_frame_size_p >= 0) q->extco3.MaxFrameSizeP = q->max_frame_size_p; +if (sw_format == AV_PIX_FMT_BGRA && +(q->profile == MFX_PROFILE_HEVC_REXT || +q->profile == MFX_PROFILE_UNKNOWN)) +q->extco3.TargetChromaFormatPlus1 = MFX_CHROMAFORMAT_YUV444 + 1; q->extco3.ScenarioInfo = q->scenario; } -- 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 1/2] libavcodec/qsvenc_av1: Add low_delay_brc support to av1_qsv encoder
On Ma, 2022-12-26 at 14:02 +0800, wenbin.chen-at-intel@ffmpeg.org wrote:
> From: Wenbin Chen
>
> Signed-off-by: Wenbin Chen
> ---
> doc/encoders.texi | 5 +
> libavcodec/qsvenc.c | 4
> libavcodec/qsvenc_av1.c | 1 +
> 3 files changed, 10 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index b8051cda3f..543b5e26a9 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -3850,6 +3850,11 @@ Extended bitrate control.
>
> @item @var{look_ahead_depth}
> Depth of look ahead in number frames, available when extbrc option is
> enabled.
> +
> +@item @var{low_delay_brc}
> +Setting this flag turns on or off LowDelayBRC feautre in qsv plugin, which
> provides
> +more accurate bitrate control to minimize the variance of bitstream size
> frame
> +by frame. Value: -1-default 0-off 1-on
> @end table
>
> @section snow
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 514a1e8148..f5c6a164bb 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -537,6 +537,7 @@ static void dump_video_av1_param(AVCodecContext *avctx,
> QSVEncContext *q,
>
> av_log(avctx, AV_LOG_VERBOSE, "WriteIVFHeaders: %s \n",
> print_threestate(av1_bs_param->WriteIVFHeaders));
> +av_log(avctx, AV_LOG_VERBOSE, "LowDelayBRC: %s\n", print_threestate(co3-
> >LowDelayBRC));
> }
> #endif
>
> @@ -1090,6 +1091,9 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
> q->extco3.MaxFrameSizeP = q->max_frame_size_p;
>
> q->extco3.ScenarioInfo = q->scenario;
> +} else if (avctx->codec_id == AV_CODEC_ID_AV1) {
> +if (q->low_delay_brc >= 0)
> +q->extco3.LowDelayBRC = q->low_delay_brc ?
> MFX_CODINGOPTION_ON : MFX_CODINGOPTION_OFF;
> }
>
> if (avctx->codec_id == AV_CODEC_ID_HEVC) {
> diff --git a/libavcodec/qsvenc_av1.c b/libavcodec/qsvenc_av1.c
> index bb9ad16927..1e7801fefe 100644
> --- a/libavcodec/qsvenc_av1.c
> +++ b/libavcodec/qsvenc_av1.c
> @@ -110,6 +110,7 @@ static const AVOption options[] = {
> QSV_OPTION_ADAPTIVE_I
> QSV_OPTION_ADAPTIVE_B
> QSV_OPTION_EXTBRC
> +QSV_OPTION_LOW_DELAY_BRC
> { "profile", NULL, OFFSET(qsv.profile), AV_OPT_TYPE_INT, { .i64 =
> MFX_PROFILE_UNKNOWN }, 0, INT_MAX, VE, "profile" },
> { "unknown" , NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_PROFILE_UNKNOWN }, INT_MIN, INT_MAX, VE, "profile" },
> { "main", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_PROFILE_AV1_MAIN }, INT_MIN, INT_MAX, VE, "profile" },
Patchset LGTM, will apply,
-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".
Re: [FFmpeg-devel] [PATCH 0/2] Interpolation filter using nvidia OFFRUC Library
On Tue, 3 Jan 2023 at 03:13, Philip Langdale wrote: > On Tue, 3 Jan 2023 02:39:19 +0300 > Dennis Mungai wrote: > > > Related, > > > > If this were to be implemented in mpv, can libplacebo pick up this > > feature spec as a filter in ffmpeg? Perhaps that would make such a > > feature easier to merge down the line, instead of re-implementing it > > directly in ffmpeg as an additional filter. > > > > Adding Niklaas to the thread. > > It doesn't make a difference. The licensing is fundamentally unusable > for an open-source project (and there are engineers at nvidia who know > this and wish they could write filters leveraging all their various > capabilities). The only thing with any nuance is what level of > `nonfree` a project is willing to have sitting in their repo. Most > projects (including mpv and libplacebo) would say "none", because it's > not worth the trouble. ffmpeg has gone back and forth on what exact > critera have to be met to qualify as mergeable vs unmergeable nonfree. > In the past we have accepted filters based around nvidia libraries with > prohibitive licensing - see the libnpp based filters, but I don't think > we have the appetite for that now. If we were to decide that this > filter was ok on that basis, I'd merge it, but honestly, the usability > benefit of it being in master is tiny vs all the other hoops you have > to jump through. > > Anyway - punchline: it is not easier to get this kind of thing merged > into other projects. > > --phil > Got it, thanks for the clarifications. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/2] Interpolation filter using nvidia OFFRUC Library
On Tue, 3 Jan 2023 02:39:19 +0300 Dennis Mungai wrote: > Related, > > If this were to be implemented in mpv, can libplacebo pick up this > feature spec as a filter in ffmpeg? Perhaps that would make such a > feature easier to merge down the line, instead of re-implementing it > directly in ffmpeg as an additional filter. > > Adding Niklaas to the thread. It doesn't make a difference. The licensing is fundamentally unusable for an open-source project (and there are engineers at nvidia who know this and wish they could write filters leveraging all their various capabilities). The only thing with any nuance is what level of `nonfree` a project is willing to have sitting in their repo. Most projects (including mpv and libplacebo) would say "none", because it's not worth the trouble. ffmpeg has gone back and forth on what exact critera have to be met to qualify as mergeable vs unmergeable nonfree. In the past we have accepted filters based around nvidia libraries with prohibitive licensing - see the libnpp based filters, but I don't think we have the appetite for that now. If we were to decide that this filter was ok on that basis, I'd merge it, but honestly, the usability benefit of it being in master is tiny vs all the other hoops you have to jump through. Anyway - punchline: it is not easier to get this kind of thing merged into other projects. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 0/2] Interpolation filter using nvidia OFFRUC Library
On Tue, 3 Jan 2023 at 02:22, Philip Langdale wrote: > This filter implements frame rate down/upsampling using nvidia's > Optical Flow FRUC (Frame Rate Up Conversion) library. It's neat because > you get realtime interpolation with a decent level of quality. It's > impractical because of licensing. > > I have no actual intention to merge this, as it doesn't even meet our > bar for a nonfree filter, and given the EULA restrictions with the SDK, > anyone who would want to use it can easily cherry-pick it into the > build they have to anyway. But I figured I'd send it to list as a way > of announcing that it exists. > > How nice would it be if nvidia had sane licensing on this stuff? > > I'll keep a branch at: https://github.com/philipl/FFmpeg/tree/fruc-me > > --phil > > Philip Langdale (2): > lavu/hwcontext_cuda: declare support for argb/abgr/rgba/bgra > avfilter/vf_nvoffruc: Add filter for nvidia's Optical Flow FRUC > library > > configure | 7 +- > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_nvoffruc.c | 644 + > libavutil/hwcontext_cuda.c | 4 + > 5 files changed, 654 insertions(+), 3 deletions(-) > create mode 100644 libavfilter/vf_nvoffruc.c > > -- > 2.37.2 Related, If this were to be implemented in mpv, can libplacebo pick up this feature spec as a filter in ffmpeg? Perhaps that would make such a feature easier to merge down the line, instead of re-implementing it directly in ffmpeg as an additional filter. Adding Niklaas to the thread. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] get_cabac_inline_x86: Don't inline if 32-bit Windows
On Tue, Jan 3, 2023 at 12:01 AM Christopher Degawa wrote: > > previouslly, it only was an issue with 32-bit clang from msys2's > mingw32 repo, however, at some point with an update to gcc 12.2.0, > the same issue popped up. Tested with a clean clone of ffmpeg, and even > tested with n5.0, but the issue persists, so I presume it's a compiler > issue. > > Related: https://trac.ffmpeg.org/ticket/8903 > I regularly build with 12.2 on win32 and its fine. In fact, there is a fate station for that: https://fate.ffmpeg.org/report.cgi?slot=x86_32-mingw-w64-dll-windows-native=20230102232810 So if you are seeing this issue, more details that trigger it will be required, and maybe a more targeted fix. - 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".
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_nvoffruc: Add filter for nvidia's Optical Flow FRUC library
On Tue, 3 Jan 2023 at 02:22, Philip Langdale wrote: > The NvOFFRUC library provides a GPU accelerated interpolation feature > based on nvidia's Optical Flow functionality. It's able to provide > reasonably high quality realtime interpolation to increase the frame > rate of a video stream - as opposed to vf_framerate that just does a > linear blend or vf_minterpolate that is anything but realtime. > > As interesting as that sounds, there are a lot of limitations that > mean this filter is mostly just a toy. > > 1. The licensing is useless. The library and header and distributed as >part of the Optical Flow SDK which has a proprietary EULA, so anyone >wanting to build the filter must obtain the SDK for both build and >runtime and the resulting binaries will be nonfree and >unredistributable. > > 2. The NvOFFRUC.h header doesn't even compile in pure C without >modification. > > 3. The library can only handle NV12 and "ARGB" (which realy means any >single plane, four channel, 8 bit format). This means it can't help >with our inevitable future dominated by 10+ bit formats. > > 4. The pitch handling logic in the library is very inflexiable, and it >assumes that for NV12, the UV plane is contiguous with the Y plane. >This actually ends up making it incompatible with nvdec output for >certain frame sizes. To avoid constantly fighting edge cases, I took >the brute force approach and copy the input and output frames >to/from CUarrays (which the library can accept) to give me a way to >ensure the correct layout is used. > > 5. The library is stateful in an unhelpful way. It is called with one >input frame, and one output buffer and always interpolates between >the passed input frame and the frame from the previous call. This >both requires special handling for the first frame, and also >prevents generating more than one intermediate frame. If you want >to do 3x or 4x etc interpolation, this approach doesn't work. > >So, again, I brute forced it by treating every interpolation as a >new session - calling it twice with each input frame, even if the >first frame happens to be the same as the last frame we called it >with. This allows us to generate as many intermediate frames as we >want, but it presumably consumes more GPU resources. > > 6. The library always creates a `NvOFFRUC` directory with an empty log >file in it in $PWD. What a niusance. > > But with all those caveats and limitations, it does actually work. I > was able to upsample a 24fps file to 144fps (my monitor limit) with > respectable results. In some situations, it starts bogging down, and > I'm not entirely sure where those limits are - certainly I can see it > consuming a significant percentage of GPU resources for large scaling > factors. > > The implementation here is heavily based on vf_framerate with the > blending function ripped out and replaced by NvOFFRUC. That means we > have all the nice properties in terms of being able to do non-integer > scaling, and downsampling via interpolation as well. > > Is this mergeable? No - but it was an interesting exercise and maybe > folks in narrow circumstances may find some genuine use from it. > > Signed-off-by: Philip Langdale > --- > configure | 7 +- > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_nvoffruc.c | 644 ++ > 4 files changed, 650 insertions(+), 3 deletions(-) > create mode 100644 libavfilter/vf_nvoffruc.c > > diff --git a/configure b/configure > index 675dc84f56..6ea9f89f97 100755 > --- a/configure > +++ b/configure > @@ -3691,6 +3691,7 @@ mptestsrc_filter_deps="gpl" > negate_filter_deps="lut_filter" > nlmeans_opencl_filter_deps="opencl" > nnedi_filter_deps="gpl" > +nvoffruc_filter_deps="ffnvcodec nonfree" > ocr_filter_deps="libtesseract" > ocv_filter_deps="libopencv" > openclsrc_filter_deps="opencl" > @@ -6450,9 +6451,9 @@ fi > if ! disabled ffnvcodec; then > ffnv_hdr_list="ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h > ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" > check_pkg_config ffnvcodec "ffnvcodec >= 12.0.16.0" "$ffnv_hdr_list" > "" || \ > - check_pkg_config ffnvcodec "ffnvcodec >= 11.1.5.2 ffnvcodec < 12.0" > "$ffnv_hdr_list" "" || \ > - check_pkg_config ffnvcodec "ffnvcodec >= 11.0.10.2 ffnvcodec < > 11.1" "$ffnv_hdr_list" "" || \ > - check_pkg_config ffnvcodec "ffnvcodec >= 8.1.24.14 ffnvcodec < 8.2" > "$ffnv_hdr_list" "" > + check_pkg_config ffnvcodec "ffnvcodec >= 11.1.5.3 ffnvcodec < 12.0" > "$ffnv_hdr_list" "" || \ > + check_pkg_config ffnvcodec "ffnvcodec >= 11.0.10.3 ffnvcodec < > 11.1" "$ffnv_hdr_list" "" || \ > + check_pkg_config ffnvcodec "ffnvcodec >= 8.1.24.15 ffnvcodec < 8.2" > "$ffnv_hdr_list" "" > fi > > if enabled_all libglslang libshaderc; then > diff --git a/libavfilter/Makefile b/libavfilter/Makefile >
[FFmpeg-devel] [PATCH 2/2] avfilter/vf_nvoffruc: Add filter for nvidia's Optical Flow FRUC library
The NvOFFRUC library provides a GPU accelerated interpolation feature based on nvidia's Optical Flow functionality. It's able to provide reasonably high quality realtime interpolation to increase the frame rate of a video stream - as opposed to vf_framerate that just does a linear blend or vf_minterpolate that is anything but realtime. As interesting as that sounds, there are a lot of limitations that mean this filter is mostly just a toy. 1. The licensing is useless. The library and header and distributed as part of the Optical Flow SDK which has a proprietary EULA, so anyone wanting to build the filter must obtain the SDK for both build and runtime and the resulting binaries will be nonfree and unredistributable. 2. The NvOFFRUC.h header doesn't even compile in pure C without modification. 3. The library can only handle NV12 and "ARGB" (which realy means any single plane, four channel, 8 bit format). This means it can't help with our inevitable future dominated by 10+ bit formats. 4. The pitch handling logic in the library is very inflexiable, and it assumes that for NV12, the UV plane is contiguous with the Y plane. This actually ends up making it incompatible with nvdec output for certain frame sizes. To avoid constantly fighting edge cases, I took the brute force approach and copy the input and output frames to/from CUarrays (which the library can accept) to give me a way to ensure the correct layout is used. 5. The library is stateful in an unhelpful way. It is called with one input frame, and one output buffer and always interpolates between the passed input frame and the frame from the previous call. This both requires special handling for the first frame, and also prevents generating more than one intermediate frame. If you want to do 3x or 4x etc interpolation, this approach doesn't work. So, again, I brute forced it by treating every interpolation as a new session - calling it twice with each input frame, even if the first frame happens to be the same as the last frame we called it with. This allows us to generate as many intermediate frames as we want, but it presumably consumes more GPU resources. 6. The library always creates a `NvOFFRUC` directory with an empty log file in it in $PWD. What a niusance. But with all those caveats and limitations, it does actually work. I was able to upsample a 24fps file to 144fps (my monitor limit) with respectable results. In some situations, it starts bogging down, and I'm not entirely sure where those limits are - certainly I can see it consuming a significant percentage of GPU resources for large scaling factors. The implementation here is heavily based on vf_framerate with the blending function ripped out and replaced by NvOFFRUC. That means we have all the nice properties in terms of being able to do non-integer scaling, and downsampling via interpolation as well. Is this mergeable? No - but it was an interesting exercise and maybe folks in narrow circumstances may find some genuine use from it. Signed-off-by: Philip Langdale --- configure | 7 +- libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_nvoffruc.c | 644 ++ 4 files changed, 650 insertions(+), 3 deletions(-) create mode 100644 libavfilter/vf_nvoffruc.c diff --git a/configure b/configure index 675dc84f56..6ea9f89f97 100755 --- a/configure +++ b/configure @@ -3691,6 +3691,7 @@ mptestsrc_filter_deps="gpl" negate_filter_deps="lut_filter" nlmeans_opencl_filter_deps="opencl" nnedi_filter_deps="gpl" +nvoffruc_filter_deps="ffnvcodec nonfree" ocr_filter_deps="libtesseract" ocv_filter_deps="libopencv" openclsrc_filter_deps="opencl" @@ -6450,9 +6451,9 @@ fi if ! disabled ffnvcodec; then ffnv_hdr_list="ffnvcodec/nvEncodeAPI.h ffnvcodec/dynlink_cuda.h ffnvcodec/dynlink_cuviddec.h ffnvcodec/dynlink_nvcuvid.h" check_pkg_config ffnvcodec "ffnvcodec >= 12.0.16.0" "$ffnv_hdr_list" "" || \ - check_pkg_config ffnvcodec "ffnvcodec >= 11.1.5.2 ffnvcodec < 12.0" "$ffnv_hdr_list" "" || \ - check_pkg_config ffnvcodec "ffnvcodec >= 11.0.10.2 ffnvcodec < 11.1" "$ffnv_hdr_list" "" || \ - check_pkg_config ffnvcodec "ffnvcodec >= 8.1.24.14 ffnvcodec < 8.2" "$ffnv_hdr_list" "" + check_pkg_config ffnvcodec "ffnvcodec >= 11.1.5.3 ffnvcodec < 12.0" "$ffnv_hdr_list" "" || \ + check_pkg_config ffnvcodec "ffnvcodec >= 11.0.10.3 ffnvcodec < 11.1" "$ffnv_hdr_list" "" || \ + check_pkg_config ffnvcodec "ffnvcodec >= 8.1.24.15 ffnvcodec < 8.2" "$ffnv_hdr_list" "" fi if enabled_all libglslang libshaderc; then diff --git a/libavfilter/Makefile b/libavfilter/Makefile index cb41ccc622..292597f3a8 100644 --- a/libavfilter/Makefile +++ b/libavfilter/Makefile @@ -389,6 +389,7 @@ OBJS-$(CONFIG_NOFORMAT_FILTER) += vf_format.o OBJS-$(CONFIG_NOISE_FILTER) += vf_noise.o
[FFmpeg-devel] [PATCH 0/2] Interpolation filter using nvidia OFFRUC Library
This filter implements frame rate down/upsampling using nvidia's Optical Flow FRUC (Frame Rate Up Conversion) library. It's neat because you get realtime interpolation with a decent level of quality. It's impractical because of licensing. I have no actual intention to merge this, as it doesn't even meet our bar for a nonfree filter, and given the EULA restrictions with the SDK, anyone who would want to use it can easily cherry-pick it into the build they have to anyway. But I figured I'd send it to list as a way of announcing that it exists. How nice would it be if nvidia had sane licensing on this stuff? I'll keep a branch at: https://github.com/philipl/FFmpeg/tree/fruc-me --phil Philip Langdale (2): lavu/hwcontext_cuda: declare support for argb/abgr/rgba/bgra avfilter/vf_nvoffruc: Add filter for nvidia's Optical Flow FRUC library configure | 7 +- libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/vf_nvoffruc.c | 644 + libavutil/hwcontext_cuda.c | 4 + 5 files changed, 654 insertions(+), 3 deletions(-) create mode 100644 libavfilter/vf_nvoffruc.c -- 2.37.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] lavu/hwcontext_cuda: declare support for argb/abgr/rgba/bgra
These can be useful.
Signed-off-by: Philip Langdale
---
libavutil/hwcontext_cuda.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 5ae7711c94..22eb9f5513 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@@ -45,6 +45,10 @@ static const enum AVPixelFormat supported_formats[] = {
AV_PIX_FMT_YUV444P16,
AV_PIX_FMT_0RGB32,
AV_PIX_FMT_0BGR32,
+AV_PIX_FMT_ARGB,
+AV_PIX_FMT_ABGR,
+AV_PIX_FMT_RGBA,
+AV_PIX_FMT_BGRA,
#if CONFIG_VULKAN
AV_PIX_FMT_VULKAN,
#endif
--
2.37.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Rework color quantization in palette{gen,use}
On Mon, Jan 02, 2023 at 10:57:33PM +0100, Michael Niedermayer wrote: [...] > > So I did a lot of experiments, and the explanation for the desaturated > > output at low number of colors can be found at the end of this article: > > http://blog.pkh.me/p/39-improving-color-quantization-heuristics.html > > interresting and its impressive how much reseacrh you did here > i hope this will get applied Thanks. I was actually planning to push in the next 12 hours or so, unless there is an objection. > also i hape a bit that it will get > extended to include clustering as in ELBG cuz it seems a bit odd > to have this sort of alternative filters neither does all Yeah at some point we probably want to group the clustering and vector quantization logics in a common module. But there are lot of questions API wise wrt its relationship with perceptual and other color systems. > > I still think it's acceptable to lean toward desaturated colors when > > reducing the number of colors, but you may disagree. > > I think a key aspect of desaturation has not been mentioned. > That is mixing, i mean dithering is some sort of mixing, in the sense of > an artist mixing several pigment/dyes/colors. > If you have black and white a 50% mixture gives 50% gray. other ratios > would give us all values between white and black though with dithering > some ratios work better like 50% looks good while ratios very close to > 0 and 100% but not exacty 0 and 100 look bad with few highly vissible > black or white pixels in a see of the opposing color. > > Now this results in 2 things at least. > 1. We should be able to improve color quantization by this. > If we have colors A and B the (A+B)/2 point is basically free, its dither > pattern looks good on any high resolution display and if we consider such > points there are more of course like maybe (A+B+C+D)/4 we can cover more > output colors with a smaller palette. That's interesting. Basically you'd free certain slots of the palette if you detect that this particular color is at the mid point of two others in the palette? And so you could use that slot for another tint… Yeah I don't know what to do with this information, it looks not trivial to implement. > 2. desaturation happens in dithered images because colors are simply not > representable, the same way a artist cant paint 100% white if the brightest > color she has is 80% white. She cant mix that with anything to make it > brighter. An algorithm which would ensure that the colors from the palette > form a convex hull around all the colors of the input would ensure all > colors are representable and no desaturation should happen. it of course > may look bad, i dont know, A convex hull likely is not the global optimum > from a perceptual POV. But one only needs 8 colors to gurantee all colors > are representable with dithering I feel like a cheap hack would be to create a filter such as "palettesource" which generates a palette using OkLCh (same as OkLab but circular space, the hue is an angle) to design such palette. That's easy to do and you could immediately test it by feeding it to paletteuse. > Another way to maybe see this is that if you have 1 color the best place > is teh one where it minimizes the distance to all. But as more points are > added average points between them become usable in a dithered image so > the thing starts filling up while the perimeter and outside is harder > to represent > One could also say that with 2 colors all points on the line joining > them can be represented and so distance to that line could be minimized > but as not really all points on that line form pleasing dither patterns > iam hesitant about this representation but it can be extended to a triangle > and so forth with more points > > Now i hope i have not given any ideas that make you spend more months on > this if you dont enjoy it :) But i find the whole myself a bit interresting Heh, yeah I'm already onto another crazy topic currently so you'll have to do it on your own :) BTW it was rightfully pointed out to me that in addition to the box and the axis selections, there is a 3rd aspect to study: the median cut itself. There is likely something better to do here that would use the values themselves instead of just a cut at the median of the set, specifically if there are large gaps in the values. For example [1,2,3,6,7,8,231,255] (assuming weights of 1) would be cut [1,2,3,6] [7,8,231,255] when [1,2,3,6,7,8] [231,255] would probably be much more appropriate. It might help addressing the bias toward L* for low number of colors where these irregularities are particularly common (and tend to smooth out over cuts because typically [7,8,231,255] is likely to be cut again soon due to its variance). I feel like it might not be that hard to actually improve the low color count by trying out some alternatives. But there are many cut solutions approaches which need to be measured. I'm happy to provide
[FFmpeg-devel] [PATCH] get_cabac_inline_x86: Don't inline if 32-bit Windows
previouslly, it only was an issue with 32-bit clang from msys2's mingw32 repo, however, at some point with an update to gcc 12.2.0, the same issue popped up. Tested with a clean clone of ffmpeg, and even tested with n5.0, but the issue persists, so I presume it's a compiler issue. Related: https://trac.ffmpeg.org/ticket/8903 Signed-off-by: Christopher Degawa --- libavcodec/x86/cabac.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/x86/cabac.h b/libavcodec/x86/cabac.h index b046a56a6b..70f990db8d 100644 --- a/libavcodec/x86/cabac.h +++ b/libavcodec/x86/cabac.h @@ -178,7 +178,7 @@ #if HAVE_7REGS && !BROKEN_COMPILER #define get_cabac_inline get_cabac_inline_x86 static -#if defined(_WIN32) && !defined(_WIN64) && defined(__clang__) +#if defined(_WIN32) && !defined(_WIN64) av_noinline #else av_always_inline -- 2.39.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Rework color quantization in palette{gen,use}
Hi On Sat, Dec 31, 2022 at 01:11:54PM +0100, Clément Bœsch wrote: > On Sun, Nov 06, 2022 at 06:30:22PM +0100, Michael Niedermayer wrote: > > On Sun, Nov 06, 2022 at 06:09:41PM +0100, Michael Niedermayer wrote: > > > On Sat, Nov 05, 2022 at 04:26:02PM +0100, Clément Bœsch wrote: > > > > Hi, > > > > > > > > This patchset essentially fixes a few core problems in these filters and > > > > switches to a perceptual model. > > > > > > > > I've generated a report for each key commit on this (temporary) page: > > > > http://big.pkh.me/pal/ (warning: heavy page, ~500M; I did try to add > > > > some lazy > > > > loading of the images but I'm not sure it's actually working as > > > > expected). > > > > > > i just looked at file00 and 16 and 64 colors with dither for it and they > > > look > > > different, some areas look better before and some better afterwards > > > > looked at more of the 16 color cases with dither > > (16 colors as i asumed fewer would magnify any issues ) > > file 01, IMHO current looks better than last (variance per axis) > > file 02, IMHO current looks better than last (variance per axis) > > file 03, IMHO VPA looks better but both really are quite off in terms of > > color, > > thats not the color of the original image. > > file 04, VPA is not good thats not the correct color > > > > It seems th last (variance per axis) is more pale and looses color > > So I did a lot of experiments, and the explanation for the desaturated > output at low number of colors can be found at the end of this article: > http://blog.pkh.me/p/39-improving-color-quantization-heuristics.html interresting and its impressive how much reseacrh you did here i hope this will get applied also i hape a bit that it will get extended to include clustering as in ELBG cuz it seems a bit odd to have this sort of alternative filters neither does all > > I still think it's acceptable to lean toward desaturated colors when > reducing the number of colors, but you may disagree. I think a key aspect of desaturation has not been mentioned. That is mixing, i mean dithering is some sort of mixing, in the sense of an artist mixing several pigment/dyes/colors. If you have black and white a 50% mixture gives 50% gray. other ratios would give us all values between white and black though with dithering some ratios work better like 50% looks good while ratios very close to 0 and 100% but not exacty 0 and 100 look bad with few highly vissible black or white pixels in a see of the opposing color. Now this results in 2 things at least. 1. We should be able to improve color quantization by this. If we have colors A and B the (A+B)/2 point is basically free, its dither pattern looks good on any high resolution display and if we consider such points there are more of course like maybe (A+B+C+D)/4 we can cover more output colors with a smaller palette. 2. desaturation happens in dithered images because colors are simply not representable, the same way a artist cant paint 100% white if the brightest color she has is 80% white. She cant mix that with anything to make it brighter. An algorithm which would ensure that the colors from the palette form a convex hull around all the colors of the input would ensure all colors are representable and no desaturation should happen. it of course may look bad, i dont know, A convex hull likely is not the global optimum from a perceptual POV. But one only needs 8 colors to gurantee all colors are representable with dithering Another way to maybe see this is that if you have 1 color the best place is teh one where it minimizes the distance to all. But as more points are added average points between them become usable in a dithered image so the thing starts filling up while the perimeter and outside is harder to represent One could also say that with 2 colors all points on the line joining them can be represented and so distance to that line could be minimized but as not really all points on that line form pleasing dither patterns iam hesitant about this representation but it can be extended to a triangle and so forth with more points Now i hope i have not given any ideas that make you spend more months on this if you dont enjoy it :) But i find the whole myself a bit interresting [...] thx -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Any man who breaks a law that conscience tells him is unjust and willingly accepts the penalty by staying in jail in order to arouse the conscience of the community on the injustice of the law is at that moment expressing the very highest respect for law. - Martin Luther King Jr signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/vaapi_encode_h26x: passthrough A53 CC data as H264/HEVC SEI
From: Aman Karmani
Signed-off-by: Aman Karmani
---
avcodec/vaapi_encode_h26x: passthrough A53 CC data as H264/HEVC SEI
Published-As:
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-46%2Ftmm1%2Fvaapi-a53cc-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg
pr-ffstaging-46/tmm1/vaapi-a53cc-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/46
libavcodec/vaapi_encode_h264.c | 27 ++-
libavcodec/vaapi_encode_h265.c | 27 ++-
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index b1b503b2a6..d22b38ab38 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -26,6 +26,7 @@
#include "libavutil/internal.h"
#include "libavutil/opt.h"
+#include "atsc_a53.h"
#include "avcodec.h"
#include "cbs.h"
#include "cbs_h264.h"
@@ -40,6 +41,7 @@ enum {
SEI_TIMING = 0x01,
SEI_IDENTIFIER = 0x02,
SEI_RECOVERY_POINT = 0x04,
+SEI_A53_CC = 0x08,
};
// Random (version 4) ISO 11578 UUID.
@@ -98,6 +100,8 @@ typedef struct VAAPIEncodeH264Context {
H264RawSEIRecoveryPointsei_recovery_point;
SEIRawUserDataUnregistered sei_identifier;
char *sei_identifier_string;
+SEIRawUserDataRegistered sei_a53cc;
+void *sei_a53cc_data;
int aud_needed;
int sei_needed;
@@ -248,6 +252,13 @@ static int
vaapi_encode_h264_write_extra_header(AVCodecContext *avctx,
if (err < 0)
goto fail;
}
+if (priv->sei_needed & SEI_A53_CC) {
+err = ff_cbs_sei_add_message(priv->cbc, au, 1,
+
SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35,
+ >sei_a53cc, NULL);
+if (err < 0)
+goto fail;
+}
priv->sei_needed = 0;
@@ -607,7 +618,8 @@ static int
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
VAAPIEncodePicture *prev = pic->prev;
VAAPIEncodeH264Picture *hprev = prev ? prev->priv_data : NULL;
VAEncPictureParameterBufferH264 *vpic = pic->codec_picture_params;
-int i;
+int i, err;
+size_t sei_a53cc_len;
if (pic->type == PICTURE_TYPE_IDR) {
av_assert0(pic->display_order == pic->encode_order);
@@ -681,6 +693,18 @@ static int
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
priv->sei_needed |= SEI_RECOVERY_POINT;
}
+av_freep(>sei_a53cc_data);
+err = ff_alloc_a53_sei(pic->input_image, 0, >sei_a53cc_data,
_a53cc_len);
+if (err < 0)
+return err;
+if (priv->sei_a53cc_data != NULL) {
+priv->sei_a53cc.itu_t_t35_country_code = 181;
+priv->sei_a53cc.data = (uint8_t *)priv->sei_a53cc_data + 1;
+priv->sei_a53cc.data_length = sei_a53cc_len - 1;
+
+priv->sei_needed |= SEI_A53_CC;
+}
+
vpic->CurrPic = (VAPictureH264) {
.picture_id = pic->recon_surface,
.frame_idx = hpic->frame_num,
@@ -1226,6 +1250,7 @@ static av_cold int vaapi_encode_h264_close(AVCodecContext
*avctx)
ff_cbs_fragment_free(>current_access_unit);
ff_cbs_close(>cbc);
av_freep(>sei_identifier_string);
+av_freep(>sei_a53cc_data);
return ff_vaapi_encode_close(avctx);
}
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 94b56c6578..3611bd6147 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -27,6 +27,7 @@
#include "libavutil/opt.h"
#include "libavutil/mastering_display_metadata.h"
+#include "atsc_a53.h"
#include "avcodec.h"
#include "cbs.h"
#include "cbs_h265.h"
@@ -40,6 +41,7 @@
enum {
SEI_MASTERING_DISPLAY = 0x08,
SEI_CONTENT_LIGHT_LEVEL = 0x10,
+SEI_A53_CC = 0x20,
};
typedef struct VAAPIEncodeH265Picture {
@@ -84,6 +86,8 @@ typedef struct VAAPIEncodeH265Context {
SEIRawMasteringDisplayColourVolume sei_mastering_display;
SEIRawContentLightLevelInfosei_content_light_level;
+SEIRawUserDataRegistered sei_a53cc;
+void *sei_a53cc_data;
CodedBitstreamContext *cbc;
CodedBitstreamFragment current_access_unit;
@@ -226,6 +230,13 @@ static int
vaapi_encode_h265_write_extra_header(AVCodecContext *avctx,
if (err < 0)
goto fail;
}
+if (priv->sei_needed & SEI_A53_CC) {
+err = ff_cbs_sei_add_message(priv->cbc, au, 1,
+
SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35,
+ >sei_a53cc, NULL);
+if (err < 0)
+goto fail;
+}
priv->sei_needed = 0;
@@ -759,7 +770,8 @@ static int
vaapi_encode_h265_init_picture_params(AVCodecContext
[FFmpeg-devel] [PATCH] avcodec/mpeg12dec: flush a53 data
From: Aman Karmani Signed-off-by: Aman Karmani --- avcodec/mpeg12dec: flush a53 data Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-45%2Ftmm1%2Fmpeg2-a53-flush-v1 Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-45/tmm1/mpeg2-a53-flush-v1 Pull-Request: https://github.com/ffstaging/FFmpeg/pull/45 libavcodec/mpeg12dec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c index 914516bbd9..fee2d4a10e 100644 --- a/libavcodec/mpeg12dec.c +++ b/libavcodec/mpeg12dec.c @@ -2845,6 +2845,7 @@ static void flush(AVCodecContext *avctx) s->sync = 0; s->closed_gop = 0; +av_buffer_unref(>a53_buf_ref); ff_mpeg_flush(avctx); } base-commit: 3bcec58535d395945a390bdc7af4048a7abc60eb -- ffmpeg-codebot ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] lavfi/dnn: Remove DNN native backend
> -Original Message- > From: ffmpeg-devel On Behalf Of > Michael Niedermayer > Sent: Monday, January 2, 2023 07:26 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavfi/dnn: Remove DNN native > backend > > On Fri, Dec 30, 2022 at 04:42:56PM +0800, Ting Fu wrote: > > According to discussion in > > https://etherpad.mit.edu/p/FF_dev_meeting_20221202. > > The DNN native backend should be removed at first step. > > All the DNN native backend related code is deleted. > > > > Signed-off-by: Ting Fu > > This patch seems breaking > > make testprogs > make: *** No rule to make target 'libavfilter/tests/dnn-layer-avgpool.c', > needed by 'libavfilter/tests/dnn-layer-avgpool.o'. Stop. > > and with a distclean and some configure > > make testprogs > LDlibavfilter/tests/dnn-layer-avgpool > gcc: error: libavfilter/tests/dnn-layer-avgpool.o: No such file or directory > ffbuild/library.mak:118: recipe for target > 'libavfilter/tests/dnn-layer-avgpool' > failed > make: *** [libavfilter/tests/dnn-layer-avgpool] Error 1 Hi Michael, Sorry for 'make testprogs' failed. This was caused by not deleting code in make target 'testprogs' in libavfilter/Makefile. I have done it and updated V2. Local make passed for all targets. Thank you Ting Fu > > [...] > > -- > Michael GnuPG fingerprint: > 9FF2128B147EF6730BADF133611EC787040B0FAB > > The educated differ from the uneducated as much as the living from the > dead. -- Aristotle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH V2 1/2] lavfi/dnn: Modify error message for incorrect backend_type
Signed-off-by: Ting Fu --- libavfilter/dnn/dnn_interface.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/dnn/dnn_interface.c b/libavfilter/dnn/dnn_interface.c index 554a36b0dc..fa484c0905 100644 --- a/libavfilter/dnn/dnn_interface.c +++ b/libavfilter/dnn/dnn_interface.c @@ -71,7 +71,7 @@ DNNModule *ff_get_dnn_module(DNNBackendType backend_type) #endif break; default: -av_log(NULL, AV_LOG_ERROR, "Module backend_type is not native or tensorflow\n"); +av_log(NULL, AV_LOG_ERROR, "Module backend_type is not supported or enabled.\n"); av_freep(_module); return NULL; } -- 2.17.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in Changelog and MAINTAINERS files
-Original Message-
From: ffmpeg-devel On Behalf Of Michael
Niedermayer
Sent: środa, 14 grudnia 2022 22:36
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] [PATCH v14 9/9] avcodec/evc: Changes in
Changelog and MAINTAINERS files
On Tue, Dec 13, 2022 at 08:33:29AM -0500, Ronald S. Bultje wrote:
> Hi David,
>
> On Tue, Dec 13, 2022 at 7:22 AM Dawid Kozinski/Multimedia (PLT)
> /SRPOL/Staff Engineer/Samsung Electronics wrote:
>
> > Should I leave the following lines:
> > + libxevd.c Dawid Kozinski
> > + libxeve.c,Dawid Kozinski
> > + evc.c, evc.hDawid Kozinski
> > + evcdec.c Dawid Kozinski
> > + evc_parser.c Dawid Kozinski
> >
> > or should I remove them?
> >
>
> Here's a question for you, and the answer probably becomes
> self-evident from that. If you, Dawid, stop working for Samsung, for
> example because you're starting your own business or Samsung fires you
> or Google hires you, or if Samsung stops sponsoring this new codec
> called "EVC" or stops contributing to this new library "libxeve". Will
> you, Dawid, still maintain these files?
>
> If the answer is yes, then you can shorten these lines ("evc*.[ch]: Dawid"
> & "livxev[ed].c: Dawid") and keep them.
>
> If the answer is no, then I think you should remove (or adjust) these
> lines, since they are (in their current form) inaccurate: you are not
> maintaining these files, your company is.
>
I think for code maintained by a company we still should list a person
because persons can be contacted while large companies are sometimes very
difficult to contact.
maybe
Dawid Kozinski (Samsung) or Samsung (Dawid Kozinski) or something like that
would specify this better
thx
DK
Since there is no further discussion related to the MAINTAINERS file, I've
added "Samsung (Dawid Koziński)" entries next to the EVC codec related
files.
I've just submitted the newest version of our implementation and waiting for
the review or merge.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"I am not trying to be anyone's saviour, I'm trying to think about the
future and not be sad" - Elon Musk
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v16 9/9] avcodec/evc: Changes in Changelog file
- Changelog update - MAINTAINERS file update Signed-off-by: Dawid Kozinski --- Changelog | 2 ++ MAINTAINERS | 3 +++ 2 files changed, 5 insertions(+) diff --git a/Changelog b/Changelog index f3a6abb9cd..ab6a8d2f1e 100644 --- a/Changelog +++ b/Changelog @@ -55,6 +55,8 @@ version 5.1: - remap_opencl filter - added chromakey_cuda filter - added bilateral_cuda filter +- eXtra-fast Essential Video Encoder (XEVE) +- eXtra-fast Essential Video Decoder (XEVD) version 5.0: diff --git a/MAINTAINERS b/MAINTAINERS index 48e2ec4fd4..565bd03b5d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -199,6 +199,8 @@ Codecs: libvpx* James Zern libxavs.c Stefan Gehrer libxavs2.cHuiwen Ren + libxevd.c Samsung (Dawid Kozinski) + libxeve.c Samsung (Dawid Kozinski) libzvbi-teletextdec.c Marton Balint lzo.h, lzo.c Reimar Doeffinger mdec.cMichael Niedermayer @@ -419,6 +421,7 @@ Muxers/Demuxers: dv.c Roman Shaposhnik electronicarts.c Peter Ross epafdec.c Paul B Mahol + evc* Samsung (Dawid Kozinski) ffm* Baptiste Coudurier flic.cMike Melanson flvdec.c Michael Niedermayer -- 2.37.3.windows.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] [PATCH v16 8/9] avformat/mov_demuxer: Extended MOV demuxer to handle EVC video content
- Added evc extension to the list of extensions for ff_mov_demuxer
Signed-off-by: Dawid Kozinski
---
libavformat/demux.c | 1 +
libavformat/mov.c | 3 ++-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 2dfd82a63c..f3ebe4d09b 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -120,6 +120,7 @@ static int set_codec_from_probe_data(AVFormatContext *s,
AVStream *st,
{ "mp3",AV_CODEC_ID_MP3, AVMEDIA_TYPE_AUDIO},
{ "mpegvideo", AV_CODEC_ID_MPEG2VIDEO, AVMEDIA_TYPE_VIDEO},
{ "truehd", AV_CODEC_ID_TRUEHD, AVMEDIA_TYPE_AUDIO},
+{ "evc",AV_CODEC_ID_EVC, AVMEDIA_TYPE_VIDEO},
{ 0 }
};
int score;
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 29bd3103e3..ab1776e1c4 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2507,6 +2507,7 @@ static int mov_finalize_stsd_codec(MOVContext *c,
AVIOContext *pb,
case AV_CODEC_ID_VP9:
sti->need_parsing = AVSTREAM_PARSE_FULL;
break;
+case AV_CODEC_ID_EVC:
case AV_CODEC_ID_AV1:
/* field_order detection of H264 requires parsing */
case AV_CODEC_ID_H264:
@@ -9135,7 +9136,7 @@ const AVInputFormat ff_mov_demuxer = {
.long_name = NULL_IF_CONFIG_SMALL("QuickTime / MOV"),
.priv_class = _class,
.priv_data_size = sizeof(MOVContext),
-.extensions = "mov,mp4,m4a,3gp,3g2,mj2,psp,m4b,ism,ismv,isma,f4v,avif",
+.extensions =
"mov,mp4,m4a,3gp,3g2,mj2,psp,m4b,ism,ismv,isma,f4v,avif,evc",
.flags_internal = FF_FMT_INIT_CLEANUP,
.read_probe = mov_probe,
.read_header= mov_read_header,
--
2.37.3.windows.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] [PATCH v16 7/9] avformat/mov_muxer: Extended MOV muxer to handle EVC video content
- Changes in mov_write_video_tag function to handle EVC elementary stream
- Provided structure EVCDecoderConfigurationRecord that specifies the decoder
configuration information for ISO/IEC 23094-1 video content
Signed-off-by: Dawid Kozinski
---
libavformat/Makefile| 2 +-
libavformat/evc.c | 455
libavformat/evc.h | 44
libavformat/isom_tags.c | 2 +
libavformat/movenc.c| 33 +++
5 files changed, 535 insertions(+), 1 deletion(-)
create mode 100644 libavformat/evc.c
create mode 100644 libavformat/evc.h
diff --git a/libavformat/Makefile b/libavformat/Makefile
index af175d2097..6ae5056c61 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -363,7 +363,7 @@ OBJS-$(CONFIG_MOV_DEMUXER) += mov.o
mov_chan.o mov_esds.o \
OBJS-$(CONFIG_MOV_MUXER) += movenc.o av1.o avc.o hevc.o vpcc.o
\
movenchint.o mov_chan.o rtp.o \
movenccenc.o movenc_ttml.o
rawutils.o \
-dovi_isom.o
+dovi_isom.o evc.o
OBJS-$(CONFIG_MP2_MUXER) += rawenc.o
OBJS-$(CONFIG_MP3_DEMUXER) += mp3dec.o replaygain.o
OBJS-$(CONFIG_MP3_MUXER) += mp3enc.o rawenc.o id3v2enc.o
diff --git a/libavformat/evc.c b/libavformat/evc.c
new file mode 100644
index 00..42b7731c8f
--- /dev/null
+++ b/libavformat/evc.c
@@ -0,0 +1,455 @@
+/*
+ * EVC helper functions for muxers
+ * Copyright (c) 2022 Dawid Kozinski
+ *
+ * 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
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "libavcodec/get_bits.h"
+#include "libavcodec/golomb.h"
+#include "libavcodec/evc.h"
+#include "avformat.h"
+#include "avio.h"
+#include "evc.h"
+#include "avio_internal.h"
+
+// The length field that indicates the length in bytes of the following NAL
unit is configured to be of 4 bytes
+#define EVC_NALU_LENGTH_PREFIX_SIZE(4) /* byte */
+#define EVC_NALU_HEADER_SIZE (2) /* byte */
+
+// @see ISO/IEC 14496-15:2021 Coding of audio-visual objects - Part 15:
section 12.3.3.1
+enum {
+SPS_INDEX,
+PPS_INDEX,
+APS_INDEX,
+SEI_INDEX,
+NB_ARRAYS
+};
+
+// rpl structure
+typedef struct RefPicListStruct {
+int poc;
+int tid;
+int ref_pic_num;
+int ref_pic_active_num;
+int ref_pics[EVC_MAX_NUM_REF_PICS];
+char pic_type;
+
+} RefPicListStruct;
+
+// The sturcture reflects SPS RBSP(raw byte sequence payload) layout
+// @see ISO_IEC_23094-1 section 7.3.2.1
+//
+// The following descriptors specify the parsing process of each element
+// u(n) - unsigned integer using n bits
+// ue(v) - unsigned integer 0-th order Exp_Golomb-coded syntax element with
the left bit first
+typedef struct EVCSPS {
+int sps_seq_parameter_set_id; // ue(v)
+int profile_idc;// u(8)
+int level_idc; // u(8)
+int toolset_idc_h; // u(32)
+int toolset_idc_l; // u(32)
+int chroma_format_idc; // ue(v)
+int pic_width_in_luma_samples; // ue(v)
+int pic_height_in_luma_samples; // ue(v)
+int bit_depth_luma_minus8; // ue(v)
+int bit_depth_chroma_minus8;// ue(v)
+
+// @note
+// Currently the structure does not reflect the entire SPS RBSP layout.
+// It contains only the fields that are necessary to read from the NAL
unit all the values
+// necessary for the correct initialization of
EVCDecoderConfigurationRecord
+
+// @note
+// If necessary, add the missing fields to the structure to reflect
+// the contents of the entire NAL unit of the SPS type
+
+} EVCSPS;
+
+// @see ISO/IEC 14496-15:2021 Coding of audio-visual objects - Part 15:
section 12.3.3.3
+typedef struct EVCNALUnitArray {
+uint8_t array_completeness; // when equal to 1 indicates that all NAL
units of the given type are in the following array
+uint8_t NAL_unit_type; // indicates the type of the NAL units in the
following array
+uint16_t numNalus; // indicates the number of NAL units of the
indicated type
+uint16_t *nalUnitLength; //
[FFmpeg-devel] [PATCH v16 6/9] avcodec/evc_decoder: Provided support for EVC decoder
- Added EVC decoder wrapper
- Changes in project configuration file and libavcodec Makefile
- Added documentation for xevd wrapper
Signed-off-by: Dawid Kozinski
---
configure | 4 +
doc/decoders.texi | 24 +++
doc/general_contents.texi | 10 +-
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/libxevd.c | 400 ++
6 files changed, 439 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/libxevd.c
diff --git a/configure b/configure
index 392169a4ee..f9b83b7166 100755
--- a/configure
+++ b/configure
@@ -292,6 +292,7 @@ External library support:
--enable-libx264 enable H.264 encoding via x264 [no]
--enable-libx265 enable HEVC encoding via x265 [no]
--enable-libxeve enable EVC encoding via libxeve [no]
+ --enable-libxevd enable EVC decoding via libxevd [no]
--enable-libxavs enable AVS encoding via xavs [no]
--enable-libxavs2enable AVS2 encoding via xavs2 [no]
--enable-libxcb enable X11 grabbing using XCB [autodetect]
@@ -1863,6 +1864,7 @@ EXTERNAL_LIBRARY_LIST="
libvorbis
libvpx
libwebp
+libxevd
libxeve
libxml2
libzimg
@@ -3396,6 +3398,7 @@ libx265_encoder_deps="libx265"
libx265_encoder_select="atsc_a53"
libxavs_encoder_deps="libxavs"
libxavs2_encoder_deps="libxavs2"
+libxevd_decoder_deps="libxevd"
libxeve_encoder_deps="libxeve"
libxvid_encoder_deps="libxvid"
libzvbi_teletext_decoder_deps="libzvbi"
@@ -6721,6 +6724,7 @@ enabled libx265 && require_pkg_config libx265
x265 x265.h x265_api_get
require_cpp_condition libx265 x265.h "X265_BUILD
>= 89"
enabled libxavs && require libxavs "stdint.h xavs.h"
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
enabled libxavs2 && require_pkg_config libxavs2 "xavs2 >= 1.3.0"
"stdint.h xavs2.h" xavs2_api_get
+enabled libxevd && require_pkg_config libxevd "xevd >= 0.4.0"
"xevd.h" xevd_decode
enabled libxeve && require_pkg_config libxeve "xeve >= 0.4.0"
"xeve.h" xeve_encode
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
enabled libzimg && require_pkg_config libzimg "zimg >= 2.7.0" zimg.h
zimg_get_api_version
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 5ba85cf9b1..54720ee8b4 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -130,6 +130,30 @@ Set amount of frame threads to use during decoding. The
default value is 0 (auto
@end table
+@section libxevd
+
+eXtra-fast Essential Video Decoder (XEVD) MPEG-5 EVC decoder wrapper.
+
+This decoder requires the presence of the libxevd headers and library
+during configuration. You need to explicitly configure the build with
+@option{--enable-libxevd}.
+
+The xevd project website is at @url{https://github.com/mpeg5/xevd}.
+
+@subsection Options
+
+The following options are supported by the libxevd wrapper.
+The xevd-equivalent options or values are listed in parentheses for easy
migration.
+
+To get a more accurate and extensive documentation of the libxevd options,
+invoke the command @code{xevd_app --help} or consult the libxevd
documentation.
+
+@table @option
+@item threads (@emph{threads})
+Force to use a specific number of threads
+
+@end table
+
@section QSV Decoders
The family of Intel QuickSync Video decoders (VC1, MPEG-2, H.264, HEVC,
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index bcff3e29b7..38940d497a 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -351,6 +351,14 @@ Go to @url{https://github.com/mpeg5/xeve} and follow the
instructions for
installing the XEVE library. Then pass @code{--enable-libxeve} to configure to
enable it.
+@section eXtra-fast Essential Video Decoder (XEVD)
+
+FFmpeg can make use of the XEVD library for EVC video decoding.
+
+Go to @url{https://github.com/mpeg5/xevd} and follow the instructions for
+installing the XEVD library. Then pass @code{--enable-libxevd} to configure to
+enable it.
+
@section ZVBI
ZVBI is a VBI decoding library which can be used by FFmpeg to decode DVB
@@ -944,7 +952,7 @@ following image formats are supported:
@item Escape 124 @tab @tab X
@item Escape 130 @tab @tab X
@item EVC / MPEG-5 Part 1@tab X @tab X
-@tab encoding supported through external library libxeve
+@tab encoding and decoding supported through external libraries libxeve
and libxevd
@item FFmpeg video codec #1 @tab X @tab X
@tab lossless codec (fourcc: FFV1)
@item Flash Screen Video v1 @tab X @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 8119a4cb6d..f0c41fb021 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1119,6 +1119,7 @@ OBJS-$(CONFIG_LIBX264_ENCODER)+= libx264.o
OBJS-$(CONFIG_LIBX265_ENCODER)+= libx265.o
[FFmpeg-devel] [PATCH v16 5/9] avcodec/evc_encoder: Provided support for EVC encoder
- Added EVC encoder wrapper
- Changes in project configuration file and libavcodec Makefile
- Added documentation for xeve wrapper
Signed-off-by: Dawid Kozinski
---
configure | 4 +
doc/encoders.texi | 69 +
doc/general_contents.texi | 11 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/libxeve.c | 618 ++
6 files changed, 704 insertions(+)
create mode 100644 libavcodec/libxeve.c
diff --git a/configure b/configure
index 675dc84f56..392169a4ee 100755
--- a/configure
+++ b/configure
@@ -291,6 +291,7 @@ External library support:
--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]
+ --enable-libxeve enable EVC encoding via libxeve [no]
--enable-libxavs enable AVS encoding via xavs [no]
--enable-libxavs2enable AVS2 encoding via xavs2 [no]
--enable-libxcb enable X11 grabbing using XCB [autodetect]
@@ -1862,6 +1863,7 @@ EXTERNAL_LIBRARY_LIST="
libvorbis
libvpx
libwebp
+libxeve
libxml2
libzimg
libzmq
@@ -3394,6 +3396,7 @@ libx265_encoder_deps="libx265"
libx265_encoder_select="atsc_a53"
libxavs_encoder_deps="libxavs"
libxavs2_encoder_deps="libxavs2"
+libxeve_encoder_deps="libxeve"
libxvid_encoder_deps="libxvid"
libzvbi_teletext_decoder_deps="libzvbi"
vapoursynth_demuxer_deps="vapoursynth"
@@ -6718,6 +6721,7 @@ enabled libx265 && require_pkg_config libx265
x265 x265.h x265_api_get
require_cpp_condition libx265 x265.h "X265_BUILD
>= 89"
enabled libxavs && require libxavs "stdint.h xavs.h"
xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
enabled libxavs2 && require_pkg_config libxavs2 "xavs2 >= 1.3.0"
"stdint.h xavs2.h" xavs2_api_get
+enabled libxeve && require_pkg_config libxeve "xeve >= 0.4.0"
"xeve.h" xeve_encode
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
enabled libzimg && require_pkg_config libzimg "zimg >= 2.7.0" zimg.h
zimg_get_api_version
enabled libzmq&& require_pkg_config libzmq "libzmq >= 4.2.1" zmq.h
zmq_ctx_new
diff --git a/doc/encoders.texi b/doc/encoders.texi
index b8051cda3f..15b8db76c0 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2894,6 +2894,75 @@ ffmpeg -i input -c:v libxavs2 -xavs2-params RdoqLevel=0
output.avs2
@end example
@end table
+@section libxeve
+
+eXtra-fast Essential Video Encoder (XEVE) MPEG-5 EVC encoder wrapper.
+The xeve-equivalent options or values are listed in parentheses for easy
migration.
+
+This encoder requires the presence of the libxeve headers and library
+during configuration. You need to explicitly configure the build with
+@option{--enable-libxeve}.
+
+@float NOTE
+Many libxeve encoder options are mapped to FFmpeg global codec options,
+while unique encoder options are provided through private options.
+Additionally the xeve-params private options allows one to pass a list
+of key=value tuples as accepted by the libxeve @code{parse_xeve_params}
function.
+@end float
+
+The xeve project website is at @url{https://github.com/mpeg5/xeve}.
+
+@subsection Options
+
+The following options are supported by the libxeve wrapper.
+The xeve-equivalent options or values are listed in parentheses for easy
migration.
+
+@float NOTE
+To reduce the duplication of documentation, only the private options
+and some others requiring special attention are documented here. For
+the documentation of the undocumented generic options, see
+@ref{codec-options,,the Codec Options chapter}.
+@end float
+
+@float NOTE
+To get a more accurate and extensive documentation of the libxeve options,
+invoke the command @code{xeve_app --help} or consult the libxeve
documentation.
+@end float
+
+@table @option
+@item b (@emph{bitrate})
+Set target video bitrate in bits/s.
+Note that FFmpeg's b option is expressed in bits/s, while xeve's bitrate is in
kilobits/s.
+
+@item bf (@emph{bframes})
+Set the maximum number of B frames (1,3,7,15).
+
+@item g (@emph{keyint})
+Set the GOP size (I-picture period).
+
+@item preset (@emph{preset})
+Set the xeve preset.
+Set the encoder preset value to determine encoding speed [fast, medium, slow,
placebo]
+
+@item tune (@emph{tune})
+Set the encoder tune parameter [psnr, zerolatency]
+
+@item profile (@emph{profile})
+Set the encoder profile [0: baselie; 1: main]
+
+@item crf (@emph{crf})
+Set the quality for constant quality mode.
+Constant rate factor <10..49> [default: 32]
+
+@item qp (@emph{qp})
+Set constant quantization rate control method parameter.
+Quantization parameter qp <0..51> [default: 32]
+
+@item threads (@emph{threads})
+Force to use a specific number of threads
+
+@end table
+
@section libxvid
Xvid MPEG-4 Part 2 encoder wrapper.
diff --git
[FFmpeg-devel] [PATCH v16 4/9] avformat/evc_demuxer: Added demuxer to handle reading EVC video files
- Provided AVInputFormat structure describing EVC input format (ff_evc_demuxer)
Signed-off-by: Dawid Kozinski
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/evcdec.c | 124 +++
3 files changed, 126 insertions(+)
create mode 100644 libavformat/evcdec.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index a14a759c1f..af175d2097 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -251,6 +251,7 @@ OBJS-$(CONFIG_HCOM_DEMUXER) += hcom.o pcm.o
OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
OBJS-$(CONFIG_HEVC_DEMUXER) += hevcdec.o rawdec.o
OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
+OBJS-$(CONFIG_EVC_DEMUXER) += evcdec.o rawdec.o
OBJS-$(CONFIG_EVC_MUXER) += rawenc.o
OBJS-$(CONFIG_HLS_DEMUXER) += hls.o hls_sample_encryption.o
OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o hlsplaylist.o avc.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index aabc9b5f99..a963c0223d 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -153,6 +153,7 @@ extern const AVInputFormat ff_ea_cdata_demuxer;
extern const AVInputFormat ff_eac3_demuxer;
extern const AVOutputFormat ff_eac3_muxer;
extern const AVInputFormat ff_epaf_demuxer;
+extern const AVInputFormat ff_evc_demuxer;
extern const AVOutputFormat ff_evc_muxer;
extern const AVOutputFormat ff_f4v_muxer;
extern const AVInputFormat ff_ffmetadata_demuxer;
diff --git a/libavformat/evcdec.c b/libavformat/evcdec.c
new file mode 100644
index 00..7887f0b591
--- /dev/null
+++ b/libavformat/evcdec.c
@@ -0,0 +1,124 @@
+/*
+ * RAW EVC video demuxer
+ *
+ * Copyright (c) 2021 Dawid Kozinski
+ *
+ * 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
+ */
+
+#include "libavcodec/get_bits.h"
+#include "libavcodec/golomb.h"
+#include "libavcodec/internal.h"
+#include "libavcodec/evc.h"
+
+#include "rawdec.h"
+#include "avformat.h"
+
+typedef struct EVCParserContext {
+int got_sps;
+int got_pps;
+int got_idr;
+int got_nonidr;
+} EVCParserContext;
+
+static int get_nalu_type(const uint8_t *bits, int bits_size)
+{
+int unit_type_plus1 = 0;
+
+if (bits_size >= EVC_NALU_HEADER_SIZE) {
+unsigned char *p = (unsigned char *)bits;
+// forbidden_zero_bit
+if ((p[0] & 0x80) != 0) { // Cannot get bitstream information.
Malformed bitstream.
+return -1;
+}
+
+// nal_unit_type
+unit_type_plus1 = (p[0] >> 1) & 0x3F;
+}
+
+return unit_type_plus1 - 1;
+}
+
+static uint32_t read_nal_unit_length(const uint8_t *bits, int bits_size)
+{
+uint32_t nalu_len = 0;
+
+if (bits_size >= EVC_NALU_LENGTH_PREFIX_SIZE) {
+
+int t = 0;
+unsigned char *p = (unsigned char *)bits;
+
+for (int i=0; ibuf;
+int bytes_to_read = p->buf_size;
+
+while (bytes_to_read > EVC_NALU_LENGTH_PREFIX_SIZE) {
+
+nalu_size = read_nal_unit_length(bits, EVC_NALU_LENGTH_PREFIX_SIZE);
+if (nalu_size == 0) break;
+
+bits += EVC_NALU_LENGTH_PREFIX_SIZE;
+bytes_to_read -= EVC_NALU_LENGTH_PREFIX_SIZE;
+
+if(bytes_to_read < nalu_size) break;
+
+nalu_type = get_nalu_type(bits, bytes_to_read);
+
+bits += nalu_size;
+bytes_to_read -= nalu_size;
+
+if (nalu_type == EVC_SPS_NUT)
+ev->got_sps++;
+else if (nalu_type == EVC_PPS_NUT)
+ev->got_pps++;
+else if (nalu_type == EVC_IDR_NUT )
+ev->got_idr++;
+else if (nalu_type == EVC_NOIDR_NUT)
+ev->got_nonidr++;
+}
+
+return 0;
+}
+
+static int evc_probe(const AVProbeData *p)
+{
+EVCParserContext ev = {0};
+int ret = parse_nal_units(p, );
+
+if (ret == 0 && ev.got_sps && ev.got_pps && (ev.got_idr || ev.got_nonidr >
3))
+return AVPROBE_SCORE_EXTENSION + 1; // 1 more than .mpg
+
+return 0;
+}
+
+FF_DEF_RAWVIDEO_DEMUXER(evc, "raw EVC video", evc_probe, "evc",
AV_CODEC_ID_EVC)
--
2.37.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit
[FFmpeg-devel] [PATCH v16 3/9] avformat/evc_muxer: Added muxer to handle writing EVC encoded data into file or output bytestream
- Provided AVOutputFormat structure describing EVC output format (ff_evc_muxer)
- Added documentation for EVC muxer
Signed-off-by: Dawid Kozinski
---
doc/muxers.texi | 6 ++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/rawenc.c | 13 +
4 files changed, 21 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index ed5341be39..eed6f0535f 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2126,6 +2126,12 @@ DTS Coherent Acoustics (DCA) audio.
Dolby Digital Plus, also known as Enhanced AC-3, audio.
+@subsection evc
+
+MPEG-5 Essential Video Coding (EVC) / EVC / MPEG-5 Part 1 EVC video.
+
+Extensions: evc
+
@subsection g722
ITU-T G.722 audio.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index d7f198bf39..a14a759c1f 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -251,6 +251,7 @@ OBJS-$(CONFIG_HCOM_DEMUXER) += hcom.o pcm.o
OBJS-$(CONFIG_HDS_MUXER) += hdsenc.o
OBJS-$(CONFIG_HEVC_DEMUXER) += hevcdec.o rawdec.o
OBJS-$(CONFIG_HEVC_MUXER)+= rawenc.o
+OBJS-$(CONFIG_EVC_MUXER) += rawenc.o
OBJS-$(CONFIG_HLS_DEMUXER) += hls.o hls_sample_encryption.o
OBJS-$(CONFIG_HLS_MUXER) += hlsenc.o hlsplaylist.o avc.o
OBJS-$(CONFIG_HNM_DEMUXER) += hnm.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 62262ae935..aabc9b5f99 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -153,6 +153,7 @@ extern const AVInputFormat ff_ea_cdata_demuxer;
extern const AVInputFormat ff_eac3_demuxer;
extern const AVOutputFormat ff_eac3_muxer;
extern const AVInputFormat ff_epaf_demuxer;
+extern const AVOutputFormat ff_evc_muxer;
extern const AVOutputFormat ff_f4v_muxer;
extern const AVInputFormat ff_ffmetadata_demuxer;
extern const AVOutputFormat ff_ffmetadata_muxer;
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 267fce252d..b7b2aff453 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -401,6 +401,19 @@ const AVOutputFormat ff_hevc_muxer = {
};
#endif
+#if CONFIG_EVC_MUXER
+AVOutputFormat ff_evc_muxer = {
+.name = "evc",
+.long_name = NULL_IF_CONFIG_SMALL("raw EVC video"),
+.extensions= "evc",
+.audio_codec = AV_CODEC_ID_NONE,
+.video_codec = AV_CODEC_ID_EVC,
+.write_header = force_one_stream,
+.write_packet = ff_raw_write_packet,
+.flags = AVFMT_NOTIMESTAMPS,
+};
+#endif
+
#if CONFIG_M4V_MUXER
const AVOutputFormat ff_m4v_muxer = {
.name = "m4v",
--
2.37.3.windows.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] [PATCH v16 2/9] avcodec/evc_parser: Added parser implementation for EVC format
- Added constants definitions for EVC parser
- Provided NAL units parsing following ISO_IEC_23094-1
- EVC parser registration
Signed-off-by: Dawid Kozinski
---
libavcodec/Makefile |1 +
libavcodec/evc.h| 155 +
libavcodec/evc_parser.c | 1417 +++
libavcodec/parsers.c|1 +
4 files changed, 1574 insertions(+)
create mode 100644 libavcodec/evc.h
create mode 100644 libavcodec/evc_parser.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 98841ed07c..401d0b7310 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1146,6 +1146,7 @@ OBJS-$(CONFIG_DVAUDIO_PARSER) += dvaudio_parser.o
OBJS-$(CONFIG_DVBSUB_PARSER) += dvbsub_parser.o
OBJS-$(CONFIG_DVD_NAV_PARSER) += dvd_nav_parser.o
OBJS-$(CONFIG_DVDSUB_PARSER) += dvdsub_parser.o
+OBJS-$(CONFIG_EVC_PARSER) += evc_parser.o
OBJS-$(CONFIG_FLAC_PARSER) += flac_parser.o flacdata.o flac.o
OBJS-$(CONFIG_FTR_PARSER) += ftr_parser.o
OBJS-$(CONFIG_G723_1_PARSER) += g723_1_parser.o
diff --git a/libavcodec/evc.h b/libavcodec/evc.h
new file mode 100644
index 00..d1fdb4fac6
--- /dev/null
+++ b/libavcodec/evc.h
@@ -0,0 +1,155 @@
+/*
+ * EVC definitions and enums
+ * Copyright (c) 2022 Dawid Kozinski
+ *
+ * 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
+ */
+
+#ifndef AVCODEC_EVC_H
+#define AVCODEC_EVC_H
+
+// The length field that indicates the length in bytes of the following NAL
unit is configured to be of 4 bytes
+#define EVC_NALU_LENGTH_PREFIX_SIZE (4) /* byte */
+#define EVC_NALU_HEADER_SIZE(2) /* byte */
+
+/**
+ * @see ISO_IEC_23094-1_2020, 7.4.2.2 NAL unit header semantic
+ * Table 4 - NAL unit type codes and NAL unit type classes
+ */
+enum EVCNALUnitType {
+EVC_NOIDR_NUT= 0, /* Coded slice of a non-IDR picture */
+EVC_IDR_NUT = 1, /* Coded slice of an IDR picture */
+EVC_RSV_VCL_NUT02= 2,
+EVC_RSV_VCL_NUT03= 3,
+EVC_RSV_VCL_NUT04= 4,
+EVC_RSV_VCL_NUT05= 5,
+EVC_RSV_VCL_NUT06= 6,
+EVC_RSV_VCL_NUT07= 7,
+EVC_RSV_VCL_NUT08= 8,
+EVC_RSV_VCL_NUT09= 9,
+EVC_RSV_VCL_NUT10= 10,
+EVC_RSV_VCL_NUT11= 11,
+EVC_RSV_VCL_NUT12= 12,
+EVC_RSV_VCL_NUT13= 13,
+EVC_RSV_VCL_NUT14= 14,
+EVC_RSV_VCL_NUT15= 15,
+EVC_RSV_VCL_NUT16= 16,
+EVC_RSV_VCL_NUT17= 17,
+EVC_RSV_VCL_NUT18= 18,
+EVC_RSV_VCL_NUT19= 19,
+EVC_RSV_VCL_NUT20= 20,
+EVC_RSV_VCL_NUT21= 21,
+EVC_RSV_VCL_NUT22= 22,
+EVC_RSV_VCL_NUT23= 23,
+EVC_SPS_NUT = 24, /* Sequence parameter set */
+EVC_PPS_NUT = 25, /* Picture paremeter set */
+EVC_APS_NUT = 26, /* Adaptation parameter set */
+EVC_FD_NUT = 27, /* Filler data */
+EVC_SEI_NUT = 28, /* Supplemental enhancement information */
+EVC_RSV_NONVCL29 = 29,
+EVC_RSV_NONVCL30 = 30,
+EVC_RSV_NONVCL31 = 31,
+EVC_RSV_NONVCL32 = 32,
+EVC_RSV_NONVCL33 = 33,
+EVC_RSV_NONVCL34 = 34,
+EVC_RSV_NONVCL35 = 35,
+EVC_RSV_NONVCL36 = 36,
+EVC_RSV_NONVCL37 = 37,
+EVC_RSV_NONVCL38 = 38,
+EVC_RSV_NONVCL39 = 39,
+EVC_RSV_NONVCL40 = 40,
+EVC_RSV_NONVCL41 = 41,
+EVC_RSV_NONVCL42 = 42,
+EVC_RSV_NONVCL43 = 43,
+EVC_RSV_NONVCL44 = 44,
+EVC_RSV_NONVCL45 = 45,
+EVC_RSV_NONVCL46 = 46,
+EVC_RSV_NONVCL47 = 47,
+EVC_RSV_NONVCL48 = 48,
+EVC_RSV_NONVCL49 = 49,
+EVC_RSV_NONVCL50 = 50,
+EVC_RSV_NONVCL51 = 51,
+EVC_RSV_NONVCL52 = 52,
+EVC_RSV_NONVCL53 = 53,
+EVC_RSV_NONVCL54 = 54,
+EVC_RSV_NONVCL55 = 55,
+EVC_UNSPEC_NUT56 = 56,
+EVC_UNSPEC_NUT57 = 57,
+EVC_UNSPEC_NUT58 = 58,
+EVC_UNSPEC_NUT59 = 59,
+EVC_UNSPEC_NUT60 = 60,
+EVC_UNSPEC_NUT61
[FFmpeg-devel] [PATCH v16 1/9] avcodec/evc: MPEG-5 EVC codec registration
Added prerequisites that must be met before providing support for the MPEG-5
EVC codec
- Added new entry to codec IDs list
- Added new entry to the codec descriptor list
- Bumped libavcodec minor version
- Added profiles for EVC codec
Signed-off-by: Dawid Kozinski
---
libavcodec/avcodec.h| 3 +++
libavcodec/codec_desc.c | 8
libavcodec/codec_id.h | 1 +
libavcodec/profiles.c | 6 ++
libavcodec/profiles.h | 1 +
libavcodec/version.h| 2 +-
6 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 0ac581d660..39296021c4 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1668,6 +1668,9 @@ typedef struct AVCodecContext {
#define FF_PROFILE_KLVA_SYNC 0
#define FF_PROFILE_KLVA_ASYNC 1
+#define FF_PROFILE_EVC_BASELINE 0
+#define FF_PROFILE_EVC_MAIN 1
+
/**
* level
* - encoding: Set by user.
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 24a0433dba..357e17d82c 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1923,6 +1923,14 @@ static const AVCodecDescriptor codec_descriptors[] = {
.long_name = NULL_IF_CONFIG_SMALL("ViewQuest VQC"),
.props = AV_CODEC_PROP_LOSSY,
},
+{
+.id= AV_CODEC_ID_EVC,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "evc",
+.long_name = NULL_IF_CONFIG_SMALL("MPEG-5 EVC (Essential Video
Coding)"),
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_REORDER,
+.profiles = NULL_IF_CONFIG_SMALL(ff_evc_profiles),
+},
/* various PCM "codecs" */
{
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index f436a2b624..b887a3788f 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -320,6 +320,7 @@ enum AVCodecID {
AV_CODEC_ID_WBMP,
AV_CODEC_ID_MEDIA100,
AV_CODEC_ID_VQC,
+AV_CODEC_ID_EVC,
/* various PCM "codecs" */
AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
start of audio codecs
diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
index 7af7fbeb13..a31244e0db 100644
--- a/libavcodec/profiles.c
+++ b/libavcodec/profiles.c
@@ -181,4 +181,10 @@ const AVProfile ff_arib_caption_profiles[] = {
{ FF_PROFILE_UNKNOWN }
};
+const AVProfile ff_evc_profiles[] = {
+{ FF_PROFILE_EVC_BASELINE, "Baseline" },
+{ FF_PROFILE_EVC_MAIN, "Main" },
+{ FF_PROFILE_UNKNOWN },
+};
+
#endif /* !CONFIG_SMALL */
diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
index 41a19aa9ad..cf92b5f126 100644
--- a/libavcodec/profiles.h
+++ b/libavcodec/profiles.h
@@ -72,5 +72,6 @@ extern const AVProfile ff_sbc_profiles[];
extern const AVProfile ff_prores_profiles[];
extern const AVProfile ff_mjpeg_profiles[];
extern const AVProfile ff_arib_caption_profiles[];
+extern const AVProfile ff_evc_profiles[];
#endif /* AVCODEC_PROFILES_H */
diff --git a/libavcodec/version.h b/libavcodec/version.h
index eb95a0f827..5fc29bdb1f 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include "version_major.h"
-#define LIBAVCODEC_VERSION_MINOR 55
+#define LIBAVCODEC_VERSION_MINOR 56
#define LIBAVCODEC_VERSION_MICRO 103
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
2.37.3.windows.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".
