a few controlbar plugin bugs Created Aug 3, 2009

Do you have any live examples of these? I tried with a few of the stock examples on the site and couldn't easily see some of the issues you mention.

Just some observations (not answers):

For #1, is this a progressive download, and how accurate is the metadata? Does this still occur if you manually set a correct duration in the player config? Finally, do you mean that the thumb goes past the end of the scrubber, or that the thumb goes to the end of the scrubber, and it shows a time entry beyond the duration of the video?

#2, it seems to me, the thumb should go back to the last successful seek (or play position). This assumes a progressive download. You didn't mention if this error is with streaming (pseudo or otherwise) or progressive. Obviously for streaming you should be able to move anywhere up to the total duration of the video.

#6 sounds like the registration point of the thumb and/or tooltip marker got changed from center to upper-left (which is the default in Flash). If you have Flash CS4 (I don't) you could check the fla file for the control bar. There's also the lockCenter parameter if they use the startDrag method. It should be true if you want the thumb to always lock to the center when you start the drag.

If you're seeing a different time on release, it means you don't have a keyframe there, and that's the best Flash could do. Except for real streaming (not pseudo) the best you can ever hope for is the nearest keyframe. (Sorry if I'm telling you something you already know.) If your keyframes are far apart you could well see an error - you drag to 2:30 but on successful seek it bounces to 2:45, because that's where the nearest keyframe is. I can't imagine you only have one keyframe per minute, though, for the kind of error you're seeing...

Sorry, I thought these would be very easy to see on the demo pages. I could recreate many of these herehttp://www.flowplayer.org/documentation/skinning/controlbar.html

Using the tube skin, you can see these problems much more clearly because of the size of the scrubber button. I wonder if some of this is due to the tube skin not working well with the code originally designed for the default skin.

#1 doesnt matter if its streaming or not, try it on nearly any demo on this site and you'll at least get a few seconds beyond the actual length of the clip, but due to the relative length of the time line, you can potentially move several minutes beyond the end, depends how long the video is. On short videos, it could be only a few seconds and most users would never notice, so it doesnt affect everyone.

#2 The scrubber button itself physically moves too far, even goes undernear the time indicator using the tube skin, and the tool tip will deplay a time higher than the actualy point where the video ends if you just let it play. Depending on what skin you use, the result of releasing the scrubber in that position is different-- default skin it pops back to where the scrubber was previously, or with the tube skin, it just ends the video. Again, the bounce or whatever doesnt matter if the video is progressive or pseudo streaming. I've not tried it with a live stream, but that is irrelevant since there is no reason to move the scrubber in that case. What does affect how much this shows up is the skin simply because of the size of the scubber button.

#6 Good thinking on this one, however I verified in the source code that those file dates have not changed since 3.1 was released, so i would think the problem is in the action script somewhere. Certainly, the mouse cursor locks to the center of the scrubber but the point on the time line which is selected by the scrubbers placement is that of the far left edge of the scrubber. The tooltip is locked to the mouse cursor, regardless of whether you are dragging the scrubber because the tool tip will appear wherever you hover. So the fix is to put it back the way it was where the scrubber selects the point at the center of itself, or make the mouse cursor lock to the left edge, either way the tooltip needs to correctly indicate what point you are about to jump to. This is not a keyframe issue. Going back to 3.1 or 3.0, the issue is no present. I understand there could be a few seconds of variation due to keyframe placement, and that is fine. I'm talking about an entire minute, possibly 30-60 keyframes i would guess? maybe more? On a short video this is hardly noticable because when you drop the scrubber, it may jump to the wrong place but it would be such a minor error that you wouldnt notice. I'm certain i have more than one keyframe per minute. I have tried some short 3 min videos and the issue is still present but almost not noticeable. The issue may have something to do with the new fancy animation on the scrubber button and volume control as of 3.1.2.

I do not have any examples on my own site to show since I've corrected all the issues in 3.1 by compiling my own version, and i have not moved to 3.1.2 since i have not found a way to correct the button centering issue. Rather, I can offer some "hack" solutions to modify the code and get some more acceptable results. I doubt many of my modifications would be proper in the eyes of the original author.

Okay, thanks for the link to the CB skinning page as a starting point. I was looking at other demo pages and many of these have very short videos as well.

I could easily duplicate just about everything you mention:

1. Running the thumb beyond what should be the "physical stop" at the end of the scrubber bar.

2. Having the tooltip marker follow the mouse, which when you're at the extremes of the scrubber makes it apparent that the timeline is tracking the mouse, not the thumb. (I can see the potential coding problems here, and I imagine Anssi might have some issues getting this to reliably work if the thumb can take on varying widths in config. Basically, the bounding rectangle for the scrubber has to be the width of the scrubber bar, minus half the width of the thumb on the left, and minus half the width on the right.)

