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

[Rahul K Patel]

I am also facing same issue with H264 and AAC streaming. And surprisingly seek issues happens in rtp over udp only
when i do streaming with rtp over tcp or rtp over http seek works properly.

Is it bug in vlc or I am missing any thing.

Thanks in Advance,
Rahul Patel.


Brett Granger wrote:
>/ Following up a bit further on this... it doesn't seem to happen on every 
/>/ MPEG2 TS.  I have some streams where the problem happens every time, 
/>/ some streams where it happens sometimes, and some streams where it never 
/>/ happens...
/>/
/>/ Any thoughts on whether I might be able to discern differences in the 
/>/ streams that would cause this problem?  I am not an MPEG expert by any 
/>/ means.
/>/
/>/ Thanks again,
/>/ --Brett
/>/
/>/ Granger, Brett wrote:
/>/   
/>>/ 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
/>>/
/>>/ ______________________________________________________
/>>/ vlc mailing list
/>>/ To unsubscribe or modify your subscription options:
/>>/ http://mailman.videolan.org/listinfo/vlc
/>>/     
/>/
/>/
/>/ ______________________________________________________
/>/ vlc mailing list
/>/ To unsubscribe or modify your subscription options:
/>/ http://mailman.videolan.org/listinfo/vlc
/>/
/>/   
/
Hi, I have bit understanding of MPEG TS. It contains Header + Adaptation 
Field and/or Payload. Adaptation field specifically contains PCR 
(Program Clock Ref). Payload contains stream data.
It is fair to say that PCR, will synchronize server and client. All 
stream time stamps are in reference to clock ref.. So, when seek 
happens, it I think, it is required to send new adaptation field with 
latest value of PCR. Also extracting of elementary stream, will happen 
when new payload will arrive having valid decoded time stamp. (Now, in 
case of video, (some) video codec requires I frame to start (as B and P 
frames are based on I) Thus, we will end up with no or messy video 
output till we receive complete and valid I frame. Frequency of I frame 
is based on GOP (group of pictures). )

I feel it will be good idea to check availability of Adaptation field 
(and thus PCR) in transport stream, received after seek operation takes 
place.

Regards,

Viral


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc/attachments/20090530/734eb249/attachment.html>