RE: [Asterisk-video] Simple vidéo conference

Tue Jun 12 15:20:26 CDT 2007

Hi All,
  Just thought I'd chip in and mention that we have Continuous Presence working in a derivative app_conference for H.263, H.261 and H.264 - up to 16 participants per conference. We're using our own codecs I'm afraid so can't share much of what we've done. But just to let you know that app_conference has made a good platform from which to work. And before anyone gets all upset - we do give back as well as take (T.140, VIDEOCAPS, Maxcallbitrate etc).
  We did find a number of deadlocks in app_conference that were're working on producing a patch for - hopefully Mihai will be able to review them when we've completed the patch and benefit everyone.
  We've found that a Core2Duo 2.2GHz can do up to 16 way H.263 CIF conference - assuming there are a few common sets of video bitrate/resolutions that need to be encoded. For example that would be 16 decodes, typically 4 encodes but only one view, so only one composition and scaling session required. We had to use a lot of MMX/SSE to get the performance but it can be done. We found this to be a similar performance to OpenMCU.

  Sorry for the delay in getting this to you Mihai.

John

> -----Original Message-----
> From: asterisk-video-bounces at lists.digium.com [mailto:asterisk-video-
> bounces at lists.digium.com] On Behalf Of Lorenzo Miniero
> Sent: 10 June 2007 10:36
> To: asterisk-video at lists.digium.com
> Cc: dave cantera
> Subject: Re: [Asterisk-video] Simple vidéo conference
> 
> 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
> 
> 
> _______________________________________________
> --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
> 
> ________________________________________________________________________
> This e-mail has been scanned for all viruses by Star. The
> service is powered by MessageLabs. For more information on a proactive
> anti-virus service working around the clock, around the globe, visit:
> http://www.star.net.uk
> ________________________________________________________________________