[Live-devel] A Bug with "MediaSubsession::getNormalPlayTime()" and its solution

[Ross Finlayson]

>         I think I have found a bug with live555 library which is 
>used in VLC media player. When it' playing  a RTSP stream from the 
>MediaServer,  I drag the slider to a new position but an error 
>occurs : The slider will no longer move, while the video and audio 
>still run correctly. (the tsx file is right there, and sequential 
>playing is no problem). So I say, the live555 library with the 
>client is not able to 'SEEK' to a position.
>
>        The cause is located in MediaSubsession::getNormalPlayTime() 
>, MediaSession.cpp. Look at this line:
>               u_int32_t timestampOffset = 
>rtpSource()->curPacketRTPTimestamp() - rtpInfo.timestamp;
>In the suitation of 'SEEKING', it will not work because 
>rtpInfo.timestamp will be larger than curPacketRTPTimestamp.

That should not be happening.  The client (VLC) does a 'seek' 
operation by doing a RTSP "PLAY" command.  The response to this 
"PLAY" command will contain a "RTP-Info:" header, which our library 
will automatically interpret by setting the 
"MediaSubsession::rtpInfo" structure (and setting the 
"rtpInfo.infoIsNew" flag).  Any subsequent RTP packets sent by the 
server - and received by the client - will have occurred *after* the 
'seek' operation, and so their timestamps should be at least as large 
as the value in "rtpInfo.timestamp".

So, I don't understand why you are seeing a situation where - for a 
packet that you receive just after a 'seek' operation - 
"curPacketRTPTimestamp" is smaller than "rtpInfo.timestamp" (unless 
the timestamp field has just wrapped around, which we will handle 
OK).  Are you using an up-to-date version of the "LIVE555 Media 
Server"?  I have tested playing an indexed Transport Stream file 
using "Live555 Media Server" version 0.5, and VLC version 1.1.3, and 
do not see any problem; I am able to seek either forwards or 
backwards, with no problem.


>        A solution to this problem can be just add a judgement before 
>compute the new fNPT_PTS_Offset:
>      ..........................
>     if (rtpInfo.infoIsNew) {
>       if(rtpSource()->curPacketRTPSeqNum() < rtpInfo.seqNum) return 
>-0.1; // add this line

First, when comparing RTP sequence numbers, you should use the 
function "seqNumLT()" instead of "<", to allow for the possibility of 
the sequence number wrapping around.  So the new line should be:

	if(seqNumLT(rtpSource()->curPacketRTPSeqNum(), 
rtpInfo.seqNum)) return -0.1;

But again, I don't see how this can be happening.  For the packet 
that you receive just after a 'seek' operation, the RTP sequence 
number should be at least as large as "rtpInfo.seqNum" (modulo 
wraparound) - not smaller.
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/