[Public WebGL] OES_EGL_image_external Extension proposal

Byungseon Shin [email protected]
Tue Oct 11 03:54:34 PDT 2016

Hi Florian, Maksims,

Thanks for the feedback.

I have updated proposal to explain how application works.
Please see the attached updated proposal.

To render an update frame, we need to call ext.EGLImageTargetTexture2DOES
to bind newly generated texture buffer from video decoder.

By supporting OES_EGL_image_external extension, application can use direct
texture when video driver provides EGLImage like OpenGL ES natvie

Our proposal is just focusing on extending format of texture compatible
with OpenGL ES extension and does not conflict with previous proposals.

So, we provides a simplest way to adopt OES_EGL_image_external extension.

By using references implementations of browser, WebGL renders video more
than 10 times faster than TEXTURE_2D format with Full HD resolution output.

Kind regards,
Byungseon Shin

On Tue, Oct 11, 2016 at 4:51 PM Maksims Mihejevs <[email protected]> wrote:

> Worth mentioning that in web there are multiple sources that have
> independent redraw mechanics, that includes video as well as canvas
> elements. It might make sense to have single extension for providing direct
> access to those sources without need to re-upload it.
> I have assumptions that internally in browsers, both video and canvas have
> their buffers, so it might lead to very similar implementation as from
> internal side as well as from webgl api side.
> On 11 Oct 2016 12:12 p.m., "Florian Bösch" <[email protected]> wrote:
> Am I correct in assuming that once you've called ext.
> EGLImageTargetTexture2DOES(ext.TEXTURE_EXTERNAL_OES, videoElement); that
> the texture is "bound" to the video and no further calls need to be emitted
> (as would presently be the case) for it to stay current?
> If that's the case, I think it's a good idea, it takes some work off web
> application programmers to make sure the video is updated, and it should
> also in all cases avoid a texture download/reupload.
> There are some other extensions that have attempted to deal with this
> problem.
>    -
>    https://www.khronos.org/registry/webgl/extensions/rejected/WEBGL_texture_from_depth_video/
>    : this extension is rejected because it introduced a complex behavioral
>    changes/semantics whose benefits where unclear and the champions of this
>    extension stopped responding to questions and didn't offer any improvements
>    on the extension specification.
>    -
>    https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/
>    : this extension is currently in a proposal state and it covers similar
>    functionality as EGL_image_external. Where it fundamentally differs is that
>    it also deals with format conversions (YUV 442 to rgb etc.) and accurate
>    timing for presentation of a video frame.
>  Perhaps you could elaborate a little why OES_EGL_image_external would be
> preferrable to WEBGL_dynamic_texture, and how the issues that
> EGL_image_external does not tackle (timing, format conversion, other
> things) would be handled by the web application programmer?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20161011/3f76ecd6/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20161011/3f76ecd6/attachment-0001.html>

More information about the public_webgl mailing list