<div>We've uploaded some ethereal output files from various points in our network demonstrating the problem.</div>
<div>We would appreciate if anyone could take a look and maybe tell us something which we might be missing...</div>
<div> </div>
<div>The files can be downloaded from this link:</div>
<div><a title="http://www.yousendit.com/download/UW16TGs2eFh5UkUwTVE9PQ" href="http://www.yousendit.com/download/UW16TGs2eFh5UkUwTVE9PQ">http://www.yousendit.com/download/UW16TGs2eFh5UkUwTVE9PQ</a></div>
<div> </div>
<div>Many thanks,</div>
<div>Ilya<br><br> </div>
<div><span class="gmail_quote">On 4/30/07, <b class="gmail_sendername"><a href="mailto:ilya77@gmail.com">ilya77@gmail.com</a></b> <<a href="mailto:ilya77@gmail.com">ilya77@gmail.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br><br>
<div><span class="q"><span class="gmail_quote">On 4/30/07, <b class="gmail_sendername">Ross Finlayson</b> <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:finlayson@live555.com" target="_blank">
finlayson@live555.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">>We are wondering if either TS or RTP provide some means of forward error<br>>correction<br><br>No, not at present. However, there is ongoing work in the IETF (the
<br>"FECFRAME" working group) towards standardizing FEC on media streams.<br>(This FEC would occur just above the UDP level, so could be applied<br>to raw-UDP Transport Streams, as well as RTP streams (of any payload
<br>type).)<br><br>>Re: Are you watching the video in real time or just recording it? you<br>>could use openRTSP to record the video stream and see if it helps at all to<br>>do this. in openRTSP you can adjust the amount of time to wait for a late
<br>>packet.<br><br>Not really. If incoming packets are not being reordered on the<br>network, then the RTP reception code (regardless of the application)<br>will wait indefinitely for RTP packets to arrive; there is no concept
<br>of a 'late' packet.<br><br>If packets *are* being reordered on the network (a rare occurrence),<br>then the code will wait up to a certain time (default: 100ms) for a<br>'late' packet to arrive. You can change this time, but note, once
<br>again, that it is relevant only if packets are arriving out of order<br>- which rarely happens.<br>--</blockquote>
<div> </div></span>
<div>We are currently using VLC to view the media stream, and our goal is to set up a server which is capable of streaming to any RTSP / MPEG-2 TS capable player, so in essence - we are using live555 media *server* capabilities, but not client capabilities (unless VLC uses portions of the live555 project).
</div>
<div> </div>
<div>We are trying to stream a pre-recorded transport stream file, and from what we see on the sniffer dump, packet reordering does *not* occur on the network.</div>
<div> </div>
<div>Regarding error correction - as far as I can tell, the transport stream does provide a container for error correction information, but it is somewhat opaque and transport-dependant, which led me to hoping that RTP might provide some method of forward error correction...
</div>
<div> </div>
<div>Am I correct that apart from trying to resolve network infrastructure problems (which might be impossible since there are too many instances involved in the process) we have no means to achieve reliable media delivery?
</div>
<div> </div>
<div>Many thanks,</div>
<div>Ilya</div>
<div> </div></div></blockquote></div><br>