On Fri, Dec 23, 2011 at 10:26 PM, Dale <firstname.lastname@example.org> wrote:
> Dale wrote:
>> Well, it took some experimenting but I finally figured it out. *I like to
>> have never found the save video option under the file menu. *Why not hide it
>> next time. *lol *I can't blame it on my glasses this time either. *I got new
>> ones a while back. *Maybe it is stupidity. *o_O
>> I will say this tho, it is dang fast. *It took like 10 to 15 seconds and
>> it was done. *Kdenlive took MUCH longer.
>> File size is awesome too. *The two files added are very close to just
>> adding the file size of each video. *I'm talking within a megabyte or two.
>> Thanks for this tip. *I got a new toy to play with. *lol
>> :-) *:-)
> Since you seem to have used this more than I have. *I have a question. *On
> the original videos, the sound is synced up fine. *The words match when
> their lips move and other sounds match up. *After I splice them together,
> the sound is off. *It seems longer videos are worse than shorter ones. *Am I
> missing something here? *I'm pretty much using the default settings.
> I also have a problem with the older .flv1 files. *Any tips on that?
> *Something special I need to install for older formats? *I googled and found
> threads but it appears the packages either merged with something else or are
> no longer available or something.
> Thanks much.
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
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.