We are converting a sequence of DPX images into an MP4 video:

ffmpeg -start_number 101 -i dpx/example.%04d.dpx ./example.mp4 # minimal conversion

ffmpeg -y -start_number 101 -i dpx/example.%04d.dpx -b12100k
-minrate 12100k -maxrate 12100k -bufsize 12100k -vf colormatrix=bt601:bt709
-pix_fmt yuv420 ./example.mp4 # conversion with colour correction

However, when opening this MP4 in Adobe Premiere Pro, it appears to be missing the first two frames (first two frames not accessible, third frame is accessible, total frame count is 2 off). The same file does not have missing frames when opened in other applications (Quicktime Player and VLC). Other video files do not have missing frames when opened in Premiere.

The following conversions do not solve the problem (ref 1) (ref 2) (ref 3 "-timecode"):

ffmpeg -start_number 101 -i dpx/example.%04d.dpx -filter_complex "[0] fps=fps=25"
./example.mp4 # force fps with filter_complex

ffmpeg -start_number 101 -i dpx/example.%%04d.dpx -timecode 00:00:00:01 ./example.mp4
# force timecode (tried drop and non-drop format)

The following conversion (inherited wholesale) does work. Why? Which argument is fixing the problem?

ffmpeg -start_number 101 -i dpx/example.%%04d.dpx -crf 15.0 -y -vcodec libx264
-b:a 128k -b:v 4000 -intra -s 1280x720 -r 25 -ar 48000 -ab 192000 -coder 1 -flags +loop
-me_method hex -subq 6 -me_range 16 -g 1 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71
-b_strategy 1 -threads 0 ./example.mp4 # mystery meat

(Obviously we're tweaking the working one to match our other requirements.)


Having tested a few scenarios, it's the presence of multiple B-frames that looks responsible. It's their storage out-of-presentation sequence and a new bug in Adobe's H264 bitstream parser which is causing this problem.

So, adding -x264opts bframes=1 (or 0) solves it. This is not an issue with FFmpeg, AFAICT, since other apps including NLEs like Vegas can read MP4s without this option correctly. Even older versions of Adobe CC do, as per your links.

Edit: -x264opts b_pyramid=0 looks to be the direct solution.

  • some experimentation revealed that -g 1 also fixed the issue, but your bframes argument results in a smaller file to boot - thanks!
    – lofidevops
    Aug 30 '16 at 10:20
  • -g 1 means no B-frames and no P-frames, but P frames don't cause the problem.
    – Gyan
    Aug 30 '16 at 10:22

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.