Just enter it manually as you're doing I think it's a signed int. On 3/2/18, Alex P <[email protected]> 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:[email protected]] 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 <[email protected]> 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:[email protected]] 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 >> [email protected] >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >> >> To unsubscribe, visit link above, or email >> [email protected] with subject "unsubscribe". >> >> _______________________________________________ >> ffmpeg-user mailing list >> [email protected] >> http://ffmpeg.org/mailman/listinfo/ffmpeg-user >> >> To unsubscribe, visit link above, or email >> [email protected] with subject "unsubscribe". >> > _______________________________________________ > ffmpeg-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email [email protected] > with subject "unsubscribe". > > _______________________________________________ > ffmpeg-user mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/ffmpeg-user > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user
To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
