Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip func
Hi Mark, Thanks for your kind guidance, but the problem is we are not trying to control the output framerate by this skip-frame feature. Our purpose is to just skip some frames, which are being requested by the content producer. And to implement that, we need an interface between the app and the vaapi lib, which informs the latter that a frame shall be skipped. Regards, SUN, Jing -Original Message- From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark Thompson Sent: Monday, December 10, 2018 2:40 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip func On 06/12/2018 10:04, Sun, Jing A wrote: > Hi Mark, > > This patch is not trying to support VFR. Some frames, after which are just > produced, could be considered as not needed by theirs producer and will get > skipped in the encoding process. And in my opinion the existing timing > information is not sufficient to support the case. A skipped frame will still have a timestamp, so if a frame is skipped before the encoder then no frame with that timestamp will be given to the encoder. For CFR content this can be detected in the encoder to reconstruct your skip-frames information exactly - a skip has occurred if the gap between two frames does not match the framerate, and the size of the gap tells you how many frames were skipped. Avoiding a requirement that the gap sizes exactly match makes it implement a simple VFR scheme too, since skips can be inserted to keep the rate controller correct as long as you never have frames closer together than the configured framerate. (Please avoid top-posting on this list.) - Mark > -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Mark Thompson > Sent: Wednesday, December 5, 2018 7:50 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add > frame-skip func > > On 04/12/2018 01:46, Sun, Jing A wrote: >> Hi Mark, >> >> Is there any issue that I need to fix for this patch please? > > See comments in the message you quoted below? I think the most important > point is that the existing timing information appears to contain all the > information you want for VFR, so you probably shouldn't need the ad-hoc > side-data type. > > - Mark > > >> -Original Message- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Sun, Jing A >> Sent: Friday, November 23, 2018 5:37 PM >> To: FFmpeg development discussions and patches >> >> Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add >> frame-skip func >> >> Hi Mark, >> >> In some cases, that is useful. For example, an online content distributer, >> who keeps encoding the captured video frames by ffmpeg and sending them out. >> At times, there is no update of source, which makes one or several captured >> source frames are exactly the same as the last one, and the distributer >> wants to just skip such frames, without stopping the encoding process. >> >> Regards, >> SUN, Jing >> >> >> -Original Message- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Mark Thompson >> Sent: Tuesday, November 20, 2018 4:07 AM >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add >> frame-skip func >> >> On 19/11/18 09:04, Jing SUN wrote: >>> frame-skip is required to implement network bandwidth self-adaptive >>> vaapi encoding. >>> To make a frame skipped, allocate its frame side data of >>> AV_FRAME_DATA_SKIP_FRAME type and set its value to 1. >> >> So if I'm reading this correctly the idea is to implement partial VFR by >> having a special new side-data type which indicates where frames would have >> been had the input actually matched the configured CFR behaviour? >> >> Why is the user meant to create these special frames? It seems to me that >> the existing method of looking at the timestamps would be a better way to >> find any gaps. >> >> (Or, even better, add timestamps to VAAPI so that it can support VFR >> in a sensible way rather than adding hacks like this to allow partial >> VFR with weird constraints.) >> >>> Signed-off-by: Jing SUN >>> --- >>> libavcodec/vaapi_encode.c | 142 >>> -- >>> libavcodec/vaapi_encode.h | 5 ++ >>> libavutil/frame.c | 1 + >>> libavutil/frame.h | 5 ++ >>> 4 files changed, 149 insertions(+), 4 deletions(-) >>> >>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c >>> index 2fe8501..a401d61 100644 >>> --- a/libavcodec/vaapi_encode.c >>> +++ b/libavcodec/vaapi_encode.c >>> @@ -23,6 +23,7 @@ >>> #include "libavutil/common.h" >>> #include "libavutil/log.h" >>> #include "libavutil/pixdesc.h" >>> +#include "libavutil/intreadwrite.h" >>> >>> #include "vaapi_encode.h" >>> #include "avcodec.h" >>> @@ -103,6
Re: [FFmpeg-devel] [PATCH V1 1/2] lavfi/vf_scale_vaapi: add scaling mode setting support.
now,
On Mon, Dec 10, 2018 at 2:25 AM Mark Thompson wrote:
>
> On 06/12/2018 10:39, Jun Zhao wrote:
> > before this change, scale_vaapi hard coding the scaling mode, add a
> > new option "mode" to setting the scaling mode, it can be use to change
> > scaling algorithm for performance/quality trade off.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavfilter/vf_scale_vaapi.c | 33 ++---
> > 1 files changed, 30 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
> > index d6529d5..ad222e6 100644
> > --- a/libavfilter/vf_scale_vaapi.c
> > +++ b/libavfilter/vf_scale_vaapi.c
> > @@ -35,10 +35,26 @@ typedef struct ScaleVAAPIContext {
> >
> > char *output_format_string;
> >
> > +int mode;
> > +
> > char *w_expr; // width expression string
> > char *h_expr; // height expression string
> > } ScaleVAAPIContext;
> >
> > +static const char *scale_vaapi_mode_name(int mode)
> > +{
> > +switch (mode) {
> > +#define D(name) case VA_FILTER_SCALING_ ## name: return #name
> > +D(DEFAULT);
> > +D(FAST);
> > +D(HQ);
> > +#undef D
> > +default:
> > +return "Invalid";
> > +}
> > +}
> > +
> > +
> > static int scale_vaapi_config_output(AVFilterLink *outlink)
> > {
> > AVFilterLink *inlink = outlink->src->inputs[0];
> > @@ -70,6 +86,7 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink,
> > AVFrame *input_frame)
> > AVFilterContext *avctx = inlink->dst;
> > AVFilterLink *outlink= avctx->outputs[0];
> > VAAPIVPPContext *vpp_ctx = avctx->priv;
> > +ScaleVAAPIContext *ctx = avctx->priv;
> > AVFrame *output_frame= NULL;
> > VASurfaceID input_surface, output_surface;
> > VAProcPipelineParameterBuffer params;
> > @@ -119,7 +136,7 @@ static int scale_vaapi_filter_frame(AVFilterLink
> > *inlink, AVFrame *input_frame)
> > params.output_color_standard = params. surface_color_standard;
> >
> > params.pipeline_flags = 0;
> > -params.filter_flags = VA_FILTER_SCALING_HQ;
> > +params.filter_flags |= ctx->mode;
>
> "=" would feel safer - "|=" implies something else might have been setting it
> as well.
>
Will keep the old way
> >
> > err = ff_vaapi_vpp_render_picture(avctx, , output_surface);
> > if (err < 0)
> > @@ -131,9 +148,10 @@ static int scale_vaapi_filter_frame(AVFilterLink
> > *inlink, AVFrame *input_frame)
> >
> > av_frame_free(_frame);
> >
> > -av_log(avctx, AV_LOG_DEBUG, "Filter output: %s, %ux%u (%"PRId64").\n",
> > +av_log(avctx, AV_LOG_DEBUG, "Filter output: %s, %ux%u (%"PRId64"),
> > mode: %s.\n",
> > av_get_pix_fmt_name(output_frame->format),
> > - output_frame->width, output_frame->height, output_frame->pts);
> > + output_frame->width, output_frame->height, output_frame->pts,
> > + scale_vaapi_mode_name(ctx->mode));
> >
> > return ff_filter_frame(outlink, output_frame);
> >
> > @@ -174,6 +192,15 @@ static const AVOption scale_vaapi_options[] = {
> >OFFSET(h_expr), AV_OPT_TYPE_STRING, {.str = "ih"}, .flags = FLAGS },
> > { "format", "Output video format (software format of hardware frames)",
> >OFFSET(output_format_string), AV_OPT_TYPE_STRING, .flags = FLAGS },
> > +{ "mode", "Scaling mode",
> > + OFFSET(mode), AV_OPT_TYPE_INT, { .i64 = VA_FILTER_SCALING_HQ },
> > + 0, VA_FILTER_SCALING_NL_ANAMORPHIC, FLAGS, "mode" },
>
> NL_ANAMORPHIC mentioned in this limit but not offered as an option?
>
NL_ANAMORPHIC never be support in the driver (both i965 and iHD), and
will be obsolete from libva, so I will change this part and remove
NL_ANAMORPHIC
> > +{ "default", "Use the default (depend on the driver) scaling
> > algorithm",
> > + 0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_DEFAULT }, 0, 0,
> > FLAGS, "mode" },
> > +{ "fast", "Use fast scaling algorithm",
> > + 0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_FAST }, 0, 0,
> > FLAGS, "mode" },
> > +{ "hq", "Use high quality scaling algorithm",
> > + 0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_HQ }, 0, 0, FLAGS,
> > "mode" },
> > { NULL },
> > };
> >
> >
>
> LGTM in any case.
>
> (Ack on keeping the HQ default - IIRC the reason for choosing HQ as the mode
> when this was written was that the default/fast mode was not faster and had
> much worse quality on some of the older Intel platforms (I would guess Bay
> Trail based on what I probably had available at the time). Might be worth
> investigating further if you have such machines available to test.)
>
I don't have Bay Trail (just Skylark and Kabylake), will investigate
this issue if I found this model. Tks.
> Thanks,
>
> - Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 8/9] lavc/qsvenc: enable QVBR mode
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Monday, December 10, 2018 3:10 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v4 8/9] lavc/qsvenc: enable QVBR mode
>
> On 29/11/2018 08:29, Zhong Li wrote:
> > QVBR mode is to use the variable bitrate control algorithm with
> > constant quality.
> > mfxExtCodingOption3 should be supported to enable QVBR mode.
> >
> > Example usage: ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -c:v
> > h264_qsv -global_quality 25 -maxrate 2M test_qvbr.mp4 -v verbose
> >
> > Signed-off-by: Zhong Li
> > ---
> > libavcodec/qsvenc.c | 39 +--
> > libavcodec/qsvenc.h | 7 +--
> > 2 files changed, 42 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> > ba74821..2dd41d7 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -136,6 +136,9 @@ static void dump_video_param(AVCodecContext
> > *avctx, QSVEncContext *q, #if QSV_HAVE_CO2
> > mfxExtCodingOption2 *co2 =
> (mfxExtCodingOption2*)coding_opts[1];
> > #endif
> > +#if QSV_HAVE_CO3
> > +mfxExtCodingOption3 *co3 =
> (mfxExtCodingOption3*)coding_opts[2];
> > +#endif
>
> With a slightly older header, I got:
>
> src/libavcodec/qsvenc.c: In function ‘dump_video_param’:
> src/libavcodec/qsvenc.c:140:26: warning: unused variable ‘co3’
> [-Wunused-variable]
> mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
> ^~~
>
> av_unused or condition on QVBR rather than CO3 to avoid that?
The problem I see is that no CO3 is supported except QVBR.
So my plan to support more CO3 parameters (win_brc is one of them and is part
of this patch series),
and I do find many of them are useful, such as EnableMBQP/ WeightedPred/ GPB.
> >
> > av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
> > print_profile(info->CodecProfile), info->CodecLevel); @@
> > -190,7 +193,12 @@ static void dump_video_param(AVCodecContext
> *avctx, QSVEncContext *q,
> > info->ICQQuality, co2->LookAheadDepth);
> > }
> > #endif
> > -
> > +#if QSV_HAVE_QVBR
> > +else if (info->RateControlMethod == MFX_RATECONTROL_QVBR) {
> > +av_log(avctx, AV_LOG_VERBOSE, "QVBRQuality: %"PRIu16"\n",
> > + co3->QVBRQuality);
> > +}
> > +#endif
> > av_log(avctx, AV_LOG_VERBOSE, "NumSlice: %"PRIu16";
> NumRefFrame: %"PRIu16"\n",
> > info->NumSlice, info->NumRefFrame);
> > av_log(avctx, AV_LOG_VERBOSE, "RateDistortionOpt: %s\n", @@
> > -326,7 +334,7 @@ static int select_rc_mode(AVCodecContext *avctx,
> QSVEncContext *q)
> > }
> > #endif
> > #if QSV_HAVE_ICQ
> > -else if (avctx->global_quality > 0) {
> > +else if (avctx->global_quality > 0 && !avctx->rc_max_rate) {
> > rc_mode = MFX_RATECONTROL_ICQ;
> > rc_desc = "intelligent constant quality (ICQ)";
> > }
> > @@ -341,6 +349,12 @@ static int select_rc_mode(AVCodecContext
> *avctx, QSVEncContext *q)
> > rc_desc = "average variable bitrate (AVBR)";
> > }
> > #endif
> > +#if QSV_HAVE_QVBR
> > +else if (avctx->global_quality > 0) {
> > +rc_mode = MFX_RATECONTROL_QVBR;
> > +rc_desc = "constant quality with VBR algorithm (QVBR)";
> > +}
> > +#endif
> > else {
> > rc_mode = MFX_RATECONTROL_VBR;
> > rc_desc = "variable bitrate (VBR)"; @@ -551,10 +565,17 @@
> > static int init_video_param(AVCodecContext *avctx, QSVEncContext *q)
> > #if QSV_HAVE_VCM
> > case MFX_RATECONTROL_VCM:
> > #endif
> > +#if QSV_HAVE_QVBR
> > +case MFX_RATECONTROL_QVBR:
> > +#endif
> > q->param.mfx.BufferSizeInKB = avctx->rc_buffer_size /
> 8000;
> > q->param.mfx.InitialDelayInKB =
> avctx->rc_initial_buffer_occupancy / 1000;
> > q->param.mfx.TargetKbps = avctx->bit_rate / 1000;
> > q->param.mfx.MaxKbps = avctx->rc_max_rate /
> 1000;
> > +#if QSV_HAVE_QVBR
> > +if (q->param.mfx.RateControlMethod ==
> MFX_RATECONTROL_QVBR)
> > +q->extco3.QVBRQuality = avctx->global_quality;
>
> I think you don't want bit_rate / TargetKbps to be set in this case? (Though
> if it's definitely just ignored then I guess it's fine to pass whatever
> value.)
I guess so too. However, as the MSDK documentation: "It uses the same set of
parameters as VBR
and quality factor specified by mfxExtCodingOption3::QVBRQuality."
So just pass all and let it be decided by MSDK.
> > +#endif
> > break;
> > case MFX_RATECONTROL_CQP:
> > quant = avctx->global_quality / FF_QP2LAMBDA; @@ -699,6
> > +720,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
> > }
> > #endif
> > }
> > +#if QSV_HAVE_CO3
> > +q->extco3.Header.BufferId =
> MFX_EXTBUFF_CODING_OPTION3;
> > +q->extco3.Header.BufferSz = sizeof(q->extco3);
> > +
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for QSV HEVC default plugin selection on Windows
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Mark Thompson > Sent: Monday, December 10, 2018 2:48 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for > QSV HEVC default plugin selection on Windows > > On 06/12/2018 05:21, Li, Zhong wrote: > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > >> Of Landgraph > >> Sent: Thursday, December 6, 2018 4:23 AM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: > >> correction for QSV HEVC default plugin selection on Windows > >> > >> Hi All, > >> > >> This is my first commit to ffmpeg, what should I do to merge it? > >> > >> Do we have any reasons to not merge this? > >> > >> Thanks! > > > > Will apply if nobody against now. > > Please add a note to the commit message explaining the original problem so > that if anyone does come across it they can understand what's going on. > Old drivers do hang around for a long time, especially with the OEM-locked > ones. Sure, will add message to raise the risk of old windows driver when merge. > Ok with that change. Should be a good idea to bump a micro version for this change? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH, v4] lavc/qsvenc: replace assert with error return
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Sunday, December 9, 2018 9:31 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [FFmpeg-devel] [PATCH, v4] lavc/qsvenc: replace assert with error
> return
>
> bs->FrameType is not set in MSDK in some cases (mjpeg encode for
> bs->example),
> and assert on a value coming from an external library is not proper.
>
> Add default type check for bs->FrameType, and return invalid data error in
> function ff_qsv_encode to avoid using uninitialized value.
>
> Fix #7593.
>
> Signed-off-by: Linjie Fu
> ---
> [v2]: Add default bs->FrameType check.
> [v3]: Add log message.
> [v4]: Fix the indentation.
>
> libavcodec/qsvenc.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> 7f4592f878..7877956952 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1337,8 +1337,13 @@ int ff_qsv_encode(AVCodecContext *avctx,
> QSVEncContext *q,
> pict_type = AV_PICTURE_TYPE_P;
> else if (bs->FrameType & MFX_FRAMETYPE_B || bs->FrameType
> & MFX_FRAMETYPE_xB)
> pict_type = AV_PICTURE_TYPE_B;
> -else
> -av_assert0(!"Uninitialized pict_type!");
> +else if (bs->FrameType == MFX_FRAMETYPE_UNKNOWN) {
> +pict_type = AV_PICTURE_TYPE_NONE;
> +av_log(avctx, AV_LOG_WARNING, "Unkown FrameType, set
> pict_type to AV_PICTURE_TYPE_NONE.\n");
> +} else {
> +av_log(avctx, AV_LOG_ERROR, "Invalid FrameType:%d.\n",
> bs->FrameType);
> +return AVERROR_INVALIDDATA;
> +}
>
> #if FF_API_CODED_FRAME
> FF_DISABLE_DEPRECATION_WARNINGS
> --
> 2.17.1
Verified and applied with an updated commit message to highlight this is a
regression.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add support for ROI-based encoding
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Monday, December 10, 2018 3:21 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] add support for ROI-based encoding
>
> On 05/12/2018 09:58, Guo, Yejun wrote:
> > this patch is not ask for merge, it is more to get a feature feedback.
> >
> > The encoders such as libx264 support different QPs offset for
> > different MBs, it makes possible for ROI-based encoding. It makes
> > sense to add support within ffmpeg to generate/accept ROI infos and pass
> into encoders.
> >
> > Typical usage: After AVFrame is decoded, a ffmpeg filter or user's
> > code generates ROI info for that frame, and the encoder finally does
> > the ROI-based encoding. And so I choose to maintain the ROI info
> > within AVFrame struct.
> >
> > TODO:
> > - remove code in vf_scale.c, it is just an example to generate ROI
> > info
> > - use AVBufferRef instead of current implementation within AVFrame
> struct.
> > - add other encoders support
> >
> > Signed-off-by: Guo, Yejun
> > ---
> > libavcodec/libx264.c | 35 +++
> > libavfilter/vf_scale.c | 8
> > libavutil/frame.c | 9 +
> > libavutil/frame.h | 14 ++
> > 4 files changed, 66 insertions(+)
>
> This approach seems reasonable to me; some thoughts below.
yeah, :)
>
> > ...
> > diff --git a/libavutil/frame.c b/libavutil/frame.c index
> > 9b3fb13..9c38bdd 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -425,6 +425,15 @@ FF_DISABLE_DEPRECATION_WARNINGS
> > FF_ENABLE_DEPRECATION_WARNINGS #endif
> >
> > +dst->nb_rois = src->nb_rois;
> > +for (int i = 0; i < dst->nb_rois; ++i) {
> > +dst->rois[i].top = src->rois[i].top;
> > +dst->rois[i].bottom = src->rois[i].bottom;
> > +dst->rois[i].left = src->rois[i].left;
> > +dst->rois[i].right = src->rois[i].right;
> > +dst->rois[i].qoffset = src->rois[i].qoffset;
> > +}
> > +
> > av_buffer_unref(>opaque_ref);
> > av_buffer_unref(>private_ref);
> > if (src->opaque_ref) {
> > diff --git a/libavutil/frame.h b/libavutil/frame.h index
> > 66f27f4..b245a90 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -193,6 +193,15 @@ typedef struct AVFrameSideData {
> > AVBufferRef *buf;
> > } AVFrameSideData;
> >
> > +
> > +typedef struct AVFrameROI {
> > +size_t top;
> > +size_t bottom;
> > +size_t left;
> > +size_t right;
>
> Do you want some additional constraints on this? For example, must be
> integers in every plane (so even values only for 4:2:0), or maybe even must
> match some codec-specific block size.
my thought is they are the coordinates at frame pixel level no matter what
format is.
And the ROI info generator can focus on their logic, do not care the underlying
codec.
If the ROI area does not exactly match with the codec-specific block size, my
thought
is to just internally extend the ROI area to match. This will added into the
comments.
>
> > +float qoffset;
>
> Everything else uses integers here, so this should be an integer. The
> meaning of it will probably be entirely codec-dependent.
I chose float because the interface provided by libx264 is float, see
https://github.com/mirror/x264/blob/master/x264.h#L760.
And I now think we might use a more general concept (enum AVRoiQuality), to
make the codec features transparent to users.
enum AVRoiQuality {
AV_RQ_NONE = 0,
AV_RQ_BETTER = 1,
AV_RQ_BEST = 2,
};
Actually, my initial idea is to export more control here, but it might
give the ROI generator burden to decide this value for different codecs.
For example, the ROI might be generated by a neural network (NN), and the NN
developers mainly focus on network model, not on the codec detail.
It is still open for me to choose which direction, I now prefer to 'enum
AVRoiQuality'
>
> > +} AVFrameROI;
> > +
> > /**
> > * This structure describes decoded (raw) audio or video data.
> > *
> > @@ -556,6 +565,11 @@ typedef struct AVFrame {
> > attribute_deprecated
> > AVBufferRef *qp_table_buf;
> > #endif
> > +
> > +//TODO: AVBufferRef*
> > +AVFrameROI rois[2];
> > +size_t nb_rois;
>
> This should be side-data (which is automatically refcounted) rather than
> included directly in the AVFrame.
I guess it is AVBufferRef*, I will switch to it in the final patch. I'm not
familiar with it
and so chose the array method for a quick implementation.
>
> > +
> > /**
> > * For hwaccel-format frames, this should be a reference to the
> > * AVHWFramesContext describing the frame.
> >
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
Re: [FFmpeg-devel] [PATCH]configure: Default to clang for Android
2018-12-07 3:06 GMT+01:00, Carl Eugen Hoyos : > I believe the Android documentation indicates that gcc will be > removed from ndk. Attached patch changes the default to > "clang" for --target-os=android. > > Now with patch. Any comments? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/xpmdec: Allow more colours per character
2018-12-06 19:11 GMT+01:00, Carl Eugen Hoyos : > Attached patch fixes decoding the files attached to ticket #6234. > > Please comment, Carl Eugen Ping. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavd: Remove libndi newtek
2018-12-03 17:05 GMT+01:00, Carl Eugen Hoyos : > It appears to me that NewTek abused our willingness to add an optional > external nonfree library, I don't see many better options. See Ticket > #7589 and a blog post by a NewTek engineer confirming the issue. > > Patch untested. After several people have objected claiming NewTek would fix this situation, a week has passed: No visible reaction whatsoever, not even requesting more time. What are those suggesting who were against this patch? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V1 2/2] lavc/vaapi_encode: fix slices number check.
On Mon, Dec 10, 2018 at 2:08 AM Mark Thompson wrote:
>
> On 06/12/2018 10:39, Jun Zhao wrote:
> > Fix slice number check logic. Only when the user setting slices
> > number more than the driver constraints dump the rounded up warning
> > message.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavcodec/vaapi_encode.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index eda8a36..3c8a33d 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -1572,7 +1572,7 @@ static av_cold int
> > vaapi_encode_init_slice_structure(AVCodecContext *avctx)
> > , tnereturn AVERROR(EINVAL);
> > }
> >
> > -if (ctx->nb_slices > avctx->slices) {
> > +if (ctx->nb_slices < avctx->slices) {
> > av_log(avctx, AV_LOG_WARNING, "Slice count rounded up to "
> > "%d (from %d) due to driver constraints on slice "
> > "structure.\n", ctx->nb_slices, avctx->slices);
> >
>
> No? The existing check looks right to me - we warn if the number got
> increased over what the user specified due to driver constraints. (We don't
> allow it to decrease unless the supplied number is larger than the number of
> rows, which gets warned about above there.)
>
> - Mark
I think avctx->slices is user setting value and ctx->nb_slices is the
driver constraints, so I think we need to check avctx->slices >
ctx->nb_slices, then give a rounded up warning. :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC]lavc/mjpegenc_common: Fix aspect ratio
Hi! Reading the specification and Wikipedia, it appears to me that FFmpeg is writing wrong values as aspect ratio for jfif files. I hope somebody can prove me wrong! This would need a slightly more sophisticated update to the decoder. Please comment, Carl Eugen From 9c42114da17c20ef6d81d3989b5521eaefc15819 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Mon, 10 Dec 2018 02:50:39 +0100 Subject: [PATCH] lavc/mjpegenc_common: Fix aspect ratio. Reported-by: Ulf Zibis --- libavcodec/mjpegenc_common.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/mjpegenc_common.c b/libavcodec/mjpegenc_common.c index 31868c9..1d3ee55 100644 --- a/libavcodec/mjpegenc_common.c +++ b/libavcodec/mjpegenc_common.c @@ -187,8 +187,8 @@ static void jpeg_put_comments(AVCodecContext *avctx, PutBitContext *p) * released revision. */ put_bits(p, 16, 0x0102); put_bits(p, 8, 0); /* units type: 0 - aspect ratio */ -put_bits(p, 16, sar.num); put_bits(p, 16, sar.den); +put_bits(p, 16, sar.num); put_bits(p, 8, 0); /* thumbnail width */ put_bits(p, 8, 0); /* thumbnail height */ } -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AMD Vega 56, UVD and OpenCL
There are decoding samples and some other samples here: https://github.com/GPUOpen-LibrariesAndSDKs/AMF There are no samples how to get Vulkan surfaces/images into OpenCL. These are public interops that you can use yourself at this point. Mikhail From: ffmpeg-devel on behalf of James Courtier-Dutton Sent: Sunday, December 9, 2018 7:04:55 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] AMD Vega 56, UVD and OpenCL On Sun, 9 Dec 2018 at 23:21, Mironov, Mikhail wrote: > There is one potential way to do it: > Decode using AMF on Vulkan, then Vulkan has interop to OpenGL and OpenGL > has interop to OpenCL. > AMF on Vulkan on Linux was released (decoder and encoder). > To integrate it to FFmpeg we need FFmpeg AMF context committed. It is > waiting for Mark to commit for quite a while. AMF has wrapped - up interop > between OpenGL to OpenCL and we are working to add Vulkan to OpenGL, though > all these interop are public APIs. > > Mikhail > > Ok, I have found and installed "libamfrt64.so". Comes with amdgpu-pro. aptitude install amf-amdgpu-pro So, getting closer to a possible solution. Are their any example/sample C++ programs for Linux demonstrating how to use the API? I am interested in decoding H.264 on the GPU and getting the decoded frame into opencl. Kind Regards James ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/buffersink: fix abuffersink flag setting issue
On Sun, Dec 9, 2018 at 10:58 PM Nicolas George wrote: > > Jun Zhao (2018-12-09): > > abuffersink need to setting AV_OPT_FLAG_AUDIO_PARAM flag. > > > > Signed-off-by: Jun Zhao > > --- > > libavfilter/buffersink.c |2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > LGTM, thanks. > > Regards, > > -- > Nicolas George Applied, Tk ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V4 0/2] Add libsvt HEVC encoder wrapper
On Sun, Dec 9, 2018 at 11:45 PM Carl Eugen Hoyos wrote: > > 2018-12-09 10:24 GMT+01:00, Jun Zhao : > > > SVT-HEVC encoder have some interesting features compare > > with the existing HEVC encoder. > > > > - Multidimensional parallelism > > a). Picture-based parallelism > > b). Segment-based parallelism (scales over many CPU cores) > > c). Will support tile-based parallelism soon > > > > - Human Visual System(HVS)-optimized classification for > > a). Data-efficient processing > > b). Computationally efficient partitioning and mode decision > > c). Higher coding efficiency > > > > - Resource adaptive scalability > > a). Speed up factor vs HM 16 about 70 times (4K/60fps content, > > SVT-HEVC enable subjective quality mode with preset setting > > with M0(highest quality)) > > b). Outperformance the x265 encoder in CQP mode > > > > Some performance data: > > - Real-time encoding of up to 1x 8Kp60/10-bit streams on the > > Platinum 8180 with preset M11/subjective quality mode > > > > - Real-time encoding of up to 2x 8Kp50/10-bit streams on the > > Platinum 8180 with preset M12/subjective quality mode > > > > - Real-time encoding of up to 4x 4Kp60/10-bit streams on the > > Gold 6148 with preset M12/subjective quality mode > > > > - Real-time encoding of up to 6x 4Kp60/10-bit streams on the > >Platinum 8180 with preset M12/subjective quality mode > > To me, this does not sound much better than the information > libturing provided and we rejected the patch. > > I have no objections but a better reasoning may be desirable, > especially regarding the subjective quality of the output streams. > > Carl Eugen More performance/quality data (include subjective quality and objectives) will be public as a official white paper as soon after the internal review finished. Please keep patience :) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/cbs_vp9: Avoid an implicit conversion from 255 to -1
2018-12-09 16:15 GMT+01:00, Mark Thompson : > On 07/12/2018 00:17, James Almer wrote: >> On 12/6/2018 8:29 PM, Carl Eugen Hoyos wrote: >>> Hi! >>> >>> Attached patch silences an ugly clang warning. >>> >>> Please comment, Carl Eugen >>> >>> >>> 0001-lavc-cbs_vp9-Avoid-an-implicit-conversion-from-255-t.patch >>> >>> From 20a643259b8e382bdfd759af78c36c3442c0affc Mon Sep 17 00:00:00 2001 >>> From: Carl Eugen Hoyos >>> Date: Fri, 7 Dec 2018 00:26:40 +0100 >>> Subject: [PATCH] lavc/cbs_vp9: Avoid an implicit conversion from 255 to >>> -1. >>> >>> Silences a warning with clang: >>> libavcodec/cbs_vp9_syntax_template.c:220:17: warning: implicit conversion >>> from 'int' to 'int8_t' (aka 'signed char') >>> changes value from 255 to -1 >>> --- >>> libavcodec/cbs_vp9.c |2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c >>> index c03ce98..95d147d 100644 >>> --- a/libavcodec/cbs_vp9.c >>> +++ b/libavcodec/cbs_vp9.c >>> @@ -310,7 +310,7 @@ static int cbs_vp9_write_le(CodedBitstreamContext >>> *ctx, PutBitContext *pbc, >>> if (prob_coded) \ >>> xf(8, name.prob, prob, subs, __VA_ARGS__); \ >>> else \ >>> -prob = 255; \ >>> +prob = -1; \ >> >> I think it may be better to make prob uint8_t instead, > > Yes, this. The values are all uint8_t, so this one should be too. Applied this variant. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/matroskadec: Do not use strncat() to limit copying a one-char constant
2018-12-09 19:03 GMT+01:00, Mark Thompson :
> On 06/12/2018 22:26, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch silences a new gcc warning, alternative would be to
>> disable the warning.
>>
>> Please comment, Carl Eugen
>>
>>
>> From dd49cddc6fad136222d4a168301059d55fea4a4c Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos
>> Date: Thu, 6 Dec 2018 23:23:12 +0100
>> Subject: [PATCH] lavf/matroskadec: Do not use strncat() to limit copying a
>> one-char constant.
>>
>> Silences a warning:
>> libavformat/matroskadec.c: In function 'webm_dash_manifest_cues':
>> libavformat/matroskadec.c:3947:13: warning: 'strncat' specified bound 1
>> equals source length [-Wstringop-overflow=]
>> strncat(buf, ",", 1);
>> ^~~~
>> ---
>> libavformat/matroskadec.c |2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>> index 2daa1db..df820b4 100644
>> --- a/libavformat/matroskadec.c
>> +++ b/libavformat/matroskadec.c
>> @@ -3944,7 +3944,7 @@ static int webm_dash_manifest_cues(AVFormatContext
>> *s, int64_t init_range)
>> }
>> end += ret;
>> if (i != s->streams[0]->nb_index_entries - 1) {
>> -strncat(buf, ",", 1);
>> +strcat(buf, ",");
>> end++;
>> }
>> }
>> --
>> 1.7.10.4
>>
>
> LGTM.
>
> (Optional: perhaps nicer to remove that code fragment with the str(n?)cat
> completely by including the comma in the snprintf above, as '"%s", i !=
> s->streams[0]->nb_index_entries - 1 ? "," : ""'?)
New patch attached.
Please review, Carl Eugen
From 082bce9706a4c326187ae543d8b8aa93424c48b0 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 10 Dec 2018 01:55:15 +0100
Subject: [PATCH] lavf/matroskadec: Do not use strncat() to limit copying a
one-char constant.
Instead add the character to the snprintf above as suggested by Mark.
Silences a warning:
libavformat/matroskadec.c: In function 'webm_dash_manifest_cues':
libavformat/matroskadec.c:3947:13: warning: 'strncat' specified bound 1 equals source length [-Wstringop-overflow=]
strncat(buf, ",", 1);
^~~~
---
libavformat/matroskadec.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 2daa1db..4ad99db 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -3936,17 +3936,14 @@ static int webm_dash_manifest_cues(AVFormatContext *s, int64_t init_range)
strcpy(buf, "");
for (i = 0; i < s->streams[0]->nb_index_entries; i++) {
int ret = snprintf(buf + end, 20,
- "%" PRId64, s->streams[0]->index_entries[i].timestamp);
+ "%" PRId64"%s", s->streams[0]->index_entries[i].timestamp,
+ i != s->streams[0]->nb_index_entries - 1 ? "," : "");
if (ret <= 0 || (ret == 20 && i == s->streams[0]->nb_index_entries - 1)) {
av_log(s, AV_LOG_ERROR, "timestamp too long.\n");
av_free(buf);
return AVERROR_INVALIDDATA;
}
end += ret;
-if (i != s->streams[0]->nb_index_entries - 1) {
-strncat(buf, ",", 1);
-end++;
-}
}
av_dict_set(>streams[0]->metadata, CUE_TIMESTAMPS, buf, 0);
av_free(buf);
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/decode: Initialize a return value on get_format() error
2018-12-09 18:54 GMT+01:00, Mark Thompson :
> On 06/12/2018 22:27, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch silences a clang warning, please comment.
>>
>> Carl Eugen
>>
>>
>> From 3b5fc2473235410920ca89c7d84654e2ce8fb29d Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos
>> Date: Thu, 6 Dec 2018 23:17:13 +0100
>> Subject: [PATCH] lavc/decode: Initialize return value for get_format()
>> failure.
>>
>> Silences a warning:
>> libavcodec/decode.c:1378:13: warning: variable 'ret' is used uninitialized
>> whenever 'if' condition is true
>> ---
>> libavcodec/decode.c |1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>> index c89c77c..a32ff2f 100644
>> --- a/libavcodec/decode.c
>> +++ b/libavcodec/decode.c
>> @@ -1378,6 +1378,7 @@ int ff_get_format(AVCodecContext *avctx, const enum
>> AVPixelFormat *fmt)
>> if (i == n) {
>> av_log(avctx, AV_LOG_ERROR, "Invalid return from
>> get_format(): "
>> "%s not in possible list.\n", desc->name);
>> +ret = AV_PIX_FMT_NONE;
>> break;
>> }
>>
>> --
>> 1.7.10.4
>>
>
> LGTM.
Patch applied.
> I think I'd also be happy with an assert there that this doesn't happen -
> it's difficult to argue that the user returning a nonsensical value from
> get_format is anything other than undefined behaviour.
I am generally a fan of asserts but I don't think this would be right.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavd/v4l2: Use ioctl(..., "int request" ) on Android
2018-12-09 18:50 GMT+01:00, Mark Thompson :
> On 06/12/2018 22:37, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes building with new Android toolchain, used to be a
>> warning.
>>
>> Please comment, Carl Eugen
>>
>> From d366c948af086520bfb2a4048e76f8d117690776 Mon Sep 17 00:00:00 2001
>> From: Carl Eugen Hoyos
>> Date: Thu, 6 Dec 2018 23:34:54 +0100
>> Subject: [PATCH] lavd/v4l2: Use "int request" as second parameter for
>> ioctl()
>> on Android.
>>
>> Fixes build with new Android toolchain.
>> ---
>> libavdevice/v4l2.c |4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
>> index 10a0ff0..aa7c052 100644
>> --- a/libavdevice/v4l2.c
>> +++ b/libavdevice/v4l2.c
>> @@ -95,7 +95,11 @@ struct video_data {
>> int (*open_f)(const char *file, int oflag, ...);
>> int (*close_f)(int fd);
>> int (*dup_f)(int fd);
>> +#ifdef __ANDROID__
>> +int (*ioctl_f)(int fd, int request, ...);
>> +#else
>> int (*ioctl_f)(int fd, unsigned long int request, ...);
>> +#endif
>> ssize_t (*read_f)(int fd, void *buffer, size_t n);
>> void *(*mmap_f)(void *start, size_t length, int prot, int flags, int
>> fd, int64_t offset);
>> int (*munmap_f)(void *_start, size_t length);
>> --
>> 1.7.10.4
>>
>
> LGTM on its own, but should this perhaps be "#ifndef (glibc something)" for
> the first case? Looking at possible V4L2-hosting libcs, only glibc has the
> nonstandard* "unsigned long" rather than "int" as the request argument, so I
> expect we're going to hit this in more cases (e.g. musl) if compilers are
> now complaining about it.
Is videodev2.h a Linux header as opposed to a c-library header or am I
completely misunderstanding?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AMD Vega 56, UVD and OpenCL
On Sun, 9 Dec 2018 at 23:21, Mironov, Mikhail wrote: > There is one potential way to do it: > Decode using AMF on Vulkan, then Vulkan has interop to OpenGL and OpenGL > has interop to OpenCL. > AMF on Vulkan on Linux was released (decoder and encoder). > To integrate it to FFmpeg we need FFmpeg AMF context committed. It is > waiting for Mark to commit for quite a while. AMF has wrapped - up interop > between OpenGL to OpenCL and we are working to add Vulkan to OpenGL, though > all these interop are public APIs. > > Mikhail > > Ok, I have found and installed "libamfrt64.so". Comes with amdgpu-pro. aptitude install amf-amdgpu-pro So, getting closer to a possible solution. Are their any example/sample C++ programs for Linux demonstrating how to use the API? I am interested in decoding H.264 on the GPU and getting the decoded frame into opencl. Kind Regards James ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AMD Vega 56, UVD and OpenCL
There is one potential way to do it: Decode using AMF on Vulkan, then Vulkan has interop to OpenGL and OpenGL has interop to OpenCL. AMF on Vulkan on Linux was released (decoder and encoder). To integrate it to FFmpeg we need FFmpeg AMF context committed. It is waiting for Mark to commit for quite a while. AMF has wrapped - up interop between OpenGL to OpenCL and we are working to add Vulkan to OpenGL, though all these interop are public APIs. Mikhail > -Original Message- > From: ffmpeg-devel On Behalf Of > James Courtier-Dutton > Sent: December 9, 2018 11:07 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] AMD Vega 56, UVD and OpenCL > > On Sun, 9 Dec 2018 at 13:37, Mark Thompson wrote: > > > On 09/12/2018 01:22, James Courtier-Dutton wrote: > > > Hi, > > > > > > I little off topic, but hopefully someone here might be able to help > > > me > > as > > > it is video processing related. > > > > > > I wish to use UVD to send a video stream to the GPU, and then have > > > OpenCL process the output video frames. > > > > > > Can anyone point me to example source code to achieve this in Linux. > > > > AMD does not support any GPU-side OpenCL interop on Linux - you will > > need to copy using the CPU. > > > > > Just to clarify. > Does the hardware (Vega 56) support it? > Is it just that the Linux drivers do not have that functionality yet? > > Kind Regards > > James > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2 v3] lavf/isom: add Dolby Vision sample entry codes for HEVC and H.264
On Fri, Dec 07, 2018 at 07:34:43PM +0200, Jan Ekström wrote: > On Wed, Dec 5, 2018 at 7:13 PM Jan Ekström wrote: > > > > On Mon, Dec 3, 2018 at 3:19 AM Jan Ekström wrote: > > > > > > From: Rodger Combs > > > > > > These are registered identifiers at the MPEG-4 RA, which are > > > defined as to be utilized for Dolby Vision AVC/HEVC streams that > > > are not correctly presentable by standards-compliant AVC/HEVC players. > > > > > > According to the Dolby Vision specification for ISOBMFF, these sample > > > entry codes are specified to have the standard AVC or HEVC decoder > > > configuration box in addition to the Dolby custom DOVIConfigurationBox. > > > This is what enables us to decode the streams without custom parsing. > > > > > > For correct presentation information from the DOVIConfigurationBox > > > is required (YCbCr or modified ICtCP, SDR or HDR, base or enhancement > > > layer). > > > --- > > > > Gentle Ping? > > > > Jan > > Ping^2? > > And if nobody really cares, I will reverse the comments on the AVC > entries (since I seem to have gotten them the wrong way around when > adding the comments and commit message late at night) and apply the > set tomorrow morning. These additional identifiers and the comment > should not be affecting existing FATE samples. probably ok, if tested and it works thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: calculate and store DAR from user SAR
On Sun, Dec 09, 2018 at 02:38:55PM +0100, Paul B Mahol wrote:
> Fixes #5155
>
> Signed-off-by: Paul B Mahol
> ---
> libavformat/mxfenc.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 3549b4137d..b3c8dc43bd 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -2726,6 +2726,12 @@ static int mxf_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> }
> }
>
> +if (st->codecpar->sample_aspect_ratio.num &&
> st->codecpar->sample_aspect_ratio.den) {
> +av_reduce_q(>aspect_ratio,
> +av_mul_q(st->codecpar->sample_aspect_ratio,
> + av_make_q(st->codecpar->width,
> st->codecpar->height)), INT_MAX);
> +}
AVRational uses int, so av_reduce* should not be needed if INT_MAX is ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avformat/concatdec: always re-calculate start time and duration
On Sun, 9 Dec 2018, Nicolas George wrote:
Marton Balint (2018-11-22):
This allows the underlying files to change their duration on subsequent
avformat context opens.
An example use case where this matters:
ffconcat version 1.0
file dummy.mxf
file dummy.mxf
ffmpeg -re -stream_loop -1 -i dummy.ffconcat -f sdl2 none
The user can seamlessly change the input by atomically replacing dummy.mxf.
Signed-off-by: Marton Balint
---
libavformat/concatdec.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index ebc50324cc..2ebd2120c3 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -355,14 +355,12 @@ static int open_file(AVFormatContext *avf, unsigned
fileno)
return ret;
}
cat->cur_file = file;
-if (file->start_time == AV_NOPTS_VALUE)
-file->start_time = !fileno ? 0 :
- cat->files[fileno - 1].start_time +
- cat->files[fileno - 1].duration;
+file->start_time = !fileno ? 0 :
+ cat->files[fileno - 1].start_time +
+ cat->files[fileno - 1].duration;
file->file_start_time = (cat->avf->start_time == AV_NOPTS_VALUE) ? 0 :
cat->avf->start_time;
file->file_inpoint = (file->inpoint == AV_NOPTS_VALUE) ?
file->file_start_time : file->inpoint;
-if (file->duration == AV_NOPTS_VALUE)
-file->duration = get_best_effort_duration(file, cat->avf);
+file->duration = get_best_effort_duration(file, cat->avf);
if (cat->segment_time_metadata) {
av_dict_set_int(>metadata, "lavf.concatdec.start_time",
file->start_time, 0);
@@ -529,8 +527,7 @@ static int open_next_file(AVFormatContext *avf)
ConcatContext *cat = avf->priv_data;
unsigned fileno = cat->cur_file - cat->files;
-if (cat->cur_file->duration == AV_NOPTS_VALUE)
-cat->cur_file->duration = get_best_effort_duration(cat->cur_file,
cat->avf);
+cat->cur_file->duration = get_best_effort_duration(cat->cur_file,
cat->avf);
if (++fileno >= cat->nb_files) {
cat->eof = 1;
I do not think it works. If the duration of the second file changes, for
example, then the start time of all subsequent files changes too, but
this patch does not update it. Seeking will show strange results.
Seeking will only work in the special case I provided in the commit
message, when we always seek back to the beginning and otherwise read the
referenced files continously.
In theory, when we are in "seekable" state then if we detect a duration
change we could indeed update all subsequent start times to provide proper
timestamps for seeking, but I did not need this for my purpose, and I am
not sure if it's worth the extra code needed.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/zmbvenc.c: don't allow motion estimation out of range.
On Sun, 9 Dec 2018 at 16:27, Michael Niedermayer
wrote:
> On Sat, Dec 08, 2018 at 02:53:44PM +0100, Tomas Härdin wrote:
> > lör 2018-12-08 klockan 00:29 + skrev Matthew Fearnley:
> > > Hi Tomas, thanks for looking through my patch.
> > >
> > > > > Practically, this patch fixes graphical glitches e.g. when
> reencoding
> > >
> > > the
> > > > > Commander Keen sample video with me_range 65 or higher:
> > > > >
> > > > > ffmpeg -i keen4e_000.avi -c:v zmbv -me_range 65 keen4e_me65.avi
> > > > I'd expect this problem to pop up with -me_range 64 too, no?
> > >
> > > I initially thought this would be the case, but taking the tx loop and
> > > removing the edge constraints:
> > >
> > > for(tx = x - c->range; tx < x + c->range; tx++){
> > > ...
> > > dx = tx - x;
> > >
> > > The effective range is (-c->range) <= dx < (c->range), meaning when
> > > c->range = me_range = 64, the dx value ranges from -64 to 63, which
> happens
> > > to be exactly in bounds.
> > > So I could have just capped me_range to 64, and that would have fixed
> the
> > > bug...
> > >
> > > But more generally, I've concluded the '<' sign is a mistake, not just
> > > because of the general asymmetry, but because of the way it prevents
> tx,ty
> > > reaching the bottom/right edges.
> > > In practice it means, for example, that if the screen pans left to
> right,
> > > the bottom edge will have to match against blocks elsewhere in the
> image.
> > >
> > > > I went over the patch, and it looks fine. But what's up with the
> xored
> > > > logic? It seems like it would compute xored always from the bottom-
> > > > right-most MV. The loop in zmbv_me() should probably have a temporary
> > > > xored and only output to *xored in if(tv < bv)..
> > >
> > > Hmm, you're right. In most cases, the code actually works anyway -
> because
> > > when *xored==0, the block entropy returned by block_cmp() is supposed
> to be
> > > 0 anyway, so it still finishes then.
> > > But... I've realised there are some exceptions to this:
> > > - the entropy calculations in block_cmp() use a lookup table
> > > (score_tab[256]), which assumes each block has 16*16 pixels. This will
> > > only be valid when the dimensions are a multiple of 16, otherwise the
> > > bottom/right edge blocks may be smaller.
> > > - I've just realised the lookup table only goes up to 255. If all
> 16*16
> > > xored pixels are the same value, it will hit the 256th entry! (I'm
> > > surprised valgrind hasn't found this..?)
> >
> > Static analysis would've caught this, which is something I've harped on
> > previously on this list (http://ffmpeg.org/pipermail/ffmpeg-devel/2018-
> > June/231598.html)
> >
> > > All that said, *xored==0 is actually the most desirable outcome
> because it
> > > means the block doesn't need to be output.
> > > So if *xored is 0, the best thing to do is probably to finish
> immediately
> > > (making sure *mx,*my are set), without processing any more MVs.
> > > And then it doesn't matter (from a correctness point of view, at
> least) if
> > > block_cmp() gives bad entropy results, as long as *xored is set
> correctly.
> >
> > Oh yeah, that's right. It might also be a good idea to try the MV of
> > the previous block first for the next block, since consecutive blocks
> > are likely to have the same MV. Even fancier would be to gather
> > statistics from the previous frame, and try MVs in order of decreasing
> > popularity. A threshold might also be useful, like "accept any MV that
> > results in no more than N bits entropy"
>
I have a feeling that this isn't a strategy that helps much in the worst
case. If the upper half of a block contains random data, there's still
potential for compression, but you wouldn't get a good enough sense of the
entropy until you've run block_cmp more than half-way for every MV.
Could still be worth it though. You could probably presume blocks like
that would be infrequent in the kind of videos ZMBV is designed for, and
just write them off with a suboptimal MV.
(This is presuming we don't go along the path suggested by Michael below.)
looking at existing fancy motion estimation methods, for example variants of
> predictive zonal searches. Might safe some time from redesigning a ME
> method
> from scratch
> also maybe something from libavcodec/motion_est.c can be reused
If the contents of zmbv_me (and block_cmp) can be replaced with a call to a
purpose-built function, that would be great.
I might be willing to help with that, but I don't understand how the
motion_est code works.
My feeling is that ZMBV's specific strengths lie with identical areas of
pixels between frames (e.g. 2D games with scrolling backgrounds/large
sprites).
With that in mind, possibly the easiest way to search is to hash every
possible block in the last frame using a rolling algorithm, and then do a
lookup on that.
The problem is the worst case - when there's no match (or no "0-entropy"
blocks), currently it would still a full search and
Re: [FFmpeg-devel] [PATCH V4 2/2] doc: Add libsvt_hevc encoder docs
On 09-12-2018 02:54 PM, Jun Zhao wrote: Add docs for libsvt_hevc encoder in encoders.texi and general.texi Signed-off-by: Jun Zhao Signed-off-by: Huang, Zhengxu Signed-off-by: hassene --- doc/encoders.texi | 157 + doc/general.texi | 14 + 2 files changed, 171 insertions(+), 0 deletions(-) LGTM. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] add support for ROI-based encoding
On 05/12/2018 09:58, Guo, Yejun wrote:
> this patch is not ask for merge, it is more to get a feature feedback.
>
> The encoders such as libx264 support different QPs offset for different MBs,
> it makes possible for ROI-based encoding. It makes sense to add support
> within ffmpeg to generate/accept ROI infos and pass into encoders.
>
> Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
> generates ROI info for that frame, and the encoder finally does the
> ROI-based encoding. And so I choose to maintain the ROI info within
> AVFrame struct.
>
> TODO:
> - remove code in vf_scale.c, it is just an example to generate ROI info
> - use AVBufferRef instead of current implementation within AVFrame struct.
> - add other encoders support
>
> Signed-off-by: Guo, Yejun
> ---
> libavcodec/libx264.c | 35 +++
> libavfilter/vf_scale.c | 8
> libavutil/frame.c | 9 +
> libavutil/frame.h | 14 ++
> 4 files changed, 66 insertions(+)
This approach seems reasonable to me; some thoughts below.
> ...
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 9b3fb13..9c38bdd 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -425,6 +425,15 @@ FF_DISABLE_DEPRECATION_WARNINGS
> FF_ENABLE_DEPRECATION_WARNINGS
> #endif
>
> +dst->nb_rois = src->nb_rois;
> +for (int i = 0; i < dst->nb_rois; ++i) {
> +dst->rois[i].top = src->rois[i].top;
> +dst->rois[i].bottom = src->rois[i].bottom;
> +dst->rois[i].left = src->rois[i].left;
> +dst->rois[i].right = src->rois[i].right;
> +dst->rois[i].qoffset = src->rois[i].qoffset;
> +}
> +
> av_buffer_unref(>opaque_ref);
> av_buffer_unref(>private_ref);
> if (src->opaque_ref) {
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 66f27f4..b245a90 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -193,6 +193,15 @@ typedef struct AVFrameSideData {
> AVBufferRef *buf;
> } AVFrameSideData;
>
> +
> +typedef struct AVFrameROI {
> +size_t top;
> +size_t bottom;
> +size_t left;
> +size_t right;
Do you want some additional constraints on this? For example, must be integers
in every plane (so even values only for 4:2:0), or maybe even must match some
codec-specific block size.
> +float qoffset;
Everything else uses integers here, so this should be an integer. The meaning
of it will probably be entirely codec-dependent.
> +} AVFrameROI;
> +
> /**
> * This structure describes decoded (raw) audio or video data.
> *
> @@ -556,6 +565,11 @@ typedef struct AVFrame {
> attribute_deprecated
> AVBufferRef *qp_table_buf;
> #endif
> +
> +//TODO: AVBufferRef*
> +AVFrameROI rois[2];
> +size_t nb_rois;
This should be side-data (which is automatically refcounted) rather than
included directly in the AVFrame.
> +
> /**
> * For hwaccel-format frames, this should be a reference to the
> * AVHWFramesContext describing the frame.
>
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v4 8/9] lavc/qsvenc: enable QVBR mode
On 29/11/2018 08:29, Zhong Li wrote:
> QVBR mode is to use the variable bitrate control algorithm
> with constant quality.
> mfxExtCodingOption3 should be supported to enable QVBR mode.
>
> Example usage: ffmpeg -hwaccel qsv -c:v h264_qsv -i input.mp4 -c:v
> h264_qsv -global_quality 25 -maxrate 2M test_qvbr.mp4 -v verbose
>
> Signed-off-by: Zhong Li
> ---
> libavcodec/qsvenc.c | 39 +--
> libavcodec/qsvenc.h | 7 +--
> 2 files changed, 42 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index ba74821..2dd41d7 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -136,6 +136,9 @@ static void dump_video_param(AVCodecContext *avctx,
> QSVEncContext *q,
> #if QSV_HAVE_CO2
> mfxExtCodingOption2 *co2 = (mfxExtCodingOption2*)coding_opts[1];
> #endif
> +#if QSV_HAVE_CO3
> +mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
> +#endif
With a slightly older header, I got:
src/libavcodec/qsvenc.c: In function ‘dump_video_param’:
src/libavcodec/qsvenc.c:140:26: warning: unused variable ‘co3’
[-Wunused-variable]
mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
^~~
av_unused or condition on QVBR rather than CO3 to avoid that?
>
> av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
> print_profile(info->CodecProfile), info->CodecLevel);
> @@ -190,7 +193,12 @@ static void dump_video_param(AVCodecContext *avctx,
> QSVEncContext *q,
> info->ICQQuality, co2->LookAheadDepth);
> }
> #endif
> -
> +#if QSV_HAVE_QVBR
> +else if (info->RateControlMethod == MFX_RATECONTROL_QVBR) {
> +av_log(avctx, AV_LOG_VERBOSE, "QVBRQuality: %"PRIu16"\n",
> + co3->QVBRQuality);
> +}
> +#endif
> av_log(avctx, AV_LOG_VERBOSE, "NumSlice: %"PRIu16"; NumRefFrame:
> %"PRIu16"\n",
> info->NumSlice, info->NumRefFrame);
> av_log(avctx, AV_LOG_VERBOSE, "RateDistortionOpt: %s\n",
> @@ -326,7 +334,7 @@ static int select_rc_mode(AVCodecContext *avctx,
> QSVEncContext *q)
> }
> #endif
> #if QSV_HAVE_ICQ
> -else if (avctx->global_quality > 0) {
> +else if (avctx->global_quality > 0 && !avctx->rc_max_rate) {
> rc_mode = MFX_RATECONTROL_ICQ;
> rc_desc = "intelligent constant quality (ICQ)";
> }
> @@ -341,6 +349,12 @@ static int select_rc_mode(AVCodecContext *avctx,
> QSVEncContext *q)
> rc_desc = "average variable bitrate (AVBR)";
> }
> #endif
> +#if QSV_HAVE_QVBR
> +else if (avctx->global_quality > 0) {
> +rc_mode = MFX_RATECONTROL_QVBR;
> +rc_desc = "constant quality with VBR algorithm (QVBR)";
> +}
> +#endif
> else {
> rc_mode = MFX_RATECONTROL_VBR;
> rc_desc = "variable bitrate (VBR)";
> @@ -551,10 +565,17 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
> #if QSV_HAVE_VCM
> case MFX_RATECONTROL_VCM:
> #endif
> +#if QSV_HAVE_QVBR
> +case MFX_RATECONTROL_QVBR:
> +#endif
> q->param.mfx.BufferSizeInKB = avctx->rc_buffer_size / 8000;
> q->param.mfx.InitialDelayInKB = avctx->rc_initial_buffer_occupancy /
> 1000;
> q->param.mfx.TargetKbps = avctx->bit_rate / 1000;
> q->param.mfx.MaxKbps = avctx->rc_max_rate / 1000;
> +#if QSV_HAVE_QVBR
> +if (q->param.mfx.RateControlMethod == MFX_RATECONTROL_QVBR)
> +q->extco3.QVBRQuality = avctx->global_quality;
I think you don't want bit_rate / TargetKbps to be set in this case? (Though
if it's definitely just ignored then I guess it's fine to pass whatever value.)
> +#endif
> break;
> case MFX_RATECONTROL_CQP:
> quant = avctx->global_quality / FF_QP2LAMBDA;
> @@ -699,6 +720,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
> }
> #endif
> }
> +#if QSV_HAVE_CO3
> +q->extco3.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3;
> +q->extco3.Header.BufferSz = sizeof(q->extco3);
> +q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer
> *)>extco3;
> +#endif
> }
>
> if (!check_enc_param(avctx,q)) {
> @@ -753,6 +779,12 @@ static int qsv_retrieve_enc_params(AVCodecContext
> *avctx, QSVEncContext *q)
> .Header.BufferSz = sizeof(co2),
> };
> #endif
> +#if QSV_HAVE_CO3
> +mfxExtCodingOption3 co3 = {
> +.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3,
> +.Header.BufferSz = sizeof(co3),
> +};
> +#endif
>
> mfxExtBuffer *ext_buffers[] = {
> (mfxExtBuffer*),
> @@ -760,6 +792,9 @@ static int qsv_retrieve_enc_params(AVCodecContext *avctx,
> QSVEncContext *q)
> #if QSV_HAVE_CO2
> (mfxExtBuffer*),
> #endif
> +#if QSV_HAVE_CO3
> +(mfxExtBuffer*),
> +#endif
> };
>
> int need_pps = avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO;
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index
Re: [FFmpeg-devel] [PATCH 3/3] qsvdec: Fix running with assert_level > 0
On 27/11/2018 09:40, Li, Zhong wrote: >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Mark Thompson >> Sent: Sunday, November 11, 2018 11:32 PM >> To: ffmpeg-devel@ffmpeg.org >> Subject: [FFmpeg-devel] [PATCH 3/3] qsvdec: Fix running with assert_level > >> 0 >> >> Assertion avctx->codec_id != AV_CODEC_ID_NONE failed at >> src/libavcodec/parser.c:128 >> >> The setting on the internal AVCodecContext used for parsing only is >> otherwise irrelevant, so just set it to avoid the assert. >> --- >> libavcodec/qsvdec.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index >> 6753e596a1..4a0be811fb 100644 >> --- a/libavcodec/qsvdec.c >> +++ b/libavcodec/qsvdec.c >> @@ -501,6 +501,8 @@ int ff_qsv_process_data(AVCodecContext *avctx, >> QSVContext *q, >> if (!q->avctx_internal) >> return AVERROR(ENOMEM); >> >> +q->avctx_internal->codec_id = avctx->codec_id; >> + >> q->parser = av_parser_init(avctx->codec_id); >> if (!q->parser) >> return AVERROR(ENOMEM); >> -- >> 2.19.1 >> > LGTM (And I am surprised it get cached so late). Yeah, I guess people rarely run with assert checks on. I try to remember it on development setups, but clearly miss it some of the time. Anyway, applied. Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for QSV HEVC default plugin selection on Windows
On 06/12/2018 05:21, Li, Zhong wrote: >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Landgraph >> Sent: Thursday, December 6, 2018 4:23 AM >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for >> QSV HEVC default plugin selection on Windows >> >> Hi All, >> >> This is my first commit to ffmpeg, what should I do to merge it? >> >> Do we have any reasons to not merge this? >> >> Thanks! > > Will apply if nobody against now. Please add a note to the commit message explaining the original problem so that if anyone does come across it they can understand what's going on. Old drivers do hang around for a long time, especially with the OEM-locked ones. Ok with that change. Thanks, - Mark >> 23.10.2018 10:14, Li, Zhong пишет: From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On >> Behalf Of Maxym Dmytrychenko Sent: Sunday, October 14, 2018 3:36 AM To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for QSV HEVC default plugin selection on Windows On Sat, Oct 13, 2018 at 6:43 PM Mark Thompson wrote: > On 06/10/18 07:21, Landgraph wrote: >> 1. Old logic meaned: everywhere, except Windows, ffmpeg has to use >> HW > acceleration, but on Windows ffmpeg has to use (unavailable) > software encode by default >> 2. Software encode is available only if you provide corresponding > software MediaSDK library, which isn't provided with ffmpeg. More > information could be found in > >> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/samples/r e > adme-encode_linux.pdf >> 3. HW encode is available on Windows in the driver by default > This has been proposed before - I can't find the original discussion > (maybe it was on IRC), but I did find < > >> https://lists.libav.org/pipermail/libav-devel/2016-November/080419.html>. > The reason for not doing it is that a subset of the Intel drivers > segfault immediately when the hardware plugin is loaded on some > platforms. That's a pain for anyone wanting to support diverse > systems, so the decision was to continue to load the sw plugin by > default so it doesn't crash (even if the software plugin isn't > present), and leave the non-default case as the crashing one so the > user has to do something to trigger it. > If you can characterise either the set of platforms it crashes on or > a set of platforms it definitely works on then maybe we could > conditionally change the default behaviour? > > - Mark > > it was 2 years old discussion and with early drivers (we even had this development a bit ahead of general driver availability) now it should be working on most of the platforms - I would suggest to make a >> positive side. >>> Basically, HEVC HW encoding should be the default case if HW platform >> can support. >>> If crashed with some specified drivers, thus should be a driver issue >>> instead >> of hiding it in ffmpeg level. >>> So, I agree with Maxym and the patch LGTM. >>> (Of course, if we can verified on the platforms which was crashed as >>> two years ago, that should be fine. However, IMHO this is not MUST. If >>> it is still crash, reporting a bug to the driver developer should be >>> the right way.) >>> ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip func
On 06/12/2018 10:04, Sun, Jing A wrote:
> Hi Mark,
>
> This patch is not trying to support VFR. Some frames, after which are just
> produced, could be considered as not needed by theirs producer and will get
> skipped in the encoding process. And in my opinion the existing timing
> information is not sufficient to support the case.
A skipped frame will still have a timestamp, so if a frame is skipped before
the encoder then no frame with that timestamp will be given to the encoder.
For CFR content this can be detected in the encoder to reconstruct your
skip-frames information exactly - a skip has occurred if the gap between two
frames does not match the framerate, and the size of the gap tells you how many
frames were skipped. Avoiding a requirement that the gap sizes exactly match
makes it implement a simple VFR scheme too, since skips can be inserted to keep
the rate controller correct as long as you never have frames closer together
than the configured framerate.
(Please avoid top-posting on this list.)
- Mark
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark
> Thompson
> Sent: Wednesday, December 5, 2018 7:50 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add frame-skip
> func
>
> On 04/12/2018 01:46, Sun, Jing A wrote:
>> Hi Mark,
>>
>> Is there any issue that I need to fix for this patch please?
>
> See comments in the message you quoted below? I think the most important
> point is that the existing timing information appears to contain all the
> information you want for VFR, so you probably shouldn't need the ad-hoc
> side-data type.
>
> - Mark
>
>
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Sun, Jing A
>> Sent: Friday, November 23, 2018 5:37 PM
>> To: FFmpeg development discussions and patches
>>
>> Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add
>> frame-skip func
>>
>> Hi Mark,
>>
>> In some cases, that is useful. For example, an online content distributer,
>> who keeps encoding the captured video frames by ffmpeg and sending them out.
>> At times, there is no update of source, which makes one or several captured
>> source frames are exactly the same as the last one, and the distributer
>> wants to just skip such frames, without stopping the encoding process.
>>
>> Regards,
>> SUN, Jing
>>
>>
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Mark Thompson
>> Sent: Tuesday, November 20, 2018 4:07 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 1/1] avcodec/vaapi_encode: add
>> frame-skip func
>>
>> On 19/11/18 09:04, Jing SUN wrote:
>>> frame-skip is required to implement network bandwidth self-adaptive
>>> vaapi encoding.
>>> To make a frame skipped, allocate its frame side data of
>>> AV_FRAME_DATA_SKIP_FRAME type and set its value to 1.
>>
>> So if I'm reading this correctly the idea is to implement partial VFR by
>> having a special new side-data type which indicates where frames would have
>> been had the input actually matched the configured CFR behaviour?
>>
>> Why is the user meant to create these special frames? It seems to me that
>> the existing method of looking at the timestamps would be a better way to
>> find any gaps.
>>
>> (Or, even better, add timestamps to VAAPI so that it can support VFR
>> in a sensible way rather than adding hacks like this to allow partial
>> VFR with weird constraints.)
>>
>>> Signed-off-by: Jing SUN
>>> ---
>>> libavcodec/vaapi_encode.c | 142
>>> --
>>> libavcodec/vaapi_encode.h | 5 ++
>>> libavutil/frame.c | 1 +
>>> libavutil/frame.h | 5 ++
>>> 4 files changed, 149 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>>> index 2fe8501..a401d61 100644
>>> --- a/libavcodec/vaapi_encode.c
>>> +++ b/libavcodec/vaapi_encode.c
>>> @@ -23,6 +23,7 @@
>>> #include "libavutil/common.h"
>>> #include "libavutil/log.h"
>>> #include "libavutil/pixdesc.h"
>>> +#include "libavutil/intreadwrite.h"
>>>
>>> #include "vaapi_encode.h"
>>> #include "avcodec.h"
>>> @@ -103,6 +104,47 @@ static int
>>> vaapi_encode_make_param_buffer(AVCodecContext *avctx,
>>> return 0;
>>> }
>>>
>>> +static int vaapi_encode_check_if_skip(AVCodecContext *avctx,
>>> + VAAPIEncodePicture *pic) {
>>> +AVFrameSideData *fside = NULL;
>>> +VAAPIEncodeContext *ctx = avctx->priv_data;
>>> +VAAPIEncodePicture *cur = NULL;
>>> +int i = 0;
>>> +
>>> +if (!pic || !pic->input_image)
>>> +return AVERROR(EINVAL);
>>> +
>>> +fside = av_frame_get_side_data(pic->input_image,
>>> AV_FRAME_DATA_SKIP_FRAME);
>>> +if (fside)
>>> +pic->skipped_flag = AV_RL8(fside->data);
>>> +
Re: [FFmpeg-devel] [PATCH] ffmpeg-opt: mark stream disable options as output-only
On 09-12-2018 11:32 PM, Michael Niedermayer wrote: On Sat, Dec 08, 2018 at 06:56:10PM +0530, Gyan Doshi wrote: I see users with these options set in front of input. Stream disabling for input requires -discard though one packet tends to get smuggled across. But that's for another patch. Gyan ffmpeg_opt.c |8 1 file changed, 4 insertions(+), 4 deletions(-) 5c75ce498cd80cd36b868e1401c3700bb7363b94 0001-ffmpeg-opt-mark-stream-disable-options-as-output-onl.patch From f0e78555d6ea5510922e2d543c9b69dff7d480b5 Mon Sep 17 00:00:00 2001 From: Gyan Doshi Date: Sat, 8 Dec 2018 18:49:34 +0530 Subject: [PATCH] ffmpeg-opt: mark stream disable options as output-only -vn/an/sn/dn are only checked by open_output_file() why not fix it so it works for input too ? I thought it worked in the past but apparently not for the version i tried but its a intuitiv thing to use to discard a stream at demuxer/parser stage ok, will look into it. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V1 1/2] lavfi/vf_scale_vaapi: add scaling mode setting support.
On 06/12/2018 10:39, Jun Zhao wrote:
> before this change, scale_vaapi hard coding the scaling mode, add a
> new option "mode" to setting the scaling mode, it can be use to change
> scaling algorithm for performance/quality trade off.
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/vf_scale_vaapi.c | 33 ++---
> 1 files changed, 30 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
> index d6529d5..ad222e6 100644
> --- a/libavfilter/vf_scale_vaapi.c
> +++ b/libavfilter/vf_scale_vaapi.c
> @@ -35,10 +35,26 @@ typedef struct ScaleVAAPIContext {
>
> char *output_format_string;
>
> +int mode;
> +
> char *w_expr; // width expression string
> char *h_expr; // height expression string
> } ScaleVAAPIContext;
>
> +static const char *scale_vaapi_mode_name(int mode)
> +{
> +switch (mode) {
> +#define D(name) case VA_FILTER_SCALING_ ## name: return #name
> +D(DEFAULT);
> +D(FAST);
> +D(HQ);
> +#undef D
> +default:
> +return "Invalid";
> +}
> +}
> +
> +
> static int scale_vaapi_config_output(AVFilterLink *outlink)
> {
> AVFilterLink *inlink = outlink->src->inputs[0];
> @@ -70,6 +86,7 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink,
> AVFrame *input_frame)
> AVFilterContext *avctx = inlink->dst;
> AVFilterLink *outlink= avctx->outputs[0];
> VAAPIVPPContext *vpp_ctx = avctx->priv;
> +ScaleVAAPIContext *ctx = avctx->priv;
> AVFrame *output_frame= NULL;
> VASurfaceID input_surface, output_surface;
> VAProcPipelineParameterBuffer params;
> @@ -119,7 +136,7 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink,
> AVFrame *input_frame)
> params.output_color_standard = params.surface_color_standard;
>
> params.pipeline_flags = 0;
> -params.filter_flags = VA_FILTER_SCALING_HQ;
> +params.filter_flags |= ctx->mode;
"=" would feel safer - "|=" implies something else might have been setting it
as well.
>
> err = ff_vaapi_vpp_render_picture(avctx, , output_surface);
> if (err < 0)
> @@ -131,9 +148,10 @@ static int scale_vaapi_filter_frame(AVFilterLink
> *inlink, AVFrame *input_frame)
>
> av_frame_free(_frame);
>
> -av_log(avctx, AV_LOG_DEBUG, "Filter output: %s, %ux%u (%"PRId64").\n",
> +av_log(avctx, AV_LOG_DEBUG, "Filter output: %s, %ux%u (%"PRId64"), mode:
> %s.\n",
> av_get_pix_fmt_name(output_frame->format),
> - output_frame->width, output_frame->height, output_frame->pts);
> + output_frame->width, output_frame->height, output_frame->pts,
> + scale_vaapi_mode_name(ctx->mode));
>
> return ff_filter_frame(outlink, output_frame);
>
> @@ -174,6 +192,15 @@ static const AVOption scale_vaapi_options[] = {
>OFFSET(h_expr), AV_OPT_TYPE_STRING, {.str = "ih"}, .flags = FLAGS },
> { "format", "Output video format (software format of hardware frames)",
>OFFSET(output_format_string), AV_OPT_TYPE_STRING, .flags = FLAGS },
> +{ "mode", "Scaling mode",
> + OFFSET(mode), AV_OPT_TYPE_INT, { .i64 = VA_FILTER_SCALING_HQ },
> + 0, VA_FILTER_SCALING_NL_ANAMORPHIC, FLAGS, "mode" },
NL_ANAMORPHIC mentioned in this limit but not offered as an option?
> +{ "default", "Use the default (depend on the driver) scaling algorithm",
> + 0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_DEFAULT }, 0, 0,
> FLAGS, "mode" },
> +{ "fast", "Use fast scaling algorithm",
> + 0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_FAST }, 0, 0, FLAGS,
> "mode" },
> +{ "hq", "Use high quality scaling algorithm",
> + 0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_HQ }, 0, 0, FLAGS,
> "mode" },
> { NULL },
> };
>
>
LGTM in any case.
(Ack on keeping the HQ default - IIRC the reason for choosing HQ as the mode
when this was written was that the default/fast mode was not faster and had
much worse quality on some of the older Intel platforms (I would guess Bay
Trail based on what I probably had available at the time). Might be worth
investigating further if you have such machines available to test.)
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V1 2/2] lavc/vaapi_encode: fix slices number check.
On 06/12/2018 10:39, Jun Zhao wrote:
> Fix slice number check logic. Only when the user setting slices
> number more than the driver constraints dump the rounded up warning
> message.
>
> Signed-off-by: Jun Zhao
> ---
> libavcodec/vaapi_encode.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index eda8a36..3c8a33d 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1572,7 +1572,7 @@ static av_cold int
> vaapi_encode_init_slice_structure(AVCodecContext *avctx)
> return AVERROR(EINVAL);
> }
>
> -if (ctx->nb_slices > avctx->slices) {
> +if (ctx->nb_slices < avctx->slices) {
> av_log(avctx, AV_LOG_WARNING, "Slice count rounded up to "
> "%d (from %d) due to driver constraints on slice "
> "structure.\n", ctx->nb_slices, avctx->slices);
>
No? The existing check looks right to me - we warn if the number got increased
over what the user specified due to driver constraints. (We don't allow it to
decrease unless the supplied number is larger than the number of rows, which
gets warned about above there.)
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/matroskadec: Do not use strncat() to limit copying a one-char constant
On 06/12/2018 22:26, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch silences a new gcc warning, alternative would be to
> disable the warning.
>
> Please comment, Carl Eugen
>
>
> From dd49cddc6fad136222d4a168301059d55fea4a4c Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Thu, 6 Dec 2018 23:23:12 +0100
> Subject: [PATCH] lavf/matroskadec: Do not use strncat() to limit copying a
> one-char constant.
>
> Silences a warning:
> libavformat/matroskadec.c: In function 'webm_dash_manifest_cues':
> libavformat/matroskadec.c:3947:13: warning: 'strncat' specified bound 1
> equals source length [-Wstringop-overflow=]
> strncat(buf, ",", 1);
> ^~~~
> ---
> libavformat/matroskadec.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 2daa1db..df820b4 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -3944,7 +3944,7 @@ static int webm_dash_manifest_cues(AVFormatContext *s,
> int64_t init_range)
> }
> end += ret;
> if (i != s->streams[0]->nb_index_entries - 1) {
> -strncat(buf, ",", 1);
> +strcat(buf, ",");
> end++;
> }
> }
> --
> 1.7.10.4
>
LGTM.
(Optional: perhaps nicer to remove that code fragment with the str(n?)cat
completely by including the comma in the snprintf above, as '"%s", i !=
s->streams[0]->nb_index_entries - 1 ? "," : ""'?)
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg-opt: mark stream disable options as output-only
On Sat, Dec 08, 2018 at 06:56:10PM +0530, Gyan Doshi wrote: > I see users with these options set in front of input. > > Stream disabling for input requires -discard though one packet tends to get > smuggled across. But that's for another patch. > > Gyan > ffmpeg_opt.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > 5c75ce498cd80cd36b868e1401c3700bb7363b94 > 0001-ffmpeg-opt-mark-stream-disable-options-as-output-onl.patch > From f0e78555d6ea5510922e2d543c9b69dff7d480b5 Mon Sep 17 00:00:00 2001 > From: Gyan Doshi > Date: Sat, 8 Dec 2018 18:49:34 +0530 > Subject: [PATCH] ffmpeg-opt: mark stream disable options as output-only > > -vn/an/sn/dn are only checked by open_output_file() why not fix it so it works for input too ? I thought it worked in the past but apparently not for the version i tried but its a intuitiv thing to use to discard a stream at demuxer/parser stage [...] -- 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 signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/decode: Initialize a return value on get_format() error
On 06/12/2018 22:27, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch silences a clang warning, please comment.
>
> Carl Eugen
>
>
> From 3b5fc2473235410920ca89c7d84654e2ce8fb29d Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Thu, 6 Dec 2018 23:17:13 +0100
> Subject: [PATCH] lavc/decode: Initialize return value for get_format()
> failure.
>
> Silences a warning:
> libavcodec/decode.c:1378:13: warning: variable 'ret' is used uninitialized
> whenever 'if' condition is true
> ---
> libavcodec/decode.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index c89c77c..a32ff2f 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1378,6 +1378,7 @@ int ff_get_format(AVCodecContext *avctx, const enum
> AVPixelFormat *fmt)
> if (i == n) {
> av_log(avctx, AV_LOG_ERROR, "Invalid return from get_format(): "
> "%s not in possible list.\n", desc->name);
> +ret = AV_PIX_FMT_NONE;
> break;
> }
>
> --
> 1.7.10.4
>
LGTM.
I think I'd also be happy with an assert there that this doesn't happen - it's
difficult to argue that the user returning a nonsensical value from get_format
is anything other than undefined behaviour.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavd/v4l2: Use ioctl(..., "int request" ) on Android
On 06/12/2018 22:37, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes building with new Android toolchain, used to be a
> warning.
>
> Please comment, Carl Eugen
>
> From d366c948af086520bfb2a4048e76f8d117690776 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Thu, 6 Dec 2018 23:34:54 +0100
> Subject: [PATCH] lavd/v4l2: Use "int request" as second parameter for ioctl()
> on Android.
>
> Fixes build with new Android toolchain.
> ---
> libavdevice/v4l2.c |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
> index 10a0ff0..aa7c052 100644
> --- a/libavdevice/v4l2.c
> +++ b/libavdevice/v4l2.c
> @@ -95,7 +95,11 @@ struct video_data {
> int (*open_f)(const char *file, int oflag, ...);
> int (*close_f)(int fd);
> int (*dup_f)(int fd);
> +#ifdef __ANDROID__
> +int (*ioctl_f)(int fd, int request, ...);
> +#else
> int (*ioctl_f)(int fd, unsigned long int request, ...);
> +#endif
> ssize_t (*read_f)(int fd, void *buffer, size_t n);
> void *(*mmap_f)(void *start, size_t length, int prot, int flags, int fd,
> int64_t offset);
> int (*munmap_f)(void *_start, size_t length);
> --
> 1.7.10.4
>
LGTM on its own, but should this perhaps be "#ifndef (glibc something)" for the
first case? Looking at possible V4L2-hosting libcs, only glibc has the
nonstandard* "unsigned long" rather than "int" as the request argument, so I
expect we're going to hit this in more cases (e.g. musl) if compilers are now
complaining about it.
Thanks,
- Mark
* POSIX -
.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libaomenc: add row-mt option
On 12/9/2018 2:25 PM, Mark Thompson wrote:
> On 08/12/2018 23:18, James Almer wrote:
>> Default to disable, same as aomenc.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/libaomenc.c | 11 +++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
>> index 17565017b4..1d3cef73f3 100644
>> --- a/libavcodec/libaomenc.c
>> +++ b/libavcodec/libaomenc.c
>> @@ -78,6 +78,7 @@ typedef struct AOMEncoderContext {
>> int tile_cols_log2, tile_rows_log2;
>> aom_superblock_size_t superblock_size;
>> int uniform_tiles;
>> +int row_mt;
>> } AOMContext;
>>
>> static const char *const ctlidstr[] = {
>> @@ -92,6 +93,9 @@ static const char *const ctlidstr[] = {
>> [AV1E_SET_SUPERBLOCK_SIZE] = "AV1E_SET_SUPERBLOCK_SIZE",
>> [AV1E_SET_TILE_COLUMNS] = "AV1E_SET_TILE_COLUMNS",
>> [AV1E_SET_TILE_ROWS]= "AV1E_SET_TILE_ROWS",
>> +#ifdef AOM_CTRL_AV1E_SET_ROW_MT
>> +[AV1E_SET_ROW_MT] = "AV1E_SET_ROW_MT",
>> +#endif
>> };
>>
>> static av_cold void log_encoder_error(AVCodecContext *avctx, const char
>> *desc)
>> @@ -650,6 +654,10 @@ static av_cold int aom_init(AVCodecContext *avctx,
>> codecctl_int(avctx, AV1E_SET_TILE_ROWS,ctx->tile_rows_log2);
>> }
>>
>> +#ifdef AOM_CTRL_AV1E_SET_ROW_MT
>> +codecctl_int(avctx, AV1E_SET_ROW_MT, ctx->row_mt);
>> +#endif
>> +
>> // provide dummy value to initialize wrapper, values will be updated
>> each _encode()
>> aom_img_wrap(>rawimg, img_fmt, avctx->width, avctx->height, 1,
>> (unsigned char*)1);
>> @@ -983,6 +991,9 @@ static const AVOption options[] = {
>> { "tiles","Tile columns x rows", OFFSET(tile_cols),
>> AV_OPT_TYPE_IMAGE_SIZE, { .str = NULL }, 0, 0, VE },
>> { "tile-columns", "Log2 of number of tile columns to use",
>> OFFSET(tile_cols_log2), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
>> { "tile-rows","Log2 of number of tile rows to use",
>> OFFSET(tile_rows_log2), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
>> +#ifdef AOM_CTRL_AV1E_SET_ROW_MT
>> +{ "row-mt", "Enable row based multi-threading",
>> OFFSET(row_mt), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, VE},
>> +#endif
>> { NULL }
>> };
>
> With matching update to doc/encoders.texi, LGTM.
>
> Is there any reason not to enable it by default when threads are enabled?
> (E.g. because it can make the quality worse somehow?)
I don't know, maybe it disables tile multi-threading if it's enabled?
I decided to use the same default value aomenc sets for it, since a
feature being disabled by default tends to hint that it's either not yet
mature, or that the cons outweigh the pros.
>
> Thanks,
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH, v2] lavc/hevc_parser: add 4 bytes startcode condition and update FATE
On 07/12/2018 11:33, Linjie Fu wrote:
> The startcode before VPS,SPS,PPS and the first NALU in an AU is 4 bytes.
> Blindly taking the startcode as 3 bytes will leave 0x00 in last packet
> and may lead to some warnings in parse_nal_units when s->flags is set to
> PARSER_FLAG_COMPLETE_FRAMES.
>
> Add 4 bytes startcode condition in hevc_find_frame_end.
> Modify the code to print the buf_size like in H264 and reduce the duplication.
>
> Update the FATE checksum for fate-hevc-bsf-mp4toannexb:
> The ref output has redundant 0x00 at the end of the SUFFIX_SEI:
> { 50 01 84 31 00 19 39 77 d0 7b 3f bd 1e 09 38 9a 79 41
> c0 16 11 da 18 aa 0a db 2b 19 fa 47 3f 0f 67 4a 91 9c a1
> 12 72 67 d6 f0 8f 66 ee 95 f9 e2 b9 ba 23 9a e8 80 00 }
>
> To verify the output of FATE:
> ffmpeg -i hevc-conformance/WPP_A_ericsson_MAIN10_2.bit -c copy -flags \
> +bitexact hevc-mp4.mov
> ffmpeg -i hevc-mp4.mov -c:v copy -fflags +bitexact -f hevc hevc.out
>
> Signed-off-by: Linjie Fu
> ---
> [v2]: Update FATE checksum
>
> libavcodec/hevc_parser.c | 15 ++-
> tests/fate/hevc.mak | 2 +-
> 2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> index 369d1338d0..aa216e3c8d 100644
> --- a/libavcodec/hevc_parser.c
> +++ b/libavcodec/hevc_parser.c
> @@ -32,6 +32,7 @@
> #include "parser.h"
>
> #define START_CODE 0x01 ///< start_code_prefix_one_3bytes
> +#define START_CODE_4 0x0001 ///< start_code_4bytes
(There is no syntax element called "start_code_4bytes".)
>
> #define IS_IRAP_NAL(nal) (nal->type >= 16 && nal->type <= 23)
> #define IS_IDR_NAL(nal) (nal->type == HEVC_NAL_IDR_W_RADL || nal->type ==
> HEVC_NAL_IDR_N_LP)
> @@ -239,7 +240,7 @@ static int parse_nal_units(AVCodecParserContext *s, const
> uint8_t *buf,
> }
> }
> /* didn't find a picture! */
> -av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n");
> +av_log(avctx, AV_LOG_ERROR, "missing picture in access unit with size
> %d\n", buf_size);
> return -1;
> }
>
> @@ -267,8 +268,7 @@ static int hevc_find_frame_end(AVCodecParserContext *s,
> const uint8_t *buf,
> if ((nut >= HEVC_NAL_VPS && nut <= HEVC_NAL_EOB_NUT) || nut ==
> HEVC_NAL_SEI_PREFIX ||
> (nut >= 41 && nut <= 44) || (nut >= 48 && nut <= 55)) {
> if (pc->frame_start_found) {
> -pc->frame_start_found = 0;
> -return i - 5;
> +goto found;
> }
> } else if (nut <= HEVC_NAL_RASL_R ||
> (nut >= HEVC_NAL_BLA_W_LP && nut <= HEVC_NAL_CRA_NUT)) {
> @@ -277,14 +277,19 @@ static int hevc_find_frame_end(AVCodecParserContext *s,
> const uint8_t *buf,
> if (!pc->frame_start_found) {
> pc->frame_start_found = 1;
> } else { // First slice of next frame found
> -pc->frame_start_found = 0;
> -return i - 5;
> +goto found;
> }
> }
> }
> }
>
> return END_NOT_FOUND;
> +
> +found:
> +pc->frame_start_found = 0;
> +if (((pc->state64 >> 3 * 8) & 0x) == START_CODE_4)
> +return i - 6;
> +return i - 5;
> }
Maybe? Special-casing four bytes doesn't make me feel good about this, given
that leading_zero_8bits can be included as many times as you like at the
beginning of a NAL unit.
If there are a large number of zeroes between two frames, which packet do you
want them to end up in? This changes it from "all at the end of the first
frame" to "all except the last one at the end of the first frame", and it's not
immediately obvious to me why that would be the right choice. Why not, for
example, put all of the zeroes into the second frame?
> static int hevc_parse(AVCodecParserContext *s, AVCodecContext *avctx,
> diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
> index db3ea19340..ab8da53535 100644
> --- a/tests/fate/hevc.mak
> +++ b/tests/fate/hevc.mak
> @@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER MOV_DEMUXER
> HEVC_MP4TOANNEXB_BSF MOV_MUXER
> fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov
> fate-hevc-bsf-mp4toannexb: CMD = md5 -i
> $(TARGET_PATH)/tests/data/hevc-mp4.mov -c:v copy -fflags +bitexact -f hevc
> fate-hevc-bsf-mp4toannexb: CMP = oneline
> -fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9
> +fate-hevc-bsf-mp4toannexb: REF = 73019329ed7f81c24f9af67c34c640c0
>
> fate-hevc-skiploopfilter: CMD = framemd5 -skip_loop_filter nokey -i
> $(TARGET_SAMPLES)/hevc-conformance/SAO_D_Samsung_5.bit -sws_flags bitexact
> FATE_HEVC += fate-hevc-skiploopfilter
>
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libaomenc: add row-mt option
On 08/12/2018 23:18, James Almer wrote:
> Default to disable, same as aomenc.
>
> Signed-off-by: James Almer
> ---
> libavcodec/libaomenc.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 17565017b4..1d3cef73f3 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -78,6 +78,7 @@ typedef struct AOMEncoderContext {
> int tile_cols_log2, tile_rows_log2;
> aom_superblock_size_t superblock_size;
> int uniform_tiles;
> +int row_mt;
> } AOMContext;
>
> static const char *const ctlidstr[] = {
> @@ -92,6 +93,9 @@ static const char *const ctlidstr[] = {
> [AV1E_SET_SUPERBLOCK_SIZE] = "AV1E_SET_SUPERBLOCK_SIZE",
> [AV1E_SET_TILE_COLUMNS] = "AV1E_SET_TILE_COLUMNS",
> [AV1E_SET_TILE_ROWS]= "AV1E_SET_TILE_ROWS",
> +#ifdef AOM_CTRL_AV1E_SET_ROW_MT
> +[AV1E_SET_ROW_MT] = "AV1E_SET_ROW_MT",
> +#endif
> };
>
> static av_cold void log_encoder_error(AVCodecContext *avctx, const char
> *desc)
> @@ -650,6 +654,10 @@ static av_cold int aom_init(AVCodecContext *avctx,
> codecctl_int(avctx, AV1E_SET_TILE_ROWS,ctx->tile_rows_log2);
> }
>
> +#ifdef AOM_CTRL_AV1E_SET_ROW_MT
> +codecctl_int(avctx, AV1E_SET_ROW_MT, ctx->row_mt);
> +#endif
> +
> // provide dummy value to initialize wrapper, values will be updated
> each _encode()
> aom_img_wrap(>rawimg, img_fmt, avctx->width, avctx->height, 1,
> (unsigned char*)1);
> @@ -983,6 +991,9 @@ static const AVOption options[] = {
> { "tiles","Tile columns x rows", OFFSET(tile_cols),
> AV_OPT_TYPE_IMAGE_SIZE, { .str = NULL }, 0, 0, VE },
> { "tile-columns", "Log2 of number of tile columns to use",
> OFFSET(tile_cols_log2), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
> { "tile-rows","Log2 of number of tile rows to use",
> OFFSET(tile_rows_log2), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
> +#ifdef AOM_CTRL_AV1E_SET_ROW_MT
> +{ "row-mt", "Enable row based multi-threading",
> OFFSET(row_mt), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, VE},
> +#endif
> { NULL }
> };
With matching update to doc/encoders.texi, LGTM.
Is there any reason not to enable it by default when threads are enabled?
(E.g. because it can make the quality worse somehow?)
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_refs: reset MMCO when invalid mmco code is found
On 12/9/18, Mark Thompson wrote:
> On 09/12/2018 13:54, Paul B Mahol wrote:
>> On 12/9/18, Mark Thompson wrote:
>>> On 09/12/2018 08:52, Paul B Mahol wrote:
On 12/7/18, Paul B Mahol wrote:
> On 12/7/18, Michael Niedermayer wrote:
>> On Fri, Dec 07, 2018 at 10:36:23AM +0100, Paul B Mahol wrote:
>>> On 12/7/18, Paul B Mahol wrote:
On 12/7/18, Michael Niedermayer wrote:
> On Thu, Dec 06, 2018 at 03:26:41PM +0100, Paul B Mahol wrote:
>> This recovers state with #7374 linked sample.
>>
>> Work funded by Open Broadcast Systems.
>>
>> Signed-off-by: Paul B Mahol
>> ---
>> libavcodec/h264_refs.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
>> index eaf965e43d..5645a203a7 100644
>> --- a/libavcodec/h264_refs.c
>> +++ b/libavcodec/h264_refs.c
>> @@ -718,6 +718,7 @@ int
>> ff_h264_execute_ref_pic_marking(H264Context
>> *h)
>> }
>> break;
>> case MMCO_RESET:
>> +default:
>> while (h->short_ref_count) {
>> remove_short(h, h->short_ref[0]->frame_num, 0);
>> }
>> @@ -730,7 +731,6 @@ int
>> ff_h264_execute_ref_pic_marking(H264Context
>> *h)
>> for (j = 0; j < MAX_DELAYED_PIC_COUNT; j++)
>> h->last_pocs[j] = INT_MIN;
>> break;
>> -default: assert(0);
>> }
>> }
>
> mmco[i].opcode should not be invalid, its checked around the point
> where
> this
> array is filled.
> unless there is something iam missing
Yes, you are missing big time.
If you think by "checked" about those nice asserts they are not
enabled
at
all.
>>>
>>> There is check for invalid opcode, but stored invalid opcode is not
>>> changed.
>>
>> Theres no question that we end with a invalid value in the struct, but
>> that
>> is not intended to be in there. You can see that this is not intended
>> by
>> simply looking at the variable that holds the number of entries, it is
>> not written at all in this case.
>>
>> So for example if this code stores 5 correct looking mmcos and the 6th
>> is
>> invalid, 6 are in the array but the number of entries is just left
>> where
>> it
>> was, that could be maybe 3 or 8 or 1. Just "defaulting out" the
>> invalid
>> value
>> later doesnt feel ideal.
>
> Nope, mmco state is left in inconsistent state, and my patch fix it. As
> you
> provided nothing valuable to consider as alternative I will apply it.
>
What about converting any invalid mmco opcode to mmco reset and
updating mmco size too?
Currently mmco size is left in previous state.
>>>
>>> Don't invent a new RESET (= 5) operation - that type is special and its
>>> presence implies other constraints which we probably don't want to think
>>> about here (around frame_num in particular).
>>>
>>> I think END / truncating the list would be best option?
>>>
>>
>> Nope, that would still put it into bad state. With your approach decoder
>> does
>> not recover from artifacts. Try sample from bug report #7374.
>
> Adding a spurious reset here throws away all previous reference frames,
> which will break the stream where it wouldn't otherwise be if the corrupted
> frame would have been bypassed for referencing. For example, in real-time
> cases with feedback a stream which has encountered errors can be recovered
> without an intra frame by referring to an older frame which still exists in
> the DPB.
So instead of fixing all frames after error you prefer keeping old
code which will keep spurious errors all the time, keeping decoder
useless.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/zmbvenc.c: don't allow motion estimation out of range.
On Sat, Dec 08, 2018 at 02:53:44PM +0100, Tomas Härdin wrote:
> lör 2018-12-08 klockan 00:29 + skrev Matthew Fearnley:
> > Hi Tomas, thanks for looking through my patch.
> >
> > > > Practically, this patch fixes graphical glitches e.g. when reencoding
> >
> > the
> > > > Commander Keen sample video with me_range 65 or higher:
> > > >
> > > > ffmpeg -i keen4e_000.avi -c:v zmbv -me_range 65 keen4e_me65.avi
> > > I'd expect this problem to pop up with -me_range 64 too, no?
> >
> > I initially thought this would be the case, but taking the tx loop and
> > removing the edge constraints:
> >
> > for(tx = x - c->range; tx < x + c->range; tx++){
> > ...
> > dx = tx - x;
> >
> > The effective range is (-c->range) <= dx < (c->range), meaning when
> > c->range = me_range = 64, the dx value ranges from -64 to 63, which happens
> > to be exactly in bounds.
> > So I could have just capped me_range to 64, and that would have fixed the
> > bug...
> >
> > But more generally, I've concluded the '<' sign is a mistake, not just
> > because of the general asymmetry, but because of the way it prevents tx,ty
> > reaching the bottom/right edges.
> > In practice it means, for example, that if the screen pans left to right,
> > the bottom edge will have to match against blocks elsewhere in the image.
> >
> > > I went over the patch, and it looks fine. But what's up with the xored
> > > logic? It seems like it would compute xored always from the bottom-
> > > right-most MV. The loop in zmbv_me() should probably have a temporary
> > > xored and only output to *xored in if(tv < bv)..
> >
> > Hmm, you're right. In most cases, the code actually works anyway - because
> > when *xored==0, the block entropy returned by block_cmp() is supposed to be
> > 0 anyway, so it still finishes then.
> > But... I've realised there are some exceptions to this:
> > - the entropy calculations in block_cmp() use a lookup table
> > (score_tab[256]), which assumes each block has 16*16 pixels. This will
> > only be valid when the dimensions are a multiple of 16, otherwise the
> > bottom/right edge blocks may be smaller.
> > - I've just realised the lookup table only goes up to 255. If all 16*16
> > xored pixels are the same value, it will hit the 256th entry! (I'm
> > surprised valgrind hasn't found this..?)
>
> Static analysis would've caught this, which is something I've harped on
> previously on this list (http://ffmpeg.org/pipermail/ffmpeg-devel/2018-
> June/231598.html)
>
> > All that said, *xored==0 is actually the most desirable outcome because it
> > means the block doesn't need to be output.
> > So if *xored is 0, the best thing to do is probably to finish immediately
> > (making sure *mx,*my are set), without processing any more MVs.
> > And then it doesn't matter (from a correctness point of view, at least) if
> > block_cmp() gives bad entropy results, as long as *xored is set correctly.
>
> Oh yeah, that's right. It might also be a good idea to try the MV of
> the previous block first for the next block, since consecutive blocks
> are likely to have the same MV. Even fancier would be to gather
> statistics from the previous frame, and try MVs in order of decreasing
> popularity. A threshold might also be useful, like "accept any MV that
> results in no more than N bits entropy"
looking at existing fancy motion estimation methods, for example variants of
predictive zonal searches. Might safe some time from redesigning a ME method
from scratch
also maybe something from libavcodec/motion_est.c can be reused
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AMD Vega 56, UVD and OpenCL
On Sun, 9 Dec 2018 at 13:37, Mark Thompson wrote: > On 09/12/2018 01:22, James Courtier-Dutton wrote: > > Hi, > > > > I little off topic, but hopefully someone here might be able to help me > as > > it is video processing related. > > > > I wish to use UVD to send a video stream to the GPU, and then have OpenCL > > process the output video frames. > > > > Can anyone point me to example source code to achieve this in Linux. > > AMD does not support any GPU-side OpenCL interop on Linux - you will need > to copy using the CPU. > > Just to clarify. Does the hardware (Vega 56) support it? Is it just that the Linux drivers do not have that functionality yet? Kind Regards James ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V4 0/2] Add libsvt HEVC encoder wrapper
2018-12-09 10:24 GMT+01:00, Jun Zhao : > SVT-HEVC encoder have some interesting features compare > with the existing HEVC encoder. > > - Multidimensional parallelism > a). Picture-based parallelism > b). Segment-based parallelism (scales over many CPU cores) > c). Will support tile-based parallelism soon > > - Human Visual System(HVS)-optimized classification for > a). Data-efficient processing > b). Computationally efficient partitioning and mode decision > c). Higher coding efficiency > > - Resource adaptive scalability > a). Speed up factor vs HM 16 about 70 times (4K/60fps content, > SVT-HEVC enable subjective quality mode with preset setting > with M0(highest quality)) > b). Outperformance the x265 encoder in CQP mode > > Some performance data: > - Real-time encoding of up to 1x 8Kp60/10-bit streams on the > Platinum 8180 with preset M11/subjective quality mode > > - Real-time encoding of up to 2x 8Kp50/10-bit streams on the > Platinum 8180 with preset M12/subjective quality mode > > - Real-time encoding of up to 4x 4Kp60/10-bit streams on the > Gold 6148 with preset M12/subjective quality mode > > - Real-time encoding of up to 6x 4Kp60/10-bit streams on the >Platinum 8180 with preset M12/subjective quality mode To me, this does not sound much better than the information libturing provided and we rejected the patch. I have no objections but a better reasoning may be desirable, especially regarding the subjective quality of the output streams. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/cbs_vp9: Avoid an implicit conversion from 255 to -1
On 07/12/2018 00:17, James Almer wrote: > On 12/6/2018 8:29 PM, Carl Eugen Hoyos wrote: >> Hi! >> >> Attached patch silences an ugly clang warning. >> >> Please comment, Carl Eugen >> >> >> 0001-lavc-cbs_vp9-Avoid-an-implicit-conversion-from-255-t.patch >> >> From 20a643259b8e382bdfd759af78c36c3442c0affc Mon Sep 17 00:00:00 2001 >> From: Carl Eugen Hoyos >> Date: Fri, 7 Dec 2018 00:26:40 +0100 >> Subject: [PATCH] lavc/cbs_vp9: Avoid an implicit conversion from 255 to -1. >> >> Silences a warning with clang: >> libavcodec/cbs_vp9_syntax_template.c:220:17: warning: implicit conversion >> from 'int' to 'int8_t' (aka 'signed char') >> changes value from 255 to -1 >> --- >> libavcodec/cbs_vp9.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c >> index c03ce98..95d147d 100644 >> --- a/libavcodec/cbs_vp9.c >> +++ b/libavcodec/cbs_vp9.c >> @@ -310,7 +310,7 @@ static int cbs_vp9_write_le(CodedBitstreamContext *ctx, >> PutBitContext *pbc, >> if (prob_coded) \ >> xf(8, name.prob, prob, subs, __VA_ARGS__); \ >> else \ >> -prob = 255; \ >> +prob = -1; \ > > I think it may be better to make prob uint8_t instead, Yes, this. The values are all uint8_t, so this one should be too. Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V4 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.
On 09/12/2018 09:24, Jun Zhao wrote:
> base on patch by Huang, Zhengxu from https://github.com/intel/SVT-HEVC
>
> Signed-off-by: Huang, Zhengxu
> Signed-off-by: hassene
> Signed-off-by: Jun Zhao
> ---
> Changelog|1 +
> configure|4 +
> libavcodec/Makefile |1 +
> libavcodec/allcodecs.c |1 +
> libavcodec/libsvt_hevc.c | 506
> ++
> 5 files changed, 513 insertions(+), 0 deletions(-)
> create mode 100644 libavcodec/libsvt_hevc.c
Given that the interface is still in prototype form, is there any chance of
changing it to something more appropriate for a software encoder? The current
OpenMAX clone does not fit very well.
> diff --git a/libavcodec/libsvt_hevc.c b/libavcodec/libsvt_hevc.c
> new file mode 100644
> index 000..86988d8
> --- /dev/null
> +++ b/libavcodec/libsvt_hevc.c
> @@ -0,0 +1,506 @@
> +/*
> +* Scalable Video Technology for HEVC encoder library plugin
> +*
> +* Copyright (c) 2018 Intel Corporation
> +*
> +* This program 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.
> +*
> +* This program 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 this program; if not, write to the Free Software
> +* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> +*/
> +
> +#include "EbErrorCodes.h"
> +#include "EbTime.h"
> +#include "EbApi.h"
> +
> +#include "libavutil/common.h"
> +#include "libavutil/frame.h"
> +#include "libavutil/opt.h"
> +
> +#include "internal.h"
> +#include "avcodec.h"
> +
> +typedef struct SvtEncoder {
> +EB_H265_ENC_CONFIGURATION enc_params;
> +EB_COMPONENTTYPE*svt_handle;
> +EB_BUFFERHEADERTYPE *in_buf;
> +EB_BUFFERHEADERTYPE *out_buf;
> +int raw_size;
> +} SvtEncoder;
Why is this structure separate from the SvtContext? It seems to have identical
lifetime, so the fields should just be in there.
> +
> +typedef struct SvtParams {
> +int vui_info;
> +int hierarchical_level;
> +int la_depth;
> +int intra_ref_type;
> +int enc_mode;
> +int rc_mode;
> +int scd;
> +int tune;
> +int qp;
> +
> +int aud;
> +
> +int profile;
> +int tier;
> +int level;
> +
> +int base_layer_switch_mode;
> +}SvtParams;
> +
> +typedef struct SvtContext {
> +AVClass *class;
> +SvtEncoder *svt_enc;
> +SvtParams svt_param;
> +int eos_flag;
> +} SvtContext;
> +
> +static void free_buffer(SvtEncoder *svt_enc)
> +{
> +if (svt_enc->in_buf) {
> +EB_H265_ENC_INPUT *in_data = (EB_H265_ENC_INPUT
> *)svt_enc->in_buf->pBuffer;
> +av_freep(_data);
> +av_freep(_enc->in_buf);
> +}
> +av_freep(_enc->out_buf);
> +}
> +
> +static EB_ERRORTYPE alloc_buffer(EB_H265_ENC_CONFIGURATION *config,
> SvtEncoder *svt_enc)
> +{
> +EB_ERRORTYPE ret = EB_ErrorNone;
> +
> +const intpack_mode_10bit =
> +(config->encoderBitDepth > 8) && (config->compressedTenBitFormat ==
> 0) ? 1 : 0;
> +const size_t luma_size_8bit=
> +config->sourceWidth * config->sourceHeight * (1 << pack_mode_10bit);
> +const size_t luma_size_10bit =
> +(config->encoderBitDepth > 8 && pack_mode_10bit == 0) ?
> luma_size_8bit : 0;
> +
> +svt_enc->raw_size = (luma_size_8bit + luma_size_10bit) * 3 / 2;
This seems like a bad idea - a software encoder should allocate its own output
buffers, since it knows how big they should be. Using the OpenMAX abstraction
intended to allow fixed hardware mapping is not helpful.
> +
> +// allocate buffer for in and out
> +svt_enc->in_buf = av_mallocz(sizeof(EB_BUFFERHEADERTYPE));
sizeof(*pointer) rather than sizeof(type), please.
> +svt_enc->out_buf = av_mallocz(sizeof(EB_BUFFERHEADERTYPE));
> +if (!svt_enc->in_buf || !svt_enc->out_buf)
> +goto failed;
> +
> +svt_enc->in_buf->pBuffer = av_mallocz(sizeof(EB_H265_ENC_INPUT));
> +if (!svt_enc->in_buf->pBuffer)
> +goto failed;
> +
> +svt_enc->in_buf->nSize= sizeof(EB_BUFFERHEADERTYPE);
> +svt_enc->in_buf->pAppPrivate = NULL;
> +svt_enc->out_buf->nSize = sizeof(EB_BUFFERHEADERTYPE);
> +svt_enc->out_buf->nAllocLen = svt_enc->raw_size;
> +svt_enc->out_buf->pAppPrivate = NULL;
> +
> +return ret;
> +
> +failed:
> +free_buffer(svt_enc);
> +return
Re: [FFmpeg-devel] [PATCH] lavfi/buffersink: fix abuffersink flag setting issue
Jun Zhao (2018-12-09): > abuffersink need to setting AV_OPT_FLAG_AUDIO_PARAM flag. > > Signed-off-by: Jun Zhao > --- > libavfilter/buffersink.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) LGTM, thanks. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi/buffersink: fix abuffersink flag setting issue
abuffersink need to setting AV_OPT_FLAG_AUDIO_PARAM flag.
Signed-off-by: Jun Zhao
---
libavfilter/buffersink.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libavfilter/buffersink.c b/libavfilter/buffersink.c
index 0f87b54..f9b0b5e 100644
--- a/libavfilter/buffersink.c
+++ b/libavfilter/buffersink.c
@@ -320,7 +320,7 @@ static const AVOption buffersink_options[] = {
{ NULL },
};
#undef FLAGS
-#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_AUDIO_PARAM
static const AVOption abuffersink_options[] = {
{ "sample_fmts", "set the supported sample formats",
OFFSET(sample_fmts), AV_OPT_TYPE_BINARY, .flags = FLAGS },
{ "sample_rates","set the supported sample rates",
OFFSET(sample_rates),AV_OPT_TYPE_BINARY, .flags = FLAGS },
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_refs: reset MMCO when invalid mmco code is found
On 09/12/2018 13:54, Paul B Mahol wrote:
> On 12/9/18, Mark Thompson wrote:
>> On 09/12/2018 08:52, Paul B Mahol wrote:
>>> On 12/7/18, Paul B Mahol wrote:
On 12/7/18, Michael Niedermayer wrote:
> On Fri, Dec 07, 2018 at 10:36:23AM +0100, Paul B Mahol wrote:
>> On 12/7/18, Paul B Mahol wrote:
>>> On 12/7/18, Michael Niedermayer wrote:
On Thu, Dec 06, 2018 at 03:26:41PM +0100, Paul B Mahol wrote:
> This recovers state with #7374 linked sample.
>
> Work funded by Open Broadcast Systems.
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/h264_refs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
> index eaf965e43d..5645a203a7 100644
> --- a/libavcodec/h264_refs.c
> +++ b/libavcodec/h264_refs.c
> @@ -718,6 +718,7 @@ int ff_h264_execute_ref_pic_marking(H264Context
> *h)
> }
> break;
> case MMCO_RESET:
> +default:
> while (h->short_ref_count) {
> remove_short(h, h->short_ref[0]->frame_num, 0);
> }
> @@ -730,7 +731,6 @@ int ff_h264_execute_ref_pic_marking(H264Context
> *h)
> for (j = 0; j < MAX_DELAYED_PIC_COUNT; j++)
> h->last_pocs[j] = INT_MIN;
> break;
> -default: assert(0);
> }
> }
mmco[i].opcode should not be invalid, its checked around the point
where
this
array is filled.
unless there is something iam missing
>>>
>>> Yes, you are missing big time.
>>> If you think by "checked" about those nice asserts they are not
>>> enabled
>>> at
>>> all.
>>>
>>
>> There is check for invalid opcode, but stored invalid opcode is not
>> changed.
>
> Theres no question that we end with a invalid value in the struct, but
> that
> is not intended to be in there. You can see that this is not intended by
> simply looking at the variable that holds the number of entries, it is
> not written at all in this case.
>
> So for example if this code stores 5 correct looking mmcos and the 6th
> is
> invalid, 6 are in the array but the number of entries is just left where
> it
> was, that could be maybe 3 or 8 or 1. Just "defaulting out" the invalid
> value
> later doesnt feel ideal.
Nope, mmco state is left in inconsistent state, and my patch fix it. As
you
provided nothing valuable to consider as alternative I will apply it.
>>>
>>> What about converting any invalid mmco opcode to mmco reset and
>>> updating mmco size too?
>>> Currently mmco size is left in previous state.
>>
>> Don't invent a new RESET (= 5) operation - that type is special and its
>> presence implies other constraints which we probably don't want to think
>> about here (around frame_num in particular).
>>
>> I think END / truncating the list would be best option?
>>
>
> Nope, that would still put it into bad state. With your approach decoder does
> not recover from artifacts. Try sample from bug report #7374.
Adding a spurious reset here throws away all previous reference frames, which
will break the stream where it wouldn't otherwise be if the corrupted frame
would have been bypassed for referencing. For example, in real-time cases with
feedback a stream which has encountered errors can be recovered without an
intra frame by referring to an older frame which still exists in the DPB.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_refs: reset MMCO when invalid mmco code is found
On 12/9/18, Mark Thompson wrote:
> On 09/12/2018 08:52, Paul B Mahol wrote:
>> On 12/7/18, Paul B Mahol wrote:
>>> On 12/7/18, Michael Niedermayer wrote:
On Fri, Dec 07, 2018 at 10:36:23AM +0100, Paul B Mahol wrote:
> On 12/7/18, Paul B Mahol wrote:
>> On 12/7/18, Michael Niedermayer wrote:
>>> On Thu, Dec 06, 2018 at 03:26:41PM +0100, Paul B Mahol wrote:
This recovers state with #7374 linked sample.
Work funded by Open Broadcast Systems.
Signed-off-by: Paul B Mahol
---
libavcodec/h264_refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index eaf965e43d..5645a203a7 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -718,6 +718,7 @@ int ff_h264_execute_ref_pic_marking(H264Context
*h)
}
break;
case MMCO_RESET:
+default:
while (h->short_ref_count) {
remove_short(h, h->short_ref[0]->frame_num, 0);
}
@@ -730,7 +731,6 @@ int ff_h264_execute_ref_pic_marking(H264Context
*h)
for (j = 0; j < MAX_DELAYED_PIC_COUNT; j++)
h->last_pocs[j] = INT_MIN;
break;
-default: assert(0);
}
}
>>>
>>> mmco[i].opcode should not be invalid, its checked around the point
>>> where
>>> this
>>> array is filled.
>>> unless there is something iam missing
>>
>> Yes, you are missing big time.
>> If you think by "checked" about those nice asserts they are not
>> enabled
>> at
>> all.
>>
>
> There is check for invalid opcode, but stored invalid opcode is not
> changed.
Theres no question that we end with a invalid value in the struct, but
that
is not intended to be in there. You can see that this is not intended by
simply looking at the variable that holds the number of entries, it is
not written at all in this case.
So for example if this code stores 5 correct looking mmcos and the 6th
is
invalid, 6 are in the array but the number of entries is just left where
it
was, that could be maybe 3 or 8 or 1. Just "defaulting out" the invalid
value
later doesnt feel ideal.
>>>
>>> Nope, mmco state is left in inconsistent state, and my patch fix it. As
>>> you
>>> provided nothing valuable to consider as alternative I will apply it.
>>>
>>
>> What about converting any invalid mmco opcode to mmco reset and
>> updating mmco size too?
>> Currently mmco size is left in previous state.
>
> Don't invent a new RESET (= 5) operation - that type is special and its
> presence implies other constraints which we probably don't want to think
> about here (around frame_num in particular).
>
> I think END / truncating the list would be best option?
>
Nope, that would still put it into bad state. With your approach decoder does
not recover from artifacts. Try sample from bug report #7374.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/h264_refs: reset MMCO when invalid mmco code is found
On 09/12/2018 08:52, Paul B Mahol wrote:
> On 12/7/18, Paul B Mahol wrote:
>> On 12/7/18, Michael Niedermayer wrote:
>>> On Fri, Dec 07, 2018 at 10:36:23AM +0100, Paul B Mahol wrote:
On 12/7/18, Paul B Mahol wrote:
> On 12/7/18, Michael Niedermayer wrote:
>> On Thu, Dec 06, 2018 at 03:26:41PM +0100, Paul B Mahol wrote:
>>> This recovers state with #7374 linked sample.
>>>
>>> Work funded by Open Broadcast Systems.
>>>
>>> Signed-off-by: Paul B Mahol
>>> ---
>>> libavcodec/h264_refs.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
>>> index eaf965e43d..5645a203a7 100644
>>> --- a/libavcodec/h264_refs.c
>>> +++ b/libavcodec/h264_refs.c
>>> @@ -718,6 +718,7 @@ int ff_h264_execute_ref_pic_marking(H264Context
>>> *h)
>>> }
>>> break;
>>> case MMCO_RESET:
>>> +default:
>>> while (h->short_ref_count) {
>>> remove_short(h, h->short_ref[0]->frame_num, 0);
>>> }
>>> @@ -730,7 +731,6 @@ int ff_h264_execute_ref_pic_marking(H264Context
>>> *h)
>>> for (j = 0; j < MAX_DELAYED_PIC_COUNT; j++)
>>> h->last_pocs[j] = INT_MIN;
>>> break;
>>> -default: assert(0);
>>> }
>>> }
>>
>> mmco[i].opcode should not be invalid, its checked around the point
>> where
>> this
>> array is filled.
>> unless there is something iam missing
>
> Yes, you are missing big time.
> If you think by "checked" about those nice asserts they are not
> enabled
> at
> all.
>
There is check for invalid opcode, but stored invalid opcode is not
changed.
>>>
>>> Theres no question that we end with a invalid value in the struct, but
>>> that
>>> is not intended to be in there. You can see that this is not intended by
>>> simply looking at the variable that holds the number of entries, it is
>>> not written at all in this case.
>>>
>>> So for example if this code stores 5 correct looking mmcos and the 6th is
>>> invalid, 6 are in the array but the number of entries is just left where
>>> it
>>> was, that could be maybe 3 or 8 or 1. Just "defaulting out" the invalid
>>> value
>>> later doesnt feel ideal.
>>
>> Nope, mmco state is left in inconsistent state, and my patch fix it. As you
>> provided nothing valuable to consider as alternative I will apply it.
>>
>
> What about converting any invalid mmco opcode to mmco reset and
> updating mmco size too?
> Currently mmco size is left in previous state.
Don't invent a new RESET (= 5) operation - that type is special and its
presence implies other constraints which we probably don't want to think about
here (around frame_num in particular).
I think END / truncating the list would be best option?
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: calculate and store DAR from user SAR
Fixes #5155
Signed-off-by: Paul B Mahol
---
libavformat/mxfenc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 3549b4137d..b3c8dc43bd 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2726,6 +2726,12 @@ static int mxf_write_packet(AVFormatContext *s, AVPacket
*pkt)
}
}
+if (st->codecpar->sample_aspect_ratio.num &&
st->codecpar->sample_aspect_ratio.den) {
+av_reduce_q(>aspect_ratio,
+av_mul_q(st->codecpar->sample_aspect_ratio,
+ av_make_q(st->codecpar->width,
st->codecpar->height)), INT_MAX);
+}
+
if (st->codecpar->codec_id == AV_CODEC_ID_MPEG2VIDEO) {
if (!mxf_parse_mpeg2_frame(s, st, pkt, )) {
av_log(s, AV_LOG_ERROR, "could not get mpeg2 profile and level\n");
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avutil/rational: add av_reduce_q()
Signed-off-by: Paul B Mahol
---
libavutil/rational.c | 5 +
libavutil/rational.h | 12
2 files changed, 17 insertions(+)
diff --git a/libavutil/rational.c b/libavutil/rational.c
index 35ee08877f..47f64e914e 100644
--- a/libavutil/rational.c
+++ b/libavutil/rational.c
@@ -77,6 +77,11 @@ int av_reduce(int *dst_num, int *dst_den,
return den == 0;
}
+int av_reduce_q(AVRational *dst, AVRational src, int64_t max)
+{
+return av_reduce(>num, >den, src.num, src.den, max);
+}
+
AVRational av_mul_q(AVRational b, AVRational c)
{
av_reduce(, ,
diff --git a/libavutil/rational.h b/libavutil/rational.h
index 5c6b67b4e9..a62b895fff 100644
--- a/libavutil/rational.h
+++ b/libavutil/rational.h
@@ -119,6 +119,18 @@ static inline double av_q2d(AVRational a){
*/
int av_reduce(int *dst_num, int *dst_den, int64_t num, int64_t den, int64_t
max);
+/**
+ * Reduce a rational.
+ *
+ * This is useful for aspect ratio calculations.
+ *
+ * @param[out] dst Destination rational
+ * @param[in] src Source rational
+ * @param[in] max Maximum allowed values for `dst`
+ * @return 1 if the operation is exact, 0 otherwise
+ */
+int av_reduce_q(AVRational *dst, AVRational src, int64_t max);
+
/**
* Multiply two rationals.
* @param b First rational
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] AMD Vega 56, UVD and OpenCL
On 09/12/2018 01:22, James Courtier-Dutton wrote: > Hi, > > I little off topic, but hopefully someone here might be able to help me as > it is video processing related. > > I wish to use UVD to send a video stream to the GPU, and then have OpenCL > process the output video frames. > > Can anyone point me to example source code to achieve this in Linux. AMD does not support any GPU-side OpenCL interop on Linux - you will need to copy using the CPU. - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH, v4] lavc/qsvenc: replace assert with error return
bs->FrameType is not set in MSDK in some cases (mjpeg encode for example),
and assert on a value coming from an external library is not proper.
Add default type check for bs->FrameType, and return invalid data error in
function
ff_qsv_encode to avoid using uninitialized value.
Fix #7593.
Signed-off-by: Linjie Fu
---
[v2]: Add default bs->FrameType check.
[v3]: Add log message.
[v4]: Fix the indentation.
libavcodec/qsvenc.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 7f4592f878..7877956952 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1337,8 +1337,13 @@ int ff_qsv_encode(AVCodecContext *avctx, QSVEncContext
*q,
pict_type = AV_PICTURE_TYPE_P;
else if (bs->FrameType & MFX_FRAMETYPE_B || bs->FrameType &
MFX_FRAMETYPE_xB)
pict_type = AV_PICTURE_TYPE_B;
-else
-av_assert0(!"Uninitialized pict_type!");
+else if (bs->FrameType == MFX_FRAMETYPE_UNKNOWN) {
+pict_type = AV_PICTURE_TYPE_NONE;
+av_log(avctx, AV_LOG_WARNING, "Unkown FrameType, set pict_type to
AV_PICTURE_TYPE_NONE.\n");
+} else {
+av_log(avctx, AV_LOG_ERROR, "Invalid FrameType:%d.\n",
bs->FrameType);
+return AVERROR_INVALIDDATA;
+}
#if FF_API_CODED_FRAME
FF_DISABLE_DEPRECATION_WARNINGS
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: calculate and store DAR from user SAR
Paul B Mahol (2018-12-09):
> >> +if (st->codecpar->sample_aspect_ratio.num &&
> >> st->codecpar->sample_aspect_ratio.den) {
> >> +av_reduce(>aspect_ratio.num, >aspect_ratio.den,
> >> + st->codecpar->sample_aspect_ratio.num *
> >> st->codecpar->width,
> >> + st->codecpar->sample_aspect_ratio.den *
> >> st->codecpar->height, INT_MAX);
> There is no av_reduce_q.
But there are av_mul_q() and av_div_q(), that would make these
computations much more readable, and are protected from overflow.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: calculate and store DAR from user SAR
On 12/9/18, Tomas Härdin wrote:
> fre 2018-12-07 klockan 21:30 +0100 skrev Paul B Mahol:
>> Fixes #5155
>>
>> > Signed-off-by: Paul B Mahol
>> ---
>> libavformat/mxfenc.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> index 3549b4137d..8f762c7eaf 100644
>> --- a/libavformat/mxfenc.c
>> +++ b/libavformat/mxfenc.c
>> @@ -2726,6 +2726,14 @@ static int mxf_write_packet(AVFormatContext *s,
>> AVPacket *pkt)
>> }
>> }
>>
>> +if (st->codecpar->sample_aspect_ratio.num &&
>> st->codecpar->sample_aspect_ratio.den) {
>> +av_reduce(>aspect_ratio.num, >aspect_ratio.den,
>> + st->codecpar->sample_aspect_ratio.num *
>> st->codecpar->width,
>> + st->codecpar->sample_aspect_ratio.den *
>> st->codecpar->height, INT_MAX);
>
> Can these multiplications ever overflow? av_reduce_q might be a better
> choice.
There is no av_reduce_q.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: calculate and store DAR from user SAR
fre 2018-12-07 klockan 21:30 +0100 skrev Paul B Mahol:
> Fixes #5155
>
> > Signed-off-by: Paul B Mahol
> ---
> libavformat/mxfenc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 3549b4137d..8f762c7eaf 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -2726,6 +2726,14 @@ static int mxf_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> }
> }
>
> +if (st->codecpar->sample_aspect_ratio.num &&
> st->codecpar->sample_aspect_ratio.den) {
> +av_reduce(>aspect_ratio.num, >aspect_ratio.den,
> + st->codecpar->sample_aspect_ratio.num *
> st->codecpar->width,
> + st->codecpar->sample_aspect_ratio.den *
> st->codecpar->height, INT_MAX);
Can these multiplications ever overflow? av_reduce_q might be a better
choice.
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/zmbvenc.c: don't allow motion estimation out of range.
lör 2018-12-08 klockan 00:29 + skrev Matthew Fearnley: > All that said, *xored==0 is actually the most desirable outcome because it > means the block doesn't need to be output. > So if *xored is 0, the best thing to do is probably to finish immediately > (making sure *mx,*my are set), without processing any more MVs. > And then it doesn't matter (from a correctness point of view, at least) if > block_cmp() gives bad entropy results, as long as *xored is set correctly. > > Note: the code currently exits on bv==0. It's a very good result, but it > does not always imply the most desirable case, because it will happen if > the xored block contains all 42's (etc), not just all 0's. > It's obviously highly compressible, but it would still be better if the > block could be omitted entirely. Maybe it's an acceptable time/space > tradeoff though. I don't know... Another couple of thoughts crossed my mind regarding scoring: The current scoring is entirely context-less. It might be better to at the last bring in the histogram of the previous block into the current one, to bias the encoder toward outputing similar bytes, thus making zlib's job easier. If blocks are scored primarily based on the number of zeroes, only using the entropy model for breaking ties, then some MVs can be discarded earlier if the number of non-zeroes exceeds the best MV found so far. This should speed the encoder up considerably. It would bias the output toward outputing more zeroes, which may or may not be beneficial for the zlib step. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avformat/concatdec: always re-calculate start time and duration
Marton Balint (2018-11-22):
> This allows the underlying files to change their duration on subsequent
> avformat context opens.
>
> An example use case where this matters:
>
> ffconcat version 1.0
> file dummy.mxf
> file dummy.mxf
>
> ffmpeg -re -stream_loop -1 -i dummy.ffconcat -f sdl2 none
>
> The user can seamlessly change the input by atomically replacing dummy.mxf.
>
> Signed-off-by: Marton Balint
> ---
> libavformat/concatdec.c | 13 +
> 1 file changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
> index ebc50324cc..2ebd2120c3 100644
> --- a/libavformat/concatdec.c
> +++ b/libavformat/concatdec.c
> @@ -355,14 +355,12 @@ static int open_file(AVFormatContext *avf, unsigned
> fileno)
> return ret;
> }
> cat->cur_file = file;
> -if (file->start_time == AV_NOPTS_VALUE)
> -file->start_time = !fileno ? 0 :
> - cat->files[fileno - 1].start_time +
> - cat->files[fileno - 1].duration;
> +file->start_time = !fileno ? 0 :
> + cat->files[fileno - 1].start_time +
> + cat->files[fileno - 1].duration;
> file->file_start_time = (cat->avf->start_time == AV_NOPTS_VALUE) ? 0 :
> cat->avf->start_time;
> file->file_inpoint = (file->inpoint == AV_NOPTS_VALUE) ?
> file->file_start_time : file->inpoint;
> -if (file->duration == AV_NOPTS_VALUE)
> -file->duration = get_best_effort_duration(file, cat->avf);
> +file->duration = get_best_effort_duration(file, cat->avf);
>
> if (cat->segment_time_metadata) {
> av_dict_set_int(>metadata, "lavf.concatdec.start_time",
> file->start_time, 0);
> @@ -529,8 +527,7 @@ static int open_next_file(AVFormatContext *avf)
> ConcatContext *cat = avf->priv_data;
> unsigned fileno = cat->cur_file - cat->files;
>
> -if (cat->cur_file->duration == AV_NOPTS_VALUE)
> -cat->cur_file->duration = get_best_effort_duration(cat->cur_file,
> cat->avf);
> +cat->cur_file->duration = get_best_effort_duration(cat->cur_file,
> cat->avf);
>
> if (++fileno >= cat->nb_files) {
> cat->eof = 1;
I do not think it works. If the duration of the second file changes, for
example, then the start time of all subsequent files changes too, but
this patch does not update it. Seeking will show strange results.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avformat/concatdec: fix cur_dts based duration calculation with nonzero stream start_time
Marton Balint (2018-11-22): > Signed-off-by: Marton Balint > --- > libavformat/concatdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) I suppose it is valid. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec: add gif parser
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/gif_parser.c | 188
libavcodec/parsers.c| 1 +
3 files changed, 190 insertions(+)
create mode 100644 libavcodec/gif_parser.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 5feadac729..d53b8ff330 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1026,6 +1026,7 @@ OBJS-$(CONFIG_DVDSUB_PARSER) += dvdsub_parser.o
OBJS-$(CONFIG_FLAC_PARSER) += flac_parser.o flacdata.o flac.o \
vorbis_data.o
OBJS-$(CONFIG_G729_PARSER) += g729_parser.o
+OBJS-$(CONFIG_GIF_PARSER) += gif_parser.o
OBJS-$(CONFIG_GSM_PARSER) += gsm_parser.o
OBJS-$(CONFIG_H261_PARSER) += h261_parser.o
OBJS-$(CONFIG_H263_PARSER) += h263_parser.o
diff --git a/libavcodec/gif_parser.c b/libavcodec/gif_parser.c
new file mode 100644
index 00..9d31dc7e48
--- /dev/null
+++ b/libavcodec/gif_parser.c
@@ -0,0 +1,188 @@
+/*
+ * GIF parser
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * 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
+ * GIF parser
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/bswap.h"
+#include "libavutil/common.h"
+
+#include "gif.h"
+#include "parser.h"
+
+typedef enum GIFParseStates {
+GIF_HEADER = 1,
+GIF_EXTENSION,
+GIF_EXTENSION_BLOCK,
+GIF_IMAGE,
+GIF_IMAGE_BLOCK,
+} gif_states;
+
+typedef struct GIFParseContext {
+ParseContext pc;
+unsigned found_sig;
+int found_start;
+int found_end;
+int index;
+int state;
+int gct_flag;
+int gct_size;
+int block_size;
+int etype;
+int delay;
+} GIFParseContext;
+
+static int gif_find_frame_end(GIFParseContext *g, const uint8_t *buf,
+ int buf_size, void *logctx)
+{
+int index, next = END_NOT_FOUND;
+
+for (index = 0; index < buf_size; index++) {
+if (!g->state) {
+if (!memcmp(buf + index, gif87a_sig, 6) ||
+!memcmp(buf + index, gif89a_sig, 6)) {
+g->state = GIF_HEADER;
+g->found_sig++;
+} else if (buf[index] == GIF_EXTENSION_INTRODUCER) {
+g->state = GIF_EXTENSION;
+g->found_start = 1;
+} else if (buf[index] == GIF_IMAGE_SEPARATOR) {
+g->state = GIF_IMAGE;
+} else if (buf[index] == GIF_TRAILER) {
+g->state = 0;
+g->found_end = 1;
+g->found_sig = 0;
+} else {
+av_assert0(0);
+}
+}
+
+if (g->state == GIF_HEADER) {
+if (g->index == 10) {
+g->gct_flag = !!(buf[index] & 0x80);
+g->gct_size = 3 * (1 << ((buf[index] & 0x07) + 1));
+}
+if (g->index >= 12 + g->gct_flag * g->gct_size) {
+g->state = 0;
+g->index = 0;
+g->gct_flag = 0;
+g->gct_size = 0;
+continue;
+}
+g->index++;
+} else if (g->state == GIF_EXTENSION) {
+if (g->found_start && g->found_end && g->found_sig) {
+next = index;
+g->found_start = 0;
+g->found_end = 0;
+g->index = 0;
+g->gct_flag = 0;
+g->gct_size = 0;
+g->state = 0;
+break;
+}
+if (g->index == 1) {
+g->etype = buf[index];
+}
+if (g->index >= 2) {
+g->block_size = buf[index];
+g->index = 0;
+g->state = GIF_EXTENSION_BLOCK;
+continue;
+}
+g->index++;
+} else if (g->state == GIF_IMAGE_BLOCK) {
+if (!g->index)
+g->block_size = buf[index];
+if (g->index >= g->block_size) {
+g->index = 0;
+if (!g->block_size) {
+g->state = 0;
+g->found_end = 1;
+}
+continue;
+}
+g->index++;
+
Re: [FFmpeg-devel] [PATCH 2/4] avformat/concatdec: factorize the duration calculating function
Marton Balint (2018-11-22): > Signed-off-by: Marton Balint > --- > libavformat/concatdec.c | 37 +++-- > 1 file changed, 23 insertions(+), 14 deletions(-) LGTM. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avformat/concatdec: set seekable flag after opening the last file
Marton Balint (2018-11-22): > After finishing the last file all durations and start times should be known. > > Signed-off-by: Marton Balint > --- > libavformat/concatdec.c | 1 + > 1 file changed, 1 insertion(+) Ok in principle. I would be more comfortable if some kind of consistency test were added to check the "should", but I do not consider blocking. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V4 2/2] doc: Add libsvt_hevc encoder docs
On 09-12-2018 02:54 PM, Jun Zhao wrote: Add docs for libsvt_hevc encoder in encoders.texi and general.texi Signed-off-by: Jun Zhao Signed-off-by: Huang, Zhengxu Signed-off-by: hassene --- doc/encoders.texi | 157 + doc/general.texi | 14 + 2 files changed, 171 insertions(+), 0 deletions(-) LGTM. Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V4 1/2] lavc/svt_hevc: add libsvt hevc encoder wrapper.
base on patch by Huang, Zhengxu from https://github.com/intel/SVT-HEVC Signed-off-by: Huang, Zhengxu Signed-off-by: hassene Signed-off-by: Jun Zhao --- Changelog|1 + configure|4 + libavcodec/Makefile |1 + libavcodec/allcodecs.c |1 + libavcodec/libsvt_hevc.c | 506 ++ 5 files changed, 513 insertions(+), 0 deletions(-) create mode 100644 libavcodec/libsvt_hevc.c diff --git a/Changelog b/Changelog index 1f53ff4..cef444d 100644 --- a/Changelog +++ b/Changelog @@ -10,6 +10,7 @@ version : - truehd_core bitstream filter - dhav demuxer - PCM-DVD encoder +- add SVT(Scalable Video Technology) HEVC encoder version 4.1: diff --git a/configure b/configure index 642c13d..32bb97e 100755 --- a/configure +++ b/configure @@ -263,6 +263,7 @@ External library support: --enable-libspeexenable Speex de/encoding via libspeex [no] --enable-libsrt enable Haivision SRT protocol via libsrt [no] --enable-libssh enable SFTP protocol via libssh [no] + --enable-libsvt enable HEVC encoding via svt [no] --enable-libtensorflow enable TensorFlow as a DNN module backend for DNN based filters like sr [no] --enable-libtesseractenable Tesseract, needed for ocr filter [no] @@ -1665,6 +1666,7 @@ EXTERNAL_LIBRARY_GPL_LIST=" libcdio libdavs2 librubberband +libsvt libvidstab libx264 libx265 @@ -3130,6 +3132,7 @@ libshine_encoder_select="audio_frame_queue" libspeex_decoder_deps="libspeex" libspeex_encoder_deps="libspeex" libspeex_encoder_select="audio_frame_queue" +libsvt_hevc_encoder_deps="libsvt" libtheora_encoder_deps="libtheora" libtwolame_encoder_deps="libtwolame" libvo_amrwbenc_encoder_deps="libvo_amrwbenc" @@ -6148,6 +6151,7 @@ enabled libsoxr && require libsoxr soxr.h soxr_create -lsoxr enabled libssh&& require_pkg_config libssh libssh libssh/sftp.h sftp_init enabled libspeex && require_pkg_config libspeex speex speex/speex.h speex_decoder_init enabled libsrt&& require_pkg_config libsrt "srt >= 1.3.0" srt/srt.h srt_socket +enabled libsvt&& require_pkg_config libsvt libsvt EbApi.h EbInitHandle enabled libtensorflow && require libtensorflow tensorflow/c/c_api.h TF_Version -ltensorflow enabled libtesseract && require_pkg_config libtesseract tesseract tesseract/capi.h TessBaseAPICreate enabled libtheora && require libtheora theora/theoraenc.h th_info_init -ltheoraenc -ltheoradec -logg diff --git a/libavcodec/Makefile b/libavcodec/Makefile index 5feadac..1a2506a 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -983,6 +983,7 @@ OBJS-$(CONFIG_LIBOPUS_ENCODER)+= libopusenc.o libopus.o \ OBJS-$(CONFIG_LIBSHINE_ENCODER) += libshine.o OBJS-$(CONFIG_LIBSPEEX_DECODER) += libspeexdec.o OBJS-$(CONFIG_LIBSPEEX_ENCODER) += libspeexenc.o +OBJS-$(CONFIG_LIBSVT_HEVC_ENCODER)+= libsvt_hevc.o OBJS-$(CONFIG_LIBTHEORA_ENCODER) += libtheoraenc.o OBJS-$(CONFIG_LIBTWOLAME_ENCODER) += libtwolame.o OBJS-$(CONFIG_LIBVO_AMRWBENC_ENCODER) += libvo-amrwbenc.o diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index d70646e..094ee3c 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -699,6 +699,7 @@ extern AVCodec ff_librsvg_decoder; extern AVCodec ff_libshine_encoder; extern AVCodec ff_libspeex_encoder; extern AVCodec ff_libspeex_decoder; +extern AVCodec ff_libsvt_hevc_encoder; extern AVCodec ff_libtheora_encoder; extern AVCodec ff_libtwolame_encoder; extern AVCodec ff_libvo_amrwbenc_encoder; diff --git a/libavcodec/libsvt_hevc.c b/libavcodec/libsvt_hevc.c new file mode 100644 index 000..86988d8 --- /dev/null +++ b/libavcodec/libsvt_hevc.c @@ -0,0 +1,506 @@ +/* +* Scalable Video Technology for HEVC encoder library plugin +* +* Copyright (c) 2018 Intel Corporation +* +* This program 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. +* +* This program 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 this program; if not, write to the Free Software +* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA +*/ + +#include "EbErrorCodes.h" +#include "EbTime.h" +#include "EbApi.h" + +#include "libavutil/common.h" +#include "libavutil/frame.h" +#include "libavutil/opt.h" + +#include "internal.h" +#include "avcodec.h" + +typedef struct
[FFmpeg-devel] [PATCH V4 0/2] Add libsvt HEVC encoder wrapper
The Scalable Video Technology for HEVC Encoder (SVT-HEVC Encoder) is an HEVC-compliant encoder library core that achieves excellent density-quality tradeoffs, and is highly optimized for Intel Xeon Scalable Processor and Xeon D processors. Intel open source SVT-HEVC encoder in: https://github.com/intel/SVT-HEVC. This wrapper work with SVT-HEVC new_api branch, more information can get from https://github.com/intel/SVT-HEVC/blob/new_api/ffmpeg_plugin/. For SVT-HEVC build, you can switch the branch to new_api, then run: mkdir build && cd build && cmake ../ && make -j `nproc` && sudo make install in the directory. (Yes, SVT-HEVC now support the full CMake style's build/install after the commit https://github.com/intel/SVT-HEVC/commit/f28d492971ef58dc655ccdc7d819cc18ddb45a2f) This patches based on Zhengxu, huang/hassene's hard work. SVT-HEVC encoder have some interesting features compare with the exsting HEVC encoder. - Multidimensional parallelism a). Picture-based parallelism b). Segment-based parallelism (scales over many CPU cores) c). Will support tile-based parallelism soon - Human Visual System(HVS)-optimized classification for a). Data-efficient processsing b). Computationally efficient partitioning and mode decision c). Higher coding efficiency - Resource adaptive scalability a). Speed up factor vs HM 16 about 70 times (4K/60fps content, SVT-HEVC enable subjective quality mode with preset setting with M0(highest quality)) b). Outperformance the x265 encoder in CQP mode Some performance data: - Real-time encoding of up to 1x 8Kp60/10-bit streams on the Platinum 8180 with preset M11/subjective quality mode - Real-time encoding of up to 2x 8Kp50/10-bit streams on the Platinum 8180 with preset M12/subjective quality mode - Real-time encoding of up to 4x 4Kp60/10-bit streams on the Gold 6148 with preset M12/subjective quality mode - Real-time encoding of up to 6x 4Kp60/10-bit streams on the Platinum 8180 with preset M12/subjective quality mode More performance/quality data will be public as a white paper as soon after the internal review finished. V4: - Add more options support and update related docs (profile/aud/tile/...) - Rebase the docs in general.texi based on Gyan's review - Refine the encoder.texi part as Gyan's suggestion V3: - Merge Changelog patch to new wrapper(Tks Moritz/Carl's review) V2: - Refine the error handle (Tks Steven/James's review). - Add docs part (Tks Steven/Moritz's review). - Use named parameters in options. - Follow FFmpeg coding style and Changelog. V1: - Add libsvt hevc encoder wrapper and a Changelog entry. Jun Zhao (2): lavc/svt_hevc: add libsvt hevc encoder wrapper. doc: Add libsvt_hevc encoder docs Changelog|1 + configure|4 + doc/encoders.texi| 157 ++ doc/general.texi | 14 ++ libavcodec/Makefile |1 + libavcodec/allcodecs.c |1 + libavcodec/libsvt_hevc.c | 506 ++ 7 files changed, 684 insertions(+), 0 deletions(-) create mode 100644 libavcodec/libsvt_hevc.c ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH V4 2/2] doc: Add libsvt_hevc encoder docs
Add docs for libsvt_hevc encoder in encoders.texi and general.texi
Signed-off-by: Jun Zhao
Signed-off-by: Huang, Zhengxu
Signed-off-by: hassene
---
doc/encoders.texi | 157 +
doc/general.texi | 14 +
2 files changed, 171 insertions(+), 0 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 4db7764..822044f 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1566,6 +1566,163 @@ Set maximum NAL size in bytes.
Allow skipping frames to hit the target bitrate if set to 1.
@end table
+@section libsvt_hevc
+
+Intel Scalable Video Technology HEVC encoder wrapper.
+
+This encoder requires the presence of the headers and
+library during configuration. You need to explicitly configure the
+build with @code{--enable-libsvt}. The library is detected using
+@command{pkg-config}.
+
+For more information about the library see
+@url{https://github.com/intel/SVT-HEVC.git}.
+
+@subsection Options
+
+The following FFmpeg global options affect the configurations of the
+libsvt_hevc encoder.
+
+@table @option
+@item b (@emph{bitrate})
+Set the bitrate (as a number of bits per second). Default is 7M.
+
+@item refs (@emph{ref})
+Number of reference frames each P-frame can use. The range is from @var{0-16}.
+Default is 0(disabled).
+
+@item g / @option{gop_size}
+Set the GOP size. Default is 64.
+
+@item flags +cgop
+Enable closed GOP.
+
+@item qmin (@emph{min-q})
+Defaults 10
+
+@item qmax (@emph{max-q})
+Defaults 48
+
+Set minimum/maximum quantisation values. Valid range is from 0 to 51
+(Only used when bit rate control mode @option{rc} is set to 0(cqp) mode.
+Has to be qmax > = qmin).
+
+@item profile (@emph{profile})
+Set profile restrictions. Can assume one of the following possible values:
+
+Default is 2 (main10).
+
+@table @samp
+@item main
+main profile
+@item main10
+main10 profile
+@end table
+
+@item level
+
+@option{profile} sets the value of @emph{profile_idc} and the
@emph{constraint_set*_flag}s.
+@option{level} sets the value of @emph{level_idc}.
+
+@end table
+
+The encoder also has its own specific options:
+
+@table @option
+@item vui
+Enables or disables the vui structure in the HEVC elementary
+bitstream. 0 = Off, 1 = On. Default is 0 (Off).
+
+@item aud (@emph{aud})
+Enable use of access unit delimiters when set to 1. Default is 0 (Off).
+
+@item hielevel
+Set hierarchical levels. Can assume one of the following possible values:
+
+Default is 3 (4level).
+
+@table @samp
+@item flat
+none hierarchy level
+@item 2level
+2-level hierarchy
+@item 3level
+3-level hierarchy
+@item 4level
+4-level hierarchy
+@end table
+
+@item la_depth
+Set look-ahead depth, depending on bit rate control mode @option{rc}, when
+bit rate control mode is set to vbr it's best to set this parameter to be
+equal to the intra period value (such is the default set by the encoder),
+when cqp is chosen, then a look ahead is recommended. The range is from
@var{0-256}.
+
+@item intra_ref_type
+Set intra refesh type. Can assume one of the following possible values:
+
+Default is 2 (idr).
+
+@table @samp
+@item cra
+open group of pictures
+@item idr
+closed group of pictures
+@end table
+
+@item preset
+A preset defining the quality vs density tradeoff point that the
+encoding is to be performed at.(e.g. 0 is the highest quality mode,
+12 is the highest density mode). The range is from @var{0-12}. Default is 9.
+
+@item tier
+Set @emph{general_tier_flag}. This may affect the level chosen for the stream
+if it is not explicitly specified. Can assume one of the following possible
values:
+
+Default is 1 (main).
+
+@table @samp
+@item main
+main tier
+@item high
+high tier
+@end table
+
+@item rc
+Set bit rate control mode. Can assume one of the following possible values:
+
+Default is 0 (cqp).
+
+@table @samp
+@item cqp
+Constant QP (CQP) mode
+@item vbr
+Variable Bit Rate (VBR) mode
+@end table
+
+@item qp
+Initial quantization parameter for the intra pictures used when
+@option{rc} is cqp mode. The range is from @var{0-51}. Default is 32.
+
+@item sc_detection
+Enables or disables the scene change detection algorithm. Default is 0
(disable).
+
+@item tune
+Set quality tuning mode. Can assume one of the following possible values:
+
+Default is 1 (objective).
+
+@table @samp
+@item subjective
+Subjective quality mode
+@item objective
+Objective quality mode for PSNR / SSIM / VMAF benchmarking
+@end table
+
+@item bl_mode
+Enables or disables Random Access Prediction. Default is 0 (disable).
+@end table
+
@section libtheora
libtheora Theora encoder wrapper.
diff --git a/doc/general.texi b/doc/general.texi
index 2bc33d1..81995a0 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -126,6 +126,20 @@ The dispatcher is open source and can be downloaded from
with the @code{--enable-libmfx} option and @code{pkg-config} needs to be able
to
locate the dispatcher's @code{.pc} files.
+@section Intel SVT-HEVC
+
+FFmpeg can make use of the
Re: [FFmpeg-devel] [PATCH] avcodec/h264_refs: reset MMCO when invalid mmco code is found
On 12/7/18, Paul B Mahol wrote:
> On 12/7/18, Michael Niedermayer wrote:
>> On Fri, Dec 07, 2018 at 10:36:23AM +0100, Paul B Mahol wrote:
>>> On 12/7/18, Paul B Mahol wrote:
>>> > On 12/7/18, Michael Niedermayer wrote:
>>> >> On Thu, Dec 06, 2018 at 03:26:41PM +0100, Paul B Mahol wrote:
>>> >>> This recovers state with #7374 linked sample.
>>> >>>
>>> >>> Work funded by Open Broadcast Systems.
>>> >>>
>>> >>> Signed-off-by: Paul B Mahol
>>> >>> ---
>>> >>> libavcodec/h264_refs.c | 2 +-
>>> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>> >>>
>>> >>> diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
>>> >>> index eaf965e43d..5645a203a7 100644
>>> >>> --- a/libavcodec/h264_refs.c
>>> >>> +++ b/libavcodec/h264_refs.c
>>> >>> @@ -718,6 +718,7 @@ int ff_h264_execute_ref_pic_marking(H264Context
>>> >>> *h)
>>> >>> }
>>> >>> break;
>>> >>> case MMCO_RESET:
>>> >>> +default:
>>> >>> while (h->short_ref_count) {
>>> >>> remove_short(h, h->short_ref[0]->frame_num, 0);
>>> >>> }
>>> >>> @@ -730,7 +731,6 @@ int ff_h264_execute_ref_pic_marking(H264Context
>>> >>> *h)
>>> >>> for (j = 0; j < MAX_DELAYED_PIC_COUNT; j++)
>>> >>> h->last_pocs[j] = INT_MIN;
>>> >>> break;
>>> >>> -default: assert(0);
>>> >>> }
>>> >>> }
>>> >>
>>> >> mmco[i].opcode should not be invalid, its checked around the point
>>> >> where
>>> >> this
>>> >> array is filled.
>>> >> unless there is something iam missing
>>> >
>>> > Yes, you are missing big time.
>>> > If you think by "checked" about those nice asserts they are not
>>> > enabled
>>> > at
>>> > all.
>>> >
>>>
>>> There is check for invalid opcode, but stored invalid opcode is not
>>> changed.
>>
>> Theres no question that we end with a invalid value in the struct, but
>> that
>> is not intended to be in there. You can see that this is not intended by
>> simply looking at the variable that holds the number of entries, it is
>> not written at all in this case.
>>
>> So for example if this code stores 5 correct looking mmcos and the 6th is
>> invalid, 6 are in the array but the number of entries is just left where
>> it
>> was, that could be maybe 3 or 8 or 1. Just "defaulting out" the invalid
>> value
>> later doesnt feel ideal.
>
> Nope, mmco state is left in inconsistent state, and my patch fix it. As you
> provided nothing valuable to consider as alternative I will apply it.
>
What about converting any invalid mmco opcode to mmco reset and
updating mmco size too?
Currently mmco size is left in previous state.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
