pix_film even at 640x360 is quite slow on my machine, pegging one CPU even at a relatively low frame rate.

I'm sure it's pix_film because it still hogs the CPU even if I remove all other pixes.

Any tricks to improve this? Should I reencode the video with more key frames, maybe?

Thanks,
hjh

"Should I reencode the video with more key frames, maybe?"

-> Yes, and usually "Photo Jpg", "Animation Jpeg" codec and those who have less time-encoded frames are more efficients. But I don't know much about codecs so maybe someone can give better advices here.

But It also depends on the plateform you are running it and the loader you use with pix_film: you can change it using "loader foo" message.

For example, on OSX I have:
[pix_film]: loader[0] quicktime4linux
[pix_film]: loader[1] AVF
[pix_film]: loader[2] image

There is a VLC plugin somewhere that could help but I don't know where.
Also this might help:
https://gitlab.com/antoine.villeret/pd-mpv

Generally when I want to have a long HD movie with a good framerate to play within pd, I use ofelia library wich is far more stable and robust than Gem now.

@60hz

Thanks for the suggestions.

The context is an interactive multimedia class where some students are using Mac and others are using Windows. So I couldn't use libmpv without a Windows build. I glanced at it but didn't see Windows build dependencies.

I tend to agree that Ofelia is more powerful than Gem, but I've tried using code in class before and it just doesn't work in this institution. They just refuse to do it. I'm afraid for the moment that I have to stick with objects. I understand that it's possible with Ofelia to do many of the standard things without code boxes, but the documentation is not to the point where I can approach it realistically (unless there's been a big documentation push lately).

So Gem it is, for now, with attendant limitations.

hjh

FWIW: The issue is keyframes. If there aren't enough of them, then (I think) moving to another frame requires pix_film to look for the preceding keyframe and render n deltas on top of that. Assuming that was the case, if you increase the number of keyframes, then the number of deltas required could be controlled.

So I just recoded part of a video so that every other frame is a keyframe: ffmpeg -ss (secs_to_skip) -i (original file).mp4 -t 20 -vcodec libx264 -an -x264-params keyint=2 (output file).mp4 and Pd's CPU usage with pix_film dropped from maxing out one core down to 9-10%.

Maybe that will help someone later.

I have a feeling, for the next iteration of this course, that I'll probably use Ofelia with your abstractions. (Edit: FWIW, performance of random frame access in Ofelia is no better than in Gem -- though Ofelia seems to use multiple threads distributed between cores. In any case, in Ofelia as well, it seems to be necessary to encode with a lot of keyframes.)

hjh