> Op 17 jul. 2015, om 10:15 heeft Ross Finlayson <[email protected]> het
> volgende geschreven:
>
>
>> On Jul 15, 2015, at 9:13 PM, Erik Oomen <[email protected]> wrote:
>>
>> I’m using live555 to stream H264+PCMU audio between two servers (both are
>> bare Linux 64bit under my control). Due to firewall reasons I have chosen
>> to use TCP. The sending server has 100Mbit FD, the receiver has 20Mbit FD
>> bandwidth, 8 hops between them and average 9msec RTT.
>>
>> For some reason the sender will stop sending because the sendDataOverTCP is
>> seeing EAGAIN on a regular basis (every minute more or less). Perhaps due
>> to congestion, a saturated line or something like that
>
> Yes, you are exceeding the capacity of your network - likely because of the
> firewall(s) that are inbetween the server and client. (Note, BTW, that the
> "capacity of your network” - especially for TCP connections - usually has
> little to do with the nominal bitrate of the network interfaces at each end.)
Ok, clear. I also understand that tcp is not suited for hard realtime
communications, however sometimes I have to fallback to TCP.
>
>> My question: What is the reason to not use ‘forceSendToSucceed’ for the
>> framingHeader in sendRTPorRTCPPacketOverTCP?
>
> Because this would cause the server to block for an unpredictable (and
> possibly significant) length of time, which would prevent the server from
> being able to doing anything else (like serving stream to other client(s)) in
> the meantime. That’s why we do blocking packet sends only when we really
> need to - i.e., after we’ve already successfully written the framing header.
Ok thats clever. However, once the framing header hits a failure, the socket
is not used anymore (see below) and it is now up to the client to detect a
timeout (VLC for example just waits for 10 seconds before stopping because
there is no more incoming data). testRTSPClient just stops receiving.
Perhaps not only de-registering but also closing the socket would be a better
shutdown?
>
>
>> Because, this is causing my stream to stop.
>
> No, it’s not causing your stream to ‘stop’. It’s possibly causing some of
> your RTP datagrams to not get transmitted - which is reasonable and
> appropriate when your network is congested. (Note that you’re still
> streaming datagrams, even though you’re framing them over a TCP connection.)
I don’t think so because this condition is triggered if sending the framing
data hits an error and the socket is removed for further usage (not closed
however).
} else if (sendResult < 0) {
// Because the "send()" call failed, assume that the socket is now
unusable, so stop
// using it (for both RTP and RTCP):
removeStreamSocket(socketNum, 0xFF);
}
This behaviour can be seen with the testRTSPClient. The connection is active
however the RTP datagrams are not transmitted anymore due the the
‘removeStreamSocket’.
>
>>
>> Changing the forceSendToSucceed in first sendDataOverTCP in
>> RTPInterface::sendRTPorRTCPPacketOverTCP fixes my problem
>
> No, it doesn’t (unless you’re planning on only ever streaming one stream at a
> time from this server, and possibly not even then). In any case, if you
> modify the supplied code, you can expect no support on this mailing list.
In my case I’m receiving video over 3G mobile connection with ‘huge’ variable
latencies. This video is retrieved on a server which re-restreams this data
over RTSP to another server. The few delays when using RTP over TCP are of no
concern.
I completely understand. The modifications are just to understand the behavior.
Erik Oomen.
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
