I've captured some .mkv files with Simple Screen Recorder (SSR). When I watch these individual files, they play fine in Mplayer. The sound and image are in perfect sync. I hear clicks from my mouse and they match with actions on the screen.

While editing (A/V Sync is on) in Blender's Video Sequence Editor (VSE) it all seems rather fine - I can not play it back smoothly from Blender (640x480@60FPS, h.264 losless, stereo FLAC audio), but it doesn't seem to float too much. Just a little, especially when I start in the middle of a clip.

I rendered the movie, and the sound is completely off with timing in relation to the motion picture. It's floating around by a couple of seconds (an event happens, a few seconds later I hear sounds that were related to the event I saw earliest etc.).

I tried re-rendering the movie after enabling and generating timecode (Free run mode) for all movie clips. It didn't help at all.

What is happening? Is this a bug? I'm having these sync issues for years now.

  • $\begingroup$ Related: blender.stackexchange.com/q/2654/599 $\endgroup$
    – gandalf3
    Oct 14, 2014 at 20:35
  • $\begingroup$ Is the blender project's framerate the same as the video you are editing? $\endgroup$
    – user1853
    Oct 16, 2014 at 13:46
  • $\begingroup$ Yes. I've recorded in 60 FPS, and I've edited in 60 FPS - the video and audio clips match in length. $\endgroup$
    – unfa
    Oct 29, 2014 at 17:09

1 Answer 1


My guess would be that Blender is not decompressing the file successfully. Best solution is to transcode the source media (with non Blender app) to be Blender friendly but sadly this will probably increase file sizes a lot.

  • $\begingroup$ I've captured the video into Matroska container with H.264 lossless video stream and FLAC audio stream. Gotta try some transcoding and see what can I get. $\endgroup$
    – unfa
    Oct 29, 2014 at 17:12
  • $\begingroup$ Depending on your capture method the key frames (I frames) and bitrate may vary a lot, Blender seems to prefer simple compression schemes. Unfortunately that means more bitrate than modern compression techniques need. $\endgroup$
    – 3pointedit
    Nov 6, 2014 at 8:04
  • $\begingroup$ @3pointedit nailed it. Bi-directional frames are entirely unsuitable for scrubbing and the needs of an NLE. This is almost certainly causing the issue. Use still images or transcode to a format with only P frames or all I frames. $\endgroup$
    – troy_s
    May 17, 2015 at 21:57

You must log in to answer this question.

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