Some tutorials online recommend converting a video to an image sequence in Blender before using the motion tracking features. See https://www.youtube.com/watch?v=InIuTtt7W3E?t=135, which explains that doing it directly to a video works but does not save correctly i.e. next time you re-open the project you'll find the video is out of sync.

I find this hard to believe, that something as simple as this is broken in Blender.

Can anyone elaborate on why this is the case with Blender?


1 Answer 1


You don't necessarily have to convert video to an image sequence.

While it is possible to decode and track without having to use an image sequence, some videos will work and some will result in errors, depending on how they are encoded.

Blender is not broken, but can only work with video that is encoded with certain specific parameters.

Video encoded with intraframe compression will work fine. Each and every frame containd all of the information, so it does not depend from the information of previous frames or any of the frames that come after it (same as with an image sequence).

Video encoded with interframe , or long GOP compression, will likely yield errors, since the information needed to decode each frame is dependent on adjacent frames, and only the differences are calculated. In other words, there is a key frame that has all the information, for the next few frames only the differences are calculated, but to decode those frames you need to reference the keframe everytime.

Also, if the video is encoded using any kind of variable framerate (some phones use this to make small files, as well as some screen recording software), then it needs to be re-encoded and conformed to a uniform and stable framerate, before being imported in blender.

Blender will not do on-the-fly framerate conversion or temporal interpolation in any way.

For more information read: http://www.leckman.com/articles/codecs_05.html

  • 2
    $\begingroup$ Even if your system did support any compression, youd most likely want to convert the footage to something more suitable to random lookup. The cost is minimal, but the benefits are huge. $\endgroup$
    – joojaa
    Commented Dec 31, 2019 at 7:59
  • 2
    $\begingroup$ Part of the issue is that non-professional cameras (phone cameras, for example) use delivery codecs (8 bit, long GOP, variable framerates) to create small files. Those files are designed to minimize file size and facilitate playback at the expense of precision. They are a poor choice for precision editing and any form of post-production. Professional cameras use production codecs or raw files, that will yield much larger files, with less compression, more bits per pixel and stable framerates. Only after post-production those images are converted to delivery codecs for easy playback. $\endgroup$
    – user1853
    Commented Dec 31, 2019 at 17:18

You must log in to answer this question.

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