Re: [FFmpeg-user] 4K RGB->YUV realtime conversion.
On Tue, Mar 09, 2021 at 07:38:09AM +0100, Anders Degerberg wrote: > On Tue, Mar 9, 2021 at 4:52 AM Peter White wrote: > > > Just an aside, you need to specifiy the -sws_flags like this: > > -sws_flags bilinear+print_info > > Thanks Peter, > unfortunately it does not seem to improve the yuv conversion speed, > still at about 0.6x. Some output below: Having thought about it some more, I believe that is to be expected, since basically no real interpolation is taking place other than converting data types, if I am not mistaken. But I could not help but notice this curiosity: > [auto_scaler_0 @ 0x4508600] w:iw h:ih flags:'bicubic' interl:0 Here it states bicubic. > [swscaler @ 0x450a040] bilinear scaler, from gbrp10le to yuv444p16le And now it is bilinear. Or did you mix the output of two different invocations? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] 4K RGB->YUV realtime conversion.
On Tue, Mar 9, 2021 at 4:52 AM Peter White wrote: > Just an aside, you need to specifiy the -sws_flags like this: > -sws_flags bilinear+print_info Thanks Peter, unfortunately it does not seem to improve the yuv conversion speed, still at about 0.6x. Some output below: - snip - [graph 0 input from stream 0:1 @ 0x44c7480] w:4096 h:2160 pixfmt:gbrp10le tb:1/100 fr:25000/1000 sar:0/1 [auto_scaler_0 @ 0x4508600] w:iw h:ih flags:'bicubic' interl:0 [format @ 0x44d9bc0] auto-inserting filter 'auto_scaler_0' between the filter 'Parsed_null_0' and the filter 'format' SwScaler: reducing / aligning filtersize 1 -> 4 Last message repeated 1 times SwScaler: reducing / aligning filtersize 1 -> 1 Last message repeated 1 times [swscaler @ 0x450a040] bilinear scaler, from gbrp10le to yuv444p16le using MMXEXT [swscaler @ 0x450a040] 4096x2160 -> 4096x2160 [auto_scaler_0 @ 0x4508600] w:4096 h:2160 fmt:gbrp10le sar:0/1 -> w:4096 h:2160 fmt:yuv444p16le sar:0/1 flags:0x4 [hevc_nvenc @ 0x44dd4c0] Loaded Nvenc version 11.0 - snip - ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] 4K RGB->YUV realtime conversion.
On Mon, Mar 08, 2021 at 09:46:22PM +0100, Anders Degerberg wrote: > Hi, see output below: > $ ffmpeg -loglevel verbose -f decklink -raw_format rgb10 -i "DeckLink > 8K Pro (1)" -sws_flags bilinear -sws_flags print_info -c:v hevc_nvenc > -an -b:v 30M -f null - Just an aside, you need to specifiy the -sws_flags like this: -sws_flags bilinear+print_info Otherwise the last -sws_flags occurence wins, as can be seen below. > [auto_scaler_0 @ 0x46e2b00] w:iw h:ih flags:'bicubic' interl:0 > [format @ 0x46e0cc0] auto-inserting filter 'auto_scaler_0' between the > filter 'Parsed_null_0' and the filter 'format' > SwScaler: reducing / aligning filtersize 1 -> 4 > Last message repeated 1 times > SwScaler: reducing / aligning filtersize 1 -> 1 > Last message repeated 1 times > [swscaler @ 0x46e4540] bicubic scaler, from gbrp10le to yuv444p16le using > MMXEXT > [swscaler @ 0x46e4540] 4096x2160 -> 4096x2160 It is still using the default bicubic algoritm. Peter ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] 4K RGB->YUV realtime conversion.
Am Mo., 8. März 2021 um 23:32 Uhr schrieb Anders Degerberg : > > On Mon, Mar 8, 2021 at 10:44 PM Carl Eugen Hoyos wrote: > > > Just to make sure that our assumption that this would need > > changes in libswscale is correct, please also test the following: > > -pix_fmt yuv444p16 -vcodec rawvideo -an -f null - > > -i "Decklink ..." -an -f null - > > and compare the speed (or fps) indicator. > > Hi Carl Eugen, > thanks for looking into this, and my apologies for the top-posting mistake. > > - With pix_fmt yuv444p16 and rawvideo, auto_scaler engages, and I get > 15fps/0.6x. One cpu thread at 100%, a few other threads around 10-20%. > - Without changing pix_fmt, passing on the rgb data straight to null > pipe, I get full framerate, 25fps/1x. One or two cpu-threads around > 20-40%. This shows that the assumption was correct, libswscale is the culprit. Carl Eugen ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] 4K RGB->YUV realtime conversion.
On Mon, Mar 8, 2021 at 10:44 PM Carl Eugen Hoyos wrote: > Just to make sure that our assumption that this would need > changes in libswscale is correct, please also test the following: > -pix_fmt yuv444p16 -vcodec rawvideo -an -f null - > -i "Decklink ..." -an -f null - > and compare the speed (or fps) indicator. Hi Carl Eugen, thanks for looking into this, and my apologies for the top-posting mistake. - With pix_fmt yuv444p16 and rawvideo, auto_scaler engages, and I get 15fps/0.6x. One cpu thread at 100%, a few other threads around 10-20%. - Without changing pix_fmt, passing on the rgb data straight to null pipe, I get full framerate, 25fps/1x. One or two cpu-threads around 20-40%. See output for the two tests below, a bit shortened for convenience. Kind regards Anders $ ffmpeg -loglevel verbose -f decklink -raw_format rgb10 -i "DeckLink 8K Pro (1)" -pix_fmt yuv444p16 -vcodec rawvideo -an -f null - [decklink @ 0x455e900] Found Decklink mode 4096 x 2160 with rate 25.00 Input #0, decklink, from 'DeckLink 8K Pro (1)': Duration: N/A, start: 0.00, bitrate: 6637056 kb/s Stream #0:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s Stream #0:1: Video: r210, 1 reference frame, gbrp10le(progressive), 4096x2160, 6635520 kb/s, 25 tbr, 1000k tbn, 1000k tbc Stream mapping: Stream #0:1 -> #0:0 (r210 (native) -> rawvideo (native)) Press [q] to stop, [?] for help [graph 0 input from stream 0:1 @ 0x45ab280] w:4096 h:2160 pixfmt:gbrp10le tb:1/100 fr:25000/1000 sar:0/1 [auto_scaler_0 @ 0x45ae1c0] w:iw h:ih flags:'bicubic' interl:0 [format @ 0x45ac3c0] auto-inserting filter 'auto_scaler_0' between the filter 'Parsed_null_0' and the filter 'format' [auto_scaler_0 @ 0x45ae1c0] w:4096 h:2160 fmt:gbrp10le sar:0/1 -> w:4096 h:2160 fmt:yuv444p16le sar:0/1 flags:0x4 Output #0, null, to 'pipe:': Metadata: encoder : Lavf58.71.100 Stream #0:0: Video: rawvideo, 1 reference frame (Y3[0][16] / 0x10003359), yuv444p16le(tv, progressive), 4096x2160 (0x0), q=2-31, 10616832 kb/s, 25 fps, 25 tbn Metadata: encoder : Lavc58.129.100 rawvideo [decklink @ 0x455e900] Decklink input buffer overrun!bitrate=N/A speed=0.604x --- $ ffmpeg -loglevel verbose -f decklink -raw_format rgb10 -i "DeckLink 8K Pro (1)" -an -f null - [decklink @ 0x451c8c0] Found Decklink mode 4096 x 2160 with rate 25.00 Input #0, decklink, from 'DeckLink 8K Pro (1)': Duration: N/A, start: 0.00, bitrate: 6637056 kb/s Stream #0:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s Stream #0:1: Video: r210, 1 reference frame, gbrp10le(progressive), 4096x2160, 6635520 kb/s, 25 tbr, 1000k tbn, 1000k tbc Stream mapping: Stream #0:1 -> #0:0 (r210 (native) -> wrapped_avframe (native)) Press [q] to stop, [?] for help [graph 0 input from stream 0:1 @ 0x456a600] w:4096 h:2160 pixfmt:gbrp10le tb:1/100 fr:25000/1000 sar:0/1 Output #0, null, to 'pipe:': Metadata: encoder : Lavf58.71.100 Stream #0:0: Video: wrapped_avframe, 1 reference frame, gbrp10le(progressive), 4096x2160 (0x0), q=2-31, 200 kb/s, 25 fps, 25 tbn Metadata: encoder : Lavc58.129.100 wrapped_avframe frame= 492 fps= 25 q=-0.0 Lsize=N/A time=00:00:19.68 bitrate=N/A speed= 1x ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] 4K RGB->YUV realtime conversion.
Am Mo., 8. März 2021 um 21:46 Uhr schrieb Anders Degerberg : > > Hi, see output below: > $ ffmpeg -loglevel verbose -f decklink -raw_format rgb10 -i "DeckLink > 8K Pro (1)" -sws_flags bilinear -sws_flags print_info -c:v hevc_nvenc > -an -b:v 30M -f null - Just to make sure that our assumption that this would need changes in libswscale is correct, please also test the following: -pix_fmt yuv444p16 -vcodec rawvideo -an -f null - -i "Decklink ..." -an -f null - and compare the speed (or fps) indicator. Please find out what top-posting means and avoid it here, Carl Eugen ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] 4K RGB->YUV realtime conversion.
Hi, see output below: $ ffmpeg -loglevel verbose -f decklink -raw_format rgb10 -i "DeckLink 8K Pro (1)" -sws_flags bilinear -sws_flags print_info -c:v hevc_nvenc -an -b:v 30M -f null - ffmpeg version N-101405-g2570663 Copyright (c) 2000-2021 the FFmpeg developers built with gcc 10 (GCC) configuration: --prefix=/home/admin/ffmpeg_build --pkg-config-flags=--static --extra-cflags='-I/home/admin/ffmpeg_build/include -I/home/admin/ffmpeg_build/include/decklink -I/usr/local/cuda/include' --extra-ldflags='-L/home/admin/ffmpeg_build/lib -L/home/admin/ffmpeg_build/include/decklink -L/usr/local/cuda/lib64' --extra-libs=-lpthread --extra-libs=-lm --bindir=/home/admin/bin --enable-gpl --enable-libfdk_aac --enable-libfreetype --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-nonfree --enable-libsrt --enable-decklink --enable-nvenc --enable-cuda --enable-libnpp --enable-pthreads libavutil 56. 67.100 / 56. 67.100 libavcodec 58.129.100 / 58.129.100 libavformat58. 71.100 / 58. 71.100 libavdevice58. 12.100 / 58. 12.100 libavfilter 7.109.100 / 7.109.100 libswscale 5. 8.100 / 5. 8.100 libswresample 3. 8.100 / 3. 8.100 libpostproc55. 8.100 / 55. 8.100 [decklink @ 0x4677940] Autodetected the input mode [decklink @ 0x4677940] Found Decklink mode 4096 x 2160 with rate 25.00 [decklink @ 0x4677940] Using 2 input audio channels Guessed Channel Layout for Input Stream #0.0 : stereo Input #0, decklink, from 'DeckLink 8K Pro (1)': Duration: N/A, start: 0.00, bitrate: 6637056 kb/s Stream #0:0: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s Stream #0:1: Video: r210, 1 reference frame, gbrp10le(progressive), 4096x2160, 6635520 kb/s, 25 tbr, 1000k tbn, 1000k tbc Stream mapping: Stream #0:1 -> #0:0 (r210 (native) -> hevc (hevc_nvenc)) Press [q] to stop, [?] for help [graph 0 input from stream 0:1 @ 0x46e06c0] w:4096 h:2160 pixfmt:gbrp10le tb:1/100 fr:25000/1000 sar:0/1 [auto_scaler_0 @ 0x46e2b00] w:iw h:ih flags:'bicubic' interl:0 [format @ 0x46e0cc0] auto-inserting filter 'auto_scaler_0' between the filter 'Parsed_null_0' and the filter 'format' SwScaler: reducing / aligning filtersize 1 -> 4 Last message repeated 1 times SwScaler: reducing / aligning filtersize 1 -> 1 Last message repeated 1 times [swscaler @ 0x46e4540] bicubic scaler, from gbrp10le to yuv444p16le using MMXEXT [swscaler @ 0x46e4540] 4096x2160 -> 4096x2160 [auto_scaler_0 @ 0x46e2b00] w:4096 h:2160 fmt:gbrp10le sar:0/1 -> w:4096 h:2160 fmt:yuv444p16le sar:0/1 flags:0x4 [hevc_nvenc @ 0x46b7f40] Loaded Nvenc version 11.0 [hevc_nvenc @ 0x46b7f40] Nvenc initialized successfully [hevc_nvenc @ 0x46b7f40] 1 CUDA capable devices found [hevc_nvenc @ 0x46b7f40] [ GPU #0 - < TITAN X (Pascal) > has Compute SM 6.1 ] [hevc_nvenc @ 0x46b7f40] supports NVENC Output #0, null, to 'pipe:': Metadata: encoder : Lavf58.71.100 Stream #0:0: Video: hevc (Rext), 1 reference frame, yuv444p16le(tv, progressive), 4096x2160 (0x0), q=2-31, 3 kb/s, 25 fps, 25 tbn Metadata: encoder : Lavc58.129.100 hevc_nvenc Side data: cpb: bitrate max/min/avg: 0/0/3000 buffer size: 6000 vbv_delay: N/A [decklink @ 0x4677940] Decklink input buffer overrun!bitrate=N/A speed= 0.6x Last message repeated 9 times [decklink @ 0x4677940] Decklink input buffer overrun!bitrate=N/A speed=0.615x Last message repeated 14 times Den mån 8 mars 2021 kl 20:35 skrev Dennis Mungai : > > On Mon, 8 Mar 2021 at 17:49, Anders Degerberg wrote: > > > Hi, > > > > I've come across a problem I really can't figure out when trying to stream > > realtime a RGB 10-bit Decklink input, as YUV444 10-bit HEVC in 25fps. > > In a 1920x1080 resolution on the Decklink input, it all works very well, > > using hevc_nvenc codec on a Nvidia GPU. Auto_scaler kicks in converting the > > correctly identified 'gbrp10le' input format to 'yuv44416le' for > > hevc_nvenc. > > But doing the same in 4K resolution causes input buffer overruns, only > > capable of about 20 fps. When watching CPU usage, there's only real load on > > one of the 32 threads, and that load is maxing out at 99%. CPU frequency is > > close to 4GHz on the AMD CPU. > > If I then switch the Decklink input to YUV instead, 4K works fine, so the > > hevc encoding on the gpu or streaming protocol is not the bottleneck. > > This makes me think the problem lies with the auto_scaler RGB->YUV not > > keeping up with 4096x2160 pixels. This RGB->YUV conversion is done in > > libswscale I understand. I've tried to use -filter_threads and -threads to > > increase thread usage of the swscale, but it still seems to use only one > > thread. > > > > Any suggestions how I can do this 4K RGB 10-bit->YUV444 10-bit colorspace > > conversion in ffmpeg in realtime? > > > > I've tried to hwupload to the gpu to be able to use scale_npp, but > > auto_scaler kicks in before I have the chance to send the RGB data to the > > -vf filters. > > > > I've also
Re: [FFmpeg-user] 4K RGB->YUV realtime conversion.
On Mon, 8 Mar 2021 at 17:49, Anders Degerberg wrote: > Hi, > > I've come across a problem I really can't figure out when trying to stream > realtime a RGB 10-bit Decklink input, as YUV444 10-bit HEVC in 25fps. > In a 1920x1080 resolution on the Decklink input, it all works very well, > using hevc_nvenc codec on a Nvidia GPU. Auto_scaler kicks in converting the > correctly identified 'gbrp10le' input format to 'yuv44416le' for > hevc_nvenc. > But doing the same in 4K resolution causes input buffer overruns, only > capable of about 20 fps. When watching CPU usage, there's only real load on > one of the 32 threads, and that load is maxing out at 99%. CPU frequency is > close to 4GHz on the AMD CPU. > If I then switch the Decklink input to YUV instead, 4K works fine, so the > hevc encoding on the gpu or streaming protocol is not the bottleneck. > This makes me think the problem lies with the auto_scaler RGB->YUV not > keeping up with 4096x2160 pixels. This RGB->YUV conversion is done in > libswscale I understand. I've tried to use -filter_threads and -threads to > increase thread usage of the swscale, but it still seems to use only one > thread. > > Any suggestions how I can do this 4K RGB 10-bit->YUV444 10-bit colorspace > conversion in ffmpeg in realtime? > > I've tried to hwupload to the gpu to be able to use scale_npp, but > auto_scaler kicks in before I have the chance to send the RGB data to the > -vf filters. > > I've also tried to build with a patch for multi-thread swscale found here: > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/c1125bd979e9ae41908dc4913cbfacbb67a31...@irsmsx103.ger.corp.intel.com/ > But this patch doesn't seem to make a difference for the rgb2yuv colorspace > conversions, it's probably only affective for image up/downscaling? > > Kind regards > Anders > > Hello there, What is your exact ffmpeg command, and output? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] 4K RGB->YUV realtime conversion.
On Mon, Mar 08, 2021 at 07:58:44PM +0100, Anders Degerberg wrote: > Hi Peter, > > On Mon, 8 Mar 2021 at 19:18, Peter White wrote: > > Try: > > > > ffmpeg -i input_file -sws_flags show_info ... output_file > '-sws_flags print_info' gives: > [swscaler @ 0x4752f00] bicubic scaler, from gbrp10le to yuv444p16le using > MMXEXT Seeing that, maybe try a different scaling algorithm, like bilinear? One thing that just came to mind: to check the impact of the color space conversion alone is like this: ffmpeg -i input -sws_flags bilinear -f null - To be honest, I have no clue if, the scaling algorithm has any effect on quality of the conversion, but at least it might be worth shot. On the other stuff below I am out of my depth. I am sure there are others, that know more on that. BTW, it helps a lot to provide the full output of the command, at least everything before the stats line. Peter ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] 4K RGB->YUV realtime conversion.
Hi Peter, On Mon, 8 Mar 2021 at 19:18, Peter White wrote: > Try: > > ffmpeg -i input_file -sws_flags show_info ... output_file '-sws_flags print_info' gives: [swscaler @ 0x4752f00] bicubic scaler, from gbrp10le to yuv444p16le using MMXEXT > Do you really have to use RGB on the Decklink? Seems pointless to me, if > it has to be converted anyway. Why not simply keep it in YUV-mode? Basically because the SDI signal I feed to the Decklink card is received from a RGB-10 bit monitor feed. I've been thinking about inserting a hardware RGB->YUV converter in between, but unfortunately the ffmpeg decklink input device doesn't support yuv444p10. Therefore, doing so will introduce an unnecessary chroma subsampling step which I'm trying to avoid. > Maybe it is because of the massive amount of data that needs to be > shifted around. Not sure, but 4K is four times as much data as 1080p. Yes, converting RGB 10bit ->YUV in 1920x1080 creates about 40% load on the 4GHz Ryzen processor thread at 25fps. So I guess 4K would need 4x40%=160%(impossible) load on that one thread, or a multi-thread solution for libswscale's rgb2yuv conversion? ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-user] 4K RGB->YUV realtime conversion.
On Mon, Mar 08, 2021 at 03:19:46PM +0100, Anders Degerberg wrote: > Hi, > > I've come across a problem I really can't figure out when trying to stream > realtime a RGB 10-bit Decklink input, as YUV444 10-bit HEVC in 25fps. > In a 1920x1080 resolution on the Decklink input, it all works very well, > using hevc_nvenc codec on a Nvidia GPU. Auto_scaler kicks in converting the > correctly identified 'gbrp10le' input format to 'yuv44416le' for hevc_nvenc. > > But doing the same in 4K resolution causes input buffer overruns, only > capable of about 20 fps. When watching CPU usage, there's only real load on > one of the 32 threads, and that load is maxing out at 99%. CPU frequency is > close to 4GHz on the AMD CPU. > If I then switch the Decklink input to YUV instead, 4K works fine, so the > hevc encoding on the gpu or streaming protocol is not the bottleneck. I am not sure, which pixel formats (-pix_fmt) the hevc_nvenc supports but YUV seems a reasonable guess. That is why it runs fine with that format. But for the conversion of RGB to YUV the software scaler seems to kick in, which explains the high processor load. Try: ffmpeg -i input_file -sws_flags show_info ... output_file and send the output. > Any suggestions how I can do this 4K RGB 10-bit->YUV444 10-bit colorspace > conversion in ffmpeg in realtime? Do you really have to use RGB on the Decklink? Seems pointless to me, if it has to be converted anyway. Why not simply keep it in YUV-mode? > I've also tried to build with a patch for multi-thread swscale found here: > https://patchwork.ffmpeg.org/project/ffmpeg/patch/c1125bd979e9ae41908dc4913cbfacbb67a31...@irsmsx103.ger.corp.intel.com/ > But this patch doesn't seem to make a difference for the rgb2yuv colorspace > conversions, it's probably only affective for image up/downscaling? Maybe it is because of the massive amount of data that needs to be shifted around. Not sure, but 4K is four times as much data as 1080p. ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-user] 4K RGB->YUV realtime conversion.
Hi, I've come across a problem I really can't figure out when trying to stream realtime a RGB 10-bit Decklink input, as YUV444 10-bit HEVC in 25fps. In a 1920x1080 resolution on the Decklink input, it all works very well, using hevc_nvenc codec on a Nvidia GPU. Auto_scaler kicks in converting the correctly identified 'gbrp10le' input format to 'yuv44416le' for hevc_nvenc. But doing the same in 4K resolution causes input buffer overruns, only capable of about 20 fps. When watching CPU usage, there's only real load on one of the 32 threads, and that load is maxing out at 99%. CPU frequency is close to 4GHz on the AMD CPU. If I then switch the Decklink input to YUV instead, 4K works fine, so the hevc encoding on the gpu or streaming protocol is not the bottleneck. This makes me think the problem lies with the auto_scaler RGB->YUV not keeping up with 4096x2160 pixels. This RGB->YUV conversion is done in libswscale I understand. I've tried to use -filter_threads and -threads to increase thread usage of the swscale, but it still seems to use only one thread. Any suggestions how I can do this 4K RGB 10-bit->YUV444 10-bit colorspace conversion in ffmpeg in realtime? I've tried to hwupload to the gpu to be able to use scale_npp, but auto_scaler kicks in before I have the chance to send the RGB data to the -vf filters. I've also tried to build with a patch for multi-thread swscale found here: https://patchwork.ffmpeg.org/project/ffmpeg/patch/c1125bd979e9ae41908dc4913cbfacbb67a31...@irsmsx103.ger.corp.intel.com/ But this patch doesn't seem to make a difference for the rgb2yuv colorspace conversions, it's probably only affective for image up/downscaling? Kind regards Anders ___ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".