W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2018

RE: Raw data APIs - 2 - Access to unencoded data

From: Stojiljkovic, Aleksandar <aleksandar.stojiljkovic@intel.com>
Date: Wed, 30 May 2018 20:01:55 +0000
To: Randell Jesup <randell-ietf@jesup.org>, "harald@alvestrand.no" <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <7A0FAB90EDAE304EA98E76ACB132D51233254732@IRSMSX103.ger.corp.intel.com>
Fair enough, both are valid points. I thought it was good to reopen timestamp approach.

For the reference - clock resolution security issues [1].

Android camera defines the timestamp as sensor capture start time [2]. Note that SENSOR_INFO_TIMESTAMP_SOURCE could have value UNKNOWN and we would get monotonic time, that cannot be compared to timestamps from other subsystems, e.g. sensors.

[1]
https://www.w3.org/TR/hr-time/#clock-resolution<https://www.w3.org/TR/hr-time/#clock-resolution.>

[2]
https://developer.android.com/reference/android/hardware/camera2/CameraCharacteristics#SENSOR_INFO_TIMESTAMP_SOURCE

Kind Regards,
Aleksandar

________________________________
From: Randell Jesup [randell-ietf@jesup.org]
Sent: Wednesday, May 30, 2018 7:53 PM
To: public-webrtc@w3.org
Subject: Re: Raw data APIs - 2 - Access to unencoded data

On 5/30/2018 8:10 AM, Harald Alvestrand wrote:

Den 30. mai 2018 13:42, skrev Stojiljkovic, Aleksandar:


Interface Buffer ... Long long timestamp; // for start of buffer. Definition TBD.


Maybe DOMHighResTimeStamp
<https://www.w3.org/TR/hr-time/#sec-domhighrestimestamp><https://www.w3.org/TR/hr-time/#sec-domhighrestimestamp>, to enable sync
with other events, e.g. Sensor interface
<https://www.w3.org/TR/generic-sensor/#the-sensor-interface><https://www.w3.org/TR/generic-sensor/#the-sensor-interface>.


DOMHighResTimeStamp is convenient for absolute times, when it's clear
what it's related to (time the light hit the camera sensor?). For
playback of stored media, we might want to use a clock relative to the
start of the media; I know there are various well known apps for doing
things like time-stretching of videos - I'm not sure how that would be
representable in an API.

I'll note that any use of high-resolution timers by apps may be constrained by the wonders of Spectre mitigation for some time.   It would be nice to un-fuzz the timers, but even once one  has implemented fission/site-isolation/whatever-edge-will-call-it, lots of high-res clock sources make it super-easy to do spectre attacks. :-(



--
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randell-ietf@jesup.org<mailto:randell-ietf@jesup.org>!  Way too much spam

---------------------------------------------------------------------
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
Received on Wednesday, 30 May 2018 20:02:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:41 UTC