On 12.06.2020 00:31, Gavin Smith wrote:
On 11/06/2020 22:03, Timo Rothenpieler wrote:
On 11.06.2020 22:27, Gavin Smith wrote:
This is to address trac ticket #8724. The filter did not preserve
alpha transparency. Items that were transparent in the input would
appear black on the output or
On 17.06.2020 18:07, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
I failed to find any document about nvenc so that I can update for new option.
libavcodec/nvenc.c | 53 +
libavcodec/nvenc.h | 1 +
On 23.06.2020 16:44, lance.lmw...@gmail.com wrote:
On Thu, Jun 18, 2020 at 12:32:57PM +0800, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/nvenc.c | 17 +
libavcodec/nvenc.h | 1 +
libavcodec/nvenc_hevc.c | 1 +
3 file
I have sent one of my spare AMD GPUs to Rodger Combs for work on AMF and
AMF/Vulkan integration.
Since there is personal information on the receipts, I won't post them
here, but can send them to the responsible person on request easily.
Packaging:
PackSet M: 1.99€
Bubble-Wrap "Protection Kit"
On 02.09.2019 18:24, Timo Rothenpieler wrote:
I have sent one of my spare AMD GPUs to Rodger Combs for work on AMF and
AMF/Vulkan integration.
Since there is personal information on the receipts, I won't post them
here, but can send them to the responsible person on request e
On 12/09/2019 15:17, Steve Lhomme wrote:
---
Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index a51c2c9..c3a9209 100644
--- a/Makefile
+++ b/Makefile
@@ -1,4 +1,4 @@
-PREFIX = /usr/local
+PREFIX ?= /usr/local
Overriding the prefix worked ju
On 12/09/2019 15:19, Steve Lhomme wrote:
It can be useful to determine if the decoder context is the same as the display
context.
It's used in some samples at https://github.com/NVIDIA/video-sdk-samples
---
include/ffnvcodec/dynlink_cuda.h | 1 +
include/ffnvcodec/dynlink_loader.h | 2 ++
On 27/09/2019 11:04, Roman Arzumanyan wrote:
Hello,
This patch adds multiple reference frames support (part of Video Codec SDK 9.1).
It adds "nb_ref_frames" CLI option to set number of reference frames. Possible
values:
* auto - let encoder decide (default value).
* [0;7] - set value
On 27/09/2019 12:28, Roman Arzumanyan wrote:
First, this needs SDK Version Guards
Thanks, I've missed that. Added to patch.
Second, in what way is this different from the existing global
option(avctx->refs), which nvenc.c already uses to set
It's slightly different from existing global opti
applied, but after some discussion on IRC, I opted to rename the current
-refs option to -dpb_size, and use -refs for this one.
-refs now matches what libx264 uses it for and what probably the
majority of users expect.
___
ffmpeg-devel mailing list
f
On 04.10.2019 06:42, Holy Wu wrote:
Chroma format was not checked properly as it's always set to
cudaVideoChromaFormat_420 regardless of the input pixel format.
Why does it remove the check for the codec being supported at all?
___
ffmpeg-devel mailin
On 14.10.2019 17:43, Hendrik Leppkes wrote:
Since some users seem to have blindly passed -refs to their
commandline which now fails without really telling them why, any
thoughts on moving the capability check error messages onto a high log
level so that they are shown by default, since they are t
On 17.10.2019 23:59, James Almer wrote:
On 10/17/2019 6:43 PM, Andrey Semashev wrote:
On 2019-10-17 23:11, James Almer wrote:
Actually reorder the values.
Should effectively fix ticket #8300.
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 21 -
1 file changed
On 27.10.2019 03:30, hydra wrote:
---
libavcodec/nvenc.c | 40 +---
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index bbb43ddad8..a18eb1df89 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nven
Good oh. Thank you.
"No capable devices found" is briefer, I wonder whether it works for a confused
user like me :)
I suppose it would, given it would be in combination the other message expanded
as
"Multiple reference frames are not supported by the device".
On that note, I suppose some or mo
On 17.11.2019 15:58, Oleg Dobkin wrote:
Add AVCUDADeviceContextFlags to control the creation of CUDA device
context for the hardware CUDA decoder.
The current values are 0 (default behavior) - new context will be
created for each decoder, and 1 - primary CUDA context will be used.
There are sev
t now are:
9.1.23.1, 9.0.18.3, 8.2.15.10 and 8.1.24.11
On Sun, 2019-11-17 at 23:31 +0100, Timo Rothenpieler wrote:
On 17.11.2019 15:58, Oleg Dobkin wrote:
Add AVCUDADeviceContextFlags to control the creation of CUDA device
context for the hardware CUDA decoder.
The current values are 0 (default beh
On 18/11/2019 12:25, Oleg Dobkin wrote:
FFmpeg supports multiple tracks of the Video Codec SDK, to support
older
drivers and legacy GPUs that way.
Since the version number only tracks the Video SDK Version, and not
the
CUDA loader version, what needs to be done is to set the new minimum
version f
On 18.11.2019 12:09, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
libavfilter/vf_chromakey.c | 142 +++--
1 file changed, 137 insertions(+), 5 deletions(-)
No complaints about the code. I don't have files to test with, but
assuming you have tested th
On 19.11.2019 17:42, Oleg Dobkin wrote:
Any more comments?
Only thing I'm still wondering is if it would make sense to use the
primary context by default.
I can't think of any obvious downsides, other than weakened isolation,
which really shouldn't be a huge concern.
And there apparently ar
On 20/11/2019 11:29, Oleg Dobkin wrote:
On Tue, 2019-11-19 at 23:58 +0100, Timo Rothenpieler wrote:
Only thing I'm still wondering is if it would make sense to use the
primary context by default.
I can't think of any obvious downsides, other than weakened
isolation,
which really shou
On 20/11/2019 10:30, Alex wrote:
Hi!
We have overlay_opencl, overlay_qsv, ... etc, but don't have overlay_cuda what
can be speed up video processing without copy frame between cpu and gpu.
So, doy You guys planning to implement overlay_cuda filter?
Alex
Ideally, there would soon be CUDA/Vulkan
On 20.11.2019 13:51, Rick Kern wrote:
The current version of clang enables stack checking by default, causing
a crash when binaries are run.
Why does it trigger a crash? Doesn't it indicate something is wrong that
should be fixed instead?
___
ffmpeg
applied with some changes regarding flags and device flags
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "un
I think this was discussed on this list in the past.
Not sure what the conclusion was, but I think an unconditional flag like
this being added wasn't all that well received.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailm
On 04.01.2020 14:37, Michael Niedermayer wrote:
I dont know how effective this is or what exactly this option does, i
couldnt find documentation for it quickly what it does in clang on macosx.
google keeps pointing to gcc
but
a crash is better than arbitrary code execution, which IIUC is the ide
Using a hardware encoder to encode h264 has absolutely no impact on what
can decode the result. It produces absolutely standard h264.
Also, this should be on ffmpeg- or libav-user.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.or
On 20.01.2020 00:50, Ming Ying wrote:
Yes, understood...my question was more about changing the pixel format from
AV_PIX_FMT_CUDA to YUV420P. If I understand correctly, a frame encoded using
h264_nvenc will have the CUDA pixel format (I specified this when I created the
hardware frame context)
On 01.02.2020 20:02, Andriy Gelman wrote:
From: Andriy Gelman
Supports connecting to a RabbitMQ broker via AMQP version 0-9-1. The
broker can redistribute content to other clients based on "exchange" and
"routing_key" fields.
---
Compilation notes:
- Requires librabbitmq-dev package (on ubuntu
Vulkan is the new standard API for interfacing with GPUs.
A video decode API in on the horizon, and shaders can be used as filters.
FFmpeg is primarily a library, the command line tool is pretty much only
an example implementation.
___
ffmpeg-devel mai
On 30.04.2021 13:34, Brad Hards wrote:
Signed-off-by: Brad Hards
---
libavcodec/nvenc.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 0dcd93a99c..1a895a64f4 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -2173,
On 01.05.2021 01:30, Brad Hards wrote:
I don't understand this comment. The existing code defines a fixed size
array,
and I don't want to change it because I couldn't find an authoritative source
as to why that size or approach. I assume it could be a hardware limitation on
at least some versio
On 12.05.2021 15:19, Samuel Marks wrote:
Started hacking around to make it work. So I changed the `main` to a:
extern int ffprobe(int argc, char **argv);
Then I added a header with a prototype of the same, and started
messing with vcpkg + CMake to try and get it to build correctly.
That's not
On 15.05.2021 11:45, Zane van Iperen wrote:
Fixes build failure on older SDKs without it.
Fixes #9242
Signed-off-by: Zane van Iperen
---
libavcodec/videotoolboxenc.c | 5 +
1 file changed, 5 insertions(+)
NB: This is untested, I do not have a Mac to try it on.
diff --git a/libavcodec/
On 16.05.2021 19:46, Jan Ekström wrote:
If you have interest in figuring out building binaries for
distribution, I would recommend contributing to one of the public and
automated build systems such as https://github.com/BtbN/FFmpeg-Builds
.
Currently it has Windows and 64bit Linux in there, and
On 16.05.2021 21:26, Jan Ekström wrote:
On Sun, May 16, 2021 at 10:02 PM Timo Rothenpieler
wrote:
On 16.05.2021 19:46, Jan Ekström wrote:
If you have interest in figuring out building binaries for
distribution, I would recommend contributing to one of the public and
automated build systems
On 17.05.2021 10:19, Brad Hards wrote:
Signed-off-by: Brad Hards
---
libavcodec/nvenc.c | 64 ++
1 file changed, 53 insertions(+), 11 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 0dcd93a99c..e22fdfb5a8 100644
--- a/libavc
On 17.05.2021 17:52, Marton Balint wrote:
Don't we have av_fast_realloc for this?
Yes, but you still need to save the pointer for that somewhere.
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
On 22.05.2021 20:54, Dylan Fernando wrote:
I'm unable to compile on Arch Linux with cuda enabled. Command:
./configure --enable-opencl --enable-vulkan --enable-libglslang
--disable-stripping --enable-nonfree --enable-cuda-nvcc --extra-c
flags=-I/opt/local/cuda/include
Error:
ERROR: failed chec
On 24.05.2021 00:08, Dylan Fernando wrote:
I got it to work, with --enable-cuda as well, using:
PKG_CONFIG_PATH="/home/dylan/Files/nv-codec-headers" ./configure
--enable-opencl --enable-vulkan --enable-libglslang --disable-stripping
--enable-nonfree --enable-cuda --enable-cuda-nvcc
--extra-cflag
On 25/05/2021 12:11, Brad Hards wrote:
Signed-off-by: Brad Hards
---
libavcodec/nvenc.c | 73 +-
libavcodec/nvenc.h | 2 ++
2 files changed, 62 insertions(+), 13 deletions(-)
diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index 0dcd93a99
I'm in favour of switching over to Libera.chat.
Freenodes business model is more than questionable, and some recent
actions of the new staff are questionable at best.
The old Freenode staff have switched to Libera in their entirety, so it
seems only natural to follow along than to stay on a ne
On 26.05.2021 12:43, Gyan Doshi wrote:
On 2021-05-25 16:37, Timo Rothenpieler wrote:
I'm in favour of switching over to Libera.chat.
Freenodes business model is more than questionable, and some recent
actions of the new staff are questionable at best.
The old Freenode staff have swi
On 01.06.2021 11:51, Brad Hards wrote:
Anything more on this version?
Brad
No, but we're investigating weird crashes that are caused by the s12m
timecodes _somehow_, so I'm holding off on merging any other changes in
that area until it's figured out.
smime.p7s
Description: S/MIME Crypto
On 01.06.2021 12:46, Brad Hards wrote:
On Tuesday, 1 June 2021 8:01:13 PM AEST Timo Rothenpieler wrote:
No, but we're investigating weird crashes that are caused by the s12m
timecodes _somehow_, so I'm holding off on merging any other changes in
that area until it's figured out.
On 02.06.2021 00:29, Brad Hards wrote:
Is that consistent with the problem you are seeing?
Brad
It matches the backtrace on both linux and Windows.
Something deep inside the nvidia driver is doing an invalid read.
smime.p7s
Description: S/MIME Cryptographic Signature
__
Pushed a very much refactored version of this patch and some more
refactoring on top of it.
It still shows the crash, but both the previous code and this code seem
fine to me in that regard.
smime.p7s
Description: S/MIME Cryptographic Signature
__
Missed this one, will give it a test.
Looks good to me so far.
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link abo
It'd probably make sense to also copy over the option for evaluating the
expression per-frame or on init.
Given that this is usually going to run much faster than the software
overlay filter, the slight overhead from the expression could be much
more severe.
Looks good otherwise, and for what
On 08.06.2021 21:03, Kevin LaFlamme wrote:
When streaming mode is enabled with fMP4/CMAF for DASH output, the
segment files are available to read by players as soon as the first byte
is written instead of only after the file is fully written. The DASH
manifest currently only gets written when the
On 08.06.2021 21:24, Kevin LaFlamme wrote:
For streaming mode with fragmented MP4 the intention is to have the client read
a partial file since it’s broken up into sequential boxes that are playable
independently. This doesn’t change the segment files themselves or how they are
written, it jus
Applied, thanks!
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org w
---
configure | 2 +
doc/filters.texi| 46 ++
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/cuda/vector_helpers.cuh | 14 +-
libavfilter/version.h | 2 +-
libavfilter/vf_format
On 11.06.2021 12:27, stuhlo wrote:
From: stuhlo
This fixes setting of `key_frame` flag in AVFrame when input h264 packets
represents individual fields of interlaced video.
In this case, pairs of two consecutive fields represents a single decoded
picture and have identical `CurrPicIdx`, howeve
On 11.06.2021 17:33, Steven Liu wrote:
在 2021年6月11日，22:43，Timo Rothenpieler 写道：
Hi Timo,
---
configure | 2 +
doc/filters.texi| 46 ++
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/cuda
---
.gitignore | 1 +
compat/cuda/bin2c.c | 58
compat/cuda/ptx2c.sh| 34
configure | 17 ++
ffbuild/.gitignore | 1 +
ffbuild/common.mak | 28 --
libavfilte
On 12.06.2021 00:42, Timo Rothenpieler wrote:
+#include
+#include
+#include
+
+int main(int argc, char **argv)
+{
+const char *name = NULL;
+unsigned int length = 0;
+unsigned char data;
+
+if (argc != 2) {
+return 1;
+} else {
+int arglen = strlen(argv[1
On 12.06.2021 12:43, Anton Khirnov wrote:
From: Matthieu Patou
compute_30 seems to be removed from CUDA SDK 11.0
It is, that's why just a few lines below there is a check that tests for
that and upgrades the version if necessary.
smime.p7s
Description: S/MIME Cryptographic Signature
On 12.06.2021 07:07, Lynne wrote:
Jun 12, 2021, 00:26 by t...@rothenpieler.org:
On 11.06.2021 17:33, Steven Liu wrote:
在 2021年6月11日，22:43，Timo Rothenpieler 写道：
Hi Timo,
---
configure | 2 +
doc/filters.texi| 46 ++
libavfilter/Makefile
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index bdd23479ba..41449eac5f 100755
--- a/configure
+++ b/configure
@@ -4424,7 +4424,7 @@ fi
exesuf() {
case $1 in
-
mingw32*|mingw64*|win32|win64|cygwin*|*-dos|freedos|opendos|o
On 12.06.2021 18:08, Hendrik Leppkes wrote:
On Sat, Jun 12, 2021 at 2:31 PM Timo Rothenpieler wrote:
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index bdd23479ba..41449eac5f 100755
--- a/configure
+++ b/configure
@@ -4424,7
---
.gitignore | 1 +
compat/cuda/ptx2c.sh| 34
configure | 17 ++
ffbuild/.gitignore | 1 +
ffbuild/bin2c.c | 76 ++
ffbuild/common.mak | 28 --
liba
---
doc/filters.texi | 6 ++
libavfilter/f_select.c | 18 ++
libavfilter/version.h | 2 +-
3 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index da8f7d7726..db6ecd7c2a 100644
--- a/doc/filters.texi
+++ b/doc/filters.te
On 18.06.2021 06:19, Gyan Doshi wrote:
Instead of a specific option for silencedetect, it would be future-proof
if it was an option called, say, metadata with a constant for
silencedetect to start with.
There are multiple per-frame analysis filters like blackframe,
blackdetect, freezedetect..et
On 18.06.2021 13:46, Gyan Doshi wrote:
On 2021-06-18 17:02, Timo Rothenpieler wrote:
On 18.06.2021 06:19, Gyan Doshi wrote:
Instead of a specific option for silencedetect, it would be
future-proof if it was an option called, say, metadata with a
constant for silencedetect to start with
On 18.06.2021 14:35, Gyan Doshi wrote:
The drawtext filter does not use expression evaluation for its text
parameter.
It implements its own logic for that, and it's purely text-replace.
The expression parser does support functions, but only functions with
one or two numeric arguments.
So it'll
---
doc/filters.texi | 18 ++
libavfilter/f_select.c | 79 --
libavfilter/version.h | 2 +-
3 files changed, 96 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index da8f7d7726..05fec04b55 100644
--- a/doc/filt
On 18.06.2021 22:45, Philip Langdale wrote:
On Sat, 12 Jun 2021 18:47:50 +0200
Timo Rothenpieler wrote:
---
.gitignore | 1 +
compat/cuda/ptx2c.sh| 34
configure | 17 ++
ffbuild/.gitignore | 1
On 11.06.2021 16:43, Timo Rothenpieler wrote:
---
configure | 2 +
doc/filters.texi| 46 ++
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/cuda/vector_helpers.cuh | 14 +-
libavfilter
On 21.06.2021 19:56, James Almer wrote:
On 6/17/2021 2:45 PM, James Almer wrote:
The AVCodec.receive_frame() callback takes precedence.
Signed-off-by: James Almer
---
libavcodec/cuviddec.c | 32
1 file changed, 32 deletions(-)
diff --git a/libavcodec/cuvidd
On 18.06.2021 14:50, Timo Rothenpieler wrote:
---
doc/filters.texi | 18 ++
libavfilter/f_select.c | 79 --
libavfilter/version.h | 2 +-
3 files changed, 96 insertions(+), 3 deletions(-)
Will push this soon
smime.p7s
Description
On 25.06.2021 10:14, Lynne wrote:
The prices have dropped a little, but the biggest difference is that
stuff is *actually* available now.
Unfortunately, now is not a good time to build an entire system.
Socket AM4's finished, so if I build an AMD system, it'll be obsolete
within a year or so, an
On 26.06.2021 01:28, Lynne wrote:
Jun 25, 2021, 13:25 by t...@rothenpieler.org:
On 25.06.2021 10:14, Lynne wrote:
The prices have dropped a little, but the biggest difference is that
stuff is *actually* available now.
Unfortunately, now is not a good time to build an entire system.
Socket AM
On 26.06.2021 15:35, Dylan Fernando wrote:
I can't seem to be able to use exp() and sqrt() in CUDA.
I get:
NVCClibavfilter/try_cuda.ptx
clang-11: warning: Unknown CUDA version. cuda.h: CUDA_VERSION=11030.
Assuming the latest supported version 10.1 [-Wunknown-cuda-version]
libavfilter/try_cu
On 27.06.2021 18:42, Dylan Fernando wrote:
Yeah, I was using enable-cuda-llvm.
I haven't been including cuda.h in my cuda file. Could it be from the
include in hwcontext_cuda.h possibly? I was using:
Are you including hwcontext_cuda.h in your Kernel Code?
That's a C side file. You shouldn't re
On 10.07.2021 00:53, Andrii wrote:
Hi,
I am working on porting a Kodi player to an NVidia Jetson Nano device. I've
been developing a decoder for quite some time now, and realized that the
best approach would be to have it inside of ffmpeg, instead of embedding
the decoder into Kodi as it heavily
On 11.07.2021 14:01, Derek Buitenhuis wrote:
Hi Brad,
On 7/8/2021 4:31 AM, Brad Hards wrote:
About a month ago, I submitted a patch to add User Data Unregistered SEI
writing to the x265 implementation.
See http://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/280978.html[1]
and
https://patchwork.
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 2d2d125fd3..f5370b3ead 100755
--- a/configure
+++ b/configure
@@ -6194,7 +6194,7 @@ check_func_headers windows.h Sleep
check_func_headers windows.h VirtualAlloc
check_func_headers glob.h
On 14.07.2021 23:28, James Almer wrote:
On 7/14/2021 6:23 PM, Timo Rothenpieler wrote:
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 2d2d125fd3..f5370b3ead 100755
--- a/configure
+++ b/configure
@@ -6194,7 +6194,7
On 15.07.2021 00:02, James Almer wrote:
On 7/14/2021 6:54 PM, Timo Rothenpieler wrote:
On 14.07.2021 23:28, James Almer wrote:
On 7/14/2021 6:23 PM, Timo Rothenpieler wrote:
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index
On 16.07.2021 18:09, Jai Luthra wrote:
Recent encode API restructure (827d6fe73d) removed some state - which broke
the API for flushing without closing the encoder.
This functionality was originally added in 3ea7057677 and is useful for
segmented video, where we don't want to do expensive re-ini
I'm super loaded with work this week already, so I won't have a chance
to look at this before some time next week.
First glance looks fine though and I'll come back to you with a proper
review next week!
smime.p7s
Description: S/MIME Cryptographic Signature
_
This list is about development of ffmpeg itself.
You are probably looking for libav-users.
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 06/02/2019 11:46, Michael Niedermayer wrote:
There is also a new lets encrypt certificate, these expire frequently
The problem probably is that the server didnt sent the full chain of
certificates
ive manually made a certificate that works now but reimars script needs
an update so it cats all
On 06/02/2019 14:50, Reimar Döffinger wrote:
As I remember, apache actually wants certificate and chain separately, so we
might need to create and use 2 different ones (even if the difference is just a
cat command or so).
https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatechainfi
On 13.02.2019 09:56, Roman Arzumanyan wrote:
Hello,
Please find attached patch, it adds HEVC YUV444P decoding support.
Supported formats are AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV444P10LE,
AV_PIX_FMT_YUV444P12LE.
This feature requires Video Codec SDK 9.
There is one big issue with this.
And th
On 13.02.2019 09:47, Roman Arzumanyan wrote:
Hello,
Please find attached patch for nv-codec-headers.
It adds Video Codec SDK 9 support.
Applied and followed up with a patch adding some more new fields from
SDK 9.0.18.
smime.p7s
Description: S/MIME Cryptographic Signature
___
On 13.02.2019 09:52, Roman Arzumanyan wrote:
Hello,
Please find attached patch, it adds HEVC B-frames support to nvenc_hevc.
This feature requires Video Codec SDK 9 + Turing card.
Will it cause issues if set on an older card, or just plain get ignored?
If it's ignored, this LGTM.
smime.p
On 13.02.2019 20:18, Timo Rothenpieler wrote:
On 13.02.2019 09:52, Roman Arzumanyan wrote:
Hello,
Please find attached patch, it adds HEVC B-frames support to nvenc_hevc.
This feature requires Video Codec SDK 9 + Turing card.
Will it cause issues if set on an older card, or just plain get
On 14.02.2019 05:03, Philip Langdale wrote:
This is the equivalent change for cuviddec after the previous change
for nvdec. I made similar changes to the copying routines to handle
pixel formats in a more generic way.
Note that unlike with nvdec, there is no confusion about the ability
of a code
On 14.02.2019 19:59, Carl Eugen Hoyos wrote:
2019-02-14 18:21 GMT+01:00, Hendrik Leppkes :
On Thu, Feb 14, 2019 at 4:51 PM Carl Eugen Hoyos wrote:
Am 14.02.2019 um 13:39 schrieb Timo Rothenpieler :
ffmpeg | branch: master | Timo Rothenpieler |
Fri Feb 8 22:47:01 2019 +0100
You changed libavfilter but didn't commit (I guess), please mention
ticket #7735.
(I didn't test myself, sorry if there is no issue!)
I just completely missed the parts in libavfilter.
I am thoroughly confused why this did not break compilation for me.
Will push the missing part asap.
smime.p
On 15.02.2019 01:01, Carl Eugen Hoyos wrote:
2019-02-14 23:36 GMT+01:00, Carl Eugen Hoyos :
please mention ticket #7735.
Ping!
I remembered the moment i pushed the patch, sorry.
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-d
On 21.02.2019 04:57, Philip Langdale wrote:
The use of nvcc to compile cuda kernels is distinct from the use of
cuda sdk libraries and linking against those libraries. We have
previously not bothered to distinguish these two cases because all
the filters that used cuda kernels also used the sdk.
The patch seems to be corrupted by something. At least git am is
refusing to apply it, and it looks very jumbled on patchwork.
But it LGTM. Feel free to push.
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg
On 21.02.2019 04:57, Philip Langdale wrote:
I've been thinking about this for a while, but I only recently made the
realisation that compiling cuda kernels to the ptx format does not
introduce any non-free dependencies - the ptx files are an intermediate
assembly code format that is actually comp
This seems weird to me, why would there only be an issue on Ubuntu 16.04?
I'd assume that the code in question has been tested quite a bit.
Do you have an example of where and how it fails?
smime.p7s
Description: S/MIME Cryptographic Signature
___
ff
looks good at first glance, will give it a test this weekend.
smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 08/03/2019 00:57, Carl Eugen Hoyos wrote:
2019-03-06 15:57 GMT+01:00, Oliver Collyer :
Hi
I needed the dynamic resolution changing feature of NVENC to be accessible
through the ffmpeg libraries for a hobby project, so I added support and
here is a patch.
I will format this as a proper patch
On 11/03/2019 09:40, Carl Eugen Hoyos wrote:
2019-03-11 6:36 GMT+01:00, Ruta Gadkari :
Please find attached the patch, it enables ffnvcodec and
nvenc, nvdec, cuvid for PPC64 architecture.
Is it supported on both little and big endian?
Good question.
This email message is for the sole use
201 - 300 of 1371 matches
Mail list logo
