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