3. The "spring back" looks to be related to getting an invalid seek if attempting to move the thumb beyond the duration. The same "spring back" would be the effect if it's progressive and the video hasn't downloaded that far. IMO, it's the desired overall effect - going back to the position of the last valid seek - but of course isn't desired for moving to the end of the video. Fixing #1 automatically addresses this, and then it should be a non-issue.

4. Couldn't as easily see the effect of ending the video when dragging to the right stop, because that invariably caused an invalid seek, and the "spring back" effect occurred. Ideally, on any seek Flowplayer should allow no more than to the lastkeyframe metadata, rather than to the duration metadata. That way you don't abruptly end the video by dragging all the way over (it will only go to the lastkeyframe, which is usually a second or more before the end). However, your videos need to have metadata injected by flvtool2, yamdi, or one of the others, because few encoders/converters put the lastkeyframe metadata in by default.

5. Couldn't reproduce the major 1+ minute error on any video I found here, and all my own pages use 3.1.1 (and some 3.1.0). I'll try some with 3.1.2 free player, as I think I have some longish clips.

I did in fact visit the site listed in your user account, and found some of your vids that didn't exhibit these problems, so I was confused! BTW, cool effect with dimming down the surrounding page during play - without resorting to modal lightboxes. Well done!!

4: this only happens with the tube skin from what i can tell and you dont need to let go of the scrubber. Use tube skin, drag all the way to the right. it will go under the time indicator. Its not the worst thing in the world.

5?? 5 was the the problem where the bar hits the mute button if you turn off the time indicator. That one is way easy to recreate. Only happens on tube skin tho.

6: 1+ min error: only happens on 3.1.2 as i said, so if you dont use that version, it wont happen. This is caused by the button marking the time line from the left side and not the center. This shouldnt be hard to fix. The previous version worked after all. This and the other issue dating back to 3.1 where the scrubber isnt restricted may all be related. The code just doesnt seem to support the tube skin properly, so maybe a resign of the tube skin flash files is necessary...

On my own site, like i said, Im using controls 3.1.1 so this problem isnt so bad, and thats also my own build with some added code to restrict the movement of the scrubber and to shorten the bar when the time indicator is disabled.

If you use the default build of 3.1.2 controls with a 30 min video for example, you will see all the problems mentioned, however the one where the bar doesnt appear immediately after seeking, is visible on my site because that problem i also did not fix and it does date back to 3.1 or earlier.

FYI that dimming effect is simply the previous version of the jquery based "expose" js from this site. The current version which is now part of jquery tools, is buggy and i couldnt get it to work at all on nested DIVs due to some z-index bugs in both IE and firefox (though even the older one which I use has its issues)

So if there are any problems you still cant reproduce, let me know and ill make up demos for them.

I have fixed issue #1 in this controlbar version. It should also fix the other issues that relate to the ability to seek beyond the clip's duration.

I will investigate the other issues mentioned here too. Thanks for testing and problem reports...

Anssi

With this dev version, thats about half the problem fixed! It does only allow you to drag to the end of the bar now, but the button left edge problem, the buffer bar drawing after seek issue, and the other stuff is all there. So on my original list, 1, 2, and 4 are fixed now.

While you're in there tweaking it, can you make it so that when you specify a height for the time indicator window (tube skin), if you specify 0 (zero) the time indicator window is just not there at all? Right now 0 shows a single pixel line as if I specified 1, and i think it looks cooler without that window at all, just with the time indicator right on the silver bar.

I fixed this in my version by modifying this function in TimeView.as

private function drawBackground():void {
            
            graphics.clear();
            if (_config.style.timeBgHeightRatio > 0) { //added to hide the single line when the height is zero
            graphics.lineStyle(1, 0, .3);  
            }
            else {graphics.lineStyle(1, 0, 0); }
            graphics.beginFill(_config.style.timeBgColor, 1);
            var bgWidth:Number = (_durationText ? (_durationText.x + _durationText.textWidth) : (_timeText.x + _timeText.textWidth)) + borderRadius;
            var bgHeight:Number = height * _config.style.timeBgHeightRatio
//            log.debug("_left.width " + _left.width);
//            log.debug("height/2 " + height/2);
//            log.debug("bgheight " + bgHeight);

            graphics.drawRoundRect(_left.width, height/2 - bgHeight/2, bgWidth, bgHeight, borderRadius, borderRadius);
            graphics.endFill();

            // reset the manged width value
            _width = bgWidth + _left.width + _right.width;
        }

Another thing is the bar running into the mute or whatever next button if the time indicator is completely hidden. I fixed it on my version in this function inside controls.as:

