> On Mar 3, 2021, at 10:03 AM, Eric Beuque wrote:
[…]
> i think "real time" is not mandatory for stream synchronization
For our server implementation, outgoing frames’ presentation times *must* be
the same as times produced by calling “gettimeofday()”, because our
implementation of RTCP call
Le mer. 3 mars 2021 à 18:53, dan_desjardins a
écrit :
> Perhaps it’s not warranted advice but… If updates from your NTP service
> are forcing large changes than it would seem your MOBO is bad or you need
> to force NTP updates more often so the changes are small enough to be
> handled elegantly.
Perhaps it’s not warranted advice but… If updates from your NTP service are
forcing large changes than it would seem your MOBO is bad or you need to force
NTP updates more often so the changes are small enough to be handled elegantly.
___
live-devel ma
Le mer. 3 mars 2021 à 17:28, Ross Finlayson a
écrit :
>
>
> > On Mar 3, 2021, at 7:11 AM, Eric Beuque
> wrote:
> >
> > My question is how i'm supposed to deal with a camera clock change when
> the stream is already running ?
>
> In short, you can’t. Your server’s presentation times must be alig
> On Mar 3, 2021, at 7:11 AM, Eric Beuque wrote:
>
> My question is how i'm supposed to deal with a camera clock change when the
> stream is already running ?
In short, you can’t. Your server’s presentation times must be aligned with
‘wall clock time' (more precisely, the times returned by
Hi,
I have an issue using the presentation time of the RTSP stream of a camera.
When the clock changes due to a manual change or NTP synchronisation,
presentation times are affected, which lead to get next presentation time
very bigger or lower than the previous timestamp.
For exemple, i got this
