First, note that developers (using the LIVE555 libraries) never need to concern
themselves with RTP timestamps. Our library automatically converts
presentation times to RTP timestamps (when sending), and from RTP timestamps to
presentation times (when receiving). See
http://live555.com/liveMe
Original Message
Subject: Re: [Live-devel] Delay problem of the first RTCP "SR" packet
From: Steve Ha
To: LIVE555 Streaming Media - development & use
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
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
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
wrote:
>
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 b
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 ti
