It is very unlikely that a bug-fix made more than 6 years ago has anything to
do with your problem. Remember that many, many other people have been
successfully using our software since then. Please, just begin by describing
your symptoms; don’t waste your time trying to understand the arcane
Hi,
We are experiencing an issue with a product on the project that I'm working on.
It is an analogue video encoder that uses the live555 media server. When we
make multiple RTSP joins to the device, each new RTSP join causes the video
sessions already in progress to glitch.
I noticed one of t
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
