So what is Red5 ?
As a non java-geek it's like to explain it to my collegues like this (in english that should be understandable for a 12-year-old) :
Red5 is a piece of javacode that runs on a server and listens on a port for commands. Since it's java you can run it on near every platform (Unix (like Linux) , Windows , OS/X). It's no binary, it's a class that is execute by Java that needs to be installed on the server. Like Java v1.6 JRE/JDK.
You can extend the basic javacode by writing an 'Application'. The application is a class called 'Application'. The application extends the builtin javacode and has event-handlers, private and public methods, properties etc.
You can connect from Flash (Player) (SWF) to Red5 but also from Flex, standalone Java-programs (including/using pieces of the Red5-sourcecode).
When you connect to Red5 you connect to an instance of the Application-class. This instance has a name like a directory, a path, "/" by default (aka root).
The instance behaves like a singleton ; it's executed once when the server starts. The class has events like 'appStart' (and 'appStop') which fire as soon as the application-class is loaded by the server. The instance is 'always on'. Once started it stateful. If you don't restart your server the instance will remember all properties until you change them or shut it down.
If your client connects to the instance you can call/execute functions of the instanced application/class/singleton. If you'd modify a public property then another client that would connect later would be able to read the data from that public property. This is the basic 101 for
inter-client-communication.
Imagine we'd have a basic 'chatroom' application that has 30 clients which connect to Red5.
You could execute a function on your client that calls a function in the application-class which fills for example a public string. All other clients could read that string.
The server can also call functions on the client, if the client allows this. That way the server can push data to a client even while the client is 'sleeping'. The protocol used for sending data back and forth is 'AMF v0 or AMF v3'. AMF3 allows more complex datastructures to be sent over the line than AMF0.
The 'room' thing is like a 'new' instance of the application-class (well not really but this is easier to get the idea).
(it's a scope (subscope) of the main instance/singleton))
This new instance also has a name like a directory structure like "/room1".
If 10 clients would connect to that instance and modify a public property
then only those 10 clients would be able to read that property. If you'd
disconnect from "/room1" and don't clear the instance/scope then it
maintains state. You could connect to it 1 week later and 'continue'. (If
the server hasn't restarted or the garbagecollector hasn't 'removed' the
room/instance).
You get the idea when 20 other clients connect to instance "/room2" and 5
more connect to "/room827".
You'd see 3 rooms on the server : [room1] [room2] [room827] each having
different clients connected to.
The video(streaming) thing isn't more complex ; a client connects to a
'room' (like '/room1') and starts a "netstream" object/class on his client.
The data will be magically transferred to red5 and red5 will identify the
stream by a name (e.g. "stream1"). All clients can open a "netstream" class
on their client too and ask for 'stream1' to play from the server. The
server then happily starts sending data to all those clients.
Streaming video is nothing more than 'copy incoming data (from a file or
another client) to other clients'. Red5 does not encode, recode, transcode ;
it just copies data to and from clients. Currently Red5 knows how to 'copy'
data for the Sorensen Codec (flash 6) and the VP6 codec (flash7+). A Flash
Player client can ONLY publish a stream using Sorensen Codec (it does NOT
have a built in VP6 encoder). Flash 9 can READ the H.264 encoded data but
CANNOT encode H.264 and stream to Red5.
Red5 cannot accept H.264 encoded streams YET, ppl are working on that. Red5
will not recode, transcode or decode the H.264 stream, it will only
distribute it. More or less like a normal fileserver. You'd copy a zip-file
to a fileserver and if other clients connect to the fileserver they can
download that zip-file. The server itself does not decompress/recompress
that zip-file in any way.
Red5 CAN drop frames while sending data to a client that does not have
enough bandwidth. It just drops audio- and video-frames resulting in bad
video (most of the times). If you want to serve various qualities of the
same stream then you should encode those streams in advance or publish ,
from a client , more than 1 stream e.g. one with a 50kbit bitrate and one
with a 500 kbit bitrate.
Think of Red5 as a satellite ; the sat will receive a signal from the ground
and distribute it to many clients. If your client cannot receive a certain
'HD'-stream it should subscribe to a SD-stream. The satellite won't recode
the HD-signal for you.
The server doesn't care if the stream is a live stream (being publish at the
very moment) or a FLV file (videofile, FLV format, like WMV, MPG, etc)
stored on the server.
