Re: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate continuous memory
> -Original Message-
> From: Fu, Linjie
> Sent: Monday, June 3, 2019 1:17 PM
> To: Li, Zhong ; FFmpeg development discussions and
> patches
> Subject: RE: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate
> continuous memory
>
> > -Original Message-
> > From: Li, Zhong
> > Sent: Friday, May 31, 2019 17:20
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Cc: Fu, Linjie
> > Subject: RE: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate
> > continuous memory
> >
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > > Of Linjie Fu
> > > Sent: Thursday, May 30, 2019 1:01 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Fu, Linjie
> > > Subject: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate
> > > continuous memory
> > >
> > > Mediasdk calls CMRT to copy from video to system memory and requires
> > > memory to be continuously allocated across Y and UV.
> > >
> > > Add a new path to allocate continuous memory when using system out.
> > > Use av_image_fill_pointers to arrange data according to pixfmt.
> > >
> > > Signed-off-by: Linjie Fu
> > > ---
> > > [v2]: use av_image_fill_pointers
> > >
> > > libavfilter/qsvvpp.c | 32 +++-
> > > 1 file changed, 27 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c index
> > > 06efdf5089..6eeed7e632 100644
> > > --- a/libavfilter/qsvvpp.c
> > > +++ b/libavfilter/qsvvpp.c
> > > @@ -27,6 +27,7 @@
> > > #include "libavutil/hwcontext_qsv.h"
> > > #include "libavutil/time.h"
> > > #include "libavutil/pixdesc.h"
> > > +#include "libavutil/imgutils.h"
> > >
> > > #include "internal.h"
> > > #include "qsvvpp.h"
> > > @@ -51,6 +52,7 @@ struct QSVVPPContext {
> > > enum AVPixelFormat out_sw_format; /* Real output format
> */
> > > mfxVideoParam vpp_param;
> > > mfxFrameInfo *frame_infos; /* frame info for each
> > > input */
> > > +AVBufferPool *pool;
> > >
> > > /* members related to the input/output surface */
> > > int in_mem_mode;
> > > @@ -375,10 +377,24 @@ static QSVFrame
> *query_frame(QSVVPPContext *s,
> > > AVFilterLink *outlink)
> > > out_frame->surface = (mfxFrameSurface1
> > > *)out_frame->frame->data[3];
> > > } else {
> > > /* Get a frame with aligned dimensions.
> > > - * Libmfx need system memory being 128x64 aligned */
> > > -out_frame->frame = ff_get_video_buffer(outlink,
> > > -
> > > FFALIGN(outlink->w, 128),
> > > -
> > > FFALIGN(outlink->h, 64));
> > > + * Libmfx need system memory being 128x64 aligned
> > > + * and continuously allocated across Y and UV */
> > > +out_frame->frame = av_frame_alloc();
> > > +if (!out_frame->frame) {
> > > +return NULL;
> >
> > Should be better to return AVERROR(ENOMEM)?
>
> Will refine.
>
> >
> > > +}
> > > +
> > > +out_frame->frame->linesize[0] = FFALIGN(outlink->w, 128);
> > > +out_frame->frame->linesize[1] =
> out_frame->frame->linesize[0];
> > > +out_frame->frame->buf[0] =
> av_buffer_pool_get(s->pool);
> > > +out_frame->frame->format = outlink->format;
> > > +
> > > +if (!out_frame->frame->buf[0])
> > > +return NULL;
> >
> > Same as frame alloc.
>
> Will refine.
> > 1. What is the benefit to use a pool? Comparing with directly alloc a
> > buffer use ()?
> Directly allocate seems to be better.
I am thinking using av_frame_get_buffer() will make life easier or not.
It can make sure memory continuous and call av_buffer_alloc() and
av_image_fill_pointers() internally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate continuous memory
> -Original Message-
> From: Li, Zhong
> Sent: Friday, May 31, 2019 17:20
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: RE: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate
> continuous memory
>
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Thursday, May 30, 2019 1:01 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie
> > Subject: [FFmpeg-devel] [PATCH, v2 1/2] lavf/qsvvpp: allocate continuous
> > memory
> >
> > Mediasdk calls CMRT to copy from video to system memory and requires
> > memory to be continuously allocated across Y and UV.
> >
> > Add a new path to allocate continuous memory when using system out.
> > Use av_image_fill_pointers to arrange data according to pixfmt.
> >
> > Signed-off-by: Linjie Fu
> > ---
> > [v2]: use av_image_fill_pointers
> >
> > libavfilter/qsvvpp.c | 32 +++-
> > 1 file changed, 27 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c index
> > 06efdf5089..6eeed7e632 100644
> > --- a/libavfilter/qsvvpp.c
> > +++ b/libavfilter/qsvvpp.c
> > @@ -27,6 +27,7 @@
> > #include "libavutil/hwcontext_qsv.h"
> > #include "libavutil/time.h"
> > #include "libavutil/pixdesc.h"
> > +#include "libavutil/imgutils.h"
> >
> > #include "internal.h"
> > #include "qsvvpp.h"
> > @@ -51,6 +52,7 @@ struct QSVVPPContext {
> > enum AVPixelFormat out_sw_format; /* Real output format */
> > mfxVideoParam vpp_param;
> > mfxFrameInfo *frame_infos; /* frame info for each
> > input */
> > +AVBufferPool *pool;
> >
> > /* members related to the input/output surface */
> > int in_mem_mode;
> > @@ -375,10 +377,24 @@ static QSVFrame *query_frame(QSVVPPContext
> > *s, AVFilterLink *outlink)
> > out_frame->surface = (mfxFrameSurface1
> > *)out_frame->frame->data[3];
> > } else {
> > /* Get a frame with aligned dimensions.
> > - * Libmfx need system memory being 128x64 aligned */
> > -out_frame->frame = ff_get_video_buffer(outlink,
> > -
> > FFALIGN(outlink->w, 128),
> > -
> > FFALIGN(outlink->h, 64));
> > + * Libmfx need system memory being 128x64 aligned
> > + * and continuously allocated across Y and UV */
> > +out_frame->frame = av_frame_alloc();
> > +if (!out_frame->frame) {
> > +return NULL;
>
> Should be better to return AVERROR(ENOMEM)?
Will refine.
>
> > +}
> > +
> > +out_frame->frame->linesize[0] = FFALIGN(outlink->w, 128);
> > +out_frame->frame->linesize[1] = out_frame->frame->linesize[0];
> > +out_frame->frame->buf[0] = av_buffer_pool_get(s->pool);
> > +out_frame->frame->format = outlink->format;
> > +
> > +if (!out_frame->frame->buf[0])
> > +return NULL;
>
> Same as frame alloc.
Will refine.
>
> > +
> > +av_image_fill_pointers(out_frame->frame->data,
> > out_frame->frame->format,
> > +FFALIGN(outlink->h, 64),
> > out_frame->frame->buf[0]->data,
> > +
> > + out_frame->frame->linesize);
> > if (!out_frame->frame)
> > return NULL;
> >
> > @@ -483,8 +499,13 @@ static int init_vpp_session(AVFilterContext *avctx,
> > QSVVPPContext *s)
> >
> > av_buffer_unref(>hw_frames_ctx);
> > outlink->hw_frames_ctx = out_frames_ref;
> > -} else
> > +} else {
> > s->out_mem_mode = MFX_MEMTYPE_SYSTEM_MEMORY;
> > +s->pool =
> > av_buffer_pool_init(av_image_get_buffer_size(outlink->format,
> > +
> > FFALIGN(outlink->w, 128),
> > +
> > FFALIGN(outlink->h, 64), 1),
> > +av_buffer_allocz);
>
> 1. What is the benefit to use a pool? Comparing with directly alloc a buffer
> use av_buffer_allocz()?
Directly allocate seems to be better.
> 2. av_buffer_allocz() will memset the whole buffer and make performance
> drop. Is it really necessary here?
> If no (I believe so), just use av_buffer_alloc()
I' not quite sure whether the non-initialized padding data introduced by
the alignment will cause some potential run2run issues if we do encoding next.
But as the usages in lavu/frame.c and lavc/avpacket.c, av_buffer_alloc() is
enough.
Will refine and send a new version today.
Thanks.
Linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V1 3/3] lavf/sr: Refine the coding style for init
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Jun Zhao
> Sent: Saturday, June 01, 2019 12:58 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Jun Zhao
> Subject: [FFmpeg-devel] [PATCH V1 3/3] lavf/sr: Refine the coding style for
> init
>
> From: Jun Zhao
>
> We perfer the coding style like:
>
> /* some stuff */
> if (error) {
> /* error handling */
> return -(errorcode);
> }
> /* normal actions */
> do_something()
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/vf_sr.c | 13 ++---
> 1 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/libavfilter/vf_sr.c b/libavfilter/vf_sr.c
> index 0be572f..0433246 100644
> --- a/libavfilter/vf_sr.c
> +++ b/libavfilter/vf_sr.c
> @@ -72,17 +72,16 @@ static av_cold int init(AVFilterContext *context)
> av_log(context, AV_LOG_ERROR, "could not create DNN module for
> requested backend\n");
> return AVERROR(ENOMEM);
> }
> +
> if (!sr_context->model_filename){
> av_log(context, AV_LOG_ERROR, "model file for network was not
> specified\n");
> return AVERROR(EIO);
> -} else {
> -if (!sr_context->dnn_module->load_model) {
> -av_log(context, AV_LOG_ERROR, "load_model for network was
> not specified\n");
> -return AVERROR(EIO);
> -} else {
> -sr_context->model =
> (sr_context->dnn_module->load_model)(sr_context->model_filename);
> -}
> }
> +if (!sr_context->dnn_module->load_model) {
> +av_log(context, AV_LOG_ERROR, "load_model for network was not
> specified\n");
> +return AVERROR(EIO);
> +}
> +sr_context->model =
> (sr_context->dnn_module->load_model)(sr_context->model_filename);
> if (!sr_context->model){
> av_log(context, AV_LOG_ERROR, "could not load DNN model\n");
> return AVERROR(EIO);
looks good. :)
> --
> 1.7.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] lavf/qsv: use av_cold for init/uninit
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Saturday, June 1, 2019 4:41 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] lavf/qsv: use av_cold for init/uninit
>
> Am Fr., 31. Mai 2019 um 10:01 Uhr schrieb Zhong Li :
> >
> > Signed-off-by: Zhong Li
> > ---
> > libavfilter/vf_deinterlace_qsv.c | 2 +-
> > libavfilter/vf_overlay_qsv.c | 2 +-
> > libavfilter/vf_scale_qsv.c | 4 ++--
> > 3 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavfilter/vf_deinterlace_qsv.c
> > b/libavfilter/vf_deinterlace_qsv.c
> > index bee10c220f..80217c8419 100644
> > --- a/libavfilter/vf_deinterlace_qsv.c
> > +++ b/libavfilter/vf_deinterlace_qsv.c
> > @@ -83,7 +83,7 @@ typedef struct QSVDeintContext {
> > int mode;
> > } QSVDeintContext;
> >
> > -static void qsvdeint_uninit(AVFilterContext *ctx)
> > +static av_cold void qsvdeint_uninit(AVFilterContext *ctx)
> > {
> > QSVDeintContext *s = ctx->priv;
> > QSVFrame *cur;
> > diff --git a/libavfilter/vf_overlay_qsv.c
> > b/libavfilter/vf_overlay_qsv.c index 9aabb594ba..2a4dc5cb58 100644
> > --- a/libavfilter/vf_overlay_qsv.c
> > +++ b/libavfilter/vf_overlay_qsv.c
> > @@ -345,7 +345,7 @@ static int overlay_qsv_init(AVFilterContext *ctx)
> > return 0;
> > }
> >
> > -static void overlay_qsv_uninit(AVFilterContext *ctx)
> > +static av_cold void overlay_qsv_uninit(AVFilterContext *ctx)
> > {
> > QSVOverlayContext *vpp = ctx->priv;
> >
> > diff --git a/libavfilter/vf_scale_qsv.c b/libavfilter/vf_scale_qsv.c
> > index 7d593b2b21..db7715fc1b 100644
> > --- a/libavfilter/vf_scale_qsv.c
> > +++ b/libavfilter/vf_scale_qsv.c
> > @@ -109,7 +109,7 @@ typedef struct QSVScaleContext {
> > char *format_str;
> > } QSVScaleContext;
> >
> > -static int qsvscale_init(AVFilterContext *ctx)
> > +static av_cold int qsvscale_init(AVFilterContext *ctx)
> > {
> > QSVScaleContext *s = ctx->priv;
> >
> > @@ -126,7 +126,7 @@ static int qsvscale_init(AVFilterContext *ctx)
> > return 0;
> > }
> >
> > -static void qsvscale_uninit(AVFilterContext *ctx)
> > +static av_cold void qsvscale_uninit(AVFilterContext *ctx)
>
> Patch looks fine to me.
>
> Carl Eugen
Thanks. Will apply
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] lavf/qsv_vpp: add frame format option
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Saturday, June 1, 2019 4:43 AM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavf/qsv_vpp: add frame format
> option
>
> Am Fr., 31. Mai 2019 um 10:01 Uhr schrieb Zhong Li :
>
> > @@ -104,6 +109,8 @@ static const AVOption options[] = {
> > { "width", "Output video width", OFFSET(ow),
> AV_OPT_TYPE_STRING, { .str="cw" }, 0, 255, .flags = FLAGS },
> > { "h", "Output video height", OFFSET(oh),
> AV_OPT_TYPE_STRING, { .str="w*ch/cw" }, 0, 255, .flags = FLAGS },
> > { "height", "Output video height", OFFSET(oh),
> > AV_OPT_TYPE_STRING, { .str="w*ch/cw" }, 0, 255, .flags = FLAGS },
> > +{ "format", "Output pixel format", OFFSET(output_format_str),
> > + AV_OPT_TYPE_STRING, { .str = "same" }, .flags = FLAGS },
>
> AV_OPT_TYPE_PIXEL_FMT?
> Or do I miss something?
>
> Carl Eugen
It is a string and converted to AVPixelFormat using av_get_pix_fmt()
Keep alignment with vf_scaling_qsv/npp/vaapi.c
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V5 1/2] lavfi/colorlevels: Add slice threading support
On Sun, Jun 2, 2019 at 4:19 PM Paul B Mahol wrote: > > On 6/1/19, Jun Zhao wrote: > > From: Jun Zhao > > > > Add slice threading support, use the command like: > > > > ./ffmpeg -i input -vf colorlevels -f null /dev/null > > > > with 1080p h264 clip, the fps from 39 fps to 79 fps > > in the local(Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz) > > > > Signed-off-by: Jun Zhao > > --- > > libavfilter/vf_colorlevels.c | 110 > > ++--- > > 1 files changed, 91 insertions(+), 19 deletions(-) > > Should be ok if filter produces same md5 output with multiple threads. > Pushed, thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V5 2/2] lavfi/lut: Add slice threading support
On Sun, Jun 2, 2019 at 4:13 PM Paul B Mahol wrote: > > On 6/1/19, Jun Zhao wrote: > > -- > > 1.7.1 > > > > Should be ok if md5 hash does not change. > Yes, both changes pass the md5 hash test. Will apply, Thanks ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v5] avformat/ifv: added support for ifv cctv files
On Sun, May 26, 2019 at 01:46:32AM +0530, Swaraj Hota wrote: > Fixes ticket #2956. > > Signed-off-by: Swaraj Hota > --- > Minor changes based on previous discussions. > Seeking is fixed. > --- > Changelog| 1 + > libavformat/Makefile | 1 + > libavformat/allformats.c | 1 + > libavformat/ifv.c| 304 +++ > libavformat/version.h| 4 +- > 5 files changed, 309 insertions(+), 2 deletions(-) > create mode 100644 libavformat/ifv.c > Is the patch okay now? Can it be merged? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/7] hwcontext_vaapi: Add option to set driver name
On 21/05/2019 06:18, Li, Zhong wrote:
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Mark Thompson
>> Sent: Monday, May 6, 2019 10:49 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: [FFmpeg-devel] [PATCH 5/7] hwcontext_vaapi: Add option to set
>> driver name
>>
>> For example: -init_hw_device vaapi:/dev/dri/renderD128,driver=foo
>>
>> This may be more convenient that using the environment variable, and
>> allows loading different drivers for different devices in the same process.
>> ---
>> libavutil/hwcontext_vaapi.c | 19 +++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c index
>> c151f8da93..35883d7855 100644
>> --- a/libavutil/hwcontext_vaapi.c
>> +++ b/libavutil/hwcontext_vaapi.c
>> @@ -1598,6 +1598,25 @@ static int
>> vaapi_device_create(AVHWDeviceContext *ctx, const char *device,
>> return AVERROR(EINVAL);
>> }
>>
>> +ent = av_dict_get(opts, "driver", NULL, 0);
>> +if (ent) {
>> +#if VA_CHECK_VERSION(0, 38, 0)
>> +VAStatus vas;
>> +vas = vaSetDriverName(display, ent->value);
>> +if (vas != VA_STATUS_SUCCESS) {
>> +av_log(ctx, AV_LOG_ERROR, "Failed to set driver name to "
>> + "%s: %d (%s).\n", ent->value, vas, vaErrorStr(vas));
>> +vaTerminate(display);
>> +return AVERROR_EXTERNAL;
>> +}
>> +#else
>> +av_log(ctx, AV_LOG_WARNING, "Driver name setting is not "
>> + "supported with this VAAPI version.\n");
>> +vaTerminate(display);
>> +return AVERROR(ENOSYS);
>
> Giving a warning message should be enough?
Yes, that's fair. Changed to not fail in that case.
On 07/05/2019 02:37, myp...@gmail.com wrote:
> On Mon, May 6, 2019 at 10:55 PM Mark Thompson wrote:
>>...
>
> LGTM, except for the need to update the document
Doc patch sent.
With that, this set applied.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc/ffmpeg: Document VAAPI device creation options
---
doc/ffmpeg.texi | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index cd35eb49c8..ccd490d1a7 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -950,8 +950,32 @@ device type:
@item vaapi
@var{device} is either an X11 display name or a DRM render node.
-If not specified, it will attempt to open the default X11 display
(@emph{$DISPLAY})
-and then the first DRM render node (@emph{/dev/dri/renderD128}).
+If not specified, it will attempt to open the first usable DRM render node
+(@emph{/dev/dri/renderD128}, @emph{/dev/dri/renderD129}, etc.). If no render
+node is found then it will try the default X11 display (@emph{$DISPLAY}).
+
+Some options are also supported to guide the selection:
+@table @option
+@item connection_type
+Explicitly specify the connection type to use - @samp{x11} or @samp{drm}.
+@item kernel_driver
+Only consider DRM render nodes using the named kernel driver.
+@item driver
+Select the VA driver to load after the connection is open. This does not
+affect the selection of the device itself.
+@end table
+
+Examples:
+@table @emph
+@item -init_hw_device vaapi:/dev/dri/renderD129
+Choose the device on the second DRM render node.
+@item -init_hw_device vaapi:,connection_type=drm,kernel_driver=amdgpu
+Choose a device on a DRM render node using the @emph{amdgpu} kernel driver,
+as found on most current AMD graphics devices.
+@item -init_hw_device vaapi:,kernel_driver=i915,driver=iHD
+Choose a device using the @emph{i915} kernel driver, and load the @emph{iHD}
+VA driver to use with it.
+@end table
@item vdpau
@var{device} is an X11 display name.
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/4] cbs_mpeg2: Fix parsing of picture and slice headers
1. The extra information in slice headers was parsed incorrectly:
In the first reading pass to derive the length of the extra information,
one should look at bits n, n + 9, n + 18, ... and check whether they
equal one (further extra information) or zero (end of extra information),
but instead bits n, n + 8, n + 16, ... were inspected. The second pass
of reading (where the length is already known and the bytes between the
length-determining bits are copied into a buffer) did not record what
was in bits n, n + 9, n + 18, ..., presuming they equal one. And during
writing, the bytes in the buffer are interleaved with set bits and
written. This means that if the detected length of the extra information
was greater than the real length, the output was corrupted. Fortunately
no sample is known that made use of this mechanism: The extra information
in slices is still marked as reserved in the specifications. cbs_mpeg2
is now ready in case this changes.
2. Furthermore, the buffer is now padded and slightly different, but
very similar code for reading resp. writing has been replaced by code
used for both. This was made possible by a new macro, the equivalent
to cbs_h2645's fixed().
3. These changes also made it possible to remove the extra_bit_slice
element from the MPEG2RawSliceHeader structure. Said element was always
zero except when the detected length of the extra information was less
than the real length.
4. The extra information in picture headers (which uses essentially the
same syntax as the extra information in slice headers) has simply been
forgotten. This meant that if this extra information was present, it was
discarded during reading; and unfortunately writing created invalid
bitstreams in this case (an extra_bit_picture - the last set bit of the
whole unit - indicated that there would be a further byte of data,
although the output didn't contain said data).
This has been fixed; both types of extra information are now parsed via
the same code and essentially passed through.
Signed-off-by: Andreas Rheinhardt
---
1. I squashed the two commits because just dropping in a function call
seems to be too little for a commit of its own.
2. The __VA_ARGS__ problem you mentioned is not a problem here and it is
nothing new:
a) In both the new and the old code the SUBSCRIPTS macro gets expanded
to "(0 > 0 ? ((int[0 + 1]){ 0, }) : NULL)" in case someone uses no
subscripts. So there is nothing new.
b) And more importantly, this is completely legal C (89 as well as any
later standard), as a trailing comma is allowed in initializers.
3. The 'a' in the macro stands for "advanced". I couldn't come up with a
better name: 's' (for string) would clash with subscripts.
4. Given that you merged the version without the range parameters for
the xsi macro (which James objected to), I have not added a xsia macro
just for the purpose of consistency (because there is no need for it).
libavcodec/cbs_mpeg2.c | 43 ---
libavcodec/cbs_mpeg2.h | 14 ++---
libavcodec/cbs_mpeg2_syntax_template.c | 72 ++
3 files changed, 71 insertions(+), 58 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index ede6e806e1..3aa003286e 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -48,17 +48,26 @@
xui(width, name, current->name, 0, MAX_UINT_BITS(width), subs,
__VA_ARGS__)
#define uirs(width, name, subs, ...) \
xui(width, name, current->name, 1, MAX_UINT_BITS(width), subs,
__VA_ARGS__)
+#define xui(width, name, var, range_min, range_max, subs, ...) \
+xuia(width, #name, var, range_min, range_max, subs, __VA_ARGS__)
#define sis(width, name, subs, ...) \
xsi(width, name, current->name, subs, __VA_ARGS__)
+#define marker_bit() \
+bit("marker_bit", 1)
+#define bit(string, value) do { \
+av_unused uint32_t bit = value; \
+xuia(1, string, bit, value, value, 0); \
+} while (0)
+
#define READ
#define READWRITE read
#define RWContext GetBitContext
-#define xui(width, name, var, range_min, range_max, subs, ...) do { \
+#define xuia(width, string, var, range_min, range_max, subs, ...) do { \
uint32_t value; \
-CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
+CHECK(ff_cbs_read_unsigned(ctx, rw, width, string, \
SUBSCRIPTS(subs, __VA_ARGS__), \
, range_min, range_max)); \
var = value; \
@@ -73,11 +82,6 @@
var = value; \
} while (0)
-#define marker_bit() do { \
-av_unused uint32_t one; \
-CHECK(ff_cbs_read_unsigned(ctx, rw, 1, "marker_bit", NULL, , 1,
1)); \
-} while (0)
-
#define nextbits(width, compare, var) \
(get_bits_left(rw) >= width && \
(var = show_bits(rw, width)) == (compare))
@@ -91,9 +95,8 @@
#undef READ
#undef READWRITE
#undef RWContext
-#undef xui
+#undef xuia
#undef xsi
-#undef marker_bit
#undef
[FFmpeg-devel] [PATCH 4/4] cbs_mpeg2: Remove zero byte stuffing
Remove superfluous trailing zeros from slices. Because MPEG-2 slices
can end with zero bits a safe number of trailing zero bits is always
kept.
More explicitly, 6 + max{f_code[i][1] - 1, i = 0,1, f_code[i][1] != 0xf}
is an upper bound for the number of possible trailing zeros that are
part of the slice. Here f_code[i][1] is the relevant value of the
picture coding extension the slice belongs to and the maximum of the
empty set is zero.
It is this number of trailing zero bits that is actually kept.
That this is really an upper bound can be seen as follows:
a) Every slice actually ends with a macroblock.
b) If the last macroblock of a slice ends with a block(i) structure
with pattern_code[i] != 0, then the slice ends with an "End of block"
VLC code (namely the "End of block" code of the last block with
pattern_code[i] != 0).
These codes are 10 and 0110, so that in this case there is exactly one
trailing zero bit.
c) Otherwise, all pattern_code[i] are zero. In this case,
if macroblock_pattern is set for the last macroblock of the slice, then
by the definition of pattern_code[i] in 6.3.17.4 cbp (derived
according to table B.9) must be zero and also the
coded_block_pattern_1/2 (if existing) must consist of zeros alone. The
value zero for cbp is coded by 1 so that the maximum number of
trailing zeros in this case is the length of coded_block_pattern_1/2 which
have a length of two resp. six bits. So six trailing zero bits at most.
d) Otherwise, if the slice actually ends with the marker bit of the
last macroblock, then there are certainly no trailing zero bits at
all.
e) Otherwise, if the slice ends with a motion_vectors(s) structure
(with s = 0 or 1 -- it doesn't matter which one), then it ends with a
motion_vector(r,s) (r, s = 0, 1 -- it doesn't matter) structure. This
structure ends with motion_code[r][s][1] (always existing) potentially
followed by motion_residual[r][s][1] and dmvector[1]. If dmvector[1]
exists, and contains a bit different from 0, there is at most one
trailing zero bit; if dmvector[1] consists of zeros alone, its length
is one according to B.11. motion_residual[r][s][1] (if it exists) has
a length of f_code[s][1] - 1 bits and can consist of zero bits alone.
Given that the value 0xf for f_code indicates that there is no motion
vector of the mentioned type, the length of motion_residual[r][s][1] is
bounded by max{f_code[i][1] - 1, i=1,2, f_code[i][1] != 0xf}. The
motion_code[r][s][1] can end with at most five zero bits (see B.10)
and always contains a bit set to one, so that in this case there are
at most 5 + max{f_code[i][1] - 1, i=1,2, f_code[i][1] != 0xf} + 1
zero trailing bits.
f) Otherwise, if the last macroblock of the slice ends with a
quantiser_scale_code, then there are at most four trailing zero bits,
because quantiser_scale_code has a length of five bits and must not
attain the value zero.
g) Otherwise, the last macroblock ends with the macroblock_modes
syntax structure. The potentially existing dct_type at the end might
be a zero bit; the frame/field_motion_type isn't present here, because
otherwise we would have a motion_vectors(i) (i = 0 or 1 or both) syntax
structure, so that e) (or b)-d)) would have applied.
spatial_temporal_weight_code might entirely consist of two zero bits.
The macroblock_type VLC code always contains a 1 bit and ends with two
zero bits at most (see B.2-B.8 for this), so we have maximally 2+2+1
trailing zero bits.
The fate test cbs-mpeg2-sony-ct3 had to be adapted because the input
file contains trailing zeros that were stripped away; the filesize is
reduced from 135 KB to 117 KB. Of course, decoding the smaller output
still produces the same frames.
Most of these savings happen in between slices rather than after the
last slice: The chomp bitstream filter can only reduce the filesize
by 50 bytes.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_mpeg2.c| 26 --
tests/ref/fate/cbs-mpeg2-sony-ct3 | 2 +-
2 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 3aa003286e..b56fecd6fa 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -170,7 +170,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
uint8_t *unit_data;
uint32_t start_code = -1, next_start_code = -1;
size_t unit_size;
-int err, i, unit_type;
+int err, i, unit_type, max_trailing_bits = 14;
start = avpriv_find_start_code(frag->data, frag->data + frag->data_size,
_code);
@@ -187,10 +187,32 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
unit_size = end - (start - 1);
} else {
// Unit runs from start to the beginning of the start code
-// pointed to by end (including any padding zeroes).
+// pointed to by end (preliminarily including any padding zeroes).
unit_size = (end - 4) - (start -
[FFmpeg-devel] [PATCH 1/4] mpeg2_metadata, cbs_mpeg2: Fix handling of colour_description
If a sequence display extension is read with colour_description equal to
zero, but a user wants to add one or more of the colour_description
elements, then the colour_description elements the user did not explicitly
request to be set are set to zero and not to the value equal to
unknown/unspecified (namely 2). A value of zero is not only inappropriate,
but explicitly forbidden. This is fixed by inferring the right default
values during the reading process if the elements are absent; moreover,
changing any of the colour_description elements to zero is now no longer
possible.
Furthermore, if a sequence display extension has to be added, the
earlier code set some fields to their default value twice. This has been
changed, too.
Signed-off-by: Andreas Rheinhardt
---
I implemented your solution, because it is easy to add the check I just
removed back in should it be needed some day because of the
AVCodecParameter stuff.
libavcodec/cbs_mpeg2.c | 15 +
libavcodec/cbs_mpeg2_syntax_template.c | 4
libavcodec/mpeg2_metadata_bsf.c| 30 +++---
3 files changed, 31 insertions(+), 18 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index ce22e32c15..5e971f3a54 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -82,6 +82,10 @@
(get_bits_left(rw) >= width && \
(var = show_bits(rw, width)) == (compare))
+#define infer(name, value) do { \
+current->name = value; \
+} while (0)
+
#include "cbs_mpeg2_syntax_template.c"
#undef READ
@@ -91,6 +95,7 @@
#undef xsi
#undef marker_bit
#undef nextbits
+#undef infer
#define WRITE
@@ -116,6 +121,15 @@
#define nextbits(width, compare, var) (var)
+#define infer(name, value) do { \
+if (current->name != (value)) { \
+av_log(ctx->log_ctx, AV_LOG_WARNING, "Warning: " \
+ "%s does not match inferred value: " \
+ "%"PRId64", but should be %"PRId64".\n", \
+ #name, (int64_t)current->name, (int64_t)(value)); \
+} \
+} while (0)
+
#include "cbs_mpeg2_syntax_template.c"
#undef READ
@@ -125,6 +139,7 @@
#undef xsi
#undef marker_bit
#undef nextbits
+#undef infer
static void cbs_mpeg2_free_user_data(void *unit, uint8_t *content)
diff --git a/libavcodec/cbs_mpeg2_syntax_template.c
b/libavcodec/cbs_mpeg2_syntax_template.c
index e0cf716874..d9ef480f39 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -144,6 +144,10 @@ static int
FUNC(sequence_display_extension)(CodedBitstreamContext *ctx, RWContex
uir(8, transfer_characteristics);
uir(8, matrix_coefficients);
#endif
+} else {
+infer(colour_primaries, 2);
+infer(transfer_characteristics, 2);
+infer(matrix_coefficients, 2);
}
ui(14, display_horizontal_size);
diff --git a/libavcodec/mpeg2_metadata_bsf.c b/libavcodec/mpeg2_metadata_bsf.c
index ba3a74afda..57eded0808 100644
--- a/libavcodec/mpeg2_metadata_bsf.c
+++ b/libavcodec/mpeg2_metadata_bsf.c
@@ -111,9 +111,9 @@ static int mpeg2_metadata_update_fragment(AVBSFContext *bsf,
}
if (ctx->video_format >= 0 ||
-ctx->colour_primaries >= 0 ||
-ctx->transfer_characteristics >= 0 ||
-ctx->matrix_coefficients >= 0) {
+ctx->colour_primaries > 0 ||
+ctx->transfer_characteristics > 0 ||
+ctx->matrix_coefficients > 0) {
if (!sde) {
add_sde = 1;
ctx->sequence_display_extension.extension_start_code =
@@ -140,25 +140,19 @@ static int mpeg2_metadata_update_fragment(AVBSFContext
*bsf,
if (ctx->video_format >= 0)
sde->video_format = ctx->video_format;
-if (ctx->colour_primaries >= 0 ||
-ctx->transfer_characteristics >= 0 ||
-ctx->matrix_coefficients >= 0) {
+if (ctx->colour_primaries > 0 ||
+ctx->transfer_characteristics > 0 ||
+ctx->matrix_coefficients > 0) {
sde->colour_description = 1;
-if (ctx->colour_primaries >= 0)
+if (ctx->colour_primaries > 0)
sde->colour_primaries = ctx->colour_primaries;
-else if (add_sde)
-sde->colour_primaries = 2;
-if (ctx->transfer_characteristics >= 0)
+if (ctx->transfer_characteristics > 0)
sde->transfer_characteristics = ctx->transfer_characteristics;
-else if (add_sde)
-sde->transfer_characteristics = 2;
-if (ctx->matrix_coefficients >= 0)
+if (ctx->matrix_coefficients > 0)
sde->matrix_coefficients = ctx->matrix_coefficients;
-else if (add_sde)
-sde->matrix_coefficients = 2;
}
}
@@ -283,13 +277,13 @@ static const AVOption
[FFmpeg-devel] [PATCH 2/4] cbs: Remove useless initializations
Up until now, a temporary variable was used and initialized every time a
value was read in CBS; if reading turned out to be successfull, this
value was overwritten (without having ever been looked at) with the
value read if reading was successfull; on failure the variable wasn't
touched either. Therefore these initializations can be and have been
removed.
Signed-off-by: Andreas Rheinhardt
---
And? What did the ancient compilers say?
libavcodec/cbs_av1.c | 14 +++---
libavcodec/cbs_h2645.c | 8
libavcodec/cbs_jpeg.c | 2 +-
libavcodec/cbs_mpeg2.c | 2 +-
libavcodec/cbs_vp9.c | 8
5 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index eb2d03ef43..e31fc0c411 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -574,7 +574,7 @@ static size_t cbs_av1_get_payload_bytes_left(GetBitContext
*gbc)
#define RWContext GetBitContext
#define xf(width, name, var, range_min, range_max, subs, ...) do { \
-uint32_t value = range_min; \
+uint32_t value; \
CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
, range_min, range_max)); \
@@ -582,7 +582,7 @@ static size_t cbs_av1_get_payload_bytes_left(GetBitContext
*gbc)
} while (0)
#define xsu(width, name, var, subs, ...) do { \
-int32_t value = 0; \
+int32_t value; \
CHECK(ff_cbs_read_signed(ctx, rw, width, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), , \
MIN_INT_BITS(width), \
@@ -591,27 +591,27 @@ static size_t
cbs_av1_get_payload_bytes_left(GetBitContext *gbc)
} while (0)
#define uvlc(name, range_min, range_max) do { \
-uint32_t value = range_min; \
+uint32_t value; \
CHECK(cbs_av1_read_uvlc(ctx, rw, #name, \
, range_min, range_max)); \
current->name = value; \
} while (0)
#define ns(max_value, name, subs, ...) do { \
-uint32_t value = 0; \
+uint32_t value; \
CHECK(cbs_av1_read_ns(ctx, rw, max_value, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), )); \
current->name = value; \
} while (0)
#define increment(name, min, max) do { \
-uint32_t value = 0; \
+uint32_t value; \
CHECK(cbs_av1_read_increment(ctx, rw, min, max, #name, )); \
current->name = value; \
} while (0)
#define subexp(name, max, subs, ...) do { \
-uint32_t value = 0; \
+uint32_t value; \
CHECK(cbs_av1_read_subexp(ctx, rw, max, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), )); \
current->name = value; \
@@ -629,7 +629,7 @@ static size_t cbs_av1_get_payload_bytes_left(GetBitContext
*gbc)
} while (0)
#define leb128(name) do { \
-uint64_t value = 0; \
+uint64_t value; \
CHECK(cbs_av1_read_leb128(ctx, rw, #name, )); \
current->name = value; \
} while (0)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 319202fc48..8655d8015e 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -290,28 +290,28 @@ static int cbs_write_se_golomb(CodedBitstreamContext
*ctx, PutBitContext *pbc,
#define RWContext GetBitContext
#define xu(width, name, var, range_min, range_max, subs, ...) do { \
-uint32_t value = range_min; \
+uint32_t value; \
CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
, range_min, range_max)); \
var = value; \
} while (0)
#define xue(name, var, range_min, range_max, subs, ...) do { \
-uint32_t value = range_min; \
+uint32_t value; \
CHECK(cbs_read_ue_golomb(ctx, rw, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
, range_min, range_max)); \
var = value; \
} while (0)
#define xi(width, name, var, range_min, range_max, subs, ...) do { \
-int32_t value = range_min; \
+int32_t value; \
CHECK(ff_cbs_read_signed(ctx, rw, width, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
, range_min, range_max)); \
var = value; \
} while (0)
#define xse(name, var, range_min, range_max, subs, ...) do { \
-int32_t value = range_min; \
+int32_t value; \
CHECK(cbs_read_se_golomb(ctx, rw, #name, \
SUBSCRIPTS(subs, __VA_ARGS__), \
, range_min, range_max)); \
diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
index 5a72f0e2e7..2830f99a31 100644
--- a/libavcodec/cbs_jpeg.c
+++ b/libavcodec/cbs_jpeg.c
@@ -45,7 +45,7 @@
#define
Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort decoder/encoder/filter/... names in alphabet order
> I intent to push the awk version. I will wait at least until > Thursday, so people can further test, comment, or object. No further comments here. Thanks! Avi ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V5 1/2] configure: sort decoder/encoder/filter/... names in alphabet order
Hi all, hi Avi! Sorry for the late reply. On 2019-05-07 12:22 +, avih wrote: > > patch1 (awk) configure: print_in_columns: replace pr with awk version: > > http://ffmpeg.org/pipermail/ffmpeg-devel/2019-May/243380.html > > patch2 (shell) configure: sort decoder/encoder/filter/... names in alphabet > > order (v5 as posted in this thread) > > > > - Why do you prefer patch1 over patch2? > > In general, I agree with your reasoning, but not entirely sure about the > conclusion and its implications. > > Few exceptions first: > > > > 1. Statistics > > * patch1: 1 file changed, 16 insertions(+), 2 deletions(-) > > * patch2: 1 file changed, 24 insertions(+), 2 deletions(-) > > As you said later, and I agree, it's a weak argument, as both versions > are the same code and complexity, but differ mostly in style and language > syntax. > > > 2. patch2 uses lots of variables (which is good in itself), but those > > should be local and we cannot express that portably in shell. > > In turn we have raised potential for clashes now or in the future. > > This is incorrect. A subshell provides identical isolation as an external > process, it's fully portable, it can be used here, and it's not slower than > an external process, e.g. `print_in_columns() ( ... )`. No disagreement regarding those 2 points. Though with all other things being equal, it's nice to have patches ready and tested as they are. > > 4. Depending on the input (stdin) unexpected things can happen in the > > "eval" and "set" lines. One example is given in the comment. > > "Unexpected" is a bit general. Specifically, the "eval" line does not > execute arbitrary inputs, and neither does the "set" line. Regarding eval it seems I misremembered something or it was in previous iteration. I looked at it again and I can't see how the latest version can do something unexpected trough the eval. > The only potential surprise is globbing, as documented, and the technique > of expanding variables unquoted - like here, is used throughout configure. > > Look no further than 100% of the very places which pipe the input stream > into print_in_columns, and multiple times earlier than that. > > It's not great of course, but it's not worse than elsewhere, and it's at > least documented. Some day maybe someone would improve it. > > > I generally agree with rest of your comments/arguments, including: > > > 1. Statistics ... (patch2 is more verbose). > > 3. patch2 uses eval combined with non-trivial quoting, which is hard > > to read and hard to grasp quickly. It's not wrong, but it's not as > > easy and straight forward as in patch1. > > 5. patch2 to uses shell for the parts easily expressed in shell and > > uses awk for the parts that are non-trivial in shell. > > 6. The awk implementation should be easier to read and understand for > > the majority of readers/developers. > > which basically say that shell is hard, and, pardon the pun, awkward. :) > And also I agree with: > > > Shell though is not really suited for implementing all kinds of algorithms. > > OTOH shell is an excellent choice for starting processes that communicate > > via stdin/stdout/stderr and plugging them together. > > and with > > > Shell is best when coordinating the execution of other programs. > > And similar assertions, however, let's keep the following facts in mind: > > - We both agree that we should keep to shell except where an external tool > provides some meaningful value over shell code. > > - An external tool only helps by being more suitable for the task than > shell code (readability, portability, correctness, performance, etc), > but it doesn't help with isolation more than a subshell would. > > - Shell is capable in a portable way, including for some tasks which can > be considered "programming". > > - configure is currently written in shell, including some non trivial > functionality, and doesn't use external script engines for "scriptlets". > > - Being a shell script, it already requires competence and reasonable > understanding of shell, including quoting, expansions, etc. > > - Maintaining code in more than one scripting system does carry a cost. > > - Yes, shell is a lousy programming language. > > > I really don't care if this specific patch ends up as shell or awk. What > I do care about is being consistent, and understanding the implications. > > IMHO, because I'm not convinced that the awk version provides a meaningful > additional value other than not being shell, if we use the awk version then > it sets a precedence of using awk (or maybe also other languages) for small > scripts even if they're basically the same complexity and code as they > would be in shell. > > It's not necessarily a bad precedence (even if I wouldn't do that myself), > because I do agree that not being shell code does have value, but I think > it's important to acknowledge that it does set such precedence. > > If there was already such practice of using awk
[FFmpeg-devel] [PATCH] avcodec/fmvc: Check if header fields are available before allocating the image
Fixes: Timeout (15sec -> 0.5sec) Fixes: 14846/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FMVC_fuzzer-5068322120400896 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/fmvc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/fmvc.c b/libavcodec/fmvc.c index 5778d7b53f..5bee96a18d 100644 --- a/libavcodec/fmvc.c +++ b/libavcodec/fmvc.c @@ -402,6 +402,9 @@ static int decode_frame(AVCodecContext *avctx, void *data, AVFrame *frame = data; int ret, y, x; +if (avpkt->size < 8) +return AVERROR_INVALIDDATA; + if ((ret = ff_get_buffer(avctx, frame, 0)) < 0) return ret; -- 2.21.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder
On 02/06/2019 21:19, Derek Buitenhuis wrote: > This has nothing to do with API changes, it's a Rust toolchain (build > system, specifically) thing. These changes don't change API/ABI. Also to add: We will probably be cutting a 'real' rav1e release soon (0.1.0), I think. That could also be a place to settle on for merging the patch. I'll bring it up in the weekly Xiph/Daala/rav1e meeting on Tuesday. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder
On 02/06/2019 19:27, Carl Eugen Hoyos wrote: > Since a lot of unexpected changes can happen after months, > this sounds to me like a strong reason to wait. This has nothing to do with API changes, it's a Rust toolchain (build system, specifically) thing. These changes don't change API/ABI. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder
On 02/06/2019 19:45, Moritz Barsnick wrote: > https://github.com/lu-zero/crav1e says: > > Status > The API is far from stable Yeah, that's not super true any more, and I'll remove it. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder
On 6/2/19, Carl Eugen Hoyos wrote: > Am So., 2. Juni 2019 um 19:54 Uhr schrieb Derek Buitenhuis > : >> >> On 31/05/2019 23:08, Carl Eugen Hoyos wrote: >> > So is your patch meant to wait until this merge is done? >> > I would suggest so... >> >> Soon has a (TM) beside it for a reason (there needs to be some >> work done on Rust itself first, I think.) I would expect it to >> take at least 1-2 months. > > Since a lot of unexpected changes can happen after months, > this sounds to me like a strong reason to wait. > Why, could you elaborate? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder
On Sun, Jun 02, 2019 at 18:46:17 +0100, Derek Buitenhuis wrote: > take at least 1-2 months. The API itself won't change. https://github.com/lu-zero/crav1e says: Status The API is far from stable Just sayin', Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder
Am So., 2. Juni 2019 um 19:54 Uhr schrieb Derek Buitenhuis : > > On 31/05/2019 23:08, Carl Eugen Hoyos wrote: > > So is your patch meant to wait until this merge is done? > > I would suggest so... > > Soon has a (TM) beside it for a reason (there needs to be some > work done on Rust itself first, I think.) I would expect it to > take at least 1-2 months. Since a lot of unexpected changes can happen after months, this sounds to me like a strong reason to wait. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Build ffmpeg with clang lto
Hi Carl This is the error message I get. It seems like libavdevice.a is llvm bitcode. Thanks -Adrian ./configure --cc=clang --enable-lto && make -j28 AR libavcodec/libavcodec.a LD ffmpeg_g LD ffprobe_g /usr/bin/ld: skipping incompatible libavdevice/libavdevice.a when searching for -lavdevice /usr/bin/ld: cannot find -lavdevice /usr/bin/ld: skipping incompatible libavfilter/libavfilter.a when searching for -lavfilter /usr/bin/ld: cannot find -lavfilter /usr/bin/ld: skipping incompatible libavformat/libavformat.a when searching for /usr/bin/ld-lavformat : skipping incompatible libavdevice/libavdevice.a when searching for -lavdevice /usr/bin/ld: cannot find -lavdevice /usr/bin/ld: skipping incompatible libavfilter/libavfilter.a when searching for -lavfilter /usr/bin/ld: cannot find -lavfilter /usr/bin/ld: skipping incompatible libavformat/libavformat.a when searching for -lavformat /usr/bin/ld: skipping incompatible libavcodec/libavcodec.a when searching for -lavcodec /usr/bin/ld: skipping incompatible libavcodec/libavcodec.a when searching for -lavcodec /usr/bin/ld: skipping incompatible libswresample/libswresample.a when searching for -lswresample /usr/bin/ld: skipping incompatible libswscale/libswscale.a when searching for -lswscale /usr/bin/ld: skipping incompatible libswresample/libswresample.a when searching for -lswresample /usr/bin/ld: skipping incompatible libavutil/libavutil.a when searching for -lavutil /usr/bin/ld: skipping incompatible libswscale/libswscale.a when searching for -lswscale /usr/bin/ld: skipping incompatible libavutil/libavutil.a when searching for -lavutil clang: *error: *linker command failed with exit code 1 (use -v to see invocation) clang: *error: *linker command failed with exit code 1 (use -v to see invocation) Makefile:111: recipe for target 'ffprobe_g' failed On Sat, 1 Jun 2019 at 09:55, Carl Eugen Hoyos wrote: > Am Sa., 1. Juni 2019 um 17:45 Uhr schrieb Adrian Tong > : > > > Anyone has experience compiling ffmpeg with clang LTO before ? I tried > > ./configure --cc=clang --cxx=clang++ --enable-lto and it did not work. > > cxx should never be needed. > > "did not work" is not a useful problem description... > (clang is definitely supported) > > Carl Eugen > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: Add librav1e encoder
On 31/05/2019 23:08, Carl Eugen Hoyos wrote: > So is your patch meant to wait until this merge is done? > I would suggest so... Soon has a (TM) beside it for a reason (there needs to be some work done on Rust itself first, I think.) I would expect it to take at least 1-2 months. The API itself won't change. While I prefer to merge it sooner rather than later to aid in peoples' use of rav1e, I'm open to others opinions here. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 10/11] cbs_mpeg2: Fix parsing of picture headers
On 29/05/2019 05:54, Andreas Rheinhardt wrote:
> Mark Thompson:
>> On 22/05/2019 02:04, Andreas Rheinhardt wrote:
>>> MPEG-2 picture and slice headers can contain optional extra information;
>>> both use the same syntax for their extra information. And cbs_mpeg2's
>>> implementations of both were buggy until recently; the one for the
>>> picture headers still is and this is fixed in this commit.
>>>
>>> The extra information in picture headers has simply been forgotten.
>>> This meant that if this extra information was present, it was discarded
>>> during reading; and unfortunately writing created invalid bitstreams in
>>> this case (an extra_bit_picture - the last set bit of the whole unit -
>>> indicated that there would be a further byte of data, although the output
>>> didn't contain said data).
>>>
>>> This has been fixed; both types of extra information are now
>>> parsed via the same code and essentially passed through.
>>>
>>> Signed-off-by: Andreas Rheinhardt
>>> ---
>>> libavcodec/cbs_mpeg2.c | 31 +++-
>>> libavcodec/cbs_mpeg2.h | 12 +++--
>>> libavcodec/cbs_mpeg2_syntax_template.c | 66 +++---
>>> 3 files changed, 66 insertions(+), 43 deletions(-)
>>>
>>> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
>>> index 97425aa706..2354f665cd 100644
>>> --- a/libavcodec/cbs_mpeg2.c
>>> +++ b/libavcodec/cbs_mpeg2.c
>>> @@ -41,18 +41,18 @@
>>> #define SUBSCRIPTS(subs, ...) (subs > 0 ? ((int[subs + 1]){ subs,
>>> __VA_ARGS__ }) : NULL)
>>>
>>> #define ui(width, name) \
>>> -xui(width, name, current->name, 0, MAX_UINT_BITS(width), 0)
>>> +xui(width, #name, current->name, 0, MAX_UINT_BITS(width), 0)
>>> #define uir(width, name) \
>>> -xui(width, name, current->name, 1, MAX_UINT_BITS(width), 0)
>>> +xui(width, #name, current->name, 1, MAX_UINT_BITS(width), 0)
>>> #define uis(width, name, subs, ...) \
>>> -xui(width, name, current->name, 0, MAX_UINT_BITS(width), subs,
>>> __VA_ARGS__)
>>> +xui(width, #name, current->name, 0, MAX_UINT_BITS(width), subs,
>>> __VA_ARGS__)
>>> #define uirs(width, name, subs, ...) \
>>> -xui(width, name, current->name, 1, MAX_UINT_BITS(width), subs,
>>> __VA_ARGS__)
>>> +xui(width, #name, current->name, 1, MAX_UINT_BITS(width), subs,
>>> __VA_ARGS__)
>>> #define sis(width, name, subs, ...) \
>>> -xsi(width, name, current->name, subs, __VA_ARGS__)
>>> +xsi(width, #name, current->name, subs, __VA_ARGS__)
>>>
>>> #define marker_bit() \
>>> -bit(marker_bit, 1)
>>> +bit("marker_bit", 1)
>>> #define bit(name, value) do { \
>>> av_unused uint32_t bit = value; \
>>> xui(1, name, bit, value, value, 0); \
>>> @@ -65,7 +65,7 @@
>>>
>>> #define xui(width, name, var, range_min, range_max, subs, ...) do { \
>>> uint32_t value; \
>>> -CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, \
>>> +CHECK(ff_cbs_read_unsigned(ctx, rw, width, name, \
>>> SUBSCRIPTS(subs, __VA_ARGS__), \
>>> , range_min, range_max)); \
>>> var = value; \
>>> @@ -73,7 +73,7 @@
>>>
>>> #define xsi(width, name, var, subs, ...) do { \
>>> int32_t value; \
>>> -CHECK(ff_cbs_read_signed(ctx, rw, width, #name, \
>>> +CHECK(ff_cbs_read_signed(ctx, rw, width, name, \
>>> SUBSCRIPTS(subs, __VA_ARGS__), , \
>>> MIN_INT_BITS(width), \
>>> MAX_INT_BITS(width))); \
>>> @@ -104,13 +104,13 @@
>>> #define RWContext PutBitContext
>>>
>>> #define xui(width, name, var, range_min, range_max, subs, ...) do { \
>>> -CHECK(ff_cbs_write_unsigned(ctx, rw, width, #name, \
>>> +CHECK(ff_cbs_write_unsigned(ctx, rw, width, name, \
>>> SUBSCRIPTS(subs, __VA_ARGS__), \
>>> var, range_min, range_max)); \
>>> } while (0)
>>>
>>> #define xsi(width, name, var, subs, ...) do { \
>>> -CHECK(ff_cbs_write_signed(ctx, rw, width, #name, \
>>> +CHECK(ff_cbs_write_signed(ctx, rw, width, name, \
>>>SUBSCRIPTS(subs, __VA_ARGS__), var, \
>>>MIN_INT_BITS(width), \
>>>MAX_INT_BITS(width))); \
>>
>> Calling the inner functions directly in extra_information feels like it
>> would be cleaner? This part makes the intermediate macros for mpeg2 act in
>> a way which is subtly different to all the other codecs.
>>
> Agreed. The rationale I did it the way I did is of course that there
> turned out to be exactly one call to xui in the mpeg2-syntax-template.
> Or maybe one should add a new macro that is the macro actually calling
> the inner functions directly and gets used by xui? If we hadn't used
> the 's' for
Re: [FFmpeg-devel] [PATCH 03/11] mpeg2_metadata, cbs_mpeg2: Fix handling of colour_description
On 29/05/2019 05:12, Andreas Rheinhardt wrote:
> Mark Thompson:
>> On 22/05/2019 02:04, Andreas Rheinhardt wrote:
>>> If a sequence display extension is read with colour_description equal to
>>> zero, but a user wants to add one or more of the colour_description
>>> elements, then the colour_description elements the user did not explicitly
>>> request to be set are set to zero and not to the value equal to
>>> unknown/unspecified (namely 2). A value of zero is not only inappropriate,
>>> but explicitly forbidden. This is fixed by inferring the right default
>>> values during the reading process if the elements are absent; moreover,
>>> changing any of the colour_description elements to zero is now no longer
>>> permitted.
>>>
>>> Furthermore, if a sequence display extension has to be added, the
>>> earlier code set some fields to their default value twice. This has been
>>> changed, too.
>>>
>>> Signed-off-by: Andreas Rheinhardt
>>> ---
>>> libavcodec/cbs_mpeg2.c | 15 +++
>>> libavcodec/cbs_mpeg2_syntax_template.c | 4
>>> libavcodec/mpeg2_metadata_bsf.c| 18 --
>>> 3 files changed, 31 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
>>> index 1d319e0947..437eac88a3 100644
>>> --- a/libavcodec/cbs_mpeg2.c
>>> +++ b/libavcodec/cbs_mpeg2.c
>>> @@ -71,6 +71,10 @@
>>> (get_bits_left(rw) >= width && \
>>> (var = show_bits(rw, width)) == (compare))
>>>
>>> +#define infer(name, value) do { \
>>> +current->name = value; \
>>> +} while (0)
>>> +
>>> #include "cbs_mpeg2_syntax_template.c"
>>>
>>> #undef READ
>>> @@ -79,6 +83,7 @@
>>> #undef xui
>>> #undef marker_bit
>>> #undef nextbits
>>> +#undef infer
>>>
>>>
>>> #define WRITE
>>> @@ -97,6 +102,15 @@
>>>
>>> #define nextbits(width, compare, var) (var)
>>>
>>> +#define infer(name, value) do { \
>>> +if (current->name != (value)) { \
>>> +av_log(ctx->log_ctx, AV_LOG_WARNING, "Warning: " \
>>> + "%s does not match inferred value: " \
>>> + "%"PRId64", but should be %"PRId64".\n", \
>>> + #name, (int64_t)current->name, (int64_t)(value)); \
>>> +} \
>>> +} while (0)
>>> +
>>> #include "cbs_mpeg2_syntax_template.c"
>>>
>>> #undef READ
>>> @@ -105,6 +119,7 @@
>>> #undef xui
>>> #undef marker_bit
>>> #undef nextbits
>>> +#undef infer
>>>
>>>
>>> static void cbs_mpeg2_free_user_data(void *unit, uint8_t *content)
>>> diff --git a/libavcodec/cbs_mpeg2_syntax_template.c
>>> b/libavcodec/cbs_mpeg2_syntax_template.c
>>> index b9d53682fe..87db0ad039 100644
>>> --- a/libavcodec/cbs_mpeg2_syntax_template.c
>>> +++ b/libavcodec/cbs_mpeg2_syntax_template.c
>>> @@ -144,6 +144,10 @@ static int
>>> FUNC(sequence_display_extension)(CodedBitstreamContext *ctx, RWContex
>>> uir(8, transfer_characteristics);
>>> uir(8, matrix_coefficients);
>>> #endif
>>> +} else {
>>> +infer(colour_primaries, 2);
>>> +infer(transfer_characteristics, 2);
>>> +infer(matrix_coefficients, 2);
>>> }
>>>
>>> ui(14, display_horizontal_size);
>>> diff --git a/libavcodec/mpeg2_metadata_bsf.c
>>> b/libavcodec/mpeg2_metadata_bsf.c
>>> index ba3a74afda..5aed41a008 100644
>>> --- a/libavcodec/mpeg2_metadata_bsf.c
>>> +++ b/libavcodec/mpeg2_metadata_bsf.c
>>> @@ -147,18 +147,12 @@ static int
>>> mpeg2_metadata_update_fragment(AVBSFContext *bsf,
>>>
>>> if (ctx->colour_primaries >= 0)
>>> sde->colour_primaries = ctx->colour_primaries;
>>> -else if (add_sde)
>>> -sde->colour_primaries = 2;
>>>
>>> if (ctx->transfer_characteristics >= 0)
>>> sde->transfer_characteristics =
>>> ctx->transfer_characteristics;
>>> -else if (add_sde)
>>> -sde->transfer_characteristics = 2;
>>>
>>> if (ctx->matrix_coefficients >= 0)
>>> sde->matrix_coefficients = ctx->matrix_coefficients;
>>> -else if (add_sde)
>>> -sde->matrix_coefficients = 2;
>>> }
>>> }
>>>
>>> @@ -229,6 +223,18 @@ static int mpeg2_metadata_init(AVBSFContext *bsf)
>>> CodedBitstreamFragment *frag = >fragment;
>>> int err;
>>>
>>> +#define VALIDITY_CHECK(name) do { \
>>> +if (!ctx->name) { \
>>> +av_log(bsf, AV_LOG_ERROR, "The value 0 for %s is " \
>>> + "forbidden.\n", #name); \
>>> +return AVERROR(EINVAL); \
>>> +} \
>>> +} while (0)
>>> +VALIDITY_CHECK(colour_primaries);
>>> +VALIDITY_CHECK(transfer_characteristics);
>>> +VALIDITY_CHECK(matrix_coefficients);
>>> +#undef VALIDITY_CHECK
>>
>> Perhaps we could use the normal option checking to enforce this? Suppose we
>> change the range from [-1, 255] to [0, 255] and make the do-nothing default
>>
Re: [FFmpeg-devel] [PATCH v4 1/5] lavc/h265_profile_level: Fix DPB size calculation
On 06/05/2019 22:02, Mark Thompson wrote: > The maxDpbPicBuf value which is used in the DPB size calculation depends > on the profile (it's usually 6, but 7 for screen-extended profiles). > --- > libavcodec/h265_profile_level.c | 86 - > libavcodec/h265_profile_level.h | 1 + > 2 files changed, 44 insertions(+), 43 deletions(-) Ping for set. - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 1/7] vf_crop: Add support for cropping hardware frames
On 15/04/2019 04:35, Song, Ruiling wrote: >> -Original Message- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of >> Mark Thompson >> Sent: Wednesday, April 10, 2019 6:07 AM >> To: ffmpeg-devel@ffmpeg.org >> Subject: [FFmpeg-devel] [PATCH v4 1/7] vf_crop: Add support for cropping >> hardware frames >> >> Set the cropping fields in the AVFrame. > The patchset looks fine to me. But I am not quite sure if others are happy > with this crop patch. > If nobody against. I think you can go pushing the patchset when you make sure > it will not trigger build failures as reported by Michael. > (one unnecessary empty line below, please remove it) All noted changes done, and tested with libva 1.3. Applied. Thanks, - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/cbs_h264: add support for Alternative Transfer Characteristics SEI message
On 26/05/2019 19:40, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/cbs_h264.h | 6 ++
> libavcodec/cbs_h2645.c| 1 +
> libavcodec/cbs_h264_syntax_template.c | 17 +
> 3 files changed, 24 insertions(+)
>
> diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
> index cc46eeb3b0..a31be298ba 100644
> --- a/libavcodec/cbs_h264.h
> +++ b/libavcodec/cbs_h264.h
> @@ -314,6 +314,10 @@ typedef struct H264RawSEIMasteringDisplayColourVolume {
> uint32_t min_display_mastering_luminance;
> } H264RawSEIMasteringDisplayColourVolume;
>
> +typedef struct H264RawSEIAlternativeTransferCharacteristics {
> +uint8_t preferred_transfer_characteristics;
> +} H264RawSEIAlternativeTransferCharacteristics;
> +
> typedef struct H264RawSEIPayload {
> uint32_t payload_type;
> uint32_t payload_size;
> @@ -327,6 +331,8 @@ typedef struct H264RawSEIPayload {
> H264RawSEIRecoveryPoint recovery_point;
> H264RawSEIDisplayOrientation display_orientation;
> H264RawSEIMasteringDisplayColourVolume
> mastering_display_colour_volume;
> +H264RawSEIAlternativeTransferCharacteristics
> +alternative_transfer_characteristics;
> struct {
> uint8_t *data;
> size_t data_length;
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 319202fc48..0456937710 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -458,6 +458,7 @@ static void cbs_h264_free_sei_payload(H264RawSEIPayload
> *payload)
> case H264_SEI_TYPE_RECOVERY_POINT:
> case H264_SEI_TYPE_DISPLAY_ORIENTATION:
> case H264_SEI_TYPE_MASTERING_DISPLAY_COLOUR_VOLUME:
> +case H264_SEI_TYPE_ALTERNATIVE_TRANSFER:
> break;
> case H264_SEI_TYPE_USER_DATA_REGISTERED:
> av_buffer_unref(>payload.user_data_registered.data_ref);
> diff --git a/libavcodec/cbs_h264_syntax_template.c
> b/libavcodec/cbs_h264_syntax_template.c
> index 95fc6d7194..cdacd79fc4 100644
> --- a/libavcodec/cbs_h264_syntax_template.c
> +++ b/libavcodec/cbs_h264_syntax_template.c
> @@ -815,6 +815,19 @@ static int
> FUNC(sei_mastering_display_colour_volume)(CodedBitstreamContext *ctx,
> return 0;
> }
>
> +static int
> FUNC(sei_alternative_transfer_characteristics)(CodedBitstreamContext *ctx,
> + RWContext *rw,
> +
> H264RawSEIAlternativeTransferCharacteristics *current)
> +{
> +int err;
> +
> +HEADER("Alternative Transfer Characteristics");
> +
> +ub(8, preferred_transfer_characteristics);
> +
> +return 0;
> +}
> +
> static int FUNC(sei_payload)(CodedBitstreamContext *ctx, RWContext *rw,
> H264RawSEIPayload *current)
> {
> @@ -866,6 +879,10 @@ static int FUNC(sei_payload)(CodedBitstreamContext *ctx,
> RWContext *rw,
> CHECK(FUNC(sei_mastering_display_colour_volume)
>(ctx, rw, >payload.mastering_display_colour_volume));
> break;
> +case H264_SEI_TYPE_ALTERNATIVE_TRANSFER:
> +CHECK(FUNC(sei_alternative_transfer_characteristics)
> + (ctx, rw,
> >payload.alternative_transfer_characteristics));
> +break;
> default:
> {
> #ifdef READ
>
LGTM.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avformat/hlsenc: add EXT-X-I-FRAMES-ONLY tag support
Signed-off-by: Steven Liu
---
doc/muxers.texi | 4
libavformat/dashenc.c | 4 ++--
libavformat/hlsenc.c | 27 ++-
libavformat/hlsplaylist.c | 11 ---
libavformat/hlsplaylist.h | 5 +++--
5 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c73719c421..50147c4d20 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -852,6 +852,10 @@ including the file containing the AES encryption key.
Add the @code{#EXT-X-INDEPENDENT-SEGMENTS} to playlists that has video segments
and when all the segments of that playlist are guaranteed to start with a Key
frame.
+@item iframes_only
+Add the @code{#EXT-X-I-FRAMES-ONLY} to playlists that has video segments
+and can play only I-frames in the @code{#EXT-X-BYTERANGE} mode.
+
@item split_by_time
Allow segments to start on frames other than keyframes. This improves
behavior on some players when the time between keyframes is inconsistent,
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 94b198ceb8..3fd7e78166 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -471,7 +471,7 @@ static void write_hls_media_playlist(OutputStream *os,
AVFormatContext *s,
}
ff_hls_write_playlist_header(c->m3u8_out, 6, -1, target_duration,
- start_number, PLAYLIST_TYPE_NONE);
+ start_number, PLAYLIST_TYPE_NONE, 0);
ff_hls_write_init_file(c->m3u8_out, os->initfile, c->single_file,
os->init_range_length, os->init_start_pos);
@@ -491,7 +491,7 @@ static void write_hls_media_playlist(OutputStream *os,
AVFormatContext *s,
(double) seg->duration / timescale, 0,
seg->range_length, seg->start_pos, NULL,
c->single_file ? os->initfile : seg->file,
-_date_time);
+_date_time, 0, 0, 0);
if (ret < 0) {
av_log(os->ctx, AV_LOG_WARNING, "ff_hls_write_file_entry get
error\n");
}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 1613c34509..9884f74d51 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -75,6 +75,8 @@ typedef struct HLSSegment {
int discont;
int64_t pos;
int64_t size;
+int64_t keyframe_pos;
+int64_t keyframe_size;
unsigned var_stream_idx;
char key_uri[LINE_BUFFER_SIZE + 1];
@@ -99,6 +101,7 @@ typedef enum HLSFlags {
HLS_TEMP_FILE = (1 << 11),
HLS_PERIODIC_REKEY = (1 << 12),
HLS_INDEPENDENT_SEGMENTS = (1 << 13),
+HLS_I_FRAMES_ONLY = (1 << 14),
} HLSFlags;
typedef enum {
@@ -125,6 +128,9 @@ typedef struct VariantStream {
double dpp; // duration per packet
int64_t start_pts;
int64_t end_pts;
+int64_t video_lastpos;
+int64_t video_keyframe_pos;
+int64_t video_keyframe_size;
double duration; // last segment duration computed so far, in seconds
int64_t start_pos;// last segment starting position
int64_t size; // last segment size
@@ -994,6 +1000,8 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls,
en->duration = duration;
en->pos = pos;
en->size = size;
+en->keyframe_pos = vs->video_keyframe_pos;
+en->keyframe_size = vs->video_keyframe_size;
en->next = NULL;
en->discont = 0;
@@ -1411,7 +1419,7 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
vs->discontinuity_set = 0;
ff_hls_write_playlist_header(hls->m3u8_out, hls->version, hls->allowcache,
- target_duration, sequence, hls->pl_type);
+ target_duration, sequence, hls->pl_type,
hls->flags & HLS_I_FRAMES_ONLY);
if((hls->flags & HLS_DISCONT_START) && sequence==hls->start_sequence &&
vs->discontinuity_set==0 ){
avio_printf(hls->m3u8_out, "#EXT-X-DISCONTINUITY\n");
@@ -1439,7 +1447,7 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
ret = ff_hls_write_file_entry(hls->m3u8_out, en->discont,
byterange_mode,
en->duration, hls->flags &
HLS_ROUND_DURATIONS,
en->size, en->pos, vs->baseurl,
- en->filename, prog_date_time_p);
+ en->filename, prog_date_time_p,
en->keyframe_size, en->keyframe_pos, hls->flags & HLS_I_FRAMES_ONLY);
if (ret < 0) {
av_log(s, AV_LOG_WARNING, "ff_hls_write_file_entry get error\n");
}
@@ -1455,11 +1463,11 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
goto fail;
}
ff_hls_write_playlist_header(hls->sub_m3u8_out, hls->version,
hls->allowcache,
-
Re: [FFmpeg-devel] [PATCH] doc/muxers: fix typo of the hls var_stream_map example
> 在 2019年6月2日，21:29，Gyan 写道： > > > > On 02-06-2019 06:44 PM, Steven Liu wrote: >> Signed-off-by: Steven Liu >> --- >> doc/muxers.texi | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/doc/muxers.texi b/doc/muxers.texi >> index 7f3758b117..46580091ba 100644 >> --- a/doc/muxers.texi >> +++ b/doc/muxers.texi >> @@ -995,7 +995,7 @@ By default, a single hls variant containing all the >> encoded streams is created. >> @example >> ffmpeg -re -i in.ts -b:a:0 32k -b:a:1 64k -b:v:0 1000k \ >>-map 0:a -map 0:a -map 0:v -f hls \ >> - -var_stream_map "a:0,agroup:aud_low,default:yes,language=ENG >> a:1,agroup:aud_low,language:CHN v:0,agroup:aud_low" \ >> + -var_stream_map "a:0,agroup:aud_low,default:yes,language:ENG >> a:1,agroup:aud_low,language:CHN v:0,agroup:aud_low" \ >>-master_pl_name master.m3u8 \ >>http://example.com/live/out_%v.m3u8 >> @end example > > LGTM. > > Also, you can correct the comment on line 1833 of hlsenc.c > > defalut --> default Fix local and pushed > > Gyan > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". Thanks Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add EXT-X-I-FRAMES-ONLY tag support
On 02-06-2019 06:03 PM, Steven Liu wrote:
Signed-off-by: Steven Liu
---
doc/muxers.texi | 4
libavformat/dashenc.c | 4 ++--
libavformat/hlsenc.c | 27 ++-
libavformat/hlsplaylist.c | 11 ---
libavformat/hlsplaylist.h | 5 +++--
5 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 83ae017d6c..7f3758b117 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -852,6 +852,10 @@ including the file containing the AES encryption key.
Add the @code{#EXT-X-INDEPENDENT-SEGMENTS} to playlists that has video
segments
and when all the segments of that playlist are guaranteed to start with a Key
frame.
+@item iframes_only
+Add the @code{#EXT-X-I-FRAMES-ONLY} to playlists that has video segments
+and only can play i frames in the @code{#EXT-X-BYTERANGE} mode.
"and can play only I-frames in ..."
+
@item split_by_time
Allow segments to start on frames other than keyframes. This improves
behavior on some players when the time between keyframes is inconsistent,
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 94b198ceb8..3fd7e78166 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -471,7 +471,7 @@ static void write_hls_media_playlist(OutputStream *os,
AVFormatContext *s,
}
ff_hls_write_playlist_header(c->m3u8_out, 6, -1, target_duration,
- start_number, PLAYLIST_TYPE_NONE);
+ start_number, PLAYLIST_TYPE_NONE, 0);
ff_hls_write_init_file(c->m3u8_out, os->initfile, c->single_file,
os->init_range_length, os->init_start_pos);
@@ -491,7 +491,7 @@ static void write_hls_media_playlist(OutputStream *os,
AVFormatContext *s,
(double) seg->duration / timescale, 0,
seg->range_length, seg->start_pos, NULL,
c->single_file ? os->initfile : seg->file,
-_date_time);
+_date_time, 0, 0, 0);
if (ret < 0) {
av_log(os->ctx, AV_LOG_WARNING, "ff_hls_write_file_entry get
error\n");
}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 6b913be31c..4ffc522803 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -75,6 +75,8 @@ typedef struct HLSSegment {
int discont;
int64_t pos;
int64_t size;
+int64_t keyframe_pos;
+int64_t keyframe_size;
unsigned var_stream_idx;
char key_uri[LINE_BUFFER_SIZE + 1];
@@ -99,6 +101,7 @@ typedef enum HLSFlags {
HLS_TEMP_FILE = (1 << 11),
HLS_PERIODIC_REKEY = (1 << 12),
HLS_INDEPENDENT_SEGMENTS = (1 << 13),
+HLS_I_FRAMES_ONLY = (1 << 14),
} HLSFlags;
typedef enum {
@@ -125,6 +128,9 @@ typedef struct VariantStream {
double dpp; // duration per packet
int64_t start_pts;
int64_t end_pts;
+int64_t video_lastpos;
+int64_t video_keyframe_pos;
+int64_t video_keyframe_size;
double duration; // last segment duration computed so far, in seconds
int64_t start_pos;// last segment starting position
int64_t size; // last segment size
@@ -994,6 +1000,8 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls,
en->duration = duration;
en->pos = pos;
en->size = size;
+en->keyframe_pos = vs->video_keyframe_pos;
+en->keyframe_size = vs->video_keyframe_size;
en->next = NULL;
en->discont = 0;
@@ -1411,7 +1419,7 @@ static int hls_window(AVFormatContext *s, int last, VariantStream *vs)
vs->discontinuity_set = 0;
ff_hls_write_playlist_header(hls->m3u8_out, hls->version, hls->allowcache,
- target_duration, sequence, hls->pl_type);
+ target_duration, sequence, hls->pl_type,
hls->flags & HLS_I_FRAMES_ONLY);
if((hls->flags & HLS_DISCONT_START) && sequence==hls->start_sequence && vs->discontinuity_set==0 ){
avio_printf(hls->m3u8_out, "#EXT-X-DISCONTINUITY\n");
@@ -1439,7 +1447,7 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
ret = ff_hls_write_file_entry(hls->m3u8_out, en->discont,
byterange_mode,
en->duration, hls->flags &
HLS_ROUND_DURATIONS,
en->size, en->pos, vs->baseurl,
- en->filename, prog_date_time_p);
+ en->filename, prog_date_time_p, en->keyframe_size,
en->keyframe_pos, hls->flags & HLS_I_FRAMES_ONLY);
if (ret < 0) {
av_log(s, AV_LOG_WARNING, "ff_hls_write_file_entry get error\n");
}
@@ -1455,11 +1463,11 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
Re: [FFmpeg-devel] [PATCH] doc/muxers: fix typo of the hls var_stream_map example
On 02-06-2019 06:44 PM, Steven Liu wrote: Signed-off-by: Steven Liu --- doc/muxers.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/muxers.texi b/doc/muxers.texi index 7f3758b117..46580091ba 100644 --- a/doc/muxers.texi +++ b/doc/muxers.texi @@ -995,7 +995,7 @@ By default, a single hls variant containing all the encoded streams is created. @example ffmpeg -re -i in.ts -b:a:0 32k -b:a:1 64k -b:v:0 1000k \ -map 0:a -map 0:a -map 0:v -f hls \ - -var_stream_map "a:0,agroup:aud_low,default:yes,language=ENG a:1,agroup:aud_low,language:CHN v:0,agroup:aud_low" \ + -var_stream_map "a:0,agroup:aud_low,default:yes,language:ENG a:1,agroup:aud_low,language:CHN v:0,agroup:aud_low" \ -master_pl_name master.m3u8 \ http://example.com/live/out_%v.m3u8 @end example LGTM. Also, you can correct the comment on line 1833 of hlsenc.c defalut --> default Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc/muxers: fix typo of the hls var_stream_map example
Signed-off-by: Steven Liu --- doc/muxers.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/muxers.texi b/doc/muxers.texi index 7f3758b117..46580091ba 100644 --- a/doc/muxers.texi +++ b/doc/muxers.texi @@ -995,7 +995,7 @@ By default, a single hls variant containing all the encoded streams is created. @example ffmpeg -re -i in.ts -b:a:0 32k -b:a:1 64k -b:v:0 1000k \ -map 0:a -map 0:a -map 0:v -f hls \ - -var_stream_map "a:0,agroup:aud_low,default:yes,language=ENG a:1,agroup:aud_low,language:CHN v:0,agroup:aud_low" \ + -var_stream_map "a:0,agroup:aud_low,default:yes,language:ENG a:1,agroup:aud_low,language:CHN v:0,agroup:aud_low" \ -master_pl_name master.m3u8 \ http://example.com/live/out_%v.m3u8 @end example -- 2.15.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hlsenc: add EXT-X-I-FRAMES-ONLY tag support
Signed-off-by: Steven Liu
---
doc/muxers.texi | 4
libavformat/dashenc.c | 4 ++--
libavformat/hlsenc.c | 27 ++-
libavformat/hlsplaylist.c | 11 ---
libavformat/hlsplaylist.h | 5 +++--
5 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 83ae017d6c..7f3758b117 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -852,6 +852,10 @@ including the file containing the AES encryption key.
Add the @code{#EXT-X-INDEPENDENT-SEGMENTS} to playlists that has video segments
and when all the segments of that playlist are guaranteed to start with a Key
frame.
+@item iframes_only
+Add the @code{#EXT-X-I-FRAMES-ONLY} to playlists that has video segments
+and only can play i frames in the @code{#EXT-X-BYTERANGE} mode.
+
@item split_by_time
Allow segments to start on frames other than keyframes. This improves
behavior on some players when the time between keyframes is inconsistent,
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 94b198ceb8..3fd7e78166 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -471,7 +471,7 @@ static void write_hls_media_playlist(OutputStream *os,
AVFormatContext *s,
}
ff_hls_write_playlist_header(c->m3u8_out, 6, -1, target_duration,
- start_number, PLAYLIST_TYPE_NONE);
+ start_number, PLAYLIST_TYPE_NONE, 0);
ff_hls_write_init_file(c->m3u8_out, os->initfile, c->single_file,
os->init_range_length, os->init_start_pos);
@@ -491,7 +491,7 @@ static void write_hls_media_playlist(OutputStream *os,
AVFormatContext *s,
(double) seg->duration / timescale, 0,
seg->range_length, seg->start_pos, NULL,
c->single_file ? os->initfile : seg->file,
-_date_time);
+_date_time, 0, 0, 0);
if (ret < 0) {
av_log(os->ctx, AV_LOG_WARNING, "ff_hls_write_file_entry get
error\n");
}
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 6b913be31c..4ffc522803 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -75,6 +75,8 @@ typedef struct HLSSegment {
int discont;
int64_t pos;
int64_t size;
+int64_t keyframe_pos;
+int64_t keyframe_size;
unsigned var_stream_idx;
char key_uri[LINE_BUFFER_SIZE + 1];
@@ -99,6 +101,7 @@ typedef enum HLSFlags {
HLS_TEMP_FILE = (1 << 11),
HLS_PERIODIC_REKEY = (1 << 12),
HLS_INDEPENDENT_SEGMENTS = (1 << 13),
+HLS_I_FRAMES_ONLY = (1 << 14),
} HLSFlags;
typedef enum {
@@ -125,6 +128,9 @@ typedef struct VariantStream {
double dpp; // duration per packet
int64_t start_pts;
int64_t end_pts;
+int64_t video_lastpos;
+int64_t video_keyframe_pos;
+int64_t video_keyframe_size;
double duration; // last segment duration computed so far, in seconds
int64_t start_pos;// last segment starting position
int64_t size; // last segment size
@@ -994,6 +1000,8 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls,
en->duration = duration;
en->pos = pos;
en->size = size;
+en->keyframe_pos = vs->video_keyframe_pos;
+en->keyframe_size = vs->video_keyframe_size;
en->next = NULL;
en->discont = 0;
@@ -1411,7 +1419,7 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
vs->discontinuity_set = 0;
ff_hls_write_playlist_header(hls->m3u8_out, hls->version, hls->allowcache,
- target_duration, sequence, hls->pl_type);
+ target_duration, sequence, hls->pl_type,
hls->flags & HLS_I_FRAMES_ONLY);
if((hls->flags & HLS_DISCONT_START) && sequence==hls->start_sequence &&
vs->discontinuity_set==0 ){
avio_printf(hls->m3u8_out, "#EXT-X-DISCONTINUITY\n");
@@ -1439,7 +1447,7 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
ret = ff_hls_write_file_entry(hls->m3u8_out, en->discont,
byterange_mode,
en->duration, hls->flags &
HLS_ROUND_DURATIONS,
en->size, en->pos, vs->baseurl,
- en->filename, prog_date_time_p);
+ en->filename, prog_date_time_p,
en->keyframe_size, en->keyframe_pos, hls->flags & HLS_I_FRAMES_ONLY);
if (ret < 0) {
av_log(s, AV_LOG_WARNING, "ff_hls_write_file_entry get error\n");
}
@@ -1455,11 +1463,11 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
goto fail;
}
ff_hls_write_playlist_header(hls->sub_m3u8_out, hls->version,
hls->allowcache,
-
Re: [FFmpeg-devel] [PATCH V5 1/2] lavfi/colorlevels: Add slice threading support
On 6/1/19, Jun Zhao wrote:
> From: Jun Zhao
>
> Add slice threading support, use the command like:
>
> ./ffmpeg -i input -vf colorlevels -f null /dev/null
>
> with 1080p h264 clip, the fps from 39 fps to 79 fps
> in the local(Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz)
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/vf_colorlevels.c | 110
> ++---
> 1 files changed, 91 insertions(+), 19 deletions(-)
Should be ok if filter produces same md5 output with multiple threads.
>
> diff --git a/libavfilter/vf_colorlevels.c b/libavfilter/vf_colorlevels.c
> index 5385a5e..fadb39e 100644
> --- a/libavfilter/vf_colorlevels.c
> +++ b/libavfilter/vf_colorlevels.c
> @@ -105,6 +105,68 @@ static int config_input(AVFilterLink *inlink)
> return 0;
> }
>
> +struct thread_data {
> +const uint8_t *srcrow;
> +uint8_t *dstrow;
> +int dst_linesize;
> +int src_linesize;
> +
> +double coeff;
> +uint8_t offset;
> +
> +int h;
> +
> +int imin;
> +int omin;
> +};
> +
> +#define LOAD_COMMON\
> +ColorLevelsContext *s = ctx->priv;\
> +const struct thread_data *td = arg;\
> +\
> +int process_h = td->h;\
> +const int slice_start = (process_h * jobnr ) / nb_jobs;\
> +const int slice_end = (process_h * (jobnr+1)) / nb_jobs;\
> +int x, y;\
> +const uint8_t *srcrow = td->srcrow;\
> +uint8_t *dstrow = td->dstrow;\
> +const int step = s->step;\
> +const uint8_t offset = td->offset;\
> +\
> +int imin = td->imin;\
> +int omin = td->omin;\
> +double coeff = td->coeff;\
> +
> +static int colorlevel_slice_8(AVFilterContext *ctx, void *arg, int jobnr,
> int nb_jobs)
> +{
> +LOAD_COMMON
> +
> +for (y = slice_start; y < slice_end; y++) {
> +const uint8_t *src = srcrow + y * td->src_linesize;
> +uint8_t *dst = dstrow + y * td->dst_linesize;
> +
> +for (x = 0; x < s->linesize; x += step)
> +dst[x + offset] = av_clip_uint8((src[x + offset] - imin) *
> coeff + omin);
> +}
> +
> +return 0;
> +}
> +
> +static int colorlevel_slice_16(AVFilterContext *ctx, void *arg, int jobnr,
> int nb_jobs)
> +{
> +LOAD_COMMON
> +
> +for (y = slice_start; y < slice_end; y++) {
> +const uint16_t *src = (const uint16_t *)(srcrow + y *
> td->src_linesize);
> +uint16_t *dst = (uint16_t *)(dstrow + y * td->dst_linesize);
> +
> +for (x = 0; x < s->linesize; x += step)
> +dst[x + offset] = av_clip_uint16((src[x + offset] - imin) *
> coeff + omin);
> +}
> +
> +return 0;
> +}
> +
> static int filter_frame(AVFilterLink *inlink, AVFrame *in)
> {
> AVFilterContext *ctx = inlink->dst;
> @@ -137,6 +199,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> int omin = lrint(r->out_min * UINT8_MAX);
> int omax = lrint(r->out_max * UINT8_MAX);
> double coeff;
> +struct thread_data td;
>
> if (imin < 0) {
> imin = UINT8_MAX;
> @@ -162,15 +225,19 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
>
> srcrow = in->data[0];
> coeff = (omax - omin) / (double)(imax - imin);
> -for (y = 0; y < inlink->h; y++) {
> -const uint8_t *src = srcrow;
> -uint8_t *dst = dstrow;
> -
> -for (x = 0; x < s->linesize; x += step)
> -dst[x + offset] = av_clip_uint8((src[x + offset] -
> imin) * coeff + omin);
> -dstrow += out->linesize[0];
> -srcrow += in->linesize[0];
> -}
> +
> +td.srcrow= srcrow;
> +td.dstrow= dstrow;
> +td.dst_linesize = out->linesize[0];
> +td.src_linesize = in->linesize[0];
> +td.coeff = coeff;
> +td.offset= offset;
> +td.h = inlink->h;
> +td.imin = imin;
> +td.omin = omin;
> +
> +ctx->internal->execute(ctx, colorlevel_slice_8, , NULL,
> + FFMIN(inlink->h,
> ff_filter_get_nb_threads(ctx)));
> }
> break;
> case 2:
> @@ -184,6 +251,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> int omin = lrint(r->out_min * UINT16_MAX);
> int omax = lrint(r->out_max * UINT16_MAX);
> double coeff;
> +struct thread_data td;
>
> if (imin < 0) {
> imin = UINT16_MAX;
> @@ -209,15 +277,19 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
>
> srcrow = in->data[0];
> coeff = (omax - omin) / (double)(imax - imin);
> -for (y = 0; y < inlink->h; y++) {
> -const uint16_t *src = (const uint16_t*)srcrow;
> -uint16_t *dst = (uint16_t *)dstrow;
> -
> -for (x = 0; x < s->linesize; x += step)
> -
Re: [FFmpeg-devel] [PATCH V5 2/2] lavfi/lut: Add slice threading support
On 6/1/19, Jun Zhao wrote:
> From: Jun Zhao
>
> Used the command for 1080p h264 clip as follow:
>
> a). ffmpeg -i input -vf lutyuv="u=128:v=128" -f null /dev/null
> b). ffmpeg -i input -vf lutrgb="g=0:b=0" -f null /dev/null
>
> after enabled the slice threading, the fps change from:
>
> a). 144fps to 258fps (lutyuv)
> b). 94fps to 153fps (lutrgb)
>
> in Intel(R) Core(TM) i5-8265U CPU @ 1.60GHz
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/vf_lut.c | 310
> --
> 1 files changed, 197 insertions(+), 113 deletions(-)
>
> diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
> index c815ddc..90998e6 100644
> --- a/libavfilter/vf_lut.c
> +++ b/libavfilter/vf_lut.c
> @@ -337,13 +337,194 @@ static int config_props(AVFilterLink *inlink)
> return 0;
> }
>
> +struct thread_data {
> +AVFrame *in;
> +AVFrame *out;
> +
> +int w;
> +int h;
> +};
> +
> +#define LOAD_PACKED_COMMON\
> +LutContext *s = ctx->priv;\
> +const struct thread_data *td = arg;\
> +\
> +int i, j;\
> +const int w = td->w;\
> +const int h = td->h;\
> +AVFrame *in = td->in;\
> +AVFrame *out = td->out;\
> +const uint16_t (*tab)[256*256] = (const uint16_t (*)[256*256])s->lut;\
> +const int step = s->step;\
> +\
> +const int slice_start = (h * jobnr ) / nb_jobs;\
> +const int slice_end = (h * (jobnr+1)) / nb_jobs;\
> +
> +/* packed, 16-bit */
> +static int lut_packed_16bits(AVFilterContext *ctx, void *arg, int jobnr,
> int nb_jobs)
> +{
> +LOAD_PACKED_COMMON
> +
> +uint16_t *inrow, *outrow, *inrow0, *outrow0;
> +const int in_linesize = in->linesize[0] / 2;
> +const int out_linesize = out->linesize[0] / 2;
> +inrow0 = (uint16_t *)in ->data[0];
> +outrow0 = (uint16_t *)out->data[0];
> +
> +for (i = slice_start; i < slice_end; i++) {
> +inrow = inrow0 + i * in_linesize;
> +outrow = outrow0 + i * out_linesize;
> +for (j = 0; j < w; j++) {
> +
> +switch (step) {
> +#if HAVE_BIGENDIAN
> +case 4: outrow[3] = av_bswap16(tab[3][av_bswap16(inrow[3])]);
> // Fall-through
> +case 3: outrow[2] = av_bswap16(tab[2][av_bswap16(inrow[2])]);
> // Fall-through
> +case 2: outrow[1] = av_bswap16(tab[1][av_bswap16(inrow[1])]);
> // Fall-through
> +default: outrow[0] = av_bswap16(tab[0][av_bswap16(inrow[0])]);
> +#else
> +case 4: outrow[3] = tab[3][inrow[3]]; // Fall-through
> +case 3: outrow[2] = tab[2][inrow[2]]; // Fall-through
> +case 2: outrow[1] = tab[1][inrow[1]]; // Fall-through
> +default: outrow[0] = tab[0][inrow[0]];
> +#endif
> +}
> +outrow += step;
> +inrow += step;
> +}
> +}
> +
> +return 0;
> +}
> +
> +/* packed, 8-bit */
> +static int lut_packed_8bits(AVFilterContext *ctx, void *arg, int jobnr, int
> nb_jobs)
> +{
> +LOAD_PACKED_COMMON
> +
> +uint8_t *inrow, *outrow, *inrow0, *outrow0;
> +const int in_linesize = in->linesize[0];
> +const int out_linesize = out->linesize[0];
> +inrow0 = in ->data[0];
> +outrow0 = out->data[0];
> +
> +for (i = slice_start; i < slice_end; i++) {
> +inrow = inrow0 + i * in_linesize;
> +outrow = outrow0 + i * out_linesize;
> +for (j = 0; j < w; j++) {
> +switch (step) {
> +case 4: outrow[3] = tab[3][inrow[3]]; // Fall-through
> +case 3: outrow[2] = tab[2][inrow[2]]; // Fall-through
> +case 2: outrow[1] = tab[1][inrow[1]]; // Fall-through
> +default: outrow[0] = tab[0][inrow[0]];
> +}
> +outrow += step;
> +inrow += step;
> +}
> +}
> +
> +return 0;
> +}
> +
> +#define LOAD_PLANAR_COMMON\
> +LutContext *s = ctx->priv;\
> +const struct thread_data *td = arg;\
> +int i, j, plane;\
> +AVFrame *in = td->in;\
> +AVFrame *out = td->out;\
> +
> +#define PLANAR_COMMON\
> +int vsub = plane == 1 || plane == 2 ? s->vsub : 0;\
> +int hsub = plane == 1 || plane == 2 ? s->hsub : 0;\
> +int h = AV_CEIL_RSHIFT(td->h, vsub);\
> +int w = AV_CEIL_RSHIFT(td->w, hsub);\
> +const uint16_t *tab = s->lut[plane];\
> +\
> +const int slice_start = (h * jobnr ) / nb_jobs;\
> +const int slice_end = (h * (jobnr+1)) / nb_jobs;\
> +
> +/* planar >8 bit depth */
> +static int lut_planar_16bits(AVFilterContext *ctx, void *arg, int jobnr,
> int nb_jobs)
> +{
> +LOAD_PLANAR_COMMON
> +
> +uint16_t *inrow, *outrow;
> +
> +for (plane = 0; plane < 4 && in->data[plane] && in->linesize[plane];
> plane++) {
> +PLANAR_COMMON
> +
> +const int in_linesize = in->linesize[plane] / 2;
> +const int out_linesize = out->linesize[plane] / 2;
> +
> +inrow = (uint16_t *)(in ->data[plane] + slice_start *
> in_linesize);
> +outrow = (uint16_t
