[Live-devel] RTSP Seek problems

[Philippe Bridant]

 > Philippe,
 >
 > To follow up on my previous response, I'd like to get clarification 
on > one point:

 > Will it help you at all if you (by "you", I mean the developer of the
 > VLC "livedotcom.cpp" code, that interfaces between the LIVE.COM
 > library and the rest of VLC) can know, exactly, where the
 > discontinuity occurs?  In particular, will it help you at all if you
 > can know, for sure, that all incoming RTP frames that arrive after
 > you've done the seek will contain data that was sent after the server 
 > handled the seek operation?


My problem is that I cannot know if (and if yes how many) incoming
frames (after the seek) the lib send me.

What would be helpfull:
- Being really *SURE* lib live buffers have been flushed after a seek 
command.

OR

- Having the RTP timestamp instead of the of the calculated PTS as the 
third argument of the AfterGettingFunc function. (so not a *continuous* 
sequence of time ...).




 >
 > If this is something that is going to be helpful to you, then I can
 > probably modify the LIVE.COM library to make this happen.
 >

It would be a GREAT thing!



 > However, one thing that I *can't* do is indicate the discontinuity in
 > the presentation time stamp that's passed to the 'afterGettingFunc'
 > (for VLC, this is "StreamRead()").  The reason for this is that this
 > presentation time is a *continuous* sequence of time that represents
 > the time at which incoming data should be *rendered* by the client.
 > It does not indicate any discintinuities in the original source data.
 >


I've made a very interesting test. I have disconnected the VLC live 
module from the VLC core and have printed all presentation time stamp 
given by the lib. So the following timestamps are NOT the one calculated 
by VLC.

# HERE, PLAYING VIDEO (and not audio) NORMALY

  13:24: 8:  0
  [...]
  [...]
  [...]
  [...]
  [...]
  13:24:12:560
  13:24:12:600

# HERE, We played 4,6 seconds and we seek to the 17th second.

Sending request: PLAY rtsp://jpetazzo/test.mp4/trackID=65736 RTSP/1.0
CSeq: 6
Session: 3707054511863641487
Range: npt=17.084-
User-Agent: VLC Media Player (LIVE.COM Streaming Media v2004.12.15)


Received PLAY response: RTSP/1.0 200 OK
Server: DSS/5.0.1.1 (Build/464.1.1; Platform/Linux; Release/5; )
Cseq: 6
Session: 3707054511863641487
Range: npt=17.08400-25.44000
RTP-Info: 
url=trackID=65736;seq=12401;rtptime=1121159776,url=trackID=65636;seq=55985;rtptime=2086680659

# FROM HERE, A MESS DURING 3 seconds because of a 12,5 seconds GAP in 
the time stamp sequence.

  13:24:12:640
  13:24:25: 79
  13:24:25:119
  13:24:25:159
  13:24:25:199
  13:24:25:239
  13:24:25:279
  13:24:25:319
  13:24:25:359
  13:24:25:399
  13:24:25:439
  13:24:25:479
  13:24:25:519
  13:24:25:559
  13:24:25:599
  13:24:25:639
  13:24:25:679
  13:24:25:719
  13:24:25:759
  13:24:25:799
  13:24:25:839
  13:24:25:879
  13:24:25:919
  13:24:25:959
  13:24:25:999
  13:24:26: 39
  13:24:26: 79
  13:24:26:119
  13:24:26:159
  13:24:26:199
  13:24:26:239
  13:24:26:279
  13:24:26:319
  13:24:26:359
  13:24:26:399
  13:24:26:439
  13:24:26:479
  13:24:26:519
  13:24:26:559
  13:24:26:599
  13:24:26:639
  13:24:26:679
  13:24:26:719
  13:24:26:759
  13:24:26:799
  13:24:26:839
  13:24:26:879
  13:24:26:919
  13:24:26:959
  13:24:26:999
  13:24:27: 39
  13:24:27: 79
  13:24:27:119
  13:24:27:159
  13:24:27:199
  13:24:27:239
  13:24:27:279
  13:24:27:319
  13:24:27:359
  13:24:27:399
  13:24:27:439
  13:24:27:479

# FROM HERE, normal sequence of time stamps is back. (if playing with 
vlc => problem of audio and video synchro, late picture, ect..., (normal 
with this kind of sequence  :)  ) ).

  13:24:15:  0
  13:24:15: 40
  [...]
  [...]


I would be very gratefull if you can do something!
Many thanks for the support.

Regards,

Philippe Bridant