<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">I checked and this truncation seems to be caused by large packet loss. Is this the way UDP operates- if bandwidth is not enough it drops packets? How would it be possible to make sure server sends UDP packets only as fast as the network can let through, so that client gets all packets? I'm talking about the Unicast scenario...<br><br>Cheers,<br><br>Michael<br><br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: "the-bishop@rogers.com" <the-bishop@rogers.com><br>To: live-devel@lists.live555.com<br>Sent: Thursday, January 4, 2007 2:49:56 PM<br>Subject: Frame truncation if network bandwidth is not enough<br><br><div style="font-family: times new roman,new
york,times,serif; font-size: 12pt;"><div>Hi Ross:<br><br>I have the following problem. I stream videos using Unicast over the Internet using live555 library. The frames are provided by DirectShow streams. The frames are complete, so no framer class from live555 is used. Instead, I simply feed the DirectShow frames to my class derived from SimpleRTPSink. If the network bandwidth is not enough to deliver samples, they arrive truncated on the client side (in afterGettingFrame function). What can possibly be causing it? Is it a part of RTP standard- to truncate frames if they can't be delivered on time? I'd much prefer for samples to arrive late, then to arrive truncated... Any ideas?<br><br>Thanks,<br><br>Michael<br></div></div></div><br></div></div></body></html>