<div dir="ltr">Hi Corentin,<div><br><div class="gmail_quote"><div dir="ltr">On Tue, Oct 11, 2016 at 11:16 PM Corentin Wallez <<a href="mailto:cwallez@google.com">cwallez@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">The problem with using an EGL_image type of extension is that the texture data store becomes shared between the new texture and the object it was created from. This is great when the application controls both sides and can ensure read and writes are probably synchronized, but in the case of video here, one side would write without the application being able to control synchronization.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">The standard way to do this type of video / texture binding in EGL is to use <a href="https://www.khronos.org/registry/egl/extensions/KHR/EGL_KHR_stream.txt" class="gmail_msg" target="_blank">EGL_KHR_stream</a> which is a much more complex and might not be an improvement over what developers can do with the current APIs.</div></div><div class="gmail_extra gmail_msg"><br class="gmail_msg"></div></blockquote><div><br></div><div>As in proposal revision#3 and as Florian already mentioned,</div><div><span style="line-height:1.5">Current proposal support "bind once and update implicitly" concept :  "</span><span style="line-height:1.5">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)" </span><br></div><div><br></div><div>In a that sense, we could abstract the details implementation into MediaPlayer Side like synchronizing issues.<br></div><div><br></div><div>Even EGL_KHR_stream provides more details synchronization issues but still lot's of GPU driver and Video Decoder need to support the latest specification. </div><div>But OES_EGL_image_external extension is already supported by most of the GPU drivers and Video decoders.</div><div><br></div><div>And one of the performance bottleneck is to converting EGLImage input to TEXTURE_2D to handled by WebGL application. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg">On Tue, Oct 11, 2016 at 6:54 AM, Byungseon Shin <span dir="ltr" class="gmail_msg"><<a href="mailto:sun.shin@webkit.org" class="gmail_msg" target="_blank">sun.shin@webkit.org</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg">Hi Florian, Maksims,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Thanks for the feedback.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><span style="line-height:1.5" class="gmail_msg">I have updated proposal to explain how application works.</span><br class="gmail_msg"></div><div class="gmail_msg"><span style="line-height:1.5" class="gmail_msg">Please see the attached updated proposal.</span></div><div class="gmail_msg"><span style="line-height:1.5" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="line-height:1.5" class="gmail_msg">To render an update frame, we need to call </span><span class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg" style="line-height:1.5;font-size:13px;font-family:'helvetica neue',helvetica,arial,sans-serif">ext.</span><span class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg" style="line-height:1.5;font-size:13px;font-family:'helvetica neue',helvetica,arial,sans-serif">EGLImageTargetTexture2DOES to bind newly generated texture buffer from video decoder.</span></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">By supporting OES_EGL_image_external extension, application can use direct texture when video driver provides EGLImage like<span style="line-height:1.5" class="gmail_msg"> </span>OpenGL ES<span style="line-height:1.5" class="gmail_msg"> natvie applications.</span></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Our proposal is just focusing on extending format of texture compatible with OpenGL ES extension and does not conflict with previous proposals.</div><div class="gmail_msg"><span style="line-height:1.5" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="line-height:1.5" class="gmail_msg">So, we provides a simplest way to adopt </span>OES_EGL_image_external extension.<br class="gmail_msg"></div><div class="gmail_msg"><span style="line-height:1.5" class="gmail_msg"><br class="gmail_msg"></span></div><div class="gmail_msg"><span style="line-height:1.5" class="gmail_msg">By using references implementations of browser, WebGL renders video more than 10 times faster than TEXTURE_2D format with Full HD resolution output. </span><br class="gmail_msg"></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Kind regards,</div><div class="gmail_msg">Byungseon Shin</div><div class="gmail_msg"><div class="m_3284230554583456112h5 gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Tue, Oct 11, 2016 at 4:51 PM Maksims Mihejevs <<a href="mailto:max@playcanvas.com" class="gmail_msg" target="_blank">max@playcanvas.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg">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.</p><br class="gmail_msg"><p dir="ltr" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg">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.</p><br class="gmail_msg"><div class="gmail_extra m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><br class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><div class="gmail_quote m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg">On 11 Oct 2016 12:12 p.m., "Florian Bösch" <<a href="mailto:pyalot@gmail.com" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg" target="_blank">pyalot@gmail.com</a>> wrote:<br type="attribution" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><blockquote class="gmail_quote m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg">Am I correct in assuming that once you've called <span style="color:rgb(0,0,0)" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg">ext.</span><span style="color:rgb(0,0,0)" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg">EGLImageTargetTexture2DOES(</span><span style="color:rgb(0,0,0)" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg">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?</span><div class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><span style="color:rgb(0,0,0)" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><br class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"></span></div><div class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><span style="color:rgb(0,0,0)" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg">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.</span></div><div class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><span style="color:rgb(0,0,0)" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><br class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"></span></div><div class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><span style="color:rgb(0,0,0)" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg">There are some other extensions that have attempted to deal with this problem.</span></div><div class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><ul class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><li class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><font color="#000000" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><a href="https://www.khronos.org/registry/webgl/extensions/rejected/WEBGL_texture_from_depth_video/" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg" target="_blank">https://www.khronos.org/registry/webgl/extensions/rejected/WEBGL_texture_from_depth_video/</a> : 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.<br class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"></font></li><li class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><font color="#000000" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"><a href="https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg" target="_blank">https://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/</a> : 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.</font></li></ul><span style="color:rgb(0,0,0)" class="m_3284230554583456112m_2863902996054973688gmail_msg gmail_msg"> 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?</span></div></div><br class="gmail_msg"></blockquote></div></div><br class="gmail_msg"></blockquote></div></div></div></div></div><br></blockquote></div><br class="gmail_msg"></div><br></blockquote></div></div></div>