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

[Jean-Paul Saman]

Rahul K Patel wrote:
> 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.

Probably a bug in live555. Could you try with the live555 client? Just 
to rule out that live555 libraries are the culprit. If not then vlc is 
the culprit.

> 
> 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
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ______________________________________________________
> vlc mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc