<FONT face="Verdana" size="2">>That should not be happening. The client (VLC) does a 'seek' <BR>>operation by doing a RTSP "PLAY" command. The response to this <BR>>"PLAY" command will contain a "RTP-Info:" header, which our library <BR>>will automatically interpret by setting the <BR>>"MediaSubsession::rtpInfo" structure (and setting the <BR>>"rtpInfo.infoIsNew" flag). Any subsequent RTP packets sent by the <BR>>server - and received by the client - will have occurred *after* the <BR>>'seek' operation, and so their timestamps should be at least as large <BR>>as the value in "rtpInfo.timestamp".<BR><BR>>So, I don't understand why you are seeing a situation where - for a <BR>>packet that you receive just after a 'seek' operation - <BR>>"curPacketRTPTimestamp" is smaller than "rtpInfo.timestamp" (unless <BR>>the timestamp field has just wrapped around, which we will handle <BR>>OK). Are you using an up-to-date version of the "LIVE555 Media <BR>>Server"? I have tested playing an indexed Transport Stream file <BR>>using "Live555 Media Server" version 0.5, and VLC version 1.1.3, and <BR>>do not see any problem; I am able to seek either forwards or <BR>>backwards, with no problem.</FONT><BR>
<DIV><FONT face="Verdana" size="2">>Ross Finlayson<BR>>Live Networks, Inc.<BR>><A href="http://www.live555.com/">http://www.live555.com/</A></FONT></DIV>
<DIV><FONT face="Verdana" size="2"></FONT> </DIV>
<DIV>Yes, I used latest version of VLC 1.1.3 and media server 0.5, and It produces the same result. Only to add that,</DIV>
<DIV>If you run the VLC and media server in a same PC machine, you have to 10% chance to reproduce the bug;</DIV>
<DIV>If you run them it two separate PC computers, you have almost 100% chance to reproduce the problem.</DIV>
<DIV> </DIV>
<DIV>John.ShaoFa</DIV>