4K 60Hz Directshow Video Capture
Windows 10 Intel i7-8700K GTX 1050Ti 16GB DDR4 SATA Samsung Evo I'm using a Yuan 4K60 capture card with the end goal of capturing the video in a lossless format. I need it to be lossless as the clips will be used to test hardware h264 encoders. Product page: http://www.yuan.com.tw/products/capture/4k/sc560n1_lv_hdmi2.htm Directshow is supported. Command: ffmpeg -f dshow -video_size 3840x2160 -framerate 59.9 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v libx265 -x265-params lossless=1 out1.avi I have also tried writing to null: ffmpeg -f dshow -video_size 3840x2160 -framerate 59.9 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v libx265 -x265-params lossless=1 -f null - I get the same error (see attatched) and I have to force quit by pressing Ctrl-C a bunch. Error also occurs if I write to a RAM disk. [dshow @ 000001dda20ca3a0] real-time buffer [MZ0380 PCI, Analog 01 Capture] [video input] too full or near too full (63% of size: 2100000000 [rtbufsize parameter])! frame dropped! Any help would be appreciated. 1080p capture right to rawvideo is perfect. I would like to use NVENC in lossless mode if anyone has experience with that.
On Mon, Feb 12, 2018 at 7:37 AM, Alex P <alex.p@avenview.com> wrote:
Windows 10
Intel i7-8700K
GTX 1050Ti
16GB DDR4
SATA Samsung Evo
I'm using a Yuan 4K60 capture card with the end goal of capturing the video in a lossless format. I need it to be lossless as the clips will be used to test hardware h264 encoders.
Product page: http://www.yuan.com.tw/products/capture/4k/sc560n1_lv_hdmi2.htm
Directshow is supported.
Command: ffmpeg -f dshow -video_size 3840x2160 -framerate 59.9 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v libx265 -x265-params lossless=1 out1.avi
I have also tried writing to null: ffmpeg -f dshow -video_size 3840x2160 -framerate 59.9 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v libx265 -x265-params lossless=1 -f null -
I get the same error (see attatched) and I have to force quit by pressing Ctrl-C a bunch. Error also occurs if I write to a RAM disk.
[dshow @ 000001dda20ca3a0] real-time buffer [MZ0380 PCI, Analog 01 Capture] [video input] too full or near too full (63% of size: 2100000000 [rtbufsize parameter])! frame dropped!
Any help would be appreciated. 1080p capture right to rawvideo is perfect. I would like to use NVENC in lossless mode if anyone has experience with that.
haven't used Windows / Directshow for a few years, but back in the day I would have attempted this using VirtualDub and HuffYUV. I believe that HuffYUV is available for ffmpeg, but can't say that I've ever tried it. -- *William Caulfield *| *ContentBridge Systems*
I've tried all manner of encoders but get the same buffer error. I've actually gotten a 64-bit fork of VirtualDub to work and capture everything but it occasionally drops frames and I like the CLI of ffmpeg. I guess I could use the VD CLI. Can anyone advise? I could use Linux but I'd rather not as I know this company's Linux drivers are less developed than their Windows drivers. -----Original Message----- From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of William Caulfield Sent: Monday, February 12, 2018 1:11 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] 4K 60Hz Directshow Video Capture On Mon, Feb 12, 2018 at 7:37 AM, Alex P <alex.p@avenview.com> wrote:
Windows 10
Intel i7-8700K
GTX 1050Ti
16GB DDR4
SATA Samsung Evo
I'm using a Yuan 4K60 capture card with the end goal of capturing the video in a lossless format. I need it to be lossless as the clips will be used to test hardware h264 encoders.
Product page: http://www.yuan.com.tw/products/capture/4k/sc560n1_lv_hdmi2.htm
Directshow is supported.
Command: ffmpeg -f dshow -video_size 3840x2160 -framerate 59.9 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v libx265 -x265-params lossless=1 out1.avi
I have also tried writing to null: ffmpeg -f dshow -video_size 3840x2160 -framerate 59.9 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v libx265 -x265-params lossless=1 -f null -
I get the same error (see attatched) and I have to force quit by pressing Ctrl-C a bunch. Error also occurs if I write to a RAM disk.
[dshow @ 000001dda20ca3a0] real-time buffer [MZ0380 PCI, Analog 01 Capture] [video input] too full or near too full (63% of size: 2100000000 [rtbufsize parameter])! frame dropped!
Any help would be appreciated. 1080p capture right to rawvideo is perfect. I would like to use NVENC in lossless mode if anyone has experience with that.
haven't used Windows / Directshow for a few years, but back in the day I would have attempted this using VirtualDub and HuffYUV. I believe that HuffYUV is available for ffmpeg, but can't say that I've ever tried it. -- *William Caulfield *| *ContentBridge Systems* _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
William Caulfield wrote:
haven't used Windows / Directshow for a few years, but back in the day I would have attempted this using VirtualDub and HuffYUV. I believe that HuffYUV is available for ffmpeg, but can't say that I've ever tried it.
Indeed, FFmpeg's flavour of HuffYUV is even better than the original one! There is a fork of VirtualDub by Peter Bubestinger-Steindl which allow to capture in Matroska/FFV1. Hope this helps! Reto
Hi Alex, I looked at your attached log. It appears to me that using libx265, your computer cannot encode fast enough. It appears your computer is encoding about 10.5 fps, but your input is about 60fps. So a lot of frames get buffered every second while they're waiting to be encoded. This leads to the full rtbuffer and then dropped frames. You could try increasing your rtbufsize, but using libx265 your computer will not be able to keep up and eventually the buffer will fill and frames will be dropped.
Any help would be appreciated. 1080p capture right to rawvideo is perfect. I would like to use NVENC in lossless mode if anyone has experience with that.
If you look at the fps that you can do at 1080p, it will be much higher and that's why you don't get buffer over-runs. I also have a GTX 1050 Ti that I use for encoding. It will do hevc lossless at about 150fps, input size 3840x2160@60hz (all in RAM): ffmpeg -hwaccel cuvid -c:v hevc_cuvid -i /dev/shm/foo.4k60.hevc.mkv -c:v hevc_cuvid -preset lossless /dev/shm/test.mkv Based on my limited test, your GPU should be able to keep up and not drop frames, YMMV. I'm not sure what impact you will have because your input is raw-video (positive or negative). You shouldn't include "-hwaccel cuvid" on your cli, because you won't be doing hw-decoding/transcoding. HTH, -J
Hi James, I get the same issue with this command: ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v h264_nvenc -preset lossless -f null - Is there a way to accelerate the decoding of rawvideo? ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo -f null - Gets me nearly 1x performance. -----Original Message----- From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of James Girotti Sent: Monday, February 12, 2018 3:31 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] 4K 60Hz Directshow Video Capture Hi Alex, I looked at your attached log. It appears to me that using libx265, your computer cannot encode fast enough. It appears your computer is encoding about 10.5 fps, but your input is about 60fps. So a lot of frames get buffered every second while they're waiting to be encoded. This leads to the full rtbuffer and then dropped frames. You could try increasing your rtbufsize, but using libx265 your computer will not be able to keep up and eventually the buffer will fill and frames will be dropped.
Any help would be appreciated. 1080p capture right to rawvideo is perfect. I would like to use NVENC in lossless mode if anyone has experience with that.
If you look at the fps that you can do at 1080p, it will be much higher and that's why you don't get buffer over-runs. I also have a GTX 1050 Ti that I use for encoding. It will do hevc lossless at about 150fps, input size 3840x2160@60hz (all in RAM): ffmpeg -hwaccel cuvid -c:v hevc_cuvid -i /dev/shm/foo.4k60.hevc.mkv -c:v hevc_cuvid -preset lossless /dev/shm/test.mkv Based on my limited test, your GPU should be able to keep up and not drop frames, YMMV. I'm not sure what impact you will have because your input is raw-video (positive or negative). You shouldn't include "-hwaccel cuvid" on your cli, because you won't be doing hw-decoding/transcoding. HTH, -J _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Hi James, ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v h264_nvenc -preset lossless -f null - Gives me the same error ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo -f null - Gets me nearly x1 performance when executing from a ram disk but ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo raw.nut Only gets me x0.5 and the buffer overflows. Is there a way of accelerating rawvideo decoding? Would using my colleagues 1080 make a difference? Thanks. -Alex P -----Original Message----- From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of James Girotti Sent: Monday, February 12, 2018 3:31 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] 4K 60Hz Directshow Video Capture Hi Alex, I looked at your attached log. It appears to me that using libx265, your computer cannot encode fast enough. It appears your computer is encoding about 10.5 fps, but your input is about 60fps. So a lot of frames get buffered every second while they're waiting to be encoded. This leads to the full rtbuffer and then dropped frames. You could try increasing your rtbufsize, but using libx265 your computer will not be able to keep up and eventually the buffer will fill and frames will be dropped.
Any help would be appreciated. 1080p capture right to rawvideo is perfect. I would like to use NVENC in lossless mode if anyone has experience with that.
If you look at the fps that you can do at 1080p, it will be much higher and that's why you don't get buffer over-runs. I also have a GTX 1050 Ti that I use for encoding. It will do hevc lossless at about 150fps, input size 3840x2160@60hz (all in RAM): ffmpeg -hwaccel cuvid -c:v hevc_cuvid -i /dev/shm/foo.4k60.hevc.mkv -c:v hevc_cuvid -preset lossless /dev/shm/test.mkv Based on my limited test, your GPU should be able to keep up and not drop frames, YMMV. I'm not sure what impact you will have because your input is raw-video (positive or negative). You shouldn't include "-hwaccel cuvid" on your cli, because you won't be doing hw-decoding/transcoding. HTH, -J _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v h264_nvenc -preset lossless -f null - Gives me the same error
That's surprising, I can get about 200fps using file-based/ramdisk "-c:v h264_nvenc -preset -lossless". Have you also tried "-c:v hevc_nvenc -preset lossless"? What's the encoding FPS that you're getting? You technically shouldn't be able get much more than 60fps as that's what your capture card is supplying. Can you monitor the "Video Engine Utilization" during encoding? In linux it's listed in the nvidia-settings GUI or "nvidia-smi dmon" on the CLI will show enc/dec%.
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo -f null - Gets me nearly x1 performance when executing from a ram disk but
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo raw.nut Only gets me x0.5 and the buffer overflows.
Is there a way of accelerating rawvideo decoding? Would using my colleagues 1080 make a difference? Thanks.
I think raw-video is already decoded. So no way/need to accelerate that. You might try a different pix_fmt from your capture card while using hw-encoding, but you'd have to test. I don't know the internals, i.e. when the pixel format is converted during hw-encoding. So it might make a difference. Changing pixel formats might be a concern if you are trying to achieve "100% lossless" capture. I've read that yuv444p should be sufficient colorspace for bgr24. There isn't a lot of info out there on encoding speed differences based on GPU models. It's a complex subject, but from what I have observed the ASIC is tied to the GPU clock (I have observed that GPU clock speed increases as ASIC load increases). If that's true, then a GTX 1080, with it's higher max clock, could have faster encoding, but I have no data to back that up only.
I think I've figured it out. When I use nv12 or yuv420p as the input and output pixel format, I get x1 performance. If I use bgr24/rgb24 as the input and yuv444p as the output, I get around x0.3. But even when I use bgr0 for the input and output, I get less than x1. Does anyone know what exactly bgr0 is? I can't find any information about it in my googling. In your testing James, what was the pixel format? -----Original Message----- From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of James Girotti Sent: Monday, February 12, 2018 7:03 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] 4K 60Hz Directshow Video Capture
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v h264_nvenc -preset lossless -f null - Gives me the same error
That's surprising, I can get about 200fps using file-based/ramdisk "-c:v h264_nvenc -preset -lossless". Have you also tried "-c:v hevc_nvenc -preset lossless"? What's the encoding FPS that you're getting? You technically shouldn't be able get much more than 60fps as that's what your capture card is supplying. Can you monitor the "Video Engine Utilization" during encoding? In linux it's listed in the nvidia-settings GUI or "nvidia-smi dmon" on the CLI will show enc/dec%.
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo -f null - Gets me nearly x1 performance when executing from a ram disk but
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo raw.nut Only gets me x0.5 and the buffer overflows.
Is there a way of accelerating rawvideo decoding? Would using my colleagues 1080 make a difference? Thanks.
I think raw-video is already decoded. So no way/need to accelerate that. You might try a different pix_fmt from your capture card while using hw-encoding, but you'd have to test. I don't know the internals, i.e. when the pixel format is converted during hw-encoding. So it might make a difference. Changing pixel formats might be a concern if you are trying to achieve "100% lossless" capture. I've read that yuv444p should be sufficient colorspace for bgr24. There isn't a lot of info out there on encoding speed differences based on GPU models. It's a complex subject, but from what I have observed the ASIC is tied to the GPU clock (I have observed that GPU clock speed increases as ASIC load increases). If that's true, then a GTX 1080, with it's higher max clock, could have faster encoding, but I have no data to back that up only. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On Tue, Feb 13, 2018 at 6:57 AM, Alex P <alex.p@avenview.com> wrote:
I think I've figured it out. When I use nv12 or yuv420p as the input and output pixel format, I get x1 performance. If I use bgr24/rgb24 as the input and yuv444p as the output, I get around x0.3.
Looks like switching pixel formats highly impacts performance. It would be better for your capture card to output, for example, yuv444p. I can't tell from the specs if it can do that though. Careful selecting nv12 as format for output, my quick test showed that the final output was yuv420p.
In your testing James, what was the pixel format?
I was testing yuv420p samples as that is what was available to me at the time. I have made a yuv444p using testsrc. My poor Thuban cannot decode this FFv1 at realtime and raw-video filesize is gigantic. So I made a lossless hevc yuv444p. Surprisingly (or maybe not) hevc_cuvid can't decode it! Again, my poor Thuban cannot decode real-time, but there's some hope: FFmpeg encoding speed was about 35-40 fps and hw-encoder utilization topped out at 40%. So there's still a lot of headroom in the hw-encoder. Rough theoretical calculation: I could get 100fps hw-encoding which is ~1.7X I got about the same speed for h264_nvenc lossless. I got similar results using a 3 second raw yuv444p video input file. If there are other pix_fmts you would like me to test, let me know. I'll do my best to try.
Thank you for the offer James, but I think I know how to proceed. Looking at the pixel formats for various implementations of x264 and x265, I'm not seeing any that support bgr24, which is the only uncompressed format offered by my capture card, out of yuyv422, yuv420p, nv12, bgr0 and bgr24 Does anyone know of a lossless encoder that inputs and outputs bgr24? -----Original Message----- From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of James Girotti Sent: Tuesday, February 13, 2018 1:33 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] 4K 60Hz Directshow Video Capture On Tue, Feb 13, 2018 at 6:57 AM, Alex P <alex.p@avenview.com> wrote:
I think I've figured it out. When I use nv12 or yuv420p as the input and output pixel format, I get x1 performance. If I use bgr24/rgb24 as the input and yuv444p as the output, I get around x0.3.
Looks like switching pixel formats highly impacts performance. It would be better for your capture card to output, for example, yuv444p. I can't tell from the specs if it can do that though. Careful selecting nv12 as format for output, my quick test showed that the final output was yuv420p.
In your testing James, what was the pixel format?
I was testing yuv420p samples as that is what was available to me at the time. I have made a yuv444p using testsrc. My poor Thuban cannot decode this FFv1 at realtime and raw-video filesize is gigantic. So I made a lossless hevc yuv444p. Surprisingly (or maybe not) hevc_cuvid can't decode it! Again, my poor Thuban cannot decode real-time, but there's some hope: FFmpeg encoding speed was about 35-40 fps and hw-encoder utilization topped out at 40%. So there's still a lot of headroom in the hw-encoder. Rough theoretical calculation: I could get 100fps hw-encoding which is ~1.7X I got about the same speed for h264_nvenc lossless. I got similar results using a 3 second raw yuv444p video input file. If there are other pix_fmts you would like me to test, let me know. I'll do my best to try. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
On Tue, Feb 13, 2018, at 12:28 PM, Alex P wrote:
Does anyone know of a lossless encoder that inputs and outputs bgr24?
$ ffmpeg -h encoder=libx264rgb [...] Supported pixel formats: bgr0 bgr24 rgb24
2018-02-13 22:28 GMT+01:00 Alex P <alex.p@avenview.com>:
Does anyone know of a lossless encoder that inputs and outputs bgr24?
(ljpeg, I don't claim it helps you though.) Please avoid top-posting here, Carl Eugen
Thank you for the testing James, it was really helpful and I think my issue might ultimately be a hard drive bandwidth limitation. With ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo -f null - I was able to get 1x speeds but running the following on an 10GB RAM disk only gets me around .3x ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo out.nut Full 4K60 raw video should be 12gbps. This is 1.5GB/s. Running CrystalDiskMark gets me the attached results. In sequential reads and writes, it seems like my disk should be fast enough. But the other tests indicate otherwise. Does anyone know what kind of hard drive test would best simulate what I'm doing? Could it be overhead from Windows writing the file? ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 210000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" $03d.BMP or %03d.jpg Gives me similar performance as video. I think my only hope is my capture card natively supporting yuv444p. Converting between bgr24 to yuv444 impacts performance too much and libx264rgb isn’t fast enough. Any advice is appreciated. -----Original Message----- From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of James Girotti Sent: Tuesday, February 13, 2018 1:33 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] 4K 60Hz Directshow Video Capture On Tue, Feb 13, 2018 at 6:57 AM, Alex P <alex.p@avenview.com> wrote:
I think I've figured it out. When I use nv12 or yuv420p as the input and output pixel format, I get x1 performance. If I use bgr24/rgb24 as the input and yuv444p as the output, I get around x0.3.
Looks like switching pixel formats highly impacts performance. It would be better for your capture card to output, for example, yuv444p. I can't tell from the specs if it can do that though. Careful selecting nv12 as format for output, my quick test showed that the final output was yuv420p.
In your testing James, what was the pixel format?
I was testing yuv420p samples as that is what was available to me at the time. I have made a yuv444p using testsrc. My poor Thuban cannot decode this FFv1 at realtime and raw-video filesize is gigantic. So I made a lossless hevc yuv444p. Surprisingly (or maybe not) hevc_cuvid can't decode it! Again, my poor Thuban cannot decode real-time, but there's some hope: FFmpeg encoding speed was about 35-40 fps and hw-encoder utilization topped out at 40%. So there's still a lot of headroom in the hw-encoder. Rough theoretical calculation: I could get 100fps hw-encoding which is ~1.7X I got about the same speed for h264_nvenc lossless. I got similar results using a 3 second raw yuv444p video input file. If there are other pix_fmts you would like me to test, let me know. I'll do my best to try. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
consider also libx264 "ultrafast" preset, GL! On Tue, Feb 13, 2018 at 7:57 AM, Alex P <alex.p@avenview.com> wrote:
I think I've figured it out. When I use nv12 or yuv420p as the input and output pixel format, I get x1 performance. If I use bgr24/rgb24 as the input and yuv444p as the output, I get around x0.3.
But even when I use bgr0 for the input and output, I get less than x1. Does anyone know what exactly bgr0 is? I can't find any information about it in my googling.
In your testing James, what was the pixel format?
-----Original Message----- From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of James Girotti Sent: Monday, February 12, 2018 7:03 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] 4K 60Hz Directshow Video Capture
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v h264_nvenc -preset lossless -f null - Gives me the same error
That's surprising, I can get about 200fps using file-based/ramdisk "-c:v h264_nvenc -preset -lossless". Have you also tried "-c:v hevc_nvenc -preset lossless"? What's the encoding FPS that you're getting? You technically shouldn't be able get much more than 60fps as that's what your capture card is supplying. Can you monitor the "Video Engine Utilization" during encoding? In linux it's listed in the nvidia-settings GUI or "nvidia-smi dmon" on the CLI will show enc/dec%.
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo -f null - Gets me nearly x1 performance when executing from a ram disk but
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo raw.nut Only gets me x0.5 and the buffer overflows.
Is there a way of accelerating rawvideo decoding? Would using my colleagues 1080 make a difference? Thanks.
I think raw-video is already decoded. So no way/need to accelerate that. You might try a different pix_fmt from your capture card while using hw-encoding, but you'd have to test. I don't know the internals, i.e. when the pixel format is converted during hw-encoding. So it might make a difference.
Changing pixel formats might be a concern if you are trying to achieve "100% lossless" capture. I've read that yuv444p should be sufficient colorspace for bgr24.
There isn't a lot of info out there on encoding speed differences based on GPU models. It's a complex subject, but from what I have observed the ASIC is tied to the GPU clock (I have observed that GPU clock speed increases as ASIC load increases). If that's true, then a GTX 1080, with it's higher max clock, could have faster encoding, but I have no data to back that up only. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Thank you for that suggestion Roger, I can't believe I forgot about the preset options. Executing the following on a RAM disk gets me about .9x performance, letting me capture about 5 seconds worth of video before the buffers overflow and I lose frames. Not perfect but enough for what I need. I think this is the best I'm going to get unless the mfg makes a better driver and adds yuv444p support or I get a better CPU. I really appreciate for everyone's input. ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 210000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v libx264rgb -preset ultrafast -crf 0 -pix_fmt bgr24 -t 00:00:10 -r 60000/1001 out.avi One more question, what is the command to use the maximum buffer size? -rtbufsize INT_MAX doesn't work. Thanks. -----Original Message----- From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of Roger Pack Sent: Tuesday, February 27, 2018 8:03 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] 4K 60Hz Directshow Video Capture consider also libx264 "ultrafast" preset, GL! On Tue, Feb 13, 2018 at 7:57 AM, Alex P <alex.p@avenview.com> wrote:
I think I've figured it out. When I use nv12 or yuv420p as the input and output pixel format, I get x1 performance. If I use bgr24/rgb24 as the input and yuv444p as the output, I get around x0.3.
But even when I use bgr0 for the input and output, I get less than x1. Does anyone know what exactly bgr0 is? I can't find any information about it in my googling.
In your testing James, what was the pixel format?
-----Original Message----- From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of James Girotti Sent: Monday, February 12, 2018 7:03 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] 4K 60Hz Directshow Video Capture
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v h264_nvenc -preset lossless -f null - Gives me the same error
That's surprising, I can get about 200fps using file-based/ramdisk "-c:v h264_nvenc -preset -lossless". Have you also tried "-c:v hevc_nvenc -preset lossless"? What's the encoding FPS that you're getting? You technically shouldn't be able get much more than 60fps as that's what your capture card is supplying. Can you monitor the "Video Engine Utilization" during encoding? In linux it's listed in the nvidia-settings GUI or "nvidia-smi dmon" on the CLI will show enc/dec%.
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo -f null - Gets me nearly x1 performance when executing from a ram disk but
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo raw.nut Only gets me x0.5 and the buffer overflows.
Is there a way of accelerating rawvideo decoding? Would using my colleagues 1080 make a difference? Thanks.
I think raw-video is already decoded. So no way/need to accelerate that. You might try a different pix_fmt from your capture card while using hw-encoding, but you'd have to test. I don't know the internals, i.e. when the pixel format is converted during hw-encoding. So it might make a difference.
Changing pixel formats might be a concern if you are trying to achieve "100% lossless" capture. I've read that yuv444p should be sufficient colorspace for bgr24.
There isn't a lot of info out there on encoding speed differences based on GPU models. It's a complex subject, but from what I have observed the ASIC is tied to the GPU clock (I have observed that GPU clock speed increases as ASIC load increases). If that's true, then a GTX 1080, with it's higher max clock, could have faster encoding, but I have no data to back that up only. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Just enter it manually as you're doing I think it's a signed int. On 3/2/18, Alex P <alex.p@avenview.com> wrote:
Thank you for that suggestion Roger, I can't believe I forgot about the preset options.
Executing the following on a RAM disk gets me about .9x performance, letting me capture about 5 seconds worth of video before the buffers overflow and I lose frames. Not perfect but enough for what I need. I think this is the best I'm going to get unless the mfg makes a better driver and adds yuv444p support or I get a better CPU. I really appreciate for everyone's input.
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 210000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v libx264rgb -preset ultrafast -crf 0 -pix_fmt bgr24 -t 00:00:10 -r 60000/1001 out.avi
One more question, what is the command to use the maximum buffer size? -rtbufsize INT_MAX doesn't work. Thanks.
-----Original Message----- From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of Roger Pack Sent: Tuesday, February 27, 2018 8:03 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] 4K 60Hz Directshow Video Capture
consider also libx264 "ultrafast" preset, GL!
On Tue, Feb 13, 2018 at 7:57 AM, Alex P <alex.p@avenview.com> wrote:
I think I've figured it out. When I use nv12 or yuv420p as the input and output pixel format, I get x1 performance. If I use bgr24/rgb24 as the input and yuv444p as the output, I get around x0.3.
But even when I use bgr0 for the input and output, I get less than x1. Does anyone know what exactly bgr0 is? I can't find any information about it in my googling.
In your testing James, what was the pixel format?
-----Original Message----- From: ffmpeg-user [mailto:ffmpeg-user-bounces@ffmpeg.org] On Behalf Of James Girotti Sent: Monday, February 12, 2018 7:03 PM To: FFmpeg user questions Subject: Re: [FFmpeg-user] 4K 60Hz Directshow Video Capture
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v h264_nvenc -preset lossless -f null - Gives me the same error
That's surprising, I can get about 200fps using file-based/ramdisk "-c:v h264_nvenc -preset -lossless". Have you also tried "-c:v hevc_nvenc -preset lossless"? What's the encoding FPS that you're getting? You technically shouldn't be able get much more than 60fps as that's what your capture card is supplying. Can you monitor the "Video Engine Utilization" during encoding? In linux it's listed in the nvidia-settings GUI or "nvidia-smi dmon" on the CLI will show enc/dec%.
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo -f null - Gets me nearly x1 performance when executing from a ram disk but
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo raw.nut Only gets me x0.5 and the buffer overflows.
Is there a way of accelerating rawvideo decoding? Would using my colleagues 1080 make a difference? Thanks.
I think raw-video is already decoded. So no way/need to accelerate that. You might try a different pix_fmt from your capture card while using hw-encoding, but you'd have to test. I don't know the internals, i.e. when the pixel format is converted during hw-encoding. So it might make a difference.
Changing pixel formats might be a concern if you are trying to achieve "100% lossless" capture. I've read that yuv444p should be sufficient colorspace for bgr24.
There isn't a lot of info out there on encoding speed differences based on GPU models. It's a complex subject, but from what I have observed the ASIC is tied to the GPU clock (I have observed that GPU clock speed increases as ASIC load increases). If that's true, then a GTX 1080, with it's higher max clock, could have faster encoding, but I have no data to back that up only. _______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
_______________________________________________ ffmpeg-user mailing list ffmpeg-user@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".
Alex P wrote:
Hi James,
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v h264_nvenc -preset lossless -f null - Gives me the same error
Maybe it doesn't do rgb24 lossless - you should paste full output of ffmpeg and not top post on this list.
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo -f null - Gets me nearly x1 performance when executing from a ram disk but
ffmpeg -f dshow -video_size 3840x2160 -framerate 60000/1001 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v rawvideo raw.nut Only gets me x0.5 and the buffer overflows.
The device that raw.nut is written to would need to take 1.5 gigabytes/sec to get full speed.
2018-02-12 16:37 GMT+01:00 Alex P <alex.p@avenview.com>:
Command: ffmpeg -f dshow -video_size 3840x2160 -framerate 59.9 -rtbufsize 2100000000 -pixel_format bgr24 -i video="MZ0380 PCI, Analog 01 Capture" -c:v libx265 -x265-params lossless=1 out1.avi
Unrelated: -framerate 59.9 is most likely wrong, should be 60000/1001
frame= 74 fps= 10 q=-0.0 Lsize=N/A time=00:00:01.43 bitrate=N/A speed=0.202x
The encoder is (far!) too slow, you could try with -vcodec ffv1, but you most likely will have to either use a significantly more expensive CPU, or a lower resolution or a lower frame rate. If you have sufficiently fast disks, you can try to save rawvideo (and re-encode later). [...]
Any help would be appreciated. 1080p capture right to rawvideo is perfect. I would like to use NVENC in lossless mode if anyone has experience with that.
Is there really a hardware encoder that supports lossless encoding? If yes, why did you use software encoding at all above? Carl Eugen
Carl Eugen Hoyos wrote:
Is there really a hardware encoder that supports lossless encoding?
https://developer.nvidia.com/nvidia-video-codec-sdk#NVENCFeatures Doesn't mention rgb though.
2018-02-13 1:45 GMT+01:00 Andy Furniss <adf.lists@gmail.com>:
Carl Eugen Hoyos wrote:
Is there really a hardware encoder that supports lossless encoding?
https://developer.nvidia.com/nvidia-video-codec-sdk#NVENCFeatures
Thank you! Carl Eugen
participants (8)
-
Alex P -
Andy Furniss -
Carl Eugen Hoyos -
James Girotti -
Lou Logan -
Reto Kromer -
Roger Pack -
William Caulfield