[Live-devel] Proxy Server (Multiple Client / Recorded File Issue)

[Bob Bischan]

Ross,

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.

With your input and running through numerous permutations from an
implementation / testing perspective I believe I now know what the issue
may be.

If N=1

SETUP = SETUP
PLAY = PLAY
PAUSE = PAUSE
TEARDOWN = TEARDOWN

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.

If N > 1

SETUP == SETUP (maybe slightly different than N=1)
PLAY == PLAY
PAUSE == PAUSE
TEARDOWN = PAUSE (Here is what I believe is the issue)

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

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.

This is definitely not a critical issue...just a nuance I would like to
better understand.


Thanks,

Bob







On Thu, Oct 24, 2013 at 1:36 AM, Ross Finlayson <finlayson at live555.com>wrote:

> 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!
>
>
> FYI, you can now use our new application "registerRTSPStream" (in the
> "testProgs" directory) for this.
>
>
> 3. Connected a single client (VLC) to record the proxy stream to file.
> (Connects fine and I see debug output recording the connection)
>
> 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???)
>
>
> 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.
>
>
> 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.
>
>
> Your file looks OK; the proxy server appears to be working normally.
>
> 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.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131024/33fba081/attachment-0001.html>