W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > July 2019

[mediacapture-image] Clarify grabFrame timing (#212)

From: David Sanders via GitHub <sysbot+gh@w3.org>
Date: Wed, 17 Jul 2019 23:14:55 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-469493362-1563405294-sysbot+gh@w3.org>
dsanders11 has just created a new issue for https://github.com/w3c/mediacapture-image:

== Clarify grabFrame timing ==
The current implementation of `ImageCapture.grabFrame` in Chromium will always wait for the next frame from the video stream, which was unexpected. The spec doesn't say anything about timing, but I think it should be updated to clarify. If the intention is indeed to wait for the next frame, then personally I think `ImageCapture.grabNextFrame` would more accurately convey the intention.

In particular, without clarification in the spec, one implementation may implement it as next frame, one may implement it as current frame, and code written against the spec would act quite different between the two implementations, especially at low frame rates. At 2 FPS the first implementation would always take 500ms to resolve, while the second implementation may only take 5ms to resolve.

I think it would make the most sense to add language to the spec to say that `ImageCapture.grabFrame` should not wait for the next frame, unless this can be done without undue latency.

Then I think #210 would offer a nice alternative for implementing the current Chromium behavior.

Please view or discuss this issue at https://github.com/w3c/mediacapture-image/issues/212 using your GitHub account
Received on Wednesday, 17 July 2019 23:14:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:25 UTC