Full details at
http://quu.livejournal.com/821424.htmlProblemWhen encoding a video using modern encoding tools, the idea that the tools would change the audio and video sync of the source material is rarely considered. When initially investigating this, I found that this could not be counted on. MP3 and AAC audio encoders need to pad the beginning of the stream with empty packets, and the amount of empty packets is not always formalized, leading to different vendors using different padding, confusing the decoders. Video encoding tools have a simpler job, since a frame is well defined, but even then, some video encoders automatically change or adjust the frames with default settings, trying to compensate for interlaced source footage.
After initially doing a very broad investigation into audio and video sync, I decoded to narrow my focus. The decoder used has as much to do with the sync of any videos as the encoders. I selected two popular video players that supported an easy export feature, VLC and MPlayer. The idea is to take a known "Baseline" uncompressed AVI file, encode it with various tools, then export it with the players, and test how much the audio and video has gone out of sync as compared to the original AVI exported/played the same way.
My testing is not looking for audio or video quality of the various encoders, but just the ability to maintain the original audio and video sync when played with VLC and MPlayer.
Tools and VersionStand Alone Full Audio and Video Encoders
Handbrake - 0.9.4 (CLI version used)
x264 JEEB's build with L-SMASH, QTAAC and LAME - x264 0.104.0+1943 19e73ec built on Sep 4 2010, gcc: 4.4.4 (x86.generic.Komisar)
Audio Encoders
FAAC - 1.28
FLAC - 1.2.1
LAME - 3.98.4
Nero AAC Encoder - 1.5.1
QTAACEnc - version 20100725 by tmkk
Video Encoder
x264 (from x264.nl) x264 0.104.1713 c276662 built on Sep 4 2010, gcc: 4.4.4
Muxers
mkvmerge - v4.2.0 ('No Talking') built on Jul 28 2010 18:38:23
mp4box - MP4Box - GPAC version 0.4.5 (build 33 - Dec 11 2008) - compiled by Kurtnoise
mp4creator - mpeg4ip version 1.6.1d
tsmuxer - Version 1.10.6
ResultsAs far as video sync goes, the default "High Profile" settings in Handbrake breaks the video sync as it tries to compensate for interlaced footage, even when given progressive footage. When the default profile is modified, Handbrake is able to produce in sync video with no lost frames. No matter how it is muxed, x264 footage is always in sync.
For audio sync, things were a little different. Both of the stand alone audio/video encoders where able to produce audio that stayed in sync, even when Handbrake's default setting dropped video frames, the audio was perfectly in sync when played back. Of the stand alone audio encoders, only FAAC and FLAC were able to stay in sync with the encoded video, no matter how they were muxed. Uncompressed PCM audio was also tested, but only VLC was able to play it, and it was in sync when tested. What is strange is that JEEB's build of x264, which included QTAAC and LAME was able to maintain perfect audio sync, but when both of those tools were tested externally, they failed the sync test. Even when JEEB's x264 build imported the externally rendered files they were out of sync, so it is not purely because of the L-SMASH mp4 muxer in JEEB's build.
LAME, Nero, and QTAAC all produced audio files, that when muxed and played back in the two test players, that were delayed when compared to the original audio and out of sync with the video. It did not matter what muxer was used, the audio created by these three stand alone encoders where not played properly by VLC or MPlayer, while FAAC, FLAC, and the stand alone audio/video encoders where.