[Red5devs] Replicating a live stream between servers

[Steven Gong]

Hi Victor,
Your design block for virtual provider/consumer looks good. Currently the
Red5 clustering prototype uses terracotta to share everything in the sending
buffer including AV packets and other RTMP packets. But that will be
enhanced as was indicated by terracotta experts that sharing raw data on
terracotta is expensive. The approach to enhance this is to put the buffer
on to the Origin server. Please refer to the wiki page on Terracotta for
detail: http://www.terracotta.org/confluence/display/wiki/Red5

Back to your approach. I think that your solution does not conflict with the
Red5 clustering solution we are working on. All your blocks  could be put on
the Origin server. Take live conference as an example, for our current
design, all the connections should be routed to the same Origin server to be
served. Now with the virtual tunnel between the Origin servers, we can
provide more than one Origin server to serve a live conference session.
That's promising, isn't it?

You are welcomed to join our clustering effort to make this happen. :-)

On 9/10/07, Victor <dreamland_skib2 at mail333.com> wrote:
>
>  Steven,
>
> I was reading your discussion about clustering with Terracotta this
> weekend.
> It's great! Maybe our clustering solution will be unnecessary soon :) Are
> you going to replicate video this way - using Terracotta shared storage?
>
> I believe that choice is good - that's why we continue working at our own
> clustering solution based on JGroups and live video replication between Red5
> instances. But we need some help with Red5.
>
> If possible, please give us some ideas - where to start the integration of
> "virtual consumer" and "virtual provider" with Red5 internals (see the
> attached picture explaining our idea).
>
> Thanks,
>
> Victor
>
>
>
> Victor wrote:
>
> Steven,
>
> thanks for your answer. Seems that we are talking about 2 different
> approaches in how to replicate video data between servers:
>
> 1) implementing a Pipe which will work via network - this is what you are
> implementing with Terracotta, correct?
> 2) adding a special Consumer at server-1 and a special Provider +
> BroadcastScope at server-2 (which will communicate each other) - this is
> what we are thinking about, please see the illustration attached.
>
> What do you think about our approach? Is it possible? Where to start in
> Red5?
> Yes, I see that there are many things to do - not only sending video/audio
> messages between servers. We are going to use JGroups to manage membership
> in cluster, JGroups can also be used to send "control" messages between
> nodes (such as "ReplicateBroadcastScope with name=xxx at node yyy", etc).
> But video/audio packets will be sent directly using UDP protocol.
> What do you think about this?
>
> Victor
>
>
> Steven Gong wrote:
>
> Hi Victor,
>
> On 8/30/07, *Victor* <dreamland_skib2 at mail333.com
> <mailto:dreamland_skib2 at mail333.com> <dreamland_skib2 at mail333.com>> wrote:
>
>
>     Dear Red5 developers,
>
>     we are investigating different cluster architectures using Red5. I
>     read
>     your emails about using Terracotta for clustering.
>     But in our project, which uses live video/audio streaming via
>     Red5, we
>     are going to replicate video/audio packets between 2 or more Red5
>     instances located in one LAN. I would like to know your opinion - what
>
>     is the best way to do the following things:
>     1) grab video/audio packets in Red5-instance1
>     2) put these packets into Red5-instance2
>
>     That is I am talking about integration points with Red5. Network
>     protocol between servers could be some UDP- or TCP-based protocol,
>     this
>     is not a problem.
>
>     Should we implement a separate consumer at Red5-instance1?
>     What about Red5-instance2? Do we need to create a separate
>     BroadcastScope and a provider there which receives video/audio packets
>
>     from Red5-instance1 via network and publishes them to its own
>     consumers?
>
>     Which classes in Red5 may be interesting for me? Where to start the
>     investigation?
>
>
> The streaming framework is built from a messaging system and all the
> components are connected with pipes. So if you want to send packets from one
> component to another, I believe it's a good idea to implement a networking
> pipe instead of a "InMemory" one.
>
> The detail could be: originally the message is pushed from
> "BroadcastScope" (which is actually a Provider) from a "InMemory" pipe to a
> subscriber (PlaylistSubscriberStream). Now you make the pipe across the
> network so that the message will be pushed to the networking pipe (via the
> network) to the PlaylistSubscriberStream.
>
> The big problem for your solution is how to share the server states across
> the nodes. For example, when a broadcast scope is created in one node, how
> could another node know it. We use Terracotta to solve this.
>
>     Any starting points would be great!
>
>     Thanks,
>
>     Victor
>
>     _______________________________________________
>     Red5devs mailing list
>     Red5devs at osflash.org <mailto:Red5devs at osflash.org><Red5devs at osflash.org>
>     http://osflash.org/mailman/listinfo/red5devs_osflash.org
>
>
>
>
> --
> Best Regards
> Steven Gong
>
>
> ------------------------------
>
>
>
> _______________________________________________
> Red5devs mailing list
> Red5devs at osflash.org
> http://osflash.org/mailman/listinfo/red5devs_osflash.org
>
>
>


-- 
Best Regards
Steven Gong

InfraRed5 Red5 Consultant: http://www.infrared5.com, steven at infrared5.com

Red5 Developer: http://osflash.org/red5,
http://jira.red5.org/confluence/display/~steven/Home

Modesty is an overrated quality in men of no great accomplishment.  -- Ricky
Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/red5devs_osflash.org/attachments/20070910/04fe538d/attachment.html