Hi,
The 2nd version looks much better
.
I only commented about the use of Fraps or HyperCam for capture, as I saw the movie in full screen, which wastes a lot of HD space and data with needless screen information.
The reason I use HyperCam, is it allows me to capture in avi format, which is a raw data format, meaning when I use my editing programme, I am dealing with the best possible data quality. The last time I looked at Fraps, it could not save in that format, only with a codex which had crude settings, which reduces the raw data to work with, unless that has changed?
I am not sure if you are producing the movie to show ingame? If you are, then the resolution would be way to high, to successfully stream at less than 100kbps. All our (WBA) calculations for acheiving our media for streaming ingame are done on the basis of many hours of time spend taking readings of impact on the client and systems, when movies are running. Our goal is to acheive the highest possible quality within a 100kbps data rate stream. Acheiving high quality is a priority as this allows us to scale the movie size to compensate.
Using a careful balance of resolution and colour bit, application of masks in the editing stages to acheive quality, reduces the need for over zealous use of codex. A good sharp quality movie at 360x240 can be scaled ingame to 7200x4800 screen size and still stream at less than 100kbps.
The other thing to take into consideration when using codex, is at some point, the viewers system will have to decompress that stream. It is one thing to ram it onto their system using high compression ratios, but the trade off is in computer power to decode it. In our tests, over usage of codex settings, caused a greater lag effect than perhaps a lower setting/type codex, in addition the UpdateImage stresses on the client became more evident with highly compressed movies.
As you are using a realitively static movie material, you can also make gains by reducing the fps of the output movie format. The human brain can deal quite well with 20fps and even 15fps as long as there isnt too much high speed movement that will cause blurring and defeat the object. One of the problems with movie capture in a internet environment is the dynamics of the intermediate internet connection. Fps vary quite dramically, scenes can go from 15-40fps in the blink of an eye. If you try capturing at 20fps when your rendering speed of the client drops to 15, you will have 'holes' in the movie. Some editing programmes (like the one we use) can 'tween' frames but only over a very short space of time without causing blurring and added artifacts like an additional arm or leg
in the transition, which is acsenuated by the codex compression routines. I use a series of keyframes at low frame points, to try and 'guide' the programme through those stages. For the most part, my ingame fps is usually above 40+ so I dont have to do that extra work very often. Making movies in a stable sim helps a lot, with more predictable results. You might try doing work at over 600mtrs high where lag is potentially lower.
One last thing that may help you in some way, forget using RSTP unless you want to protect your media (no cache download to steal), the overheads to the movie and adjacent data streaming alongside the clients hungry mouth, are just too high and prone to stalling, not to mention the bandwidth used, even with those deals from the likes of DreamHost. Try using 'Progressive Downloads' (watch as it downloads). At least that way, once the viewer has seen the movie once, it will be stored in the systems cache, so the 2nd time will appear much smoother, as the decoding process would have already been done and the frames (stored as a series of jpgs) would have fully rezzed. The whole thing would appear sharper. Another reason for not using RSTP to stream, is that without any form of cache, the addition of a sound/music track, will always stall the movie should the sound track lag, it is the sound data rate (within the codex) which will determine the speed/progress of the movie.
