[Live-devel] Delay problem of the first RTCP "SR" packet

David Gessel gessel at blackrosetech.com
Fri Jan 22 07:32:13 PST 2021



-------- Original Message --------
Subject: Re: [Live-devel] Delay problem of the first RTCP "SR" packet
From: Steve Ha <steveha at u2sr.com>
To: LIVE555 Streaming Media - development & use <live-devel at us.live555.com>
Date: 2021-01-22 04:52+0300
> Thanks for your quick and useful response,
> I have checked it and admit that the "SR" always comes to the client before the first RTP packet.
>
> But I still wonder about two things:
> 1) Since the RTPTimestamp bound to the first "SR" is different from the one bound to the first RTP packet, how can PTS be synchronized to the server's NTP correctly at the client side?

Steve,

This might get mangled (ASCII art formatting) but


 From RFC 3550, 6.5.1

        +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
sender |              NTP timestamp, most significant word             |
info   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |             NTP timestamp, least significant word             |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         RTP timestamp                         |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The NTP time stamp in the sender report is accompanied by the random offset NTP stream timestamp also used RTP packet headers, so the receiver should be able to carry forward the offset between sender NTP time and RTP packets.


> 2) Does PTS at client always monotonically increase even in case RTPTimestamp (32-bit) is wrapped around?.


that I don't know....

>
> Regards.
> Steve.
>
> On Fri, Jan 22, 2021 at 4:01 PM Ross Finlayson <finlayson at live555.com <mailto:finlayson at live555.com>> wrote:
>
>
>
>     > On Jan 22, 2021, at 4:05 PM, Steve Ha <steveha at u2sr.com <mailto:steveha at u2sr.com>> wrote:
>     >
>     > My question is how can I force the first RTCP "SR" packet to be delivered at the same time as the first RTP packet so that the RTSP client could get all frames with correct PTS?
>
>     Basically, you can’t.  (But even if you could, there’d be no guarantee that it would be received, as it (like all RTCP (and RTP packets) are datagrams.)
>
>     However, our RTSP server implementation *does* send an initial RTCP “SR”, before the first RTP packet, precisely for this reason.  (See “OnDemandServerMediaSubsession.cpp”, line 550.)
>
>
>     Ross Finlayson
>     Live Networks, Inc.
>     http://www.live555.com/
>
>
>     _______________________________________________
>     live-devel mailing list
>     live-devel at lists.live555.com <mailto:live-devel at lists.live555.com>
>     http://lists.live555.com/mailman/listinfo/live-devel
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20210122/47d4c8c1/attachment.htm>


More information about the live-devel mailing list