date:20190325

[FFmpeg-devel] [PATCH, v2] lavc/qsvenc: expose low_power option in H264 QSV

2019-03-25 Thread Linjie Fu

Always exposes low_power option for h264 qsv, and reports a warning
if VDENC is not supported with current version of MSDK.

Signed-off-by: Linjie Fu 
---
[v2]: repalce "VDENC" with "low_power" to be more understandable.

 libavcodec/qsvenc.c  | 11 ++-
 libavcodec/qsvenc_h264.c |  2 --
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 5aa020d47b..8264d0a413 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -495,9 +495,18 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 }
 }
 
+if (q->low_power) {
 #if QSV_HAVE_VDENC
-q->param.mfx.LowPower   = q->low_power ? MFX_CODINGOPTION_ON : 
MFX_CODINGOPTION_OFF;
+q->param.mfx.LowPower = MFX_CODINGOPTION_ON;
+#else
+av_log(avctx, AV_LOG_WARNING, "The low_power option is "
+"not supported with this MSDK version.\n");
+q->low_power = 0;
+q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
 #endif
+} else
+q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
+
 q->param.mfx.CodecProfile   = q->profile;
 q->param.mfx.TargetUsage= avctx->compression_level;
 q->param.mfx.GopPicSize = FFMAX(0, avctx->gop_size);
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index f458137848..93044a58c9 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -154,9 +154,7 @@ static const AVOption options[] = {
 { "auto"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_MF_AUTO }, 
INT_MIN, INT_MAX, VE, "mfmode" },
 #endif
 
-#if QSV_HAVE_VDENC
 { "low_power", "enable low power mode(experimental: many limitations by 
mfx version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 
=  0 }, 0, 1, VE},
-#endif
 
 { "repeat_pps", "repeat pps for every frame", OFFSET(qsv.repeat_pps), 
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
 
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: expose low_power option in H264 QSV

2019-03-25 Thread Fu, Linjie

> -Original Message-
> From: Li, Zhong
> Sent: Tuesday, March 26, 2019 12:02
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Fu, Linjie 
> Subject: RE: [FFmpeg-devel] [PATCH] lavc/qsvenc: expose low_power option
> in H264 QSV
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Monday, March 25, 2019 9:32 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie 
> > Subject: [FFmpeg-devel] [PATCH] lavc/qsvenc: expose low_power option
> in
> > H264 QSV
> >
> > Always exposes low_power option for h264 qsv, and reports a warning if
> > VDENC is not supported with current version of MSDK.
> >
> > Signed-off-by: Linjie Fu 
> > ---
> >  libavcodec/qsvenc.c  | 11 ++-
> >  libavcodec/qsvenc_h264.c |  2 --
> >  2 files changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> > 5aa020d47b..8264d0a413 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -495,9 +495,18 @@ static int init_video_param(AVCodecContext
> *avctx,
> > QSVEncContext *q)
> >  }
> >  }
> >
> > +if (q->low_power) {
> >  #if QSV_HAVE_VDENC
> > -q->param.mfx.LowPower   = q->low_power ?
> > MFX_CODINGOPTION_ON : MFX_CODINGOPTION_OFF;
> > +q->param.mfx.LowPower = MFX_CODINGOPTION_ON; #else
> > +av_log(avctx, AV_LOG_WARNING, "The QSV VDENC option is "
> > +"not supported with this MSDK
> > version.\n");
> 
> VDEnc is driver and hardware scope should not be exposed in FFmpeg level.
> Lower power is easier for user to understand, and it is the option user set. 
> So
> I believe the would be better to change the log to be
> "low power mode is not supported ..."
> 
It's true "low power" is better, will update.
> > +q->low_power = 0;
> > +q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
> >  #endif
> > +} else
> > +q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
> 
> The rest LGTM
___
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/3] doc/examples: add QSV decode GPU copy sample

2019-03-25 Thread Linjie Fu

Usage is:
  ./qsvdec_gpucopy on/off input_stream output_stream

For example:
 - enable/disable gpu copy:
  ./qsvdec_gpucopy on input.h264 output.yuv
  ./qsvdec_gpucopy off input.h264 output.yuv

Generate fps per second.

Signed-off-by: Linjie Fu 
---
 configure |   2 +
 doc/examples/Makefile |   1 +
 doc/examples/qsvdec_gpucopy.c | 276 ++
 3 files changed, 279 insertions(+)
 create mode 100644 doc/examples/qsvdec_gpucopy.c

diff --git a/configure b/configure
index 331393f8d5..579ab9ea4a 100755
--- a/configure
+++ b/configure
@@ -1667,6 +1667,7 @@ EXAMPLE_LIST="
 metadata_example
 muxing_example
 qsvdec_example
+qsvdec_gpucopy_example
 remuxing_example
 resampling_audio_example
 scaling_video_example
@@ -3550,6 +3551,7 @@ hw_decode_example_deps="avcodec avformat avutil"
 metadata_example_deps="avformat avutil"
 muxing_example_deps="avcodec avformat avutil swscale"
 qsvdec_example_deps="avcodec avutil libmfx h264_qsv_decoder"
+qsvdec_gpucopy_example_deps="avcodec avutil avformat"
 remuxing_example_deps="avcodec avformat avutil"
 resampling_audio_example_deps="avutil swresample"
 scaling_video_example_deps="avutil swscale"
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 2935424e54..188ef0abf1 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -14,6 +14,7 @@ EXAMPLES-$(CONFIG_HW_DECODE_EXAMPLE) += hw_decode
 EXAMPLES-$(CONFIG_METADATA_EXAMPLE)  += metadata
 EXAMPLES-$(CONFIG_MUXING_EXAMPLE)+= muxing
 EXAMPLES-$(CONFIG_QSVDEC_EXAMPLE)+= qsvdec
+EXAMPLES-$(CONFIG_QSVDEC_GPUCOPY_EXAMPLE)+= qsvdec_gpucopy
 EXAMPLES-$(CONFIG_REMUXING_EXAMPLE)  += remuxing
 EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE)  += resampling_audio
 EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video
