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.
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
fprintf(stderr, "writeSocket(%d), sendTo() error: wrote %d bytes instead
of %u:, %i ", socket, bytesSent, bufferSize, WSAGetLastError());
on line 404 of GroupsockHelper.cpp, just under
socketErr(env, tmpBuf);
And
fprintf(stderr, "Packet count %i, Seq num %i\n", fPacketCount, fSeqNo);
on line 374 of MultiFramedRTPSink.cpp.
And then run the modified LIVE555 Media Server on one machine with
openRTSP (with -d 10) on another and wireshark running on both machines.
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
writeSocket(404), sendTo() error: wrote -1 bytes instead of 39:, 10049
Packet count 0, Seq num 65261
writeSocket(404), sendTo() error: wrote -1 bytes instead of 18:, 10049
Packet count 1, Seq num 65262
writeSocket(404), sendTo() error: wrote -1 bytes instead of 699:, 10049
Packet count 2, Seq num 65263
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049
Packet count 3, Seq num 65264
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049
Packet count 4, Seq num 65265
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049
Packet count 5, Seq num 65266
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049
Packet count 6, Seq num 65267
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049
Packet count 7, Seq num 65268
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049
Packet count 8, Seq num 65269
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049
Packet count 9, Seq num 65270
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049
Packet count 10, Seq num 65271
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049
Packet count 11, Seq num 65272
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049
Packet count 12, Seq num 65273
writeSocket(404), sendTo() error: wrote -1 bytes instead of 1456:, 10049
Packet count 13, Seq num 65274
*writeSocket(412), sendTo() error: wrote -1 bytes instead of 1456:,
10035 Packet count 105, Seq num 21061*
Note: I get the same output with and without wireshark tapping the
connection.
The first send errors of type 1049 (*WSAEADDRNOTAVAIL) *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.
The last error of type 10035 (*WSAEWOULDBLOCK) *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:
"Resource temporarily unavailable.
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."
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?
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.
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.
Thank you again,
James.
On 16/01/2020 20:40, Ross Finlayson wrote:
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.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
