[Public WebGL] OES_EGL_image_external Extension proposal

Maksims Mihejevs [email protected]
Tue Oct 11 00:51:26 PDT 2016

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.EGLImageTargetTextu
> re2DOES(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/
>    <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/
>    <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/33f0adc0/attachment.html>

More information about the public_webgl mailing list