Encoding H264 with windows ffmpeg results in first few seconds being "blocky"

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.

degenerate

Posted 2014-05-30T16:50:12.053

Reputation: 365

1Please 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 – 2014-06-02T01:07:46.760

@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 – 2014-06-02T23:42:25.713

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 – 2014-06-03T00:02:19.240

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 – 2014-06-03T05:02:07.113

Encoding H264 with windows ffmpeg results in first few seconds being "blocky"

Answers