VideoLoader - streamed videos don't appear unless loaded

[thoughtben]

Great suite of classes! However, found some weird behaviours for streamed videos

 

We're streaming off Amazon S3 and if you request to play a video before it is fully loaded (but only in some instances!) the audio plays out, but the visuals are not rendered to the stage (or at least cannot be seen)

 

I've traced out all the 'visible' and 'alpha' properties (tick) and found that all is good if the video is fully loaded before requesting playVideo()

 

Any advice on checking what's going on? Why would the video not be visible? Project is pretty complex, so no point loading files, but in terms of LoaderMax and VideoLoader usage, it's all basic stuff.

 

Final note - any chance of an integrated 'stateChange' listener? Might marginally affect performance, but it's so useful to know when a video is playing / buffering / stopped as with the FLVPlayback shizzle

 

Over n out.

 

Ben Templeton - www.thoughtden.co.uk - digital curiosity

[GreenSock]

Hmmm...first question: what version of VideoLoader are you using? There are some bugs in Flash's NetStream behavior that were worked around in the latest version of VideoLoader, so make sure you're up to date. http://www.loadermax.com

 

Next, can you post a super simple example FLA that demonstrates the problem so that we can publish it and see what you're talking about? I know you said it doesn't happen every time, but at least if we had an FLA pointed to a video on your S3 server, we could hit the problem intermittently and add traces, etc. to troubleshoot.

 

As for the state change, there are events already dispatched for VIDEO_PLAY and VIDEO_PAUSE and VIDEO_BUFFER_EMPTY and VIDEO_BUFFER_FULL and PLAY_PROGRESS - was there something else you needed to listen for?

[jstarrdewar]

I am having a similar issue or the same issue. I am using version 1.42. It happens with a very short video, in both flv and f4v formats. It's 4 seconds, 635 kb. It also happens semi-randomly. Once in a while it will work fine. I am actually loading several clips of this approximate length and size, and on each run, a few will work and a few won't. Which ones work, and which don't changes every run. Longer clips never seem to have the same issue, and I'm not sure what the cutoff is yet.

 

Using the flash debugger, I inspected the VideoLoader instance and found that, although the clip was playing and I could hear the video, and the VideoLoader.content property was properly added to the stage, the VideoLoader._video.videoWidth property == 0, and the videoHeight property also == 0. I happen to have a click handler that fires VideoLoader.gotoVideoTime(0), and when I click it, the next time the video plays, I see it and videoWidth == 848/videoHeight == 480, as it should. If I programmatically call VideoLoader.gotoVideoTime(0) without the click handler, it still isn't visible, and it still reports videoWidth/videoHeight == 0.

 

I tried setting the size of the video explicity with the width/height parameters of VideoLoaderVars. I also tried modifying VideoLoader so that it instantiates the Video Object like so: _video = _content = new Video(848, 480). That made no difference. I put a trace in at line 543 in the _metaDataHandler and traces the width and height. They trace 848 x 480 long before I ever attempt to play the video in the first place (I have autoPlay set to false). I can't post the videos on the public forum, but I PM'd links to them to you directly. Tomorrow, I'm planning to break down a few test cases to see if I can isolate the problem further.

 

A few other things I tried were manipulating the Video object and netstream directly, by adding the Video to the stage and using netstream.seek(). Neither had any effect, except that my click handler no longer caused the video to revert to its proper size and display if I didn't have VideoLoader.gotoVideoTime(0) in there and used netstream.seek(0) instead.

[jstarrdewar]

I just went through subversion and reverted the greensock.swc to an older version, which was current as of August 11th. Unfortunately I was using the swc, so I don't think I can figure out exactly which version of LoaderMax it was. However, that fixed the bug. It works perfectly now. I'll see if I can track down the exact version where the problem showed up. I'm almost certain, however, that it appeared in between VideoLoader version 1.3 and version 1.32, which you released on August 12th, because I remember I had used one of the loaderVars objects you added in 1.3. I was in the middle of a complicated refactor, so I thought the bug was in my code and not yours, which should teach me not to go about upgrading libraries in the middle of refactors :-/

[GreenSock]

Wait...just to clarify, you're saying that the most recent version of VideoLoader (1.321) does have the problem but an OLDER version works great? Recent versions implemented workarounds for a few bugs that are in Adobe's NetStream class - are you saying the pre-patch version worked better for you? On 8/12 and 8/30 there were fixes applied. I'd be very curious to know if the MOST RECENT version (available at http://www.LoaderMax.com) gives you the problems or if maybe you had a stale swc in there.

[jstarrdewar]

