Unauthorized Cola FAQ Notes 23-Jun-2002

Notes for this week:

1. I will be away next weekend and so we will very likely not see a posting of the UFAQ until weekend of July 6/7.

2. A couple of people gave me the OK to take posts from the 'Windows Software for Linux' thread, but, alas, it is not going to happen this week, Real World pressures abound! If anybody else were to post that stuff into a FAQ thread, this would make it quite a bit easier for me. It is easy to see some type of treatment of the subject: migrating Win to Linux. ideas like 'solutions not replacements' were well represented on that thread.

3. Same as point 2, Rap's post [SOT] Don't you wish... makes a perfect FAQ article in and of itself. What's chances you'll copy it into a FAQ thread rap and save me a little work? Pretty please?

4. There was *a* *lot* to put in this week, so if I missed something you put in, please accept my haggard apologies and repost it.

Actually, in this thread is fine. I'm getting a picture in my head of kind of another part of the FAQ, part 6, 'can I do X in Linux?' or 'From Win to Linux', where we cover all kinds of questions that are often asked by people making that switch. I sort-of kind-of pictured your post there, as a strong start on a multi-media section for this new part 6.

But for future reference, posting anything in any thread is OK. I only ask you to do this because I have from time to time thought it would be a good idea to 'mine' threads for material, but realistically it always turns out that I can only follow the FAQ threads themselves.

You know, though, this raises an interesting point. If anyone ever sees something that would work well in the FAQ, a simple cut-n-paste into a FAQ thread also preserves the history of development for the archives. Put another way, whatever makes it easier for the maintainer also makes it easier for the historian. Not that I imagine historians of 2000 years from now will be writing phD theses on the COLA FAQ, but sometimes we might want to go back just a few weeks and ask, 'where did X come from.' Although we have yet to suffer this issue, it may arise that somebody takes exception to having their content included, and does not object until a few weeks *after* it has been put in. We would need to be able to track that easily and smooth any ruffled feathers with no confusion.

Error Log for Sun, 23 Jun 2002 22:39:39 -0400: segfault in module 'Kenneth Downs' - dump details are as follows...

Error Log for Tue, 25 Jun 2002 15:46:51 -0400: segfault in module 'Mike.' - dump details are as follows...

Sorry. That should be 'vfr' for 'Video Frame Rate'.

As an additional addendum for anyone interested, it is necessary to determine what frame rate the video was encoded at, using the catch all of 4 (which is for 30 fps) sometimes results in loss of a/v synch if the file was encoded at a lower or higher rate.

So, from digging about, I found out the best way to do this is to just play the file directly with mplayer from a command line.

When the file is first loaded, mplayer determines the frame rate and will output something like this....

Playing foo.avi Cache fill: 4.10% (344064 bytes) Detected AVI file format! VIDEO: [DIV3] 352x240 24bpp 29.97 fps 559.4 kbps (68.3 kbyte/s) ^^^^^^^^^^^^ This is what to look for!

Once you have this output, you can simply exit mplayer, and then look up the Video Frame Rate code that most closely matches the encoded framerate...

Here is the table directly from the mencvcd script help:

0 - illegal (i.e. DON'T USE!)

1 - 24000.0/1001.0 (NTSC 3:2 pulldown converted FILM)

2 - 24.0 (NATIVE FILM)

3 - 25.0 (PAL/SECAM VIDEO / converted FILM)

4 - 30000.0/1001.0 (NTSC VIDEO)

5 - 30.0

6 - 50.0 (PAL FIELD RATE)

7 - 60000.0/1001.0 (NTSC FIELD RATE)

8 - 60.0

So, in the case above with foo.avi, we see that the encoded frame rate is 29.97 fps, and the lowest number that most closely matches is option 4, so in this case we would use the option '-vfr 4' in the command phrase.

Note that you could also use option 5 for 30.0 fps and it should work ok in this case, but option 4 is standard output and more likely to be recognized by more players.

HTH