Multicast stream

[Stijn]

Hi,

I'm new to red5, but I want to know if following is possible or not
with red5.

I want to have following scenario:
A streaming server sending multicast video content to a couple of flex
(flash) clients, who are able to play these multicast streams with the
flash player.

Question:
Is multicast possible with rtmp? (or with rtp and then transcode to
rtmp for the flash player on the client)
->If yes, how can this be achieved?
->If no, is it somehow possible with other tools?

Kind regards, and thanks in advance!
Stijn.

[Rajdeep Rath]

Basically what you are asking is that you want the server to act as a radio broadcaster ? right?

yes you can do that. initiate the stream from server end using the serverstream class in red5. then your clients can connect to it using flash/flex client just as they connect to any normal video stream.

Rajdeep

[Stijn]

Rajdeep,

Thanks for your quick reply!
Yes, this is basically the idea, except that it is for broadcasting
video content.
Is there an example application that is using this? Is your proposal
then using the rtmp protocol? And can the flashplayer connect to a
multicast stream?

Kind regards,
Stijn.

On 1 mrt, 22:14, Rajdeep Rath <rajdeepr...@gmail.com> wrote:
> Basically what you are asking is that you want the server to act as a radio
> broadcaster ? right?
> yes you can do that. initiate the stream from server end using the
> serverstream class in red5. then your clients can connect to it using
> flash/flex client just as they connect to any normal video stream.
>
> Rajdeep
>

[Rajdeep Rath]

dont think of it as a multicast. its like broadcast from server. so people cant control the stream, but only watch it.

http://red5.org/wiki/Examples/ServerSidePlaylists

have a look at this.

Rajdeep

[Stijn]

But to be clear, only one stream will be set up for multiple clients
watching the stream?
I'm asking this because this is my main concern. It shouldn't be that
for every client a new connection is set up.

Thanks,
Stijn.

On 1 mrt, 22:33, Rajdeep Rath <rajdeepr...@gmail.com> wrote:
> dont think of it as a multicast. its like broadcast from server.
> so people cant control the stream, but only watch it.
>
> http://red5.org/wiki/Examples/ServerSidePlaylists
>
> <http://red5.org/wiki/Examples/ServerSidePlaylists>have a look at this.
>
> Rajdeep
>

[Stijn]

But to be clear, only one (phisical) stream will be set up for
multiple clients watching this stream?
I'm asking this because bandwidth is my main concern. No multiple
streams should be set up!

Kind regards,
Stijn.

On 1 mrt, 22:33, Rajdeep Rath <rajdeepr...@gmail.com> wrote:
> dont think of it as a multicast. its like broadcast from server.
> so people cant control the stream, but only watch it.
>
> http://red5.org/wiki/Examples/ServerSidePlaylists
>
> <http://red5.org/wiki/Examples/ServerSidePlaylists>have a look at this.
>
> Rajdeep
>

[Andy Shaules]

one publish stream and many subscribers streams

but yes, that is one physical. It would be the publish stream.

[Rajdeep Rath]

[Rajdeep Rath]

Honestly speaking what you are saying sounds a bit incorrect. You will have one server side stream. But number of connections to it depends on number of clients connecting to it.

There is no way you can change that by law of networking.

Rajdeep

[Ignacio Lopez]

Rtmp is unicast, as far as i know. You can achieve the results you
want but each client will connect to the server en pull the stream

2010/3/2, Rajdeep Rath <rajde...@gmail.com>:

[Stijn]

It's still not clear for me. If every clients pulls a stream, does
this means that there will be more streams sent out by the server?
In a broadcast (or multicast) scenario, only one stream is broadcasted
and the clients connect to it just by listening to this (existing)
stream.

On Mar 2, 12:04 pm, Ignacio Lopez <ignacio.lo...@gmail.com> wrote:
> Rtmp is unicast, as far as i know. You can achieve the results you
> want but each client will connect to the server en pull the stream
>

> 2010/3/2, Rajdeep Rath <rajdeepr...@gmail.com>:

>
> > Honestly speaking what you are saying sounds a bit incorrect. You will have
> > one server side stream. But number of connections to it depends on number of
> > clients connecting to it.
>
> > There is no way you can change that by law of networking.
>
> > Rajdeep
>

[Ignacio Lopez]

The server will need as much bandwidth as clients connected multiplied by the size of stream, if that's what you are asking...

There is only one physical stream tough, but each customer receives their own bytes so, in a sense, you are dealing with "multiple" streams...

[Trevor Burton]

I'm not sure - but i think we might be talking about the difference between live and vod streaming?

With VOD you have a video file on your server and when a user connects and requests the stream it starts playing from the beginning - or they might scrub to a different part of the strem. So in this case each user is seeing a different part of the stream depending on how long they've been connected or the user's actions.

With Live streaming you're broadcasting a stream to each connected client and each is seeing the same part of the stream.

