[Live-devel] Increasing OutPacketBuffer::maxSize results in sendto() returning WSAEWOULDBLOCK

Ross Finlayson finlayson at live555.com
Fri Jan 17 06:45:38 PST 2020


First, as always, make sure that you are using the latest version of the software (the only version that we support); see
	http://live555.com/liveMedia/faq.html#latest-version

> writeSocket(412), sendTo() error: wrote -1 bytes instead of 1456:, 10035 Packet count 105, Seq num 21061
[…]
> 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:

What’s happening here is that packets are being written to your OS faster than your OS can output them to the network.  This is a side effect of having ridiculously large key frames (something that you should try to avoid; see below).  Your OS’s internal socket buffer is overflowing before it can transmit all of the packets that make up the key frame.

Our code, by default, sets an OS internal socket buffer size of 50 kBytes, which is usually more than enough - but apparently not in your case.  You could, however, change (increase) this value by modifying line 184 of “liveMedia/OnDemandServerMediaSubsession.cpp”.

Your *real* solution, however (other than not using Windows; geez, it’s 2020 :-) is to avoid having huge key frames.  Instead, you should reconfigure your encoder so that each key frame is encoded as a sequence of ’slice’ NAL units, rather than as a single NAL unit.

People often have trouble streaming H.264/H.265 video with extremely large key frames, if each key frame gets encoded as a single NAL-unit.  The problem with this is that these NAL units get sent as a (very long) sequence of RTP packets - and if even one of these RTP packets gets lost, then the whole NAL (key frame in this case) will get discarded by the receiver; see

	http://lists.live555.com/pipermail/live-devel/2011-December/014190.html
	http://lists.live555.com/pipermail/live-devel/2012-August/015615.html
	http://lists.live555.com/pipermail/live-devel/2013-May/016994.html
	http://lists.live555.com/pipermail/live-devel/2014-June/018426.html
	http://lists.live555.com/pipermail/live-devel/2014-June/018432.html
	http://lists.live555.com/pipermail/live-devel/2014-June/018433.html
	http://lists.live555.com/pipermail/live-devel/2014-June/018434.html
	http://lists.live555.com/pipermail/live-devel/2015-March/019135.html
	http://lists.live555.com/pipermail/live-devel/2015-April/019228.html

For streaming, it’s better to encode large key frames as a sequence of ‘slice’ NAL units.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/




More information about the live-devel mailing list