So, this RTCP SR logic is calling gettimeofday() and changing
fPresentationTime outside of my control?
No, it's not setting your "fPresentationTime" at all. Only your code
does that. The "RTCP SR logic" is calling "gettimeofday()" to set the
timestamps in RTCP "SR" packets (that are use
> On Jul 8, 2022, at 3:57 AM, DJM-Avalesta wrote:
>
> Hi Ross,
>
> > OK, so we’ve established (again!) that your problem is that your server’s
> > presentation times are not properly aligned with ‘wall clock’ time
> > (the time that you’d get by calling “gettimeofday()”). This is necessary
Hi Ross,
OK, so we've established (again!) that your problem is that your
server's presentation times are not properly aligned with 'wall clock'
time
(the time that you'd get by calling "gettimeofday()"). This is
necessary because the periodic RTCP "SR" ("Sender Report") packets -
sent by t
OK, so we’ve established (again!) that your problem is that your server’s
presentation times are not properly aligned with ‘wall clock’ time (the time
that you’d get by calling “gettimeofday()”). This is necessary because the
periodic RTCP “SR” (“Sender Report”) packets - sent by the server - a
Hi Ross,
Apologies, I couldn't find that thread from last year for some reason. I
know it's not netiquette to resubmit the same question so could we
please consider this a continuation of that previous thread?
I had thought I'd reduced this issue to a negligible point but not so. I
had pat
I’m confused. You sent an almost identical email last December. I thought
that the various responses to that email had resolved your problem.
Once again, you should read the various emails titled "Live555 presentation
times jump when joining multicast streams” in the December 2021 archives:
Hi,
My embedded video server outputs an H264 Multicast video stream at
25fps.
It is a requirement that multiple VLC client sessions join the stream
via ONVIF which results in an RTSP handshake to get the multicast SDP
details to join.
This works fine, however when each new client joins I
