[Public WebGL] OES_EGL_image_external Extension proposal

Byungseon Shin [email protected]
Mon Jan 9 18:54:41 PST 2017

Hi Mark,

Thanks for the feedback.
I replied inline on your comments.

Kind regards,
Byungseon Shin

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

> On Jan 7, 2017, at 4:01, Byungseon Shin <[email protected]> wrote:
> Hi WebGL working group members,
> We have updated proposal by adding following function :
> - Provides time of frame, texture width and height of HTMLVideoElement's
> EGLImage.
> Please take a look at the pull request:
> <https://github.com/KhronosGroup/WebGL/pull/2243>
> Kind regards,
> Byungseon Shin
> 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.

I could not find such a restriction. Please see the Android Video Streaming
use cases.

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.

Again, not all embedded GPU vendors support EGL_KHR_Stream.

> 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.

We can implement locking handled by browser engine internally.

> 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.

In case of Media Source Extension(MSE), application control the buffering
of each sources, so it could be used for matching the current video frame

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.

I agree this function but I am not sure this extension should cover it or

> Regards
>     -Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20170110/f08d9375/attachment.html>

More information about the public_webgl mailing list