Seeking and scrubber broken with "autobuffering" enabled. Created Mar 11, 2009

We've been encountering this error as well, and I've been looking into it, so I'll add some more detail:

I've encountered the issue with both pseudo-streaming and http providers, with both mp4 and flv videos, and both when controlling the player through javascript or the scrubber controls. It happens whether you seek into the currently-buffered section, or past what's buffered so far. It still happens with 3.0.8-dev, too.

However, it'll only happen when you seek and then play, on a clip that's already buffering. In other words, if you use autoBuffering:true or if you call startBuffering(), before seeking and playing.

I've dug into the source code some more (quite a bit, actually) and haven't found anything that would cause it, or even any likely culprits.

One interesting note: While the player is in the weird state like that, if you seek back to the beginning of the video (with javascript or the scrubber), it'll start playing correctly.

Here's the very basic sequence that can cause it, and what happens:

// Start with a basic player like Joust posted, but 
// with autoPlay:false and autoBuffering:false.
// Then the following (with appropriate delays between):

$f().startBuffering();
// The video starts buffering.
// The metadata keyframe stuff loads in, etc.
// The first frame of the video shows in the player.
// The duration of the video shows in the time section.

$f().seek(20);
// The scrubber jumps out to that point.
// The current time updates in the time section.
// The player shows the frame from 20 seconds into the video.

$f().play();
// The play button overlay fades away.
// The scrubber and current time begin moving/updating.
// The video (and audio) do NOT play.

$f().seek(0);
// The scrubber and current time go back to zero (and continue updating).
// The video starts playing from the beginning correctly.

I hope that info can help in debugging the problem...

I belive it is close to the following: http://flowplayer.org/forum/8/16505

Flash devs - please help asap.

I don't think it's actually the same issue as that other fix I posted, since I'm encountering this bug even with the patched version of the code.

I've dug in some more, watching all the calls to the NetStream object, and they all look correct, as far as I can tell. Can't see any problems regarding attaching the NetStream to the Video object either.

It seems that the timeline/scrubber gets updated by polling (or getting callbacks from) the NetStream, so it seems like the video actually *has* to be playing, as far as flash is concerned. But somehow it just isn't getting displayed. I was looking at the whole attachNetStream stuff for that reason. However, even if that wasn't working, the audio should play through correctly, and it doesn't.

I know you guys are busy, but could one of the flash developers at least take a quick look and maybe give me some suggestions of other things I could check out in the code, that might be related to or causing the issue?

No reply since wednesday :| I hope they're alive :)

we're alive and will be investigating this to be fixed in our next version

Was there a result to this investigation? Can we expect it to be resolved in 3.1?

Was trying to fix this but no luck. It works fine with FLV files so this sounds like a Flash bug to me.

The behaviour changed with ver 3.0.7 or 3.0.6. Take a look at my original report: http://flowplayer.org/forum/8/14032,

It is very hard to believe that it's flash fault, because the UI is controlled by Flowplayer, so at least there is a way to work around it.

Without going into API or tech details...

• Buffering MP4+AAC works.
• Playback works.
• Seeking to ANY pos after pushed play works
• Seeking to any non-buffered part after pushing "play" works (AKA streaming).

We have all the pieces needed to make auto-buffering seek-first solution!

So, beeing totally ignorant to the implementation, our test case could be handled as following:

1. Video auto-buffers itself
2. User clicks any position on the scrubber
3. Flowplayer remembers the clicked position, moves the scrubber head... and sits tight.
4. After user clicks play button, flowplayer executes THE SAME PROCEDURE that it would normally exec when playing from start, but soon after that it seeks to remembered position
5. (optional) If the seeking pos is outside of buffered range, flowplayer buffers (streams) from the given byterange
6. Video playback starts from the selected position

DONE! Simplest workaround in the world :)

I was just telling some other guys in the office that from what I've seen so far of this bug, it kinda' feels like a Flash bug.

However... We use FLV files with H.264 data in them, and the bug still occurs. If it is a Flash bug, then it's with the H.264 processing, but that makes it sound less likely.

Nope. How would you explain, that seeking after clicking play works, but seeking before clicking play doesn't? It doesn't feel like flash problem, because component decides when to start buffering/playing/seeking. Even if flash has a bug, that makes handling mp4 vs. flv different, the workaround has to be dead simple (like described above). Flowplayer can read type of video from the stream (and/or meta).

Having dug pretty deep into the code, I can say it is very possible it's a Flash bug. Flash handles all of the playing aspects, and basically just calls back to the player when various things happen -- when buffering finishes, when play starts, when cuepoints are hit, when the video ends, when the buffer is empty because the connection is too slow, etc. Flash takes care of actually drawing the video and playing sound, etc. You just tell it to connect to a network stream, request it to seek to a particular location, request it to play, etc...

Since all of the video data handling is internal to Flash, it's very possible that it has a bug in how/when it's storing info about h.264 encoded videos, which gets cleaned up when the video starts playing from the beginning.

Regarding your workaround, it's possible that could work, but the playing/stopping of the videos with Flash isn't always especially precise, so it may end up that doing your workaround would always mean a quarter- to half-second of video plays from the beginning before it's able to seek. Which would confuse users and be an extra delay each time.

The video API provided by Flash is very minimal and doesn't give a lot of control, so it's not as simple a prospect as it all seems. Feel free to dig into the API athttp://livedocs.adobe.com/flex/2/langref/flash/net/NetStream.html to see what options are available for implementing a workaround.

