slowmotion: broken - stops after 10 secs etc. / documentation unclear

[GoogleCodeExporter]

What steps will reproduce the problem?
1. http://flowplayer.org/plugins/streaming/slowmotion.html
2. start playback e.g. at 2x speed, stops after ~ 10 secs
3. and lots of other issues, just try to play around with the demos, both fms 
and wowza, both basically do not work

What is the expected output? What do you see instead?
Expected: at least basic functionality should work
Instead: nothing "really" works.

Docs are very obscure as well. Especially the whole fps thing: Apparently it 
defaults to multiplier * 40, so that would assume a framerate of 40???

A framerate of 40 is extremely uncommon, to say the least, and it's also the 
wrong one for the demo, Extremists has an fps of 30 (iirc, have to check again, 
but certainly not 40). Is it ignored if not given? How exactly should it be 
given, just as 2nd argument or in JSON? If in JSON, what's the attribute name 
of multiplier?

Could the basic issues related to the fps thing?

Also the controlbar seems not to update correctly.

Not to speak of more subtle problems, like implementing speed changes at 
cuepoints like in this support thread:
http://flowplayer.org/forum/support.html?id=101153
(even when you leave off streams and just try with a "normal" file)

Am I the only one seeing this?

See also: https://github.com/flowplayer/site/issues/525

Original issue reported on code.google.com by blacktrashproduct on 19 Jun 2012 at 1:02

[GoogleCodeExporter]

[LOG] time 01:08:08.479 :: org.flowplayer.slowmotion::FMSSlowMotion : 
onNetStatus(): 
[LOG] time 01:08:08.481 :: org.flowplayer.slowmotion::FMSSlowMotion :   
clientid = TQt4Hxdg
[LOG] time 01:08:08.483 :: org.flowplayer.slowmotion::FMSSlowMotion :   level = 
error
[LOG] time 01:08:08.484 :: org.flowplayer.slowmotion::FMSSlowMotion :   
description = Start transmit 1 failed, invalid arguments.
[LOG] time 01:08:08.485 :: org.flowplayer.slowmotion::FMSSlowMotion :   code = 
NetStream.InvalidArg

This is the error one of the values sent from the player the server doesn't 
like. 

Original comment by electrot...@gmail.com on 19 Jun 2012 at 3:09

[GoogleCodeExporter]

I have found fms to be unreliable in two ways:
1. Playback rates (e.g. forward(.75)) are not honored, they are just 
suggestions.  Take out a stopwatch and time the playback times.  
2. Playback often just stops -- as reported in the OP on this thread.

Wowza ( http://flowplayer.org/demos/plugins/streaming/slowmotion.html ) on the 
other hand, appears far more reliable.

Original comment by jedier...@gmail.com on 19 Jun 2012 at 3:34

[GoogleCodeExporter]

wowza uses a different implementation altogether it seems, it requires a server 
connection method, and a seek command whereas fms takes a stream step command. 
obviouslly wowza is not fms. something is up with some of the values used to 
command the step action. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 8:59

[GoogleCodeExporter]

its something to do with the timers overloading flash. its doing interval 
timers to make the call to step, and seems unstable and crashed the plugin. 
possibly needs optimising. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 9:16

[GoogleCodeExporter]

http://flowplayer.org/demos/plugins/streaming/slowmotion.html wowza looks 
indeed better, but far from perfect: play e.g. fwd x 4 until the end, and try 
replay: end of fun.

Original comment by blacktrashproduct on 21 Jun 2012 at 9:55

[GoogleCodeExporter]

From the docs

"Also, the target frame must be in the buffer. For example, if the currently 
displayed frame is frame number 120 and you specify a value of 1000, the method 
fails if frame number 1120 is not in the buffer."

hence the invalid argument. trying to work out this crash first, i started 
clicking different frame rate speeds and then it happened. ive discovered a max 
pause buffer setting which may help. in fact people are complaining about 
buffer times while paused, didn't know it was configurable :O. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 10:02

[GoogleCodeExporter]

there is very little documentation out there, and it seems not many people have 
implemented it, osmf haven't even implemented it from what i can see. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 10:03

[GoogleCodeExporter]

its not stopping for me cause by the invalid frame step value, but it crashes 
after a while. will have to setup a protoype and see if its these low value 
timers producing the crash or the method itself, its not very fast, the frames 
are sticky  which suggests it only works in the buffer.

Original comment by electrot...@gmail.com on 21 Jun 2012 at 10:19

[GoogleCodeExporter]

on wowza only flv works currently i believe have to look at fms. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 10:21

[GoogleCodeExporter]

I've managed to crash the browser calling it manually via the plugin. will try 
on wowza

Original comment by electrot...@gmail.com on 21 Jun 2012 at 11:26

[GoogleCodeExporter]

no stopping or crashing in safari. it will stop skipping until the buffer has 
caught up so its skipping within the available buffer. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 11:36

[GoogleCodeExporter]

demo is still producing the same results, can't replicate it locally but I 
think some things needed to be tweaked, its calling pause for each time the 
button is pressed which might have to prevent that. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 11:39

[GoogleCodeExporter]

slowmotion is perfectly fine because its slowed down that much by only skipping 
1 frame, the buffer is keeping up, fast forward is a problem when it passes the 
buffer and its trying to keep up so the timer might need to be paused during 
these stages. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 11:46

[GoogleCodeExporter]

http://openvideoplayer.sourceforge.net/ovpfl/samples/as3/index.html this uses 
the mousedown approach so once its lifted off the timer stops. this makes more 
sense. there is no possible way to stop it on the controlbar.

Original comment by electrot...@gmail.com on 21 Jun 2012 at 12:30

[GoogleCodeExporter]

OK from what others are doing mousedown trick play, mouse up normal play, and 
the last gotcha, if its going to fast close to the bufferlength the trickplay 
stops and resumes normal play. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 1:34

[GoogleCodeExporter]

Can resuming normal play be an option?  The other option being to pause and 
wait on the buffer to fill up again.  I hope this is possible.

Original comment by jedier...@gmail.com on 21 Jun 2012 at 1:41

[GoogleCodeExporter]

i lost my message by some timeout ! 

1) controls mouse down / up starts /stops trick play
2) for javascript controls the timer will keep going so stopping for the buffer 
seems to help but the frame keeps stopping and starting which may be 
undesirable. perhaps the same code has to happen for the javascript controls 
also. anything more than 2 as a multipler is crashing flash still for some 
reason in chrome. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 2:04

