<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thank you for your quick reply. I would like to clarify a few
points if possible because I am not sure I explained myself
correctly in the previous message. <br>
</p>
<p>I believe the packets are not being written to the server socket
and are not being lost on the network. To check this I have
included the following<br>
</p>
<p>fprintf(stderr, "writeSocket(%d), sendTo() error: wrote %d bytes
instead of %u:, %i ", socket, bytesSent, bufferSize,
WSAGetLastError());</p>
<p>on line 404 of GroupsockHelper.cpp, just under</p>
<p>socketErr(env, tmpBuf);</p>
<p>And <br>
</p>
<p>fprintf(stderr, "Packet count %i, Seq num %i\n", fPacketCount,
fSeqNo);</p>
<p>on line 374 of MultiFramedRTPSink.cpp.<br>
</p>
<p>And then run the modified LIVE555 Media Server on one machine
with openRTSP (with -d 10) on another and wireshark running on
both machines. <br>
</p>
<p>If I request a .264 file with openRTSP, recorded from an ip
camera which unfortunately has large iframes, I observer the
following output from the Media Server</p>
<p>writeSocket(404), sendTo() error: wrote -1 bytes instead of 39:,
10049 Packet count 0, Seq num 65261<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 18:,
10049 Packet count 1, Seq num 65262<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 699:,
10049 Packet count 2, Seq num 65263<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:,
10049 Packet count 3, Seq num 65264<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:,
10049 Packet count 4, Seq num 65265<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:,
10049 Packet count 5, Seq num 65266<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:,
10049 Packet count 6, Seq num 65267<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:,
10049 Packet count 7, Seq num 65268<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:,
10049 Packet count 8, Seq num 65269<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:,
10049 Packet count 9, Seq num 65270<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:,
10049 Packet count 10, Seq num 65271<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:,
10049 Packet count 11, Seq num 65272<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:,
10049 Packet count 12, Seq num 65273<br>
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:,
10049 Packet count 13, Seq num 65274<br>
<b>writeSocket(412), sendTo() error: wrote -1 bytes instead of
1456:, 10035 Packet count 105, Seq num 21061</b></p>
<p>Note: I get the same output with and without wireshark tapping
the connection.<br>
</p>
<p>The first send errors of type 1049 (<strong>WSAEADDRNOTAVAIL) </strong>always
occur and do not effect the stream or the reported packet loss. I
have included them just for completeness in case I am wrong on
this.<br>
</p>
<p>The last error of type 10035 (<strong>WSAEWOULDBLOCK) </strong>occurs
only when I have increased OutPacketBuffer::maxSize to accommodate
the large iframes in the .264 video (removing the truncation).
This description for this error implies the socket is busy and I
should try again later:<br>
</p>
<p>"Resource temporarily unavailable.<br>
This error is returned from operations on nonblocking sockets
that cannot be completed immediately, for example recv when no
data is queued to be read from the socket. It is a nonfatal error,
and the operation should be retried later. It is normal for
WSAEWOULDBLOCK to be reported as the result from calling connect
on a nonblocking SOCK_STREAM socket, since some time must elapse
for the connection to be established."</p>
<p>OpenRTSP then reports a packet loss of 1. Wireshark on both
ends of the connection records the same number of RTP packets
however the packet with sequence number 21061 is missing. This
appears to confirm that this packet, as reported by the
application, is not written to the socket. Am I incorrect in this
assumption?</p>
<p>In addition I have observed a similar pattern when using the
proxy server. If I request 1-2 streams from the proxy then I do
not observer any of the above errors, however when I increase this
number I get lots of 10035 error codes and reported packet loss
from the openRTSP application.</p>
<p>I have tested this on Windows 8.1 and 10 in both directions.
Whilst I understand, if I have not made a mistake in my
assumptions, that this is probably a Windows issue and outside the
remit of live555 I would appreciate any help in
resolving/re-transmitting the lost packets I am observing.<br>
</p>
<p>Thank you again,</p>
<p>James.<br>
</p>
<div class="moz-cite-prefix">On 16/01/2020 20:40, Ross Finlayson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CCD58961-B79D-442D-9D99-26974DA30CB8@live555.com">
<pre class="moz-quote-pre" wrap="">The reason that you’re seeing lost packets has nothing to do with "OutPacketBuffer::maxSize”, nor with “sendto()”. It’s simply because the streaming is done over UDP, a ‘best efforts' datagram protocol, in which data delivery (unlike in TCP) is not guaranteed.
That’s simply how real-time (RTP) streaming works. Time-sensitive data is sent via an unreliable datagram protocol. Packets can get lost. If a packet gets lost, then it often would not make sense to try to retransmit it, because the data is time-sensitive. (By the time the receiver (e.g., media player) ended up getting it, it would no longer be of any use; the media player will have already moved on to a later frame.) (For very low-latency connections (e.g., over a LAN), there are feedback-based retransmission mechanisms available for RTP; however, we do not implement these.)
This confuses some people who are relatively new to the Internet, because most people's exposure to the Internet these days is solely via the World-Wide Web (HTTP), in which data is sent using a reliable protocol (such as TCP). But datagram-based streaming is different.
If data loss is a ‘deal breaker’ for you, then you should not be using RTP, nor our software. Instead, transfer your stream over TCP, using something like “nc”, or “scp”.
Ross Finlayson
Live Networks, Inc.
<a class="moz-txt-link-freetext" href="http://www.live555.com/">http://www.live555.com/</a>
_______________________________________________
live-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:live-devel@lists.live555.com">live-devel@lists.live555.com</a>
<a class="moz-txt-link-freetext" href="http://lists.live555.com/mailman/listinfo/live-devel">http://lists.live555.com/mailman/listinfo/live-devel</a>
</pre>
</blockquote>
</body>
</html>