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?
- 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.