Copy link to clipboard
Copied
I have a reproducible bug for which I made a VERY simple test set of code that demonstrates the problem.
Using AIR 3.2 with regular Video (not StageVideo) the NetStream gets a "NetStream.Play.Stop" early... AND the video stops playing before the end. Happens on all my devices.
Using AIR 3.1 the video plays through correctly but will very soon crash my Kindle Fire. Maybe my code is whack--but you can download it and see it copied here--it's very plain. Plus, the video is fairly tiny (320x240). I am happy using 3.1 if I have to, but it crashes on Kindle so I'm pretty stuck. Please test this out and suggest any ideas you have.
You can install the apps from here:
http://www.phillipkerman.com/air/VideoTester32.apk
http://www.phillipkerman.com/air/VideoTester31.apk
And download the source from here:
http://www.phillipkerman.com/air/source.zip (remember to modify the -app.xml when publishing to 3.1 or 3.2).
I've also included the relavant code below. Thanks in advance!!!
nc = new NetConnection();
nc.addEventListener(NetStatusEvent.NET_STATUS, onNetStatus);
nc.addEventListener(SecurityErrorEvent.SECURITY_ERROR, onSecurityErrorHandler);
nc.connect(null);
//
private function onNetStatus(evt:NetStatusEvent):void {
if (evt.info.code == "NetConnection.Connect.Success" ){
ns = new NetStream(nc);
var client:Object = {};
client.onMetaData = onMetaData;
client.onCuePoint = onCuePoint;
client.onBWDone = onBWDone;
ns.client = client;
ns.addEventListener(NetStatusEvent.NET_STATUS, onStreamStatus);
var video:Video = new Video();
video.smoothing = true;
addChild(video);
video.attachNetStream(ns);
video.x = 200;
video.y = 200;
ns.play(_url);
}
}
protected function onStreamStatus(evt:NetStatusEvent):void{
if( evt.info.code == "NetStream.Play.Stop" ){
//MY DISPATCHER:
//dispatchEvent ( new MyVideoEvent(MyVideoEvent.VIDEO_COMPLETE, true ) );
}
}
Copy link to clipboard
Copied
I tried both the 3.1 and 3.2 versions, on an Acer Iconia A500 and a Kindle Fire. All four tests worked.
Copy link to clipboard
Copied
Thanks for testing Colin.
You sure the video plays through on the 3.2 version? I should have put the transcript of the video:
"the safest place to walk is on the sidewalk, if there is a sidewalk use it"
When I play the 3.2 version it skips the ending "...use it"
When I play the 3.1 version it will crash after a few tries (every time you click it starts a new video... so click a few times and it will eventually crash--on Kindle)
I should add, I get this behavior (the last second or two missing) for any video (in AIR 3.2/Android)
Copy link to clipboard
Copied
So, it does end early in the 3.2 version, on both the Kindle Fire and the Acer tablet.
Copy link to clipboard
Copied
I guess it's good that it fails as I describe. I'll bet you can make the kindle crash too. I'd prefer to use the 3.2 version incase other things come up--at least I'd have the latest version. But, videos ending early isn't going to work for me. I should note: it's not just the "NetStream.Play.Stop" that occurs early, but the video won't play through. Anyway, I'm just looking for a workaround/fix for now.
Copy link to clipboard
Copied
Phillip,
I got the same results on my Kindle Fire. Thought 3.1 wasn't crashing at first, but then it did after a couple more clicks.
Have you tried the same experiment with StageVideo? I know it may not work for your needs if your video needs to overlay any other Flash content but was wondering if the Kindle just doesnt play nicely with AIR & video.
- John O
Copy link to clipboard
Copied
Thanks John--but Kindle doesn't support StageVideo. My plan on this project is just to use CPU video on Android because--besides Kindle, there is at least one Android tablet which reports to support StageVideo (StageVideoAvailability.AVAILABLE) but doesn't actually work--namely, the galaxy tab 7+. Because these videos are so small I'm not bothering with StageVideo (on Android). According to my tests it's just not ready for prime time.
Regardless I'm curious if there's some workaround to that crash.
Copy link to clipboard
Copied
Hi Phillip,
Were you able to find a solution or workaround to this problem? We have just discovered we have the same problem (video ends early) which is a real hassle as most of our stuff is video based, and we were planning to launch the app really soon!
Cheers,
Amanda.
Copy link to clipboard
Copied
Naw--it's whack. I tried by adding 1 second to each video, then after a couple dozen I found it wasn't consistent. I was about to log all the durations... add FIVE seconds to each, and then use my hardwired (logged) values and handle it that way. Then, I just backed off and decided to use .flv (VP6) videos. Works fine. But, still, it's whacked. You can read more details here (but you won't see a workaround): https://bugbase.adobe.com/index.cfm?event=bug&id=3162442
Do post if you figure anything out! FWIW, I'm just targetting AIR 3.2 because at least there's a chance Adobe will fix it--where, they can't fix AIR 3.1 crashing on Kindle.
Copy link to clipboard
Copied
Thanks Phillip - it's really great you posted about it, I really appreciate all the time and hair pulling you have saved me! (Especially since my next step - before I saw your post - was that I too was going to try whacking some extra black video on the end!) Unfortunately, I have no workaround to contribute. It's likely that we'll just re-encode all our videos to FLV. We can't wait for Adobe to release a fix (in fact, there is no official word on a fix date, is there?) and I'm unwilling to add hacky hacks to our video player which might come undone in the next release anyway. Now, to dust off Sorenson Squeeze ...
Cheers,
Amanda.
Copy link to clipboard
Copied
no official date--but what's more risky is that they haven't said they'll implement the fix. Apparently they do have a fix--but, like always, there's a risk to put it in... so I've not heard that they will. MY bugs always seem so important--but this one really is a basic functionality that is lacking. FWIW, it works in AIR3.1 so, if you don't mind it crashing on Kindle Fire, it might work fine in 3.1. The "captive runtime" feature makes this really nice (instead of targeting whichever version of AIR the user has).
Not to push my buddy's company--but re-encoding as .flv was a pretty quick task as I was using videorx.com. If you have your own compression settings and a machine set aside to do renders I suppose you probably don't need videorx.com but it DOES do a great job at interpreting footage--plus, for me, it was very convenient to just re-encode everything with just a few clicks. The hardest part was just tracking all the files.