[FFmpeg-devel] [PATCH] avformat/hlsenc: check dirname before use it

[Steven Liu]

fix ticket: 7527

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f8f060d065..3e4f2b6c8b 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -461,7 +461,7 @@ static int hls_delete_old_segments(AVFormatContext *s, 
HLSContext *hls,
 char * r_dirname = dirname;
 
 /* if %v is present in the file's directory */
-if (av_stristr(dirname, "%v")) {
+if (dirname && av_stristr(dirname, "%v")) {
 
 if (replace_int_data_in_filename(&r_dirname, dirname, 'v', 
segment->var_stream_idx) < 1) {
 ret = AVERROR(EINVAL);
-- 
2.15.2 (Apple Git-101.1)



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

Re: [FFmpeg-devel] [PATCH 1/4] doc/filters: add document for opencl filters

[Gyan]

On Tue, Oct 30, 2018 at 12:00 PM Gyan  wrote:

>
>
> On Mon, Oct 29, 2018 at 10:50 AM Ruiling Song 
> wrote:
>
>> Signed-off-by: Danil Iashchenko 
>> Signed-off-by: Ruiling Song 
>> ---
>> Seems like Danil is not working on this recently.
>> So I re-submit this patch to address the comment over overlay_opencl.
>>
>
> Looks good for a push now. I'll make any changes later on.
>

Lou, can you push this? Won't have my comp with the repo credentials for
some time.

Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add CUDA function cuDeviceGetAttribute

[Soft Works]

Hi Phil,

thank you very much for taking the time to respond.

I've understood the differences regarding the parser.

> The hwaccels are officially called 'cuvid' and 'nvdec'. As a
> convenience, we alias 'cuda' to 'nvdec'. The confusion is that the HW
> pix_fmt and hwcontext are called 'cuda' because these are generic and
> used by both decoders (and the various cuda based filters).

By "officially", I guess you are referring to the suffixes of the
encoder names, like h264_cuvid and h264_nvdec.

When executing with -hwaccels - it returns:

Hardware acceleration methods:
cuda
dxva2
qsv
d3d11va
qsv
cuvid

All of these are hwcontext types except 'cuvid'. So, is cuvid an alias 
for 'cuda' then?

Just to get things 100% clear: In case of cuvid, the codec must be specified 
explicitly like this:

ffpmeg -hwaccel cuvid -c:v h264_cuvid


While for nvdec one would use:

ffpmeg -hwaccel cuda

and actually get h264_nvdec?

> Now, cuviddec has somewhat limited value. It allows you to take
> advantage of the nvidia deinterlacer, which does rate doubling. This
> can't be used in nvdec because an hwaccel can't change the frame rate.
> It may be more performant in certain situations. But apart from those
> two things, you should use nvdec. 

Also cuviddec has the -resize option which nvdec does not have, right?

> I've made an attempt to bridge the deinterlacing gap by writing a
> yadif_cuda deinterlacer as you've probably seen on the list, but I
> suspect cuviddec will stick around just because it might be a useful
> option for some people.

I've seen that and I'm looking forward to trying and using it.
Is there any cuda scaling filter planned? (as npp_scale is not an option)

Thanks,

softworkz

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

Re: [FFmpeg-devel] [PATCH] Add CUDA function cuDeviceGetAttribute

[Philip Langdale]

On Thu, 1 Nov 2018 23:48:03 +
Soft Works  wrote:

> In this context, I wonder if there is some explanation somewhere
> about the differences between the cuvid and nvdec codec
> implementations.
> 
> I understand the ffmpeg side where cuvid is a full codec and nvdec is 
> implemented as hwaccel. 

This is correct. It's the same decoder being used, but 'cuviddec' uses
the full nvidia parser, which then drives the decoder. As such, it's a
full codec. nvdec is an hwaccel that plugs into the ffmpeg decoders.
 
> What adds to the confusion is that the hwaccel is called 'cuda'.

The hwaccels are officially called 'cuvid' and 'nvdec'. As a
convenience, we alias 'cuda' to 'nvdec'. The confusion is that the HW
pix_fmt and hwcontext are called 'cuda' because these are generic and
used by both decoders (and the various cuda based filters).

> 
> What I'm wondering now is what difference all this makes at the side
> of the GPU acceleration, doesn't this end up being just the same?
> Why do we have that dual implementation?

We have two primarily because cuviddec was written first, as it's
relatively easy to build a working full codec around the nvidia library
and it supports all the formats largely automatically. Writing an
hwaccel is a bit more work, including the very tedious exercise of
mapping all the properties across when describing a frame for the
decoder. But it was eventually done.

Now, cuviddec has somewhat limited value. It allows you to take
advantage of the nvidia deinterlacer, which does rate doubling. This
can't be used in nvdec because an hwaccel can't change the frame rate.
It may be more performant in certain situations. But apart from those
two things, you should use nvdec. The ffmpeg parsers and decoders are
generally more capable than the nvidia ones, and particularly for HDR
content, the nvidia ones have problems.

I've made an attempt to bridge the deinterlacing gap by writing a
yadif_cuda deinterlacer as you've probably seen on the list, but I
suspect cuviddec will stick around just because it might be a useful
option for some people.

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

[FFmpeg-devel] [PATCH 3/3] avcodec/nvdec: Increase frame pool size to help deinterlacing

[Philip Langdale]

With the cuda yadif filter in use, the number of mapped decoder
frames could increase by two, as the filter holds on to additional
frames.

Signed-off-by: Philip Langdale 
---
 libavcodec/nvdec.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 4dd6b1acf3..0426c9b319 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -601,7 +601,11 @@ int ff_nvdec_frame_params(AVCodecContext *avctx,
 frames_ctx->format= AV_PIX_FMT_CUDA;
 frames_ctx->width = (avctx->coded_width + 1) & ~1;
 frames_ctx->height= (avctx->coded_height + 1) & ~1;
-frames_ctx->initial_pool_size = dpb_size;
+/*
+ * We add two extra frames to the pool to account for deinterlacing filters
+ * holding onto their frames.
+ */
+frames_ctx->initial_pool_size = dpb_size + 2;
 
 frames_ctx->free = nvdec_free_dummy;
 frames_ctx->pool = av_buffer_pool_init(0, nvdec_alloc_dummy);
-- 
2.19.1

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

[FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

[Philip Langdale]

Signed-off-by: Philip Langdale 
---
 Changelog|   1 +
 configure|   1 +
 doc/filters.texi |  58 +
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_yadif_cuda.c  | 426 +++
 libavfilter/vf_yadif_cuda.cu | 296 
 7 files changed, 784 insertions(+)
 create mode 100644 libavfilter/vf_yadif_cuda.c
 create mode 100644 libavfilter/vf_yadif_cuda.cu

diff --git a/Changelog b/Changelog
index 8430da3c6a..f92886fc2e 100644
--- a/Changelog
+++ b/Changelog
@@ -44,6 +44,7 @@ version 4.1:
 - xstack filter
 - pcm vidc decoder and encoder
 - (a)graphmonitor filter
+- yadif_cuda filter
 
 
 version 4.0:
diff --git a/configure b/configure
index 2606b885b0..f3fa0cde86 100755
--- a/configure
+++ b/configure
@@ -3482,6 +3482,7 @@ zscale_filter_deps="libzimg const_nan"
 scale_vaapi_filter_deps="vaapi"
 vpp_qsv_filter_deps="libmfx"
 vpp_qsv_filter_select="qsvvpp"
+yadif_cuda_filter_deps="cuda_sdk"
 
 # examples
 avio_dir_cmd_deps="avformat avutil"
diff --git a/doc/filters.texi b/doc/filters.texi
index 4345a4931b..5d4bfd2e8e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17943,6 +17943,64 @@ filter").
 It accepts the following parameters:
 
 
+@table @option
+
+@item mode
+The interlacing mode to adopt. It accepts one of the following values:
+
+@table @option
+@item 0, send_frame
+Output one frame for each frame.
+@item 1, send_field
+Output one frame for each field.
+@item 2, send_frame_nospatial
+Like @code{send_frame}, but it skips the spatial interlacing check.
+@item 3, send_field_nospatial
+Like @code{send_field}, but it skips the spatial interlacing check.
+@end table
+
+The default value is @code{send_frame}.
+
+@item parity
+The picture field parity assumed for the input interlaced video. It accepts one
+of the following values:
+
+@table @option
+@item 0, tff
+Assume the top field is first.
+@item 1, bff
+Assume the bottom field is first.
+@item -1, auto
+Enable automatic detection of field parity.
+@end table
+
+The default value is @code{auto}.
+If the interlacing is unknown or the decoder does not export this information,
+top field first will be assumed.
+
+@item deint
+Specify which frames to deinterlace. Accept one of the following
+values:
+
+@table @option
+@item 0, all
+Deinterlace all frames.
+@item 1, interlaced
+Only deinterlace frames marked as interlaced.
+@end table
+
+The default value is @code{all}.
+@end table
+
+@section yadif_cuda
+
+Deinterlace the input video using the @ref{yadif} algorithm, but implemented
+in CUDA so that it can work as part of a GPU accelerated pipeline with nvdec
+and/or nvenc.
+
+It accepts the following parameters:
+
+
 @table @option
 
 @item mode
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index ffbcb40806..4b78b29fad 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -408,6 +408,7 @@ OBJS-$(CONFIG_WEAVE_FILTER)  += vf_weave.o
 OBJS-$(CONFIG_XBR_FILTER)+= vf_xbr.o
 OBJS-$(CONFIG_XSTACK_FILTER) += vf_stack.o framesync.o
 OBJS-$(CONFIG_YADIF_FILTER)  += vf_yadif.o yadif_common.o
+OBJS-$(CONFIG_YADIF_CUDA_FILTER) += vf_yadif_cuda.o 
vf_yadif_cuda.ptx.o yadif_common.o
 OBJS-$(CONFIG_ZMQ_FILTER)+= f_zmq.o
 OBJS-$(CONFIG_ZOOMPAN_FILTER)+= vf_zoompan.o
 OBJS-$(CONFIG_ZSCALE_FILTER) += vf_zscale.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index d5a211bda5..c40c7e3a3c 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -389,6 +389,7 @@ extern AVFilter ff_vf_weave;
 extern AVFilter ff_vf_xbr;
 extern AVFilter ff_vf_xstack;
 extern AVFilter ff_vf_yadif;
+extern AVFilter ff_vf_yadif_cuda;
 extern AVFilter ff_vf_zmq;
 extern AVFilter ff_vf_zoompan;
 extern AVFilter ff_vf_zscale;
diff --git a/libavfilter/vf_yadif_cuda.c b/libavfilter/vf_yadif_cuda.c
new file mode 100644
index 00..be22344d9d
--- /dev/null
+++ b/libavfilter/vf_yadif_cuda.c
@@ -0,0 +1,426 @@
+/*
+ * Copyright (C) 2018 Philip Langdale 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include "libavutil/avassert.h"
+#include "liba

[FFmpeg-devel] [PATCH 0/3] CUDA implementation of yadif filter v2

[Philip Langdale]

This patch series adds a CUDA implementation of yadif so that we have
a deinterlacing option when doing full GPU transcode or playback with
nvdec and/or nvenc. The nvidia deinterlacer cannot be used with the
nvdec decoder because an hwaccel cannot return more than one frame
per input packet. (It does work with the cuviddec decoder which is
a full decoder, but uses nvidia's parsers which tend to be more
limited than the ffmpeg ones).

This update includes minor changes to reflect feedback. I will bump
the minor version when I push.

Philip Langdale (3):
  libavfilter/vf_yadif: Make frame management logic and options
shareable
  avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer
  avcodec/nvdec: Increase frame pool size to help deinterlacing

 Changelog|   1 +
 configure|   1 +
 doc/filters.texi |  58 +
 libavcodec/nvdec.c   |   6 +-
 libavfilter/Makefile |   3 +-
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_yadif.c   | 196 +---
 libavfilter/vf_yadif_cuda.c  | 426 +++
 libavfilter/vf_yadif_cuda.cu | 296 
 libavfilter/yadif.h  |   9 +
 libavfilter/yadif_common.c   | 209 +
 11 files changed, 1017 insertions(+), 189 deletions(-)
 create mode 100644 libavfilter/vf_yadif_cuda.c
 create mode 100644 libavfilter/vf_yadif_cuda.cu
 create mode 100644 libavfilter/yadif_common.c

-- 
2.19.1

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

[FFmpeg-devel] [PATCH 1/3] libavfilter/vf_yadif: Make frame management logic and options shareable

[Philip Langdale]

I'm writing a cuda implementation of yadif, and while this
obviously has a very different implementation of the actual
filtering, all the frame management is unchanged. To avoid
duplicating that logic, let's make it shareable.

From the perspective of the existing filter, the only real change
is introducing a function pointer for the filter() function so it
can be specified for the specific filter.

Signed-off-by: Philip Langdale 
---
 libavfilter/Makefile   |   2 +-
 libavfilter/vf_yadif.c | 196 ++
 libavfilter/yadif.h|   9 ++
 libavfilter/yadif_common.c | 209 +
 4 files changed, 228 insertions(+), 188 deletions(-)
 create mode 100644 libavfilter/yadif_common.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index c35cd8f422..ffbcb40806 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -407,7 +407,7 @@ OBJS-$(CONFIG_WAVEFORM_FILTER)   += 
vf_waveform.o
 OBJS-$(CONFIG_WEAVE_FILTER)  += vf_weave.o
 OBJS-$(CONFIG_XBR_FILTER)+= vf_xbr.o
 OBJS-$(CONFIG_XSTACK_FILTER) += vf_stack.o framesync.o
-OBJS-$(CONFIG_YADIF_FILTER)  += vf_yadif.o
+OBJS-$(CONFIG_YADIF_FILTER)  += vf_yadif.o yadif_common.o
 OBJS-$(CONFIG_ZMQ_FILTER)+= f_zmq.o
 OBJS-$(CONFIG_ZOOMPAN_FILTER)+= vf_zoompan.o
 OBJS-$(CONFIG_ZSCALE_FILTER) += vf_zscale.o
diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
index f58d8ac2bc..3107924932 100644
--- a/libavfilter/vf_yadif.c
+++ b/libavfilter/vf_yadif.c
@@ -22,7 +22,6 @@
 #include "libavutil/avassert.h"
 #include "libavutil/cpu.h"
 #include "libavutil/common.h"
-#include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/imgutils.h"
 #include "avfilter.h"
@@ -254,166 +253,6 @@ static void filter(AVFilterContext *ctx, AVFrame *dstpic,
 emms_c();
 }
 
-static int return_frame(AVFilterContext *ctx, int is_second)
-{
-YADIFContext *yadif = ctx->priv;
-AVFilterLink *link  = ctx->outputs[0];
-int tff, ret;
-
-if (yadif->parity == -1) {
-tff = yadif->cur->interlaced_frame ?
-  yadif->cur->top_field_first : 1;
-} else {
-tff = yadif->parity ^ 1;
-}
-
-if (is_second) {
-yadif->out = ff_get_video_buffer(link, link->w, link->h);
-if (!yadif->out)
-return AVERROR(ENOMEM);
-
-av_frame_copy_props(yadif->out, yadif->cur);
-yadif->out->interlaced_frame = 0;
-}
-
-filter(ctx, yadif->out, tff ^ !is_second, tff);
-
-if (is_second) {
-int64_t cur_pts  = yadif->cur->pts;
-int64_t next_pts = yadif->next->pts;
-
-if (next_pts != AV_NOPTS_VALUE && cur_pts != AV_NOPTS_VALUE) {
-yadif->out->pts = cur_pts + next_pts;
-} else {
-yadif->out->pts = AV_NOPTS_VALUE;
-}
-}
-ret = ff_filter_frame(ctx->outputs[0], yadif->out);
-
-yadif->frame_pending = (yadif->mode&1) && !is_second;
-return ret;
-}
-
-static int checkstride(YADIFContext *yadif, const AVFrame *a, const AVFrame *b)
-{
-int i;
-for (i = 0; i < yadif->csp->nb_components; i++)
-if (a->linesize[i] != b->linesize[i])
-return 1;
-return 0;
-}
-
-static void fixstride(AVFilterLink *link, AVFrame *f)
-{
-AVFrame *dst = ff_default_get_video_buffer(link, f->width, f->height);
-if(!dst)
-return;
-av_frame_copy_props(dst, f);
-av_image_copy(dst->data, dst->linesize,
-  (const uint8_t **)f->data, f->linesize,
-  dst->format, dst->width, dst->height);
-av_frame_unref(f);
-av_frame_move_ref(f, dst);
-av_frame_free(&dst);
-}
-
-static int filter_frame(AVFilterLink *link, AVFrame *frame)
-{
-AVFilterContext *ctx = link->dst;
-YADIFContext *yadif = ctx->priv;
-
-av_assert0(frame);
-
-if (yadif->frame_pending)
-return_frame(ctx, 1);
-
-if (yadif->prev)
-av_frame_free(&yadif->prev);
-yadif->prev = yadif->cur;
-yadif->cur  = yadif->next;
-yadif->next = frame;
-
-if (!yadif->cur &&
-!(yadif->cur = av_frame_clone(yadif->next)))
-return AVERROR(ENOMEM);
-
-if (checkstride(yadif, yadif->next, yadif->cur)) {
-av_log(ctx, AV_LOG_VERBOSE, "Reallocating frame due to differing 
stride\n");
-fixstride(link, yadif->next);
-}
-if (checkstride(yadif, yadif->next, yadif->cur))
-fixstride(link, yadif->cur);
-if (yadif->prev && checkstride(yadif, yadif->next, yadif->prev))
-fixstride(link, yadif->prev);
-if (checkstride(yadif, yadif->next, yadif->cur) || (yadif->prev && 
checkstride(yadif, yadif->next, yadif->prev))) {
-av_log(ctx, AV_LOG_ERROR, "Failed to reallocate frame\n");
-return -1;
-}
-
-if (!yadif->prev)
-return 0;
-
-if ((yadif->deint && !yadif->cur->interlaced_frame) ||
-  

Re: [FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

[Philip Langdale]

On Thu, 1 Nov 2018 22:16:53 +0100
Hendrik Leppkes  wrote:

> One might do something like this:
> 
> NVDEC -> hwdownload -> yadif -> x264
> NVDEC -> cuda_yadif -> hwdownload -> x264
> 
> How do those compare, maybe when you replace x264 with null?

I set my baseline with NVDEC -> hwdownload -> null.

I then compared hwdownload->yadif and cuda_yadif->hwdownload with
same_frame and same_field.

* hwdownload->yadif=same_frame: 70%
* hwdownload->yadif=same_field: 56%
* cuda_yadif=same_frame->hwdownload: 88%
* cuda_yadif=same_field->hwdownload: 69%

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

Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Disable writing CODECS tag for HEVC streams

[Jeyapal, Karthick]

On 10/21/18 4:45 PM, Jeyapal, Karthick wrote:
>
> On 10/21/18 2:28 PM, Hendrik Leppkes wrote:
>> On Sun, Oct 21, 2018 at 10:41 AM Karthick J  wrote:
>>>
>>> For HEVC streams, only the FourCC tag is written without profile, level 
>>> etc.,
>>> This is breaking playout support in native Safari.
>>> Native Safari playout expects the full info in CODECS tag or None at all.
>>
>> Generating the full string shouldn't be that impossible for HEVC
>> either, why not go that more complete route?
> Two reasons:
> 1. I was not sure what is the right format of that string. I saw some 
> examples, like hvc1.2.4.L123.B0. But I didn't know what that meant.
> If somebody here could provide some explanation or the relevant spec, I will 
> hold off this patch and would definitely try implementing it.
>
> 2. I heard recently in a demuxed talk that for 2K and 4K resolution Apple 
> clients don't playout properly even when properly constructed CODEC tag is 
> there(hvc1.2.4.L153).
> But they played properly without a CODEC tag. 
> https://www.twitch.tv/videos/323919819 , Seek to 42:30 for the relevant info.
>
> For the above two reasons, I assumed it is going to be a time-consuming job. 
> Hence, I decided to atleast restore the earlier status for HEVC, so that we 
> don't break anything that was working properly earlier.
Pushed.
>>
>> - Hendrik
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/ivfenc: use the av1_metadata bsf to insert Temporal Delimiter OBUs if needed

[James Almer]

On 10/4/2018 7:48 PM, Mark Thompson wrote:
> On 04/10/18 00:12, James Almer wrote:
>> On 10/3/2018 8:01 PM, Mark Thompson wrote:
>>> On 03/10/18 01:18, James Almer wrote:
 Signed-off-by: James Almer 
 ---
  libavformat/ivfenc.c | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
 index 66441a2a43..adf72117e9 100644
 --- a/libavformat/ivfenc.c
 +++ b/libavformat/ivfenc.c
 @@ -97,6 +97,8 @@ static int ivf_check_bitstream(struct AVFormatContext 
 *s, const AVPacket *pkt)
  
  if (st->codecpar->codec_id == AV_CODEC_ID_VP9)
  ret = ff_stream_add_bitstream_filter(st, "vp9_superframe", NULL);
 +else if (st->codecpar->codec_id == AV_CODEC_ID_AV1)
 +ret = ff_stream_add_bitstream_filter(st, "av1_metadata", 
 "td=insert");
  
  return ret;
  }

>>>
>>> I'm not quite seeing why this is wanted - could you explain it a bit 
>>> further?
>>>
>>> (Since IVF is packetised into temporal units already, it seems to me that 
>>> having TDs or not in the file won't change anything from the point of view 
>>> of the consumer.)
>>
>> No, but ivf afaik doesn't suggest or mandate the removal of TDs, unlike
>> mp4 and matroska, so i figured it would be best to put them back in
>> place for such remuxing scenarios.
>>
>> I don't mind dropping this patch.
> 
> No preference - I don't have any arguments one way or the other.
> 
> If you think it's a good idea then it looks fine to me, though probably the 
> IVF muxer needs to select av1_metadata in configure to match.  (Several 
> muxers seem to be missing these dependencies, including IVF on vp9_superframe 
> - patch incoming.)
> 
> Thanks,
> 
> - Mark

aomenc doesn't remove them, and other muxers like mkvextract readd them
if missing as well, so configure dep added, and pushed.

Thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add CUDA function cuDeviceGetAttribute

[Soft Works]

> Those headers come straight from nvidia under a free license(MIT) and
> are just slightly modified for better compatibility.

> There is no such thing for CUDA sadly.

Thanks. I made the requested changes and submitted a new patch.


In this context, I wonder if there is some explanation somewhere about the
differences between the cuvid and nvdec codec implementations.

I understand the ffmpeg side where cuvid is a full codec and nvdec is 
implemented as hwaccel. 

What adds to the confusion is that the hwaccel is called 'cuda'.


What I'm wondering now is what difference all this makes at the side
of the GPU acceleration, doesn't this end up being just the same?
Why do we have that dual implementation?

Thanks again,

softworkz


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

[FFmpeg-devel] [PATCH] Add CUDA function cuDeviceGetAttribute V2

[Soft Works]

Signed-off-by: softworkz 
---
 include/ffnvcodec/dynlink_cuda.h   | 26 ++
 include/ffnvcodec/dynlink_loader.h |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/include/ffnvcodec/dynlink_cuda.h b/include/ffnvcodec/dynlink_cuda.h
index 373215d..069acd1 100644
--- a/include/ffnvcodec/dynlink_cuda.h
+++ b/include/ffnvcodec/dynlink_cuda.h
@@ -59,6 +59,31 @@ typedef enum cudaError_enum {
 CUDA_ERROR_NOT_READY = 600
 } CUresult;
 
+/**
+ * Device properties (subset)
+ */
+typedef enum CUdevice_attribute_enum {
+CU_DEVICE_ATTRIBUTE_CLOCK_RATE = 13,
+CU_DEVICE_ATTRIBUTE_MULTIPROCESSOR_COUNT = 16,
+CU_DEVICE_ATTRIBUTE_INTEGRATED = 18,
+CU_DEVICE_ATTRIBUTE_CAN_MAP_HOST_MEMORY = 19,
+CU_DEVICE_ATTRIBUTE_COMPUTE_MODE = 20,
+CU_DEVICE_ATTRIBUTE_CONCURRENT_KERNELS = 31,
+CU_DEVICE_ATTRIBUTE_PCI_BUS_ID = 33,
+CU_DEVICE_ATTRIBUTE_PCI_DEVICE_ID = 34,
+CU_DEVICE_ATTRIBUTE_TCC_DRIVER = 35,
+CU_DEVICE_ATTRIBUTE_MEMORY_CLOCK_RATE = 36,
+CU_DEVICE_ATTRIBUTE_GLOBAL_MEMORY_BUS_WIDTH = 37,
+CU_DEVICE_ATTRIBUTE_ASYNC_ENGINE_COUNT = 40,
+CU_DEVICE_ATTRIBUTE_UNIFIED_ADDRESSING = 41,
+CU_DEVICE_ATTRIBUTE_PCI_DOMAIN_ID = 50,
+CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR = 75,
+CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR = 76,
+CU_DEVICE_ATTRIBUTE_MANAGED_MEMORY = 83,
+CU_DEVICE_ATTRIBUTE_MULTI_GPU_BOARD = 84,
+CU_DEVICE_ATTRIBUTE_MULTI_GPU_BOARD_GROUP_ID = 85,
+} CUdevice_attribute;
+
 typedef enum CUarray_format_enum {
 CU_AD_FORMAT_UNSIGNED_INT8  = 0x01,
 CU_AD_FORMAT_UNSIGNED_INT16 = 0x02,
@@ -184,6 +209,7 @@ typedef void CUDAAPI CUstreamCallback(CUstream hStream, 
CUresult status, void *u
 typedef CUresult CUDAAPI tcuInit(unsigned int Flags);
 typedef CUresult CUDAAPI tcuDeviceGetCount(int *count);
 typedef CUresult CUDAAPI tcuDeviceGet(CUdevice *device, int ordinal);
+typedef CUresult CUDAAPI tcuDeviceGetAttribute(int *pi, CUdevice_attribute 
attrib, CUdevice dev);
 typedef CUresult CUDAAPI tcuDeviceGetName(char *name, int len, CUdevice dev);
 typedef CUresult CUDAAPI tcuDeviceGetUuid(CUuuid *uuid, CUdevice dev);
 typedef CUresult CUDAAPI tcuDeviceComputeCapability(int *major, int *minor, 
CUdevice dev);
diff --git a/include/ffnvcodec/dynlink_loader.h 
b/include/ffnvcodec/dynlink_loader.h
index bce9630..c9472fe 100644
--- a/include/ffnvcodec/dynlink_loader.h
+++ b/include/ffnvcodec/dynlink_loader.h
@@ -139,6 +139,7 @@ typedef struct CudaFunctions {
 tcuInit *cuInit;
 tcuDeviceGetCount *cuDeviceGetCount;
 tcuDeviceGet *cuDeviceGet;
+tcuDeviceGetAttribute *cuDeviceGetAttribute;
 tcuDeviceGetName *cuDeviceGetName;
 tcuDeviceGetUuid *cuDeviceGetUuid;
 tcuDeviceComputeCapability *cuDeviceComputeCapability;
@@ -248,6 +249,7 @@ static inline int cuda_load_functions(CudaFunctions 
**functions, void *logctx)
 LOAD_SYMBOL(cuInit, tcuInit, "cuInit");
 LOAD_SYMBOL(cuDeviceGetCount, tcuDeviceGetCount, "cuDeviceGetCount");
 LOAD_SYMBOL(cuDeviceGet, tcuDeviceGet, "cuDeviceGet");
+LOAD_SYMBOL(cuDeviceGetAttribute, tcuDeviceGetAttribute, 
"cuDeviceGetAttribute");
 LOAD_SYMBOL(cuDeviceGetName, tcuDeviceGetName, "cuDeviceGetName");
 LOAD_SYMBOL(cuDeviceGetUuid, tcuDeviceGetUuid, "cuDeviceGetUuid");
 LOAD_SYMBOL(cuDeviceComputeCapability, tcuDeviceComputeCapability, 
"cuDeviceComputeCapability");
-- 
2.17.1.windows.2

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

Re: [FFmpeg-devel] [PATCH] Add CUDA function cuDeviceGetAttribute

[Timo Rothenpieler]

On 02.11.2018 00:09, Soft Works wrote:

That enum is _way_ too massive. Most of that seems entirely useless in
the context of ffmpeg anyway, like all the 1D and 3D stuff, and probably
most of the 2D stuff as well.


I copied the full enum to have an exact match to cuda.h, but no problem, I can 
trim it down.


Can you trim it down to only those exact ones you need? Also, just get
rid of the comments, we're not doing that anywhere else anyway.


I kept them because dynlink_cuviddec.h has all comments included as well.
Should I still remove them in this case?


Those headers come straight from nvidia under a free license(MIT) and 
are just slightly modified for better compatibility.


There is no such thing for CUDA sadly.



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

Re: [FFmpeg-devel] [PATCH] Add CUDA function cuDeviceGetAttribute

[Soft Works]

> That enum is _way_ too massive. Most of that seems entirely useless in
> the context of ffmpeg anyway, like all the 1D and 3D stuff, and probably
> most of the 2D stuff as well.

I copied the full enum to have an exact match to cuda.h, but no problem, I can 
trim it down.

> Can you trim it down to only those exact ones you need? Also, just get
> rid of the comments, we're not doing that anywhere else anyway.

I kept them because dynlink_cuviddec.h has all comments included as well.
Should I still remove them in this case?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add CUDA function cuDeviceGetAttribute

[Timo Rothenpieler]

That enum is _way_ too massive. Most of that seems entirely useless in 
the context of ffmpeg anyway, like all the 1D and 3D stuff, and probably 
most of the 2D stuff as well.


Can you trim it down to only those exact ones you need? Also, just get 
rid of the comments, we're not doing that anywhere else anyway.




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

[FFmpeg-devel] [PATCH] Add CUDA function cuDeviceGetAttribute

[Soft Works]

Signed-off-by: softworkz 
---
 include/ffnvcodec/dynlink_cuda.h   | 104 +
 include/ffnvcodec/dynlink_loader.h |   2 +
 2 files changed, 106 insertions(+)

diff --git a/include/ffnvcodec/dynlink_cuda.h b/include/ffnvcodec/dynlink_cuda.h
index 373215d..b16e9a5 100644
--- a/include/ffnvcodec/dynlink_cuda.h
+++ b/include/ffnvcodec/dynlink_cuda.h
@@ -59,6 +59,109 @@ typedef enum cudaError_enum {
 CUDA_ERROR_NOT_READY = 600
 } CUresult;
 
+/**
+ * Device properties
+ */
+typedef enum CUdevice_attribute_enum {
+CU_DEVICE_ATTRIBUTE_MAX_THREADS_PER_BLOCK = 1,  /**< Maximum 
number of threads per block */
+CU_DEVICE_ATTRIBUTE_MAX_BLOCK_DIM_X = 2,/**< Maximum 
block dimension X */
+CU_DEVICE_ATTRIBUTE_MAX_BLOCK_DIM_Y = 3,/**< Maximum 
block dimension Y */
+CU_DEVICE_ATTRIBUTE_MAX_BLOCK_DIM_Z = 4,/**< Maximum 
block dimension Z */
+CU_DEVICE_ATTRIBUTE_MAX_GRID_DIM_X = 5, /**< Maximum 
grid dimension X */
+CU_DEVICE_ATTRIBUTE_MAX_GRID_DIM_Y = 6, /**< Maximum 
grid dimension Y */
+CU_DEVICE_ATTRIBUTE_MAX_GRID_DIM_Z = 7, /**< Maximum 
grid dimension Z */
+CU_DEVICE_ATTRIBUTE_MAX_SHARED_MEMORY_PER_BLOCK = 8,/**< Maximum 
shared memory available per block in bytes */
+CU_DEVICE_ATTRIBUTE_SHARED_MEMORY_PER_BLOCK = 8,/**< 
Deprecated, use CU_DEVICE_ATTRIBUTE_MAX_SHARED_MEMORY_PER_BLOCK */
+CU_DEVICE_ATTRIBUTE_TOTAL_CONSTANT_MEMORY = 9,  /**< Memory 
available on device for __constant__ variables in a CUDA C kernel in bytes */
+CU_DEVICE_ATTRIBUTE_WARP_SIZE = 10, /**< Warp size 
in threads */
+CU_DEVICE_ATTRIBUTE_MAX_PITCH = 11, /**< Maximum 
pitch in bytes allowed by memory copies */
+CU_DEVICE_ATTRIBUTE_MAX_REGISTERS_PER_BLOCK = 12,   /**< Maximum 
number of 32-bit registers available per block */
+CU_DEVICE_ATTRIBUTE_REGISTERS_PER_BLOCK = 12,   /**< 
Deprecated, use CU_DEVICE_ATTRIBUTE_MAX_REGISTERS_PER_BLOCK */
+CU_DEVICE_ATTRIBUTE_CLOCK_RATE = 13,/**< Typical 
clock frequency in kilohertz */
+CU_DEVICE_ATTRIBUTE_TEXTURE_ALIGNMENT = 14, /**< Alignment 
requirement for textures */
+CU_DEVICE_ATTRIBUTE_GPU_OVERLAP = 15,   /**< Device 
can possibly copy memory and execute a kernel concurrently. Deprecated. Use 
instead CU_DEVICE_ATTRIBUTE_ASYNC_ENGINE_COUNT. */
+CU_DEVICE_ATTRIBUTE_MULTIPROCESSOR_COUNT = 16,  /**< Number of 
multiprocessors on device */
+CU_DEVICE_ATTRIBUTE_KERNEL_EXEC_TIMEOUT = 17,   /**< Specifies 
whether there is a run time limit on kernels */
+CU_DEVICE_ATTRIBUTE_INTEGRATED = 18,/**< Device is 
integrated with host memory */
+CU_DEVICE_ATTRIBUTE_CAN_MAP_HOST_MEMORY = 19,   /**< Device 
can map host memory into CUDA address space */
+CU_DEVICE_ATTRIBUTE_COMPUTE_MODE = 20,  /**< Compute 
mode (See ::CUcomputemode for details) */
+CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE1D_WIDTH = 21,   /**< Maximum 
1D texture width */
+CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE2D_WIDTH = 22,   /**< Maximum 
2D texture width */
+CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE2D_HEIGHT = 23,  /**< Maximum 
2D texture height */
+CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE3D_WIDTH = 24,   /**< Maximum 
3D texture width */
+CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE3D_HEIGHT = 25,  /**< Maximum 
3D texture height */
+CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE3D_DEPTH = 26,   /**< Maximum 
3D texture depth */
+CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE2D_LAYERED_WIDTH = 27,   /**< Maximum 
2D layered texture width */
+CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE2D_LAYERED_HEIGHT = 28,  /**< Maximum 
2D layered texture height */
+CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE2D_LAYERED_LAYERS = 29,  /**< Maximum 
layers in a 2D layered texture */
+CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE2D_ARRAY_WIDTH = 27, /**< 
Deprecated, use CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE2D_LAYERED_WIDTH */
+CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE2D_ARRAY_HEIGHT = 28,/**< 
Deprecated, use CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE2D_LAYERED_HEIGHT */
+CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE2D_ARRAY_NUMSLICES = 29, /**< 
Deprecated, use CU_DEVICE_ATTRIBUTE_MAXIMUM_TEXTURE2D_LAYERED_LAYERS */
+CU_DEVICE_ATTRIBUTE_SURFACE_ALIGNMENT = 30, /**< Alignment 
requirement for surfaces */
+CU_DEVICE_ATTRIBUTE_CONCURRENT_KERNELS = 31,/**< Device 
can possibly execute multiple kernels concurrently */
+CU_DEVICE_ATTRIBUTE_ECC_ENABLED = 32,   /**< Device 
has ECC support enabled */
+CU_DEVICE_ATTRIBUTE_PCI_BUS_ID = 33,/**< PCI bus 
ID of the device */
+CU_DEVICE_ATTRIBUTE_PCI_DEV

[FFmpeg-devel] Add CUDA function cuDeviceGetAttribute.

[Soft Works]

0001-Add-CUDA-function-cuDeviceGetAttribute.patch
Description: 0001-Add-CUDA-function-cuDeviceGetAttribute.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag

[Marton Balint]

On Wed, 24 Oct 2018, James Almer wrote:


On 10/24/2018 6:43 PM, Marton Balint wrote:



On Tue, 23 Oct 2018, Henrik Gramner wrote:


On Tue, Oct 23, 2018 at 3:22 PM Derek Buitenhuis
 wrote:

I'd like to point out that this patch or some variant may be required
anyway.

libx264 only uses strtok_r or strtok_s if available on the platform.

See:
https://git.videolan.org/?p=x264.git;a=blob;f=common/osdep.h;h=715ef8a00c01ad5a94de2b29a422429b9b1f0a53;hb=HEAD#l75


The real fix is to bundle a strtok_r implementation, or to just outright
require strtok_r/strtok_s. Sad, I know.

What platforms that x264 supports don't have it anyway?


Honestly no idea, probably something obscure.


Well, then maybe x264 configure should simply fail for those.

I pushed the patch, once the strtok fix is merged to stable and we know
the build number, the flag can be re-introduced with an #if.

Regards,
Marton


This should be backported to supported branches, or at least 2.8, 3.2,
3.4 and 4.0


I did it for 4.0, I leave the rest for others.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/ftp: return AVERROR_EOF for EOF

[Marton Balint]

On Thu, 1 Nov 2018, Nicolas George wrote:


Marton Balint (2018-11-01):

Without this FTP just hangs on eof...

Signed-off-by: Marton Balint 
---
 libavformat/ftp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


LGTM.


Thanks, pushed and backported to 4.0.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] lavu/hwcontext_amf: HWContext for AMF based components

[akravchenko188]

From: Alexander Kravchenko 

---
 libavutil/Makefile |   2 +
 libavutil/hwcontext.c  |   4 +
 libavutil/hwcontext.h  |   1 +
 libavutil/hwcontext_amf.c  | 290 +
 libavutil/hwcontext_amf.h  |  53 ++
 libavutil/hwcontext_internal.h |   1 +
 6 files changed, 351 insertions(+)
 create mode 100644 libavutil/hwcontext_amf.c
 create mode 100644 libavutil/hwcontext_amf.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 9ed24cfc82..d8b9f03d43 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -157,6 +157,7 @@ OBJS = adler32.o
\
xtea.o   \
tea.o\
 
+OBJS-$(CONFIG_AMF)  += hwcontext_amf.o
 OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o
 OBJS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.o
 OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o
@@ -174,6 +175,7 @@ OBJS += $(COMPAT_OBJS:%=../compat/%)
 # Windows resource file
 SLIBOBJS-$(HAVE_GNU_WINDRES)+= avutilres.o
 
+SKIPHEADERS-$(CONFIG_AMF)  += hwcontext_amf.h
 SKIPHEADERS-$(HAVE_CUDA_H) += hwcontext_cuda.h
 SKIPHEADERS-$(CONFIG_CUDA) += hwcontext_cuda_internal.h
 SKIPHEADERS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.h
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index f1e404ab20..642f3ca5d0 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -29,6 +29,9 @@
 #include "pixfmt.h"
 
 static const HWContextType * const hw_table[] = {
+#if CONFIG_AMF
+&ff_hwcontext_type_amf,
+#endif
 #if CONFIG_CUDA
 &ff_hwcontext_type_cuda,
 #endif
@@ -63,6 +66,7 @@ static const HWContextType * const hw_table[] = {
 };
 
 static const char *const hw_type_names[] = {
+[AV_HWDEVICE_TYPE_AMF]= "amf",
 [AV_HWDEVICE_TYPE_CUDA]   = "cuda",
 [AV_HWDEVICE_TYPE_DRM]= "drm",
 [AV_HWDEVICE_TYPE_DXVA2]  = "dxva2",
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index f5a4b62387..b18591205a 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -36,6 +36,7 @@ enum AVHWDeviceType {
 AV_HWDEVICE_TYPE_DRM,
 AV_HWDEVICE_TYPE_OPENCL,
 AV_HWDEVICE_TYPE_MEDIACODEC,
+AV_HWDEVICE_TYPE_AMF,
 };
 
 typedef struct AVHWDeviceInternal AVHWDeviceInternal;
diff --git a/libavutil/hwcontext_amf.c b/libavutil/hwcontext_amf.c
new file mode 100644
index 00..b993c76a7e
--- /dev/null
+++ b/libavutil/hwcontext_amf.c
@@ -0,0 +1,290 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "config.h"
+
+ //#include "avassert.h"
+ //#include "avstring.h"
+ //#include "common.h"
+#include "hwcontext.h"
+#include "hwcontext_internal.h"
+#include "hwcontext_amf.h"
+
+#if CONFIG_D3D11VA
+#include "hwcontext_d3d11va.h"
+#endif
+
+#if CONFIG_DXVA2
+#define COBJMACROS
+#include "hwcontext_dxva2.h"
+#endif
+
+#ifdef _WIN32
+#include "compat/w32dlfcn.h"
+#else
+#include 
+#endif
+
+/**
+* Error handling helper
+*/
+#define AMFAV_RETURN_IF_FALSE(avctx, exp, ret_value, /*message,*/ ...) \
+if (!(exp)) { \
+av_log(avctx, AV_LOG_ERROR, __VA_ARGS__); \
+return ret_value; \
+}
+
+/**
+* AMF library context: amflib_class, amflib_context, amf_trace_writer
+* AMF library has global tracer settings. It is set global library context
+* to path AMF logs to av_log with library class
+*
+*/
+static const AVClass amflib_class = {
+.class_name = "amf",
+.item_name = av_default_item_name,
+.version = LIBAVUTIL_VERSION_INT,
+};
+
+typedef struct AMFLibraryContext {
+const AVClass  *avclass;
+} AMFLibraryContext;
+
+static AMFLibraryContext amflib_context =
+{
+.avclass = &amflib_class,
+};
+
+typedef struct AmfTraceWriter {
+const AMFTraceWriterVtbl*vtbl;
+void*avcl;
+} AmfTraceWriter;
+
+static void AMF_CDECL_CALL AMFTraceWriter_Write(AMFTraceWriter *pThis,
+const wchar_t *scope, const wchar_t *message)
+{
+AmfTraceWriter *tracer = (AmfTraceWriter*)pThis;
+av_log(tracer->avcl, AV_LOG_DEBUG, "%ls: %ls", scope, message);
+}
+
+static void A

[FFmpeg-devel] [PATCH 2/2] lavc/amfenc: redesign to use hwcontext_amf

[akravchenko188]

From: Alexander Kravchenko 

---
 libavcodec/amfenc.c | 252 +---
 libavcodec/amfenc.h |  27 ++---
 2 files changed, 34 insertions(+), 245 deletions(-)

diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
index 384d8efc92..24a4d2ad92 100644
--- a/libavcodec/amfenc.c
+++ b/libavcodec/amfenc.c
@@ -21,13 +21,6 @@
 #include "libavutil/avassert.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/hwcontext.h"
-#if CONFIG_D3D11VA
-#include "libavutil/hwcontext_d3d11va.h"
-#endif
-#if CONFIG_DXVA2
-#define COBJMACROS
-#include "libavutil/hwcontext_dxva2.h"
-#endif
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/time.h"
@@ -35,18 +28,14 @@
 #include "amfenc.h"
 #include "internal.h"
 
-#if CONFIG_D3D11VA
-#include 
+#if CONFIG_DXVA2
+#include 
 #endif
 
-#ifdef _WIN32
-#include "compat/w32dlfcn.h"
-#else
-#include 
+#if CONFIG_D3D11VA
+#include 
 #endif
 
-#define FFMPEG_AMF_WRITER_ID L"ffmpeg_amf"
-
 #define PTS_PROP L"PtsProp"
 
 const enum AVPixelFormat ff_amf_pix_fmts[] = {
@@ -88,34 +77,18 @@ static enum AMF_SURFACE_FORMAT amf_av_to_amf_format(enum 
AVPixelFormat fmt)
 return AMF_SURFACE_UNKNOWN;
 }
 
-static void AMF_CDECL_CALL AMFTraceWriter_Write(AMFTraceWriter *pThis,
-const wchar_t *scope, const wchar_t *message)
-{
-AmfTraceWriter *tracer = (AmfTraceWriter*)pThis;
-av_log(tracer->avctx, AV_LOG_DEBUG, "%ls: %ls", scope, message); // \n is 
provided from AMF
-}
 
-static void AMF_CDECL_CALL AMFTraceWriter_Flush(AMFTraceWriter *pThis)
-{
-}
-
-static AMFTraceWriterVtbl tracer_vtbl =
-{
-.Write = AMFTraceWriter_Write,
-.Flush = AMFTraceWriter_Flush,
-};
-
-static int amf_load_library(AVCodecContext *avctx)
+static int amf_init_context(AVCodecContext *avctx)
 {
-AmfContext*ctx = avctx->priv_data;
-AMFInit_Fn init_fun;
-AMFQueryVersion_Fn version_fun;
-AMF_RESULT res;
+AmfContext *ctx = avctx->priv_data;
+AVAMFDeviceContext *amf_ctx;
+int ret;
 
 ctx->delayed_frame = av_frame_alloc();
 if (!ctx->delayed_frame) {
 return AVERROR(ENOMEM);
 }
+
 // hardcoded to current HW queue size - will realloc in 
timestamp_queue_enqueue() if too small
 ctx->timestamp_list = av_fifo_alloc((avctx->max_b_frames + 16) * 
sizeof(int64_t));
 if (!ctx->timestamp_list) {
@@ -123,119 +96,9 @@ static int amf_load_library(AVCodecContext *avctx)
 }
 ctx->dts_delay = 0;
 
-
-ctx->library = dlopen(AMF_DLL_NAMEA, RTLD_NOW | RTLD_LOCAL);
-AMF_RETURN_IF_FALSE(ctx, ctx->library != NULL,
-AVERROR_UNKNOWN, "DLL %s failed to open\n", AMF_DLL_NAMEA);
-
-init_fun = (AMFInit_Fn)dlsym(ctx->library, AMF_INIT_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, init_fun != NULL, AVERROR_UNKNOWN, "DLL %s failed 
to find function %s\n", AMF_DLL_NAMEA, AMF_INIT_FUNCTION_NAME);
-
-version_fun = (AMFQueryVersion_Fn)dlsym(ctx->library, 
AMF_QUERY_VERSION_FUNCTION_NAME);
-AMF_RETURN_IF_FALSE(ctx, version_fun != NULL, AVERROR_UNKNOWN, "DLL %s 
failed to find function %s\n", AMF_DLL_NAMEA, AMF_QUERY_VERSION_FUNCTION_NAME);
-
-res = version_fun(&ctx->version);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with 
error %d\n", AMF_QUERY_VERSION_FUNCTION_NAME, res);
-res = init_fun(AMF_FULL_VERSION, &ctx->factory);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "%s failed with 
error %d\n", AMF_INIT_FUNCTION_NAME, res);
-res = ctx->factory->pVtbl->GetTrace(ctx->factory, &ctx->trace);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetTrace() 
failed with error %d\n", res);
-res = ctx->factory->pVtbl->GetDebug(ctx->factory, &ctx->debug);
-AMF_RETURN_IF_FALSE(ctx, res == AMF_OK, AVERROR_UNKNOWN, "GetDebug() 
failed with error %d\n", res);
-return 0;
-}
-
-#if CONFIG_D3D11VA
-static int amf_init_from_d3d11_device(AVCodecContext *avctx, 
AVD3D11VADeviceContext *hwctx)
-{
-AmfContext *ctx = avctx->priv_data;
-AMF_RESULT res;
-
-res = ctx->context->pVtbl->InitDX11(ctx->context, hwctx->device, 
AMF_DX11_1);
-if (res != AMF_OK) {
-if (res == AMF_NOT_SUPPORTED)
-av_log(avctx, AV_LOG_ERROR, "AMF via D3D11 is not supported on the 
given device.\n");
-else
-av_log(avctx, AV_LOG_ERROR, "AMF failed to initialise on the given 
D3D11 device: %d.\n", res);
-return AVERROR(ENODEV);
-}
-
-return 0;
-}
-#endif
-
-#if CONFIG_DXVA2
-static int amf_init_from_dxva2_device(AVCodecContext *avctx, 
AVDXVA2DeviceContext *hwctx)
-{
-AmfContext *ctx = avctx->priv_data;
-HANDLE device_handle;
-IDirect3DDevice9 *device;
-HRESULT hr;
-AMF_RESULT res;
-int ret;
-
-hr = IDirect3DDeviceManager9_OpenDeviceHandle(hwctx->devmgr, 
&device_handle);
-if (FAILED(hr)) {
-av_log(avctx, AV_LOG_ERROR, "Failed to open device handle for 
Direct3D9 device: %lx.\n", (unsigned long)hr);
-return AVERROR_EXT

Re: [FFmpeg-devel] Maintainer of nv-codec-headers

[Timo Rothenpieler]

Send a patch to this list and I'll see if I can add it.



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

[FFmpeg-devel] Maintainer of nv-codec-headers

[Soft Works]

Hi,

I'm wondering who is the maintainer of the "nv-codec-headers" repo and what 
procedure I would need to follow to get something added there?

Actually it's not a big issue, I would just like to have the 
"cuDeviceGetAttribute" function (from cuda.h) to be added there.

Thanks,

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

Re: [FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

[Hendrik Leppkes]

On Thu, Nov 1, 2018 at 10:12 PM Philip Langdale  wrote:
>
> On 2018-11-01 14:05, Timo Rothenpieler wrote:
> > On 01.11.2018 21:54, Carl Eugen Hoyos wrote:
> >> 2018-10-26 17:56 GMT+02:00, Philip Langdale :
> >>
> >> Could you add some sample numbers about how fast the cuda
> >> variant is compared to cpu?
> >
> > I don't think such numbers are overly useful by themselves.
> > The primary benefit here is that it's now possible to decode,
> > deinterlace and encode all without pulling the frames out of VRAM.
> >
> > Though it would definitely be interesting. I guess hwupload +
> > yadif_cuda + hwdownload vs. normal yadif is a fair comparison?
>
> Yeah, the comparison is a bit fuzzy, because you completely
> change how you think about solving the problem depending on whether
> you have a filter available or not. But I did get some data previously.
>
> For cpu decode + cpu yadif, the yadif slowdown is ~50%
> For gpu decode + gpu yadif, the yadif slowdown is ~25%
>
> That means, the fps reported by `ffmpeg` when down by 50%/25%
> respectively. This was with null encoding.
>
> I can collect data for the up/down case, but I do think it's
> unrealistic - no one would actually do that.
>

One might do something like this:

NVDEC -> hwdownload -> yadif -> x264
NVDEC -> cuda_yadif -> hwdownload -> x264

How do those compare, maybe when you replace x264 with null?

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

Re: [FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

[Carl Eugen Hoyos]

2018-11-01 22:12 GMT+01:00, Philip Langdale :
> On 2018-11-01 14:05, Timo Rothenpieler wrote:
>> On 01.11.2018 21:54, Carl Eugen Hoyos wrote:
>>> 2018-10-26 17:56 GMT+02:00, Philip Langdale :
>>>
>>> Could you add some sample numbers about how fast the cuda
>>> variant is compared to cpu?
>>
>> I don't think such numbers are overly useful by themselves.
>> The primary benefit here is that it's now possible to decode,
>> deinterlace and encode all without pulling the frames out of VRAM.
>>
>> Though it would definitely be interesting. I guess hwupload +
>> yadif_cuda + hwdownload vs. normal yadif is a fair comparison?
>
> Yeah, the comparison is a bit fuzzy, because you completely
> change how you think about solving the problem depending on whether
> you have a filter available or not. But I did get some data previously.
>
> For cpu decode + cpu yadif, the yadif slowdown is ~50%
> For gpu decode + gpu yadif, the yadif slowdown is ~25%

Thank you!

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

[Philip Langdale]

On 2018-11-01 14:05, Timo Rothenpieler wrote:

On 01.11.2018 21:54, Carl Eugen Hoyos wrote:

2018-10-26 17:56 GMT+02:00, Philip Langdale :

Could you add some sample numbers about how fast the cuda
variant is compared to cpu?


I don't think such numbers are overly useful by themselves.
The primary benefit here is that it's now possible to decode,
deinterlace and encode all without pulling the frames out of VRAM.

Though it would definitely be interesting. I guess hwupload +
yadif_cuda + hwdownload vs. normal yadif is a fair comparison?


Yeah, the comparison is a bit fuzzy, because you completely
change how you think about solving the problem depending on whether
you have a filter available or not. But I did get some data previously.

For cpu decode + cpu yadif, the yadif slowdown is ~50%
For gpu decode + gpu yadif, the yadif slowdown is ~25%

That means, the fps reported by `ffmpeg` when down by 50%/25%
respectively. This was with null encoding.

I can collect data for the up/down case, but I do think it's
unrealistic - no one would actually do that.

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

Re: [FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

[Timo Rothenpieler]

On 01.11.2018 21:54, Carl Eugen Hoyos wrote:

2018-10-26 17:56 GMT+02:00, Philip Langdale :

Could you add some sample numbers about how fast the cuda
variant is compared to cpu?


I don't think such numbers are overly useful by themselves.
The primary benefit here is that it's now possible to decode, 
deinterlace and encode all without pulling the frames out of VRAM.


Though it would definitely be interesting. I guess hwupload + yadif_cuda 
+ hwdownload vs. normal yadif is a fair comparison?




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

Re: [FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

[Carl Eugen Hoyos]

2018-10-26 17:56 GMT+02:00, Philip Langdale :

Could you add some sample numbers about how fast the cuda
variant is compared to cpu?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] libavfilter/vf_yadif: Make frame management logic and options shareable

[Philip Langdale]

On 2018-11-01 12:42, Michael Niedermayer wrote:



+const AVOption yadif_options[] = {


missing prefix


I will fix. Are you otherwise happy with this change?

Thanks,

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

Re: [FFmpeg-devel] [PATCH 2/3] avfilter/vf_yadif_cuda: CUDA accelerated deinterlacer

[Timo Rothenpieler]

Not an export on CUDA code but it looks sensible to me, C part looks 
good as well.


GTM once the yadiff changes have been acked.



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

[FFmpeg-devel] Fwd: [OpenMedia] FOSDEM 2019 Open Media room - Call for speakers participation

[Kieran Kunhya]

-- Forwarded message -
From: Zohar Babin 
Date: Fri, 12 Oct 2018 at 12:50
Subject: [OpenMedia] FOSDEM 2019 Open Media room - Call for speakers
participation
To: FOSDEM , Open Media devroom <
open-media-devr...@lists.fosdem.org>


Hi all,

Join us on February 2, 2019 in Brussels for the 5th year of the Open Media
devroom at FOSDEM!

Video has gone mainstream, and technologies to handle media assets,
streams, workflows and apps at scale are now critical for many operations
both hobby and commercial.
Submit a speaking session and share your knowledge with the community at
FOSDEM! We want to learn about open standards, software or hardware
projects that deal with media.

We're looking for sessions on software or hardware spanning from building
audio / video applications, through open standards, formats, codecs, media
analytics and search, AI for creating or analyzing media, IPTV,
Broadcasting and Radio practices - anything media is welcome!

This year, the Open Media devroom will take place on:
Saturday, February 2nd, 2019.
About FOSDEM

FOSDEM is one of the largest (5,000+ hackers!) gatherings of Free and Open
Source Software contributors in the world and happens each February in
Brussels (Belgium, Europe).
About the Open Media devroom

A lot of free and open source projects are used in the media business, as
well in the broadcast industry as in the Web streaming. There are seldom
events where project members are able to share and promote their projects,
and FOSDEM is a very good place for such discussions and presentations. The
Open Media room has already been organised at FOSDEM for the last four
years, with a strong attendance and talks of great quality. We intend to
continue the work to make it even greater.
If you're interested in video, image or audio technologies, and the breadth
of available open source technologies and communities for media - the Open
Media Room is for you!
For more information about the previous year sessions:
https://archive.fosdem.org/2018/schedule/track/open_media/ .
CFP Guidelines

The deadline for submission is: December 3rd 2018 (Monday).

   - To submit your proposal, visit:
   https://penta.fosdem.org/submission/FOSDEM19
   - You can submit a session of one of the following formats:


   - lightning talks (10 minutes incl. questions)
   - regular talk (25 minutes incl. questions)
   - workshops (45 minutes or more)


   - Between sessions we will allow additional 5 minutes Q&A and 5 minutes
   for speaker switching/prep in between. Panel discussions may last longer
   (Feel free to ask if you want to have a longer or a shorter slot).
   - IMPORTANT: Please make sure to select *”Open Media devroom”* track for
   your submission.
   - You will need to create an account (or use your account from previous
   years) and then go to "create event”, and add the details of your
   presentation.
   - Selected talks will be notified by December 15th 2018.
   - All sessions will be recorded and be made available under CC-BY
   licence by FOSDEM at https://video.fosdem.org/ .

Your submission must include the following information

   - The title and subtitle of your talk (please be descriptive).
   - select *”Open Media devroom”* as the track.
   - Short single paragraph detailing what the talk will discuss, and why
   attendees should attend it.
   - A longer description if you have more details to share.
   - Links to related material/websites/blogs etc.

Community

The official communication channel is the Open Media devroom mailinglist.
Join the list at: https://lists.fosdem.org/listinfo/open-media-devroom .

And please don't hesitate to contact us for more information!

Zohar, Avital, Jess, Christophe and Kieran,
On behalf of the Open Media devroom.


___
open-media-devroom mailing list
open-media-devr...@lists.fosdem.org
https://lists.fosdem.org/listinfo/open-media-devroom
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avformat/ftp: return AVERROR_EOF for EOF

[Nicolas George]

Marton Balint (2018-11-01):
> Without this FTP just hangs on eof...
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/ftp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

LGTM.

Regards,

-- 
  Nicolas George
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] avformat/ftp: allow nonstandard 202 reply to OPTS UTF8

[Marton Balint]

Fixes ticket #7481.

Signed-off-by: Marton Balint 
---
 libavformat/ftp.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/ftp.c b/libavformat/ftp.c
index 5063b7c204..e072067480 100644
--- a/libavformat/ftp.c
+++ b/libavformat/ftp.c
@@ -513,7 +513,7 @@ static int ftp_features(FTPContext *s)
 static const char *feat_command= "FEAT\r\n";
 static const char *enable_utf8_command = "OPTS UTF8 ON\r\n";
 static const int feat_codes[] = {211, 0};
-static const int opts_codes[] = {200, 451, 0};
+static const int opts_codes[] = {200, 202, 451, 0};
 
 av_freep(&s->features);
 if (ftp_send_command(s, feat_command, feat_codes, &s->features) != 211) {
@@ -521,7 +521,8 @@ static int ftp_features(FTPContext *s)
 }
 
 if (ftp_has_feature(s, "UTF8")) {
-if (ftp_send_command(s, enable_utf8_command, opts_codes, NULL) == 200)
+int ret = ftp_send_command(s, enable_utf8_command, opts_codes, NULL);
+if (ret == 200 || ret == 202)
 s->utf8 = 1;
 }
 
-- 
2.16.4

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

[FFmpeg-devel] [PATCH 1/2] avformat/ftp: return AVERROR_EOF for EOF

[Marton Balint]

Without this FTP just hangs on eof...

Signed-off-by: Marton Balint 
---
 libavformat/ftp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/ftp.c b/libavformat/ftp.c
index 676f1c6b4c..5063b7c204 100644
--- a/libavformat/ftp.c
+++ b/libavformat/ftp.c
@@ -781,13 +781,13 @@ static int ftp_read(URLContext *h, unsigned char *buf, 
int size)
 if (s->state == DISCONNECTED) {
 /* optimization */
 if (s->position >= s->filesize)
-return 0;
+return AVERROR_EOF;
 if ((err = ftp_connect_data_connection(h)) < 0)
 return err;
 }
 if (s->state == READY) {
 if (s->position >= s->filesize)
-return 0;
+return AVERROR_EOF;
 if ((err = ftp_retrieve(s)) < 0)
 return err;
 }
-- 
2.16.4

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

Re: [FFmpeg-devel] [PATCH 1/3] libavfilter/vf_yadif: Make frame management logic and options shareable

[Michael Niedermayer]

On Fri, Oct 26, 2018 at 08:56:04AM -0700, Philip Langdale wrote:
> I'm writing a cuda implementation of yadif, and while this
> obviously has a very different implementation of the actual
> filtering, all the frame management is unchanged. To avoid
> duplicating that logic, let's make it shareable.
> 
> From the perspective of the existing filter, the only real change
> is introducing a function pointer for the filter() function so it
> can be specified for the specific filter.
> 
> Signed-off-by: Philip Langdale 
> ---
>  libavfilter/Makefile   |   2 +-
>  libavfilter/vf_yadif.c | 190 +
>  libavfilter/yadif.h|   9 ++
>  libavfilter/yadif_common.c | 209 +
>  4 files changed, 222 insertions(+), 188 deletions(-)
>  create mode 100644 libavfilter/yadif_common.c
[...]

> +#define OFFSET(x) offsetof(YADIFContext, x)
> +#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
> +
> +#define CONST(name, help, val, unit) { name, help, 0, AV_OPT_TYPE_CONST, 
> {.i64=val}, INT_MIN, INT_MAX, FLAGS, unit }
> +

> +const AVOption yadif_options[] = {

missing prefix

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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/nvdec: Increase frame pool size to help deinterlacing

[Timo Rothenpieler]

On 26.10.2018 17:56, Philip Langdale wrote:

With the cuda yadif filter in use, the number of mapped decoder
frames could increase by two, as the filter holds on to additional
frames.

Signed-off-by: Philip Langdale 
---
  libavcodec/nvdec.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/nvdec.c b/libavcodec/nvdec.c
index 4dd6b1acf3..8e91c36084 100644
--- a/libavcodec/nvdec.c
+++ b/libavcodec/nvdec.c
@@ -601,7 +601,7 @@ int ff_nvdec_frame_params(AVCodecContext *avctx,
  frames_ctx->format= AV_PIX_FMT_CUDA;
  frames_ctx->width = (avctx->coded_width + 1) & ~1;
  frames_ctx->height= (avctx->coded_height + 1) & ~1;
-frames_ctx->initial_pool_size = dpb_size;
+frames_ctx->initial_pool_size = dpb_size + 2;


A small comment here as to where that magic +2 is coming from and it's GTM.



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

Re: [FFmpeg-devel] FFmpeg 4.1

[Paul B Mahol]

On 11/1/18, Michael Niedermayer  wrote:
> On Fri, Oct 05, 2018 at 03:31:04PM -0800, Lou Logan wrote:
>> On Tue, Sep 25, 2018, at 10:50 AM, Lou Logan wrote:
>> >
>> > The users on Twitter have been asked for their suggestions. Please let
>> > me know a little while before you want to make the release and  I'll
>> > post the results here.
>>
>> Results. Number of likes are in parentheses. Multiple suggestions from a
>> single user are presented in one line.
>>
>
>> Carl (5)
>> Dr. Wöhrl (3)
>
> I think we should not name a release based on a still living person.

Why so? Do you know that every single Carl that lived is still alive and well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] FFmpeg 4.1

[Michael Niedermayer]

On Fri, Sep 14, 2018 at 03:22:56AM +0200, Michael Niedermayer wrote:
> Hi all
> 
> its almost 5 months since 4.0 so its time to make a new release.
> 
> Are there any suggestions for a name ?
> If not ill pick something from unused past suggestions.
> 
> If there are no objections i will likely make that release in the next weeks

some weeks later ...
i intend to really really soon(tm) bump minor version and branch to release/4.1
(if you want me to wait for some reason, ping me on IRC ASAP)

once the branch is created i intend to wait a few days so everyone can still
backport and change anything needed. Write release notes and all that stuff.
And then make 4.1 

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] FFmpeg 4.1

[Michael Niedermayer]

On Fri, Oct 05, 2018 at 03:31:04PM -0800, Lou Logan wrote:
> On Tue, Sep 25, 2018, at 10:50 AM, Lou Logan wrote:
> >
> > The users on Twitter have been asked for their suggestions. Please let 
> > me know a little while before you want to make the release and  I'll 
> > post the results here.
> 
> Results. Number of likes are in parentheses. Multiple suggestions from a 
> single user are presented in one line.
> 

> Carl (5)
> Dr. Wöhrl (3)

I think we should not name a release based on a still living person.


> Noether (3)
> uncut console output pls (2)
> Curie, Meitner, Lovelace, Hopper (1)
> [Muhammad ibn Musa] al-Khwarizmi (1)
> Wave
> Archimedes, Euclid, Thales, Pythagoras, Aristarchus, Eratosthenes, 
> Hipparchus, Democritus, Heron
> Schrödinger
> Hawking
> Alan Turing
> Cooks
> gary the snail
> Tesla
> Gauss
> Chaplin
> William Sealy Gosset
> Sakharov
> Newton, Maxwell, Pythagoras, Archimedes
> Satoshi, Merkle
> 
> 
> 
> Personally I prefer al-Khwarizmi or Gauss.

I like al-Khwarizmi too, it increaes diversity amongth the names
and IIUC with your and my vote that makes it 3 too.
So ill go with that but iam happy to pick some other if people
prefer and add votes still to this on the ML before the release

thx


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

Re: [FFmpeg-devel] [PATCH v2] libavdevice/libndi_newtek: Added extra_ips option to libndi_newtek allowing use remote network sources

[Marton Balint]

On Mon, 29 Oct 2018, Anton Platov wrote:


   Signed-off-by: Anton Platov 
---
doc/indevs.texi | 17 +
libavdevice/libndi_newtek_dec.c |  4 +++-
2 files changed, 20 insertions(+), 1 deletion(-)



Thanks, pushed.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] 7505

[Marton Balint]

On Thu, 1 Nov 2018, BIGLER Don (Framatome) wrote:


Fix ticket: 7505



Thanks, pushed. In the future please send git format-patch style patches.

Regards,
Marton

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

Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter

[Paul B Mahol]

On 11/1/18, Matthias Troffaes  wrote:
> Dear Paul,
>
> On Thu, Nov 1, 2018 at 11:21 AM Matthias Troffaes
>  wrote:
>> Would you consider accepting a patch that added an integer "cutoff"
>> option to tmix, for the purpose of setting all weights for frames
>> beyond "cutoff" to 0? The reason for requesting this is that in some
>> workflows, one is blending together a lot of frames at once, and
>> specifying a vector of, say, 100 ones followed by a zero, when
>> blending together, say, 200 frames, whilst possible, is rather
>> tedious; for instance "tmix=frames=200:cutoff=100" (weights are 1 by
>> default so this should then work as expected).
>
> I found a way of doing this differently, as I now found that tmix
> doesn't actually step frames, unlike skipblend. For history's sake,
> the way to get skipblend behaviour is to do something like
> "tmix=frames=100,framestep=150" for instance assuming you want to
> blend 100 frames, skip 50, and so on. It is *much* slower compared to
> skipblend by quite a large factor, as tmix does a lot of redundant
> computations, but it works.

I think that adding option to skip some frames can be added.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add tpad filter

[Paul B Mahol]

On 10/30/18, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi |  40 +++
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/vf_tpad.c| 218 +++
>  4 files changed, 260 insertions(+)
>  create mode 100644 libavfilter/vf_tpad.c

Will apply soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/libdavs2: use assert instead of wrong return value

[Carl Eugen Hoyos]

2018-11-01 5:20 GMT+01:00, hwren :
> Signed-off-by: hwren 
> ---
>  libavcodec/libdavs2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
> index 4dbce73..acdfaca 100644
> --- a/libavcodec/libdavs2.c
> +++ b/libavcodec/libdavs2.c
> @@ -93,7 +93,7 @@ static int davs2_dump_frames(AVCodecContext *avctx,
> davs2_picture_t *pic,
>  break;
>  default:
>  av_log(avctx, AV_LOG_ERROR, "Decoder error: unknown frame
> type\n");
> -return AVERROR_EXTERNAL;
> +assert(0);

Please do not assert on return values of an external library.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] 7505

[BIGLER Don (Framatome)]

Fix ticket: 7505


7505.patch
Description: 7505.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/hlsenc: remove the use_localtime_mkdir check logic

[Steven Liu]

fix ticket: 7527
the use_localtime_mkdir check logic looks should be needn't.

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f8f060d065..f4b3eb2aad 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -442,7 +442,7 @@ static int hls_delete_old_segments(AVFormatContext *s, 
HLSContext *hls,
 }
 }
 
-if (segment && !hls->use_localtime_mkdir) {
+if (segment) {
 if (hls->segment_filename) {
 dirname = av_strdup(hls->segment_filename);
 } else {
-- 
2.15.1



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

Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter

[Matthias Troffaes]

Dear Paul,

On Thu, Nov 1, 2018 at 11:21 AM Matthias Troffaes
 wrote:
> Would you consider accepting a patch that added an integer "cutoff"
> option to tmix, for the purpose of setting all weights for frames
> beyond "cutoff" to 0? The reason for requesting this is that in some
> workflows, one is blending together a lot of frames at once, and
> specifying a vector of, say, 100 ones followed by a zero, when
> blending together, say, 200 frames, whilst possible, is rather
> tedious; for instance "tmix=frames=200:cutoff=100" (weights are 1 by
> default so this should then work as expected).

I found a way of doing this differently, as I now found that tmix
doesn't actually step frames, unlike skipblend. For history's sake,
the way to get skipblend behaviour is to do something like
"tmix=frames=100,framestep=150" for instance assuming you want to
blend 100 frames, skip 50, and so on. It is *much* slower compared to
skipblend by quite a large factor, as tmix does a lot of redundant
computations, but it works.

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] avcodec/libopenh264enc.c: Handle sample_aspect_ratio in libopenh264 encoder

[Valery Kot]

On Thu, Nov 1, 2018 at 1:55 PM Valery Kot  wrote:
>
> > I think this would look nicer (and generate less code) as a table + loop 
> > rather than an if-ladder making each fraction structure inline?
> >
> > E.g. something like 
> > .
>
> Thanks for the suggestion! Here is an updated patch.

Was too hurry to send a patch, sorry! Here is the correct one.
From 638277354338bf42020854e5bebec5fe61677135 Mon Sep 17 00:00:00 2001
From: vkot 
Date: Thu, 1 Nov 2018 14:15:11 +0100
Subject: [PATCH] Handle sample_aspect_ratio in libopenh264-encoder

---
 libavcodec/libopenh264enc.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 83c3f0ce20..b3ddb4609b 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -164,6 +164,47 @@ FF_ENABLE_DEPRECATION_WARNINGS
 param.sSpatialLayers[0].iSpatialBitrate = param.iTargetBitrate;
 param.sSpatialLayers[0].iMaxSpatialBitrate  = param.iMaxBitrate;
 
+#if OPENH264_VER_AT_LEAST(1, 7)
+if (avctx->sample_aspect_ratio.num && avctx->sample_aspect_ratio.den) {
+// Table E-1.
+static const AVRational sar_idc[] = {
+{   0,  0 }, // Unspecified (never written here).
+{   1,  1 }, {  12, 11 }, {  10, 11 }, {  16, 11 },
+{  40, 33 }, {  24, 11 }, {  20, 11 }, {  32, 11 },
+{  80, 33 }, {  18, 11 }, {  15, 11 }, {  64, 33 },
+{ 160, 99 }, // Last 3 are unknown to openh264: {   4,  3 }, {   
3,  2 }, {   2,  1 },
+};
+static const ESampleAspectRatio asp_idc[] = {
+ASP_UNSPECIFIED,
+ASP_1x1,  ASP_12x11,   ASP_10x11,   ASP_16x11,
+ASP_40x33,ASP_24x11,   ASP_20x11,   ASP_32x11,
+ASP_80x33,ASP_18x11,   ASP_15x11,   ASP_64x33,
+ASP_160x99,
+};
+int num, den, i;
+
+av_reduce(&num, &den, avctx->sample_aspect_ratio.num,
+  avctx->sample_aspect_ratio.den, 65535);
+
+for (i = 1; i < FF_ARRAY_ELEMS(sar_idc); i++) {
+if (num == sar_idc[i].num &&
+den == sar_idc[i].den)
+break;
+}
+if (i == FF_ARRAY_ELEMS(sar_idc)) {
+param.sSpatialLayers[0].eAspectRatio = ASP_EXT_SAR;
+param.sSpatialLayers[0].sAspectRatioExtWidth = num;
+param.sSpatialLayers[0].sAspectRatioExtHeight = den;
+} else {
+param.sSpatialLayers[0].eAspectRatio = asp_idc[i];
+}
+param.sSpatialLayers[0].bAspectRatioPresent = true;
+}
+else {
+param.sSpatialLayers[0].bAspectRatioPresent = false;
+}
+#endif
+
 if ((avctx->slices > 1) && (s->max_nal_size)) {
 av_log(avctx, AV_LOG_ERROR,
"Invalid combination -slices %d and -max_nal_size %d.\n",
-- 
2.15.1.windows.2

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

Re: [FFmpeg-devel] [PATCH] avcodec/libopenh264enc.c: Handle sample_aspect_ratio in libopenh264 encoder

[Valery Kot]

> I think this would look nicer (and generate less code) as a table + loop 
> rather than an if-ladder making each fraction structure inline?
>
> E.g. something like 
> .

Thanks for the suggestion! Here is an updated patch.
From 7af627f923530d51a51b7630919df0da92f8b71d Mon Sep 17 00:00:00 2001
From: vkot 
Date: Thu, 1 Nov 2018 13:32:21 +0100
Subject: [PATCH] Handle sample_aspect_ratio in libopenh264 encoder

---
 libavcodec/libopenh264enc.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/libavcodec/libopenh264enc.c b/libavcodec/libopenh264enc.c
index 83c3f0ce20..c0ecdb2472 100644
--- a/libavcodec/libopenh264enc.c
+++ b/libavcodec/libopenh264enc.c
@@ -164,6 +164,47 @@ FF_ENABLE_DEPRECATION_WARNINGS
 param.sSpatialLayers[0].iSpatialBitrate = param.iTargetBitrate;
 param.sSpatialLayers[0].iMaxSpatialBitrate  = param.iMaxBitrate;
 
+#if OPENH264_VER_AT_LEAST(1, 7)
+if (avctx->sample_aspect_ratio.num && avctx->sample_aspect_ratio.den) {
+// Table E-1.
+static const AVRational sar_idc[] = {
+{   0,  0 }, // Unspecified (never written here).
+{   1,  1 }, {  12, 11 }, {  10, 11 }, {  16, 11 },
+{  40, 33 }, {  24, 11 }, {  20, 11 }, {  32, 11 },
+{  80, 33 }, {  18, 11 }, {  15, 11 }, {  64, 33 },
+{ 160, 99 }, // Last 3 are unknown to openh264: {   4,  3 }, {   
3,  2 }, {   2,  1 },
+};
+static const ESampleAspectRatio asp_idc[] = {
+ASP_UNSPECIFIED,
+ASP_1x1,  ASP_12x11,   ASP_10x11,   ASP_16x11,
+ASP_40x33,ASP_24x11,   ASP_20x11,   ASP_32x11,
+ASP_80x33,ASP_18x11,   ASP_15x11,   ASP_64x33,
+ASP_160x99,
+};
+int num, den, i;
+
+av_reduce(&num, &den, avctx->sample_aspect_ratio.num,
+  avctx->sample_aspect_ratio.den, 65535);
+
+for (i = 1; i < FF_ARRAY_ELEMS(sar_idc); i++) {
+if (num == sar_idc[i].num &&
+den == sar_idc[i].den)
+break;
+}
+if (i == FF_ARRAY_ELEMS(sar_idc)) {
+param.sSpatialLayers[0].eAspectRatio = ASP_EXT_SAR;
+param.sSpatialLayers[0].sAspectRatioExtWidth = 
avctx->sample_aspect_ratio.num;
+param.sSpatialLayers[0].sAspectRatioExtHeight = 
avctx->sample_aspect_ratio.den;
+} else {
+param.sSpatialLayers[0].eAspectRatio = asp_idc[i];
+}
+param.sSpatialLayers[0].bAspectRatioPresent = true;
+}
+else {
+param.sSpatialLayers[0].bAspectRatioPresent = false;
+}
+#endif
+
 if ((avctx->slices > 1) && (s->max_nal_size)) {
 av_log(avctx, AV_LOG_ERROR,
"Invalid combination -slices %d and -max_nal_size %d.\n",
-- 
2.15.1.windows.2

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

Re: [FFmpeg-devel] [PATCH 2/2] libx264: Pass the reordered_opaque field through the encoder

[Martin Storsjö]

On Thu, 1 Nov 2018, Derek Buitenhuis wrote:


On 31/10/2018 21:41, Martin Storsjö wrote:

Even though we do allow reconfiguration, it doesn't look like we support
changing any parameters which would actually affect the delay, only RC
method and targets (CRF, bitrate, etc). So given that, the current patch
probably should be safe - what do you think? Or the current patch, with an
added margin of 16 on top just in case?


We allow reconfiguring to/from interlaced. I'm not sure if this can modify 
delay?


Not really sure either... So perhaps it'd be safest with some bit of extra 
margin/overestimate of the delay here? It just costs a couple bytes in the 
mapping array anyway.


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

Re: [FFmpeg-devel] [PATCH 2/2] libx264: Pass the reordered_opaque field through the encoder

[Derek Buitenhuis]

On 31/10/2018 21:41, Martin Storsjö wrote:
> Even though we do allow reconfiguration, it doesn't look like we support
> changing any parameters which would actually affect the delay, only RC
> method and targets (CRF, bitrate, etc). So given that, the current patch
> probably should be safe - what do you think? Or the current patch, with an
> added margin of 16 on top just in case?

We allow reconfiguring to/from interlaced. I'm not sure if this can modify 
delay?

Othwewise, probably safe, I guess.

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

[FFmpeg-devel] [PATCH] avcodec/tiff: add initial bayer and sub image support

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/tiff.c | 162 ++
 libavcodec/tiff.h |   6 +-
 2 files changed, 156 insertions(+), 12 deletions(-)

diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index b537ec06a5..74b76c9fdf 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -37,6 +37,7 @@
 #include "libavutil/avstring.h"
 #include "libavutil/intreadwrite.h"
 #include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
 #include "avcodec.h"
 #include "bytestream.h"
 #include "faxcompr.h"
@@ -46,11 +47,15 @@
 #include "tiff.h"
 #include "tiff_data.h"
 #include "thread.h"
+#include "get_bits.h"
 
 typedef struct TiffContext {
+AVClass *class;
 AVCodecContext *avctx;
 GetByteContext gb;
 
+int get_subimage;
+
 int width, height;
 unsigned int bpp, bppcount;
 uint32_t palette[256];
@@ -65,6 +70,12 @@ typedef struct TiffContext {
 int fill_order;
 uint32_t res[4];
 
+int is_bayer;
+uint8_t pattern[4];
+unsigned white_level;
+
+uint32_t sub_ifd;
+
 int strips, rps, sstype;
 int sot;
 int stripsizesoff, stripsize, stripoff, strippos;
@@ -236,7 +247,8 @@ static int add_metadata(int count, int type,
 };
 }
 
-static void av_always_inline horizontal_fill(unsigned int bpp, uint8_t* dst,
+static void av_always_inline horizontal_fill(TiffContext *s,
+ unsigned int bpp, uint8_t* dst,
  int usePtr, const uint8_t *src,
  uint8_t c, int width, int offset)
 {
@@ -267,6 +279,15 @@ static void av_always_inline horizontal_fill(unsigned int 
bpp, uint8_t* dst,
 dst[(width+offset)*2+0] = (usePtr ? src[width] : c) >> 4;
 }
 break;
+case 12: {
+ uint16_t *dst16 = (uint16_t *)dst;
+ GetBitContext gb;
+ init_get_bits8(&gb, src, width);
+ for (int i = 0; i < s->width; i++) {
+ dst16[i] = get_bits(&gb, 12) << 4;
+ }
+ }
+break;
 default:
 if (usePtr) {
 memcpy(dst + offset, src, width);
@@ -368,7 +389,7 @@ static int tiff_unpack_zlib(TiffContext *s, AVFrame *p, 
uint8_t *dst, int stride
 src = zbuf;
 for (line = 0; line < lines; line++) {
 if (s->bpp < 8 && s->avctx->pix_fmt == AV_PIX_FMT_PAL8) {
-horizontal_fill(s->bpp, dst, 1, src, 0, width, 0);
+horizontal_fill(s, s->bpp, dst, 1, src, 0, width, 0);
 } else {
 memcpy(dst, src, width);
 }
@@ -433,7 +454,7 @@ static int tiff_unpack_lzma(TiffContext *s, AVFrame *p, 
uint8_t *dst, int stride
 src = buf;
 for (line = 0; line < lines; line++) {
 if (s->bpp < 8 && s->avctx->pix_fmt == AV_PIX_FMT_PAL8) {
-horizontal_fill(s->bpp, dst, 1, src, 0, width, 0);
+horizontal_fill(s, s->bpp, dst, 1, src, 0, width, 0);
 } else {
 memcpy(dst, src, width);
 }
@@ -476,7 +497,7 @@ static int tiff_unpack_fax(TiffContext *s, uint8_t *dst, 
int stride,
   s->compr, s->fax_opts);
 if (s->bpp < 8 && s->avctx->pix_fmt == AV_PIX_FMT_PAL8)
 for (line = 0; line < lines; line++) {
-horizontal_fill(s->bpp, dst, 1, dst, 0, width, 0);
+horizontal_fill(s, s->bpp, dst, 1, dst, 0, width, 0);
 dst += stride;
 }
 return ret;
@@ -516,6 +537,9 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p, 
uint8_t *dst, int strid
 av_assert0(width <= bytes_per_row);
 av_assert0(s->bpp == 24);
 }
+if (s->is_bayer) {
+width = (s->bpp * s->width + 7) >> 3;
+}
 
 if (s->compr == TIFF_DEFLATE || s->compr == TIFF_ADOBE_DEFLATE) {
 #if CONFIG_ZLIB
@@ -559,7 +583,7 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p, 
uint8_t *dst, int strid
 return AVERROR_INVALIDDATA;
 }
 if (s->bpp < 8 && s->avctx->pix_fmt == AV_PIX_FMT_PAL8)
-horizontal_fill(s->bpp, dst, 1, dst, 0, width, 0);
+horizontal_fill(s, s->bpp, dst, 1, dst, 0, width, 0);
 if (is_yuv) {
 unpack_yuv(s, p, dst, strip_start + line);
 line += s->subsampling[1] - 1;
@@ -595,7 +619,7 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p, 
uint8_t *dst, int strid
 return AVERROR_INVALIDDATA;
 
 if (!s->fill_order) {
-horizontal_fill(s->bpp * (s->avctx->pix_fmt == 
AV_PIX_FMT_PAL8),
+horizontal_fill(s, s->bpp * (s->avctx->pix_fmt == 
AV_PIX_FMT_PAL8 || s->is_bayer),
 dst, 1, src, 0, width, 0);
 } else {
 int i;
@@ -619,7 +643,7 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p, 
uint8_t *dst, int strid
"Copy went out of bounds

Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter

[Matthias Troffaes]

Dear Paul,

On Thu, Nov 1, 2018 at 10:34 AM Paul B Mahol  wrote:
> Duplicates funcionality of tmix filter.

Many thanks for your reply, and for pointing out the existence of the
tmix filter. Please forgive my ignorance about it. I see tmix was only
added in April this year, whilst I've been carrying skipblend (and
tried getting it upstreamed a few times) since June 2017. No matter,
it's great to see this sort of functionality finally included!

Would you consider accepting a patch that added an integer "cutoff"
option to tmix, for the purpose of setting all weights for frames
beyond "cutoff" to 0? The reason for requesting this is that in some
workflows, one is blending together a lot of frames at once, and
specifying a vector of, say, 100 ones followed by a zero, when
blending together, say, 200 frames, whilst possible, is rather
tedious; for instance "tmix=frames=200:cutoff=100" (weights are 1 by
default so this should then work as expected).

Kind regards,
Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter

[Paul B Mahol]

On 11/1/18, Matthias Troffaes  wrote:
> Dear FFmpeg developers,
>
> ... is there a possibility for this patch to get applied? Obviously
> I'm happy to work further on the code where need be to get this
> upstreamed.

Duplicates funcionality of tmix filter.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavformat/hlsenc: only initialize the "start_pts" value if the incoming packet is a video packet.

[Boris Nagels]

The packet type should be checked before the start value is assigned. For 
example, if the first packet to arrive is an audio packet, the value of 
start-pts is in the timebase units of the audio stream. This will cause the 
stream to be split on every I-frame of the video stream since the pts value of 
the audio stream is typically much smaller than the pts value of the video 
stream.
---
 libavformat/hlsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 902896ef81..85167761b9 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2201,7 +2201,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 end_pts = init_list_dur + after_init_list_dur ;
 }
 
-if (vs->start_pts == AV_NOPTS_VALUE) {
+if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO && vs->start_pts == 
AV_NOPTS_VALUE) {
 vs->start_pts = pkt->pts;
 vs->end_frame = st->nb_frames;
 }
-- 

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

Re: [FFmpeg-devel] [PATCH] avfilter: add skipblend filter

[Matthias Troffaes]

Dear FFmpeg developers,

... is there a possibility for this patch to get applied? Obviously
I'm happy to work further on the code where need be to get this
upstreamed.

Kind regards,
Matthias
On Wed, Oct 24, 2018 at 11:14 AM Matthias Troffaes
 wrote:
>
> Attached a patch which adds a "skipblend" filter, which I've been
> using for a while. My hope is that an ffmpeg developer here can merge
> it. The filter is similar to the framestep filter, but additionally
> blends frames together at each step, for a motion blur effect. The
> number of frames that are blended (i.e. the exposure time, in frames)
> can be set, allowing control over the strength of the motion blur. The
> filter has timeline support, and supports both 8-bit and 16-bit pixel
> formats. Tests and documentation included.
>
> The main use so far that I (and others) have for this filter is to
> blend down high framerate footage, generated through computer
> rendering, to produce a high quality motion blur effect.
>
> Note that a similar effect is already possible by repeatedly chaining
> the tblend and framestep=step=2 filters; see for example:
>
> https://video.stackexchange.com/questions/16552/4x-resample-videoframes-using-ffmpeg
>
> But this is limited to steps that are powers of two, and this does not
> allow an intermediate exposure time. It's also slower.
>
> In the documentation, I've also added links between framestep, tblend,
> and the new skipblend filter, to help users to find the right filter
> they are looking for.
>
> Kind regards,
> Matthias
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add xstack filter

[Gyan]

On Thu, Oct 25, 2018 at 12:35 AM Paul B Mahol  wrote:

>
> +if (s->is_horizontal || s->is_vertical) {
> +if ((ret = av_image_fill_linesizes(linesize, inlink->format,
> inlink->w)) < 0) {
> +av_frame_free(&out);
> +return ret;
> +}
>

 Nice filter. One unfortunate side-effect is that unused parts of the
canvas are zero-ed which in YUV formats is a shade of dark green. Users
will generally want black. Would be nice to add a color option which fills
the canvas before av_image_copy_plane.

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

Re: [FFmpeg-devel] [PATCH] avcodec/qsvenc: add VDENC support for H264 and HEVC

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Thursday, November 1, 2018 10:59 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [FFmpeg-devel] [PATCH] avcodec/qsvenc: add VDENC support for
> H264 and HEVC
> 
> Add VDENC(lowpower mode) support for QSV h264 and HEVC with the
> limitation of MSDK API verion greater than 1.15.

Should be "version", not "verion" 
IMHO, API version limitation is not necessary in the commit message since it is 
quite clear in the code

> 
> It's an experimental function(like lowpower in vaapi) with some limitations:
> - CBR/VBR require HuC which should be explicitly loaded via i915 module
> parameter(i915.enable_guc=2 for >=4.16)

4.16 is not a clear message, should be Linux kernel version >= 4.16.

> - HEVC VDENC was supported >= ICE LAKE
> 
> use option "-low_power 1" to enable VDENC.
> 
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/qsvenc.c  | 3 +++
>  libavcodec/qsvenc.h  | 2 ++
>  libavcodec/qsvenc_h264.c | 3 +++
>  libavcodec/qsvenc_hevc.c | 3 +++
>  4 files changed, 11 insertions(+)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> 948751daf4..7a031297fe 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -464,6 +464,9 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
>  }
>  }
> 
> +#if QSV_HAVE_VDENC
> +q->param.mfx.LowPower   = q->low_power ?
> MFX_CODINGOPTION_ON:MFX_CODINGOPTION_OFF;
> +#endif
>  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.h b/libavcodec/qsvenc.h index
> 50cc4267e7..a396aa7d3f 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -44,6 +44,7 @@
>  #define QSV_HAVE_LA QSV_VERSION_ATLEAST(1, 7)
>  #define QSV_HAVE_LA_DS  QSV_VERSION_ATLEAST(1, 8)  #define
> QSV_HAVE_LA_HRD QSV_VERSION_ATLEAST(1, 11)
> +#define QSV_HAVE_VDENC  QSV_VERSION_ATLEAST(1, 15)
> 
>  #if defined(_WIN32) || defined(__CYGWIN__)
>  #define QSV_HAVE_AVBR   QSV_VERSION_ATLEAST(1, 3)
> @@ -162,6 +163,7 @@ typedef struct QSVEncContext {
>  int recovery_point_sei;
> 
>  int a53_cc;
> +int low_power;
> 
>  #if QSV_HAVE_MF
>  int mfmode;
> diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c index
> 07c9d64e6b..483faf832b 100644
> --- a/libavcodec/qsvenc_h264.c
> +++ b/libavcodec/qsvenc_h264.c
> @@ -153,6 +153,9 @@ static const AVOption options[] = {
>  { "off", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_MF_DISABLED }, INT_MIN, INT_MAX, VE, "mfmode" },
>  { "auto"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_MF_AUTO }, INT_MIN, INT_MAX, VE, "mfmode" },
>  #endif
> +#if QSV_HAVE_VDENC
> +{ "low_power",  "low power mode for encoder h264_qsv",

Since it is a h264_qsv private option, it is no need to add the comment "for 
encoder h264_qsv "
I prefer "enable low power mode (experimental, many limitations by mfx version, 
HW platform, BRC modes, etc.)"

> OFFSET(qsv.low_power),  AV_OPT_TYPE_INT, { .i64 =  0 }, 0,
> 1, VE },

Should be AV_OPT_TYPE_BOOL.

> +#endif
> 
>  { NULL },
>  };
> diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c index
> 4339b316a3..cfe3674f0f 100644
> --- a/libavcodec/qsvenc_hevc.c
> +++ b/libavcodec/qsvenc_hevc.c
> @@ -243,6 +243,9 @@ static const AVOption options[] = {
>  { "main",NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_PROFILE_HEVC_MAIN}, INT_MIN, INT_MAX, VE, "profile" },
>  { "main10",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_PROFILE_HEVC_MAIN10  }, INT_MIN, INT_MAX, VE, "profile" },
>  { "mainsp",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_PROFILE_HEVC_MAINSP  }, INT_MIN, INT_MAX, VE, "profile" },
> +#if QSV_HAVE_VDENC
> +{ "low_power", "low power mode for encoder hevc_qsv",
> +OFFSET(qsv.low_power), AV_OPT_TYPE_INT, { .i64 =  0 },  0,  1, VE },
> +#endif

Should be AV_OPT_TYPE_BOOL as above.

> 
>  { NULL },
>  };
> --
> 2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel