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

sf shaofa at vip.163.com
Thu Sep 9 18:37:38 PDT 2010


>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.

>Ross Finlayson
>Live Networks, Inc.
>http://www.live555.com/
 
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,
If you run the VLC and media server in a same PC machine, you have to 10% chance to reproduce the bug;
If you run them it two separate PC computers, you have almost 100% chance to reproduce the problem.
 
John.ShaoFa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100910/7ff80491/attachment.html>


More information about the live-devel mailing list