Hello Ross,

Thanks for the updates. Please see my comments inline.


On Thursday 07 December 2017 06:52 PM, Ross Finlayson wrote:
There is no bug here.  The problem is that your incoming stream(s) are 
exceeding the capacity of your network (which is often a lot less than the 
nominal bit rate of your network adaptor(s)).  If you try to stream at a rate 
that exceeds the capacity of your network, then you *will* experience packet 
loss.  Streaming over TCP will not (and cannot) overcome this.  (In fact, it 
makes the problem worse.  You should stream over TCP *only if* you have a 
firewall - between your server and client - that blocks UDP packets.  Otherwise 
you should do regular streaming over UDP.)
Sorry, I am not meant that there is bug. I wanted to know how do you I know whether the frames are dropped, once the function after FramedSource::afterGetting(this) is called. I tried enabling debug messages using DEBUG macro and increasing debugLevel using int Socket::DebugLevel = 4. Did not see message about drop. I may be wrong here.

I feel that in a 100Mbps isolated network, 3.5Mbps is a very nominal bitrate. So, there shouldn't be any drop with TCP.

This confuses many 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 never arrives faster than the receiver can process it.  
But datagram-based applications are different, and unfortunately many people 
these days - who think that the World-Wide Web is the entire Internet - don't 
appreciate this.  They try using the LIVE555 code and then, when they see 
network data loss for the first time in their life, mistakenly think that the 
LIVE555 code has to be to blame.
As I understand Live555 is a open source evolved over several years and used by many users across the world. So, I am trying to find out whether I have mistakes in usage using debugging.

Ross Finlayson
Live Networks, Inc.

live-devel mailing list

live-devel mailing list

Reply via email to