[AG-DEV] multi-input capture (was AccessGrid 3: What information is available)

[Andrew Rowley]

Hi,

One solution to the headless vic and bridge problem is to make the headless
vic send-only.  This means that you don't bind the unicast socket to any
particular port.

I am sceptical about the problem being in quickbridge alone; only one
unicast socket can be bound to a particular port on any machine.  So when
vic is used in unicast mode, all the vics try to bind to the same unicast
port to listen for data.  Since SO_REUSEPORT is enabled, the port is set to
be reused, and so they all appear to be successful.  However, only one of
these unicast port bindings can actually receive traffic.  

So far as I can tell, vic creates two sockets each for RTP and RTCP.  It
uses one of these to receive and one to send.  So if QuickBridge used the
ports as well as the address, it would probably try to send traffic back to
the vic send socket, not the vic receive socket, so no data at all would be
received.

This is just my understanding, so let me know if I'm wrong...

Andrew :)

============================================
Access Grid Support Centre,
RSS Group,
Manchester Computing,
Kilburn Building,
University of Manchester,
Oxford Road,
Manchester, 
M13 9PL, 
UK
Tel: +44(0)161-275 0685
Email: Andrew.Rowley at manchester.ac.uk 

> -----Original Message-----
> From: Thomas D. Uram [mailto:turam at mcs.anl.gov]
> Sent: 01 June 2005 18:08
> To: Andrew Swan
> Cc: Andrew Rowley; 'Steve Smith'; ag-dev at mcs.anl.gov
> Subject: Re: [AG-DEV] multi-input capture (was AccessGrid 3: What
> information is available)
> 
> Andrew S.:
> 
> You've got it right wrt the toolkit handling of resources.  We've
> considered allowing
> services to use multiple resources; doing so would be fairly simple, but
> implies
> additional complexity in service configuration.
> 
> There is currently in CVS an OMVideoProducerService which does headless
> capture.  This
> approach is in accord with the current design, and resolves the 'too many
> vics with muted
> windows' problem that AndrewR mentioned.  It doesn't address the problem
> with a single
> application getting traffic from a bridge; in fact, it worsens it, because
> video data may
> be coming into one of the headless vics, and not into a vic gui where the
> user can see
> (muted) streams.
> 
> The unicast problem is with QuickBridge, in that it tracks clients by IP
> address alone.
> If it did so based on ip/port, it could track multiple clients on one
> machine and send
> data to them.  I tried briefly to resolve this, but haven't had time to
> get back to it.
> If someone else would like to, great.  We definitely will consider this
> issue when looking
> at alternative bridging solutions ;-)
> 
> Tom
> 
> 
> On 06/01/05 03:50, Andrew Swan wrote:
> > Andrew Rowley wrote:
> >
> >>>be possible to take advantage of a multi-input vic since there
> >>>is a 1-to-1 mapping of "resources" (i.e., video capture devices)
> >>>to node services.  if that is incorrect, i'd be interested in a
> >>>clarification.
> >>
> >>[...]
> >>In summary, it would be useful to have a video tool that sends and
> receives
> >>all the video streams so that only one instance need be opened on any
> >>system, and that instance will cope in both a unicast and multicast
> >>situation.
> >
> >
> > sorry, let me clarify the question.  as i understand the code,
> > one of the methods in the AGService api is SetResource(), which
> > tells an AGService which resource to use, where a resource is
> > an i/o device like a video capture card for a video service,
> > or a sound card for an audio serivce.  the way these resources
> > are discovered is different in 2.3 and in the cvs head but in
> > either case, only a single resource may be assigned to an
> > instance of a service.  this assignment is done manually by the
> > node operator from the "Select Resource" dialog that is presented
> > when adding a new service instance.
> >
> > so, if we had a multi-input encoder, it wouldn't be possible to
> > write a MultipleInputVideoProducerService since only a single
> > resource (i.e., video capture card) could be assigned to an
> > instance of the service.  of course, the encoder could attempt
> > to open and encode from each video capture card that is present
> > and just ignore the configuration done from the NodeManagement
> > app but that doesn't seem like a very good idea.
> >
> > i think this explanation is correct -- can somebody who is more
> > familiar with the code either confirm that this is right or
> > explain what has been overlooked?
> >
> > assuming that this evaluation is correct, do people think the
> > simplest solution be to make headless capture work correctly?
> > or would it be better to somehow change the abstractions in the
> > core toolkit?
> >
> > -Andrew
> >
> >