[vlc] Problems seeking in MPEG2 TS stream via RTSP?

Brett Granger bgranger at verivue.com
Mon Jan 28 21:57:09 CET 2008


Hello,

I am using a VLC client on linux (VLC 0.8.6b default package from Ubuntu 
Feisty repos) to play an MPEG-2 transport stream from a 
live555MediaServer using RTSP and RTP.  I have used the 
MPEG2TransportStreamIndexer application included with the liveMedia code 
to create an index file to go along with the stream.  Normal playback of 
the stream from the beginning works just fine.

However, if I attempt to use the --start-time=<time> command line 
option, I see strange behavior:  the client puts up a black screen for 
the amount of time in the start-time parameter, and then finally starts 
to display the video from the desired offset into the stream.  Likewise, 
if I launch vlc with the rc interface and let it start playing the 
stream from the beginning, then use the "seek <x>" command in the rc 
interface, the video presentation stalls for an amount of time equal to 
the difference between the requested new presentation time and the 
current presentation time, then resumes from the correct newly-requested 
location in the stream.  Using the -vvv option on the command line, I 
see that the live555 access_demux *always* issues a PLAY request from 
time 0 when starting to play a stream, then follows up almost 
immediately with a PLAY request for the new time passed in via the 
--start-time option, so I believe that both cases are showing the same 
behavior.

I used wireshark to look at the traffic between client and server.  I 
see that when the seek command is issued via the interface, the RTSP 
server immediately replies and starts sending RTP packets from the new 
location in the stream.  However, the VLC client does not present them 
until the wallclock time has advanced to the point where the next frame 
would have been displayed without the seek request -- e.g. "seek 15" 
from time 0 results in a 15 second delay before video resumes. 
Additionally, the VLC client appears to have buffered all the RTP 
packets that were sent in the meantime.  When I attempt to pause after 
having issued a seek, wireshark shows that the PAUSE request goes to the 
server immediately and the RTP packets stop coming, but VLC continues to 
play video for a time equal to the duration of the seek before pausing. 
  I have --rtsp-caching=200, and yet VLC will play 15 seconds of video 
after the pause if I have done a seek of 15 seconds.

Has anyone seen this problem, and is there anything I can do either to 
solve it or to get more information about it?  It appears to have 
something to do with the timestamp at which VLC believes it is supposed 
to present the next frame.  VLC just waits until that time and then 
proceeds with the presentation.  I have determined that if I am in the 
rc interface and use the command "goto 0" on a clip which has a 
start-time option, it will immediately start presenting from the correct 
time in the stream, and I think that is because it does not issue a PLAY 
request for time 0 before issuing the PLAY request for the start time. 
However, if I then seek in that stream, I still see the same stalling 
behavior.

I do not see this behavior when streaming an mp3 stream from the same 
RTSP server, so it appears to be specific to the MPEG2 transport stream 
as well...

Thanks in advance for any thoughts or help.  Please let me know if this 
issue belongs on a different VLC mailing list.

--Brett Granger




More information about the vlc mailing list