[Live-devel] How to distinguish new RTP packets from out-of-data RTP packets when random accessing the video

Ross Finlayson finlayson at live555.com
Sat Jan 7 01:45:46 PST 2012


> I would like to random access the video, so I send a PAUSE command and then a PLAY command with a specified time.
> That is like follows.
>  
> PAUSE rtsp://113.31.34.14:554/work/500/115/969/967/500.3gp RTSP/1.0
> SeqNo: 3
> Session: 6347526623097789397
> (==> without range header)
>  
> ...
>  
> PLAY rtsp://113.31.34.14:554/work/500/115/969/967/500.3gp RTSP/1.0
> SeqNo: 4
> Range: npt=12-100    (==> set start play point at the 12th second)
> Session: 6347526623097789397
>  
>  
> However, I can’t control the network traffic, so I may still receive some old RTP packets after receiving PLAY response.

Are you actually seeing this happen with this server (a Darwin Streaming Server)?    Our RTP reception software will automatically discard out-of-order incoming RTP packets (by checking the RTP sequence number).  So, if you're seeing "old RTP packets" after the "PLAY", then presumably you're seeing some 'old RTP packets', followed by only 'new RTP packets'.  You should not be seeing 'old RTP packets' mixed with 'new RTP packets'.

In this case, I wouldn't worry too much about this.  It's unlikely that you're seeing very many 'old RTP packets' (unless your server is badly broken), so you can probably just feed all incoming data to your decoder, as usual, and things should be OK.  It'll be merely as if you slightly delayed sending the "PAUSE" command.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120107/615a768e/attachment-0001.html>


More information about the live-devel mailing list