Flash Media Server 3 Feature Requests

Steve Wolkoff, Flash Media Server Product Manager, is asking the community for feature requests for the next version of Flash Media Server. I’ve put my comments there, but wanted to post them to myblog as well for reference.

1. A Remote SharedObject version with different licensing.

I don’t want video, I don’t want audio. I just want server-side scripting with Remote SharedObjects. I shouldn’t have to pay for things I’ll never use. There are a lot of multi -user, real-time data applications I’d like to create, and FMS is the best technology for those apps compared to XMLSocket, and yet to be released Binary socket alternatives. I’m down with Red5, but not all my clients will be.

It’s about empowering smaller markets. Think After Effects vs. Combustion / AVID; or Ruby on Rails vs. Java’s Spring & Hibernate. There is a lot of room for smaller scale, quicker to market applications that need the insane power FMS has in it’s data part. These apps don’t need video and audio.

If it’s a new product, so be it.

2. Streaming 3GP.

Being forced to use RealPlayer for streaming 3GP via Flash Lite is an f’ing joke. Give us an integrated solution! Or… I’ll keep RealPlayer on my phone, but at least allow the server to progressively stream them so I can not pollute my server. The reverse is true as well. 3GP conversion to FLV would allow better integration with this format from devices to desktop translation. A lot of weird, zombie-rific “solutions” are out there to allow clients to use cellphone video to be used on the web. 3GP to FLV server-side conversion could really be a nice niche here.

3. Backwards compatibility on Server-Side Scripting.

I’ve seen a lot of people ask for ActionScript 3 support, or even a move to a “mature” or “enterprise” language like Java. Whatever. Rhino’s ECMA 3 thing works great for me. If you move to a new language, fine, but keep it so I can still code in case-sensitive JavaScript like I have been. If you can’t expose the same API’s like they do for Flash 8 & 9 via AS1, AS2, and AS3, that’s fine; just make it so my old server-side code works in FMS 3. If not, at least allow some sort of scripting engine like .NET’s CLR where we can code in whatever we want.

4. SMS – Text Message Support

I’ve seen people wanting some form of VOIP bridge. It’d be nice to have some form of API for SMS too. If this is traditionally the forte of middle-ware, no problem.

3 Replies to “Flash Media Server 3 Feature Requests”

  1. Hey Jesse,

    Great suggestions! These of course are very useful for us developing Red5 as well.

    I have thought about providing a way to deploy content to mobile devices using 3GP and or RTSP. That shouldn’t be too hard to do given our infrastructure. The main hurdle would be the encoding/decoding legal issues surrounding On2’s VP6. Perhaps Adobe will have better luck doing that sort of thing given that they are already licensing the codec from them.

    The SMS idea is cool too. Assuming that there is a decent Java API for doing this sort of thing (Just googled and found this: http://www.objectxp.com/products/jSMS/ ), then hooking it up with Red5 should be cake.

    I’m also curious to hear why some of your clients might not be down with Red5. It seems to me that if you want a lightweight RTMP solution that supports server-side scripting with a low cost license arrangement (free), then Red5 would be a great solution for you/them.

  2. Thanks for your input, Chris! I really don’t know much about the technicals behind SMS so if it’s really that do-able, it sounds really fun!

    Regarding clients… well, no good answer here bro! Basically, there are people out there who don’t like open-source, mainly because it’s expensive and/or dangerous. For example, currently, it’s expensive and hard to find an FMS consultant. They certainly aren’t coming out of the woodwork compared to Java developers. It’s even worse with Red5 cause she’s so new. I know you’ve got a following on OSFlash, but it’s hard for me to pin down an applicable, competent community size yet, ya know?

    So, some companies don’t want to be left out on the cold. A lot pay consultants insane fee’s to make themsevles feel more comfortable. Like, the same dudes who pay for Windows and .NET solutions vs. Linux & PHP. The consultants selling the packaged solutions sometimes do better sales. While some may find it easier to sell open source solutions on merit alone, a lot of companies don’t sell on price. As such, the “open source is cheaper argument” doesn’t ring true with them, and thus they have no qualms paying large fee’s because they recognize all the support they are getting with those solutions. They want large, older companies behind their technology. It helps them have trust.

    Support obviously is questionable, but on paper in sale’s meetings it gives the suits warm fuzzy feelings, ya see?

    Same argument can be made against Ruby on Rails vs. Java Spring & Hibernate, ColdFusion vs. .NET, Perl vs. C. It’s not just open source vs. proprietary, or free vs. pay, but a combination of the services that surround the technologies, and their perception inside a company.

    For example, one of the con’s to Flex was it was from Macromedia. A server-side technology from a ‘small’ company didn’t score a lot of points with people who traditionally were used to Oracle n’ friends. I personally don’t understand the mentaility of those poeple, but I do recognize the reality of it existing. Adobe’s acquisition helped since they are a bigger company, but their server-side offerings aren’t well known compared to Microsoft, Sun, and IBM for example.

    So… perception. FMS, pay, big company, services around it, make you feel secure by spending more money.

    I don’t really care which one they use, I just want my RSO’s…

  3. We are looking for software API:
    1) API for Helix DNA producer to accept RGB data in real time from our own software
    2) API for Helix DNA server to save the file in 3GPP in original size (VGA or QVGA) and stream out QCIF to RTSP. Time sync is not important in our application.
    3) API for Helix DNA server to add channel or remove channel (one channel represents one camera source) (if authentication is provided in the following item, this request could be eliminated)
    4) API for Helix DNA server to receive connect, disconnect and authentication information from client software
    5) Sample code similar to http://www.astatech.com/news/200508/20050814.asp

    Please let us know if you could help or know any one who could.

Comments are closed.