[Public WebGL] OES_EGL_image_external Extension proposal

Byungseon Shin [email protected]
Tue Oct 11 08:10:54 PDT 2016


Hi Florian,


On Tue, Oct 11, 2016 at 11:48 PM Florian Bösch <[email protected]> wrote:

> 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?
>
>
I mistakenly left the string in the template and fixed at attached proposal
revision #3.


> Another question I have is, how do you handle YUV and such as are commonly
> provided by video decoders?
>
>
Video decoder output shared as a form of EGLImage as a YUV format.


> 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?
>
>
>
Yes, it could be possibly implemented, but we want to support both
OES_EGL_external texture and TEXTURE_2D.  And eventually share the sample
code to our partner.


>
>
>
> 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.
> 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/af47cd60/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20161011/af47cd60/attachment-0001.html>


More information about the public_webgl mailing list