It's the difference between watching what's on TV and watching a DVD i suppose.

In both cases there is only 1 'stream' - 1 copy of the file/pipe/whatever that represents the video container. But each client may be viewing a different part of that stream.

hope i got this right - and that it helps

T

--
Trevor Burton
http://www.flashmonkey.org
http://www.infrared5.com

[Stijn]

Ignacio,

This was indeed what I wanted to know.

So to summarize, there is no added value by 'broadcasting' the stream
to reduce the network bandwidth.
Thus, this is not really broadcasting (or multicasting) because the
more clients ask for the stream, the more bytes are being sent by the
server.

This is really a pity because this was exactly what I wanted to
achieve. Are there other tools/possibilities to have 'real'
broadcasting?

Thanks for your help!

Kind regards,
Stijn.

On Mar 2, 3:09 pm, Trevor Burton <worldofpa...@googlemail.com> wrote:
> I'm not sure - but i think we might be talking about the difference between
> live and vod streaming?
>
> With VOD you have a video file on your server and when a user connects and
> requests the stream it starts playing from the beginning - or they might
> scrub to a different part of the strem. So in this case each user is seeing
> a different part of the stream depending on how long they've been connected
> or the user's actions.
>
> With Live streaming you're broadcasting a stream to each connected client
> and each is seeing the same part of the stream.
>
> It's the difference between watching what's on TV and watching a DVD i
> suppose.
>
> In both cases there is only 1 'stream' - 1 copy of the file/pipe/whatever
> that represents the video container. But each client may be viewing a
> different part of that stream.
>
> hope i got this right - and that it helps
>
> T
>

> On Tue, Mar 2, 2010 at 1:25 PM, Ignacio Lopez <ignacio.lo...@gmail.com>wrote:
>
>
>
> > The server will need as much bandwidth as clients connected multiplied by
> > the size of stream, if that's what you are asking...
>
> > There is only one physical stream tough, but each customer receives their
> > own bytes so, in a sense, you are dealing with "multiple" streams...
>

[Camille Lochet]

I think Stijn is talking about the red5 packets being multicast vs. unicast.

 

In any case Red5 would be unicast... 

 

Camille

[Marc Torrent]

RTMFP is intended for P2P and Red5 supports it, I think. Several examples should be searching google.

P2P != Client-Server

P2P = unicast but distributed through all users

2010/3/2 Camille Lochet <skyha...@gmail.com>

[Golden Habenero]

Just out of curiosity, what kind of player would be used in such a p2p setup? 

Also multicast is very dependant on routers not blocking multicasting and there is very very little chance of it working over the internet and that's why multicast is almost exclusively used in closed networks and has nothing to do with VOD or live...

Cheers

Eiki, Idega Open Source

[Rajdeep Rath]

RTMFP is not supported by red5 yet !

[Walter Tak]

Real broadcasting will only work when 'the internet' will finally support
multicast packets but as Eiki wrote that's not happening right and never
will be since it would mean that every signal someone would be broadcasting
would have to be repeated to every corner of the planet.

Thus ; often only available in very local networks e.g. a LAN or perhaps a
WAN of some company, university or perhaps a local community.

If you want to reach 100 users then your server will send out 100 streams.
Nothing can be done about that.

Bandwidth (cost) isn't that much of a problem though if you have a decent
service (commercially viable) and know a bit about serverhosting and
'flatfee' tarifs.

Regards,
Walter

----- Original Message -----
From: "Stijn" <stijn.der...@gmail.com>
To: "red5" <red5in...@googlegroups.com>
Sent: Tuesday, 02 March 2010 15:18
Subject: [Red5] Re: Multicast stream

[Golden Habenero]

Yes Walter is right.

I looked at this myself when considering an IPTV solution for a custom internet based tv receiver and the only solution I saw for the 1 connection per client was to go with P2P based streaming.
There are some players/plugins doing this today but I haven't looked at this solution space in a while, google "p2p streaming video"

cheers
-Eiki

[Rajdeep Rath]

yes true. currently flash adobe stratus is in beta, and red does not work with rtmfp

[Ignacio Lopez]

There is a sibling project called blue5 aimed at supporting rtmfp, but
it doesnt seem to be very active now....someone knows if there is any
other way outside stratus to test p2p in flash??

2010/3/3, Rajdeep Rath <rajde...@gmail.com>:

[Rajdeep Rath]

i think adobe live cycle services support p2p. you can create a developer's account here:

http://www.adobe.com/devnet/flashplatform/services/collaboration/

[Ignacio Lopez]

Cool
Any other alternative outside adobe??

2010/3/3, Rajdeep Rath <rajde...@gmail.com>:

[Rajdeep Rath]

may be you can use JMS with BlazeDS to get p2p support in open source mode. Read here:

http://www.infoq.com/articles/blazedsjms1