ofVideoPlayer bug with setSpeed (006_linux_cb)

I tried the new OF version with gstreamer under linux and it seems that there is a bug with the setSpeed method of the ofVideoPlayer.

To reproduce the bug you only have to extend the moviePlayerExample with a simple setSpeed(1.0) in the update and comment the other setSpeed in the mouseMoved method:

  
void testApp::update(){  
  fingerMovie.setSpeed(1.0);  
  fingerMovie.idleMovie();  
}  

I would expect that nothing will change, but the movie go slower or jumps or stops.

Is this normal?

,Seven

i’m afraid it’s normal.

i even contacted the gstreamer dev-list and the answer was:

How responsive it’s going to be is a function of the pipeline mostly.
You might want to check out the ‘scrubby’ example in
gst-plugins-base/tests/examples/seek/scrubby.c - it does pretty much
what you’re looking for.

There has been some discussion of how we might perform
rate-changes-that-don’t-change-the-playback-direction more quickly, but
nothing has come of that yet.

J.

the usual way of changing speed in gstreamer, the method they use in the scrubby example, was indeed much less responsive that what i have now, by resetting the position everytime you change the speed i managed to make it a little bit more responsive but changing it in every frame is too much. if you set a lower frame rate things get a little better but not too much.

ok maybe my example was a little bit to extrem. I only want to change the speed by mousePressed or some other event. But with the gstreamer under ubuntu it first pause the movie instead of slow down the speed. Only after a few seconds the movie plays again (at least with the correct speed).

I think there is a relation between this two bugs.

do you mean something like:

  
  
void testApp::mousePressed(int x, int y, int button){  
        int width = ofGetWidth();  
        float pct = (float)x / (float)width;  
        float speed = (2 * pct - 1) * 5.0f;  
        fingerMovie.setSpeed(speed);  
}  

for me it works instantaneously, at least with the example movie. perhaps depending on the format of the video u are using it can be a little bit less responsive.

Ok arturo you are right!
There is only a problem with one of my own example movies. The format differs from the fingers.mov. But now I noticed, that other movies with the same format works. So I hope this one movie is only an exclusion.

Thanks for your time arturo.

,Seven

[quote author=“arturo”]do you mean something like:

  
  
void testApp::mousePressed(int x, int y, int button){  
        int width = ofGetWidth();  
        float pct = (float)x / (float)width;  
        float speed = (2 * pct - 1) * 5.0f;  
        fingerMovie.setSpeed(speed);  
}  

for me it works instantaneously, at least with the example movie. perhaps depending on the format of the video u are using it can be a little bit less responsive.[/quote]

Hi,

I see this problem even in the moviePlayerExample without changing it a bit, and with the “finger” movie included in it. (in Ubuntu)

I’m not sure whether this is a matter of responsiveness, or if the problem is, that every time you change the speed the “fraction of a frame” that has been “travelled” since the last update is “lost” (that is, the current position is “reset” to the integer value of the current position in frames).

Anyway the result (in the example) is that if you continuously move the mouse (even by little-but-continuous movements within the “fast speed” zone), the movie plays much slower than it should. It’s almost still.

This is practically the same test as in the original post, but actually with the finger.mov.

Yes thats normal in linux, if you change the speed or the position continously in every frame gstreamer cant handle it. Also theres a difference with win/osx, in the mouse callbacks. In linuz you receive as many as your mouse resolution. About 150/sec so its even worse than doing it every frame.

You can try storing the speed/position in a variable and setting it in the update function once every two frames for example to see if that helps.

[quote author=“arturo”]Yes thats normal in linux, if you change the speed or the position continously in every frame gstreamer cant handle it. Also theres a difference with win/osx, in the mouse callbacks. In linuz you receive as many as your mouse resolution. About 150/sec so its even worse than doing it every frame.

You can try storing the speed/position in a variable and setting it in the update function once every two frames for example to see if that helps.[/quote]

I’ve tried storing the speed in a variable and setting it in the update function once every SINGLE frame, and it doesn’t help (i think it’s the same issue as described in the original post).
Setting it every two frame wouldn’t be a solution.

Correct me if I am wrong, if gstreamer can’t handle one change of speed per frame (even multiple changes of speed per frame imho) then there is a bug somewhere, no?
Even if you change the speed only every once in a while, every time you do it an error (perhaps small) will be introduced in the video position.

Otherwise, how do you control speed in a precise and reliable way?

thanks
m.

yes, it takes a bit to change the position so if you need something super accurate, perhaps its not doable. if you want to control the speed though it’s better to use setSpeed instead of trying to control it externally by setting the position very fast.

the problem is your not controlling directly the position but sending messages to gstreamer that are stored in a queue and attended whenever it’s possible since gstreamer runs in it’s own thread.

what are you trying to do btw? perhaps there’s a different solution that will work.

[quote author=“arturo”]yes, it takes a bit to change the position so if you need something super accurate, perhaps its not doable. if you want to control the speed though it’s better to use setSpeed instead of trying to control it externally by setting the position very fast.

the problem is your not controlling directly the position but sending messages to gstreamer that are stored in a queue and attended whenever it’s possible since gstreamer runs in it’s own thread.

what are you trying to do btw? perhaps there’s a different solution that will work.[/quote]

Hi Arturo, muchas gracias for your interest.

Indeed I was just playing around. At this very moment I’m not trying to do anything special, just getting familiar with OF and the libraries.

But I am interested in controlling video playback in a “super accurate” way. I know that’s possible because you can do that with PureData + GEM. Up to now GEM is the most accurate software I’ve ever seen as far as playing back video is concerned (at least with some codecs), even much more accurate than most popular VJ tools (which surprised me a lot, since I thought that for VJing, a 100% accurate control of video playback in order to sync it with music was of primary importance - but then I’ve realised that most VJs don’t give a sh** about it).
Obviously from time to time you do get some unwanted delay in GEM, if a disk acces takes longer than expected, or if CPU load is high etc, but it then readjusts itself as soon as it can, so error don’t accumulate. It can take several minutes until you accumulate an error of 1 frame.

Maybe ofVideoPlayer is not the right object to use for this kind of accurate video playback? If I understand correctly, you said that even controlling directly the position (and computing the speed externally) wouldn’t help, right?
What are the alternatives?

(but now that I think about it, I think you told me in another occasion that OF’s frame timing itself is not very accurate, so probably it’s not even a matter of what library you use to stream video…¿?)

thanks again
m.

One thing you might try is the same video file but with different codecs.

One thing I’ve found is that video playback on the different platforms tends to perform better when using a codec common or native to that platform.

Try encoding using a range of native linux codecs and see if you get a better result if you haven’t done so already.