diff --git a/doc/examples/qsvdec_gpucopy.c b/doc/examples/qsvdec_gpucopy.c
new file mode 100644
index 00..244cf6c6a0
--- /dev/null
+++ b/doc/examples/qsvdec_gpucopy.c
@@ -0,0 +1,276 @@
+/*
+ * Copyright (c) 2019 Linjie Fu
+ *
+ * HW Acceleration API (video decoding) decode sample
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * @file
+ * QSV-Accelerated H264 decoding GPU Copy example.
+ *
+ * @example qsvdec_gpucopy.c
+ * This example shows how to do QSV decode with GPU Copy
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "libavcodec/qsv.h"
+#include 
+
+static AVBufferRef *hw_device_ctx = NULL;
+static enum AVPixelFormat hw_pix_fmt;
+static FILE *output_file = NULL;
+static int g_frame_count = 0;
+int g_avg_fps = 0;
+struct timeval pre_timestamp, cur_timestamp;
+
+static int hw_decoder_init(AVCodecContext *ctx,
+   const enum AVHWDeviceType type) {
+int err = 0;
+
+if ((err = av_hwdevice_ctx_create(_device_ctx, type, NULL, NULL, 0)) <
+0) {
+fprintf(stderr, "Failed to create specified HW device.\n");
+return err;
+}
+ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
+
+return err;
+}
+
+static enum AVPixelFormat get_hw_format(AVCodecContext *ctx,
+const enum AVPixelFormat *pix_fmts) {
+const enum AVPixelFormat *p;
+
+for (p = pix_fmts; *p != -1; p++) {
+if (*p == hw_pix_fmt) return *p;
+}
+
+fprintf(stderr, "Failed to get HW surface format.\n");
+return AV_PIX_FMT_NONE;
+}
+
+static int decode_write(AVCodecContext *avctx, AVPacket *packet) {
+AVFrame *frame = NULL;
+
+uint8_t *buffer = NULL;
+int size;
+int ret = 0;
+
+ret = avcodec_send_packet(avctx, packet);
+if (ret < 0) {
+fprintf(stderr, "Error during decoding\n");
+return ret;
+}
+
+while (1) {
+if (!(frame = av_frame_alloc())) {
+fprintf(stderr, "Can not alloc frame\n");
+ret =

[FFmpeg-devel] [PATCH, RFC 2/3] lavc/qsvdec: add support for system memory mode

2019-03-25 Thread Linjie Fu

Copy from video to system memory, so output in sysmem memory mode is needed.

Signed-off-by: Linjie Fu 
---
Previously discussed in:
https://patchwork.ffmpeg.org/patch/7009/
This mode is needed in gpu_copy, is this feature implemented in
current lavc now?
 libavcodec/qsvdec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 5dd2b3834b..604effbd51 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -47,7 +47,8 @@ const AVCodecHWConfigInternal *ff_qsv_hw_configs[] = {
 &(const AVCodecHWConfigInternal) {
 .public = {
 .pix_fmt = AV_PIX_FMT_QSV,
-.methods = AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX |
+.methods = AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX |
+   AV_CODEC_HW_CONFIG_METHOD_HW_FRAMES_CTX |
AV_CODEC_HW_CONFIG_METHOD_AD_HOC,
 .device_type = AV_HWDEVICE_TYPE_QSV,
 },
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] lavc/qsvdec: add support for gpu_copy

2019-03-25 Thread Linjie Fu

Add support for GPU copy when QSV decoders works in system memory mode.
However, memory must be sequent and aligned with 128x64 to enable this
feature.(first introduced in FFmpeg 3.3.1)

GPUCopy = MFX_GPUCOPY_ON leads to performance improvement up to x10.

CMD:
ffmpeg -init_hw_device qsv=hw -filter_hw_device hw -c:v h264_qsv
-gpu_copy on -i input.h264 -pix_fmt yuv420p out.yuv


Signed-off-by: Linjie Fu 
Signed-off-by: ChaoX A Liu 
---
 libavcodec/qsv.c  | 27 +---
 libavcodec/qsv_internal.h |  6 ++---
 libavcodec/qsvdec.c   | 53 ++-
 libavcodec/qsvdec.h   |  2 ++
 libavcodec/qsvdec_h2645.c | 10 
 libavcodec/qsvdec_other.c |  5 
 libavcodec/qsvenc.c   |  7 +++---
 7 files changed, 89 insertions(+), 21 deletions(-)

diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index bb0d79588c..40e6c677cb 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -277,15 +277,19 @@ load_plugin_fail:
 }
 
 int ff_qsv_init_internal_session(AVCodecContext *avctx, mfxSession *session,
- const char *load_plugins)
+ const char *load_plugins, int gpu_copy)
 {
-mfxIMPL impl   = MFX_IMPL_AUTO_ANY;
-mfxVersion ver = { { QSV_VERSION_MINOR, QSV_VERSION_MAJOR } };
+mfxIMPL  impl = MFX_IMPL_AUTO_ANY;
+mfxVersionver = { { QSV_VERSION_MINOR, QSV_VERSION_MAJOR } };
+mfxInitParam init_par = { MFX_IMPL_AUTO_ANY };
 
 const char *desc;
 int ret;
 
-ret = MFXInit(impl, , session);
+init_par.GPUCopy= gpu_copy;
+init_par.Implementation = impl;
+init_par.Version= ver;
+ret = MFXInitEx(init_par, session);
 if (ret < 0)
 return ff_qsv_print_error(avctx, ret,
   "Error initializing an internal MFX 
session");
@@ -571,7 +575,8 @@ static mfxStatus qsv_frame_get_hdl(mfxHDL pthis, mfxMemId 
mid, mfxHDL *hdl)
 }
 
 int ff_qsv_init_session_device(AVCodecContext *avctx, mfxSession *psession,
-   AVBufferRef *device_ref, const char 
*load_plugins)
+   AVBufferRef *device_ref, const char 
*load_plugins,
+   int gpu_copy)
 {
 static const mfxHandleType handle_types[] = {
 MFX_HANDLE_VA_DISPLAY,
@@ -581,11 +586,12 @@ int ff_qsv_init_session_device(AVCodecContext *avctx, 
mfxSession *psession,
 AVHWDeviceContext*device_ctx = (AVHWDeviceContext*)device_ref->data;
 AVQSVDeviceContext *device_hwctx = device_ctx->hwctx;
 mfxSessionparent_session = device_hwctx->session;
+mfxInitParaminit_par = { MFX_IMPL_AUTO_ANY };
+mfxHDLhandle = NULL;
 
 mfxSessionsession;
 mfxVersionver;
 mfxIMPL   impl;
-mfxHDLhandle = NULL;
 mfxHandleType handle_type;
 mfxStatus err;
 
@@ -611,7 +617,10 @@ int ff_qsv_init_session_device(AVCodecContext *avctx, 
mfxSession *psession,
"from the session\n");
 }
 
-err = MFXInit(impl, , );
+init_par.GPUCopy= gpu_copy;
+init_par.Implementation = impl;
+init_par.Version= ver;
+err = MFXInitEx(init_par, );
 if (err != MFX_ERR_NONE)
 return ff_qsv_print_error(avctx, err,
   "Error initializing a child MFX session");
@@ -642,7 +651,7 @@ int ff_qsv_init_session_device(AVCodecContext *avctx, 
mfxSession *psession,
 
 int ff_qsv_init_session_frames(AVCodecContext *avctx, mfxSession *psession,
QSVFramesContext *qsv_frames_ctx,
-   const char *load_plugins, int opaque)
+   const char *load_plugins, int opaque, int 
gpu_copy)
 {
 mfxFrameAllocator frame_allocator = {
 .pthis  = qsv_frames_ctx,
@@ -662,7 +671,7 @@ int ff_qsv_init_session_frames(AVCodecContext *avctx, 
mfxSession *psession,
 int ret;
 
 ret = ff_qsv_init_session_device(avctx, ,
- frames_ctx->device_ref, load_plugins);
+ frames_ctx->device_ref, load_plugins, 
gpu_copy);
 if (ret < 0)
 return ret;
 
diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
index 394c558883..8be6c3757c 100644
--- a/libavcodec/qsv_internal.h
+++ b/libavcodec/qsv_internal.h
@@ -95,14 +95,14 @@ int ff_qsv_map_pixfmt(enum AVPixelFormat format, uint32_t 
*fourcc);
 enum AVPictureType ff_qsv_map_pictype(int mfx_pic_type);
 
 int ff_qsv_init_internal_session(AVCodecContext *avctx, mfxSession *session,
- const char *load_plugins);
+ const char *load_plugins, int gpu_copy);
 
 int ff_qsv_init_session_device(AVCodecContext *avctx, mfxSession *psession,
-   AVBufferRef *device_ref, const char 
*load_plugins);
+   AVBufferRef

Re: [FFmpeg-devel] [PATCH][FFmpeg-devel v2] Add GPU accelerated video crop filter

2019-03-25 Thread Song, Ruiling

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Timo Rothenpieler
> Sent: Monday, March 25, 2019 6:31 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH][FFmpeg-devel v2] Add GPU accelerated
> video crop filter
> 
> On 25/03/2019 09:27, Tao Zhang wrote:
> >>> Hi,
> >>>
> >>> Timo and Mark and I have been discussing this, and we think the right
> >>> thing to do is add support to vf_scale_cuda to respect the crop
> >>> properties on an input AVFrame. Mark posted a patch to vf_crop to
> >>> ensure that the properties are set, and then the scale filter should
> >>> respect those properties if they are set. You can look at
> >>> vf_scale_vaapi for how the properties are read, but they will require
> >>> explicit handling to adjust the src dimensions passed to the scale
> >>> filter.
> > Maybe a little not intuitive to users.
> >>>
> >>> This will be a more efficient way of handling crops, in terms of total
> >>> lines of code and also allowing crop/scale with one less copy.
> >>>
> >>> I know this is quite different from the approach you've taken here, and
> >>> we appreciate the work you've done, but it should be better overall to
> >>> implement this integrated method.
> >> Hi Philip,
> >>
> >> Glad to hear you guys had discussion on this. As I am also considering the
> problem, I have some questions about your idea.
> >> So, what if user did not insert a scale_cuda after crop filter? Do you 
> >> plan to
> automatically insert scale_cuda or just ignore the crop?
> >> What if user want to do crop,transpose_cuda,scale_cuda? So we also need
> to handle crop inside transpose_cuda filter?
>  >
> > I have the same question.
> Ideally, scale_cuda should be auto-inserted at the required places once
> it works that way.
> Otherwise it seems pointless to me if the user still has to manually
> insert it after the generic filters setting metadata.
Agree.

> 
> For that reason it should also still support getting its parameters
> passed directly as a fallback, and potentially even expose multiple
> filter names, so crop_cuda and transpose_cuda are still visible, but
> ultimately point to the same filter code.
> 
> We have a transpose_npp, right now, but with libnpp slowly being on its
> way out, transpose_cuda is needed, and ultimately even a format_cuda
> filter, since right now scale_npp is the only filter that can convert
> pixel formats on the hardware.
> I'd also like to see scale_cuda to support a few more interpolation
> algorithms, but that's not very important for now.
> 
> All this functionality can be in the same filter, which is scale_cuda.
> The point of that is that it avoids needless expensive frame copies as
> much as possible.

For crop/transpose, these are just some copy-like kernel. May be a good idea to 
merge with other kernels.
But I am not sure how much overall performance gain we would get for a 
transcoding pipeline. And merging all the things together may make code very 
complex.
For example, a crop+scale or crop+transpose may be easy to merge. But a 
crop+transpose+scale or crop+transpose+scale+format will be more complex.

I want to share some of my experience on developing opencl scale filter( 
https://patchwork.ffmpeg.org/patch/11910/ ).
I tried to merge scale and format-convert in one single OpenCL kernel.
But I failed to make the code clean after supporting interpolation method like 
bicubic, so I plan to separate them in two kernels these days.

And my experiments on scale_opencl show that merging scale with format-convert 
may not always get benefit.
For example, for 1080p scale-down, merging these two operations together is 
about 10% faster (for decode+scale), but for 4K input, merging two kernels make 
it slower.
My guess is different planes may compete the limited GPU cache. For scale-only, 
we can do it plane by plane, but for format-convert you have to read all the 
input planes and write all output planes at the same time.
This is just my guess, I have not root-caused what is the real reason. But I 
think keeping scale and format-convert in separate kernel function seems better.

I am also thinking about this issue other way, whether it is possible that we 
simple do the needed copy in crop/transpose and try to optimize off one filter 
if they are neighbors and pass the options to the other when configuring the 
filter pipeline?
Definitely I am really interested to see the work you described happen in 
FFmpeg.

Thanks!
Ruiling
___
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] lavc/qsvenc: expose low_power option in H264 QSV

2019-03-25 Thread Li, Zhong

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Monday, March 25, 2019 9:32 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [FFmpeg-devel] [PATCH] lavc/qsvenc: expose low_power option in
> H264 QSV
> 
> Always exposes low_power option for h264 qsv, and reports a warning if
> VDENC is not supported with current version of MSDK.
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/qsvenc.c  | 11 ++-
>  libavcodec/qsvenc_h264.c |  2 --
>  2 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> 5aa020d47b..8264d0a413 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -495,9 +495,18 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
>  }
>  }
> 
> +if (q->low_power) {
>  #if QSV_HAVE_VDENC
> -q->param.mfx.LowPower   = q->low_power ?
> MFX_CODINGOPTION_ON : MFX_CODINGOPTION_OFF;
> +q->param.mfx.LowPower = MFX_CODINGOPTION_ON; #else
> +av_log(avctx, AV_LOG_WARNING, "The QSV VDENC option is "
> +"not supported with this MSDK
> version.\n");

VDEnc is driver and hardware scope should not be exposed in FFmpeg level. 
Lower power is easier for user to understand, and it is the option user set. So 
I believe the would be better to change the log to be
"low power mode is not supported ..."

> +q->low_power = 0;
> +q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
>  #endif
> +} else
> +q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;

The rest LGTM
___
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][FFmpeg-devel v2] Add GPU accelerated video crop filter

2019-03-25 Thread Tao Zhang

Timo Rothenpieler  于2019年3月25日周一 下午6:31写道：
>
> On 25/03/2019 09:27, Tao Zhang wrote:
> >>> Hi,
> >>>
> >>> Timo and Mark and I have been discussing this, and we think the right
> >>> thing to do is add support to vf_scale_cuda to respect the crop
> >>> properties on an input AVFrame. Mark posted a patch to vf_crop to
> >>> ensure that the properties are set, and then the scale filter should
> >>> respect those properties if they are set. You can look at
> >>> vf_scale_vaapi for how the properties are read, but they will require
> >>> explicit handling to adjust the src dimensions passed to the scale
> >>> filter.
> > Maybe a little not intuitive to users.
> >>>
> >>> This will be a more efficient way of handling crops, in terms of total
> >>> lines of code and also allowing crop/scale with one less copy.
> >>>
> >>> I know this is quite different from the approach you've taken here, and
> >>> we appreciate the work you've done, but it should be better overall to
> >>> implement this integrated method.
> >> Hi Philip,
> >>
> >> Glad to hear you guys had discussion on this. As I am also considering the 
> >> problem, I have some questions about your idea.
> >> So, what if user did not insert a scale_cuda after crop filter? Do you 
> >> plan to automatically insert scale_cuda or just ignore the crop?
> >> What if user want to do crop,transpose_cuda,scale_cuda? So we also need to 
> >> handle crop inside transpose_cuda filter?
>  >
> > I have the same question.
> Ideally, scale_cuda should be auto-inserted at the required places once
> it works that way.
> Otherwise it seems pointless to me if the user still has to manually
> insert it after the generic filters setting metadata.
>
> For that reason it should also still support getting its parameters
> passed directly as a fallback, and potentially even expose multiple
> filter names, so crop_cuda and transpose_cuda are still visible, but
> ultimately point to the same filter code.
>
> We have a transpose_npp, right now, but with libnpp slowly being on its
> way out, transpose_cuda is needed, and ultimately even a format_cuda
> filter, since right now scale_npp is the only filter that can convert
> pixel formats on the hardware.
> I'd also like to see scale_cuda to support a few more interpolation
> algorithms, but that's not very important for now.
>
> All this functionality can be in the same filter, which is scale_cuda.
> The point of that is that it avoids needless expensive frame copies as
> much as possible.
I think frame copy is very low cost on cuda. Maybe the better way is
to create common functions for cuda related repeat code, but keep
frame detailed filtering seperate.
For example, if someone want to do bilateral filter with cuda, just
need focus on the filtering itself. True, scale_cuda can crop, however
hard to do bilateral filtering currently.
Thank you all for the discussion. If I have wrong, feel free to point it out.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/matroskadec: disable parsing for AV1 streams

2019-03-25 Thread James Almer

Keyframes are signaled at the container level on Matroska/Webm files,
so bitstream parsing for that purpose is unnecessary.

Should speed up demuxing a bit.

Signed-off-by: James Almer 
---
 libavformat/matroskadec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 81e9bb9bff..491c4ddf35 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -2507,7 +2507,8 @@ static int matroska_parse_tracks(AVFormatContext *s)
   st->codecpar->width  * track->video.display_height * 
display_height_mul,
   255);
 }
-if (st->codecpar->codec_id != AV_CODEC_ID_HEVC)
+if (st->codecpar->codec_id != AV_CODEC_ID_HEVC &&
+st->codecpar->codec_id != AV_CODEC_ID_AV1)
 st->need_parsing = AVSTREAM_PARSE_HEADERS;
 
 if (track->default_duration) {
-- 
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".

[FFmpeg-devel] Patch request to timestamp.h for silencedetect filter

2019-03-25 Thread Allan Cady via ffmpeg-devel

 Noob here. I would like to suggest a simple change to libavutil\timestamp.h, 
that for me makes the difference between silencedetect being very useful, or 
not useful at all. If there is a better way to submit this, I'm happy to jump 
through proper hoops... this seems like a good place to start the process.

REQUESTED PATCH

The requested patch is to the function av_ts_make_time_string in 
ffmpeg_sources\ffmpeg\libavutil\timestamp.h:

Compare: (<) ffmpeg_sources\ffmpeg\libavutil\timestamp.h.orig (2617 bytes)
   with: (>) ffmpeg_sources\ffmpeg\libavutil\timestamp.h (2617 bytes)
68c68
<     else                      snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.6g", 
av_q2d(*tb) * ts);
---
>     else                      snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.3f", 
>av_q2d(*tb) * ts);

The original function:

/**
 * Fill the provided buffer with a string containing a timestamp time
 * representation.
 *
 * @param buf a buffer with size in bytes of at least AV_TS_MAX_STRING_SIZE
 * @param ts the timestamp to represent
 * @param tb the timebase of the timestamp
 * @return the buffer in input
 */
static inline char *av_ts_make_time_string(char *buf, int64_t ts, AVRational 
*tb)
{
    if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
    else                      snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.6g", 
av_q2d(*tb) * ts);
    return buf;
}

PROBLEM DESCRIPTION

The problem is with the format of the timestamp output, which is hardcoded in 
timestamp.h. The issue has been, for long audio files, as ffmpeg scans further 
into the file, the magnitude of the time offsets grows, and the output 
gradually loses decimal places off the right end, until eventually it's in 
whole seconds, which is not enough precision to be useful for me. Current code 
formats the output as "%.6g". Changing it to either "%.3f" or just "%f", 
ensures at least millisecond precision, which would serve my purposes.

EXAMPLE

For a sample scan on a file that's about 35 hours (126000 seconds) length:

$ /usr/bin/ffmpeg -i input.mp3 -filter_complex 
silencedetect=n=-30dB:d=3.5,ametadata=mode=print:file=silence-out.txt -f null -

NOTE: One might think, 35 hours is an unusually long audio file. That's true, 
but in fact it's the need to work with long files that brought me to ffmpeg for 
this. For smaller files, I often use Audacity, which works fine, but it's 
problematic to have to load entire large files into an Audacity project, so I 
went looking for a command line option. So anyway...

The output goes from this near the beginning:

frame:83085 pts:47856431 pts_time:2170.36
lavfi.silence_start=2166.86
frame:83139 pts:47887535 pts_time:2171.77
lavfi.silence_end=2171.77
lavfi.silence_duration=4.91061

to this somewhere in the middle:

frame:2450348 pts:1411399919 pts_time:64009.1
lavfi.silence_start=64005.6
frame:2450371 pts:1411413167 pts_time:64009.7
lavfi.silence_end=64009.7
lavfi.silence_duration=4.10082

to eventually this after it passes 10 seconds:

frame:4738029 pts:2729104175 pts_time:123769
lavfi.silence_start=123765
frame:4738055 pts:2729119151 pts_time:123770
lavfi.silence_end=123770
lavfi.silence_duration=4.17918

As you can see, the start and end are eventually limited to whole-number 
precision, which is not sufficient for my needs. And it doesn't make sense 
logically to reduce precision for large numbers anyway; I can't think of a use 
where this would be desirable.

After making the above patch and building the code myself, I now get this 
output near the end:

frame:4738029 pts:2729104175 pts_time:123768.897
lavfi.silence_start=123765.411
frame:4738055 pts:2729119151 pts_time:123769.576
lavfi.silence_end=123769.584
lavfi.silence_duration=4.173

This gives me the output I want.

I haven't attempted to find if this routine is used elsewhere or if it might 
have undesirable results. If there is further effort you would like me to make 
before you will consider the change, please let me know and I can see what I 
can do.

Thank you,

Allan Cady
Seattle WA
___
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/flvdec: added support for KUX container

2019-03-25 Thread Carl Eugen Hoyos

2019-03-19 18:11 GMT+01:00, swarajhota...@gmail.com :
> From: Swaraj Hota 
>
> Fixes ticket #4519.

I will push this if there are no objections.

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] [PATCH] swscale: Remove duplicated code

2019-03-25 Thread Michael Niedermayer

On Mon, Mar 25, 2019 at 12:36:24PM +0100, Hendrik Leppkes wrote:
> On Mon, Mar 25, 2019 at 11:35 AM Lauri Kasanen  wrote:
> >
> > On Mon, 25 Mar 2019 11:17:38 +0100
> > Michael Niedermayer  wrote:
> >
> > > On Sun, Mar 24, 2019 at 01:04:51PM +0200, Lauri Kasanen wrote:
> > > > In this function, the exact same clamping happens both in the if and 
> > > > unconditionally.
> > > >
> > > > Signed-off-by: Lauri Kasanen 
> > > > ---
> > > >  libswscale/output.c | 14 --
> > > >  1 file changed, 14 deletions(-)
> > >
> > > The removed code is the one that should stay, the other should be
> > > removed.
> > > one check for a rarely true condition should be faster than 4 checks
> >
> > Yes, I thought so too, but the commit that added the unconditional code
> > says it fixes a bug...
> >
> 
> Could it overflow so high that other bits then the one being checked
> for are set? 

in realistic cases this should not happen. It may be possible
to construct a case with crafted scale parameters where this happens


> Perhaps another bit pattern with more high bits set would
> solve that.

yes, actually i thought we did use a different pattern ...

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Observe your enemies, for they first find out your faults. -- Antisthenes


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale: Remove duplicated code

2019-03-25 Thread Michael Niedermayer

On Mon, Mar 25, 2019 at 12:37:37PM +0200, Lauri Kasanen wrote:
> On Mon, 25 Mar 2019 11:17:38 +0100
> Michael Niedermayer  wrote:
> 
> > On Sun, Mar 24, 2019 at 01:04:51PM +0200, Lauri Kasanen wrote:
> > > In this function, the exact same clamping happens both in the if and 
> > > unconditionally.
> > >
> > > Signed-off-by: Lauri Kasanen 
> > > ---
> > >  libswscale/output.c | 14 --
> > >  1 file changed, 14 deletions(-)
> >
> > The removed code is the one that should stay, the other should be
> > removed.
> > one check for a rarely true condition should be faster than 4 checks
> 
> Yes, I thought so too, but the commit that added the unconditional code
> says it fixes a bug...

yes, but its parent did not had the other cliping code, it should have
been a bugfix only as long as the other code wasnt there

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4] avformat/http, icecast, rtsp: Add option to disable send-100-continue

2019-03-25 Thread Jun Li

On Fri, Mar 22, 2019 at 4:12 PM Jun Li  wrote:

> The current setting for send-100-continue option is either
> enabled if applicable or forced enabled, no option to force
> disable the header. This change is to expand the option setting
> to provide more flexibility, which is useful for rstp case.
> ---
>  libavformat/http.c| 28 +---
>  libavformat/icecast.c |  2 +-
>  libavformat/rtsp.c|  1 +
>  3 files changed, 19 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 74d743850d..5a937994cf 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -113,6 +113,7 @@ typedef struct HTTPContext {
>  uint8_t *inflate_buffer;
>  #endif /* CONFIG_ZLIB */
>  AVDictionary *chained_options;
> +/* -1 = try to send if applicable, 0 = always disabled, 1 = always
> enabled */
>  int send_expect_100;
>  char *method;
>  int reconnect;
> @@ -155,7 +156,7 @@ static const AVOption options[] = {
>  { "auth_type", "HTTP authentication type",
> OFFSET(auth_state.auth_type), AV_OPT_TYPE_INT, { .i64 = HTTP_AUTH_NONE },
> HTTP_AUTH_NONE, HTTP_AUTH_BASIC, D | E, "auth_type"},
>  { "none", "No auth method set, autodetect", 0, AV_OPT_TYPE_CONST, {
> .i64 = HTTP_AUTH_NONE }, 0, 0, D | E, "auth_type"},
>  { "basic", "HTTP basic authentication", 0, AV_OPT_TYPE_CONST, { .i64
> = HTTP_AUTH_BASIC }, 0, 0, D | E, "auth_type"},
> -{ "send_expect_100", "Force sending an Expect: 100-continue header
> for POST", OFFSET(send_expect_100), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E
> },
> +{ "send_expect_100", "Force sending an Expect: 100-continue header
> for POST", OFFSET(send_expect_100), AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1,
> E },
>  { "location", "The actual location of the data received",
> OFFSET(location), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, D | E },
>  { "offset", "initial byte offset", OFFSET(off), AV_OPT_TYPE_INT64, {
> .i64 = 0 }, 0, INT64_MAX, D },
>  { "end_offset", "try to limit the request to bytes preceding this
> offset", OFFSET(end_off), AV_OPT_TYPE_INT64, { .i64 = 0 }, 0, INT64_MAX, D
> },
> @@ -1179,16 +1180,21 @@ static int http_connect(URLContext *h, const char
> *path, const char *local_path,
>  local_path, method);
>  proxyauthstr = ff_http_auth_create_response(>proxy_auth_state,
> proxyauth,
>  local_path, method);
> -if (post && !s->post_data) {
> -send_expect_100 = s->send_expect_100;
> -/* The user has supplied authentication but we don't know the
> auth type,
> - * send Expect: 100-continue to get the 401 response including the
> - * WWW-Authenticate header, or an 100 continue if no auth actually
> - * is needed. */
> -if (auth && *auth &&
> -s->auth_state.auth_type == HTTP_AUTH_NONE &&
> -s->http_code != 401)
> -send_expect_100 = 1;
> +
> + if (post && !s->post_data) {
> +if (s->send_expect_100 != -1) {
> +send_expect_100 = s->send_expect_100;
> +} else {
> +send_expect_100 = 0;
> +/* The user has supplied authentication but we don't know the
> auth type,
> + * send Expect: 100-continue to get the 401 response
> including the
> + * WWW-Authenticate header, or an 100 continue if no auth
> actually
> + * is needed. */
> +if (auth && *auth &&
> +s->auth_state.auth_type == HTTP_AUTH_NONE &&
> +s->http_code != 401)
> +send_expect_100 = 1;
> +}
>  }
>
>  #if FF_API_HTTP_USER_AGENT
> diff --git a/libavformat/icecast.c b/libavformat/icecast.c
> index c93b06b553..d2198b78ec 100644
> --- a/libavformat/icecast.c
> +++ b/libavformat/icecast.c
> @@ -115,7 +115,7 @@ static int icecast_open(URLContext *h, const char
> *uri, int flags)
>  av_dict_set(_dict, "auth_type", "basic", 0);
>  av_dict_set(_dict, "headers", headers, 0);
>  av_dict_set(_dict, "chunked_post", "0", 0);
> -av_dict_set(_dict, "send_expect_100", s->legacy_icecast ? "0" :
> "1", 0);
> +av_dict_set(_dict, "send_expect_100", s->legacy_icecast ? "-1" :
> "1", 0);
>  if (NOT_EMPTY(s->content_type))
>  av_dict_set(_dict, "content_type", s->content_type, 0);
>  else
> diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
> index ae8811234a..6e67e411b9 100644
> --- a/libavformat/rtsp.c
> +++ b/libavformat/rtsp.c
> @@ -1793,6 +1793,7 @@ redirect:
>   sessioncookie);
>  av_opt_set(rt->rtsp_hd_out->priv_data, "headers", headers, 0);
>  av_opt_set(rt->rtsp_hd_out->priv_data, "chunked_post", "0", 0);
> +av_opt_set(rt->rtsp_hd_out->priv_data, "send_expect_100", "0", 0);
>
>  /* Initialize the authentication state for the POST session. The
> HTTP
>   * protocol implementation doesn't properly

Re: [FFmpeg-devel] [PATCH] Use packet DTS to correct frame PTS for PTS missing video in nvidia cuvid decoder

2019-03-25 Thread Joonsik Baek

Could i get this reviewed?

This is about libavcodec/cuviddec.c

-Original Message-
From: "백준식" 
To: ; 
Cc: 
Sent: 2019-03-21 (목) 08:18:22 (GMT+09:00)
Subject: [PATCH] Use packet DTS to correct frame PTS for PTS missing video in 
nvidia cuvid decoder
 
- Current Status
In cuvid decoder wrapper, PTS is resolved based on input packet PTS.
When PTS is missing, cuvid decoder produces monotorically increasing numbers 
with same interval.
This does not occur problem when every single frame in video has same frame 
duration like fixed frame rate video.

- Problem
For variable frame rate video with missing PTS, however, resolving PTS based on 
monotorically increasing number with same interval do not reflect actual frame 
position in timedomain.
Test sample is AVI without PTS info, and has missing frames which means this is 
variable frame rate video. When cuvid decoder processes this video, various 
frame duration is ignored due to missing PTS. This directly leads to AV sync 
problem and a lot of frame duplication at end of video.

- Solution
To correct each frame duration, packet DTS is passed through 
cuvidParseVideoData() to resolve output frame duration.
Since passed packet DTS is not actual PTS, resolved value through 
CuvidParsedFrame is stored in frame->best_effort_timestamp like any other 
decoder wrapper.

Signed-off-by: JoonsikBaek 
---
 libavcodec/cuviddec.c | 36 +++-
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index 291bb93..c9f0ff1 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -81,6 +81,8 @@ typedef struct CuvidContext
     int internal_error;
     int decoder_flushing;
 
+    int use_best_effort_pts_from_dts;
+
     int *key_frame;
 
     cudaVideoCodec codec_type;
@@ -384,6 +386,7 @@ static int cuvid_decode_packet(AVCodecContext *avctx, const 
AVPacket *avpkt)
     AVPacket filter_packet = { 0 };
     AVPacket filtered_packet = { 0 };
     int ret = 0, eret = 0, is_flush = ctx->decoder_flushing;
+    int64_t timestamp = AV_NOPTS_VALUE;
 
     av_log(avctx, AV_LOG_TRACE, "cuvid_decode_packet\n");
 
@@ -426,11 +429,18 @@ static int cuvid_decode_packet(AVCodecContext *avctx, 
const AVPacket *avpkt)
         cupkt.payload = avpkt->data;
 
         if (avpkt->pts != AV_NOPTS_VALUE) {
+            timestamp = avpkt->pts;
+        } else if (avpkt->dts != AV_NOPTS_VALUE) {
+            ctx->use_best_effort_pts_from_dts = 1;
+            timestamp = avpkt->dts;
+        }
+
+        if (timestamp != AV_NOPTS_VALUE) {
             cupkt.flags = CUVID_PKT_TIMESTAMP;
             if (avctx->pkt_timebase.num && avctx->pkt_timebase.den)
-                cupkt.timestamp = av_rescale_q(avpkt->pts, 
avctx->pkt_timebase, (AVRational){1, 1000});
+                cupkt.timestamp = av_rescale_q(timestamp, avctx->pkt_timebase, 
(AVRational){1, 1000});
             else
-                cupkt.timestamp = avpkt->pts;
+                cupkt.timestamp = timestamp;
         }
     } else {
         cupkt.flags = CUVID_PKT_ENDOFSTREAM;
@@ -506,6 +516,7 @@ static int cuvid_output_frame(AVCodecContext *avctx, 
AVFrame *frame)
         unsigned int pitch = 0;
         int offset = 0;
         int i;
+        int64_t timestamp;
 
         av_fifo_generic_read(ctx->frame_queue, _frame, 
sizeof(CuvidParsedFrame), NULL);
 
@@ -610,22 +621,29 @@ static int cuvid_output_frame(AVCodecContext *avctx, 
AVFrame *frame)
         frame->key_frame = ctx->key_frame[parsed_frame.dispinfo.picture_index];
         frame->width = avctx->width;
         frame->height = avctx->height;
+
         if (avctx->pkt_timebase.num && avctx->pkt_timebase.den)
-            frame->pts = av_rescale_q(parsed_frame.dispinfo.timestamp, 
(AVRational){1, 1000}, avctx->pkt_timebase);
+            timestamp = av_rescale_q(parsed_frame.dispinfo.timestamp, 
(AVRational){1, 1000}, avctx->pkt_timebase);
         else
-            frame->pts = parsed_frame.dispinfo.timestamp;
+            timestamp = parsed_frame.dispinfo.timestamp;
 
         if (parsed_frame.second_field) {
             if (ctx->prev_pts == INT64_MIN) {
-                ctx->prev_pts = frame->pts;
-                frame->pts += (avctx->pkt_timebase.den * avctx->framerate.den) 
/ (avctx->pkt_timebase.num * avctx->framerate.num);
+                ctx->prev_pts = timestamp;
+                timestamp += (avctx->pkt_timebase.den * avctx->framerate.den) 
/ (avctx->pkt_timebase.num * avctx->framerate.num);
             } else {
-                int pts_diff = (frame->pts - ctx->prev_pts) / 2;
-                ctx->prev_pts = frame->pts;
-                frame->pts += pts_diff;
+                int pts_diff = (timestamp - ctx->prev_pts) / 2;
+                ctx->prev_pts = timestamp;
+                timestamp += pts_diff;
             }
         }
 
+        if(ctx->use_best_effort_pts_from_dts) {
+            frame->best_effort_timestamp = timestamp;
+        } else

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

2019-03-25 Thread Moritz Barsnick

On Mon, Mar 25, 2019 at 18:51:15 +0100, Nicolas George wrote:
> Yufei He (12019-03-25):
> > Yes, it's part of the installation for the driver of the card. People
> > who have the card will install it.
> Why does it have "ffmpeg" in its name? It looks like deliberate
> circumvention; if it is, then no, thanks.

In other words: Kindly make the library's code part of your patch for
ffmpeg (with a liberal license), and then things start to look different.

Or release the library under such a license as open source.

Yes, it's really that easy. ;-) (Almost)

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 v2] avcodec: add AV1 frame split bitstream filter

2019-03-25 Thread James Almer

On 3/25/2019 4:30 PM, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Mar 25, 2019 at 12:42 PM James Almer  wrote:
> 
>> On 3/25/2019 12:29 PM, James Almer wrote:
>>> +ret = ff_cbs_read_packet(s->cbc, td, s->buffer_pkt);
>>> +if (ret < 0) {
>>> +av_log(ctx, AV_LOG_ERROR, "Failed to parse temporal
>> unit.\n");
>>> +return ret;
>>
>>> +if (split) {
>>> +AV1RawFrameHeader *frame = NULL;
>>> +int cur_frame_type = -1, size = 0;
>>> +
>>> +for (i = s->cur_frame_idx; i < td->nb_units; i++) {
>>> +CodedBitstreamUnit *unit = >units[i];
>>> +
>>> +size += unit->data_size;
>>> +if (unit->type == AV1_OBU_FRAME) {
>>> +AV1RawOBU *obu = unit->content;
>>> +
>>> +if (frame) {
>>> +ret = AVERROR_INVALIDDATA;
>>> +goto fail;
>>
>>> +} else if (unit->type == AV1_OBU_FRAME_HEADER) {
>>> +AV1RawOBU *obu = unit->content;
>>> +
>>> +if (frame) {
>>> +ret = AVERROR_INVALIDDATA;
>>> +goto fail;
>>
>>> +} else if (unit->type == AV1_OBU_TILE_GROUP) {
>>> +AV1RawOBU *obu = unit->content;
>>> +AV1RawTileGroup *group = >obu.tile_group;
>>> +
>>> +if (!frame || cur_frame_type != AV1_OBU_FRAME_HEADER) {
>>> +ret = AVERROR_INVALIDDATA;
>>> +goto fail;
>>
>> I'm not sure if we should abort and discard the packet in these cases,
>> or just pass it through.
>>
>> In all these the Temporal Unit is invalid in some form (Orphaned Tile
>> Group OBUs, Frame Headers showing up when the Tile Groups from a
>> previous Frame Header were expected, etc), but maybe it should be left
>> to the decoder to decide what to do with them.
> 
> 
> Is cur_frame_type the previous OBU's type?

cur_frame_type is set to either Frame or Frame Header based on the last
of such OBU type seen, and checked when parsing a Tile Group OBU in
order to abort if it was not a Frame Header (Tile Group OBUs must come
after a Frame Header OBU).

I only added it because in the case where i want to include all the
trailing OBUs when the last frame is the Frame OBU kind, if one of said
trailing OBUs is an orphaned Tile Group then it means the TU is broken.

> Is something like framehdr-highdynamicrangframedata-tiledata valid?

I don't know. The spec says:

"A coded video sequence consists of one or more temporal units. A
temporal unit consists of a series of OBUs starting from a temporal
delimiter, optional sequence headers, optional metadata OBUs, a sequence
of one or more frame headers, each followed by zero or more tile group
OBUs as well as optional padding OBUs."

It would seem it's not valid or at least not expected, but nothing in
practice should prevent decoding with such ordering.
It doesn't seem to be too strict about what's meant to be after a Frame
Header other than its Tile Groups (The sentence is lacking the usual
must/shall/should wording), but either way this bsf will handle that
just fine. It makes sure to split starting from a Frame Header all the
way to last Tile Group for the frame, including everything in between,
and everything after if it's the last frame. It doesn't do any reordering.
___
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] lavd/v4l2: Return FFERROR_REDO when receiving a frame of unexpected size

2019-03-25 Thread Stephan Hilb

Alexander Strasser wrote on 21.03.2019 at 23:34:

> 3. Return zero-sized packets => This works and is consistent with how
>we handle frames flagged to be corrupted (V4L2_BUF_FLAG_ERROR).
>See commit 28f20d2ff487aa589643d8f70eaf614b78839685 .

I posted a patch for this on Sat, 25 Aug 2018. It seems to have been
forgotten, attached again.
From 0af8515acca4d598570d03450656adc0ed7ac2d7 Mon Sep 17 00:00:00 2001
From: Stephan Hilb 
Date: Sun, 10 Jun 2018 21:07:52 +0200
Subject: [PATCH] lavd/v4l2: skip buffers not matching frame_size

By adopting the same behaviour as if there was corrupted data in the
buffer (see the check for V4L2_BUF_FLAG_ERROR) the resulting rawvideo
now at least contains valid data (the previous frame being duplicated).
Fixes video capturing for some stk1160 devices.
---
 libavdevice/v4l2.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
index 10a0ff0dd6..ab903bbcee 100644
--- a/libavdevice/v4l2.c
+++ b/libavdevice/v4l2.c
@@ -534,11 +534,10 @@ static int mmap_read_frame(AVFormatContext *ctx, AVPacket *pkt)
 s->frame_size = buf.bytesused;
 
 if (s->frame_size > 0 && buf.bytesused != s->frame_size) {
-av_log(ctx, AV_LOG_ERROR,
+av_log(ctx, AV_LOG_WARNING,
"Dequeued v4l2 buffer contains %d bytes, but %d were expected. Flags: 0x%08X.\n",
buf.bytesused, s->frame_size, buf.flags);
-enqueue_buffer(s, );
-return AVERROR_INVALIDDATA;
+buf.bytesused = 0;
 }
 }
 
-- 
2.18.0



pgpNOj7I3nYx7.pgp
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avcodec: add AV1 frame split bitstream filter

2019-03-25 Thread Ronald S. Bultje

Hi,

On Mon, Mar 25, 2019 at 12:42 PM James Almer  wrote:

> On 3/25/2019 12:29 PM, James Almer wrote:
> > +ret = ff_cbs_read_packet(s->cbc, td, s->buffer_pkt);
> > +if (ret < 0) {
> > +av_log(ctx, AV_LOG_ERROR, "Failed to parse temporal
> unit.\n");
> > +return ret;
>
> > +if (split) {
> > +AV1RawFrameHeader *frame = NULL;
> > +int cur_frame_type = -1, size = 0;
> > +
> > +for (i = s->cur_frame_idx; i < td->nb_units; i++) {
> > +CodedBitstreamUnit *unit = >units[i];
> > +
> > +size += unit->data_size;
> > +if (unit->type == AV1_OBU_FRAME) {
> > +AV1RawOBU *obu = unit->content;
> > +
> > +if (frame) {
> > +ret = AVERROR_INVALIDDATA;
> > +goto fail;
>
> > +} else if (unit->type == AV1_OBU_FRAME_HEADER) {
> > +AV1RawOBU *obu = unit->content;
> > +
> > +if (frame) {
> > +ret = AVERROR_INVALIDDATA;
> > +goto fail;
>
> > +} else if (unit->type == AV1_OBU_TILE_GROUP) {
> > +AV1RawOBU *obu = unit->content;
> > +AV1RawTileGroup *group = >obu.tile_group;
> > +
> > +if (!frame || cur_frame_type != AV1_OBU_FRAME_HEADER) {
> > +ret = AVERROR_INVALIDDATA;
> > +goto fail;
>
> I'm not sure if we should abort and discard the packet in these cases,
> or just pass it through.
>
> In all these the Temporal Unit is invalid in some form (Orphaned Tile
> Group OBUs, Frame Headers showing up when the Tile Groups from a
> previous Frame Header were expected, etc), but maybe it should be left
> to the decoder to decide what to do with them.


Is cur_frame_type the previous OBU's type? Is something like
framehdr-highdynamicrangframedata-tiledata valid?

Ronald
___
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] News: Removal of libndi

2019-03-25 Thread Nicolas George

Yufei He (12019-03-25):
> Yes, it's part of the installation for the driver of the card. People 
> who have the card will install it.

Why does it have "ffmpeg" in its name? It looks like deliberate
circumvention; if it is, then no, thanks.

> On 03/25/2019 01:04 PM, Jean-Baptiste Kempf wrote:

Please remember that top-posting is not accepted on this list. If you
forgot what it means, look it up.

Regards,

-- 
  Nicolas George

signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

2019-03-25 Thread Yufei He

Yes, it's part of the installation for the driver of the card. People 
who have the card will install it.

Thanks.

Yufei

On 03/25/2019 01:04 PM, Jean-Baptiste Kempf wrote:
> On Mon, 25 Mar 2019, at 14:02, Yufei He wrote:
>> Matrox card is very similar to cards from other companies in terms of
>> accesses.
> Then why do you have this specific libmvM264Ffmpeg library?
> What is it? Is it part of the driver? Is it installed at the same time as the 
> driver?
>
___
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] News: Removal of libndi

2019-03-25 Thread Jean-Baptiste Kempf

On Mon, 25 Mar 2019, at 14:02, Yufei He wrote:
> Matrox card is very similar to cards from other companies in terms of 
> accesses.

Then why do you have this specific libmvM264Ffmpeg library?
What is it? Is it part of the driver? Is it installed at the same time as the 
driver?

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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] News: Removal of libndi

2019-03-25 Thread Jean-Baptiste Kempf

On Mon, 25 Mar 2019, at 08:32, Tobias Rapp wrote:
> > Most of those hardware libraries are glorified ioctls around the driver and 
> > shipped with the drivers.
> > And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ 
> > interface, set param" there, release the C++ interface).
> > 
> > Matrox seems to do something else, though, introducing a special library 
> > for FFmpeg consumption, and I doubt that feels like a driver...
> 
> The GPL is mentioned a lot in this thread. Maybe it would make sense to 
> distinguish the two cases where FFmpeg is compiled with --enable-gpl and 
> without it -- as the LGPL applies in that case.

That does not change a thing, sorry.
The section 6 of the LGPLv2.1 is similar to the section 3 of the GPL, and 
mentions exactly the same limitations and exceptions for major components of 
the OS.

The fact that you can combine the library with a 3rd party library inside your 
program does not allow you to ship non-LGPL-compatible code inside the library. 
(The library must be changeable + redistributable by the user).

I know that means that you can do more or less the same feature, but that means 
the architecture must be different.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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] avcodec: add AV1 frame split bitstream filter

2019-03-25 Thread James Almer

On 3/25/2019 12:29 PM, James Almer wrote:
> +ret = ff_cbs_read_packet(s->cbc, td, s->buffer_pkt);
> +if (ret < 0) {
> +av_log(ctx, AV_LOG_ERROR, "Failed to parse temporal unit.\n");
> +return ret;

> +if (split) {
> +AV1RawFrameHeader *frame = NULL;
> +int cur_frame_type = -1, size = 0;
> +
> +for (i = s->cur_frame_idx; i < td->nb_units; i++) {
> +CodedBitstreamUnit *unit = >units[i];
> +
> +size += unit->data_size;
> +if (unit->type == AV1_OBU_FRAME) {
> +AV1RawOBU *obu = unit->content;
> +
> +if (frame) {
> +ret = AVERROR_INVALIDDATA;
> +goto fail;

> +} else if (unit->type == AV1_OBU_FRAME_HEADER) {
> +AV1RawOBU *obu = unit->content;
> +
> +if (frame) {
> +ret = AVERROR_INVALIDDATA;
> +goto fail;

> +} else if (unit->type == AV1_OBU_TILE_GROUP) {
> +AV1RawOBU *obu = unit->content;
> +AV1RawTileGroup *group = >obu.tile_group;
> +
> +if (!frame || cur_frame_type != AV1_OBU_FRAME_HEADER) {
> +ret = AVERROR_INVALIDDATA;
> +goto fail;

I'm not sure if we should abort and discard the packet in these cases,
or just pass it through.

In all these the Temporal Unit is invalid in some form (Orphaned Tile
Group OBUs, Frame Headers showing up when the Tile Groups from a
previous Frame Header were expected, etc), but maybe it should be left
to the decoder to decide what to do with them.

> +fail:
> +if (ret < 0)
> +av_packet_unref(out);
> +av_packet_unref(s->buffer_pkt);
> +ff_cbs_fragment_reset(s->cbc, td);
> +
> +return ret;
> +}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/cinepak: check the first slice against the input size before obtaining a frame

2019-03-25 Thread Michael Niedermayer

Fixes: Timeout (16sec -> 0.5sec)
Fixes: 
13854/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CINEPAK_fuzzer-5641061185093632

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/cinepak.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/libavcodec/cinepak.c b/libavcodec/cinepak.c
index 9b0077402f..18ec19f08d 100644
--- a/libavcodec/cinepak.c
+++ b/libavcodec/cinepak.c
@@ -319,6 +319,9 @@ static int cinepak_predecode_check (CinepakContext *s)
 {
 int   num_strips;
 int   encoded_buf_size;
+int   i;
+const uint8_t *data = s->data;
+const uint8_t  *eod = s->data + s->size;
 
 num_strips  = AV_RB16 (>data[8]);
 encoded_buf_size = AV_RB24(>data[1]);
@@ -353,6 +356,17 @@ static int cinepak_predecode_check (CinepakContext *s)
 if (s->size < 10 + s->sega_film_skip_bytes + num_strips * 12)
 return AVERROR_INVALIDDATA;
 
+data += 10 + s->sega_film_skip_bytes;
+
+for (i=0; i < FFMIN(num_strips, 1); i++) {
+int strip_size = AV_RB24 ([1]);
+if (strip_size < 12 || eod - data < strip_size - strip_size * 
(int64_t)s->avctx->discard_damaged_percentage / 100)
+return AVERROR_INVALIDDATA;
+if (eod - data < strip_size)
+break;
+data += strip_size;
+}
+
 return 0;
 }
 
-- 
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] [PATCHv3] FATE: Add test for HEVC files that claim to have two first slices

2019-03-25 Thread Derek Buitenhuis

On 21/03/2019 21:30, Michael Niedermayer wrote:
> about this specific file, 
> derek should have write access to samples as well

I actually don't remember the specifics / servers / etc...

- 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".

[FFmpeg-devel] [PATCH v2] avcodec: add AV1 frame split bitstream filter

2019-03-25 Thread James Almer

This will be needed by the eventual native AV1 decoder.

Signed-off-by: James Almer 
---
Updated after recent changes to the CBS fragment handling API.

 configure|   1 +
 libavcodec/Makefile  |   1 +
 libavcodec/av1_frame_split_bsf.c | 248 +++
 libavcodec/bitstream_filters.c   |   1 +
 4 files changed, 251 insertions(+)
 create mode 100644 libavcodec/av1_frame_split_bsf.c

diff --git a/configure b/configure
index 331393f8d5..ed33490797 100755
--- a/configure
+++ b/configure
@@ -3076,6 +3076,7 @@ vc1_parser_select="vc1dsp"

 # bitstream_filters
 aac_adtstoasc_bsf_select="adts_header"
+av1_frame_split_select="cbs_av1"
 av1_metadata_bsf_select="cbs_av1"
 eac3_core_bsf_select="ac3_parser"
 filter_units_bsf_select="cbs"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 15c43a8a6a..27f326247d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1065,6 +1065,7 @@ OBJS-$(CONFIG_XMA_PARSER)  += xma_parser.o
 # bitstream filters
 OBJS-$(CONFIG_AAC_ADTSTOASC_BSF)  += aac_adtstoasc_bsf.o mpeg4audio.o
 OBJS-$(CONFIG_AV1_METADATA_BSF)   += av1_metadata_bsf.o
+OBJS-$(CONFIG_AV1_FRAME_SPLIT_BSF)+= av1_frame_split_bsf.o
 OBJS-$(CONFIG_CHOMP_BSF)  += chomp_bsf.o
 OBJS-$(CONFIG_DUMP_EXTRADATA_BSF) += dump_extradata_bsf.o
 OBJS-$(CONFIG_DCA_CORE_BSF)   += dca_core_bsf.o
diff --git a/libavcodec/av1_frame_split_bsf.c b/libavcodec/av1_frame_split_bsf.c
new file mode 100644
index 00..2ff58e464f
--- /dev/null
+++ b/libavcodec/av1_frame_split_bsf.c
@@ -0,0 +1,246 @@
+/*
+ * 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
+ * This bitstream filter splits AV1 Temporal Units into packets containing
+ * just one frame.
+ */
+
+#include "libavutil/avassert.h"
+
+#include "avcodec.h"
+#include "bsf.h"
+#include "cbs.h"
+#include "cbs_av1.h"
+
+typedef struct AV1FSplitContext {
+AVPacket *buffer_pkt;
+CodedBitstreamContext *cbc;
+CodedBitstreamFragment temporal_unit;
+
+int nb_frames;
+int cur_frame;
+int cur_frame_idx;
+int last_frame_idx;
+} AV1FSplitContext;
+
+static int av1_frame_split_filter(AVBSFContext *ctx, AVPacket *out)
+{
+AV1FSplitContext *s = ctx->priv_data;
+CodedBitstreamFragment *td = >temporal_unit;
+int i, ret;
+int split = !!s->buffer_pkt->data;
+
+if (!s->buffer_pkt->data) {
+int nb_frames = 0;
+
+ret = ff_bsf_get_packet_ref(ctx, s->buffer_pkt);
+if (ret < 0)
+return ret;
+
+ret = ff_cbs_read_packet(s->cbc, td, s->buffer_pkt);
+if (ret < 0) {
+av_log(ctx, AV_LOG_ERROR, "Failed to parse temporal unit.\n");
+return ret;
+}
+
+for (i = 0; i < td->nb_units; i++) {
+CodedBitstreamUnit *unit = >units[i];
+
+if (unit->type == AV1_OBU_FRAME ||
+unit->type == AV1_OBU_FRAME_HEADER)
+nb_frames++;
+else if (unit->type == AV1_OBU_TILE_LIST) {
+av_log(ctx, AV_LOG_VERBOSE, "Large scale tiles are 
unsupported. Skipping Temporal Unit.\n");
+nb_frames = 0;
+break;
+}
+}
+if (nb_frames > 1) {
+s->cur_frame = 0;
+// Don't attach the Temporal Delimiter OBU with the first frame
+s->cur_frame_idx = s->last_frame_idx =
+td->units[0].type == AV1_OBU_TEMPORAL_DELIMITER;
+s->nb_frames = nb_frames;
+split = 1;
+}
+}
+
+if (split) {
+AV1RawFrameHeader *frame = NULL;
+int cur_frame_type = -1, size = 0;
+
+for (i = s->cur_frame_idx; i < td->nb_units; i++) {
+CodedBitstreamUnit *unit = >units[i];
+
+size += unit->data_size;
+if (unit->type == AV1_OBU_FRAME) {
+AV1RawOBU *obu = unit->content;
+
+if (frame) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
+frame = >obu.frame.header;
+cur_frame_type = obu->header.obu_type;
+s->last_frame_idx = s->cur_frame_idx;
+s->cur_frame_idx  = i +

[FFmpeg-devel] [PATCH 1/3] avcodec/cbs_av1: add support for Padding OBUs

2019-03-25 Thread James Almer

Based on itut_t35 Matadata OBU parsing code.

Signed-off-by: James Almer 
---
 libavcodec/cbs_av1.c | 20 +
 libavcodec/cbs_av1.h |  7 ++
 libavcodec/cbs_av1_syntax_template.c | 32 
 3 files changed, 59 insertions(+)

diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index 02f168b58d..22330eabf3 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -857,6 +857,11 @@ static void cbs_av1_free_tile_data(AV1RawTileData *td)
 av_buffer_unref(>data_ref);
 }
 
+static void cbs_av1_free_padding(AV1RawPadding *pd)
+{
+av_buffer_unref(>payload_ref);
+}
+
 static void cbs_av1_free_metadata(AV1RawMetadata *md)
 {
 switch (md->metadata_type) {
@@ -883,6 +888,9 @@ static void cbs_av1_free_obu(void *unit, uint8_t *content)
 case AV1_OBU_METADATA:
 cbs_av1_free_metadata(>obu.metadata);
 break;
+case AV1_OBU_PADDING:
+cbs_av1_free_padding(>obu.padding);
+break;
 }
 
 av_freep();
@@ -1057,6 +1065,12 @@ static int cbs_av1_read_unit(CodedBitstreamContext *ctx,
 }
 break;
 case AV1_OBU_PADDING:
+{
+err = cbs_av1_read_padding(ctx, , >obu.padding);
+if (err < 0)
+return err;
+}
+break;
 default:
 return AVERROR(ENOSYS);
 }
@@ -1182,6 +1196,12 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
 }
 break;
 case AV1_OBU_PADDING:
+{
+err = cbs_av1_write_padding(ctx, pbc, >obu.padding);
+if (err < 0)
+return err;
+}
+break;
 default:
 return AVERROR(ENOSYS);
 }
diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
index 71ceff9427..e799964b72 100644
--- a/libavcodec/cbs_av1.h
+++ b/libavcodec/cbs_av1.h
@@ -364,6 +364,12 @@ typedef struct AV1RawMetadata {
 } metadata;
 } AV1RawMetadata;
 
+typedef struct AV1RawPadding {
+uint8_t *payload;
+size_t   payload_size;
+AVBufferRef *payload_ref;
+} AV1RawPadding;
+
 
 typedef struct AV1RawOBU {
 AV1RawOBUHeader header;
@@ -377,6 +383,7 @@ typedef struct AV1RawOBU {
 AV1RawTileGroup  tile_group;
 AV1RawTileList   tile_list;
 AV1RawMetadata   metadata;
+AV1RawPaddingpadding;
 } obu;
 } AV1RawOBU;
 
diff --git a/libavcodec/cbs_av1_syntax_template.c 
b/libavcodec/cbs_av1_syntax_template.c
index 76eb90b279..a6cafdd99f 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -1763,3 +1763,35 @@ static int FUNC(metadata_obu)(CodedBitstreamContext 
*ctx, RWContext *rw,
 
 return 0;
 }
+
+static int FUNC(padding)(CodedBitstreamContext *ctx, RWContext *rw,
+ AV1RawPadding *current)
+{
+int i, err;
+
+HEADER("Padding");
+
+#ifdef READ
+// The payload runs up to the start of the trailing bits, but there might
+// be arbitrarily many trailing zeroes so we need to read through twice.
+{
+GetBitContext tmp = *rw;
+current->payload_size = 0;
+for (i = 0; get_bits_left(rw) >= 8; i++) {
+if (get_bits(rw, 8))
+current->payload_size = i;
+}
+*rw = tmp;
+
+current->payload_ref = av_buffer_alloc(current->payload_size);
+if (!current->payload_ref)
+return AVERROR(ENOMEM);
+current->payload = current->payload_ref->data;
+}
+#endif
+
+for (i = 0; i < current->payload_size; i++)
+xf(8, obu_padding_byte[i], current->payload[i], 0x00, 0xff, 1, i);
+
+return 0;
+}
-- 
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/cbs_av1: fix range of values for Mastering Display Color Volume Metadata OBUs

2019-03-25 Thread James Almer

On 3/23/2019 2:30 PM, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>> Does something like
>> FFMIN(((uint64_t)current->luminance_max << 6) - 1, MAX_UINT_BITS(32))
>> do the right thing?
> 
> Yes. Fixed and a comment added.
> 
>  libavcodec/cbs_av1_syntax_template.c | 13 -
>  1 file changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/cbs_av1_syntax_template.c 
> b/libavcodec/cbs_av1_syntax_template.c
> index 48f4fab514..76eb90b279 100644
> --- a/libavcodec/cbs_av1_syntax_template.c
> +++ b/libavcodec/cbs_av1_syntax_template.c
> @@ -1637,15 +1637,18 @@ static int 
> FUNC(metadata_hdr_mdcv)(CodedBitstreamContext *ctx, RWContext *rw,
>  int err, i;
>  
>  for (i = 0; i < 3; i++) {
> -fcs(16, primary_chromaticity_x[i], 0, 5, 1, i);
> -fcs(16, primary_chromaticity_y[i], 0, 5, 1, i);
> +fbs(16, primary_chromaticity_x[i], 1, i);
> +fbs(16, primary_chromaticity_y[i], 1, i);
>  }
>  
> -fc(16, white_point_chromaticity_x, 0, 5);
> -fc(16, white_point_chromaticity_y, 0, 5);
> +fb(16, white_point_chromaticity_x);
> +fb(16, white_point_chromaticity_y);
>  
>  fc(32, luminance_max, 1, MAX_UINT_BITS(32));
> -fc(32, luminance_min, 0, current->luminance_max >> 6);
> +// luminance_min must be lower than luminance_max. Convert luminance_max 
> from
> +// 24.8 fixed point to 18.14 fixed point in order to compare them.
> +fc(32, luminance_min, 0, FFMIN(((uint64_t)current->luminance_max << 6) - 
> 1,
> +   MAX_UINT_BITS(32)));
>  
>  return 0;
>  }

Pushed.
___
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 2/3] avcodec/av1_metadata: add an option to remove Padding OBUs

2019-03-25 Thread James Almer

Signed-off-by: James Almer 
---
 libavcodec/av1_metadata_bsf.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
index 2b74b697e4..fe208feaf5 100644
--- a/libavcodec/av1_metadata_bsf.c
+++ b/libavcodec/av1_metadata_bsf.c
@@ -46,6 +46,8 @@ typedef struct AV1MetadataContext {
 
 AVRational tick_rate;
 int num_ticks_per_picture;
+
+int delete_padding;
 } AV1MetadataContext;
 
 
@@ -158,6 +160,19 @@ static int av1_metadata_filter(AVBSFContext *bsf, AVPacket 
*out)
 }
 }
 
