[FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-06 Thread Sven C. Dack
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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-06 Thread Sven C. Dack
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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-06 Thread Sven C. Dack
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 the 0

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-07 Thread Sven C. Dack
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 channel

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-07 Thread Sven C. Dack
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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-07 Thread Sven C. Dack
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.

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-07 Thread Sven C. Dack
On 07/09/16 11:25, Carl Eugen Hoyos wrote: Hi! Am 07.09.2016 um 11:40 schrieb "Sven C. Dack" <sven.c.d...@sky.com>: 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 ma

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-07 Thread Sven C. Dack
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], +

Re: [FFmpeg-devel] Possible incomplete commit "avcodec/nvenc: support RGB input"

2016-09-08 Thread Sven C. Dack
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

Re: [FFmpeg-devel] Possible incomplete commit "avcodec/nvenc: support RGB input"

2016-09-08 Thread Sven C. Dack
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

Re: [FFmpeg-devel] Possible incomplete commit "avcodec/nvenc: support RGB input"

2016-09-08 Thread Sven C. Dack
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 einen wei

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-08 Thread Sven C. Dack
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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-07 Thread Sven C. Dack
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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-07 Thread Sven C. Dack
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

Re: [FFmpeg-devel] Possible incomplete commit "avcodec/nvenc: support RGB input"

2016-09-07 Thread 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. This is not quite accurate. It doesn't explain the seg. fault. This didn't happen in my

Re: [FFmpeg-devel] [PATCH] configure: don't build ffserver unless explicitly enabled

2016-09-11 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH] configure: don't build ffserver unless explicitly enabled

2016-09-11 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH] configure: don't build ffserver unless explicitly enabled

2016-09-11 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH] configure: don't build ffserver unless explicitly enabled

2016-09-11 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH] Select cubic and lanczos as alternative where super-sampling is not supported

2016-09-11 Thread Sven C. Dack
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 && +

Re: [FFmpeg-devel] [PATCH] configure: don't build ffserver unless explicitly enabled

2016-09-11 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH] configure: don't build ffserver unless explicitly enabled

2016-09-11 Thread Sven C. Dack
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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-10 Thread Sven C. Dack
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

Re: [FFmpeg-devel] Strategy to optimally playback audio & video

2016-09-12 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH] Select cubic and lanczos as alternative where super-sampling is not supported

2016-09-09 Thread Sven C. Dack
On 09/09/16 11:03, Carl Eugen Hoyos wrote: 2016-09-09 11:55 GMT+02:00 Sven C. Dack <sven.c.d...@sky.com>: 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 alg

[FFmpeg-devel] [PATCH] Select cubic and lanczos as alternative where super-sampling is not supported

2016-09-09 Thread Sven C. Dack
prints a warning in such cases. Sven >From aacd8ecc2f39a45bbfdf6780d9b3b13e6ed0fb41 Mon Sep 17 00:00:00 2001 From: "Sven C. Dack" <s...@debian-linux.no.domain> Date: Fri, 9 Sep 2016 10:18:07 +0100 Subject: [PATCH] Select cubic and lanczos as alternative where super-sampling

Re: [FFmpeg-devel] [PATCH] configure: don't build ffserver unless explicitly enabled

2016-09-11 Thread Sven C. Dack
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 stderr

Re: [FFmpeg-devel] [PATCH] configure: don't build ffserver unless explicitly enabled

2016-09-11 Thread Sven C. Dack
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

Re: [FFmpeg-devel] adding RGBA and BGRA to nvenc.c

2016-09-07 Thread Sven C. Dack
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

Re: [FFmpeg-devel] FFmpeg 3.2

2016-09-27 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH 1/8] compat/cuda: add dynamic loader

2016-10-19 Thread Sven C. Dack
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.

Re: [FFmpeg-devel] [PATCH]nvenc: Add capability check for Temporal AQ

2016-10-19 Thread Sven C. Dack
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 hevc

Re: [FFmpeg-devel] [PATCH]nvenc: Add capability check for Temporal AQ

2016-10-19 Thread Sven C. Dack
On 19/10/16 12:00, Hendrik Leppkes wrote: On Wed, Oct 19, 2016 at 12:20 PM, Sven C. Dack <sven.c.d...@sky.com> 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-

Re: [FFmpeg-devel] [PATCH]nvenc: Add capability check for Temporal AQ

2016-10-19 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH]nvenc: Add capability check for Temporal AQ

2016-10-19 Thread 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 hevc, 3. limitation work-around for scale npp), but there seems to be no maintainer present at

Re: [FFmpeg-devel] [PATCH 1/8] compat/cuda: add dynamic loader

2016-10-19 Thread Sven C. Dack
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

Re: [FFmpeg-devel] h264_nvenc encoding issue

2016-10-14 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH] Select cubic and lanczos as alternative where super-sampling is not supported

2016-10-14 Thread Sven C. Dack
*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 resize error: -23".

[FFmpeg-devel] [PATCH] libavcodec/nvenc.c: add test for Temporal AQ support

2016-10-14 Thread Sven C. Dack
Adds a check to see if the hardware supports temporal aq. >From a68d7b359d53a4d858a25a146489f24a39f4dad0 Mon Sep 17 00:00:00 2001 From: "Sven C. Dack" <sven.c.d...@sky.com> Date: Fri, 14 Oct 2016 15:12:27 +0100 Subject: [PATCH] libavcodec/nvenc.c: add test for

Re: [FFmpeg-devel] Memcpy Operation Duration

2016-10-18 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH] lavd/xcbgrab: do not try to create refcounted packets.

2016-10-25 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH 4/7] avcodec/mpegvideo_enc: Add missing emms_c() to clear MMX state after SIMD use

2016-10-21 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH 1/8] compat/cuda: add dynamic loader

2016-10-19 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH]nvenc: Add capability check for Temporal AQ

2016-10-19 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH 1/8] compat/cuda: add dynamic loader

2016-10-19 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH 1/8] compat/cuda: add dynamic loader

2016-10-19 Thread Sven C. Dack
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

[FFmpeg-devel] [PATCH] libavcodec/nvenc_hevc.c: Added missing option -temporal_aq

2016-10-13 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH v2] lavf/movenc: suggest video_track_timescale for invalid timescale

2016-10-12 Thread Sven C. Dack
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

Re: [FFmpeg-devel] [PATCH v2] lavf/movenc: suggest video_track_timescale for invalid timescale

2016-10-12 Thread Sven C. Dack
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 we know why

[FFmpeg-devel] replacing -r for -framerate in StreamingGuide

2016-10-16 Thread Sven C. Dack
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