I got about 24MB/sec, but it appears to be single threaded.
Does recordit store my screencasts Offline#
You can then transcode offline to H.264 in YUV, dual-pass for maximum quality etc. Why can't you see the cpu usage of ffmpeg? How about recording a minute of a terminal window showing top? If not, how about perf record -a sleep 60 in a terminal, then switching to what you do, recording a minute followed by perf report?ĮDIT: I used avconv -v warning -f x11grab -s 1680x1050 -r 30000/1001 -i :0.0 -vcodec ffvhuff -s 1280x720 -threads 0 capture.mkv and it worked great to record in RGB. Global Traffic Rank: 46,234 Estimated Visitors: 1,156,830 visitors per.
Does recordit store my screencasts full#
Using fdatasync (or full fsync) will give you the real time until the data is on disk. Recordit: Record screencasts fast & free with GIF Support Screenshot: Domain Summary. Linux has writeback, meaning it flushes dirty pages to disk every 5 seconds, not as soon as you write. Measure how long the write takes (reading from urandom will take time). vcodec rawvideo -pix_fmt yuv420p -s 1280x720\ĭo you know for sure whether your problem is CPU or disk bandwidth? What is the data rate you're trying to write to disk? How much CPU does ffmpeg need for your codec at your bitrate and settings? I assume you're no recording the computer being idle - how much resources does it have left for the recording?įor testing disk write perf, just allocate 100MB, read 100MB from /dev/urandom into it, and write the buffer to file on that disk while the disk is idle. The question is, which combination of video codecs should I look at? Record straight in x264 and recompress to "better" x264 later? Raw video, then compress? How would I go about pinpointing issues such as the frame drops I've been experiencing?ĮDIT: This is the ffmpeg line I currently use. I suspect this is due to hard drive speed, even if I'm sitting in a SATA3 Caviar Black that's being used exclusively to hold the recorded data. I've found that ffv1 gives me terrible frame dropping, and yuv4 too, but less so. My system can't handle real time encoding with x264 on the settings I want for the final stream, so I have to recompress separately once the recording is done. I experimented with ffv1 and straight x264 recording before. Right now, I'm having ffmpeg record a rawvideo stream to be fed to x264's yuv4 demuxer. Later, the whole thing is filtered, normalized, encoded, and combined into a Matroska container. I record two audio streams separately with pacat and sox. I'd like to do "lightweight" recording of a video stream, that puts as little strain as possible on the system while the stream is being recorded.
I understand that a/v encoding is a complex process with many fine details, but I'm doing my best to learn. I've been experimenting with recording screencasts using FFmpeg's X11grab module, which has worked more or less fine so far.
0 kommentar(er)
