Hi Ross, hi Nitin, I am also experimenting packet lost or malformed packets when I use high bitrate clips and rtp over tcp streaming transport.
When I turn on the DEBUG mode, I noticed that sendRTPoverTCP generally returns "failed" status. The errno is set to EAGAIN (or EWOULDBLOCK) and is not handled at all by the method. As a reminder, this eagain flag simply means that the ressource is not avalaible at the moment and we should try later. For some reason (in my case, OS socket buffer overflow) if we get a EAGAIN error value, this means that the socket will be triggered later and it should be possible to write the remaining data at that time. I think this mechanism is not handled for the moment. Ross, do we agree with this ? We simply do not send remaining data and read again from source. Do we? In my mind the potential solution would be : - use both signal at the task scheduler level : "readable" and "writeable"; - if we get a EAGAIN status while we are writing data, attach a callback to the service scheduler and block reading operation on the stream (from a file, another network socket,...) We should also store the remaining data to write, i.e. the data that has not be sent yet. At the time the socket will be ok, the task scheduler get an event that will trigger the callback, which will write remaining data. If the write operation is complete, read again from source. What do you think about this problem? Thanks in advance for your help. Best Regards, David -- _______________________________________________ Surf the Web in a faster, safer and easier way: Download Opera 9 at http://www.opera.com Powered by Outblaze _______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
