5

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.

Improve this question
5
  • 2
    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
    Commented Jun 2, 2014 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
    Commented Jun 2, 2014 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
    Commented Jun 3, 2014 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
    Commented Jun 3, 2014 at 5:02
  • It's not a problem FFmpeg but rather of the x264 encoder you're using.
    – tripulse
    Commented Oct 1, 2020 at 5:42

1 Answer 1

Reset to default
3

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"
Improve this answer
4
  • Not working for me. webm -> mp4. Mp4 file 1h duration still has delay.
    – Alex Sham
    Commented Nov 22, 2020 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
    Commented Jan 21, 2021 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
    Commented Jan 22, 2021 at 13:13
  • I don't know how many days I would have spent trying to solve the similar problem had it not been for this answer. Thank you!
    – yaskovdev
    Commented Dec 6, 2022 at 14:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .