| 1 |
On Fri, Dec 23, 2011 at 10:26 PM, Dale <rdalek1967@×××××.com> wrote: |
| 2 |
> Dale wrote: |
| 3 |
>> |
| 4 |
>> |
| 5 |
>> Well, it took some experimenting but I finally figured it out. I like to |
| 6 |
>> have never found the save video option under the file menu. Why not hide it |
| 7 |
>> next time. lol I can't blame it on my glasses this time either. I got new |
| 8 |
>> ones a while back. Maybe it is stupidity. o_O |
| 9 |
>> |
| 10 |
>> I will say this tho, it is dang fast. It took like 10 to 15 seconds and |
| 11 |
>> it was done. Kdenlive took MUCH longer. |
| 12 |
>> |
| 13 |
>> File size is awesome too. The two files added are very close to just |
| 14 |
>> adding the file size of each video. I'm talking within a megabyte or two. |
| 15 |
>> |
| 16 |
>> Thanks for this tip. I got a new toy to play with. lol |
| 17 |
>> |
| 18 |
>> Dale |
| 19 |
>> |
| 20 |
>> :-) :-) |
| 21 |
>> |
| 22 |
> |
| 23 |
> Since you seem to have used this more than I have. I have a question. On |
| 24 |
> the original videos, the sound is synced up fine. The words match when |
| 25 |
> their lips move and other sounds match up. After I splice them together, |
| 26 |
> the sound is off. It seems longer videos are worse than shorter ones. Am I |
| 27 |
> missing something here? I'm pretty much using the default settings. |
| 28 |
> |
| 29 |
> I also have a problem with the older .flv1 files. Any tips on that? |
| 30 |
> Something special I need to install for older formats? I googled and found |
| 31 |
> threads but it appears the packages either merged with something else or are |
| 32 |
> no longer available or something. |
| 33 |
> |
| 34 |
> Thanks much. |
| 35 |
|
| 36 |
This is a slightly simplified explanation, owing to my probably not |
| 37 |
remembering details quite correctly. |
| 38 |
|
| 39 |
Media files consist of at least three parts: The container format, the |
| 40 |
audio stream and the video stream. You're familiar with container |
| 41 |
formats as ".flv", ".mkv", ".avi", ".mpg", ".mp4", etc. |
| 42 |
|
| 43 |
The audio and video streams consist of frames (for video) or samples |
| 44 |
(for audio) where each one consists of information particular to a |
| 45 |
particular video image or audio sample. The audio and video frames |
| 46 |
typically don't include information as to when they occurred; a frame |
| 47 |
won't tell you that it's specific to 33.2 seconds into a sequence, for |
| 48 |
example. |
| 49 |
|
| 50 |
Normally, the file and/or streams will describe how many frames per |
| 51 |
second the video stream should move along at, and how many samples per |
| 52 |
second the audio stream should move along. |
| 53 |
|
| 54 |
When the samples and frames stop matching up as the media file plays, |
| 55 |
you get desync. This is normal to within a certain tolerance; when |
| 56 |
you're moving along 48k audio samples per second, and only 30 video |
| 57 |
frames per second, nobody cares if an audio sample is ten or so off |
| 58 |
from its ideal position. |
| 59 |
|
| 60 |
Unfortunately, I can only tell you what's going on. I can't tell you |
| 61 |
how to fix it; it's not something I dealt with much. |
| 62 |
|
| 63 |
I'd suggest you give the other tools a try, too. The other tools |
| 64 |
brought up will do essentially the same thing as avidemux; they're |
| 65 |
just ripping the audio and video streams out of the source container |
| 66 |
files and placing them into a new container file. Your old approach |
| 67 |
was very, very slow because your tools were generating completely new |
| 68 |
audio and video streams. It's the difference between "dd if=src |
| 69 |
of=dst" and "dd if=src|lzma --decompress --stdout|lzma --stdout|dd |
| 70 |
of=dst" ... except lzma doesn't loose any data in the process, while |
| 71 |
your transcoding was. Once you get the sync issues worked out, you |
| 72 |
might even notice improvements in audio and image quality. :) |
| 73 |
|
| 74 |
-- |
| 75 |
:wq |
Archives