[Asterisk-video] Simple vidéo conference

[Lorenzo Miniero]

Hi Dave,

to have a better view of what I mean with floor control, you can have a look 
at the BFCP RFC (http://www.ietf.org/rfc/rfc4582.txt), which is exactly the 
protocol we implemented.

To sum it up, a floor is a logical element: when you associate this token to a 
resource (e.g. audio) or a set of resources (e.g. audio and video together), 
the floor becomes the permission to access this resource. To get this 
permission you need to request the floor, which is done by means of a floor 
control protocol, in this case the BFCP. This way you can moderate the access 
to the resources: all the requests are handled as queues, and there can be 
chairs (moderators) which decide if a request has to be accepted or denied.

So, when you associate a floor to video, you basically let a video stream by a 
participant be part of a conference only if this participant has been granted 
the video floor. As the paper states, it can be used to limit bandwidth if 
each participant in a conference with N users receives N-1 video streams, to 
limit to M<N the maximum allowed active video streams for example.

However, this is not the case of the videomixer we are talking about in this 
thread, since both with basic videoswitching and with video mixing involved, 
you would always only get one video stream back. And in both cases you can 
have floor control: you could want to have a floor-moderated video, where 
only one person at a time can be granted video (floor-moderated 
videoswitching, which is what we already have in our prototype), or you could 
want to have a floor-moderated video, where N persons at max at a time can be 
granted video (floor-moderated video mixing, where sources are enabled and 
admitted in the mix only if they have the floor).


I hope I clarified it all, regards,
Lorenzo


On Sunday 10 June 2007 04:59:36 dave cantera wrote:
> sorry, I am a neophyte to video over IP... I didn't know what floor
> control was so I googled it...
>
> from this Parc Research paper:
>
>     http://www.parc.xerox.com/research/publications/details.php?id=5634
>
> it looks like implementors would have a challenge with bandwidth along
> with encoding/decoding.  if I am running a videoconferencing server and
> connecting all channels in and out, that is really sucking up my
> bandwidth.  could make the application too expensive for most.
>
> would it be appropriate to put a throttle option in the config files to
> limit bandwidth or video updates to every other frame or every 4th frame
> unless you are the speaker then you get full throttle?  I would not
> mention the throttling ability except I can see that if development
> shoots for four streams you know that four will want to invite eight,
> and eight sixteen.  before you know it everyone will want to use it and
> that would be cost prohibitive for the provider and make it only
> available to those who can pay the high bandwidth rates the provider
> will have to charge.  don't know if throttling is possible but it is
> better to talk about it sooner than later...
>
> below is the parc research abstract...  I don't know what licensing
> requirements would be from parc...
> daveC
>
> Floor control alternatives for distributed videoconferencing over IP
> networks
>
> Garcia-Luna-Aceves, J. J.
> <http://www.parc.xerox.com/research/publications/results.php?author=1607>;
> Mantey, P. E.; Potireddy, S. N. Floor control alternatives for
> distributed videoconferencing over IP networks. Proceedings of IEEE
> CollaborateCom 2005: The First International Conference on Collaborative
> Computing: Networking, Applications and Worksharing; 2005 December
> 19-21; San Jose; CA; USA.
>
> Applications that require the communication of multiple video streams
> can consume considerable bandwidth and computing resources, which poses
> a challenge for the widespread use of videoconferencing over the IP
> Internet. On the one hand, the bandwidth of the link connecting a given
> participant to a videoconferencing session may not be enough to support
> many video streams at bit rates of 500 kbps or more, especially when the
> participant is connecting to the rest of the Internet through a wireless
> link. On the other hand, the processing capacity of a participating site
> may not be enough to decode several video streams in real time. This
> paper explores the use of floor control over videoconferencing
> applications as a means to support videoconferences with many
> participating sites, but with a processing and communication overhead
> per site that is equivalent to a two-party videoconference. The main
> tradeoff we explore is the scalability attained with floor control
> versus the latencies incurred with floor transitions, which can be much
> too disruptive to the videoconference participants. We present a viable
> compromise in which only the video stream of the "floor holder" is sent
> to all sites, but the floor-passing protocol is such that it supports a
> brief overlap of the transmissions from the old and the new floor
> holder, such that the participants in the videoconference can
> instantaneously switch over to the media streams of the next speaker in
> an apparently seamless transition. Experimental results and
> implementation in a research video-conferencing system show that the
> proposed protocol can run effectively, eliminating race conditions,
> while maintaining scalability and reliability.
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-video mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-video