[...] a quarter- to half-second of video plays from the beginning before it's able to seek. [...]

You could buffer the call to compensate or put the call into an event (onstart, onplay?).

So I've implemented a couple workarounds (such as saving the seekpoint and waiting until Netstream.Buffer.Full happens before doing the actual seek, as well as ensuring that onBegin is called in the StreamProviderController before doing a seek), and so far they can significantly reduce how often this bug happens (and how often it crashes the browser), but don't completely alleviate the problem.

The tradeoff is, of course, a lot of jumpy skipping/playing stuff as you seek around, because it's playing a bit from the beginning before it can actually seek, etc. Kinda' ugly, that.

I also checked out the newest version of Flash (10.0.22.87) and updated to it, because it supposedly has these bug fixes:

* Seeking H264 video on the first few frames causes IE to crash. (FP-913/2216957)
* When the end of a video is reached at certain websites, IE crashes instead of showing the next frame. (FP-1123/1932362)

Where, of course, by "IE" they mean "the browser"... Unfortunately, that didn't seem to fix the problem.

When using pure FLV files (instead of h.264 in an FLV container), I haven't seen this exact bug happen, but I have seen the browser crash once or twice while seeking video. (With and without my workarounds in place.)

The fact remains, though, that if you play the video from the start, then no manner of seeking about within it seems to encounter the bug. However, trying to truly implement such a workaround in the flowplayer code seems more than just a trivial matter (at least for me). Is there any chance you guys could try your hand at hacking in a test of the concept, at least to determine if it would alleviate the issue? (Then it might be possible to detach the netstream from the video display until it's really ready to play, or something?)

We're pretty much ready to buy our commercial license and deploy flowplayer on our site, but really can't do so when it often crashes the browser.

Same here. We're waiting for this critical bug to be fixed before paying. Don't have skills to dig into fla code though.

We could prevent seeking when it's paused on first frame by making the scrubber disabled. Then it would enable the scrubber once the playback has started. How does this sound?

I've now implemented following: The scrubber is disabled when paused on first frame if the clip URL does not have one of the flash video extensions 'f4b', 'f4p', 'f4v', 'flv'.

The default can be overridden using a new clip property seekableOnBegin: true. Adding this will enable the scrubber also for h.264 encoded files.

So now the scrubber is by default disabled when paused on the first frame and if the clip does not have one of the extensions mentioned above.

Please test the simplest one:

autoPlay = autoBuffering (in terms of flash calls)

Now the question is, how fast can you pause the video? First frame? first keyframe?

Bottomline: when autoBuffering:true imply autoPlay:true, but pause at the very first frame (possible).

Unfortunately, this doesn't really address the issue. For one, we're using the FLV container on our h.264 videos, so the extension-matching won't work. (Of course, if you allowed explicit "seekableOnBegin: false" as well, that could mitigate the situation.)

However, we jump to certain points in the video using Javascript, and can't just let the video pre-buffer that far, because it could be easily an hour into the video we're trying to jump to. (Not sure if that's actually a factor.)

In any case, our situation doesn't lend to having the user play the start of the video before wanting to seek around within in, so this tweak would actually make things worse for us. (Possibly destroying our ability to use FlowPlayer at all.)

So ... looking at actual solutions...

Have you been able to put together a simpler test case (like, just a basic bit of actionscript to show a video and seek into it), so we can look at exactly what situation causes the bug? FlowPlayer already has some code in there to netStream.play(URL) and then immediately afterward do a netStream.pause(), for when you want autobuffering but not autoplay. It seems like this could be extended to allow the first frame or two of video to actually play, which would hopefully clear out the h.264 bug. However, with all the passing back and forth between events, and inherent delays in them, I haven't been able to figure out how to test that inside FlowPlayer yet.

Any news?
Is fix/workaround coming ? (please)

Sounds like a cheap workaround. Cheap, because many streams don't use extensions (i.e. /stream/9192do9rqqsw002312/331).
Workaround, because disabling scrubber helps with nothing. Widely adopted H264 is the new standard for flash (as Adobe states), and proprietary FLV is going to it's retirement. not mentioning AAC.

I'd rather see the "play-before-scrubbing" workaround, even if it jerks a little bit at start. At least we don't loose the functionality.

Consider UI repercussions! - user sees that his video is buffered (like on youtube) - GREAT! He clicks the scrubber but nothing happens - conclusion: seeking doesn't work on this #$@^*&@# site [bounce]

bump.

What is going on? 4 weeks ? That could be a new record. Any news?

Would a simple solution be:

onBufferFull: function() {
  this.play();
  this.pause();
}

I don't work with H.264 videos so I cannot test this, but it seems as long as you play/pause the video before the user tries to seek, you will never encounter the bug.

However this might mess up some onStart functions if you have them.

Nope. How do you know someone will fill their buffer? Basically it works like this: someone enters site, sees the player and 10:00 length, clicks in the middle then play - and *boing* *crash*

I believe we are experiencing this same bug:

http://www.morningstar.com/Cover/videocenter.aspx

Play with scrubber bar and you'll have some strange behavior.

It's still here with the newest version and Flash updates. So unless you stick to the very basic configuration and dump autoBuffering, you're out of luck. Or dump MP4, who would use that anyways? Or get another player.

And still no workaround.