http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_16458&sliceId=1
http://osflash.org/documentation/rtmp
Monday, June 30, 2008
Wednesday, June 25, 2008
AMF-
At home I've been working on an AMF serializer/deserializer for common lisp. It feels like I'm finally getting some traction with lisp-I'm actually starting to understand some code people post to usenet/etc.
next step: rule the world.
next step: rule the world.
FISA Bill-Speech by Senator Christopher Dodd
If you haven't been paying attention, the House and Senate are on the verge of passing a bill that provides the Executive the ability to run warrentless wiretaps(circumventing the FISA court and it's retroactive warrant system, it seems) and provides retroactive immunity for the telecom industry's shannegans. This is an industry that cooperated with the Bush Administration in the current, illegal round of warrantless wiretaps.
Here is his speech. Contact your Senator to prevent a closure vote(a vote for closure will end his filibuster).
Here is his speech. Contact your Senator to prevent a closure vote(a vote for closure will end his filibuster).
Friday, June 20, 2008
A nice post about Red5 from their mailing list...
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.
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.
Saturday, June 14, 2008
Wednesday, June 11, 2008
Wednesday, June 04, 2008
The Server Side of Flash/Flex: Options and Armchair Evaluations
I've got a project I've been working on privately for a while now(six months!?) that requires server integration. My app needs (secure)video streaming and AMF(think an Adobe-controlled, fast binary web service specification).
To those ends, I've been evaluating Red5 and pyamf.
Red5 is an open source product that provides both of these features(plus shared remote objects). Pyamf, as it's name suggests just implements the AMF protocol.
Red5 may do everything short of flossing your teeth, but the development environment seems kinda stupid. The architecture seems to have more moving parts than necessary. It's JEE based, so lots of restarts as you work, and everything is interface based (and also really poorly documented). But, apparently, it's just brain dead simple to stream hosted videos. So I'm going to use it for that.
Pyamf does one thing and seems to do it well. It's documentation is light, but the user email list is quite active and since it does one thing, simply, it may not need that much. It's also compatible with Google App Engine, with is one of the server implementations I'm considering(really, the only one. I don't want to manage more web servers/dbs than I've got to and I don't want to cross into the weirdness that is rails shared hosting). So I'm going to use pyamf for client-server integration. Now I just gotta get better with Python.
Fin.
To those ends, I've been evaluating Red5 and pyamf.
Red5 is an open source product that provides both of these features(plus shared remote objects). Pyamf, as it's name suggests just implements the AMF protocol.
Red5 may do everything short of flossing your teeth, but the development environment seems kinda stupid. The architecture seems to have more moving parts than necessary. It's JEE based, so lots of restarts as you work, and everything is interface based (and also really poorly documented). But, apparently, it's just brain dead simple to stream hosted videos. So I'm going to use it for that.
Pyamf does one thing and seems to do it well. It's documentation is light, but the user email list is quite active and since it does one thing, simply, it may not need that much. It's also compatible with Google App Engine, with is one of the server implementations I'm considering(really, the only one. I don't want to manage more web servers/dbs than I've got to and I don't want to cross into the weirdness that is rails shared hosting). So I'm going to use pyamf for client-server integration. Now I just gotta get better with Python.
Fin.
Red 5 Tutorial
I think this guy is doing a presentation at Flashbelt here in the Twin Cities in MPLS(I can't go). Red5 looks like an awesome project but it's documentation seems fragmented and incomplete.
These look like good video tutorials....
These look like good video tutorials....
Subscribe to:
Posts (Atom)
