Thanks updating the spec. I am not comfortable with calling this OES_EGL_image_external and especially not with reusing the function name EGLImageTargetTexture2DOES. I think you are really wrapping the OES extension NV_EGL_stream_consumer_external. This is actually what WEBGL_dynamic_texture is wrapping.
I also wonder if using the same function for initial setup and for latching each frame is a good idea. The work to be done will be different so there should be different functions.
I think it would be better to go back to WEBGL_dynamic_texture, simplify it a bit by changing its WDTStream class to be a bit more like Android’s SurfaceTexture and adding the essl3 support.
I know at first glance WDT looks way more complex than this current proposal but that is because it documents precise detailed behavior while the current proposal still leaves a lot to the imagination. The only real functional difference is the presence of a call to set the presentation time of the drawing buffer. This function is also the area of greatest concern for browser vendors. I note though that Android’s MediaCodec class provides this capability via its