processing-video
processing-video copied to clipboard
Video speed not working, reverse direction not working
Hi, I am on MacOs Yosemite, Processing 3.2.2 I can not get the Movie.speed() function to control speed or to reverse the direction. I am running the example from the docs
import processing.video.*;
Movie myMovie;
void setup() {
size(200, 200);
frameRate(30);
myMovie = new Movie(this, "totoro.mov");
myMovie.speed(4.0);
myMovie.loop();
}
void draw() {
if (myMovie.available()) {
myMovie.read();
}
image(myMovie, 0, 0);
}
but the player seems to ignore the call to Movie.speed() no matter what movie I feed into it. does it have to do with the video format, is there a video format that would work? I tried different formats (including theora) and the call to Movie.speed() seems to always get ignored.
I have seen a precious issue about this (https://github.com/processing/processing-video/issues/16) that sees to mark it as resolved but it is definetely not working for me. Thanks for any help sergio
Is it maybe related to the version of Gstreamer? I am not sure of how Processing handles the video... does it rely on system Gstreamer or does it have its own Gstreamer version? http://gstreamer-devel.966125.n4.nabble.com/Reverse-Playback-in-V1-0-td4665354.html
Possibly related issues?
- #7
- #16
- #17
There's a problem with the sample code on the Processing website--when I changed the order of the speed and loop lines, speed suddenly started working for me.
So instead of
void setup() { size(200, 200); frameRate(30); myMovie = new Movie(this, "totoro.mov"); myMovie.speed(4.0); myMovie.loop(); }
You're going to want to switch the last two lines (or maybe just make sure speed always comes last, like so)
void setup() { size(200, 200); frameRate(30); myMovie = new Movie(this, "totoro.mov"); myMovie.loop();
myMovie.speed(4.0); }
Hope this helps.
I have had problems running the Reverse example for the Video library on a machine running OS X 10.12.4. It seems to freeze without errors about 6 seconds before the start of the video.
Hi guys,
Have been playing around with reverse video playback and looping.
Found the following notes:
- check that video is actually available and playing before calling mov.jump()
- avoid setting speed = 0.0 (gstreamer error)
- before calling mov.jump() set speed to positive value, after .jump() restore speed
- skip some frames before calling mov.speed() again. otherwise gstreamer errors pop up and framerate drops.
At least these steps worked for me as a workaround with Processing Video library Release 3. https://github.com/processing/processing-video/releases/tag/r3-v2.0-beta1
Working example attached on the forum: https://discourse.processing.org/t/movie-library-reverse-video-looping-example/11963
Best, Arne.
@arneboon @kellyegan @emilyj0y @jeremydouglass @smarques Do you still experience errors with reverse playback using latest beta?
@codeanticode will try and let you know. Thank you!
I added the latest video beta linked above to Processing 3.4, restarted, and ran the example Video > Movie > Reverse. The sketch displays a static image but keeps running without crashing after dumping this warning text on the first frame:
(Processing core video:12383): GStreamer-WARNING **: 10:35:51.441: Failed to load plugin '/Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx/gstreamer-1.0/libgstpango.dylib': dlopen(/Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx/gstreamer-1.0/libgstpango.dylib, 2): Library not loaded: @loader_path/libexpat.1.dylib Referenced from: /Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx/libfontconfig.1.dylib Reason: Incompatible library version: libfontconfig.1.dylib requires version 8.0.0 or later, but libexpat.1.dylib provides version 7.0.0
(Processing core video:12383): GStreamer-WARNING **: 10:35:51.522: Failed to load plugin '/Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx/gstreamer-1.0/libgstrsvg.dylib': dlopen(/Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx/gstreamer-1.0/libgstrsvg.dylib, 2): Library not loaded: @loader_path/libexpat.1.dylib Referenced from: /Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx/librsvg-2.2.dylib Reason: Incompatible library version: librsvg-2.2.dylib requires version 8.0.0 or later, but libexpat.1.dylib provides version 7.0.0 Processing video library using GStreamer 1.16.0
When I restore Video 1.0.1 restart, and run the Video > Movie > Reverse example, it runs "transit" for several seconds, then the frame playback freezes without errors.
The sketch is still running and drawing -- if I add a mouse cursor or ellipse, for example, it displays and is interactive, but the movie frame is always the same frame. This is true for the new example as well -- the returned frame is frozen, but the sketch is still running and fully interactive.
Cool, thanks for the report. What happens if you install the latest GStreamer package for Mac available in this page? (the video library will override the bundled version oft he GStreamer libs if it finds a valid system install)
I've got GStreamer 1.16.0 installed via homebrew, just re-updated it.
190828 Reason4:~ $ brew info gstreamer gstreamer: stable 1.16.0 (bottled), HEAD Development framework for multimedia applications https://gstreamer.freedesktop.org/ /usr/local/Cellar/gstreamer/1.16.0_1 (420 files, 22.9MB) * Poured from bottle on 2019-08-28 at 10:59:28 From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/gstreamer.rb
When I reinstalled video beta, it still prints the same error msg and Reverse still showing a single frozen frame of launch2.mp4.
Ok, I will look into it :-)
Just to double check, if you add the following line to the end of setup:
println(Video.gstreamerLibPath);
what do you get in the Processing console?
/Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx
So it looks like it is not picking up the gstreamer install from homebrew... probably because is not in /Library/Frameworks/GStreamer.framework/ (which is where the GStremer installer copies it to
You can set the environmental variable GSTREAMER_1_0_ROOT_X86_64 to point to the root of homebrew's GStreamer installation, and then run Processing again.
Okay.
GSTREAMER_1_0_ROOT_X86_64=/usr/local/Cellar/gstreamer/1.16.0_1/; open -a Processing
When I run the Reverse sketch, the sketch displays the same initial frozen frame, and the same warnings about plugins in the local Processing library install -- the error paths don't change.
(Processing core video:23837): GStreamer-WARNING **: 12:08:55.616: Failed to load plugin '/Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx/gstreamer-1.0/libgstpango.dylib': dlopen(/Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx/gstreamer-1.0/libgstpango.dylib, 2): Library not loaded: @loader_path/libexpat.1.dylib Referenced from: /Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx/libfontconfig.1.dylib Reason: Incompatible library version: libfontconfig.1.dylib requires version 8.0.0 or later, but libexpat.1.dylib provides version 7.0.0
(Processing core video:23837): GStreamer-WARNING **: 12:08:55.630: Failed to load plugin '/Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx/gstreamer-1.0/libgstrsvg.dylib': dlopen(/Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx/gstreamer-1.0/libgstrsvg.dylib, 2): Library not loaded: @loader_path/libexpat.1.dylib Referenced from: /Users/jeremydouglass/Documents/Processing/libraries/video/library/macosx/librsvg-2.2.dylib Reason: Incompatible library version: librsvg-2.2.dylib requires version 8.0.0 or later, but libexpat.1.dylib provides version 7.0.0 Processing video library using GStreamer 1.16.0
However if I set GSTREAMER_1_0_ROOT_X86_64 to a bad directory instead of my brew install it also prints the exact same local plugin warnings, but I get a black screen instead of a frozen frame.
Note: I also tried
brew install gst-plugins-base gst-plugins-good
just in case. Still no change.
mmmh, looks like the path setting mechanism needs to be revised as well :-) Thanks for the updates!