+if (ctx->delete_padding) {
+for (i = 0; i < frag->nb_units; i++) {
+if (frag->units[i].type == AV1_OBU_PADDING) {
+err = ff_cbs_delete_unit(ctx->cbc, frag, i);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to delete Padding 
OBU.\n");
+goto fail;
+}
+--i;
+}
+}
+}
+
 err = ff_cbs_write_packet(ctx->cbc, out, frag);
 if (err < 0) {
 av_log(bsf, AV_LOG_ERROR, "Failed to write packet.\n");
@@ -275,6 +290,10 @@ static const AVOption av1_metadata_options[] = {
 OFFSET(num_ticks_per_picture), AV_OPT_TYPE_INT,
 { .i64 = -1 }, -1, INT_MAX, FLAGS },
 
+{ "delete_padding", "Delete all Padding OBUs",
+OFFSET(delete_padding), AV_OPT_TYPE_BOOL,
+{ .i64 = 0 }, 0, 1, FLAGS},
+
 { NULL }
 };
 
-- 
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".

[FFmpeg-devel] [PATCH 3/3] avcodec/cbs_av1: fix parsing spatial_id

2019-03-25 Thread James Almer

Signed-off-by: James Almer 
---
 libavcodec/cbs_av1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index 22330eabf3..77548084b6 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -964,7 +964,7 @@ static int cbs_av1_read_unit(CodedBitstreamContext *ctx,
 
 if (obu->header.obu_extension_flag) {
 priv->temporal_id = obu->header.temporal_id;
-priv->spatial_id  = obu->header.temporal_id;
+priv->spatial_id  = obu->header.spatial_id;
 
 if (obu->header.obu_type != AV1_OBU_SEQUENCE_HEADER &&
 obu->header.obu_type != AV1_OBU_TEMPORAL_DELIMITER &&
-- 
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 1/2] avcodec/mpegpicture: Check size of edge_emu_buffer

2019-03-25 Thread Michael Niedermayer

On Mon, Mar 18, 2019 at 12:50:36AM +0100, Michael Niedermayer wrote:
> Fixes: OOM
> Fixes: 
> 13710/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MPEG4_fuzzer-5633152942342144
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mpegpicture.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

will apply patchset

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/jpeg2000dec: Skip de-quantization of empty areas

2019-03-25 Thread Michael Niedermayer

On Wed, Mar 20, 2019 at 01:02:36AM +0100, Michael Niedermayer wrote:
> Fixes: Timeout (26sec -> 18sec)
> Fixes: 
> 13448/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-576903098243481
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/jpeg2000dec.c | 2 ++
>  1 file changed, 2 insertions(+)

will apply patchset

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/mov: Fix potential integer overflow in entry check in mov_read_trun()

2019-03-25 Thread Michael Niedermayer

On Sun, Mar 17, 2019 at 11:34:40AM +0100, Michael Niedermayer wrote:
> No testcase
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] AVPixelFormat for YUYV 10 bit.

2019-03-25 Thread Yufei He

It's a standard format. I suggest that it should be in AVPixelFormat.  
the codec can do the conversion.

Yufei.


On 03/25/2019 09:55 AM, Kieran Kunhya wrote:
> On Mon, 25 Mar 2019 at 13:53 Yufei He  wrote:
>
>> Hi
>>
>> I think there may be one format missing in AVPixelFormat.
>>
>> AV_PIX_FMT_YUYV210
>>
> For various reasons v210 and friends are implemented as a codec in FFmpeg.
>
> Kieran
> ___
> 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] AVPixelFormat for YUYV 10 bit.

2019-03-25 Thread Devin Heitmueller

Hello Yufei,

> On Mar 25, 2019, at 9:53 AM, Yufei He  wrote:
> 
> Hi
> 
> I think there may be one format missing in AVPixelFormat.
> 
> AV_PIX_FMT_YUYV210
> 
> 
> [cid:part1.002B7405.3138ACFB@matrox.com]
> 
> 
> The start of each line in the V210 video buffer format must be
> aligned to a multiple of 48 pixels (128 bytes). This means that if a line is 
> not a
> multiple of 48, each line of video data must be padded out to the nearest 48 
> pixel
> boundary. For example, a 1280 × 720 video buffer is 1280 pixels wide, which 
> is not a
> multiple of 48. Each line of the video buffer must be padded to 1296 pixels 
> (3456
> bytes) in order to make each line a multiple of 48.
> 
> It's popular when video is in 10bit.
> 

So V210 video is supported, but not as a pixel format.  It’s treated as a 
packet format.  Hence in order to use v210 video, you have to pass the video 
frame through the v210enc or v210 decoder module, at which point you end up 
with video in AV_PIX_FMT_YUV422P10 format.

We can argue about whether that was the right approach, but that’s what is done 
in ffmpeg today, and we use it regularly with the Blackmagic cards (i.e. you 
can look at libavdevice/decklink_enc.cpp, decklink_dec.cpp for usage).

Devin

---
Devin Heitmueller - LTN Global Communications
dheitmuel...@ltnglobal.com

___
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] News: Removal of libndi

2019-03-25 Thread Kieran Kunhya

On Mon, 25 Mar 2019 at 13:56 Kieran Kunhya  wrote:

> On Mon, 25 Mar 2019 at 13:02 Yufei He  wrote:
>
>> Hardware codecs and software codecs are taking different responsibilities.
>>
>> Thanks a lot.
>>
>> Yufei.
>>
>
> Hi,
>
> You should expose the APIs to the hardware, people will buy more of them
> if they can program the chip to do things as they want.
> I appreciate it's difficult for hardware companies to understand open
> source, since you all are very secretive and live in a world of IP.
> But what people actually want is low-level access to the hardware APIs.
>
> Kieran
>

I would add that most/all APIs to hardware are terrible, hardware engineers
can't design good APIs.
Just let us talk to the chip.

Kieran
___
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/truemotion2: Fix integer overflow in tm2_null_res_block()

2019-03-25 Thread Michael Niedermayer

On Sat, Mar 16, 2019 at 09:39:10AM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 638592 - -2122219136 cannot be 
> represented in type 'int'
> Fixes: 
> 13441/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5732769815068672
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/truemotion2.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dxtory: Check slice sizes before allocating image

2019-03-25 Thread Michael Niedermayer

On Sat, Mar 16, 2019 at 05:32:11PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout (26sec -> 2sec)
> Fixes: 
> 13612/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXTORY_fuzzer-5676845977042944
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dxtory.c | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)

will apply

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.

signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

2019-03-25 Thread Kieran Kunhya

On Mon, 25 Mar 2019 at 13:02 Yufei He  wrote:

> Hardware codecs and software codecs are taking different responsibilities.
>
> Thanks a lot.
>
> Yufei.
>

Hi,

You should expose the APIs to the hardware, people will buy more of them if
they can program the chip to do things as they want.
I appreciate it's difficult for hardware companies to understand open
source, since you all are very secretive and live in a world of IP.
But what people actually want is low-level access to the hardware APIs.

Kieran
___
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] AVPixelFormat for YUYV 10 bit.

2019-03-25 Thread Kieran Kunhya

On Mon, 25 Mar 2019 at 13:53 Yufei He  wrote:

> Hi
>
> I think there may be one format missing in AVPixelFormat.
>
> AV_PIX_FMT_YUYV210
>

For various reasons v210 and friends are implemented as a codec in FFmpeg.

Kieran
___
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] AVPixelFormat for YUYV 10 bit.

2019-03-25 Thread Yufei He

Hi

I think there may be one format missing in AVPixelFormat.

AV_PIX_FMT_YUYV210


[cid:part1.002B7405.3138ACFB@matrox.com]


The start of each line in the V210 video buffer format must be
aligned to a multiple of 48 pixels (128 bytes). This means that if a line is 
not a
multiple of 48, each line of video data must be padded out to the nearest 48 
pixel
boundary. For example, a 1280 × 720 video buffer is 1280 pixels wide, which is 
not a
multiple of 48. Each line of the video buffer must be padded to 1296 pixels 
(3456
bytes) in order to make each line a multiple of 48.

It's popular when video is in 10bit.

Yufei.





___
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] lavc/qsvenc: expose low_power option in H264 QSV

2019-03-25 Thread Linjie Fu

Always exposes low_power option for h264 qsv, and reports a warning
if VDENC is not supported with current version of MSDK.

Signed-off-by: Linjie Fu 
---
 libavcodec/qsvenc.c  | 11 ++-
 libavcodec/qsvenc_h264.c |  2 --
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 5aa020d47b..8264d0a413 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -495,9 +495,18 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 }
 }
 
+if (q->low_power) {
 #if QSV_HAVE_VDENC
-q->param.mfx.LowPower   = q->low_power ? MFX_CODINGOPTION_ON : 
MFX_CODINGOPTION_OFF;
+q->param.mfx.LowPower = MFX_CODINGOPTION_ON;
+#else
+av_log(avctx, AV_LOG_WARNING, "The QSV VDENC option is "
+"not supported with this MSDK version.\n");
+q->low_power = 0;
+q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
 #endif
+} else
+q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
+
 q->param.mfx.CodecProfile   = q->profile;
 q->param.mfx.TargetUsage= avctx->compression_level;
 q->param.mfx.GopPicSize = FFMAX(0, avctx->gop_size);
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index f458137848..93044a58c9 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -154,9 +154,7 @@ static const AVOption options[] = {
 { "auto"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_MF_AUTO }, 
INT_MIN, INT_MAX, VE, "mfmode" },
 #endif
 
