90 kHz Units

[John L. Poole]

The database schema file has a comment:

-- The starting time of the recording, in 90 kHz units since
-- 1970-01-01 00:00:00 UTC excluding leap seconds.

And the column names have ..."_90k" to highlight the unit of time.

Can you identify some articles or rationale for using this kind of precision time system?  And why 90 kHz as opposed to 44.1k, 48k or 96k?  I was hoping something would pop up in Google search.

https://en.wikipedia.org/wiki/Sampling_(signal_processing) addresses Video sampling and Audio Sampling, but I'm not seeing something that ties in with the selection of 90.

Lastly, how are leap seconds handled in conversions to epoch time?

One of the user interface issues I am encountering is the difference between local time and UTC.  I can never remember whether Pacific time is 7 or 8.  I'm considering seeing what it would take to get local time displayed to the user. 

--

John Laurence Poole
1566 Court ST NE
Salem OR 97301-4241
707-812-1323 office

[Scott Lamb]

On Fri, Jun 5, 2020 at 1:51 PM John L. Poole <jlpo...@gmail.com> wrote:

The database schema file has a comment:

-- The starting time of the recording, in 90 kHz units since
-- 1970-01-01 00:00:00 UTC excluding leap seconds.

And the column names have ..."_90k" to highlight the unit of time.

Can you identify some articles or rationale for using this kind of precision time system?  And why 90 kHz as opposed to 44.1k, 48k or 96k?  I was hoping something would pop up in Google search.

design/schema.md mentions this briefly. It comes from RTP, RFC 3551 section 5:

   All of these video encodings use an RTP timestamp frequency of 90,000
   Hz, the same as the MPEG presentation time stamp frequency.  This
   frequency yields exact integer timestamp increments for the typical
   24 (HDTV), 25 (PAL), and 29.97 (NTSC) and 30 Hz (HDTV) frame rates
   and 50, 59.94 and 60 Hz field rates.  While 90 kHz is the RECOMMENDED
   rate for future video encodings used within this profile, other rates
   MAY be used.  However, it is not sufficient to use the video frame
   rate (typically between 15 and 30 Hz) because that does not provide
   adequate resolution for typical synchronization requirements when
   calculating the RTP timestamp corresponding to the NTP timestamp in
   an RTCP SR packet.  The timestamp resolution MUST also be sufficient
   for the jitter estimate contained in the receiver reports.

I originally chose this to exactly preserve the durations given to Moonfire NVR by the cameras. Now it actually adjusts the durations a bit because it turns out that cameras are really bad at keeping time. design/time.md talks about this (quite extensively). I might in the future adjust the internal time format to save SSD space and/or when representing audio (which doesn't use the 90 kHz time base).

https://en.wikipedia.org/wiki/Sampling_(signal_processing) addresses Video sampling and Audio Sampling, but I'm not seeing something that ties in with the selection of 90.

Lastly, how are leap seconds handled in conversions to epoch time?

The short version is that Moonfire NVR just uses Unix time, including its unfortunate behavior of excluding leap seconds. I'd like to improve this some day. There's more written about it here:

https://github.com/scottlamb/moonfire-nvr/blob/master/design/time.md#leap-seconds

One of the user interface issues I am encountering is the difference between local time and UTC.  I can never remember whether Pacific time is 7 or 8.  I'm considering seeing what it would take to get local time displayed to the user. 

That's supposed to happen out of the box. In particular, the server should tell the UI what time zone to use, and the UI should respect that. If it's not working, does the "date" command show Pacific time on your system? Do you have an /etc/localtime symlink? an /etc/timezone file with the name of the zone? The logic Moonfire NVR uses for this is here.

--

John Laurence Poole
1566 Court ST NE
Salem OR 97301-4241
707-812-1323 office

--
You received this message because you are subscribed to the Google Groups "moonfire-nvr-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moonfire-nvr-us...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/moonfire-nvr-users/5b3b9410-0a94-011d-211b-69abbf6f89d2%40gmail.com.

--

Scott Lamb <http://www.slamb.org/>