Body: <p>I have been experimenting with some ffmpeg options and I could not figure out, why the resulting files had been in a format I did not want. After further combing through the man pages, I realized that i used <code>cropdetect=24:16:0</code> in my video filters. This was a result of googling and copy-pasting. After reading the man page, I changed the values to <code>cropdetect=24:2:0</code>, which got me to the results I expected (video of 720x540, SAR 1/1, DAR 4/3).</p>
  
  <p>"Sadly", the man pages states:</p>
  
  <blockquote>
    <p>round:
    The value which the width/height should be divisible by. It defaults to 16. The offset is automatically adjusted to center the video. Use 2 to get only even dimensions (needed for 4:2:2 video). 16 is best when encoding to most video codecs.</p>
  </blockquote>
  
  <p>I cannot find information, why 16 should/could be "best" for "most video codecs". Can you give me a hint? Do I do anything severely wrong, if I use '2' instead of '16'?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-30T10:11:06.990Z
Comments.Text: I found http://support.brightcove.com/en/video-cloud/docs/optimal-video-dimensions which states again, that everything should at best be a multiple of 16, or, if needed of 8 or 4. Again no explanation, no reasoning, just the statement.
Comments.UserDisplayName: jesterchen
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-03-30T12:15:53.223Z
Comments.Text: It seems like this might be due to video compression itself: http://forum.doom9.org/archive/index.php/t-143215.html holds a comment by LoRd_MuldeR, who states that the compression (still generalized) works on blocks ofh the size 16x16 and that smaller parts of the pictures will be padded. But he also states: "However with x264 the cost for none-mod16 is pretty low. Wouldn't worry too much!" This is enough of an explanation for me, so perhaps anyone else might stumble over this. Have fun.
Comments.UserDisplayName: jesterchen
Tags: <ffmpeg>
Title: Why does parameter round in ffmpeg's cropdetect default to 16?
UserDisplayName: jesterchen
ThreadText: # Why does parameter round in ffmpeg's cropdetect default to 16?
  
  (Asked by: username_0 on 2015-03-24)
  
  I have been experimenting with some ffmpeg options and I could not figure out, why the resulting files had been in a format I did not want. After further combing through the man pages, I realized that i used `cropdetect=24:16:0` in my video filters. This was a result of googling and copy-pasting. After reading the man page, I changed the values to `cropdetect=24:2:0`, which got me to the results I expected (video of 720x540, SAR 1/1, DAR 4/3).
  
  "Sadly", the man pages states:
  
  > round:
  > The value which the width/height should be divisible by. It defaults to 16. The offset is automatically adjusted to center the video. Use 2 to get only even dimensions (needed for 4:2:2 video). 16 is best when encoding to most video codecs.
  
  I cannot find information, why 16 should/could be "best" for "most video codecs". Can you give me a hint? Do I do anything severely wrong, if I use '2' instead of '16'?
  
  **Tags:** ffmpeg
  
  > **Comments:**
  > **username_0**: I found http://support.brightcove.com/en/video-cloud/docs/optimal-video-dimensions which states again, that everything should at best be a multiple of 16, or, if needed of 8 or 4. Again no explanation, no reasoning, just the statement.  
  > **username_0**: It seems like this might be due to video compression itself: http://forum.doom9.org/archive/index.php/t-143215.html holds a comment by LoRd_MuldeR, who states that the compression (still generalized) works on blocks ofh the size 16x16 and that smaller parts of the pictures will be padded. But he also states: "However with x264 the cost for none-mod16 is pretty low. Wouldn't worry too much!" This is enough of an explanation for me, so perhaps anyone else might stumble over this. Have fun.  
  
  ---
  
  ## 0 answers
  
  