3

I've been experimenting with recording screencasts using FFmpeg's X11grab module, which has worked more or less fine so far. I understand that a/v encoding is a complex process with many fine details, but I'm doing my best to learn.

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 record two audio streams separately with pacat and sox. Later, the whole thing is filtered, normalized, encoded, and combined into a Matroska container.

Right now, I'm having ffmpeg record a rawvideo stream to be fed to x264's yuv4 demuxer. I experimented with ffv1 and straight x264 recording before. 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've found that ffv1 gives me terrible frame dropping, and yuv4 too, but less so. 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.

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?

EDIT: This is the ffmpeg line I currently use.

ffmpeg -v warning -f x11grab -s 1920x1080 -r 30000/1001 -i :0.0\
-vcodec rawvideo -pix_fmt yuv420p -s 1280x720\
-threads 0\
recvideo.y4m
mkaito
  • 1,005
  • 1
  • 10
  • 19

1 Answers1

3

Have you tried http://en.wikipedia.org/wiki/Huffyuv ?

Do 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?

For 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. Measure how long the write takes (reading from urandom will take time). Linux has writeback, meaning it flushes dirty pages to disk every 5 seconds, not as soon as you write. Using fdatasync (or full fsync) will give you the real time until the data is on disk.

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?

EDIT: 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. You can then transcode offline to H.264 in YUV, dual-pass for maximum quality etc. I got about 24MB/sec, but it appears to be single threaded. My Core2 @ 2.3Ghz is fine with it.

Z.T.
  • 939
  • 8
  • 20
  • Yes, I tried huffyuv. I keep two of my four cores dedicated for ffmpeg during recording. Also, part of my question was about pinpointing the issues I have, which implies that I have no idea whether it's CPU or HDD related. I'm also not sure about finding the data rate being used to write to disk. – mkaito Apr 16 '12 at 14:40
  • 1
    You're converting RGB (native pixels) to YUV. Try recording in RGB. Getting CPU use should be as easy as running `top` (or `htop`, or `perf record -a sleep 60` from linux tools) while you're recording. Disk write rate in bytes per second is the size of the file you record in a minute divided by 60. A disk should be able to write at 100MB/sec (sequentially, if it's only used for this and performs no other work, including reads, that causes it to seek). – Z.T. Apr 16 '12 at 15:25
  • YUV4 doesn't like (A)RGB pixel format. x264 won't eat anything besides a raw y4m stream, and ffmpeg automatically selects yuv420p when telling it to use x264. Video file size is roughly 2.30Gb per minute. Which means it's writing around 40Mb/s. htop reports the cores assigned to ffmpeg to be around 30% load each. – mkaito Apr 16 '12 at 17:23