On 12/10/16 13:44, Mark Thompson wrote:
How about the approach in the test program below? This makes the whole timebase
fraction; the suggested timescale would then be the denominator of that. (It is
currently just a program linked with lavu, I could make it into a patch if
someone else thinks
On 12/10/16 14:38, Sven C. Dack wrote:
It may be too much. We only know of 3 video files, which don't play on the
Apple player. We don't know how they got produced, what produced them, what
caused them to have this deviation, if it was done intentionally or by
accident, nor do w
The option is present in nvenc_h264.c, but was missing from nvenc_hevc.c. Please
note that there is a bit of a mess going on in the options with regards to
dashes and underlines. Is there a guideline available for this??
I've settled for "temporal_aq" with nvenc_hevc.c, because of the already
*ping*
The patch didn't seem to have caught anyone's interest. Could somebody please
apply it or say what's wrong?
Thanks
On 09/09/16 10:55, Sven C. Dack wrote:
CUDA/NPP doesn't allow super-sampling in some cases and the module then prints
an error message "NPP resi
On 14/10/16 13:47, tyt xtreme wrote:
Hi,
I already post my mail to ffmpeg-users group regarding this issue but no
one could help me out and advised to ask more experienced users. So i hope
you can tell me something and sorry posting here.
Here is my re-encoding command's output (Windows 8.1 wit
Adds a check to see if the hardware supports temporal aq.
>From a68d7b359d53a4d858a25a146489f24a39f4dad0 Mon Sep 17 00:00:00 2001
From: "Sven C. Dack"
Date: Fri, 14 Oct 2016 15:12:27 +0100
Subject: [PATCH] libavcodec/nvenc.c: add test for Temporal AQ support
---
libavcode
Hello,
I've just noticed how the StreamingGuide
https://trac.ffmpeg.org/wiki/StreamingGuide uses -r for the framerate in its
examples. I believe the correct command line argument here now is -framerate.
___
ffmpeg-devel mailing list
ffmpeg-devel@ff
On 18/10/16 20:26, Ali KIZIL wrote:
Hi Everyone,
Today, I was analyzing memcpy duration in FFmpeg. I noticed that it is
taking longer time compared to an optimized SSE, SSE2, MMX, MMX2, AVX or
AVX2 based memcpy operation.
I tried march=corei7-avx2 compiled FFmpeg version, it does not change the
On 19/10/16 09:34, Yogender Kumar Gupta wrote:
Added capability check for Temporal AQ
Thanks,
Yogender
I've send in 3 patches regarding Nvidia stuff (1. check for temp aq, 2. option
for temp aq in hevc, 3. limitation work-around for scale npp), but there seems
to be no maintainer present at th
On 19/10/16 10:22, Timo Rothenpieler wrote:
Am 19.10.2016 um 11:15 schrieb Sven C. Dack:
On 19/10/16 09:34, Yogender Kumar Gupta wrote:
Added capability check for Temporal AQ
Thanks,
Yogender
I've send in 3 patches regarding Nvidia stuff (1. check for temp aq, 2.
option for temp aq in
On 19/10/16 11:01, Yogender Kumar Gupta wrote:
I've send in 3 patches regarding Nvidia stuff (1. check for temp aq, 2.
option for temp aq in hevc, 3. limitation work-around for scale npp), but
there seems to be no maintainer present at the moment to pick them up...
Tempoal AQ HEVC not supported
On 19/10/16 12:00, Hendrik Leppkes wrote:
On Wed, Oct 19, 2016 at 12:20 PM, Sven C. Dack wrote:
On 19/10/16 11:01, Yogender Kumar Gupta wrote:
I've send in 3 patches regarding Nvidia stuff (1. check for temp aq, 2.
option for temp aq in hevc, 3. limitation work-around for scale npp)
On 19/10/16 13:50, Hendrik Leppkes wrote:
On Wed, Oct 19, 2016 at 2:00 PM, Timo Rothenpieler
wrote:
---
compat/cuda/dynlink_cuda.h | 88 +
compat/cuda/dynlink_cuviddec.h | 808 +
compat/cuda/dynlink_loader.h | 254 +
compat/cud
On 19/10/16 14:24, Hendrik Leppkes wrote:
If its entirely untested (due to being unsupported), it should not be
made available, and instead be added once it is supported and has been
confirmed to be working properly.
There is also no reason to add it if we know it doesn't work, it would
just be m
On 19/10/16 15:25, Hendrik Leppkes wrote:
You seem to be referring to the license of the cuvid files, which is
not the license actually used by the CUDA headers. The CUDA headers
are under a full proprietary license with no such permission.
Are you saying the use of CUDA header files (with #inc
On 19/10/16 17:18, Hendrik Leppkes wrote:
Thats the general interpretation of the license situation. If you
include non-free headers, your binary becomes non-free, hence why
building with cuda currently requires the --enable-nonfree option.
No. This is a generalization and cannot make sense. At b
On 19/10/16 18:56, Andreas Cadhalpun wrote:
I think you are missing the main problem here: FFmpeg is licensed
under the LGPL 2.1, which states [1]:
" 4. You may copy and distribute the Library [...] in object code
or executable form [...] provided that you accompany it with the
complete correspo
On 19/10/16 20:23, Andreas Cadhalpun wrote:
Read the FAQ: "What about the compiler, the toolchain?"
Best regards,
Andreas
1: http://gpl-violations.org/faq/sourcecode-faq/
You are misinterpreting it. The FAQ explicitly excludes external components such
as compilers, kernels and libraries.
On 21/10/16 14:42, Michael Niedermayer wrote:
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundaman
On 23/10/16 13:29, Nicolas George wrote:
The framework will allocate a buffer and copy the data to it,
that takes time. But it avoids constently creating and
destroyng the shared memory segment, and that saves more time.
On my setup,
from ~200 to ~300 FPS at full screen (1920×1200),
from ~1400 t
On 26/10/16 02:30, chengmo wrote:
Hi All:
Do someone encountered this situation like the attach showed ?
If so ,could you give some tips about it ?
What's the problem could it be ?
A couple of things... "libav" and "ffmpeg" are not the same project. So please
Hello,
I haven't been sending patches in ages. Can somebody walk me through?
The patch is a "low hanging fruit" and simply adds the pixel formats RGBA and
BGRA to the Nvidia encoder "nvenc", which supports these two formats natively.
The gain here is that when one grabs the screen with x11grab
On 07/09/16 00:43, Carl Eugen Hoyos wrote:
Should be AV_PIX_FMT_RGB0...
... and AV_PIX_FMT_BGR0
I was wondering about that. The 0 means undefined/unused and I didn't want to
open a can of worms with it. Should I add BGR0 and RGB0, too? Does the 0 mean it
is reliably 0?
Sven
On 07/09/16 01:08, Sven C. Dack wrote:
On 07/09/16 00:43, Carl Eugen Hoyos wrote:
Should be AV_PIX_FMT_RGB0...
... and AV_PIX_FMT_BGR0
I was wondering about that. The 0 means undefined/unused and I didn't want to
open a can of worms with it. Should I add BGR0 and RGB0, too? Does
On 07/09/16 09:23, Timo Rothenpieler wrote:
avctx->width << 1, avctx->height);
+} else if (frame->format == AV_PIX_FMT_RGBA || frame->format ==
AV_PIX_FMT_RGB0) {
+ av_image_copy_plane(buf, lockBufferParams->pitch,
+ frame->data[0], frame->linesize[0],
+
On 07/09/16 10:40, Sven C. Dack wrote:
It is necessary in order to make it work. The twist here is intentional as I
pointed out earlier. If you do it the other way around as described in the
documentation then you get false and missing colours.
I'd like to keep in the transparency ch
On 07/09/16 11:25, Carl Eugen Hoyos wrote:
Hi!
Am 07.09.2016 um 11:40 schrieb "Sven C. Dack" :
On 07/09/16 09:23, Timo Rothenpieler wrote:
Otherwise will RGBA/BGRA have to
be converted into RGB0/BGR0
and you will again get a performance penalty.
What makes you think so?
I have
On 07/09/16 12:27, Carl Eugen Hoyos wrote:
If your patch adds "RGBA" as supported colour space,
the encoder (by definition) announces that it supports
transparency.
nvenc does not support transparency (if it would, it would
be a - grave - bug to use "RGB0" in the patch). So please
do not add it.
On 07/09/16 12:40, Timo Rothenpieler wrote:
libavutil/pixfmt.h defines AV_PIX_FMT_RGB0 and the other ones like this:
packed RGB 8:8:8, 32bpp, XRGBXRGB... X=unused/undefined
So I would expect the Alpha-Channel to be anything, and converting from
RGBA to RGB0 to be a no-op "conversion".
It is
On 07/09/16 14:33, Timo Rothenpieler wrote:
0RGB/0BGR does not mean the alpha bits are zeroed.
It means they are undefined, so you convert from ARGB to 0RGB by doing
nothing. There is no performance to gain by supporting a format that
falsely advertises support for an alpha channel.
Also, the co
On 07/09/16 15:01, Sven C. Dack wrote:
On 07/09/16 14:33, Timo Rothenpieler wrote:
0RGB/0BGR does not mean the alpha bits are zeroed.
It means they are undefined, so you convert from ARGB to 0RGB by doing
nothing. There is no performance to gain by supporting a format that
falsely advertises
On 07/09/16 17:52, Timo Rothenpieler wrote:
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I've updated my git clone and it is now seg faulting.
Sven
$ ffmpeg -f x11grab -framerate 200
On 08/09/16 00:57, Hendrik Leppkes wrote:
The image copying code was refactored in an earlier patch to be
generic and not rely on hard-coding format info, hence the second part
is not needed anymore.
This is not quite accurate. It doesn't explain the seg. fault. This didn't
happen in my patch
On 08/09/16 08:46, Timo Rothenpieler wrote:
Am 08.09.2016 um 02:29 schrieb Sven C. Dack:
On 08/09/16 00:57, Hendrik Leppkes wrote:
The image copying code was refactored in an earlier patch to be
generic and not rely on hard-coding format info, hence the second part
is not needed anymore
Hallo,
ich schicke Dir noch einen weitere Backtrace mit etwas mehr Details:
(gdb) bt
#0 0x7f19eb8e3a3e in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x00fbc63e in av_image_copy_plane (height=8, bytewidth=7680,
src_linesize=, src=0x7f19ea08f000 "", dst_linesize=out>, dst=) at sr
frame->linesize, frame->format,
- nv_surface->width, nv_surface->height);
+ avctx->width, avctx->height);
return 0;
}
... then it's again working for me.
Sven
On 08/09/16 11:00, Sven C. Dack wrote:
Hallo,
ich schicke Dir noch eine
On 08/09/16 15:17, Andy Furniss wrote:
Carl Eugen Hoyos wrote:
2016-09-08 12:01 GMT+02:00 Andy Furniss :
I don't know what it is about x11grab/CSC with ffmpeg, but
on my old CPU gstreamer is twice as fast.
x11grab or xcb?
I guess xcb as I don't --enable anything related with configure.
I
mpeg
select an alternative algorithm and prints a warning in such cases.
Sven
>From aacd8ecc2f39a45bbfdf6780d9b3b13e6ed0fb41 Mon Sep 17 00:00:00 2001
From: "Sven C. Dack"
Date: Fri, 9 Sep 2016 10:18:07 +0100
Subject: [PATCH] Select cubic and lanczos as alternative wh
On 09/09/16 11:03, Carl Eugen Hoyos wrote:
2016-09-09 11:55 GMT+02:00 Sven C. Dack :
Super-sampling is currently only supported by CUDA/NPP when the output
dimensions are both smaller than the input dimensions. The patch lets ffmpeg
select an alternative algorithm and prints a warning in such
On 10/09/16 18:35, Andy Furniss wrote:
Andy Furniss wrote:
With gstreamer 1080p I can get around 350 fps testing like -
gst-launch-1.0 -f ximagesrc use-damage=0 startx=0 starty=0 endx=1919
endy=1079 num-buffers=5000 ! queue ! videoconvert !
video/x-raw,framerate=500/1,format=BGRx ! fakesink S
On 11/09/16 02:07, Carl Eugen Hoyos wrote:
Or actually: Don't you agree that a deprecation message printed by
the program would make much more sense?
Carl Eugen
This could interfere with users' current scripts for running ffserver and turn
into "adding insult to injury" for the time it is st
On 11/09/16 08:39, Nicolas George wrote:
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit :
This could interfere with users' current scripts for running ffserver and
turn into "adding insult to injury" for the time it is still around.
Deprecation messages go to s
On 11/09/16 10:45, Nicolas George wrote:
Le sextidi 26 fructidor, an CCXXIV, Sven C. Dack a écrit :
Error messages go to stderr and one sometimes parses these to respond to an
error.
This is bogus and should not be considered a reason for design decisions.
If there are cases where this is
On 11/09/16 15:12, Nicolas George wrote:
I do not care at all about ffserver, but the argument of parsing stderr to
revuse a warning is completely void, period.
Regards,
Please no foot stomping of opinions. When you cannot see how changing the output
can confuse scripts of users then that's o
On 11/09/16 16:31, Nicolas George wrote:
I see how it can do that, but you refuse to understand that this part of the
output is not meant to be parsed, unlike, for example, the output of
ffprobe.
Nonsense. All messages, regardless if send to stdout or stderr, can be parsed.
There is no rule in
On 11/09/16 18:27, Clément Bœsch wrote:
Aside from the stdout output in ffprobe, no stdout/stderr output is
standardized in FFmpeg and thus can be changed at will (and does
regularly). You can try to parse it, but there is zero warranty that it
will work the next day.
Regards,
Did you at least
On 11/09/16 18:55, Moritz Barsnick wrote:
Moin Sven,
On Fri, Sep 09, 2016 at 11:13:55 +0100, Sven C. Dack wrote:
I may be missing something, but my excuse is that I can't test, but just
inspect by looking at it:
+ if (s->interp_algo == NPPI_INTER_SUPER &&
+
On 11/09/16 18:57, Clément Bœsch wrote:
I think we disagree, because no user of a working setup will ever read the
documentation just to check for deprecated tools. Having the warning at
runtime is the most efficient way to reach out a maximum of users as soon
as possible so they have time to mig
On 11/09/16 19:45, Nicolas George wrote:
Please stop about ffserver. This branch of the discussion is not about
ffserver, it is about you not understanding 40+ years of good software
design, namely the separation between normalized reliable output on stdout
and human-readable diagnosis output on
On 11/09/16 21:41, Hendrik Leppkes wrote:
We don't care because "caring" would severly limit the things we can
change in the code.
Your logic would be sound if the code hadn't been declared as deprecated. I do
agree that for live code the users have to accept changes when it means there is
a
On 11/09/16 20:37, Matthieu Beghin wrote:
I see various solutions:
1- I could put in cache more than one second of audio and video and I should
be ok, but with 4k movies, keeping 30 frames could imply using a huge amount of
memory and I would like to avoid that.
2- I could open the file tw
On 27/09/16 14:30, Michael Niedermayer wrote:
Hi all
Its long since FFmpeg 3.1, so its time to make 3.2
ill branch release/3.2 off master and make 3.2 in maybe about a week or
2 unless something delays it
also a name needs to be choosen
Thanks
I narrowed it down for myself to Trump, Clinton
52 matches
Mail list logo
