Michael Mol wrote:
This is a slightly simplified explanation, owing to my probably not
remembering details quite correctly.
Media files consist of at least three parts: The container format, the
audio stream and the video stream. You're familiar with container
formats as ".flv", ".mkv", ".avi", ".mpg", ".mp4", etc.
The audio and video streams consist of frames (for video) or samples
(for audio) where each one consists of information particular to a
particular video image or audio sample. The audio and video frames
typically don't include information as to when they occurred; a frame
won't tell you that it's specific to 33.2 seconds into a sequence, for
example.
Normally, the file and/or streams will describe how many frames per
second the video stream should move along at, and how many samples per
second the audio stream should move along.
When the samples and frames stop matching up as the media file plays,
you get desync. This is normal to within a certain tolerance; when
you're moving along 48k audio samples per second, and only 30 video
frames per second, nobody cares if an audio sample is ten or so off
from its ideal position.
Unfortunately, I can only tell you what's going on. I can't tell you
how to fix it; it's not something I dealt with much.
I'd suggest you give the other tools a try, too. The other tools
brought up will do essentially the same thing as avidemux; they're
just ripping the audio and video streams out of the source container
files and placing them into a new container file. Your old approach
was very, very slow because your tools were generating completely new
audio and video streams. It's the difference between "dd if=src
of=dst" and "dd if=src|lzma --decompress --stdout|lzma --stdout|dd
of=dst" ... except lzma doesn't loose any data in the process, while
your transcoding was. Once you get the sync issues worked out, you
might even notice improvements in audio and image quality. :)
I been doing some testing on this. I went to about the end of a 3 hour
video. By the time it gets near the end of the video, the sound is
almost 1.4 seconds off. I tested this by telling smplayer to adjust the
audio delay. It is a bit annoying to see something on screen then hear
it a second or so later. It's like seeing a explosion at a distance.
You see it then have to wait for the sound wave to hit you. When I am
midways of the video, it is about .6 to .7 seconds off. So, it gets
farther off as it goes. It's most likely one step off that just gets
worse as it goes.
I tried a couple other commands but I get errors about the file type. I
think a couple movies are in flv1 which is old. I may have to convert
them then stitch them together, which may not do the sound any good then
either. lol
Well, I got something to play with.
Dale
:-) :-)
--
I am only responsible for what I said ... Not for what you understood or how
you interpreted my words!
Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"
