<p>As mentioned by @Mulvya, I think the issue is the "slow" preset. </p>

<p>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:
<a href="https://video.stackexchange.com/questions/16674/using-h264-in-loseless-mode-brings-small-unexpected-results?rq=1">Using h264 in loseless mode brings small unexpected results</a></p>

<p>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.</p>

<p>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 <a href="https://software.intel.com/en-us/articles/using-the-intel-media-sdk-within-mainconcept-h264avc-encoder-for-intel-quick-sync-video" rel="nofollow noreferrer">https://software.intel.com/en-us/articles/using-the-intel-media-sdk-within-mainconcept-h264avc-encoder-for-intel-quick-sync-video</a> 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.</p>

CC BY-SA 3.0
2016-05-09T18:52:45.363Z
x264 does produce lossless output. I added an answer to the question you linked to.
Gyan
CC BY-SA 3.0
2016-05-09T18:17:47.873Z
2016-05-09T18:17:47.873Z
2017-04-13T12:46:08.110Z
Michael Steinberg
<p>I'm capturing uncompressed 4K video from my Sony A7R II via a video capture device, and am using ffmpeg to save the video.</p>

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

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

<p>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.</p>

<p>My requirements are that the codec allows:</p>

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

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

<p><strong>Update</strong>: 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.</p>

CC BY-SA 3.0
2016-03-26T07:27:21.020Z
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
CC BY-SA 3.0
2016-03-26T09:00:38.793Z
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
CC BY-SA 3.0
2016-03-26T09:01:35.863Z
Please also add your priority between loosing quality or decreasing recording capacity
RawBean
CC BY-SA 3.0
2016-03-26T09:41:00.370Z
@RawBean added clarifications
Dmitri Nesteruk
CC BY-SA 3.0
2016-03-26T09:41:25.513Z
@Mulvya I've tried things like `ffmpeg -f dshow -rtbufsize 2000M -video_size 3840x2160 -i video="2318-INOGENI 4K2USB3":audio="Digital Audio Interface (2318-INOGENI 4K2USB3)" -c:v nvenc -preset slow -loglevel info r:\4k.mp4`
Dmitri Nesteruk
CC BY-SA 3.0
2016-03-26T10:00:16.640Z
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
CC BY-SA 3.0
2016-03-26T10:11:27.323Z
@Mulvya ha! direct recording on SD is impossible because of the terrible 30-minute limit. that just kills the whole thing outright.
Dmitri Nesteruk
CC BY-SA 3.0
2016-05-30T20:38:54.180Z
@Mulvya `veryfast` appears to work, anything slower does not
Dmitri Nesteruk
<ffmpeg><encoding><video-recording><video-capture><4k>
How should I encode my 4K video stream?
Dmitri Nesteruk
# How should I encode my 4K video stream?

(Asked by: username_0 on 2016-03-26)

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.

**Tags:** ffmpeg, encoding, video-recording, video-capture, 4k

> **Comments:**
> **username_1**: 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.  
> **username_2**: 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.  
> **username_2**: Please also add your priority between loosing quality or decreasing recording capacity  
> **username_0**: @username_2 added clarifications  
> **username_0**: @Mulvya I've tried things like `ffmpeg -f dshow -rtbufsize 2000M -video_size 3840x2160 -i video="2318-INOGENI 4K2USB3":audio="Digital Audio Interface (2318-INOGENI 4K2USB3)" -c:v nvenc -preset slow -loglevel info r:\4k.mp4`  
> **username_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`.  
> **username_0**: @Mulvya ha! direct recording on SD is impossible because of the terrible 30-minute limit. that just kills the whole thing outright.  
> **username_0**: @Mulvya `veryfast` appears to work, anything slower does not  

---

## 1 answers

### Answer by username_3 on 2016-05-09. Score: 3

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](https://video.stackexchange.com/questions/16674/using-h264-in-loseless-mode-brings-small-unexpected-results?rq=1)

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.

> **Comments:**
> **username_1**: x264 does produce lossless output. I added an answer to the question you linked to.  

---

