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

[Thomas D. Uram]

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
> 
>