Looking for input for an upcoming tutorial movie

I'm working on a tutorial video to demonstrate the basic steps of producing a movie in Second Life, and I'd appreciate some input, and possibly help, from my fellow machinimers.

Subject areas include:
1) Software - capture, editing, export, codecs, compression, etc
2) Hosting - Personal hosting, Youtube, Blip, etc
3) Showing movies inworld
4) SL camera systems - Alt-Zoom, Filming Path, others?
5) Free content sources - music, sound effects
6) SL-based content sources - props, locations, etc
7) Intro to cinematography - terminology, demo of basic moves, editing techniques

These are the main areas that I think should be adequately covered. All over, this video might be 20-30 min long.

I am *not* a RL film maker, my interest in machinima has only come through Second Life. In this regard, if some of you fellow machinimers ARE film makers and would like to add your input it would be really really appreciated. I've learned enough to be dangerous and to teach others what I know, but some pro-talent input would be nice.

Hi Geuis,
Sounds a great idea, could be used as a 'reference' baseline for anyone starting in SL.

I would offer some points:-
Items 1 - 2 from our experience are linked. The delivery format should be matched to the delivery mechanism.
There are 3 basic ways to deliver movies into SL, or indeed any rendering software/browser. Download and watch, Progressive download (starts and plays as the movie is downloading) and full RSTP streaming.
Download and watch, along with progressive download are the cheapest and easiest to use. Download and watch, being the slowest. One of the downsides is you loose control of the content as it is stored on each viewers PC. For 'secure' content, RSTP renders the movie on the fly.

Download and watch can be virtually hosted by any internet linked PC/server, from Home Brew, to fully supported dedicated servers.

Progressive download would have to have a much more powerful delivery system, that can maintain the stream, keeping the cache full ahead of the movie being watched, otherwise it may stop and start, or begin from the start each time the cache becomes empty.

RSTP requires and even more powerful system, due to the dynamic nature of the format. It doesn't use any cache, other than that on the delivery server. The delivery server must use the correct OS and hardware/connection bandwidth, to cope with the situation.

Overall, each having their good and bad points, the system must take into account not just the actual file download in issolation, but the amount of people that are likely to view the movie at the same time (the bandwidth). Taking a 10mb file, if 10 people either downloaded it at the same time (or watched the stream in repect of RSTP), that would equate to 100mb bandwidth for just that one event. The RSTP being the heaviest load on any server delivery as it is dynamic, otherwise the movie would become choppy and heavily pixelated.

As far as SL is concerned, the best supported format (not to be confused with codex) is QuickTime MOV. SL does support other formats. The use of codex (compressor/decompressor) used within the MOV format would be relevant to the type of delivery you intend to use and is suited to the server.

Download and watch, you need a fast delivery, to negate the time spent waiting for the file to fully download, before veiwing.
Progressive download, uses less powerful delivery, as long at the initial burst is acheived via the server to fill the cache quickly, and it maintains a steady flow in line with the cache buffer. If you apply the correct settings, you should be able to make a movie that is 'throttled' to supply a steady 100kbps (or less) stream, which will not overload the SL viewer or take too much bandwidth away from the client viewer, causing the game to stall.
RSTP required a 'instantly available stream' that must maintain its connection at all times, as this type of movie can be forwarded to any point within the movie, from the moment it is switched on. Any drop in connection, will stall/freeze the movie.

This is taking into account the bandwidth required, on a commercial level.

To ascertain the 'bit rate' of a Progressive Download type movie delivery, can be found either by simple maths (file size divided by file time length=bit rate per second - kbps), or let QuickTime do it for you. Load the movie file and click Window menu, Info. It will give you the file type (codex used), file size, data bit rate, frame rate (fps), total time length of the movie/file and size. If you have a music track applied to the movie, it will give that information as well.

When using a music backing track (not voice or event sounds), you have 2 choices, let the movie or the music take presidence over the bit rate flow. That is to say, you can either allow either the music to hold back the movie if it becomes out of sync, or vice versa. If you prepare your movie correctly and have the right devliery system (server), both can be sync'd to the bit rate of both. To acheive the correct balance, use the correct codex on each element to produce a useable bit rate (music codex are different to the 'movie' content codex). Make a 'self contained' file, that doesn't rely on outsourced files.

It is possible (because we do it all the time) to 'stack' codex into a self contained movie file. Only the last applied codex will be visible in the file information. From our experiments, we have managed to stack 5 codex, giving serveral different characteristics to our movies. Get the combination right for each movie format and resolution, and you can smoothly 'stream' movies and sound tracks into the SL Cleint view, minimising the overheads to the experience. I would add, using the correct preparation of the movie to target only the correct ports to the OS is important, especially in SL.