Audio/Video out of sync in rendered video, but not in VSE First let me apologize to ask this question, as this has been basically already asked, for instance here, here and here. However these answers don't seem to provide an understanding what's really going on, so I will pose my question anyway.

Every once in a while the video in a rendered video file will playback much faster than the audio, despite audio and video being perfectly in sync in the VSE. This problem seems always to pop up when then input source video is "mostly static", i.e. when the change from one frame to the next is miniscule (e.g. a screen recording). I should also add that I record the videos in question using a lossless codec (FRAPS or lagarith).

From the other questions linked above, I get the impression that this is due to Blender (or rather its version libavcodec) incorrectly decoding the compressed source video. It is also mentioned in one answer to the above questions that this is related to the use of b-frames in the encoding algorithm. However I had this problem also using the lagarith codec, which apparently uses only keyframes/i-frames.

Now in order to turn this cry for help into a question, let me ask: What the hell is going on here?

More precisely: 


Why can Blender (or its version of libavcodec) apparently correctly decode and show the video in the VSE, but not render it correctly? Is the decoding in the VSE done differently than in rendering?
What version of libavcodec is used in Blender 2.74? Is the implementation of e.g. lagarith faulty in this version? If not, then why does Blender mess up the rendering? 
It has been suggested that one should use "Blender-friendly" codecs for compression. Which lossless codecs are known to be so? 


Edit: It seems there are several error sources here, which just makes everything much more confusing. The problem of the video playing back at twice the normal speed I had with this one particular lagarith encoded source seemed to stem from a corrupted (??) .blend file. Namely during editing Blender got stuck and I had to force it quit. When I re-opened this file Blender didn't give me any complains, but comparing its file size with the sizes of some other .blend files which were similar, I noticed that it seemed about 3 kB smaller than the rest. Opening this file and saving it to a new file ("Save as") got rid of this playback issue. However the video is still out of sync, even more subtly. Instead of the video globally playing back faster, it sometimes seems to "get stuck" and then "catching up again".

These issues are also already visible in the VSE, so it seems that my problem at least in this instance is solved. On the other hand this makes the behaviour of Blender seem even more mysterious, as I do not understand how a corrupted (was it even corrupted??) .blend file can lead to such an effect.

As I wrote, I experienced this issue with several videos, one of them being a video encoded in FRAPS. There the audio and video seemed in sync in the VSE, but wasn't in the rendered video. Strangely, after re-creating this .blend file from scratch, the audio and video now was out of sync even in the VSE. I tried transcoding it with ffmpeg, and this also gave an out of sync video. However transcoding it with Windows Movie Maker gave perfect result. So I suppose that for this particular video, the problem is that the fraps codec is implemented imperfectly in ffmpeg/libavcodec.

2nd Edit: The problem is back. Apparently it didn't have anything to do with the file being 'corrupted'. Running blender again on the very same file this time produced again an out-of-sync video. This issue seems to appear and disappear randomly.

3rd Edit: Still no clue why it only appears sometimes. But I noticed something else. The audio in the rendered video is as it should be, i.e. its start and end are as defined in the .blend file. However the last frame in the rendered video is actually way beyond the end frame. For some reason Blender consumes more video frames than it is supposed to be. I am going to file a bug report on this.
I was asked to take a look at this post. Codecs can be rather puzzling to diagnose from a distance, but it does seem that some information can be offered.


  This problem seems always to pop up when then input source video is
  "mostly static", i.e. when the change from one frame to the next is
  miniscule (e.g. a screen recording). I should also add that I record
  the videos in question using a lossless codec (FRAPS or lagarith).


The “mostly static” comment here is interesting. This does indeed sound like an I versus P / B frame issue, as the “mostly static” frames would be subject to many more instances of P / B frames. While I am unfamiliar with Lagarith or FRAPS, I would be extremely surprised if a non-GOP codec had this issue, as your solution hints toward.


  Why can Blender (or its version of libavcodec) apparently correctly
  decode and show the video in the VSE, but not render it correctly? Is
  the decoding in the VSE done differently than in rendering?


The VSE is using certain techniques to display the video that, when decoded on a shot by shot basis for rendering are different. This is why non-GOP codecs are more robust, or time code indices will yield more consistent results. This is also why most always-online NLEs will transcode upon ingestion; to avoid the codec problems as well as try to reduce the always-online image degradation issues.


  What version of libavcodec is used in Blender 2.74? Is the
  implementation of e.g. lagarith faulty in this version? If not, then
  why does Blender mess up the rendering?


FFMPEG's version was a bit nasty on some platforms as it previously used a bundled version on some while on others it used a local version. If you check the ffcompat code, you can see many version checks to support generic versions of FFMPEG.


  It has been suggested that one should use "Blender-friendly" codecs
  for compression. Which lossless codecs are known to be so?


The easiest way to avoid all of the codec mess is to rely on still frame intermediates. If you must for whatever reason rely on codecs, you are likely going to be constantly faced with these sorts of issues unless you manage to coax one of the codecs to behave under generated timecode indices. I would also speculate that FFv1 should be a reasonable choice to test and put under duress, given the nature of its design. If you try FFv1, it would be interesting if you reported your results back here for future reference.

Best of luck.