AIR 32 runtime - Desktop video failing 100%

[KramSurfer2]

The net stream object is failing in the Publicly distributed AIR 32.

From the bug tracker which has had ZERO response from the AIR team:

After several hours of adding debugging code to help isolate the problem, I believe that the snippit attached as Bug.txt will let you most quickly hone in on the problem. [I'm sorry, but it is really no feasible, to create complete working application with the code, but, that said, there is nothing going on in the rest of the application that impacts on the failure.] What has worked for eons: A. A NetConnection is established via connect (null) for purely internal operation. B. That was working and still works as confirmed by the NET_STATUS of Success. C. A Net Stream is then created and its play (null) method is invoked because the media content is embedded in the swf file. D. A ByteArray version of the Clip [which is a 5 second .flv video] is then appended to the stream which is attached to the Video object. In proper operation, the clip plays and all is well. In the failed SDKs after Build 89, the stream reports: NetStream.Play.Failed NetStream.Play.Stop The failure is black and white constant. Test with Build 89, it works. Test with Build 100 or 103 it fails, consistently, always with the same error report.

Comment by Terry C.

https://tracker.adobe.com/#/view/AIR-4198798

This is causing already distributed software to not be able to show video content.   We need the fix or rollback NOW!

[zwetan_uk]

no code sample to illustrate the bug == CAN NOT REPRODUCE

[KramSurfer2]

There are TWO tickets that are several weeks old.

BOTH have code to reproduce. 

BOTH have zero response from Adobe.

[chris.campbell · Accepted solution]

We're doing a few things to resolve this bug.  First we've stopped the auto update of the shared runtime, so users will no longer be pushed a release that breaks video.  Next week we hope to release another shared runtime that will revert our video changes.  Auto update will be turned back on at this time so that everyone gets a shared runtime with working video.

We will also release a new AIR beta (runtime and sdk), with the actual video changes we wanted in place to begin with.  This beta will leverage the OS api's for video rendering in a new accelerated video pipeline.  We were shooting for next week for the beta, but with the revert and unscheduled runtime rebuild, it'll probably be the week after next.

[KramSurfer2]

Thank You!   I look forward to the improved video!  🙂

[itlancer]

With latest AIR SDK 32.0.0.129 beta all my tested FLV videos and mostly H.264 videos works fine for me with Windows devices. But it also have some problems:

1) If you disable hardware decoder:

NetStream::useHardwareDecoder = false

H.264 videos doesn't shows.

2) H.264 videos doesn't shows with StageVideo

3) H.264 videos doesn't shows with Stage3D VideoTexture

4) H.264 videos with resolution more than 4096 pixels by any side doesn't shows.

It would be nice to see these issues fixed with next AIR SDK builds.

[itlancer]

With latest AIR SDK 32.0.0.141 beta with Windows devices simple Video and StageVideo for me works fine but we still have some problems:

1) If you disable hardware decoder:

NetStream::useHardwareDecoder = false

H.264 videos doesn't shows.

2) H.264 videos doesn't shows with Stage3D VideoTexture

3) H.264 videos with resolution more than 4096 pixels by any side doesn't shows.

[gfantiniAqua]

With build 141 (compared to build 89) compiling for 32-bit, I'm seeing about triple CPU usage and half GPU usage when playing 4 simultaneous videos on an Intel i5 4690 with integrated HD 4600, 16 GB RAM, 64-bit Windows 10 Pro 1803. The video resolutions range from 540p to 1440p and are rescaled to the same size (about 240p), with app running in fullscreen at 1080p using classic Stage only.

Is this expected?

[itlancer]

With latest AIR SDK 32.0.0.144 beta with Windows devices we still have some problems:

1) If you disable hardware decoder:

NetStream::useHardwareDecoder = false

H.264 videos doesn't shows.

It works fine with AIR SDK 32.0.0.89.

2) H.264 videos doesn't shows with Stage3D VideoTexture. FLV H.263 video with Stage3D VideoTexture works fine. All it works fine with AIR SDK 32.0.0.89.

3) H.264 videos with resolution more than 4096 pixels by any side doesn't shows.

4) Video doesn't work without adding to stage and fails with NetStream.Play.Failed

It works fine with AIR SDK 32.0.0.89.

5) Draw Video to BitmapData just after NetStream.Play.Failed cause exception:

"SecurityError: Error #2123: Security sandbox violation: BitmapData.draw: app:/App.swf cannot access null. No policy files granted access."

It works fine with AIR SDK 32.0.0.89.

[xfirei62055307]

Can anyone else confirm AIR SDK 32.0.0.89 works fine with the Stage3D VideoTexture?

Also is it dependent on the AIR runtime version too, because we got 32.0.0.125 and 32.0.0.89 to choose from.

[xfirei62055307]

OK, when it comes to 89 build being the more stable release of the 2 current SDKs, does it also depend on the runtime aswell?

[zwetan_uk]

KramSurfer2  wrote

There are TWO tickets that are several weeks old.

BOTH have code to reproduce. 

BOTH have zero response from Adobe.

and BOTH never mentioned that the problem occurred with the SHARED runtime

[KramSurfer2]

True, but both meantion  'the problem still exists with AIR 32.0.0.116' which was the published AIR version.

Either way, I fix is happening and my clients are no longer updating into a broken application.  I sprent a lot of last week remoting desktoping or on the phone talking users through the uninstall / reinstall of AIR 31.

[zwetan_uk]

this kind of bug yeah can happen but it is super rare, and if you produce an app for the desktop

and you have that many customers .... why don't you publish with a bundle runtime?

just curious to know

[KramSurfer2]

We export right out of Flash Builder, utlilizing the built in bundler.  It's quick and easy and has never been an issue.

We create customized apps ( about 8-15 a week ) which are used in sales offices for about 9-24 months, depending on how well they sell and amount of product.  So we have about 300 'active' apps with, many with multiple installs and companion iOS apps.  The iOS apps obviously unaffected.  

Luckly we can contact most of our user base, but it didn't stop many from clicking the 'update' button.

These apps are the backbone of their sales floor and video an important component.  So it's important they work.

How do you bundle your runtime?  I've done tests with NSIS and Advanced Installer, but it's just another semi-complex step to add each time we create or update an app, which seems not worth it.

[zwetan_uk]

KramSurfer2  wrote

...

How do you bundle your runtime?  I've done tests with NSIS and Advanced Installer, but it's just another semi-complex step to add each time we create or update an app, which seems not worth it.

I always build my own installer with NSIS / Advanced Installer / WiX etc.
for the very purpose to use a captive runtime and so fully control updates

everything is done with command-line automated builds

btw AIR Runtime been updated to 32.0.0.125 today
Find and download archived versions of Adobe AIR SDK

[KramSurfer2]

awesome  good to know..

We manage updates through code in the app.  Of the three which do you think is easiest? 
A pro version of Advanced installer is  looking like my near term purchase.  I've used it twice for apps that requirer the 64 bit, for memory issues.

my thought is to make a template folder for the team and they just update the relevant fieldss and files.

[zwetan_uk]

There are many ways to do it, really depends on needs/goals.

Advanced installer can visually edit a build and then run it from the command-line later,

using something like Wix will give more control but require to learn the gritty details,

there are pros and cons, NSIS is good but then it generates exe not msi and in some case

you do want to publish msi (corporate networks, admin etc.).

My advise is to use a VM that reflect your general user setup, take the time to automate the build (even if it can take weeks),

test test test etc.

so you said

KramSurfer2  wrote

We create customized apps ( about 8-15 a week ) which are used in sales offices for about 9-24 months, depending on how well they sell and amount of product.

then you could work on a general automated build that you can customise with variables/templates

so if each apps has unique name and a version (like semver) you could just reuse the same automated build
but passing the name and version as parameters when you build or from a config file etc.

[KramSurfer2]

haha .. yeah too many options is one of the reasons we just used the default packager...  🙂

[Paul Istoan]

This is a critical bug. All my Adobe Air applications that use video are useless now. Don't really understand why no one is willing to respond or roll back this update?

[gfantiniAqua]

With build 144, I'm still seeing about triple CPU usage and 1/3 GPU usage.

Edit: compared to build 89.

[clouds40936465]

me too.

Tested in desktop.

Bug tracker:

Tracker