VideoLoader VIDEO_COMPLETE triggered prematurely

[ggritmon]

The VideoLoader is a great feature of the LoaderMax package, but has a few issues which prevent it from being usable as a video player. Please let me know if you ever get a chance to update the following issues. Thanks in advance!

 

1. REQUEST: The VideoLoader could use a stopVideo(). If I want to stop a video, so that the next request to playVideo() starts from the beginning, I need to instead call pauseVideo() followed by gotoVidTime(0).

 

2. BUG: The VIDEO_COMPLETE event triggers prematurely when on the local machine. I encountered this issue when building my own players as well. Essentially, "NetStream.Play.Stop" only means the video has ended if "NetStream.Buffer.Empty" or "NetStream.Buffer.Flush" directly preceded it. If not, the player needs to play out the rest of the buffer before the video is over. My logic looks something like:

// Inside NetStream handler
switch (event.info.code) {
case "NetStream.Play.Stop":
	//Video End...Ready END Event;
	if (_lastStatus == "NetStream.Buffer.Empty" || _lastStatus == "NetStream.Buffer.Flush") {
		dispatchVidEvent(VidEvent.END);
	}else{
		_endAfterBuffer = true;
	}
	break;
case "NetStream.Buffer.Empty":
case "NetStream.Buffer.Flush":
	if (_endAfterBuffer){
		_endAfterBuffer = false;
		dispatchVidEvent(VidEvent.END);
	}
	break;
}
_lastStatus = event.info.code;

[GreenSock]

1) Just to clarify, you're saying that you don't like calling two methods to accomplish what you want - you want me to add a new method to the VideoLoader API to reduce your two method calls to one? If so, I'm a little apprehensive about this because I try hard to keep the API clean and protect the class(es) from bloat so if something can be easily accomplished with two method calls, I'm inclined to leave it that way (unless I get a bunch of requests for the convenience method). Things can quickly get bloated if I accommodate every request like this. Why not a playVideoThenCallMethod() or loadAndOnBufferFull() or some other convenient combination of methods? I'm not saying your idea is bad at all - I'm just saying I'm protective of the file size and API cleanliness so I don't like adding to it unless there's a very clear advantage that goes beyond saving one line of code.

 

2) Could you help me see an example of the premature firing of VIDEO_COMPLETE? I have tested several videos locally and I can't reproduce the problem you mentioned. And Adobe's own docs say that the NetStream.Play.Stop indicates the end of playback: "The two codes that you want to specifically listen for are "NetStream.Play.Start" and "NetStream.Play.Stop" which signal the beginning and end of the video's playback" (http://livedocs.adobe.com/flex/3/html/h ... eo_07.html). And a Google search seems to turn up similar results. But Adobe's NetStream class certainly has a ton of bugs and inconsistencies, so maybe you've stumbled across another one that I need to work around. I'm just very curious to see the bug for myself. Could you help me see it? Maybe you could post a simple FLA and video file that I can publish to clearly see what's going on.

[ggritmon]

1) I totally understand & respect the desire to not bloat the API. My point is that stop() is a fairly common video functionality that is absent from the current API. I can assume that pause() and seek(0) do the same thing, but am unsure what other timers/event handlers/etc you may have going on that may be unnecessary when what I am actually doing is putting the video entirely into standby mode again. In addition, stopping a video means the video is 'over' just like the video completing does. Calling stop() could result in an instant VIDEO_COMPLETE event, allowing handlers to differentiate it from a pause and continue with anything they may have been waiting to do until the video ended.

 

2) The NetStream event issue is definitely a bug in their API. In this case, I really noticed the problem when I was playing very short videos (2 or 3 seconds). I added a listener for VIDEO_COMPLETE and had it (conditionally) restarting the video immediately. The second request for the video kept triggering an immediate VIDEO_COMPLETE. Everything worked as expected once I added the logic I mentioned to the VideoLoader class.

Naturally, I just tried to create an example file for you and everything worked perfectly using the out-of-the-box VideoLoader...reproducing issues can sometimes be such a pain. I've attached my modified version of VideoLoader anyway. If I come across the issue again I will be sure to follow up with the exact code.

[GreenSock]

1) Actually, your description demonstrates one of the other reasons why I'm hesitant about adding a stopVideo() method - "stop" means different things to different people. For you, it might make sense to dispatch a VIDEO_COMPLETE event when you stopVideo() even if the video is only halfway through its duration whereas I would definitely NOT think that's intuitive. You might think it makes sense to have the video return to the beginning whereas others might thing stopVideo() should just stop it...as in don't play anymore...which is basically the same as pauseVideo(). When you stop() a MovieClip timeline in Flash, it doesn't make the playhead go back to the beginning. Some might even think that if you stopVideo(), it should clear out the image completely from the Video object on the stage because after all, that video isn't playing anymore. It can get pretty confusing and different people want different things, so I think it's better to provide an API that allows people to accomplish exactly what they want even if it might take 2 function calls instead of 1. See what I mean?

 

2) I'm super interested in working around any bugs in NetStream, but if I can't reproduce it and you can't reproduce it and all the docs I can find indicate that the current functionality is the correct one, I'm inclined to leave it alone until we can prove there actually is an issue somewhere to work around. Not that you're mistaken - I just need evidence before I start monkeying with the widely accepted best practices, you know? So if/when you do reproduce the problem, definitely send the example file(s) my way and I'll jump on the fix.

[ggritmon]

First off, thanks so much for the quick & constant communication. You rule.

 

1) If you dispatch a VIDEO_STOP event, then a user could listen to either or both. As you mentioned, having stopVideo() do nothing but stop the video would be the same as pauseVideo, so make it do something else. No reason you couldn't make the method take some optional parameters. stopVideo(reset:Boolean=true, clear:Boolean=true);

 

2) I agree that asking you to fix an issue I can't reproduce is not the best of requests. I will keep my eyes open for the issue to return & create an example as soon as that happens. Thanks for all the effort you've already put into this.