seek onStart does not work with httpstreaming

[GoogleCodeExporter]

What steps will reproduce the problem?
1. http://flowplayer.blacktrash.org/test/httpstreaming.html
2. clip: {
     onStart: function () {
       this.seek(20000);
     }
   }

What is the expected output? What do you see instead?

Expected: seeks to position onStart
Instead: spinning buffer animation

Seeking onStart should work with every streaming protocol.

Original issue reported on code.google.com by blacktrashproduct on 15 Apr 2012 at 12:49

[GoogleCodeExporter]

Hi expected i'm afraid is very general. This is an OSMF feature, there is no 
such example out there i'm afraid trying to do this. The standard way made 
available is the start time which is what is designed into the feature and 
obviously works. Again there is no advertised feature saying it can do this so 
people are on their own really. 

onStart: function () {
            setTimeout(function() {
                $f("player").seek(20);
            }, 1000);

        },

This seems to work, so giving it a delay to run the seek. 

Original comment by dani...@electroteque.org on 15 Apr 2012 at 2:05

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Oops, made a mistake wrt seek argument (should have been 20 instead of 20000) - 
seconds instead of milliseconds.

Updated http://flowplayer.blacktrash.org/test/httpstreaming.html

Then: seeking works without timeout, BUT! the playhead starts at 0, so you get 
the buffering animation when you try to scrub to the end of video.

wrt being too general: seek should work once the player is in paused or playing 
state, which is with onStart. Examples like 
http://flowplayer.blacktrash.org/chapters.html are often asked for. And ui-wise 
there is no reason why it should not work. We can't offer an api and then say: 
sorry, folks it's actually a lottery.

The whole thing about using a streaming protocol is that one is able to seek to 
unbuffered portions of the video. And that is advertised clearly and 
prominently.

Original comment by blacktrashproduct on 15 Apr 2012 at 3:05

[GoogleCodeExporter]

So it works ? It needs a timeout for this so once it gets some fragments. YES a 
lottery , it is not designed to do such things apart from the start property, 
and not possible to go hacking the internals, it is what it is, this is an OSMF 
feature. Ui is completely different to the internal functions, if it can't do 
it it cannot do it, and it's not advertised to do it ;)

It works for me, I don't understand what the issue is now. What is happening 
here is a hack really, the start property is the standard way, and functions 
properly.

onStart: function () {
            setTimeout(function() {
                $f("player").seek(20);
            }, 250);

        },

This is the shortest possible timeout setting or else it fails to initiate the 
seek. 

Original comment by dani...@electroteque.org on 15 Apr 2012 at 3:23

[GoogleCodeExporter]

I'm able to seek on startup outside of flowplayer so it's an api issue 
somewhere. 

Original comment by dani...@electroteque.org on 15 Apr 2012 at 3:43

[GoogleCodeExporter]

eeek, it is seeking fine, but the netstream time does not update to the correct 
time ! will keep looking. 

Original comment by dani...@electroteque.org on 15 Apr 2012 at 4:18

[GoogleCodeExporter]

There is a "bug" in the internal functions where the initial time becomes the 
seek start time therefore 20-20 == 0. 

Original comment by dani...@electroteque.org on 15 Apr 2012 at 4:42

[GoogleCodeExporter]

For the last time: the `start' property is something different than the 
`onStart' event. `start' shortens the video duration, seeking does not. Don't 
tell me I am demanding something completely obscure here. I used seek onStart 
for years in my setups.

Original comment by blacktrashproduct on 15 Apr 2012 at 4:51

[GoogleCodeExporter]

http://code.google.com/p/flowplayer-core/issues/detail?id=447

Confirming there is a hardcoded setting to prevent seeking within 200ms hence 
why the interval is required, this feature might be helpful ?  I'm not really 
sure how it worked at all because of this 200ms limitation. 

"[LOG] time 03:09:48.840 :: org.flowplayer.httpstreaming::HttpStreamingProvider 
: current time within 0.2 range from the seek target --> will not seek"

Again, there is no advertised feature anywhere so it should never be expected 
to work, every streaming implementation is different, this is a fragmented 
streaming technology for instance. 

there is an obvious bug returning the correct time in the internal feature 
anyway so requires a work around. it's very hard to explain if you don't 
understand yourself so bare with me ;)

Original comment by dani...@electroteque.org on 15 Apr 2012 at 5:21

[GoogleCodeExporter]

http://dl.dropbox.com/u/3394987/flowplayer.httpstreaming-3.2.8.zip

Please try this, it's a strange one at first I needed the delay then suddenly  
whatever I did I did not. There is a small delay when seeking on a stream time 
of 0, which is exactly like doing it on the javascript and it will return the 
correct stream time, and overrides the seek limitation now. the buffer 
indicators have been fixed up also. 

Basically the OSMF developers did not factor in this kind of seeking scenario, 
and I doubt any of them have because they have the start offset instead, and 
during this phase on startup, things do get quite complicated to deal with. It 
is treating the seek time as the offset start initial time and removing it from 
the calculated stream time, the actual seeking is working just the returned 
time is not returned correctly. 

Basically this would have been worth working on if we can refactor to OSMF 
version 2.0 which is in another ticket,  it has a tonne of extra functionality 
for the dynamic streaming calculations. 

It should function now ;)

Original comment by dani...@electroteque.org on 15 Apr 2012 at 6:42

[GoogleCodeExporter]

Hi all,

Thank you for the patch posted in DropBox. I had a test with this version and 
the behaviour is now as expected : a seek within the onStart now does not 
change the duration, and the cursor is now in the correct position. Very nice.

I tried the "hack" with the setTimeout, but this was ugly. 250 msec was too 
short, 1000 msec is quite long for the user, and this will probably not work 
with a slow connection (3G for example). This is to avoid.

Will this change be included in a "flowplayer.httpstreaming-3.2.9.swf" official 
release ?

Thans again for your testings and works.

  Patrick

Original comment by canal9ap...@gmail.com on 16 Apr 2012 at 1:55

[GoogleCodeExporter]

No problem I will close this for now. I consider this an interim fix until the 
OSMF people look at the issue I have discovered and this plugin and the bwcheck 
plugins are upgraded to work with version 2.0 of the sources which may not 
happen right away. 

Once things are upgraded it might be a 3.2.10 release. 

Original comment by dani...@electroteque.org on 17 Apr 2012 at 10:38

• Changed state: Fixed