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

David Gessel gessel at blackrosetech.com
Fri Jan 22 07:21:35 PST 2021


Steve,


Thanks for the answer.  Unfortunately, I don't entirely understand either.  Basically I was having trouble with FFMPEG, but I tested with VLC and it did sync.  I will try rebuilding ffmpeg and resyncing and I set up a local NTP server to improve device NTP synchronization, I'm not sure why that would matter as I had multiple streams from the same camera failing to sync - and they share the same device clock.  So maybe ffmpeg isn't the answer.

I chased down RFC6051 as I thought if it were fairly easy to turn on, it is likely many media sinks would understand it and Do The Right Thing.

Unfortunately, this can be muddy waters because ONVIF chose a slightly different method of achieving the same goal and while similar the header extension is not identical.  Optimally, there would be easily enabled code to generate the necessary header extensions for RFC 6051 compliant headers (A or B), ONVIF compliant NTP headers, both, or neither.

If implementing RFC 6051 header decode (assuming it were available) is problematic - it might be easier to look at sending rapid resynchronization request packets - RFC 6051 3.2:

    If the RTP/AVPF profile [RFC4585  <https://tools.ietf.org/html/rfc4585>] is in use, this feedback message
    MAY be sent by a receiver to indicate that it's unable to synchronise
    some media streams, and desires that the media source transmit an
    RTCP SR packet as soon as possible


-David

-------- 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 05:09+0300
> Hi David,
> The RFC-6051 seems good for quickly synchronization, but it requires a big effort to adapt to the current library and I am not sure if it is worth enough to do so.
> I don't understand your issue well so I have no idea. Sorry.
>
> Steve.
>
> On Fri, Jan 22, 2021 at 8:44 PM David Gessel <gessel at blackrosetech.com <mailto:gessel at blackrosetech.com>> wrote:
>
>     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 <mailto:finlayson at live555.com>>
>     To: LIVE555 Streaming Media - development & use <live-devel at us.live555.com <mailto: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 <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 <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/968511a8/attachment-0001.htm>


More information about the live-devel mailing list