New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pix_film on Windows does not allow playback to be restarted with auto message. #163

musger opened this Issue Nov 15, 2017 · 3 comments


None yet
2 participants

musger commented Nov 15, 2017

Loading somefile.avi into [pix_film] on Win10 and sending the [auto 1< message will start playback. When playback is stopped with an [auto 0< message, it is not possible to restart it with [auto 1<.
Re-opening the file does not help. Explicitely setting a frame number prior to [auto 1< does not help.

@umlaeute umlaeute added the bug label Nov 16, 2017

@umlaeute umlaeute added the help wanted label Dec 5, 2017


This comment has been minimized.


umlaeute commented Dec 5, 2017

given that this is backend-specific, we'd need to know which backend you were actually using to play back the film?

@umlaeute umlaeute removed the help wanted label Dec 5, 2017

@umlaeute umlaeute referenced this issue Dec 5, 2017


make filmDS consistent #180

0 of 7 tasks complete

This comment has been minimized.

musger commented Dec 19, 2017

How do I find out which backend I am using? Upon loading my videofile into pix_video Pd/Gem prints on the console:
[pix_film]: DirectShow support
[pix_film]: QuickTime support
Image loading support: QT SGI jpeg tiff
GEM: GLEW version 1.5.4
GEM: Start rendering
[pix_film]: opening C:/vid/somefile.avi with format 1908
[pix_film]: loaded file: C:/vid/somefile.avi with 464 frames (320x240) at -1.000000 fps


This comment has been minimized.

musger commented Dec 19, 2017

Some more observations:

Starting playback with [auto 1< and then stopping playback with [auto 0< and starting again with [auto 1< will not always start from the position where it was stopped. Sometimes it will display a black frame even. When an [auto 0< is sent then, a still frame is displayed.

Sometimes selecting frame number 1 using the right inlet and sending [auto 1< will not start playback. The rightmost outlet then bangs with the framerate.
Now selecting [auto 0< will display a still frame from the video which is not the first frame. Pressing [auto 1< again, will turn to a black screen and will let the rightmost output bang with the framerate.
This can also be oberved when a video is played to/beyond its last frame and [pix_film] is sent an [auto 1< message, playback will not restart (this is consistent with the help patch explanation) but pressing [auto 0< will display a still frame.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment