Synchronizing Videos Over a Cluster
From Virtools Wiki
WARNING: this is a very undergoing document, it is my first real use of the VirtoolsWiki. I'm hopping to both use it as a knowledge repository for my own brain and expect to see external contributions. Let's see if sharing vs keeping things for you can be the ultimate way of going forwards
Contents |
The problem
Playing a video over a PC cluster can be achieved in many ways. This article is here to help achieve this goal the best way, and discusses the potential candidates for a solution.
General concepts
- Start and Pray
Will a video started at the very same frame behave the very same way on all machines ? Media:VideoStartAndPrayVRTest.zip is a composition to try this. Just put it in the Samples directory of your VRPack (Virtools 4.0 and up) directory Follow the comments in the cfg file, especially to put the video locally on each PC. Start the video from the master with the space bar and observe the slave 2D text indicating the current milliseconds offset compared to the master time code
I experienced a very good behavior with this Media:SampleMPegVideo.mpg file (arraound + or - 10 msec offset)
[What does it produce with other movies ? Please give feedback here]
[ TODO: do a VRNR Tools, or a simple nmo to load inside VRNav, without the VR Distribute BB]
- Frame control
Doing a Video Seek ...
- Speed control
Setting the video speed to slow or accelerate a movie so as to match the master timecode: costly solution ...
Using the (old) movie player BB
Using the new Video engine (Direct Show)
DXT streamed from disk to GPU
The idea is to convert a given movie in a series of dds images e.g myMovie0001.dds, myMovie0002.dds, ... create a multi-slot texture with each image (Texture.LoadSlotImage()) and use a Texture.SetCurrentSlot() command to make the texture show the appropriate frame (based on a shared master frame index)
Texture Save Option should be put to External, and Desired Video Format to "Compressed DXT? *"
- VideoShadow / Discard / Procedural ?
- Discard enables to have no specific limit in frame duration as images would directly go from disk to vram, but performances are very likelly to be limited by the disk, especially if an image is big
- VideoShadow provides a RAM cache to speed access time. It requires a pre-load in RAM (a priori automatically done by the SetCurrentSlot). This has the conterpart to potentially require a lot of RAM. NB: There is known OpenGL raterizer performance issues with VideoShadow mode. NB2: Mipmapping will not work in VideoShadow. One has to set the Texture MipLevels to None.
- Procedural is probably a bad idea as the image bits will have to converted from 32 bits to the vram format, and even if the vram format is 32 bits, it will be bigger than a DXT format
- Windows-based RAM disk ? A clever way to overcome the performance limitations of the Discard mode, while not facing the VideoShadow OpenGL limitations
Future low level coding
There is no doubt that the very good way to treat the problem is to use the new Video manager and replace the low level