-#if QSV_HAVE_VDENC
 { "low_power", "enable low power mode(experimental: many limitations by 
mfx version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 
=  0 }, 0, 1, VE},
-#endif
 
 { "repeat_pps", "repeat pps for every frame", OFFSET(qsv.repeat_pps), 
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
 
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

2019-03-25 Thread Yufei He

Hi

Matrox card is very similar to cards from other companies in terms of 
accesses.

I suggest that we should differentiate hardware codec and software codec.

Hardware codecs are very strong help to FFmpeg for high resolution video 
encoding and decoding like 4k. though gradually software codec will be 
stronger and stronger with CPU grows.

Currently, it's very hard to trancode a quadhd  mxf file to a streaming 
.mp4 file with cpu.

Actually, I don't know what we can get from code to access the hardware, 
it's all detailed hardware access api.

Hardware codecs and software codecs are taking different responsibilities.

Thanks a lot.

Yufei.


On 03/24/2019 04:14 PM, Jean-Baptiste Kempf wrote:
> On Sun, 24 Mar 2019, at 20:10, Ronald S. Bultje wrote:
>> The GPL does not mention hardware (instead, they use the word "system
>> library"). Going from here, I don't consider enterprise-level hardware like
>> Matrox $$$ priced stuff to be a system library at all. My system certainly
>> has no hardware or drivers or system-level libraries that are
>> API+ABI+functionally compatible with Matrox' tools and wares - under any
>> license, not open-source and not closed-source. How can the system library
>> exception possibly apply here?
> Drivers have always been considered part of the OS, whatever the price of the 
> hardware.
> The Linux kernel has drivers for pieces of hardware that are way more 
> expensive than Matrox hardware.
>
> So, if the library is part of the driver (installed at the same time), it is 
> considered part of the "major components of the OS", because if you don't 
> install the driver, you cannot use the hardware.
> This is the opinion of the Linux Foundation, the FSF, FSFE and so many others.
>
> Usually, the "major components" (as mentioned in the GPL and not "system 
> libraries", which is the shortcut) explicitly mention 3 parts: kernel, 
> compiler and  "others."
> The common understanding is that everything that runs in Kernel-Land, aka 
> kernel + drivers is the kernel part of the "major components". libc, compiler 
> and libraries linked by compilers, if distributed with the OS, are the second 
> part of the "major components"; and the last part, "others" cover the other 
> core parts of the OS (usually the "base" in linux distributions), and covers 
> init and the shell, and the basic services normally installed by default (at, 
> cron, etc..).
>
> Yes, this meaning is very dated, but GPLv2 is from 1991.
>
>
> Most of those hardware libraries are glorified ioctls around the driver and 
> shipped with the drivers.
> And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ 
> interface, set param" there, release the C++ interface).
>
> Matrox seems to do something else, though, introducing a special library for 
> FFmpeg consumption, and I doubt that feels like a driver...
>
>
___
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] swscale: Remove duplicated code

2019-03-25 Thread Hendrik Leppkes

On Mon, Mar 25, 2019 at 11:35 AM Lauri Kasanen  wrote:
>
> On Mon, 25 Mar 2019 11:17:38 +0100
> Michael Niedermayer  wrote:
>
> > On Sun, Mar 24, 2019 at 01:04:51PM +0200, Lauri Kasanen wrote:
> > > In this function, the exact same clamping happens both in the if and 
> > > unconditionally.
> > >
> > > Signed-off-by: Lauri Kasanen 
> > > ---
> > >  libswscale/output.c | 14 --
> > >  1 file changed, 14 deletions(-)
> >
> > The removed code is the one that should stay, the other should be
> > removed.
> > one check for a rarely true condition should be faster than 4 checks
>
> Yes, I thought so too, but the commit that added the unconditional code
> says it fixes a bug...
>

Could it overflow so high that other bits then the one being checked
for are set? Perhaps another bit pattern with more high bits set would
solve that.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [Patch] beautified + accelerated vf_fillborders – Please review

2019-03-25 Thread Ulf Zibis


Am 24.03.19 um 00:40 schrieb Carl Eugen Hoyos:
> There are two patches "1", one with wrong indentation.
I intentionally have provided 2 patches with the same number, one for
the code base an one with additions for the benchmark. I've catched the
wrong indentation, hopefully at the place you meant.

> Iiuc, the patch mixes the following:
> Renaming of a variable
> Moving of blocks
> Adding commented code that is removed in a later patch
> Replacing constants with harder to read calculations
This is an argument. There are several places in the code using "* 2".
At some places this is an algorithmic purpose, at others to serve the
16-bit logic. I wanted to set this in clear view.

> Adding comments
>
> I don't maintain the file but in general not all of these are
> acceptable and it any case should be separate changes.
>
> This also removes outcommented code which should
> not be part of a performance enhancement.
> How much "slight enhancement" were you able to measure?
> Iiuc, some cases get slower, no?
> Some people prefer that patches like this do not change the
> indentation to make it more readable.
>
> Again: Please do not mix functional and cosmetic changes.
I'm preparing a new set of patches to follow your advice.

> Do I read the results correctly that for all patches some cases
> get faster and others get slower?

Correct. I'm wondering about the cases, where it gets such slower. So
I'm interested in an answer from you experienced developers to
understand this. Maybe a compiler option would help.

-Ulf

___
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] Added support for XV video files

2019-03-25 Thread Shivam Goyal



On 3/25/19 3:59 PM, Michael Niedermayer wrote:

On Sun, Mar 24, 2019 at 04:35:40PM +0530, Shivam Goyal wrote:

The attached patch is for ticket #3720

     https://trac.ffmpeg.org/ticket/3720

I have tested this demuxer on the files 1.xv and 5.xv attached with the
ticket

http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3720/


  It is working on both of these files.

As XV video files are flv files with some encrypted data. These can be
converted to flv without loosing video quality (and it would be really
fast). I have also tried this and it is working "ffmpeg -i 1.xv -c copy
converted.flv".


Please suggest any improvements



[...]


diff --git a/libavformat/xvtools.h b/libavformat/xvtools.h
new file mode 100644
index 00..42c2c65c46
--- /dev/null
+++ b/libavformat/xvtools.h
@@ -0,0 +1,95 @@
+int flvid = 0x46;
+
+
+int byte_shift(int byte,int shift);
+int find_rot(AVIOContext *pb);
+int xvio_r8(AVIOContext *pb, int rot);
+unsigned int xvio_rb16(AVIOContext *s, int rot);
+unsigned int xvio_rb24(AVIOContext *s, int rot);
+unsigned int xvio_rb32(AVIOContext *s, int rot);
+uint64_t xvio_rb64(AVIOContext *s, int rot);
+int xv_string_decrypt(int64_t curr_pos, char *buffer, int length, int rot);
+
+
+
+int byte_shift(int byte,int shift){
+return ((byte + shift)&0xff);
+}
+
+
+int find_rot(AVIOContext *pb){
+int64_t curr_pos = avio_tell(pb);
+avio_seek(pb,0x20,SEEK_SET);
+int rot = flvid - avio_r8(pb);
+avio_seek(pb,curr_pos, SEEK_SET);
+return rot;
+}
+
+
+
+int xvio_r8(AVIOContext *pb, int rot){
+int64_t curr_pos = avio_tell(pb);
+if(curr_pos < 0x200400){
+int ret=avio_r8(pb);
+if(ret == 0)return 0;
+ret = byte_shift(ret,rot);
+return ret;
+}
+int ret=avio_r8(pb);
+return ret;
+}

There is so much wrong with this code
global variables are not ok in a demuxer that can have multiple instances
global variables do not belong in headers either
also non static inline functions do not belong in headers

this xvio stuff all looks like a bad idea.
Do i guess correctly that this fileformat is flv but scrambled at the IO
layer ?
if this is true it may be possible to implement a xv demuxer as a
descrambler which than passes the data on to a unchanged flv demuxer.
If that how this xv fundamentally works then that would be much
cleaner.
Also theflv demuxer duplication is not ok


Yeah The XV file is a flv file which starts from 0x20 byte and its 
_next__0x400_ bytes are encrypted by something like caesar cipher (the 
bytes after 0x200400 till the end of the file are not encrypted) . So, 
Please suggest what would be best solution for this situation and how 
can i change this.


    Thank you, Shivam Goyal






+
+
+unsigned int xvio_rb16(AVIOContext *s, int rot)
+{
+unsigned int val;
+val = xvio_r8(s, rot) << 8;
+val |= xvio_r8(s, rot);
+return val;
+}
+
+
+unsigned int xvio_rb24(AVIOContext *s, int rot)
+{
+unsigned int val;
+val = xvio_rb16(s, rot) << 8;
+val |= xvio_r8(s, rot);
+return val;
+}
+
+
+unsigned int xvio_rb32(AVIOContext *s, int rot)
+{
+unsigned int val;
+val = xvio_rb16(s, rot) << 16;
+val |= xvio_rb16(s, rot);
+return val;
+}
+
+
+uint64_t xvio_rb64(AVIOContext *s, int rot)
+{
+uint64_t val;
+val = (uint64_t)xvio_rb32(s, rot) << 32;
+val |= (uint64_t)xvio_rb32(s, rot);
+return val;
+}
+
+
+
+int xv_string_decrypt(int64_t curr_pos, char *buffer, int length, int rot){
+if(curr_pos>=0x200400){
+return 0;
+}
+for(int i=0;ihttps://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale: Remove duplicated code

2019-03-25 Thread Lauri Kasanen

On Mon, 25 Mar 2019 11:17:38 +0100
Michael Niedermayer  wrote:

> On Sun, Mar 24, 2019 at 01:04:51PM +0200, Lauri Kasanen wrote:
> > In this function, the exact same clamping happens both in the if and 
> > unconditionally.
> >
> > Signed-off-by: Lauri Kasanen 
> > ---
> >  libswscale/output.c | 14 --
> >  1 file changed, 14 deletions(-)
>
> The removed code is the one that should stay, the other should be
> removed.
> one check for a rarely true condition should be faster than 4 checks

Yes, I thought so too, but the commit that added the unconditional code
says it fixes a bug...

- Lauri
___
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][FFmpeg-devel v2] Add GPU accelerated video crop filter

2019-03-25 Thread Timo Rothenpieler


On 25/03/2019 09:27, Tao Zhang wrote:

Hi,

Timo and Mark and I have been discussing this, and we think the right
thing to do is add support to vf_scale_cuda to respect the crop
properties on an input AVFrame. Mark posted a patch to vf_crop to
ensure that the properties are set, and then the scale filter should
respect those properties if they are set. You can look at
vf_scale_vaapi for how the properties are read, but they will require
explicit handling to adjust the src dimensions passed to the scale
filter.

Maybe a little not intuitive to users.


This will be a more efficient way of handling crops, in terms of total
lines of code and also allowing crop/scale with one less copy.

I know this is quite different from the approach you've taken here, and
we appreciate the work you've done, but it should be better overall to
implement this integrated method.

Hi Philip,

Glad to hear you guys had discussion on this. As I am also considering the 
problem, I have some questions about your idea.
So, what if user did not insert a scale_cuda after crop filter? Do you plan to 
automatically insert scale_cuda or just ignore the crop?
What if user want to do crop,transpose_cuda,scale_cuda? So we also need to 
handle crop inside transpose_cuda filter?

>

I have the same question.
Ideally, scale_cuda should be auto-inserted at the required places once 
it works that way.
Otherwise it seems pointless to me if the user still has to manually 
insert it after the generic filters setting metadata.


For that reason it should also still support getting its parameters 
passed directly as a fallback, and potentially even expose multiple 
filter names, so crop_cuda and transpose_cuda are still visible, but 
ultimately point to the same filter code.


We have a transpose_npp, right now, but with libnpp slowly being on its 
way out, transpose_cuda is needed, and ultimately even a format_cuda 
filter, since right now scale_npp is the only filter that can convert 
pixel formats on the hardware.
I'd also like to see scale_cuda to support a few more interpolation 
algorithms, but that's not very important for now.


All this functionality can be in the same filter, which is scale_cuda. 
The point of that is that it avoids needless expensive frame copies as 
much as possible.




smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Added support for XV video files

2019-03-25 Thread Michael Niedermayer

On Sun, Mar 24, 2019 at 04:35:40PM +0530, Shivam Goyal wrote:
> The attached patch is for ticket #3720
> 
>     https://trac.ffmpeg.org/ticket/3720
> 
> I have tested this demuxer on the files 1.xv and 5.xv attached with the
> ticket
> 
> http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3720/
> 
> 
>  It is working on both of these files.
> 
> As XV video files are flv files with some encrypted data. These can be
> converted to flv without loosing video quality (and it would be really
> fast). I have also tried this and it is working "ffmpeg -i 1.xv -c copy
> converted.flv".
> 
> 
> Please suggest any improvements
> 
> 
[...]

> diff --git a/libavformat/xvtools.h b/libavformat/xvtools.h
> new file mode 100644
> index 00..42c2c65c46
> --- /dev/null
> +++ b/libavformat/xvtools.h
> @@ -0,0 +1,95 @@

> +int flvid = 0x46;
> +
> +
> +int byte_shift(int byte,int shift);
> +int find_rot(AVIOContext *pb);
> +int xvio_r8(AVIOContext *pb, int rot);
> +unsigned int xvio_rb16(AVIOContext *s, int rot);
> +unsigned int xvio_rb24(AVIOContext *s, int rot);
> +unsigned int xvio_rb32(AVIOContext *s, int rot);
> +uint64_t xvio_rb64(AVIOContext *s, int rot);
> +int xv_string_decrypt(int64_t curr_pos, char *buffer, int length, int rot);
> +
> +
> +
> +int byte_shift(int byte,int shift){
> +return ((byte + shift)&0xff);
> +}
> +
> +
> +int find_rot(AVIOContext *pb){
> +int64_t curr_pos = avio_tell(pb);
> +avio_seek(pb,0x20,SEEK_SET);
> +int rot = flvid - avio_r8(pb);
> +avio_seek(pb,curr_pos, SEEK_SET);
> +return rot;
> +}
> +
> +
> +
> +int xvio_r8(AVIOContext *pb, int rot){
> +int64_t curr_pos = avio_tell(pb);
> +if(curr_pos < 0x200400){
> +int ret=avio_r8(pb);
> +if(ret == 0)return 0;
> +ret = byte_shift(ret,rot);
> +return ret;
> +}
> +int ret=avio_r8(pb);
> +return ret;
> +}

There is so much wrong with this code
global variables are not ok in a demuxer that can have multiple instances
global variables do not belong in headers either
also non static inline functions do not belong in headers

this xvio stuff all looks like a bad idea.
Do i guess correctly that this fileformat is flv but scrambled at the IO
layer ?
if this is true it may be possible to implement a xv demuxer as a
descrambler which than passes the data on to a unchanged flv demuxer.
If that how this xv fundamentally works then that would be much
cleaner.
Also theflv demuxer duplication is not ok



> +
> +
> +unsigned int xvio_rb16(AVIOContext *s, int rot)
> +{
> +unsigned int val;
> +val = xvio_r8(s, rot) << 8;
> +val |= xvio_r8(s, rot);
> +return val;
> +}
> +
> +
> +unsigned int xvio_rb24(AVIOContext *s, int rot)
> +{
> +unsigned int val;
> +val = xvio_rb16(s, rot) << 8;
> +val |= xvio_r8(s, rot);
> +return val;
> +}
> +
> +
> +unsigned int xvio_rb32(AVIOContext *s, int rot)
> +{
> +unsigned int val;
> +val = xvio_rb16(s, rot) << 16;
> +val |= xvio_rb16(s, rot);
> +return val;
> +}
> +
> +
> +uint64_t xvio_rb64(AVIOContext *s, int rot)
> +{
> +uint64_t val;
> +val = (uint64_t)xvio_rb32(s, rot) << 32;
> +val |= (uint64_t)xvio_rb32(s, rot);
> +return val;
> +}
> +
> +
> +
> +int xv_string_decrypt(int64_t curr_pos, char *buffer, int length, int rot){
> +if(curr_pos>=0x200400){
> +return 0;
> +}
> +for(int i=0;i +if((curr_pos+i) < 0x200400){
> +buffer[i] = byte_shift(buffer[i],rot);
> +}
> +else{
> +break;
> +}
> +}
> +return 0;
> +}
> +
> +
> -- 
> 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".


-- 
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
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v7] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

2019-03-25 Thread Wang, Shaofei

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Mark Thompson
> Sent: Saturday, March 23, 2019 9:42 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v7] Improved the performance of 1
> decode + N filter graphs and adaptive bitrate.
> 
> On 21/03/2019 15:09, Shaofei Wang wrote:
> > It enabled MULTIPLE SIMPLE filter graph concurrency, which bring above
> > about 4%~20% improvement in some 1:N scenarios by CPU or GPU
> > acceleration
> >
> > ...>
> > Signed-off-by: Wang, Shaofei 
> > Reviewed-by: Michael Niedermayer 
> > Reviewed-by: Mark Thompson 
> 
> The reviewed-by annotation generally implies review approval for a patch,
> which I don't think is true for either of the stated people.
> 
Will remove them. Just thought about the reviewer contribution.
Thx
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Added support for XV video files

