There are two cases observed so far, 1. The "200 ok" PLAY response is handled slower than first RTP packet. We use the rtptime of RTP-Info in "200 OK" as the base timestamp. The timestamp of following RTP packets should refer to it. Otherwise, the timestamp will be incorrect and decoder may not play the streaming properly. 2. The npt header in "200 ok" PLAY response may have the format "npt:now-", in this case, the rtp packets will be dropped.

The attachment is a captured file using wireshark when I streaming the url by vlc. rtsp://v6.cache6.c.youtube.com/CjYLENy73wIaLQlcR8cV2UMCLxMYESARFEIJbXYtZ29vZ2xlSARSBXdhdGNoYJP5sJqzyKf0TQw=/0/0/0/video.3gp Please set the filter "rtp" "rtsp" "rtcp" in wireshark. And focus on the packet No. 82 83 87. No. 82: It's a RTCP packet and it's RTP Timestamp is 609073040 No. 83: It's a RTSP packet and it carries the RTP Timestamp for both track. 964595889 and 609072026 No. 87: It's a RTP packet and it is the first RTP packet for one track. It's RTP timestamp is 609072026. In current codebase, |ARTPConnection::parseRTCP| parse the No. 82 packet as the base timestamp. So obviously the No.87 packet will be dropped since its timestamp is negative calculated by No. 82. We should parse the RTP-Info in No. 83 instead No. 82. Some reference: http://www.ietf.org/rfc/rfc2326.txt 12.33 RTP-Info

Here is a description for the symptom. http://lists.live555.com/pipermail/live-devel/2007-March/006364.html

Hi sworkman: Could you please review this patch? Without this patch, the addMediaTimestamp() will drop the first rtp packet and also shift the timestamp of following rtp packets.

tryserver: https://tbpl.mozilla.org/?tree=Try&rev=3ed63a17ea6d

r=sworkman