[Public WebGL] OES_EGL_image_external Extension proposal

Florian Bösch [email protected]
Mon Jan 9 23:34:22 PST 2017


On Tue, Jan 10, 2017 at 2:27 AM, Mark Callow <[email protected]> wrote:

> Thanks for the update. Unfortunately it does nothing to settle my previous
> concerns.
>
> On the native side EGL_image and its companion OES_EGL_image_external are
> designed only for static images such as something drawn with OpenVG.
> EGL_KHR_stream (and family) + EGL_KHR_stream_consumer_gltexture are
> designed for dynamic images, i.e. sequences of image frames, . The stream
> provides buffering necessary to accommodate different frame rates of the
> video decoder and the application’s GL rendering and to avoid having to
> lock either to ensure half-completed video frames are not rendered.
>
> In the web browser, as far as I know, the HTMLVideoElement decoder and
> WebGL rendering can run at different rates so a similar buffer or else
> locking is needed. This extension provides neither. Because of this “time
> of frame of HTMLVideoElement’s EGLImage” could change at any time, even
> right after the function is called and before the WebGL application renders.
>
> Unless browsers are prepared to provide guarantees that HTMLVideoElement
> decoding and WebGL rendering have the same frame rate and will be
> synchronized, buffering is needed.
>

If the decoder provides the video frame closest to the estimate when a
webgl framebuffer shows up on screen, then it doesn't matter if "the video
frame just changed" because the decoder would be lookahead to match. If
that can be done implicitely by the UA, and doesn't have to be tracked by
the API user, all the better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170110/7596d5de/attachment.html>


More information about the public_webgl mailing list