I am using the following code to transcode a 10mbps high quality 1280x720 H264 mp4 into a lower quality H264 mp4 with our logo watermarked on the video.

ffmpeg.exe -i test.mp4 -i watermark.png -filter_complex overlay="(main_w)-(overlay_w):(main_h)-(overlay_h)" -c:v libx264 -profile:v main -preset slow -b:v 400k -r 30 -c:a libvo_aacenc -b:a 128k -s 1280x720 -movflags faststart -f mp4 "test-done.mp4"

These settings work wonderful and after lots of tweaking to get this code, it produces crisp, clear video for high action, stills, many different colors, etc.

The problem is that in the first few seconds of the video, the stream is very blocky. Then, after about 3-5 seconds, the stream "corrects" itself and the video is crisp and clear. Slowing down the rendering time by changing the preset to "veryslow" only marginally improves the first few seconds, but it increases render time dramatically.

How can I tell ffmpeg to pay more attention to the beginning of the video? Do I have to resort to 2-pass encoding? I don't want to nearly double the render time because only the first few seconds of the video have this problem. Could anyone modify my code to provide better encoding at the beginning of the file?

For reference, the original 10mbps mp4s are encoded by Premiere 5.0 and do not have blockiness at the beginning. This is something I have only witnessed with ffmpeg after transcoding.

  • 1
    Please include the complete ffmpeg console output that results form your command. Also, do you get the blockiness if you replace -b:v 400k with -crf 18?
    – llogan
    Jun 2 '14 at 1:07
  • @LordNeckbeard You're the ffmpeg-man, man! I always stumble upon your awesome answers on SO from searching google. Indeed crf instead of b:v fixed the problem. A crf of 18 resulted in ~4MB/s bitrate. After some testing, -crf 26 results in approximately the bitrate I was shooting for (~400kbps) but the encoding blockiness in the beginning of the file is now gone. Cheers to you!
    – degenerate
    Jun 2 '14 at 23:42
  • 1
    Glad it worked for you. What is the use case for your output? What is the significance of 400k? I recommend removing -s and appending scale to your filtergraph so the behavior is more predictable: "overlay=W-w:H-h,scale=1280:-2". Since you mentioned Premiere you might like How to encode with ffmpeg from Adobe Premiere Pro.
    – llogan
    Jun 3 '14 at 0:02
  • We have a low bandwidth target audience. I never knew about the native UT Video encoder for ffmpeg, and the frameserver ability. These are both new to me. I'll also try out the scaling tweak. Thanks again :)
    – degenerate
    Jun 3 '14 at 5:02
  • It's not a problem FFmpeg but rather of the x264 encoder you're using.
    – tripulse
    Oct 1 '20 at 5:42

Thank you @LordNeckbeard for the solution. It seems ffmpeg encodes x264 way better using -crf instead of -v:b.

So -crf 26 worked perfectly to eliminate the blockiness at the beginning of the video encoding process.

My final code is now:

ffmpeg.exe -i test.mp4 -c:v libx264 -crf 26 -c:a libvo_aacenc -movflags faststart -f mp4 "test-done.mp4"
  • Not working for me. webm -> mp4. Mp4 file 1h duration still has delay.
    – Alex Sham
    Nov 22 '20 at 13:09
  • @AlexSham my post was from 2014, ffmpeg has changed a lot in 7 years. I suggest googling for articles on ffmpeg encoding that were written in 2020/2021.
    – degenerate
    Jan 21 '21 at 18:06
  • I'm not downvoting, just leaving comment here for others, who may face same problem, that they are not alone.
    – Alex Sham
    Jan 22 '21 at 13:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.