5

I'm executing basic ffmpeg command to transcode input MP4 video to output MP4 video (both using H264 as video codec, and stripping out audio, for simplicity):

ffmpeg -i input-video.mp4 -b:v 20000k -an -vcodec libx264 output-video.mp4

Transcoding is initially pretty fast (around 60-70 fps for first 20 or so frames), and then starts dropping steadily, ending at around 30 fps after 5000 frames.

Is this inherent behavior? If so, why does it happen? Also, is there any better option for the command line that would improve speed (besides using -threads)?

Would it be better to cut the input video and process it as smaller chunks, getting overall higher speed per sequence? (I'm afraid that chunking might affect encoder's RD optimization)

Nikola R.
  • 51
  • 1
  • 3
  • 1
    I observe that all the time when a movie starts mostly black or with very simplified images (can be easily checked if video-content is the reason). Keep also in mind, that the nature of mean-fps calculation can obscure the effect (slowly getting slower although speed is constant now; running-average). Maybe also some window-based data-structures need to grow effecting in more cycles needed when saturated. – sascha Jan 23 '18 at 20:04
  • The optimal number of `-threads` is automatically used for this encoder. – llogan Jan 23 '18 at 20:14
  • @sascha You might be right in case of movies, or other clips that have intro. Video clips I'm using have same, demanding content at the beginning (unlike movies that might begin with intros, etc.). I'm also wondering if there's some saturation in the memory. – Nikola R. Jan 23 '18 at 21:22
  • @LordNeckbeard yes, that's why I'm wondering if there's some other parameter that would prevent this slow-down. – Nikola R. Jan 23 '18 at 21:22
  • At that bitrate, it might also be disk caching. – Brad Jan 24 '18 at 06:22
  • @Brad, that's an interesting suggestion. I tested with lower bitrate (1500k, instead of 15000k). The slow-down is still there but at a lower pace - it starts around same numbers and goes down to 40 fps. Probably disk contributes to the issue, but it seems it's not the only reason. – Nikola R. Jan 24 '18 at 15:57
  • perhaps it's the average time, I have to look at the code to be sure but I *guess* the gauge starts with a very high number (say 50x), the next frame goes to the true speed (say 5x), now the avrg(50,5)=27x, with the next frame we have avrg(50,5,5)=20x, next frame... and so on untill 50x shifts out and we just have avrg avrg(5,5,...,5)=5x – hkoosha Apr 27 '19 at 09:44

0 Answers0