RE: How many vic's on the same machine?

["Matthew Delco" <delco@bmrc.berkeley.edu>]

> Here's the problem - when I start the video capture programs in reverse
> order, the AG vic first, then the Delco vserver, the vic on the display
> machine never shows the vserver mjpeg stream, just the H.261 stream.
>
> I've been wondering if there is some problem on the video capture machine
> with the both capture programs sharing the same mcast address or if the
> display machine vic receive a H.261 stream as the first stream it never
> looks/recognizes a mjpeg stream on that same mcast address.
>
> Any notions?

I've noticed something analogous before when dealing with 2 RTPtv streams to
the same vic.  If a vserver was started, and vic was receiving that stream,
then vic never saw the second vserver that was started up at a later time.
However if 2 vservers were started at the same time, then vic could see
both.  From what I recall, I verified that both vservers were transmitting
in both situations, so I assumed it was a vic problem of some sort.  Were
you able to verify that the vserver was actually transmitting in both the
situations that you described?

I'm asking because I got to thinking that the on-demand multicast feature in
vserver could be causing the problem, so using the "-A" (transmit
continuously) command-line parameter might fix the problem if the vserver
is, in fact, not transmitting.

The vserver will start (or continue) to transmit when it receives a RTCP
receiver report that is reporting information about that vserver, or if a
client is transmitting an empty RTCP receiver report (i.e., the receiver is
reporting its own existence, but it has no servers to report information
about).  So, in the case where the ag vic is started first, by the time the
vserver is started the only RTCP traffic the vserver sees is RTCP server
reports from the ag vic, and RTCP receiver reports (from the openmash vic)
that are "addressed" to the ag vic.  Thus, by the time the vserver starts it
sees/thinks that no one is interested in the stream, and thus doesn't
transmit RTP data (however, a vserver will always transmit RTCP server
reports to make its existence known).

The basic issue is whether (in the on-demand mode) to have the vserver error
on the side of being quiet (which is the current default), or error in
"talking" too much (which is potentially bad if you have a dozen vservers
that are all transmitting even if only one of those sources is being
"watched").  In the case of vclient, it can only receive one stream at a
time, which is why I erred on the quiet side (and the "-A" mode is for those
who want a "talkative" vserver).  A vserver should send RTCP sender reports,
even if it isn't transmitting.  This allows a vclient to become aware of all
of the various servers that are present on a multicast channel.  The vclient
can be sent a command (vic rpc or standard input, when enabled) that tells
it to advance to the next multicast source, in which case the vclient stops
producing RTCP receiver reports for the "old source" (causing that vserver
to eventually timeout and stop transmitting if no other clients exist for
that source), and start transmitting receiver reports for the "new source"
(causing that vserver to start transmitting, if it isn't already).

I'm just left wondering in what situations does vic transmit a receiver
report for a given source: when it receives RTP data from that source,
and/or when it receives RTCP sender reports from that source?  I'm guessing
that RTCP server reports alone is not sufficient.

MD