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

[Steve Ha]

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?
2) Does PTS at client always monotonically increase even in case
RTPTimestamp (32-bit) is wrapped around?.

Regards.
Steve.

On Fri, Jan 22, 2021 at 4:01 PM Ross Finlayson <finlayson at live555.com>
wrote:

>
>
> > On Jan 22, 2021, at 4:05 PM, Steve Ha <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
> 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/c6edc293/attachment.htm>