Kieran Kunhya (12021-02-07):
> QED that you don't understand the problem whatsoever.
This is the third time you've been rude today.
I am sorry, but it's you who do not understand what people actually
need. Most use cases do not need better precision than a few hundredth
of seconds, if that.
--
Sent from my mobile device
On Sun, 7 Feb 2021, 20:27 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > It doesn't work in practice.
> > It's why every Android phone captures video at 29.970fps ± jitter instead
> > of the correct 3/1001
>
> Good enough for most uses. Let the user deci
Kieran Kunhya (12021-02-07):
> It doesn't work in practice.
> It's why every Android phone captures video at 29.970fps ± jitter instead
> of the correct 3/1001
Good enough for most uses. Let the user decide.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
On Sun, 7 Feb 2021, 20:20 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > Your scenario is contrived. Its impossible to sync exactly between
> > different machines for all the reasons I explained and you didn't
> > understand.
>
> I understand very well. What you refuse to understand is
Kieran Kunhya (12021-02-07):
> Your scenario is contrived. Its impossible to sync exactly between
> different machines for all the reasons I explained and you didn't
> understand.
I understand very well. What you refuse to understand is that all this
theoretical stuff does not matter. What matters
Sent from my mobile device
On Sun, 7 Feb 2021, 19:21 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > NTP is allowed to jump when it wants for example. It's not trivial for
> the
> > user to guarantee this.
>
> In practice, it does not.
>
Read the docs where it explains where it can ju
Kieran Kunhya (12021-02-07):
> NTP is allowed to jump when it wants for example. It's not trivial for the
> user to guarantee this.
In practice, it does not.
> Exactly, so by default you must give the user a clock which is guaranteed
> not to jump as you don't know. If they need to synchronise be
On Sun, 7 Feb 2021, 18:34 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > This time can jump forward or backwards. It is trivial to do this.
>
> Not on a correctly configured system, it does not.
>
NTP is allowed to jump when it wants for example. It's not trivial for the
user to guara
Kieran Kunhya (12021-02-07):
> This time can jump forward or backwards. It is trivial to do this.
Not on a correctly configured system, it does not.
> The monotonic clock cannot do that.
The monotonic clock cannot synchronize from different computers.
Each has limitations the other has not, thi
Sent from my mobile device
On Sun, 7 Feb 2021, 17:35 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > Yes and thus you need a monotonic clock as a starting point for proper
> > filtering. Ffmpeg has neither.
>
> The kernel provides timestamps that are accurate enough. I do not
> underst
Kieran Kunhya (12021-02-07):
> Yes and thus you need a monotonic clock as a starting point for proper
> filtering. Ffmpeg has neither.
The kernel provides timestamps that are accurate enough. I do not
understand why you insist on the contrary in the face of facts.
Also, for a properly configured
On Sun, 7 Feb 2021, 17:29 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > You do care because different sources generated either by a PC or
> different
> > physical cameras will drift. E.g at 25fps after one hour you might get
> > 9 frames from one and 90002 or whatever frames from
Kieran Kunhya (12021-02-07):
> You do care because different sources generated either by a PC or different
> physical cameras will drift. E.g at 25fps after one hour you might get
> 9 frames from one and 90002 or whatever frames from another etc. And of
> course the timestamps will drift slowly
On Sun, 7 Feb 2021, 17:15 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > Yes the montonic clock should be the default.
>
> Changing the default is acceptable to me. Probably after a transition
> period.
>
> > You misunderstand greatly. How does the clock rate of NTP magically make
> >
Kieran Kunhya (12021-02-07):
> Yes the montonic clock should be the default.
Changing the default is acceptable to me. Probably after a transition
period.
> You misunderstand greatly. How does the clock rate of NTP magically make
> its way to the camera?
I do not know, I do not care, I am not a
Sent from my mobile device
On Sun, 7 Feb 2021, 16:55 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > Give the user the option not to use the monotonic clock.
>
> So this should be an option. Thank you very much.
Yes the montonic clock should be the default.
> This is not possible wi
Kieran Kunhya (12021-02-07):
> Give the user the option not to use the monotonic clock.
So this should be an option. Thank you very much.
> This is not possible without high end capture equipment to synchronise the
> clocks on each camera. Everything else is guesswork.
This is nonsense. The accu
Sent from my mobile device
On Sun, 7 Feb 2021, 16:31 Nicolas George, wrote:
> Kieran Kunhya (12021-02-07):
> > It is wrong to suggest that the clock of an IP webcam has any relation at
> > all to the PC clock both absolute or relative.
>
> It is not wrong to let users observe that their particul
Kieran Kunhya (12021-02-07):
> It is wrong to suggest that the clock of an IP webcam has any relation at
> all to the PC clock both absolute or relative.
It is not wrong to let users observe that their particular model of IP
webcam uses Unix timestamps and is correctly synchronized. This is a
comm
On Sun, 7 Feb 2021, 14:21 Nicolas George, wrote:
> Marton Balint (12021-02-07):
> > av_gettime_relative() is using the monotonic clock therefore more
> suitable as a
> > timestamp source and for relative time calculations.
> >
> > Probably fixes ticket #9089.
>
> Not ok.
>
> This is a user-visibl
Marton Balint (12021-02-07):
> av_gettime_relative() is using the monotonic clock therefore more suitable as
> a
> timestamp source and for relative time calculations.
>
> Probably fixes ticket #9089.
Not ok.
This is a user-visible change of behavior, we cannot do it just like
that.
Furthermor
av_gettime_relative() is using the monotonic clock therefore more suitable as a
timestamp source and for relative time calculations.
Probably fixes ticket #9089.
Signed-off-by: Marton Balint
---
libavdevice/alsa_dec.c| 2 +-
libavdevice/bktr.c| 6 +++---
libavdevice/fbdev_de
22 matches
Mail list logo
