I wrote a new AIR app called LiveStreamer available now via the Adobe AIR Marketplace.
This started as a simple mechanism to display a live RTMP stream from Flash Media Server to a client machine and related projection system. So… not for broadcast over the web- just sending a live stream from one physical location to another.
While developing the application, I came across the need to test an RTMP stream and it was so simple using this app that I decided to expand it. In the current version (0.9.0), it will accept RTMP and HTTP streams- just type in the URL and you can easily test it in order to verify that it is correct before trying to publish anything on a website or whatnot. You can also use it as a fullscreen projection or display mechanism as was originally intended.
If you have some FLVs or MP4s or whatnot on your local machine- you can just drag those into the app to watch them. I’m thinking about adding some playback controls and other options a bit later.
Application for display of video streams via RTMP, HTTP, or local filesystem. Just drag in a file or enter a stream address and away we go!
At the University of Denver, we have built a good number of AIR applications at this point. Some are internal data management tools, others are full, complex, private applications such as the VPS Projection system, and then we have small utility apps like this which others may also find some use for. These we make available to others free of charge as part of our community outreach.
I had heard about a security concern over Amazon’s video streaming service a few days ago with a lot of people (including some at Amazon) blaming Adobe for the security hole. Apparently, there is an exploit in their (Amazons) player that allows stream-ripping a full video.
I’ve read the documentation on FMS3 security features and have used quite a few myself. Knowing these features, I could not understand how the Flash Player security model could be at fault- it seemed much more likely that the developers simply didn’t cover all their bases.
Whenever I read something like this, I am naturally concerned as I’ve thrown quite a bit of support behind FMS over the years.
Well, it seems that my hunch was correct and Adobe is not to blame. People are far too quick to pass judgement on things like this, whether it’s Adobe, Microsoft, Apple or some other giant corporation, everyone jumps on the bandwagon when a story like this breaks. Give it a rest…
In past versions of FMS, developers were barred from accessing raw audio and video data over RTMP and had to resort to a number of hacks and proxies to get around the restriction. As time went by and new versions of the Flash Player were released, a lot of these loopholes were blocked as well.
With FMS3, there is Client.videoSampleAccess: a property of the Flash Media Server 3 that allows direct access to raw stream data for video use (“audioSampleAccess” for audio). This can be used for things like producing visual audio spectrums or grabbing a still from a video stream. It is applied within the onConnect method of the Application server class as demonstrated here:
appClient.audioSampleAccess = "/";
appClient.videoSampleAccess = "/";
In the above example, the “/” signifies that any streams within the application directory are allowed to be sampled in this way. You can also specify a semicolon-delimited list of folder names instead if you need to be picky.
Something I came across today and the whole point of this post: even when you have Client.videoSampleAccess set up properly on Flash Media Server, you will still receive a security sandbox violation error #2123 if the stream data is not available. This can easily happen if you have a timer invoking BitmapData.draw every few milliseconds on loading content.
One way to get around this is using NetStatusEvent.NET_STATUS making sure it reports “NetStream.Buffer.Full” before attempting to access the stream data. Depending on what you are doing, you can oftentimes check the object recieving the stream data to be sure it is accessible first. this all seems really obvious now, but threw me for a bit of a loop, initially.
We’ve been running Flash Media Interactive Server 3 for over two weeks now on one of our media servers and I couldn’t be happier with the results. I was going to put off the upgrade from FMS2 for a few months while testing and waiting on a point release, but after having so many issues with FMS2 and with the security patch released last week, decided to just push ahead.
I’d recommend anyone having weird issues with FMS2 to upgrade as soon as you possibly can. It only takes about 15 minutes and will preserve all your current applications. I did need to update some of my client SWFs- but only because of how much more accurate this new version is.
While I had to continually monitor FMS2 for various problems, this new server has been nothing but stable, fast, and just a great performer all-around! I am honestly so pleased with the results that I want to give a general ‘thanks’ to the team involved in this latest release. You have taken a load off my shoulders!
I’m used to setting the ObjectEncoding to AMF0 when working with Flash Media Server 2, but haven’t realized till now that I also am required to do this when communicating with Coldfusion 8 through remoting:
NetConnection.defaultObjectEncoding = flash.net.ObjectEncoding.AMF0;
The error “Unknown object type tag (17)” was being generated by CF8 as I attempted to pass an Object in AS3 over remoting to CF8 interpreted as a Structure. Apparently, there is also the need to wrap any such Object within a container Object for it to be properly read by the CFC:
var wrapper:Object = new Object();
wrapper.submissionObject = submissionObject;
submissionResponder = new Responder(onSubmissionResult, onSubmissionError);
testConnection.call("some.cfc.Test", submissionResponder, wrapper);
The CFC function expects a Structure named “submissionObject” in this case.
I hope this is helpful for someone- I had a hell of a time digging up this information.