Alternatives to Flash Media Server

Man of Honour
Joined
16 May 2005
Posts
31,297
Location
Manchester
I'm looking to build a video library upload/hosting solution as a potential replacement for the software in use at work. Previously when I've done things like this I've used FMS but I'm hoping to avoid anything that requires a license fee this time (this will be part of my sales pitch for the software).

I've looked at a few bits and pieces that could possibly work and at the moment I'm extremely tempted by the psuedo-streaming plugins for apache/lighttpd/etc. My only concern with these is the possible memory overhead and a few reports I've read about html5 video playing not liking psuedo streaming. I could fall back to using flowplayer or jwplayer/etc but tbh I'd prefer to go for a pure html5 solution if possible.

One of the advantages of the place this would be deployed is that we can be a lot more arsey about requiring browsers other than IE 6, so that isn't a major concern.

Has anyone had any experiences with both FMS and other solutions? Or in the use of psuedo-streaming with html5 video playback?

edit: I should add that this will be running on a linux (ubuntu) server.
 
Last edited:
http://www.red5.org/ - Open-source alternative to Flash Media Server.

If you want an HTML5 solution, you don't need a streaming server. HTML5 is designed around H.264/WebM videos hosted on any HTTP server. I'm not sure about uploading; you'll probably need to design your own solution...maybe using a Java plugin?

I did read a while back about a native specification to bring webcam/microphone access to the browser, but I can't find it again, and I don't think any browser vendor is implementing it currently.
 
Yeah, I've looked at Red5 but I can't really use software that isn't fully released (latest seems to be 1.0RC?) for a production site. I'm also a little concerned about it's stability.

Creation of the upload side of things isn't an issue as I'll be coding that stuff from scratch.

I'm pretty sure I *do* need a streaming server even when using an html5 player. Progressive download isn't really an acceptable solution for users. Are you sure you're not getting the player and the server mixed up?
 
I'm pretty sure I *do* need a streaming server even when using an html5 player. Progressive download isn't really an acceptable solution for users. Are you sure you're not getting the player and the server mixed up?

May I ask why it's not acceptable? Are you streaming live stuff or just playing back pre-recorded stuff?

No I'm not getting them mixed up. I've served H.264 from a bog standard LAMP stack using the HTML5 video tag and it's worked fine. It would also be pretty easy to implement some kind of source switching based on quality on the client side.

I found this thread, where one person suggests using VLC to live transcode an RTSP stream to serve to the browser. Can you do that?
 
May I ask why it's not acceptable? Are you streaming live stuff or just playing back pre-recorded stuff?

No I'm not getting them mixed up. I've served H.264 from a bog standard LAMP stack using the HTML5 video tag and it's worked fine. It would also be pretty easy to implement some kind of source switching based on quality on the client side.

I found this thread, where one person suggests using VLC to live transcode an RTSP stream to serve to the browser. Can you do that?

Because progressive download of a large video file would lead to an unacceptable wait time for videos to play, which would be even more pronounced when attempting to seek early on. Pretty much the same reasons that using streaming rather than progressive download is preferable right across the internet. I've played videos that are just served as file from a web server and though it does work it really isn't an elegant solution (though using the streaming modules I mentioned in my first post could mitigate this if html5 video can deal with psuedo-streaming).

I don't really see transcoding as an acceptable solution as it would massively reduce the number of concurrent users that the system could support.

The system will be playing back pre-recorded videos of up to to 1-2 hours length (average much less than this) at ~720p. Switching between quality levels isn't a problem as, as you say, it's very easy to add a switch that can be controlled client side.
 
Last edited:
What are you expecting a "streaming server" to do that a "progressive download" won't?

Perhaps I shouldn't have used "progressive download" in my previous post.

Main issues are seeking, cross-platform support (I may need to stream to systems/applications other than the web app).

In addition to this (apologies for not brining this up in my OP), I will need to take reasonable steps to reduce possible copying of the data. I realise that this is somewhat of a futile exercise, but if I present the system and it's using methods that have really obvious piracy flaws then it will be picked apart.
 
Last edited:
H264 supports seeking.

Have a search for "Pseudo-Streaming". There's an apache plugin that supports "streaming" m4v/mp4 videos. That supports seeking, too. :)

As for the piracy stuff, there's only so much you can do, but I'd imagine building a client app to view the videos that uses a private key for encryption (of the video stream itself) is probably the strongest you'll get.

You've still got Fraps to worry about though..
 
I'm aware of the apache plugin - I even talked about it in two of my posts above :p I've also mentioned that I've read about html5 video tag having issues with psuedo streaming. I'm going to test this later today/tomorrow when I get some time. The apache (or other web server) plugin will probably not work for streaming to applications other than web apps though.
 
I saw LAMP mentioned, but nothing of http://h264.code-shop.com/trac :p

I fail to see why any app, let alone non-"web-app" would fail to view the video. I think what you actually mean is that your code for the client app will fail to consume the web-service. :p Can you expand on what you mean here? Can you define what you mean by "non-web-app" when in the context of streaming from a server?
 
I saw LAMP mentioned, but nothing of http://h264.code-shop.com/trac :p

I fail to see why any app, let alone non-"web-app" would fail to view the video. I think what you actually mean is that your code for the client app will fail to consume the web-service. :p Can you expand on what you mean here? Can you define what you mean by "non-web-app" when in the context of streaming from a server?

in my OP:
I've looked at a few bits and pieces that could possibly work and at the moment I'm extremely tempted by the psuedo-streaming plugins for apache/lighttpd/etc. My only concern with these is the possible memory overhead and a few reports I've read about html5 video playing not liking psuedo streaming. I could fall back to using flowplayer or jwplayer/etc but tbh I'd prefer to go for a pure html5 solution if possible.

Sorry, I'm using pretty dodgy terminology in regards to web-app/etc.

What I mean is that the streaming plugin will no doubt work fine for streaming video to a player embedded in a web page. However, I doubt it will work if I want to allow streaming to (for instance) windows media player, vlc, etc.
 
Back
Top Bottom