4K RGB->YUV realtime conversion.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

4K RGB->YUV realtime conversion.

Anders Degerberg
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/C1125BD979E9AE41908DC4913CBFACBB67A31216@.../
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 4K RGB->YUV realtime conversion.

Peter White
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/C1125BD979E9AE41908DC4913CBFACBB67A31216@.../
> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 4K RGB->YUV realtime conversion.

Anders Degerberg
Hi Peter,

On Mon, 8 Mar 2021 at 19:18, Peter White <[hidden email]> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 4K RGB->YUV realtime conversion.

Peter White
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 <[hidden email]> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 4K RGB->YUV realtime conversion.

Brainiarc7
In reply to this post by Anders Degerberg
On Mon, 8 Mar 2021 at 17:49, Anders Degerberg <[hidden email]> 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/C1125BD979E9AE41908DC4913CBFACBB67A31216@.../
> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 4K RGB->YUV realtime conversion.

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 -

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
  libavformat    58. 71.100 / 58. 71.100
  libavdevice    58. 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
  libpostproc    55.  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.000000, 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/1000000 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, 30000 kb/s, 25 fps, 25 tbn
    Metadata:
      encoder         : Lavc58.129.100 hevc_nvenc
    Side data:
      cpb: bitrate max/min/avg: 0/0/30000000 buffer size: 60000000
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 <[hidden email]>:

>
> On Mon, 8 Mar 2021 at 17:49, Anders Degerberg <[hidden email]> 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/C1125BD979E9AE41908DC4913CBFACBB67A31216@.../
> > 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
> [hidden email]
> https://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> [hidden email] with subject "unsubscribe".
_______________________________________________
ffmpeg-user mailing list
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 4K RGB->YUV realtime conversion.

Carl Eugen Hoyos-2
Am Mo., 8. März 2021 um 21:46 Uhr schrieb Anders Degerberg
<[hidden email]>:
>
> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 4K RGB->YUV realtime conversion.

Anders Degerberg
On Mon, Mar 8, 2021 at 10:44 PM Carl Eugen Hoyos <[hidden email]> 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.000000, 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/1000000 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.000000, 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/1000000 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 4K RGB->YUV realtime conversion.

Carl Eugen Hoyos-2
Am Mo., 8. März 2021 um 23:32 Uhr schrieb Anders Degerberg
<[hidden email]>:

>
> On Mon, Mar 8, 2021 at 10:44 PM Carl Eugen Hoyos <[hidden email]> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 4K RGB->YUV realtime conversion.

Peter White
In reply to this post by Anders Degerberg
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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 4K RGB->YUV realtime conversion.

Anders Degerberg
On Tue, Mar 9, 2021 at 4:52 AM Peter White <[hidden email]> 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/1000000 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".
Reply | Threaded
Open this post in threaded view
|

Re: 4K RGB->YUV realtime conversion.

Peter White
On Tue, Mar 09, 2021 at 07:38:09AM +0100, Anders Degerberg wrote:
> On Tue, Mar 9, 2021 at 4:52 AM Peter White <[hidden email]> 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
[hidden email]
https://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email
[hidden email] with subject "unsubscribe".