2019-03-25 Thread Moritz Barsnick

On Mon, Mar 25, 2019 at 07:57:04 +0530, Shivam Goyal wrote:

> which would be intialised at the time of reading header) whenever we
> need to read from the input file, Which would recquire more processing
> and would make the program slow for both xv  and flv files

Good point. I agree that deciding whether to do rot with each and
every frame and other function calls. Can this not be optimized?

> total no. of occurences of the functions avio_r8, avio_rb16, avio_rb24,
> avio_rb32, avio_rb64 is around 39 . So, should i merge it with flvdec.c.

I cannot decide, I am just commenting. I was just pointing out that
copying a large amount of code for few modifications makes the whole
thing ineffective and a large maintenance burden.

Michael Niedermayer is the flvdec maintainer, and other core developers
will also know better what to do.

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] beautified + accelerated vf_fillborders – Please review

2019-03-25 Thread Ulf Zibis

Hi again,

Am 19.03.19 um 21:44 schrieb Ulf Zibis:
> Am 19.03.19 um 17:31 schrieb Carl Eugen Hoyos:
>>>  122670 decicycles in fillborders=0:0:5:5:mirror 3p-8bit-1x1,
>>> 1 runs,  0 skips
>> One run is not good.
>> Either use the loop option to filter the same frame again and
>> again or feed a video to ffmpeg.
> With:
> ./ffmpeg -y -v error -stream_loop 100 -i input.jpg -vf
> fillborders=5:5:5:5:mirror -f null -
> I still see only 1 run. What I'm doing wrong?
As I was not able to find a loop option I used -stream_loop. Now I'm
wondering, that it doesn't work as I expect.

Do I misinterpret the purpose of -stream_loop?

-Ulf


___
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] configure: include pkgconfig path as vaapi header search

2019-03-25 Thread Timo Rothenpieler


On 20/03/2019 08:57, Zhong Li wrote:

Currectly just standard header path and be found,
check_type/struct will fail if vaapi is installed somewhere else.
---
  configure | 18 ++
  1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/configure b/configure
index eaf543df96..0e3c2d24bf 100755
--- a/configure
+++ b/configure
@@ -6024,14 +6024,6 @@ check_type "windows.h d3d11.h" "ID3D11VideoDecoder"
  check_type "windows.h d3d11.h" "ID3D11VideoContext"
  check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602
  
-check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"

-check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
-check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
-check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
-check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
-check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
-check_type "va/va.h va/va_enc_vp9.h"  "VAEncPictureParameterBufferVP9"
-
  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
  
  if enabled cuda_sdk; then

@@ -6469,6 +6461,16 @@ if enabled vaapi; then
  check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0, 0)"
  fi
  
+if enabled vaapi; then

+check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
+check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
+check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
+check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
+check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
+check_type "va/va.h va/va_enc_vp8.h"  "VAEncPictureParameterBufferVP8"
+check_type "va/va.h va/va_enc_vp9.h"  "VAEncPictureParameterBufferVP9"
+fi
+
  if enabled_all opencl libdrm ; then
  check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
  enable opencl_drm_beignet



Do I understand this right, that the desired effect is achieved by 
putting those check_* behind the pkgconfig check, which is in between 
the old and the new location?


If so, this looks OK to me.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] swscale: Remove duplicated code

2019-03-25 Thread Michael Niedermayer

On Sun, Mar 24, 2019 at 01:04:51PM +0200, Lauri Kasanen wrote:
> In this function, the exact same clamping happens both in the if and 
> unconditionally.
> 
> Signed-off-by: Lauri Kasanen 
> ---
>  libswscale/output.c | 14 --
>  1 file changed, 14 deletions(-)

The removed code is the one that should stay, the other should be
removed.
one check for a rarely true condition should be faster than 4 checks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin

signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/avformat.h: Update the comment for AVInputFormat.flags

2019-03-25 Thread Jun Zhao

From: Jun Zhao 

AVFMT_NOTIMESTAMPS may be using AVInputFormat.flags for demuxing

Signed-off-by: Jun Zhao 
---
 libavformat/avformat.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 2907be5..a65c262 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -653,7 +653,7 @@ typedef struct AVInputFormat {
 
 /**
  * Can use flags: AVFMT_NOFILE, AVFMT_NEEDNUMBER, AVFMT_SHOW_IDS,
- * AVFMT_GENERIC_INDEX, AVFMT_TS_DISCONT, AVFMT_NOBINSEARCH,
+ * AVFMT_NOTIMESTAMPS, AVFMT_GENERIC_INDEX, AVFMT_TS_DISCONT, 
AVFMT_NOBINSEARCH,
  * AVFMT_NOGENSEARCH, AVFMT_NO_BYTE_SEEK, AVFMT_SEEK_TO_PTS.
  */
 int flags;
-- 
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] [PATCH V1 2/3] avformat/avformat.h: Update the comment for format_probesize

2019-03-25 Thread Jun Zhao

From: Jun Zhao 

Update the comment for format_probesize.

Signed-off-by: Jun Zhao 
---
 libavformat/avformat.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index e1b9b11..2907be5 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1770,7 +1770,7 @@ typedef struct AVFormatContext {
 /**
  * number of bytes to read maximally to identify format.
  * - encoding: unused
- * - decoding: set by user
+ * - decoding: set by user before avformat_open_input().
  */
 int format_probesize;
 
-- 
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] [PATCH V1 3/3] avformat/avformat.h: Update the Update the comment for AVInputFormat.flags

2019-03-25 Thread Jun Zhao

From: Jun Zhao 

AVFMT_NOTIMESTAMPS may be using AVInputFormat.flags for demuxing

Signed-off-by: Jun Zhao 
---
 libavformat/avformat.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 2907be5..a65c262 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -653,7 +653,7 @@ typedef struct AVInputFormat {
 
 /**
  * Can use flags: AVFMT_NOFILE, AVFMT_NEEDNUMBER, AVFMT_SHOW_IDS,
- * AVFMT_GENERIC_INDEX, AVFMT_TS_DISCONT, AVFMT_NOBINSEARCH,
+ * AVFMT_NOTIMESTAMPS, AVFMT_GENERIC_INDEX, AVFMT_TS_DISCONT, 
AVFMT_NOBINSEARCH,
  * AVFMT_NOGENSEARCH, AVFMT_NO_BYTE_SEEK, AVFMT_SEEK_TO_PTS.
  */
 int flags;
-- 
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] [PATCH V1 1/3] lavf/utils: Remove redundancy AVFMT_FLAG_CUSTOM_IO setting

2019-03-25 Thread Jun Zhao

From: Jun Zhao 

After commit ba631b79, we don't need to re-setting AVFMT_FLAG_CUSTOM_IO
in init_input().

Signed-off-by: Jun Zhao 
---
 libavformat/utils.c |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 9b3f0d2..fe67c8f 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -421,7 +421,6 @@ static int init_input(AVFormatContext *s, const char 
*filename,
 int score = AVPROBE_SCORE_RETRY;
 
 if (s->pb) {
-s->flags |= AVFMT_FLAG_CUSTOM_IO;
 if (!s->iformat)
 return av_probe_input_buffer2(s->pb, >iformat, filename,
  s, 0, s->format_probesize);
-- 
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".

Re: [FFmpeg-devel] [PATCH] configure: include pkgconfig path as vaapi header search

2019-03-25 Thread Li, Zhong

> From: Li, Zhong
> Sent: Wednesday, March 20, 2019 3:57 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong 
> Subject: [PATCH] configure: include pkgconfig path as vaapi header search
> 
> Currectly just standard header path and be found, check_type/struct will fail
> if vaapi is installed somewhere else.
> ---
>  configure | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
> 
> diff --git a/configure b/configure
> index eaf543df96..0e3c2d24bf 100755
> --- a/configure
> +++ b/configure
> @@ -6024,14 +6024,6 @@ check_type "windows.h d3d11.h"
> "ID3D11VideoDecoder"
>  check_type "windows.h d3d11.h" "ID3D11VideoContext"
>  check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
> -D_WIN32_WINNT=0x0602
> 
> -check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
> -check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> -check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
> -check_type "va/va.h va/va_enc_hevc.h"
> "VAEncPictureParameterBufferHEVC"
> -check_type "va/va.h va/va_enc_jpeg.h"
> "VAEncPictureParameterBufferJPEG"
> -check_type "va/va.h va/va_enc_vp8.h"
> "VAEncPictureParameterBufferVP8"
> -check_type "va/va.h va/va_enc_vp9.h"
> "VAEncPictureParameterBufferVP9"
> -
>  check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC"
> 
>  if enabled cuda_sdk; then
> @@ -6469,6 +6461,16 @@ if enabled vaapi; then
>  check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0, 0)"
>  fi
> 
> +if enabled vaapi; then
> +check_type "va/va.h va/va_dec_hevc.h"
> "VAPictureParameterBufferHEVC"
> +check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
> +check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps"
> rotation_flags
> +check_type "va/va.h va/va_enc_hevc.h"
> "VAEncPictureParameterBufferHEVC"
> +check_type "va/va.h va/va_enc_jpeg.h"
> "VAEncPictureParameterBufferJPEG"
> +check_type "va/va.h va/va_enc_vp8.h"
> "VAEncPictureParameterBufferVP8"
> +check_type "va/va.h va/va_enc_vp9.h"
> "VAEncPictureParameterBufferVP9"
> +fi
> +
>  if enabled_all opencl libdrm ; then
>  check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
>  enable opencl_drm_beignet
> --
> 2.17.1

Ping?
___
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][FFmpeg-devel v2] Add GPU accelerated video crop filter

2019-03-25 Thread Tao Zhang

Song, Ruiling  于2019年3月25日周一 下午3:26写道：
>
>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Philip Langdale via ffmpeg-devel
> > Sent: Monday, March 25, 2019 12:57 PM
> > To: FFmpeg development discussions and patches 
> > Cc: Philip Langdale 
> > Subject: Re: [FFmpeg-devel] [PATCH][FFmpeg-devel v2] Add GPU accelerated
> > video crop filter
> >
> > On Sat, 23 Mar 2019 23:51:10 +0800
> > UsingtcNower  wrote:
> >
> > > Signed-off-by: UsingtcNower 
> > > ---
> > >  Changelog   |   1 +
> > >  configure   |   1 +
> > >  doc/filters.texi|  31 +++
> > >  libavfilter/Makefile|   1 +
> > >  libavfilter/allfilters.c|   1 +
> > >  libavfilter/version.h   |   2 +-
> > >  libavfilter/vf_crop_cuda.c  | 638
> > > 
> > > libavfilter/vf_crop_cuda.cu | 109  8 files changed, 783
> > > insertions(+), 1 deletion(-) create mode 100644
> > > libavfilter/vf_crop_cuda.c create mode 100644
> > > libavfilter/vf_crop_cuda.cu
> > >
> > > diff --git a/Changelog b/Changelog
> > > index ad7e82f..f224fc8 100644
> > > --- a/Changelog
> > > +++ b/Changelog
> > > @@ -20,6 +20,7 @@ version :
> > >  - libaribb24 based ARIB STD-B24 caption support (profiles A and C)
> > >  - Support decoding of HEVC 4:4:4 content in nvdec and cuviddec
> > >  - removed libndi-newtek
> > > +- crop_cuda GPU accelerated video crop filter
> >
> > Hi,
> >
> > Timo and Mark and I have been discussing this, and we think the right
> > thing to do is add support to vf_scale_cuda to respect the crop
> > properties on an input AVFrame. Mark posted a patch to vf_crop to
> > ensure that the properties are set, and then the scale filter should
> > respect those properties if they are set. You can look at
> > vf_scale_vaapi for how the properties are read, but they will require
> > explicit handling to adjust the src dimensions passed to the scale
> > filter.
Maybe a little not intuitive to users.
> >
> > This will be a more efficient way of handling crops, in terms of total
> > lines of code and also allowing crop/scale with one less copy.
> >
> > I know this is quite different from the approach you've taken here, and
> > we appreciate the work you've done, but it should be better overall to
> > implement this integrated method.
> Hi Philip,
>
> Glad to hear you guys had discussion on this. As I am also considering the 
> problem, I have some questions about your idea.
> So, what if user did not insert a scale_cuda after crop filter? Do you plan 
> to automatically insert scale_cuda or just ignore the crop?
> What if user want to do crop,transpose_cuda,scale_cuda? So we also need to 
> handle crop inside transpose_cuda filter?
I have the same question.
> (looks like we do not have transpose_cuda right now, but this filter seems 
> needed if user want to do transpose job using cuda.)
>
> Thanks!
> Ruiling
> >
> > Thanks,
> >
> > >
> > >  version 4.1:
> > > diff --git a/configure b/configure
> > > index 331393f..3f3ac2f 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -2973,6 +2973,7 @@ qsvvpp_select="qsv"
> > >  vaapi_encode_deps="vaapi"
> > >  v4l2_m2m_deps="linux_videodev2_h sem_timedwait"
> > >
> > > +crop_cuda_filter_deps="ffnvcodec cuda_nvcc"
> > >  hwupload_cuda_filter_deps="ffnvcodec"
> > >  scale_npp_filter_deps="ffnvcodec libnpp"
> > >  scale_cuda_filter_deps="ffnvcodec cuda_nvcc"
> > > diff --git a/doc/filters.texi b/doc/filters.texi
> > > index 4ffb392..ee16a2d 100644
> > > --- a/doc/filters.texi
> > > +++ b/doc/filters.texi
> > > @@ -7415,6 +7415,37 @@ If the specified expression is not valid, it
> > > is kept at its current value.
> > >  @end table
> > >
> > > +@section crop_cuda
> > > +
> > > +Crop the input video to given dimensions, implemented in CUDA.
> > > +
> > > +It accepts the following parameters:
> > > +
> > > +@table @option
> > > +
> > > +@item w
> > > +The width of the output video. It defaults to @code{iw}.
> > > +This expression is evaluated only once during the filter
> > > +configuration.
> > > +
> > > +@item h
> > > +The height of the output video. It defaults to @code{ih}.
> > > +This expression is evaluated only once during the filter
> > > +configuration.
> > > +
> > > +@item x
> > > +The horizontal position, in the input video, of the left edge of the
> > > output +video. It defaults to @code{(in_w-out_w)/2}.
> > > +This expression is evaluated only once during the filter
> > > +configuration.
> > > +
> > > +@item y
> > > +The vertical position, in the input video, of the top edge of the
> > > output video. +It defaults to @code{(in_h-out_h)/2}.
> > > +This expression is evaluated only once during the filter
> > > +configuration.
> > > +@end table
> > > +
> > >  @section cropdetect
> > >
> > >  Auto-detect the crop size.
> > > diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> > > index fef6ec5..84df037 100644
> > > --- a/libavfilter/Makefile
> > >

