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