Okay, well, for stream delivery instead of live streaming, it is easier. You can use either red5 or erlyvideo for that too. Just remove all the live streaming parts from the config, and skip the part of doing the realtime broadcast push. You will still use RTMP for streaming DELIVERY to the viewer applet. This is an on-demand stream, but from a staged file that was pre-processed.
What you would do instead is this. Capture the video you want to deliver, to a local file in a format such as mpeg, or avi, quicktime, etc. then use handbrake, vlc, ffmpeg or whatever to create a FLV (Flash Video) or MPEG TS (TS is Transport Stream which is like DVD) file from it. (There are tons of websites that talk about this file conversion process.) Upload the FLV or TS file to directory on the remote server (probably your web server) which is also running red5 or erlyvideo, and let the red5 or erlyvideo process manage the delivery of the stream to the player application. You just have to initialize the player application with the proper parameters to get the video file over the RTMP protocol. If you look at the URL http://erlyvideo.org/examples/play and look at the HTML source, find the first SWF file (the top most viewer applet in that page) look at the line that looks like this: <param name="flashvars" value="server=rtmp://erlyvideo.org&file=video.ts" /> That is the parameter given to the player. Notice that the URL starts with RTMP. This means that the viewer will open a connection back to the server on port 1935 and start the playback stream from the file called video.ts (an MPEG transport stream format file) If you have problems supporting RTMP on port 1935, you can also implement RMTPT, which is RTMP over HTTP on port 80. the URL would start with RTMPT:// in that case. The advantage of this method is that you don't have to download the entire file over port 80 HTTP and cached in the browser cache, etc. before playback. With RTMP-delivery, the Flash player can start streaming the video stream almost immediately, you might have a 1hr clip, maybe it's 900Mb large. Once you start, after a few Mb like 1 or 2Mb have been downloaded, it can start playing, and keep a buffer of only what is needed to play in memory. The RTMP protocol supports remote SEEK command, so if the user wants to jump to the end of the stream, the command goes to the server, and the RTMP stream jumps to that location, etc. it is far more efficient than abusing HTTP and delivering the entire file for this. Because of the complexity of installing these applications (buliding from source could be a requirement) it's best to select your server distribution based on what pre-built packages exist for these RTMP delivery products. I had to build from source because I was on Centos and there are no RPM downloads for it, but someone has built erlyvideo in a DEB package which works on Debian and Ubuntu. Similarly with red5, I think there is a Debian repository for it, (and probably RPM too) DK On 9/22/2010, "Paul Saenz" <[email protected]> wrote: >Wow, that is everything I need to know. Right now all I need is staged >content delivery from files, but, in the future, I'm sure I'll be needing >this info for live streaming. > >Thanks > >On Wed, Sep 22, 2010 at 12:17 PM, David Kaiser <[email protected]> wrote: > >> Hi Paul, >> >> I've been researching something very similar for my church the past two >> weeks. I am assuming you want to do real-time or "live" streaming? >> (Or maybe I misunderstood and you just want staged content delivery from >> files?) >> >> For live streaming, you essentially need 2 systems, the one that you run >> locally is the "broadcaster" or "streamer" setup, where you have >> camera or other source, etc. plugged into a computer, and it streams it >> out to a site on the internet that is a "reflector". >> >> For the reflector, you can either use existing services or stand up your >> own with a commercial or open-source server solution. >> >> The existing reflector services include sites such as justin.tv, >> ustream.tv, livestream, and it is rumored that youtube will be offering >> a streaming service in the future. >> >> The existing proprietary reflector server applications include Apple >> Distributed Streaming Server, Adobe Flash Media Server, as well as other >> has-beens products like RealNetworks helix or any Microsoft offering. >> >> Essentially the Adobe one is the best architecture. The best existing >> open-source reflectors such as red5 and erlyvideo are compatible with >> the Adobe stream formats. >> >> For the broadcasting application: In the proprietary realm, you would >> use Apple Quicktime Broadcaster (only runs on Mac or Windows) and stream >> RTSP protocol to one of the reflectors, OR you would run Adobe Flash >> Live Media Encoder (only runs on Mac or Windows) to stream RTMP to one >> of the reflectors. They do pretty much the same thing - grab the video >> source, encode it (H.264 for video, and AAC for audio) then package it >> inside a protocol (RTSP for Apple, RTMP for Adobe) and then stream it to >> the reflector. >> >> For open source broadcaster solutions, you need to look at building a >> solution with a couple different components. For grabbing the video and >> encoding it, use ffmpeg or vlc, they run on your broadcast pushing >> machine, and you somehow have to grab your video source from the camera, >> encode the video to H.264, the audio to AAC, and then you need to find a >> way to wrap it into RTSP or RTMP protocol an push it up to the >> reflector. There are some documented solutions for this on the red5 or >> erlyvideo.org sites, but you will need to tweak quite a bit to get them >> to work. >> >> For an open-source reflector, there is red5, which is written in Java, >> and there is Erlyvideo.org, which is written in Erlang. They both allow >> you to stream live content from a single source, and then you deploy >> Flash applet video viewers on a web page that connect to the reflector >> and view the output streams. >> >> One of the main advantages of switching to the self-hosted open-source >> reflectors is that the "free" sites such as justin.tv, ustream or >> livestream require you to use their viewer applet, and unless you pay >> for their commercial level of service (can be from $100 to $350 per >> month) they periodically cover the bottom 20% of your video picture with >> advertising. >> >> We've tried using their unpaid service, and we've had issues with >> people seeing ads (on top of our church broadcast) that are for either >> other churches buy ads with our church keywords, or people buying >> anti-church ads with our church keywords. By running our own reflector >> and using an open-source viewer applet - we can control all the content >> and don't have to deal with other people's advertising. >> >> I've been playing with using Apple Quicktime Broadcaster to stream to >> both Red5 and Erlyvideo reflector running on Centos5, and the stream >> would never properly be initialized and work. >> >> I have had better success using Adobe Flash Live Media Encoder. I've >> used it with both the red5 and erlyvideo reflectors. Erlyvideo uses >> less CPU so should scale much better than the Java-based red5, but it is >> much more work to install and configure. I had to install git, pull the >> latest Erlang runtime source code, compile and install Erlang from >> source, and then use git to pull and compile the Erlyvideo application. >> I've sunk at least 100 hours into setting up Erlyvideo so far, and >> still don't have it tuned to production level (for us, that's 100 >> viewers for 90 minutes with no interruptions.) >> >> >> For the viewer web applet, you should look at either FlowPlayer (Gnu GPL) >> or JWPlayer - which are both Flash based players. You just drop them >> into the HTML, set the properties to connect to your reflector and tune >> in to the RTMP stream. >> >> With some careful work, (and quite a bit of it) you can go almost 100% >> open-source with this solution. The video grabbing, the mpeg (h.264 and >> aac) encoding, the streaming, the reflecting and the flash-based viewer >> applet can all be open-source and all work on Linux. The only component >> that you might be non-open-source would be the Flash runtime, and this >> may even work with gnash instead of the real Flash product (i haven't >> tested with Gnash I keep the Adobe runtime on my Ubuntu machine) >> >> Ok, now you know everything I know about this - good luck and let me know >> when you get it working. >> >> If I get the ffmpeg or vlc broadcasting from Linux camera source up to >> the erlyvideo reflector working, I'll demo at a future LUG meeting. >> >> Thanks, >> DK >> >> >> >> On 9/22/2010, "Paul Saenz" <[email protected]> wrote: >> >> >I am looking for a video web hosting solution. It is for a church, so they >> >don't have a lot of money. >> >I realize that you get what you pay for, so if they want something cheep, >> >then it may lack in reliability, >> >bandwidth, and/or some other aspect. Nevertheless, if someone has a >> >suggestion of some service that >> >may be affordable (exactly what affordable means, I cannot say at this >> >point) then it would be greatly >> >appreciated. If you offer a suggestion, then please note what aspect of >> >service may be lacking. Bandwidth >> >is not a issue at this point. If anyone on the list provides this type of >> >service, please contact me offlist. >> >I am helping this church pro bono, but I never haggle over price. If >> someone >> >has a service, then they name >> >their price. So I won't be trying to bring someone's price down because >> it's >> >a church. This is still America Right? >> > >> >Thanks >> >Paul >> _______________________________________________ >> LinuxUsers mailing list >> [email protected] >> http://socallinux.org/cgi-bin/mailman/listinfo/linuxusers >> _______________________________________________ LinuxUsers mailing list [email protected] http://socallinux.org/cgi-bin/mailman/listinfo/linuxusers