Re: [FFmpeg-devel] [PATCH] News: Removal of libndi

2019-03-25 Thread Tobias Rapp

On 24.03.2019 21:14, Jean-Baptiste Kempf wrote:

On Sun, 24 Mar 2019, at 20:10, Ronald S. Bultje wrote:

The GPL does not mention hardware (instead, they use the word "system
library"). Going from here, I don't consider enterprise-level hardware like
Matrox $$$ priced stuff to be a system library at all. My system certainly
has no hardware or drivers or system-level libraries that are
API+ABI+functionally compatible with Matrox' tools and wares - under any
license, not open-source and not closed-source. How can the system library
exception possibly apply here?

Drivers have always been considered part of the OS, whatever the price of the
hardware.
The Linux kernel has drivers for pieces of hardware that are way more expensive
than Matrox hardware.

So, if the library is part of the driver (installed at the same time), it is considered
part of the "major components of the OS", because if you don't install the
driver, you cannot use the hardware.
This is the opinion of the Linux Foundation, the FSF, FSFE and so many others.

Usually, the "major components" (as mentioned in the GPL and not "system libraries",
which is the shortcut) explicitly mention 3 parts: kernel, compiler and "others."
The common understanding is that everything that runs in Kernel-Land, aka kernel + drivers is the kernel part of the
"major components". libc, compiler and libraries linked by compilers, if distributed with the OS, are the
second part of the "major components"; and the last part, "others" cover the other core parts of
the OS (usually the "base" in linux distributions), and covers init and the shell, and the basic services
normally installed by default (at, cron, etc..).

Yes, this meaning is very dated, but GPLv2 is from 1991.

Most of those hardware libraries are glorified ioctls around the driver and
shipped with the drivers.
And I see this with nVidia, Intel MFX and Decklink (lots of "acquire C++ interface,
set param" there, release the C++ interface).

Matrox seems to do something else, though, introducing a special library for
FFmpeg consumption, and I doubt that feels like a driver...

The GPL is mentioned a lot in this thread. Maybe it would make sense to
distinguish the two cases where FFmpeg is compiled with --enable-gpl and
without it -- as the LGPL applies in that case.

Regards,
Tobias

___
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][FFmpeg-devel v2] Add GPU accelerated video crop filter

2019-03-25 Thread Song, Ruiling



> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Philip Langdale via ffmpeg-devel
> Sent: Monday, March 25, 2019 12:57 PM
> To: FFmpeg development discussions and patches 
> Cc: Philip Langdale 
> Subject: Re: [FFmpeg-devel] [PATCH][FFmpeg-devel v2] Add GPU accelerated
> video crop filter
> 
> On Sat, 23 Mar 2019 23:51:10 +0800
> UsingtcNower  wrote:
> 
> > Signed-off-by: UsingtcNower 
> > ---
> >  Changelog   |   1 +
> >  configure   |   1 +
> >  doc/filters.texi|  31 +++
> >  libavfilter/Makefile|   1 +
> >  libavfilter/allfilters.c|   1 +
> >  libavfilter/version.h   |   2 +-
> >  libavfilter/vf_crop_cuda.c  | 638
> > 
> > libavfilter/vf_crop_cuda.cu | 109  8 files changed, 783
> > insertions(+), 1 deletion(-) create mode 100644
> > libavfilter/vf_crop_cuda.c create mode 100644
> > libavfilter/vf_crop_cuda.cu
> >
> > diff --git a/Changelog b/Changelog
> > index ad7e82f..f224fc8 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -20,6 +20,7 @@ version :
> >  - libaribb24 based ARIB STD-B24 caption support (profiles A and C)
> >  - Support decoding of HEVC 4:4:4 content in nvdec and cuviddec
> >  - removed libndi-newtek
> > +- crop_cuda GPU accelerated video crop filter
> 
> Hi,
> 
> Timo and Mark and I have been discussing this, and we think the right
> thing to do is add support to vf_scale_cuda to respect the crop
> properties on an input AVFrame. Mark posted a patch to vf_crop to
> ensure that the properties are set, and then the scale filter should
> respect those properties if they are set. You can look at
> vf_scale_vaapi for how the properties are read, but they will require
> explicit handling to adjust the src dimensions passed to the scale
> filter.
> 
> This will be a more efficient way of handling crops, in terms of total
> lines of code and also allowing crop/scale with one less copy.
> 
> I know this is quite different from the approach you've taken here, and
> we appreciate the work you've done, but it should be better overall to
> implement this integrated method.
Hi Philip,

Glad to hear you guys had discussion on this. As I am also considering the 
problem, I have some questions about your idea.
So, what if user did not insert a scale_cuda after crop filter? Do you plan to 
automatically insert scale_cuda or just ignore the crop?
What if user want to do crop,transpose_cuda,scale_cuda? So we also need to 
handle crop inside transpose_cuda filter?
(looks like we do not have transpose_cuda right now, but this filter seems 
needed if user want to do transpose job using cuda.)

Thanks!
Ruiling
> 
> Thanks,
> 
> >
> >  version 4.1:
> > diff --git a/configure b/configure
> > index 331393f..3f3ac2f 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2973,6 +2973,7 @@ qsvvpp_select="qsv"
> >  vaapi_encode_deps="vaapi"
> >  v4l2_m2m_deps="linux_videodev2_h sem_timedwait"
> >
> > +crop_cuda_filter_deps="ffnvcodec cuda_nvcc"
> >  hwupload_cuda_filter_deps="ffnvcodec"
> >  scale_npp_filter_deps="ffnvcodec libnpp"
> >  scale_cuda_filter_deps="ffnvcodec cuda_nvcc"
> > diff --git a/doc/filters.texi b/doc/filters.texi
> > index 4ffb392..ee16a2d 100644
> > --- a/doc/filters.texi
> > +++ b/doc/filters.texi
> > @@ -7415,6 +7415,37 @@ If the specified expression is not valid, it
> > is kept at its current value.
> >  @end table
> >
> > +@section crop_cuda
> > +
> > +Crop the input video to given dimensions, implemented in CUDA.
> > +
> > +It accepts the following parameters:
> > +
> > +@table @option
> > +
> > +@item w
> > +The width of the output video. It defaults to @code{iw}.
> > +This expression is evaluated only once during the filter
> > +configuration.
> > +
> > +@item h
> > +The height of the output video. It defaults to @code{ih}.
> > +This expression is evaluated only once during the filter
> > +configuration.
> > +
> > +@item x
> > +The horizontal position, in the input video, of the left edge of the
> > output +video. It defaults to @code{(in_w-out_w)/2}.
> > +This expression is evaluated only once during the filter
> > +configuration.
> > +
> > +@item y
> > +The vertical position, in the input video, of the top edge of the
> > output video. +It defaults to @code{(in_h-out_h)/2}.
> > +This expression is evaluated only once during the filter
> > +configuration.
> > +@end table
> > +
> >  @section cropdetect
> >
> >  Auto-detect the crop size.
> > diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> > index fef6ec5..84df037 100644
> > --- a/libavfilter/Makefile
> > +++ b/libavfilter/Makefile
> > @@ -187,6 +187,7 @@ OBJS-$(CONFIG_COPY_FILTER)   +=
> > vf_copy.o OBJS-$(CONFIG_COREIMAGE_FILTER)  +=
> > vf_coreimage.o OBJS-$(CONFIG_COVER_RECT_FILTER) +=
> > vf_cover_rect.o lavfutils.o
> > OBJS-$(CONFIG_CROP_FILTER)   += vf_crop.o
> >

[FFmpeg-devel] [PATCH 3/3 v2] swscale/ppc: VSX-optimize yuv2422_X

2019-03-25 Thread Lauri Kasanen

./ffmpeg -f lavfi -i yuvtestsrc=duration=1:size=1200x1440 \
  -s 1200x720 -f null -vframes 100 -pix_fmt $i -nostats \
  -cpuflags 0 -v error -

7.2x speedup:

yuyv422
 126354 UNITS in yuv2packedX,   16384 runs,  0 skips
  16383 UNITS in yuv2packedX,   16382 runs,  2 skips
yvyu422
 117669 UNITS in yuv2packedX,   16384 runs,  0 skips
  16271 UNITS in yuv2packedX,   16379 runs,  5 skips
uyvy422
 117310 UNITS in yuv2packedX,   16384 runs,  0 skips
  16226 UNITS in yuv2packedX,   16382 runs,  2 skips

Signed-off-by: Lauri Kasanen 
---
 libswscale/ppc/swscale_vsx.c | 104 +++
 1 file changed, 104 insertions(+)

v2: Fix accidental tabs. No code changes

diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 1c4051b..69ec63d 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -726,6 +726,93 @@ write422(const vector int16_t vy1, const vector int16_t 
vy2,
 }
 }

+static av_always_inline void
+yuv2422_X_vsx_template(SwsContext *c, const int16_t *lumFilter,
+ const int16_t **lumSrc, int lumFilterSize,
+ const int16_t *chrFilter, const int16_t **chrUSrc,
+ const int16_t **chrVSrc, int chrFilterSize,
+ const int16_t **alpSrc, uint8_t *dest, int dstW,
+ int y, enum AVPixelFormat target)
+{
+int i, j;
+vector int16_t vy1, vy2, vu, vv;
+vector int32_t vy32[4], vu32[2], vv32[2], tmp, tmp2, tmp3, tmp4;
+vector int16_t vlumFilter[MAX_FILTER_SIZE], vchrFilter[MAX_FILTER_SIZE];
+const vector int32_t start = vec_splats(1 << 18);
+const vector uint32_t shift19 = vec_splats(19U);
+
+for (i = 0; i < lumFilterSize; i++)
+vlumFilter[i] = vec_splats(lumFilter[i]);
+for (i = 0; i < chrFilterSize; i++)
+vchrFilter[i] = vec_splats(chrFilter[i]);
+
+for (i = 0; i < ((dstW + 1) >> 1); i += 8) {
+vy32[0] =
+vy32[1] =
+vy32[2] =
+vy32[3] =
+vu32[0] =
+vu32[1] =
+vv32[0] =
+vv32[1] = start;
+
+for (j = 0; j < lumFilterSize; j++) {
+vv = vec_ld(0, [j][i * 2]);
+tmp = vec_mule(vv, vlumFilter[j]);
+tmp2 = vec_mulo(vv, vlumFilter[j]);
+tmp3 = vec_mergeh(tmp, tmp2);
+tmp4 = vec_mergel(tmp, tmp2);
+
+vy32[0] = vec_adds(vy32[0], tmp3);
+vy32[1] = vec_adds(vy32[1], tmp4);
+
+vv = vec_ld(0, [j][(i + 4) * 2]);
+tmp = vec_mule(vv, vlumFilter[j]);
+tmp2 = vec_mulo(vv, vlumFilter[j]);
+tmp3 = vec_mergeh(tmp, tmp2);
+tmp4 = vec_mergel(tmp, tmp2);
+
+vy32[2] = vec_adds(vy32[2], tmp3);
+vy32[3] = vec_adds(vy32[3], tmp4);
+}
+
+for (j = 0; j < chrFilterSize; j++) {
+vv = vec_ld(0, [j][i]);
+tmp = vec_mule(vv, vchrFilter[j]);
+tmp2 = vec_mulo(vv, vchrFilter[j]);
+tmp3 = vec_mergeh(tmp, tmp2);
+tmp4 = vec_mergel(tmp, tmp2);
+
+vu32[0] = vec_adds(vu32[0], tmp3);
+vu32[1] = vec_adds(vu32[1], tmp4);
+
+vv = vec_ld(0, [j][i]);
+tmp = vec_mule(vv, vchrFilter[j]);
+tmp2 = vec_mulo(vv, vchrFilter[j]);
+tmp3 = vec_mergeh(tmp, tmp2);
+tmp4 = vec_mergel(tmp, tmp2);
+
+vv32[0] = vec_adds(vv32[0], tmp3);
+vv32[1] = vec_adds(vv32[1], tmp4);
+}
+
+for (j = 0; j < 4; j++) {
+vy32[j] = vec_sra(vy32[j], shift19);
+}
+for (j = 0; j < 2; j++) {
+vu32[j] = vec_sra(vu32[j], shift19);
+vv32[j] = vec_sra(vv32[j], shift19);
+}
+
+vy1 = vec_packs(vy32[0], vy32[1]);
+vy2 = vec_packs(vy32[2], vy32[3]);
+vu = vec_packs(vu32[0], vu32[1]);
+vv = vec_packs(vv32[0], vv32[1]);
+
+write422(vy1, vy2, vu, vv, [i * 4], target);
+}
+}
+
 #define SETUP(x, buf0, buf1, alpha) { \
 x = vec_ld(0, buf0); \
 tmp = vec_mule(x, alpha); \
@@ -841,7 +928,21 @@ yuv2422_1_vsx_template(SwsContext *c, const int16_t *buf0,
 }
 }

+#define YUV2PACKEDWRAPPERX(name, base, ext, fmt) \
+static void name ## ext ## _X_vsx(SwsContext *c, const int16_t *lumFilter, \
+const int16_t **lumSrc, int lumFilterSize, \
+const int16_t *chrFilter, const int16_t 
**chrUSrc, \
+const int16_t **chrVSrc, int chrFilterSize, \
+const int16_t **alpSrc, uint8_t *dest, int 
dstW, \
+int y) \
+{ \
+name ## base ## _X_vsx_template(c, lumFilter, lumSrc, lumFilterSize, \
+  chrFilter, chrUSrc, chrVSrc, chrFilterSize, \
+  alpSrc, dest, dstW, y, fmt); \
+}
+
 #define YUV2PACKEDWRAPPER2(name,

64 matches

Mail list logo