clip.seekableOnBegin: what is it?

[GoogleCodeExporter]

As per e.g.: 
http://flowplayer.org/documentation/configuration/clips.html#properties

"Can we seek this clip when it's paused in the first frame. When true the 
scrubber becomes disabled when the player is paused on the first frame. By 
default the scrubber is enabled when the clip's url has one of the filename 
extensions that are used for Flash video 'f4b', 'f4p', 'f4v', 'flv'."

I don't understand a word. I tried experimenting with setting it, without 
spotting any difference. And it cannot be read, returns undefined.

Please clarify.

Original issue reported on code.google.com by blacktrashproduct on 1 Jun 2012 at 7:55

[GoogleCodeExporter]

in the controlbar it will disable scrubbing when paused if set to false, for 
progressive download. I think its a redundant setting and should be removed 
from the controls as I had to enable it by default as it was causing problems 
disabling the scrubber when autobuffering. is it still doing it ? 

Original comment by dani...@electroteque.org on 1 Jun 2012 at 12:33

[GoogleCodeExporter]

Ah, ok, setting it to false (default apparently has changed to true) makes it 
readable e.g. by $f().getClip(0).seekableOnBegin - but it has no effect; once 
the clip buffers you can seek to buffered positions.

But I can see now where this setting makes sense: with the playlist-based 
splash image setup. The video clip should be configurable to only be seekable 
(even to buffered positions) after you clicked play.

I'm fine with the new default `true'. But of course only if seekableOnBegin: 
false has an effect. At the moment it doesn't.

Aside: the extension list is also strange, imho we can't get all video 
extensions anyway etc. So if there's any code regarding that, it could be 
omitted with the `true' default. If someone wants to set it to false, they 
should know what they are doing.

imho Anssi should decide whether the feature should be ditched altogether.

Original comment by blacktrashproduct on 1 Jun 2012 at 1:16

[GoogleCodeExporter]

Yes ive left it in there, its in the scrubber controller in the control plugin, 
it disables the scrubber if this is set to false

Original comment by dani...@electroteque.org on 4 Jun 2012 at 8:50

[GoogleCodeExporter]

You've left it in where? Currently clip.seekableOnBegin: false has no effect:
http://flowplayer.blacktrash.org/test/minimal.html

It _should_ disable seeking the video clip, but it does not.

Original comment by blacktrashproduct on 4 Jun 2012 at 12:08

[GoogleCodeExporter]

it's supposed to disable the scrubber on startup. The code in question is

http://code.google.com/p/flowplayer-plugins/source/browse/flash/controls/trunk/s
rc/actionscript/org/flowplayer/controls/scrubber/ScrubberController.as#103

it looks like its supposed to stop progressive download streams from the 
scrubber working while paused on startup / autobuffering. 

Original comment by electrot...@gmail.com on 18 Jun 2012 at 4:34

[GoogleCodeExporter]

Yeah, it makes sense to have it optionally with playlist-based splash images. 
At the moment it does nothing whatsoever though.

Original comment by blacktrashproduct on 19 Jun 2012 at 3:28

[GoogleCodeExporter]

its been turn on by default. 

Original comment by electrot...@gmail.com on 19 Jun 2012 at 6:24

[GoogleCodeExporter]

Yeah, the default makes sense - you cannot turn it off though:
http://flowplayer.blacktrash.org/test/minimal.html
should now not be seekable while the playlist-based splash image is visible, 
but it is.

Original comment by blacktrashproduct on 20 Jun 2012 at 11:33

[GoogleCodeExporter]

its already loaded the clip by then. im not sure why its needed to be honest 
apart from progressive download. 

Original comment by electrot...@gmail.com on 20 Jun 2012 at 2:07

[GoogleCodeExporter]

Well it would make sense, if you want to prevent seeking while the 
playlist-based splash image is displayed (but I'm aware that onBegin and 
onStart have already been fired for the video clip then). Then, like with e.g. 
a html/css splash image, the playback will always start at the beginning.

Personally I'm fine with removing that property altogether, but I guess it's 
there for the above reason - I cannot imagine any other. Can you? Work around 
some kind of broken video??? Someone must have thought something when she 
implemented the property (I'm still an optimist) surely? - I just don't know 
what.

Original comment by blacktrashproduct on 20 Jun 2012 at 2:54

[GoogleCodeExporter]

like with the image property its an internal public property and shouldn't be 
documented as such if it is as its too hard to explain. 

i reckon just leave the feature in the controlbar I suppose, perhaps the ads 
plugins use it, not sure. 

with progressive download even if they try to seek outside the buffer it will 
trap this and reset back, so its not really neccessary. i found the feature 
actually caused issues where the scrubber wouldn't re-enable hence why its 
enabled by default. so to reduce the code it could be removed just like the 
image property check for audio items. 

Original comment by dani...@electroteque.org on 29 Jun 2012 at 3:38

[GoogleCodeExporter]

"internal public", aha. Yeah, will remove both `image' and `seekableOnBegin' 
from the docs.

Original comment by blacktrashproduct on 1 Jul 2012 at 2:26

[GoogleCodeExporter]

Original comment by blacktrashproduct on 1 Jul 2012 at 2:38

• Changed state: Done

[GoogleCodeExporter]

should we remove that code from the controls ? what about the image playlists 
for audio make it just use the coverimage ?

Original comment by dani...@electroteque.org on 2 Jul 2012 at 12:20

[GoogleCodeExporter]

Ask the project leader. As I've said before, image would still make sense for 
audio over rtmp where you cannot use coverImage. But no property is better than 
a broken property.

Original comment by blacktrashproduct on 2 Jul 2012 at 2:04