Body: <p>I want to make a slideshow from images. The first image has 6932x4683 pixels, so I got an error <code>height not divisible by 2</code> and I found <a href="https://stackoverflow.com/questions/20847674/ffmpeg-libx264-height-not-divisible-by-2">this thread</a>. I understand that <code>libx264</code> is implicit in the output as <code>.mp4</code>, and that <code>libx264</code> needs an input image whose dimensions are divisible by 2. So I used the padding filter recommended there:</p>
  
  <pre><code>ffmpeg -f concat -safe 0 -i slideshow.txt -vf "pad=ceil(iw/2)*2:ceil(ih/2)*2" slideshow.mp4
  </code></pre>
  
  <p>The file <code>slideshow.txt</code> is:</p>
  
  <pre>
  file '03.jpeg'
  duration 2.5
  file '01.jpeg'
  duration 2.5
  file '02.jpeg'
  duration 2.5
  file '02.jpeg'
  </pre>
  
  <p>The command took 10 minutes to process these 3 images. When playing the result, it skipped the middle image.</p>
  
  <p>I tried outputting to <code>slideshow.MOV</code> and without the filter, and it also throws the same error.   I tried outputting to <code>slideshow.MTS</code> and without the filter, it works but the result shows no images when I play it on VLC.</p>
  
  <p>Why does the command and the implicit call to libx264 take so long, and how can I avoid using libx264?</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-03-10T11:53:31.650Z
Comments.Text: You're rendering 7.5 seconds x 25 frames/sec = 188 whole frames of `6932x4683` resolution. That will take quite a bit of processing time.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-03-10T12:47:42.250Z
Comments.Text: Indeed, scaling down (with `ffmpeg -f concat -safe 0 -i slideshow.txt -vf "scale=-1:720,pad=ceil(iw/2)*2:ceil(ih/2)*2" slideshow.mp4`) takes 2.7 seconds to output a `1065x720` file. A quick calculation would suggest that the original command would take `2.7*(6932/1065)*(4683/720)=114` seconds. Is that rule of thumb a reasonable way to estimate processing time?
Comments.UserDisplayName: emonigma
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-03-10T13:28:58.553Z
Comments.Text: As a first approximation, yes, but modern encoders have some steps like motion search to identify conserved pixels which may be proportional to surface area in a non-linear fashion.
Comments.UserDisplayName: Gyan
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2020-03-11T10:51:35.483Z
Comments.Text: Thanks! Can you move the comments to an answer?
Comments.UserDisplayName: emonigma
Tags: <ffmpeg><libx264>
Title: Slideshow compilation takes 10 minutes for 3 images
UserDisplayName: emonigma
ThreadText: # Slideshow compilation takes 10 minutes for 3 images
  
  (Asked by: username_0 on 2020-03-10)
  
  I want to make a slideshow from images. The first image has 6932x4683 pixels, so I got an error `height not divisible by 2` and I found [this thread](https://stackoverflow.com/questions/20847674/ffmpeg-libx264-height-not-divisible-by-2). I understand that `libx264` is implicit in the output as `.mp4`, and that `libx264` needs an input image whose dimensions are divisible by 2. So I used the padding filter recommended there:
  
  ```
  ffmpeg -f concat -safe 0 -i slideshow.txt -vf "pad=ceil(iw/2)*2:ceil(ih/2)*2" slideshow.mp4
  
  ```
  
  The file `slideshow.txt` is:
  
  ```
  
  file '03.jpeg'
  duration 2.5
  file '01.jpeg'
  duration 2.5
  file '02.jpeg'
  duration 2.5
  file '02.jpeg'
  
  ```
  
  The command took 10 minutes to process these 3 images. When playing the result, it skipped the middle image.
  
  I tried outputting to `slideshow.MOV` and without the filter, and it also throws the same error. I tried outputting to `slideshow.MTS` and without the filter, it works but the result shows no images when I play it on VLC.
  
  Why does the command and the implicit call to libx264 take so long, and how can I avoid using libx264?
  
  **Tags:** ffmpeg, libx264
  
  > **Comments:**
  > **username_1**: You're rendering 7.5 seconds x 25 frames/sec = 188 whole frames of `6932x4683` resolution. That will take quite a bit of processing time.  
  > **username_0**: Indeed, scaling down (with `ffmpeg -f concat -safe 0 -i slideshow.txt -vf "scale=-1:720,pad=ceil(iw/2)*2:ceil(ih/2)*2" slideshow.mp4`) takes 2.7 seconds to output a `1065x720` file. A quick calculation would suggest that the original command would take `2.7*(6932/1065)*(4683/720)=114` seconds. Is that rule of thumb a reasonable way to estimate processing time?  
  > **username_1**: As a first approximation, yes, but modern encoders have some steps like motion search to identify conserved pixels which may be proportional to surface area in a non-linear fashion.  
  > **username_0**: Thanks! Can you move the comments to an answer?  
  
  ---
  
  ## 0 answers
  
  