[Public WebGL] OES_EGL_image_external Extension proposal

Florian Bösch [email protected]
Tue Oct 11 07:48:40 PDT 2016

The proposed specification mentions:

Written against the WebGL API 1.0
> <http://www.khronos.org/registry/webgl/specs/1.0/> specification.
> Promoted to core and no longer available as an extension in WebGL API 2.0
> <http://www.khronos.org/registry/webgl/specs/2.0/> specification.

 The present WebGL 2.0 specification draft does not contain these EGL
interfaces: https://www.khronos.org/registry/webgl/specs/latest/2.0/ and
neither does the OpenGL ES 3.0 specification:

Could you clarify?

Another question I have is, how do you handle YUV and such as are commonly
provided by video decoders?

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

I'm afraid I don't quite follow why this would only be possible with this
extension. Would it not be possible for a WebGL implementation to use EGL
texture external and reinterprete a texImage2D call to call that function?

On Tue, Oct 11, 2016 at 12:54 PM, Byungseon Shin <[email protected]>

> 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
> applications.
> 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.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/0a16b14c/attachment.html>

More information about the public_webgl mailing list