Miguel

I'm working in a project for reactive cinema and am having a problem.

Basically it is a short film that has alternate scenes which are selected in real time based on audience's response.

We are using large files, full uncompressed 1920 1080 25fps Quicktime RLE .mov. It plays well each of the scenes but when changing from one to the next there is a noticeable stutter of about half a second in the video.

The video runs on a dedicated (and rather powerful) PC running the patch in the runtime environment. It only gets OSC messages to change the clips.

I would like to know if there is any way I can optimise my patch to get frame accurate playback with such large files.

 I'm working in a project for reactive cinema and am having a problem.
Basically it is a short film that has alternate scenes which are selected in real time based on audience's response.

jitter-playback-of-huge-files

1-Maybe you can start by playing with different codecs. If you have access to FCP maybe you can try ProRes, i have a rather good experience with it. Also check if you need the alpha channel of your files.

2-try to avoid using two metros. better have just one and distribute your bangs accordingly.

3-try to move your rendering to videoplanes using the openGL objects in jitter(jit.gl).

4-optimize your play back with Vade's nice tips:

5-maybe it would be a good idea to enable the adapt attribute on your qt players

6-are you crossfading between files or they are played consecutively? use a umenu object with pointing to your source folder and enable the autopopulate attribute. Link the list with a prepend read.

Hey Miguel:
1-Maybe you can start by playing with different codecs. If you have access to FCP maybe you can try ProRes, i have a rather good experience with it. Also check if you need the alpha channel of your files.
2-try to avoid using two metros. better have just one and distribute your bangs accordingly.
3-try to move your rendering to videoplanes using the openGL objects in jitter(jit.gl).
4-optimize your play back with Vade's nice tips:
http://abstrakt.vade.info/?p=147
5-maybe it would be a good idea to enable the adapt attribute on your qt players
6-are you crossfading between files or they are played consecutively? use a umenu object with pointing to your source folder and enable the autopopulate attribute. Link the list with a prepend read.

1- I have suggested recoding the files but the producer and director are quite keen in not doing so. They hired some really expensive camera for the shooting and want to see it at its full resolution. Will try playing around with ProRes and see if they notice the difference.

3.- Is there any real gain? I always thought that using openGL helped mostly for operations in matrixes. Didn't think it would make a difference for straight playback.

6.- No crossfades, just jumping from one video to the next. I have message boxes on the patch linking to the files which are in the same folder. I couldn't post example of the videos for obvious reasons (The smallest scene is 13 seconds long and 700Mb)

 Wow, thanks for your input.
1- I have suggested recoding the files but the producer and director are quite keen in not doing so. They hired some really expensive camera for the shooting and want to see it at its full resolution. Will try playing around with ProRes and see if they notice the difference.

Test the codecs. I can imagine that the filmmaker would love to see his footage as good as possible, but codecs can be the bottle neck of things like this. Check the alpha channels, those can be really heavy.

The gl objects can help you to optimize the performance as you will be using the GPU: movies will be passed as textures and bound to a geometry, in this case a plane. That will be a huge relief for your cpu(which is the one managing the loading of the movies).

If you are only using one context to render you really don't need two video players(as you are mentioning there are not crossfades between the files). In the case you want to keep both qt players stop banging the one you are not using.

Read the Vade's optimization page, it can give you good pointers of how to use some slabs to improve your performance.

Option w, if your main concern is to have an optimized movie player you can try to wrap your own player and send osc messages to it(there are some nice c++ toolkits for such thingies). In my own experience I had some bad moments optimizing jitter for this kind of tasks.

Hey Miguel:
Test the codecs. I can imagine that the filmmaker would love to see his footage as good as possible, but codecs can be the bottle neck of things like this. Check the alpha channels, those can be really heavy.
The gl objects can help you to optimize the performance as you will be using the GPU: movies will be passed as textures and bound to a geometry, in this case a plane. That will be a huge relief for your cpu(which is the one managing the loading of the movies).
If you are only using one context to render you really don't need two video players(as you are mentioning there are not crossfades between the files). In the case you want to keep both qt players stop banging the one you are not using.
Read the Vade's optimization page, it can give you good pointers of how to use some slabs to improve your performance.
Option w, if your main concern is to have an optimized movie player you can try to wrap your own player and send osc messages to it(there are some nice c++ toolkits for such thingies). In my own experience I had some bad moments optimizing jitter for this kind of tasks.


can you make it into one huge file and jump frames? that's way better in my experience. loading any new file into jit.qt.mov causes a bit of a pause.

there are tricks you can do with a single file to get an xfade effect, jit.xfade into itself with a speedlim delay, or jit.slide.

Jitter Playback of huge files