[GoogleCodeExporter]

ok from the docs this feature is doing an internal seek of the buffer on the 
client, if it reaches the buffer it requests the server for more data with a 
normal seek, this is where the problem is occuring on cloudfront anyway. still 
finding a solution. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 2:32

[GoogleCodeExporter]

Customer:

"It would be a show stopper for me if the fast-forward / slow-motion control 
was only settable by mouse interactions. Went with your tool because of the JS 
API to those functions."

http://flowplayer.org/forum/support.html?id=101153

Original comment by blacktrashproduct on 21 Jun 2012 at 3:13

[GoogleCodeExporter]

Hi I dont know where he got that information from ? 

https://dl.dropbox.com/u/3394987/flowplayer.rtmp-3.2.10.zip
https://dl.dropbox.com/u/3394987/flowplayer.slowmotion-3.2.1.zip

Possible to test ?, there was alot of possible work arounds, I have not forced 
it to begin normal playback if it reaches 0.1 of the buffer like other players 
have done, I've made it step 1 frame instead and it will continue as normal 
after, I initially had made it stop until some buffer has filled and start 
again but that might be undesirable also ? well the whole point is stepping 
frames within the buffer so that could be an option. 

In the off chance the error above is happening due to a bad internal seek 
command to the cloudfront fms servers in particular because its not in the 
buffer it will begin normal playback. Not much information on the error at all 
though someone else complained to amazon about it and they didnt respond.  

I think its also a better idea to have it on demand with the controlbar buttons 
so mouse down and mouse up as there was no way to stop the stepping timer. I 
would as an example make the javascript controls do the same thing , mouse down 
do the stepping, mouse up normal play.

 There is also a hidden keyboard command that is not documented, control-l and control-r. 

Original comment by dani...@electroteque.org on 22 Jun 2012 at 5:55

[GoogleCodeExporter]

let me know if this fixes your issues before I can commit. 

Original comment by dani...@electroteque.org on 25 Jun 2012 at 1:30

[GoogleCodeExporter]

please hold i just realised the sources were failing to update so i had to 
merge my changes, there is still an issue i am seeing resuming the stream when 
playback is normal which is possibly related to the rtmp plugin. 

Original comment by dani...@electroteque.org on 26 Jun 2012 at 9:37

[GoogleCodeExporter]

https://dl.dropbox.com/u/3394987/flowplayer.slowmotion-3.2.8.zip please try 
this, the control buttons are on demand mouse down / up. normal playback begins 
on the error above still, stepping is slowed down if it passes the buffer 
regions to allow it to catch up instead of normal playback. 

Original comment by dani...@electroteque.org on 26 Jun 2012 at 11:28

[GoogleCodeExporter]

Possible to check the stability of this now ? there is an obvious change with 
the controls and think it might be more suitable like this. 

Original comment by dani...@electroteque.org on 2 Jul 2012 at 3:30

[GoogleCodeExporter]

Ive fixed the stability issues, the stopping on FMS etc. Wowza actually 
performs better is uses a completely different communication method to provide 
the feature though. As for the forum reference, no issue was replicated setting 
the speed within cuepoints. The buttons have changed however but think it works 
better like this, the javascript api is the same as usual. closing for now. 

Original comment by dani...@electroteque.org on 2 Jul 2012 at 5:59

• Changed state: Fixed