<div class="gmail_quote">On Thu, Aug 5, 2010 at 3:19 PM, <a href="mailto:mike@grounded.net">mike@grounded.net</a> <span dir="ltr"><<a href="mailto:mike@grounded.net">mike@grounded.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">> Try not to think in terms of A/V. I would consider this more of a data<br>> transfer; request and fulfillment.<br><br></div>Fair enough, so just like any other RTP based service, voip for example.<br>
<div class="im"> <br>> When the UPnP device requests it, yes, Myth will send data to it. The<br>> UPnP is not picking anything up; it's receiving the data that it<br>> requested -- data that is sent directly to it, and nowhere else. If<br>
> you have a second UPnP device request the same channel, a second<br>> stream will be sent to the second device (creating twice the LAN<br>> traffic).<br><br></div>Got it and yes, that's exactly what I'm looking for. For example, just like some of the voip stuff I do, there is an authentication process, what amounts to a heartbeat and RTP only after calls are established.</blockquote>
<div> </div>
<div>Not really like VOIP that is a live stream, not a recording. More like playing an MP3 from a file server.</div>
<div> </div>
<div>All UPNP does is play back a file on a remote device... that file may still be being recorded when you started playback... but your not playing a live stream directly from the capture device.</div></div>