| Reference | Downloads | Github

Loading times for routines with videos are slow

Win 10 (e.g. Win10):
PsychoPy version 2021.1.4
Standard Standalone

Psychopy takes a while (3 or more seconds) to load routines where there’s a movie stimuli. This happens all the time, particularly in the first trial of a loop. Basically, when a loop has a routine with a movie and a routine with a response screen, the transition from the response to the movie routine is slow. There is a freeze for around 2/3 seconds in the response screen until Psychopy can load the movie routine. This leads to the movie being cut short from its 3s presentation to 2 or less seconds (sometimes even skipping the movie entirely and going straight to the response screen routine). The movie stimuli are all .mp4 and have only ~400kb. Plus they are set to start 1 second after the movie routine has initiated.
Upon inspecting I was able to isolate the problem to the “set every repeat” option in the movie object. For instance, if using a unique movie file and select “constant” in the movie object, there is no problem loading the routines. However, if I again use the unique movie file but select “set every repeat” there is loading times of around 3 seconds and skipped frames in the movie routine as explained above.

Of note, this happens in some computers but not others. However, it has nothing to do with the computers capability (powerful computers can struggle while less powerful ones run the experiment perfectly well).

I’ve tried many solutions, including changing movie format, changing movie backend, resolutions, sizes, etc.


if you set the movie to constant, it will be preloaded at the beginning of the experiment. Thus no delay in the movie-routine.

You could insert an ISI-component at the beginning of the relevant routine. This ISI-component should last as long as the loading usually takes. Then you select the option to load a particular movie during this ISI-period. There should be no other components starting or running during the ISI-period. Do not limit the movie-duration. Limiting the movie-duration (stop-time) results in cutting the movie short if the start was delayed. Simply insert a value in the expected duration field.

Best wishes Jens

Hi Jens

Thanks immensely for the feedback. So I tried your suggestion but it didn’t seem to help much. I inserted a ISI of 1s between response routine and video routine and it takes around 5s (1s is of the ISI, the rest is loading) for the video routine to begin. I ended up trying a 3s version of the video file (instead of the original one which had 10s and I asked psychopy to stop at 3s) and it now doesn’t skip any frames nor does it skip to the response routine, which is an improvement. It is now forced to show the video. However, it still takes a considerable (~5s, although just 1s ISI is asked) for the movie routine to start each trial.

Hello Falexs,

you could implement a longer ISI if experimental considerations do not prevent this. Five seconds for loading seems rather longer to me. Loading a 30 second long video took about 2-3 seconds on my five year old laptop. Notice that rescaling the video inside PsychoPy takes some time. So, it is best to have the video in the format you intend to use.

When do your participants may respond? After the video? In this case you can bind the onset of your response to the offset of the video:


Best wishes Jens

Hi again,

Unfortunately they do, since i want to keep the time between trials (a trial being a video routine plus a response routine) around 2s. Actually, if i compare a 2s ISI between trials to no ISI between, the time between trials is actually less in the no ISI condition. So it doesn’t appear that the ISI helps loading the video.
The participants will respond right after the 3s of the video. That is an interesting solution, but unfortunately does nothing for the loading times between trials.
It really seems to be a problem with moviepy handling the video, but cannot understand with this is the case.
As for the loading times, we actually get better performance in lower end computers for some odd reason.
Thanks for these new ideas anyway :slight_smile:.