Yes, the older swc is the working one. The swc that's been causing the problems came from the bonus-all folder and is dated 9/6/10 11:55 (I also took the swc out and compiled against the source code from the latest bonus-all folder with the same results -- the Changelog lists the version as 1.42). I'm trying to isolate which of the changes is causing the problem now.

[jstarrdewar]

It's the change on line 436. If I just copy and paste the lines from version 1.3 into 1.42, everything works fine. Revert to the original 1.42 and it breaks. I did this 6 times just to make sure.

 

This works:

			
if (_pauseOnBufferFull) {
_pauseOnBufferFull = false;
this.volume = _volume;
gotoVideoTime(0, false);
      _ns.pause();
}

 

This doesn't work:

if (_pauseOnBufferFull) {
if (this.metaData == null && getTimer() - _time < 10000) {
	_video.attachNetStream(null);
	return;
} else {
	_pauseOnBufferFull = false;
	this.volume = _volume;
	gotoVideoTime(0, false);
	_ns.pause();
	_video.attachNetStream(_ns);
}
}

 

I was thinking that the NetStream wasn't getting reattached to the video, but I see it happening in the videoPaused setter. I also tried adding _video.attachNetStream(_ns) to the playVideo method, but no luck there.

[jstarrdewar]

I have confirmed that if I comment out line 438 my problem goes away:

_video.attachNetStream(null);

[GreenSock]

Yeah, thanks for looking into that. I had already discovered that issue right before you posted. Still chasing it down now fully. I love working around bugs in Flash! It seems as though the Video object won't scale correctly unless the NetStream is attached to the Video object but it needs to be attached for at least 1 full frame (ENTER_FRAME) before it behaves correctly. And NetStreams cannot be paused before the onMetaData has been dispatched otherwise it'll never receive the metaData even when the NetStream is resumed. And there's a bug in the Video object that prevents its scrollRect from working properly unless it is initially set to eactly 320x160. So the bad news is that there are a bunch of bugs and inconsistencies in NetStream (and Loader, and URLLoader and Sound) but the good news is that LoaderMax works around them so it delivers a more reliable foundation for loading. Stand by while I work around this...should be done soon...

 

Oh, and the whole reason for doing the attachNetStream(null) is because if I don't, you may see the video (graphics) play very briefly before it pauses (again, this is because I cannot pause() a NetStream until the metaData has been received). If I detach the NetStream temporarily, you won't see that little initial playback/animation.

[jstarrdewar]

I guess I didn't notice that, because my clips get added to the stage at the same time as I call playVideo. Maybe there could be a little firstplay logic so that VideoLoader doesn't add the Video to the ContentDisplay until the video is supposed to play? Although I suppose that doesn't help those who might want to deal with the Video object directly.

[GreenSock]

Alright, I just posted an update that (according to my tests) resolves the issue. Please take a peek as soon as you can and let me know if it solves things for you as well.

[jstarrdewar]

Hi Jack,

Sorry it took so long to test it out; it works fine now. I was just running with that line commented out for a while. Thanks for fixing it so quickly. I tested the bonus-all swc.

 

I really think you have a good model going; it's well worth the money to support it, but if there's a show-stopping bug I can still jump in to the code and find a solution, or just revert part of the library back to an earlier version. Plus, I have learned an awful lot of ActionScript from you, thanks to your excellent comment coverage and documentation. I wish more Applications would follow that model, even big ones. There're several bugs in FlashBuilder, for example, that I bet wouldn't be too hard to find; plus it doesn't keep up with Eclipse.

[GreenSock]

I really think you have a good model going; it's well worth the money to support it, but if there's a show-stopping bug I can still jump in to the code and find a solution, or just revert part of the library back to an earlier version. Plus, I have learned an awful lot of ActionScript from you, thanks to your excellent comment coverage and documentation. I wish more Applications would follow that model, even big ones.

Thanks for mentioning that. Yeah, the unique licensing model is something that most people appreciate when they think it through, but initially it can seem like a liability. It's surprising how few developers understand the hidden costs involved with using "free" open source tools that have no funding mechanism or active support. The web is a wasteland of abandoned projects riddled with bugs and absolutely zero support. Not exactly something you'd want to rely on in business-critical apps. Anyway, the other interesting side effect of using the licensing model I do is that it tends to sift out the chaff in terms of short-sighted developers who aren't considerate of others and care only about "cheap"-ness. I end up with respectful, sharp developers like yourself using GreenSock tools who understand the value and that's exactly the type of folks I like working with. I don't say that as flattery - I seriously feel privileged to have the customers and supporters that I do and some of it is due to the licensing model (an unintended side effect).

 

Anyway, thanks again.

 

And for anyone else reading this who is interested in why I created the rather unique licensing model and why it benefits you, read http://www.greensock.com/licensing-considerations/