[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:
https://www.khronos.org/files/opengles3-quick-reference-card.pdf

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]>
wrote:

> 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