<p><strong>Ad 1:</strong></p>

<p>Presets have <em>(almost) no impact to the quality</em> — their purpose is for adjusting the trade-off of encoding time for the output size (the longer encoding time, the smaller the output stream).</p>

<p>Different presets enable / disable separate algorithms for compression. For example, in my installation, the <code>-preset ultrafast</code> is equivalent to options</p>

<pre><code>--no-8x8dct --aq-mode 0 --b-adapt 0
--bframes 0 --no-cabac --no-deblock
--no-mbtree --me dia --no-mixed-refs
--partitions none --rc-lookahead 0 --ref 1
--scenecut 0 --subme 0 --trellis 0
--no-weightb --weightp 0
</code></pre>

<p>As you can see, almost no optimization, i. e. the output will be very large.</p>

<hr>

<p><strong>Ad 2:</strong></p>

<p>H.264, aka MPEG-4 Part 10, aka Advanced Video Coding (AVC) is good enough, and its particular implementation — x264 library — is a very good one.</p>

<p>The pervasive rule is again the same: </p>

<blockquote>
  <p>Recent video compression standards are able to reach a little better compression than their predecessors, but for longer encoding time (and sometimes for lesser compatibility with media players, too).</p>
</blockquote>

<p>So if you don't need cutting-edge compression, every contemporary compression standard is good enough.</p>

CC BY-SA 4.0
2019-06-08T16:59:12.750Z
2020-03-27T15:05:35.610Z
2020-03-27T15:05:35.610Z
MarianD
<p>I'm learning how to use <code>ffmpeg</code> to stabilize some footage I shot at a conference (my setup had a nasty wobble and I didn't realise how bad it was until I started editing). </p>

<p>After trial and error I finally had great results with <code>ffmpeg</code> with the  <code>vidstab</code> option and I'm about to process some longer clips (over an hour each) and just want to check I'm using the optimal settings (for close to visually lossless quality and speed balance)... </p>

<p>Below are the commands I'm using:</p>

<pre><code>ffmpeg -i filename.MP4 -vf vidstabdetect=stepsize=32:shakiness=7:accuracy=10:result=transform_vectors.trf -f null -
</code></pre>

<p>and then:</p>

<pre><code>ffmpeg -i filename.MP4 -vf vidstabtransform=input=transform_vectors.trf:zoom=0:smoothing=10,unsharp=5:5:0.8:3:3:0.4 -c:v libx264 -preset slow -crf 18 -c:a copy Output.MP4
</code></pre>

<p><strong>Questions:</strong></p>

<ol>
<li>Does <code>-preset slow</code> vs <code>-preset medium</code> make much of a difference in quality at <code>-crf18</code>?</li>
<li>What is the fastest codec to output / encode to in this situation? At the moment I'm using h.264 (file sizes are good).</li>
</ol>

<p><strong>Note:</strong> ffmpeg with vidstab is much better than the other options I tried like Deshake, Pr/Ae Warp stabilizer, Blender, ...</p>

CC BY-SA 4.0
2019-05-27T12:44:12.397Z
I would expect that you can reduce settings for `shakiness` and `qrf` but want to increase `smoothing`. However, without sample footage this is difficult to say. Here is [what I'm using](https://vimeo.com/338522127).
Christian Lindig
CC BY-SA 4.0
2019-06-05T06:47:57.807Z
Just a follow up comment that I ended up leaving it on -preset medium and to stabilize a 1 hour clip on my system took less than an hour which was great, approx. 45mins
Dan
<video><ffmpeg>
Long video clip stabilization with ffmpeg and vidstab
Dan
# Long video clip stabilization with ffmpeg and vidstab

(Asked by: username_0 on 2019-05-27)

I'm learning how to use ffmpeg to stabilize some footage I shot at a conference (my setup had a nasty wobble and I didn't realise how bad it was until I started editing). 
After trial and error I finally had great results with ffmpeg with the  vidstab option and I'm about to process some longer clips (over an hour each) and just want to check I'm using the optimal settings (for close to visually lossless quality and speed balance)... 
Below are the commands I'm using:
ffmpeg -i filename.MP4 -vf vidstabdetect=stepsize=32:shakiness=7:accuracy=10:result=transform_vectors.trf -f null -

and then:
ffmpeg -i filename.MP4 -vf vidstabtransform=input=transform_vectors.trf:zoom=0:smoothing=10,unsharp=5:5:0.8:3:3:0.4 -c:v libx264 -preset slow -crf 18 -c:a copy Output.MP4

Questions:

Does -preset slow vs -preset medium make much of a difference in quality at -crf18?
What is the fastest codec to output / encode to in this situation? At the moment I'm using h.264 (file sizes are good).

Note: ffmpeg with vidstab is much better than the other options I tried like Deshake, Pr/Ae Warp stabilizer, Blender, ...

**Tags:** video, ffmpeg

> **Comments:**
> **username_1**: I would expect that you can reduce settings for `shakiness` and `qrf` but want to increase `smoothing`. However, without sample footage this is difficult to say. Here is [what I'm using](https://vimeo.com/338522127).  
> **username_0**: Just a follow up comment that I ended up leaving it on -preset medium and to stabilize a 1 hour clip on my system took less than an hour which was great, approx. 45mins  

---

## 1 answers

### Answer by username_2 on 2019-06-08. Score: 4 | Accepted answer

Ad 1:
Presets have (almost) no impact to the quality — their purpose is for adjusting the trade-off of encoding time for the output size (the longer encoding time, the smaller the output stream).
Different presets enable / disable separate algorithms for compression. For example, in my installation, the -preset ultrafast is equivalent to options
--no-8x8dct --aq-mode 0 --b-adapt 0
--bframes 0 --no-cabac --no-deblock
--no-mbtree --me dia --no-mixed-refs
--partitions none --rc-lookahead 0 --ref 1
--scenecut 0 --subme 0 --trellis 0
--no-weightb --weightp 0

As you can see, almost no optimization, i. e. the output will be very large.

Ad 2:
H.264, aka MPEG-4 Part 10, aka Advanced Video Coding (AVC) is good enough, and its particular implementation — x264 library — is a very good one.
The pervasive rule is again the same: 

Recent video compression standards are able to reach a little better compression than their predecessors, but for longer encoding time (and sometimes for lesser compatibility with media players, too).

So if you don't need cutting-edge compression, every contemporary compression standard is good enough.


---

