Forum user: ezran

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.

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.

This is actually what the start parameter is designed to do. You need to seek() to 150 if you want the whole video available, but want to start playing at a point 150 seconds in. (However, note: there's currently a bug in flash that prevents this from working perfectly in some situations.)

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.

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.

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?

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...

As of version 3.0.7, when calling seek() on the player while it's still in the buffering state (sometimes the case during the onStart callback), an exeption occurs that cuts off the rest of the javascript and such.

$f.onStart(function() {
  $f.seek(20);
  alert('Did the seek.');
});

So, in the case I'm describing, that alert just won't even get called.

Anyway, the issue is due to the durationTracker not yet being created in AbstractDurationTrackingController, so when it calls doSeekTo in the StreamProviderController, there's an error trying to set the "durationTracker.time = seconds".

To fix this, and allow the seeking to happen correctly, I've just updated seekTo so it can create the durationTracker, like so:

AbstractDurationTrackingController.as (3.0.8-dev)
@@ -168,5 +168,5 @@
    private function seekTo(event:ClipEvent, seconds:Number):void {
+     if (! durationTracker) createDurationTracker(clip);
      doSeekTo(event, seconds);
-     if (! durationTracker) return;
      durationTracker.time = seconds;
    }

As you can see, the patch is applied to the version from 3.0.8-dev (which exhibits the same behavior).

Assuming this doesn't cause any other problems, it'd be great if it could be included in the next release.

This is going to sound stupid, but do you still have the "scaling" setting set to "fit"? I wasn't having any trouble with seeking to various points, until I turned that setting on, and suddenly started encountering exactly the behavior you describe. (Including crashing the browser.) Turning it back off (back to default), everything works fine.

Not sure how/why it'd be related, but if that setting makes a difference for you, too, it could help track down the problem.

I just tested with the new 3.0.5, and it seems to be working great.

In case anyone's interested, here's the latest iteration of the seekVideo stuff, which also allows to jump to any video in the playlist:

var currentPlaylistIndex = -1;
function seekVideo(playlistIndex,seconds) {
  var p = $f();
  // If the video is done playing, or not yet loaded, we have to 
  // give it a kickstart.
  if (p.getState() == 1 || !p.isLoaded() || playlistIndex != currentPlaylistIndex) {
    _startAndSeek(p, playlistIndex, seconds);
  } else {
    p.seek(seconds);
    if (!p.isPlaying()) p.play();
  }
}

function _startAndSeek(p, playlistIndex, seconds) {
  var initialLoad = true;
  // Add a callback to do the actual seeking after the player
  // loads and we've got enough of the video buffered to know
  // where the seekpoints are.
  p.onStart(function () {
    if (!initialLoad) return; // Make sure we don't do this for future onStarts.
    initialLoad = false;
    p.seek(seconds); 
    if (!p.isPlaying()) p.play();
  });
  if (p.isLoaded()) {
    p.play(playlistIndex);
    currentPlaylistIndex = playlistIndex;
  } else {
    p.load(function () { p.play(playlistIndex); currentPlaylistIndex = playlistIndex });
  }
}

So... I've done some more work on this.

I went ahead and added the seekTo call to the BufferingState.as:

95a95,97
>    internal override function seekTo(seconds:Number):void {
>      onEvent(ClipEventType.SEEK, getMediaController(), [seconds]);
>    }

However, I noticed another issue -- that you couldn't always seekTo a particular point in the video, let it play a while, and then seekTo that point again. (It definitely wouldn't work with the first point you try to seek to, but often if you seek to another point after that, then it would work as expected from then on.)

So I found and commented out this line in seek() inside NetStreamControllingStreamProvider.as:

157c157
<      if (Math.abs(seconds - _seekTarget) < 1) return;
---
>      //if (Math.abs(seconds - _seekTarget) < 1) return;

After making that change, the seeking was reliable, but I'm not sure if that could cause problems with anything else... I have yet to see a situation when I actually want it to skip out of seek() early there, though...

Anyway, with those two changes in place, and dealing with the situation that comes up when the video has ended, but you want to seek back into it and play, I was able to update my function to look like this:

    function seekVideo(seconds) {
      var p = $f();
      if (p.getState() == 1) {
        _resumeAndSeek(p, seconds);
      } else if (p.isLoaded()) {
        p.seek(seconds);
        if (!p.isPlaying()) p.play(); 
      } else {
        _loadAndSeek(p, seconds);
      }
    }
    
    function _resumeAndSeek(p, seconds) {
      var initialLoad = true;
      p.onStart(function () {
        if (!initialLoad) return; // Make sure we don't do this for future onStarts.
        initialLoad = false;
        p.seek(seconds); 
        if (!p.isPlaying()) p.play(); 
      });
      p.play();
    }

    function _loadAndSeek(p, seconds) {
      var initialLoad = true;
      p.onStart(function () {
        if (!initialLoad) return; // Make sure we don't do this for future onStarts.
        initialLoad = false;
        p.seek(seconds); 
        if (!p.isPlaying()) p.play(); 
      });
      p.load();
    }

I plan to refactor that a bit, of course, but this is fairly clear. With these changes, it more or less works, although there are slight delays and the timeline position indicator jumps around a bit during certain types of seeking.

I tried that before coming up with the function I posted above.

However, since the player will only seek when it's in the PlayingState or PausedState, not during WaitingState or BufferingState, you can't just seek during the onStart function. (Because at that point, the player is in the BufferingState.)

It would be a very welcome addition to add the seeking ability to the BufferingState, though. It would take a good chunk of the "hackiness" out of the hack.

The problem with using the clip 'start' property is that it changes the timeline, making it appear as if there's nothing before that in the video. I'd like to be able to jump to a spot 30 seconds (or even 30 minutes) into the video, but still allow the user to go back to the beginning -- they need to see exactly where in the video they are.

Imagine you've got the video on the page, and then a bunch of links/buttons below it, "play at 0:30", "play at "0:52", "play at 2:17", etc... Basically I want to be able to jump straight to various points in the video at any given time, triggered by javascript.

Thoughts?

I've been trying to figure out a simple way to use pseudo-streaming, and have javascript tell the video to start playing at a certain offset (in seconds). Unfortunately, the Player.seek() call only seems to work when the player is paused or playing...

So for the moment, I've come up with this horrendously ugly hack:

    function seekVideo(seconds) {
      var p = $f();
      if (p.isLoaded()) {
        p.seek(seconds);
        if (!p.isPlaying()) p.play();
      } else {
        var c = p.getClip(0);
        var initialLoad = true;
        var seekInterval = null;
        if (c) c.update({ autoPlay: false, autoBuffering: true });

        p.onStart(function () {
          if (initialLoad) { 
            initialLoad = false; 
            p.pause();
            seekInterval = window.setInterval(function() { 
              if (p.isPaused()) {
                window.clearInterval(seekInterval); 
                p.seek(seconds); 
                p.play(); 
              }
            }, 10)
          }
        });
        p.load();
      }
    }

Basically if the video is not yet loaded, I have to tell it to load, catch when the metadata is loaded with onStart(), and then tell it to pause so I can seek. However, then I have to poll for when the pause actually happens/finishes, so I can do the seek... And finally I can tell it to play.

Is there something I've missed in the API that would make this simpler? If not, maybe a Player.playAt(seconds) call could be added, or something?