<div dir="ltr">Ross,<div><br></div><div>Thanks for your patience and time responding to this issue....I do understand that many of my questions and inquiries are probably outside the scope of this development list. With that said, I will be brief in my comments.</div>
<div><br></div><div>With your input and running through numerous permutations from an implementation / testing perspective I believe I now know what the issue may be. </div><div><br></div><div>If N=1</div><div><br></div><div>
SETUP = SETUP</div><div>PLAY = PLAY</div><div>PAUSE = PAUSE</div><div>TEARDOWN = TEARDOWN  </div><div><br></div><div>When N=1 I do not encounter the problem (irregardless of number of back-end streams). Client is able to close the recording file as expected. Works in desktop players and validates as html5 compatible video. My particular client (VLC) is definitely sending a TEARDOWN when closing the recording file.</div>
<div><br></div><div>If N > 1</div><div><br></div><div><div>SETUP == SETUP (maybe slightly different than N=1)</div><div>PLAY == PLAY</div><div>PAUSE == PAUSE</div><div>TEARDOWN = PAUSE (Here is what I believe is the issue)</div>
</div><div><br></div><div>For  N > 1  clients there is no actual TEARDOWN?? When  N > 1 client sends TEARDOWN request, the response from ProxyServer is not precisely the same as if it where an actual TEARDOWN?? Another possibility would be that ProxyServer SETUP response is not the same for N > 1 client???</div>
<div><br></div><div>The recording files for N > 1 clients work fine with every desktop player I use (VLC, Totem, QuickTime, ffplay, Mplayer...etc), however the file no longer validates as html5 video.</div><div><br></div>
<div>This is definitely not a critical issue...just a nuance I would like to better understand.</div><div><br></div><div><br></div><div>Thanks,</div><div><br></div><div>Bob</div><div><br></div><div><br></div><div><br></div>
<div><br></div><div><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 24, 2013 at 1:36 AM, Ross Finlayson <span dir="ltr"><<a href="mailto:finlayson@live555.com" target="_blank">finlayson@live555.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div dir="ltr"><div>2. Registered the single back-end server (works as expected; using new transport header options) . BTW, the option for setting suffix is a nice additon!</div>
</div></blockquote><div><br></div></div>FYI, you can now use our new application "registerRTSPStream" (in the "testProgs" directory) for this.</div><div><br></div><div><div class="im"><br><blockquote type="cite">
<div dir="ltr"><div>3. Connected a single client (VLC) to record the proxy stream to file. (Connects fine and I see debug output recording the connection)</div><div><br></div><div>4. Connect another client (VLC) to proxy stream to record a second file. (Connects fine, but I do not see any debug output showing this connection???)</div>
</div></blockquote><div><br></div></div>That's normal, and expected.  What's important to understand is that the diagnostic output generated by the "LIVE555 Proxy Server" (when you give it the "-V" option) is only for the proxying functionality (between the proxy server and the back-end server).  Proxying starts (by sending "SETUP" and "PLAY" commands) once the first front-end client connects, and stops (by sending a "PAUSE" command) once the last front-end client disconnects.  During that time, the proxy server will continue to serve an arbitrary number of connecting/disconnecting front-end clients, but won't have any effect on the connection between the proxy server and the back-end server - until the last front-end client disconnects.  That's why you don't see any additional diagnostic output when the second front-end client connects - but data will still be streamed to that front-end client, as expected.</div>
<div><br></div><div><div class="im"><br><blockquote type="cite"><div dir="ltr"><div>I have attached a debug file that reflects steps (1-6). If you could take a quick look to see if there something obvious that would be great.</div>
</div></blockquote><div><br></div></div>Your file looks OK; the proxy server appears to be working normally.</div><div><br></div><div>Once again, what I suspect is happening is that when you have N>1 front-end clients, you are experiencing some packet loss (because, in this case, each outgoing RTP packet from the proxy server is being transmitted N separate times (once to each front-end client)).  And apparently your stream recording software is not tolerant of data loss.  You can verify this by instead running "openRTSP" with the "-Q" (report QOS) option as your front-end clients.</div>
<div class="im"><br><br><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;white-space:normal;font-family:Helvetica;word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;white-space:normal;font-family:Helvetica;word-spacing:0px">Ross Finlayson<br>
Live Networks, Inc.<br><a href="http://www.live555.com/" target="_blank">http://www.live555.com/</a></span></span>
</div>
<br></div></div><br>_______________________________________________<br>
live-devel mailing list<br>
<a href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a><br>
<a href="http://lists.live555.com/mailman/listinfo/live-devel" target="_blank">http://lists.live555.com/mailman/listinfo/live-devel</a><br><br></blockquote></div></div></div>