Latency when Interactively Loading Movies? Information + Tips from Mark
A user asked a question about latency when loading movies interactively via MIDI, and I wrote a quite detailed response. I'm placing that response here as a reference.--------------------BackgroundThere is always some latency when loading a movie; depending on the file format and resolution this can range from a 50 mS to a couple of hundred mS. This is because the operating system needs to
This process – commonly referred to as "Preloading" and/or "Prerolling" – is not instantaneous and is unfortunately not optional.To see what I this in practice, try this experiment: load a 1080p movie into QuickTime Player and press the space bar to make it play. You'll clearly feel the delay from the time you press the space bar until the movie actually starts playing.The codec can make a big difference. For fastest response, you'll want to use Photo JPEG, DV-NSTC/PAL or Apple Pro Res (on Mac OS) or WMV files encoded with Photo JPEG or DV (Windows), as these eat up the least time when the system decodes the first few frames. Any codec with a variable bit rate capability (e.g. H264 and MP4) will be noticeably slower.One hardware note: this preloading process is one place SSD drives can make a big difference.Testing LatencyI've attached a test file that will measure the latency called latency-test.izz.The first scene uses the new, v2.0 Movie Player. In case you aren't an early adopter who has purchased the 2.0 upgrade, you can use the second scene, which uses the v1.0 Movie Player. You'll need to import a clip in the media bin to try this file; it should be the first clip in the first video bin.Just activate the scene, and press the letter 'a'. Then look at the output of the Timer actor to see the amount of time that passed from the moment when you pressed 'a' and when the first frame of the movie arrived.On my setup (2 GHz i7 Mac Book Pro, standard 5400 RPM drive) loading a 320x240 Photo JPEG movie took between 50 and 83 mS. Loading a 720x480 DV clip took about 250 mS. The Classic Movie Player (1.x) was slower, about 100 mS (320x240) and 390 mS (720x480).One SolutionCurrently, the only way to really a movie respond instantaneously is to have one movie player and one projector for each movie you want to play. The movies would all initially have a speed of 0, but they would be loaded into memory. Your MIDI trigger would set it to 1, causing the movie to play. But we would also need a system to turn off the other movies.I've created an example patch with a User Actor that implements this idea -- it's called "multi-movie-player.izz". Double click the User Actor to see the actors inside. There are lots of comments to make the functionality clear. For your application, you would want to replace the "Keyboard Watcher" actor with a Note On Watcher, or a Control Watcher -- or whichever MIDI "Watcher" actor applies to your situation.The trickiest bit is using the Broadcaster actor to send a message to all the user User Actors to tell them to stop playing before the new movie plays. But other than that, it's pretty straight ahead.
- Open the Movie File & Determine which codecs are being used (both video and audio)
- Load the necessary codec "drivers" into memory if they are not already loaded
- Load the first 1/2 second (approximately) of video into memory and decode all the frames
something is not working for me in your latency test project, in the Izzy v201 version.
I hope I'm doing it right, I understand the reset/run and the pause trigger, problem is that the PAUSE trigger in the NewMoviePlayer is not working in my computer while the ClassicMP does work, showing anything from 0 to 0.06 seconds. (internal 1 TB Crucial M550 SSD)
Hi,contrary to the classic movie player the new one only triggers when there is an output, so 'force stage preview' should do the trick.bestr
Yes, all the GPU based stuff needs a "context" (the Stage window) in which to render, or else the movie can't play the video part. So you must show the stage for the trigger output to work.