Skip to main content
U
Umanoff
Inspiring
September 29, 2014
Question

AIR for Android video issue

  • September 29, 2014
  • 1 reply
  • 2289 views

On Android, in an app that I’ve developed successfully for iOS, I’m seeing this problem:

There are 5 videos built-into the app. On Samsung phones (S3 and S4), running Android 4.4.2, at the first attempt to play a video there’s sound but no picture. After returning to the video menu and attempting again, video and sound play normally. If a video is stopped and another one is started, initially a frame of the previous video is displayed (for a fraction of a second), then play resumes normally with the chosen video.

The sound-but-no-video problem does NOT show up on a Nexus 7 running 4.4.3, although the flash-frame problem does.

I’m publishing with AIR SDK 15 packaging both with and without captive runtime to try to isolate the source of the problem. I’m using <contains video> true </contains video> in the descriptor.

This feels like AIR-for-Android buggishness. Any confirmation out there? Similar problems? Workarounds?

I’ve read somewhere that AIR runtime  v.3.3 may solve some video problems on Android, but not sure where to find an archived Android version of AIR that old.

This topic has been closed for replies.

1 reply

Colin Holgate
Colin Holgate
Inspiring
September 29, 2014

How are you playing the videos?

U
UmanoffAuthor
Inspiring
September 29, 2014

Not sure that I understand your question, Colin. I'm playing them within the app using StageVideo, which is the class that my app selects with GPU rendering. Is that what you mean?

Colin Holgate
Colin Holgate
Inspiring
September 29, 2014

Yes, StageVideo was the right answer! There are other ways of playing video (StageWebView, FLV via netstream, for example).

I have seen some issues on the lines that you're seeing. I think the big breakthrough for me was when I realized that the event that tells you that there is stage video available sometimes happens before you get to the point of showing the video. In the end I used this approach:

if ( _stage.stageVideos.length >= 1 ) {

  _enableStageVideo();

  }else{

  _stage.addEventListener(StageVideoAvailabilityEvent.STAGE_VIDEO_AVAILABILITY, _onStageVideoAvailability);

  }

That way, if the stage video availability has happened before you set your listener, the stageVideos length is already greater than zero.

As for seeing the previous video, that's the nature of hardware decoding. The buffer still has the remains of the last frame it showed. I never did this myself, but one option is to always play a silent black video after you close down the real video. Then the next video starts with a buffered black frame, which would be less annoying.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices