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

[David Gessel]

Steve,

I am having some issues with sync due to either late or ignored SR packet timestamps. Ross provided a really good answer to my question - to which I owe a response and am working toward (side-quests have intervened as a kernel update once again broke my e1000e network driver and this time the fixes are not fixin' the problem - totally irrelevant to this).

In any event there is a standard defined to extend the RTP packet structure to include NTP time stamps, RFC 6051, precisely to enable more rapid synchronization of multi-source RTSP streams. I feel Live555 would benefit from at least having the capability of optionally adding RFC6051 NTP header extensions.

-David



-------- Original Message --------
Subject: Re: [Live-devel] Delay problem of the first RTCP "SR" packet
From: Ross Finlayson <finlayson at live555.com>
To: LIVE555 Streaming Media - development & use <live-devel at us.live555.com>
Date: 2021-01-22 10:01+0300

> 
> 
>> 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
>