Re: [gentoo-user] Video editing advice on formats and size of file

[Dale <rdalek1967@gmail.com>]

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"