5
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ Related: blender.stackexchange.com/q/2654/599 $\endgroup$ – gandalf3 Oct 14 '14 at 20:35
  • $\begingroup$ Is the blender project's framerate the same as the video you are editing? $\endgroup$ – cegaton Oct 16 '14 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 '14 at 17:09
2
$\begingroup$

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.

$\endgroup$
  • $\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 '14 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 '14 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 '15 at 21:57

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.