e59915fc771ca1c5afd0c5c7ed04227933206a39 Mon Sep 17 00:00:00 2001
From: Timo Rothenpieler t...@rothenpieler.org
Date: Wed, 26 Nov 2014 11:08:11 +0100
Subject: [PATCH] Add NVENC encoder
---
configure | 11 +-
libavcodec/Makefile |1 +
libavcodec/allcodecs.c |1 +
libavcodec/nvenc.c
100644
index 000..3cb98d3
--- /dev/null
+++ b/libavcodec/nvenc.c
@@ -0,0 +1,932 @@
+/*
+ * H.264 hardware encoding using nvidia nvenc
+ * Copyright (c) 2014 Timo Rothenpieler t...@rothenpieler.org
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute
init_static_data to dynamicaly ask the nvidia driver for the
supported pixel formats instead.
From 793271822a5f52c3aed876fcedc7c6d8edd3c10c Mon Sep 17 00:00:00 2001
From: Timo Rothenpieler t...@rothenpieler.org
Date: Wed, 26 Nov 2014 11:08:11 +0100
Subject: [PATCH] Add NVENC encoder
---
Changelog
I haven't looked in detail, but this doesn't seem like a good idea to me.
For example it can't handle having different encoders using different
cards/hardware.
I don't know what other options there might be, maybe this is the best, but it
seems not particularly good.
The only other option
BTW, can you verify that interlaced encoding works for
you? I get initialization errors back from the hardware.
Doesn't work for me either. It looks like it's not (yet?) supported and
just available in the API.
signature.asc
Description: OpenPGP digital signature
does supporting these additional features need the extra complexity
that the nvidia version has ?
or could these features be added into your version while keeping its
simplicity ? (note do not copy any code from the nvidia one as its
not redistriutable nor *GPL compatible with the current
.
commit f7840ac3e9ae279e6665986a122e95b8bf9a7f6a
Author: Timo Rothenpieler t...@rothenpieler.org
Date: Wed Nov 26 11:08:11 2014 +0100
Add NVENC encoder
diff --git a/Changelog b/Changelog
index 7172d0c..d26b7fa 100644
--- a/Changelog
+++ b/Changelog
@@ -17,6 +17,7 @@ version next:
- WebP muxer
Why not just drop old versions?
The newest SDK only works with the very latest nvidia driver.
So supporting the older SDK versions is neccessary if you want to use
nvenc without the very latest nvidia driver.
signature.asc
Description: OpenPGP digital signature
+if (avctx-max_b_frames -1)
+avctx-max_b_frames = -1;
how do you get a value -1 here ?
The check is probably not needed, as the minimum for the option already
is -1.
signature.asc
Description: OpenPGP digital signature
___
Could I get a proper review on this? I'd like to believe that we have a
consensus that, independent of whether we think there's merit in this
compensation logic, it shouldn't exist in a single encoder, out of
step with all the other encoders in ffmpeg.
Thanks,
It looks good to merge for
---
libavcodec/nvenc.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 5cd7727..90856be 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -155,7 +155,6 @@ typedef struct NvencContext
char
---
libavcodec/nvenc.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 90856be..57ca130 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -471,6 +471,7 @@ static av_cold int nvenc_encode_init(AVCodecContext
---
libavcodec/nvenc.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 57ca130..85f6d43 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -67,7 +67,9 @@ typedef CUresult(CUDAAPI *PCUCTXDESTROY)(CUcontext
No? It has X265_TYPE_AUTO as the fallback if it is NULL. Just like libx264.c:
Is falls back to that if pic-pict_type is NULL, but if pic is NULL, it
will just crash.
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
Still using attachment to prevent word-wrapping.
For video streaming, repeatSPSPPS flag should be set as 1 besides
disableSPSPPS=0, elsewise if running ffmpeg before vlc/ffmpeg, there
will be no video header, decoder can't work properly.
Agatha Hu
Looks good to merge.
signature.asc
+ctx-encode_config.encodeCodecConfig.h264Config.maxNumRefFrames =
avctx-refs;
avctx-refs should propably be checked for = 0.
I'm not sure if maxNumRefFrames means the exact same thing as
avctx-refs, but the comment in the nvenc header isn't exactly clear
about that.
This would also
Signed-off-by: Philip Langdale phil...@overt.org
---
libavcodec/nvenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index c52beb7..e68bbe9 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -614,6 +614,11 @@ static av_cold
Am 07.01.2015 um 10:48 schrieb Agatha Hu:
When B frames = 1, there'll be a invalid dts/pts warning during
encoding like:
[mp4 @ 0034cba0] Invalid DTS: 1024 PTS: 512 in output stream
0:0, replacing by guess
[mp4 @ 0034cba0] Invalid DTS: 1536 PTS: 1024 in output stream
0:0,
The intel QSV api is only available for Windows.
There is a Media SDK for Linux, which seems to provide the same API, but
it's not free and intended for servers.
The encoding api is exposed through libva/vaapi on Linux. But so far no
implementation exists except for the two examples coming with
Am 24.03.2015 um 10:03 schrieb Carl Eugen Hoyos:
timo at rothenpieler.org writes:
+#if NVENCAPI_MAJOR_VERSION 5
+#error NVENC API 4 or older is not supported
+#endif
This should be checked in configure imo.
Yes, would indeed be better.
Could you confirm that the new api is available
Le nonidi 9 germinal, an CCXXIII, wm4 a écrit :
amovie1.zip, and then /tmp/amovie1.zip//amovie.srt is a perfectly
valid unix path. Multiple slashes are coalesced into 1.
Just as you say it without realizing it, it is valid but useless.
While it is useless, for example scripts frequently
---
libavformat/dashenc.c | 43 ---
1 file changed, 28 insertions(+), 15 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 25c699e..92b7d6c 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -72,7 +72,6 @@ typedef
---
libavformat/dashenc.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 98036d3..25c699e 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -72,6 +72,7 @@ typedef struct OutputStream
Am 24.03.2015 um 05:41 schrieb Philip Langdale:
Sufficiently new nvenc hardware (GM20x or later) has support for H.265
encoding. This works the same as the H.264 encoder except the
codec parameters are different.
Due to the fact that common codec parameters are not shareable, there's
quite a
---
libavcodec/nvenc.c | 111 -
1 file changed, 110 insertions(+), 1 deletion(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index f77a982..d4e0a39 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -129,6 +129,12 @@ typedef
When setting level of HEVC in NVENC, FFmpeg gives error:
root@encoder:~# /opt/ffmpeghw/bin/ffmpeg -i /root/bunny.mp4 -aspect 16:9
-s 3840x2160 -vcodec nvenc_h265 -preset hp -fflags +genpts -vb 25000k -
minrate 25000k -maxrate 25000k -bufsize 75000k -muxrate 25000k -r 50 -an
-flush_packets 0
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/nvenc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 445d60f..de082d1 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -1375,7 +1375,7 @@
---
libavfilter/vf_colorkey.c | 36 +++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c
index 6c76991..6964809 100644
--- a/libavfilter/vf_colorkey.c
+++ b/libavfilter/vf_colorkey.c
@@ -29,6
+ vf_colorkey.c Timo Rothenpieler
vf_dejudder.c Nicholas Robbins
vf_delogo.c Jean Delvare (CC kh...@linux-fr.org)
vf_drawbox.c/drawgrid Andrey Utkin
diff --git a/doc/filters.texi b/doc/filters.texi
index
Yes, agree. Maybe a fix to give info massage that NVENC does not support
levels 1, 2, 2.1, 3, 3.1, 4, 4.1, 5, 5.1, 5.2, 6 in HEVC ?
There is no documented information about what levels it supports, it
also likely depends on other settings.
So ffmpeg just offers all of them.
I think this
);
diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c
new file mode 100644
index 000..b5180cf
--- /dev/null
+++ b/libavfilter/vf_colorkey.c
@@ -0,0 +1,226 @@
+/*
+ * Copyright (c) 2015 Timo Rothenpieler t...@rothenpieler.org
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg
What does this do? (Don't answer me in email, but write in in
doc/filters.texi.)
Just noticed that git entirely removed my comments.
This is not (yet) for merging, but primarily a request for comments on
the implementation.
I'm sure this can be easily optimized quite a bit and also cleaned up
---
Changelog | 1 +
libavcodec/nvenc.c | 111 -
2 files changed, 111 insertions(+), 1 deletion(-)
diff --git a/Changelog b/Changelog
index ba0dff5..acced67 100644
--- a/Changelog
+++ b/Changelog
@@ -13,6 +13,7 @@ version next:
-
You can use AV_OPT_CONST instead of this.
That doesn't work, as the h264 and h265 encoder share the same options
array, and need diffrent values for the same input.
Splitting up the options table is something that most likely will have
to happen sooner or later, but even then I'm not sure if
It was not possible to set a profile before, the builtin profile
parameter does not seem to work propperly.
To be compatible with libx264, this overlays it with a local parameter
that expects a string, instead of an int, that takes the well known values
high, main or baseline.
---
Did you try to adding the FF_PROFILE_H264* and FF_PROFILE_HEVC* values to
options_table.h?
Currently it only has entries for aac, dts, mpeg2 and mpeg4.
While that would propably work, i'm more interested in staying
compatible with libx264 here, which accepts stuff like -profile:v
high, while
+ vf_colorkey.c Timo Rothenpieler
vf_dejudder.c Nicholas Robbins
vf_delogo.c Jean Delvare (CC kh...@linux-fr.org)
vf_drawbox.c/drawgrid Andrey Utkin
diff --git a/doc/filters.texi b/doc/filters.texi
index
We've decided to drop the libav reimplementation of nvenc support and retain
ours as is. This patch series removes the files, along with also reverting
the various fixes we made on top of them.
The series LGTM for me.
signature.asc
Description: OpenPGP digital signature
For the sake of compatibility, and because pretty much everything else in the
codebase calls it HEVC.
Both patches LGTM for me.
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
not really related to this patch but
are the nvenc encoders intended to be used by default for
h264/hevc even when libx264 / libx265 is enabled ?
they are registered before them so they would be used if no encoder
is explicitly specified
I was under the impression that the list is
---
libavfilter/vf_colorkey.c | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c
index 19e39ec..65d3e20 100644
--- a/libavfilter/vf_colorkey.c
+++ b/libavfilter/vf_colorkey.c
@@ -30,24 +30,28
vf_colorbalance.c Paul B Mahol
+ vf_colorkey.c Timo Rothenpieler
vf_dejudder.c Nicholas Robbins
vf_delogo.c Jean Delvare (CC kh...@linux-fr.org)
vf_drawbox.c/drawgrid Andrey Utkin
This has been enabled by recent nvidia driver releases.
Signed-off-by: Philip Langdale phil...@overt.org
---
libavcodec/nvenc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 87ce6f3..a5652c5 100644
--- a/libavcodec/nvenc.c
+++
Newer versions of the nvenc hardware support The High 444 Predictive profile
of H.264, and can also do lossless encoding under this profile if desired.
This change introduces support for the profile, and exposes the appropriate
presets for requesting lossless encoding.
I tested lossless
vf_colorbalance.c Paul B Mahol
+ vf_colorkey.c Timo Rothenpieler
vf_dejudder.c Nicholas Robbins
vf_delogo.c Jean Delvare (CC kh...@linux-fr.org)
vf_drawbox.c/drawgrid Andrey Utkin
diff
in advance.
I still left the float-int math conversion as seperate commit, this way, if
my conversion of the algorithm turns out to be flawed, the original algorithm
is still available as reference.
If this is not desireable, i can squash it into one commit.
Timo Rothenpieler (2):
avfilter
---
libavfilter/vf_colorkey.c | 36 +++-
1 file changed, 27 insertions(+), 9 deletions(-)
diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c
index 9c968e8..0368d7c 100644
--- a/libavfilter/vf_colorkey.c
+++ b/libavfilter/vf_colorkey.c
@@ -29,6
+static int offset_r(int fmt)
You can use the info in AVPixFmtDescriptor for these.
Didn't know about that, will look into it.
+default:
+return 0;
av_assert0(!reached); for the default case.
Yep
+frame-format = convert_format(frame-format);
I am not sure this is
---
libavfilter/vf_colorkey.c | 32 +---
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c
index 5db30e8..d5908de 100644
--- a/libavfilter/vf_colorkey.c
+++ b/libavfilter/vf_colorkey.c
@@ -30,6 +30,8 @@
Updated patch, following the suggested changes.
Timo Rothenpieler (2):
avfilter/vf_colorkey: Add colorkey video filter
avfilter/vf_colorkey: Transform calculations to integer math
Changelog | 1 +
MAINTAINERS | 1 +
doc/filters.texi | 39
vf_colorbalance.c Paul B Mahol
+ vf_colorkey.c Timo Rothenpieler
vf_dejudder.c Nicholas Robbins
vf_delogo.c Jean Delvare (CC kh...@linux-fr.org)
vf_drawbox.c/drawgrid Andrey Utkin
Device 0: Tesla M2090
CUDA Driver Version / Runtime Version 7.0 / 7.0
CUDA Capability Major/Minor version number:2.0
[nvenc @ 0x2591c20] 1 CUDA capable devices found
[nvenc @ 0x2591c20] [ GPU #0 - Tesla M2090 has Compute SM 2.0, NVENC
Not Available ]
NVENC needs CUDA
Thanks for all , if you add "*Streaming*" *Presets* To Nvidia Nevec
Presets , like this :
Automatic
Low Latency
Low Latency 2Pass
HQ Low Latency 2Pass
Lossless
HP lossless
Thanks
Not sure what you mean with this.
The ll/llhq/hp/... presets are all available. You can also enable 2pass
mode
> ---
> libavcodec/nvenc.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 0e6ef43..083e494 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -912,6 +912,11 @@ static av_cold int
> From: Agatha Hu
>
> ---
> libavcodec/nvenc.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 812b0b4..17d58fc 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@
Hi
I have check the error, for some card, yes, just like what I said above,
some cards does not support double type, so we must check the opencl
extension: cl_khr_fp64 before the kernel compile. If the device support,
we use GPU, else, we use CPU or use float type, Is it OK?
Thanks
Best regards
Anyone takes a look at this patch? Thanks
Looks fine, if noone objects, i'll merge it this weekend.
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
Using this sample: https://btbn.de/files/chromakey_sample.mp4
ffmpeg -f lavfi -i color=c=black:s=1280x720 -i chromakey_sample.mp4 -an
-c:v libx264 -preset veryfast -crf 18 -shortest -filter_complex
"[1:v]chromakey=0x70de77:0.1:0.2:0:1[ckout];[0:v][ckout]overlay[out]"
-map "[out]" -y output.mkv
tches in format-patch format, in case you
realy want to use git am.
From e231220729cb956523a869006932cd2e2680e621 Mon Sep 17 00:00:00 2001
From: Timo Rothenpieler <t...@rothenpieler.org>
Date: Thu, 24 Sep 2015 14:03:26 +0200
Subject: [PATCH 1/2] avutil/opencl: Display build log on compile error
--
Hi,
Sorry, I cannot test until next week. Does it actually work now? Based
on some #ffmpeg-devel backlogs :)
Yes, it works flawlessly, except for samples using ScalingLists.
See http://fate-suite.ffmpeg.org/hevc-conformance/ the SLIST_* files.
Those files decode with strong artifacts, with
---
configure | 2 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/hevc.c | 5 +-
libavcodec/vaapi_hevc.c | 442
5 files changed, 450 insertions(+), 1 deletion(-)
create mode 100644
acceleration through VA API
+ *
+ * Copyright (C) 2015 Timo Rothenpieler t...@rothenpieler.org
+ *
+ * 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
---
libavcodec/nvenc.c | 59
+-
1 file changed, 54 insertions(+), 5 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 5490652..7c683ea 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -610,8 +610,17 @@ static
Yes you're right, another typo.
Fix by attached patch (Based on Timo's branch, others seem fine to me).
Agatha Hu
Applied and merged, thanks.
Timo
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
nc log messages.
Signed-off-by: Timo Rothenpieler <t...@rothenpieler.org>
---
libavcodec/nvenc.c | 188 -
1 file changed, 130 insertions(+), 58 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 3174b01..72f13de 100644
---
---
libavcodec/nvenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 7c683ea..a20356f 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -580,7 +580,7 @@ static av_cold int nvenc_encode_init(AVCodecContext
*avctx)
1aa208 Mon Sep 17 00:00:00 2001
From: Agatha Hu <a...@nvidia.com>
Date: Fri, 11 Sep 2015 11:07:10 +0200
Subject: [PATCH 1/2] avcodec/nvenc: Optimize nvenc parameters
Add 3 more presets: fast, medium, slow.
Improve min/max QP calculation.
Signed-off-by: Timo Rothenpieler <t...@r
-av_log(avctx, AV_LOG_FATAL, "Failed loading %s from CUDA library\n",
s); \
+av_log(avctx, AV_LOG_FATAL, "[nvenc]: Failed loading %s from CUDA
library\n", s); \
This kind of changes are unwanted. The codec name should already be raised
in the logging (through avctx). It also
-ctx->encode_config.rcParams.enableMinQP = 1;
-ctx->encode_config.rcParams.enableMaxQP = 1;
+ctx->encode_config.rcParams.enableMinQP = 1;
+ctx->encode_config.rcParams.enableMaxQP = 1;
If you do not reindent these lines in the same patch,
the changes
> I'm not quite sure of what I think of this software/opencl hybrid
> approach. On one hand, it's good that they share the "user interface"
> (options etc.). On the other hand, the OpenCL part duplicates the
> entire actual filter code. And unlike with asm, there's no good way to
> test that they
>> ping once again
>>
>> Hi
> Could you describe how to verify it, and how can I test it?
>
> Thanks
> Best regards
>
Using this sample: https://btbn.de/files/chromakey_sample.mp4
ffmpeg -f lavfi -i color=c=black:s=1280x720 -i chromakey_sample.mp4 -an
-c:v libx264 -preset veryfast -crf 18
> @@ -3120,7 +3121,10 @@ static VideoState *stream_open(const char *filename,
> AVInputFormat *iformat)
> is = av_mallocz(sizeof(VideoState));
> if (!is)
> return NULL;
> -av_strlcpy(is->filename, filename, sizeof(is->filename));
> +is->filename =
> Signed-off-by: Timo Rothenpieler <t...@rothenpieler.org>
> ---
> doc/filters.texi | 5 +
> libavfilter/chromakey_opencl_kernel.h | 98 +++
> libavfilter/opencl_allkernels.c | 2 +
> libavfilter/vf_chro
> On Thu, Sep 24, 2015 at 05:12:23PM +0200, Timo Rothenpieler wrote:
>> ---
>> libavutil/opencl.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> LGTM
pushed this one.
If anyone with OpenCL experience could have a look at the other two,
that'd be
---
libavutil/opencl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/opencl.c b/libavutil/opencl.c
index 1d78214..8686493 100644
--- a/libavutil/opencl.c
+++ b/libavutil/opencl.c
@@ -37,7 +37,7 @@
#endif
#include "atomic.h"
-static volatile pthread_mutex_t
Signed-off-by: Timo Rothenpieler <t...@rothenpieler.org>
---
doc/filters.texi | 5 +
libavfilter/chromakey_opencl_kernel.h | 98 +++
libavfilter/opencl_allkernels.c | 2 +
libavfilter/vf_chromakey.c
---
libavutil/opencl.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/libavutil/opencl.c b/libavutil/opencl.c
index 8686493..2469ba4 100644
--- a/libavutil/opencl.c
+++ b/libavutil/opencl.c
@@ -452,8 +452,9 @@ cl_program av_opencl_compile(const char
still lgtm
If nobody objects, i'll push later today.
Timo
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Paul B Mahol
+ vf_chromakey.cTimo Rothenpieler
vf_colorchannelmixer.cPaul B Mahol
vf_colorbalance.c Paul B Mahol
vf_colorkey.c Timo Rothenpieler
diff --git a/doc/filters.texi b/doc/filters.texi
Paul B Mahol
+ vf_chromakey.cTimo Rothenpieler
vf_colorchannelmixer.cPaul B Mahol
vf_colorbalance.c Paul B Mahol
vf_colorkey.c Timo Rothenpieler
diff --git a/doc/filters.texi b/doc
Have you explored way how to handle borders?
You mean the outmost pixels, where the calculation is slightly inaccurate?
Or the greenscreen spilling into the object because of light reflections?
The first could be addressed by adjusting the value for the
out-of-bounds pixels.
The later is
Paul B Mahol
+ vf_chromakey.cTimo Rothenpieler
vf_colorchannelmixer.cPaul B Mahol
vf_colorbalance.c Paul B Mahol
vf_colorkey.c Timo Rothenpieler
diff --git a/doc/filters.texi b/doc
>> +if (frame->format == AV_PIX_FMT_YUVA420P || frame->format ==
>> AV_PIX_FMT_YUVA422P)
>> +x /= 2;
>> +
>> +if (frame->format == AV_PIX_FMT_YUVA420P)
>> +y /= 2;
>
> Why not use the usual subsampling mechanism? (using vsub/hsub etc)
That seemed more complex to me, as
> Patch from https://trac.ffmpeg.org/ticket/5036 is attached
Forgot to mention, this indeed does fix compilation for me on cygwin.
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
---
libavcodec/nvenc.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 9e448f9..b541e14 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -36,16 +36,18 @@
#include "internal.h"
#include "thread.h"
Patch from https://trac.ffmpeg.org/ticket/5036 is attached
From d5d18f91514b6c31f903b04a1c44b0e2de2ffd1a Mon Sep 17 00:00:00 2001
From: Kevin Mitchell
Date: Tue, 24 Nov 2015 19:25:12 -0800
Subject: [PATCH] avformat: add windows.h to SChannel SSP TLS code
This fixes building
>> Should fall under the system library stuff the GPL defines.
>
> I may misunderstand (I am not a native speaker) but the word
> "should" imo indicates that you cannot commit your patch.
Guess why I sent it here first...
> Sorry, Carl Eugen
> ___
>
>>> Should fall under the system library stuff the GPL defines.
>>
>> I may misunderstand (I am not a native speaker) but the word
>> "should" imo indicates that you cannot commit your patch.
>>
>
> The header is licensed rather liberally and doesn't actually link
> against anything, I don't see
>> @@ -1603,6 +1603,7 @@ CONFIG_LIST="
>> memalign_hack
>> memory_poisoning
>> neon_clobber_test
>> +nvenc
>
> You forgot to remove nvenc from EXTERNAL_LIBRARY_LIST
Yep, forgot about that.
>> +case $target_os in
>> +mingw32*|mingw64*|win32|win64|linux|cygwin*)
>> +
> On Monday 07 December 2015 03:14:08 pm Timo Rothenpieler wrote:
>> Nvidia finaly decided to put a propper MIT license on their nvenc header,
>> so it can be included, removing any external dependencies for nvenc and
>> making it no longer require the non-free flag.
>
&g
> I don't remember if this was discussed when avisynth and other headers
> where included, but what's the advantage of directly including the
> header and burden the FFmpeg sources, rather than asking the user to
> download them in case of need?
The nvenc sdk isn't exactly a common thing that
> --- libavcodec/nvenc.c | 3 +++ 1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index
> 43b8e78..b8f7f91 100644 --- a/libavcodec/nvenc.c +++
> b/libavcodec/nvenc.c @@ -762,6 +762,9 @@ static av_cold int
> nvenc_encode_init(AVCodecContext *avctx) } }
>
>
> No, it won't affect performance, we did lots of internal tests, mainly
> focused on quality improvement. But if it makes performance worse we
> won't apply it anyway.
Split and applied, thanks.
> Agatha Hu
>
> ___
> ffmpeg-devel mailing list
>
> Hi all, before switching to the new released nvenc6.0 header, can you
> take a look at this fix?
I'm fine with making it the default, the only concern i have is weather
it has any side-effects, like reduced performance that impacts some
higher resolutions which can't be encoded in realtime
> But before doing any of this, there has to be an agreement, whether or not
> the header should be included at all.
Of course.
Here's what I intend to do once I find some time again, which could take
a few days/weeks:
Split this up into three patches.
One that adds a check for NVENC Version 6,
So, to get somewhere with this, would everybody be ok if I change this
to remove the non-free marking, but keep it disabled by default for now?
Or is putting that exception-text in nvenc.c enough to make enabling it
by default viable?
signature.asc
Description: OpenPGP digital signature
Signed-off-by: Timo Rothenpieler <t...@rothenpieler.org>
---
Changelog | 1 +
configure | 3 +
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/vaapi_vp9.c | 168 +
libavcodec/version.h
ping
Is any further review required, or is it fine to just push?
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Philip Langdale
cscd.cReimar Doeffinger
+ cuvid.c Timo Rothenpieler
dca.c Kostya Shishkov, Benjamin Larsson
dirac*Rostislav Pehlivanov
dnxhd
---
Makefile | 1 +
ffmpeg.c | 5 ++
ffmpeg.h | 3 +
ffmpeg_cuvid.c | 201 +
ffmpeg_opt.c | 3 +
5 files changed, 213 insertions(+)
create mode 100644 ffmpeg_cuvid.c
diff --git a/Makefile b/Makefile
index
1 - 100 of 1296 matches
Mail list logo