I'm capturing uncompressed 4K video from my Sony A7R II via a video capture device, and am using ffmpeg to save the video.

My problem is I don't know what codec to use. The two options I tried are:

  • Uncompressed: this takes up too much space, something like 1Gb every few seconds.
  • h264: this very quickly starts skipping frames. I've tried libx264, nvenc and qvx and they all essentially fill up the buffer and then start skipping frames after less than a minute of shooting.

I'm doing all of this on a laptop, so I have little scope for adding hardware encoding, especially considering that Intel's and Nvidia's solutions - at least on my machine - are clearly insufficient for 4K.

My requirements are that the codec allows:

  • About 4-5 hours of captured footage reliably fit on a 500Gb SSD
  • Encoding can happen in realtime without frames being dropped
  • The codec is postprocessing-friendly

Just in case it's useful, my laptop has an i7-4710MQ and 32Gb RAM.

Update: some clarification: I record at 30FPS, my capture device is INOGENI, sampling is 4:2:0. And no, I don't want to lose more quality than I have to. If I have to spend 100Gb/hour for recording, I'm OK with that.

  • What ffmpeg command(s) have you tried? Are you capturing audio too? Do you know what chroma sampling the camera outputs? I assume you run a HDMI from the camera to your laptop.
    – Gyan
    Commented Mar 26, 2016 at 7:27
  • In addition to the chroma sub sampling (4:2:0 or 4:2:2 or 4:4:4) please precise the frame per second number.
    – RawBean
    Commented Mar 26, 2016 at 9:00
  • Please also add your priority between loosing quality or decreasing recording capacity
    – RawBean
    Commented Mar 26, 2016 at 9:01
  • @RawBean added clarifications Commented Mar 26, 2016 at 9:41
  • 1
    A few things: I assume direct recording on SD cards is not accptable - the camera saves XAVC-S as a 100 mbps stream on SD cards i.e. 5 hours in ~225GB. More pertinently, you've applied the slow preset - ffmpeg needs to be able to consume packets fast enough. Use libx264 with veryfast or ultrafast preset, and profile main or baseline.
    – Gyan
    Commented Mar 26, 2016 at 10:00

1 Answer 1


As mentioned by @Mulvya, I think the issue is the "slow" preset.

One option is encoding a compressed stream that is also lossless. For example, the x264 encoder can do this using "-preset ultrafast -qp 0". This will probably result in failing your 3rd requirement (compatibility), but since it's lossless, you can transcode later onto cheap spinning disks. You can also look into using the huffyuv lossless encoder, which might be better supported. There are some gotchas with this method, so you definitely want to test your workflow from beginning to end. In particular, see this question: Using h264 in loseless mode brings small unexpected results

If you do go this route, I would also experiment with dropping subsampling and encode at 4:4:4. It may not increase your file size by that much and will help you if you plan on doing any post-production work.

Another option, depending on your budget, is purchasing an encoder. I love FFmpeg, but it's meant to work everywhere, not to take full advantage of your hardware. Mainconcept isn't too expensive and will better be able to use that i7 processor you already shelled out for. (See https://software.intel.com/en-us/articles/using-the-intel-media-sdk-within-mainconcept-h264avc-encoder-for-intel-quick-sync-video for example.) They also offer an HEVC encoder which would further shrink your file size. I can't vouch for the quality, however, as my experience is with Ateme. But I believe you can at least evaluate it out for free.

  • x264 does produce lossless output. I added an answer to the question you linked to.
    – Gyan
    Commented May 9, 2016 at 18:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.