private function arrangeScrubber(leftEdge:Number, rightEdge:Number):Number {
			if (! _config.visible.scrubber) return rightEdge;
			arrangeX(_scrubber, leftEdge);
			var scrubberWidth:Number = rightEdge - leftEdge - 2 * getSpaceAfterWidget(_scrubber); 
			if (! _player || _immediatePositioning) { 
				_scrubber.width = scrubberWidth;
				if (! _timeView) _scrubber.width = _scrubber.width - 8 //josh added this to fix the line smashing into the mute button
			} else {
				_player.animationEngine.animateProperty(_scrubber, "width", scrubberWidth);
			}
            _scrubber.height = height - margins[0] - margins[2];
            _scrubber.y = _height - margins[2] - _scrubber.height;
			return rightEdge - getSpaceAfterWidget(_scrubber) - scrubberWidth;
		}

Im not sure 8 is the best value to space it out, but it looks ok on my site.

Thanks Anssi!!

I have fixed these issues except #3 which i cannot reproduce. The fixed veersion is here.

I decided to use timeBgColor: 'transparent' as the possibility to hide the background of the time view. This is more consistent with the other player config options. I hope it works for you.

About issue #3, It looks to me that the buffer bar and progress bar are drawn correctly with pseudostreaming, see here:



HTML setup for the player

<!-- include latest Flowplayer javascript file -->
<script language="javascript" src="path/to/flowplayer-3.2.6.js"></script>

<!-- player container with optional splash image -->
<a href="path/to/video_file" id="playerContainer">
	<img src="path/to/splash_image" />
</a>

JavaScript coding

Following script will install Flowplayer into our player container

<script language="javascript">
// our custom configuration is given in third argument
flowplayer("playerContainer", "path/tohttp://releases.flowplayer.org/swf/flowplayer-3.2.7.swf",{
clip: {
   url: '/video/Extremists.flv', provider: 'pseudo'
},
plugins: {
  pseudo: { url: 'flowplayer.pseudostreaming.swf' },
  controls: { url: '/swf/flowplayer.controls-tube-3.1.3-dev3.swf', timeBgColor: 'transparent' } 
}
});
</script>

I still see it happening if i skip to maybe 3:42 or even 3:00. After about 10 seconds or else whenever the video fully loads, the buffer bar does pop up suddenly as if its appearance just got delayed, taking much longer to appear that it does at the start of a video.

It is interesting that if you then seek a tiny bit further into the area where the buffer should be visible, it does not start a new download so clearly it is working, just not showing the buffered area, and when you do this, the buffered area suddenly appears again.

This is not a huge deal. I can live with it.

I tested out this newest dev and it is working very well. The timeBgColor: 'transparent' looks perfect. Thank you!!

For 3.1.3-dev3 in the demo above look at the tool tip for the scrubber bar at a time just left of 0. I get crazy numbers like -1:0-1:0-1:0-9 on the tool tip.

Fixed this. New version here.

Anssi

Hi, I encountered another probably controls related bug. Both cases happen when seeking to time 00:00 using scrubber bar.

If you click on 00:00 the movie starts from beginning but the slider stays stuck where it is.

If you move the slider to 00:00 using mouse then the movie starts from beginning, the slider is also moved but the buffering animation never ends and the scrubber bar can't be used anymore - stuck.

I'm able to reproduce it for controls-3.1.2, controls-3.1.3-dev4 and the version taken fromhttp://code.google.com/p/flowplayer-plugins/ (according to build.properties it is 3.1.3-dev2, is it?).

I'm using pseudostreaming-3.1.2 and flowplayer-3.1.2.

Hope it helps. ;-)

PS: Keep the great work! You're the best! ;-)

Im having the same problem as stated above. When seeking to time 00:00 the scrubber stays where it is.
Are there any solutions to this problem?

Thanks

Do you have a sample page that demonstrates this? Was not able to reproduce this using the latest dev versions.

Also cannot reproduce it here:http://flowplayer.org/plugins/streaming/pseudostreaming.html

There's a trick to reproducing this bug:
1. Begin to play a streaming mp4 clip
2. Seek ahead to a point that hasn't been buffered yet.
3. Drag the playhead back to 0:00.

The scrubber will snap back to wherever it was at the end of step 2, even though the clip playback will restart from 0:00.

We are using flowplayer.commercial-3.2.2.swf and flowplayer.pseudostreaming-3.2.2.swf

I'm using flowplayer.pseudostreaming-3.2.7.swf with lighttpd/1.4.28 + h264_streaming module and still such problem exists. Seeking to 00:00(and replaying too) fails and playhead stands on it's place but video starts from begining. But if seeking wasn't used and video played till the end, replaying("Play again") works right. I have noticed that this problem related only to mp4 files. Seeking in flv files works right.
I tested h264 streaming module by checking md5 sum of several downloaded files. Fileshttp://host/file.mp4 andhttp://host/file.mp4?start=0 are equal. So problem isn't in webserver.