141 lines
5.0 KiB
Plaintext
141 lines
5.0 KiB
Plaintext
Name
|
|
|
|
ANDROID_recordable
|
|
|
|
Name Strings
|
|
|
|
EGL_ANDROID_recordable
|
|
|
|
Contributors
|
|
|
|
Jamie Gennis
|
|
|
|
Contact
|
|
|
|
Jamie Gennis, Google Inc. (jgennis 'at' google.com)
|
|
|
|
Status
|
|
|
|
Complete
|
|
|
|
Version
|
|
|
|
Version 2, July 15, 2011
|
|
|
|
Number
|
|
|
|
EGL Extension #51
|
|
|
|
Dependencies
|
|
|
|
Requires EGL 1.0
|
|
|
|
This extension is written against the wording of the EGL 1.4 Specification
|
|
|
|
Overview
|
|
|
|
Android supports a number of different ANativeWindow implementations that
|
|
can be used to create an EGLSurface. One implementation, which records the
|
|
rendered image as a video each time eglSwapBuffers gets called, may have
|
|
some device-specific restrictions. Because of this, some EGLConfigs may be
|
|
incompatible with these ANativeWindows. This extension introduces a new
|
|
boolean EGLConfig attribute that indicates whether the EGLConfig supports
|
|
rendering to an ANativeWindow that records images to a video.
|
|
|
|
New Types
|
|
|
|
None.
|
|
|
|
New Procedures and Functions
|
|
|
|
None.
|
|
|
|
New Tokens
|
|
|
|
Accepted by the <attribute> parameter of eglGetConfigAttrib and
|
|
the <attrib_list> parameter of eglChooseConfig:
|
|
|
|
EGL_RECORDABLE_ANDROID 0x3142
|
|
|
|
Changes to Chapter 3 of the EGL 1.4 Specification (EGL Functions and Errors)
|
|
|
|
Section 3.4, Configuration Management, add a row to Table 3.1.
|
|
|
|
Attribute Type Notes
|
|
---------------------- ------- --------------------------
|
|
EGL_RECORDABLE_ANDROID boolean whether video recording is
|
|
supported
|
|
|
|
Section 3.4, Configuration Management, add a row to Table 3.4.
|
|
|
|
Attribute Default Selection Sort Sort
|
|
Criteria Order Priority
|
|
---------------------- ------------- --------- ----- --------
|
|
EGL_RECORDABLE_ANDROID EGL_DONT_CARE Exact None
|
|
|
|
Section 3.4, Configuration Management, add a paragraph at the end of the
|
|
subsection titled Other EGLConfig Attribute Descriptions.
|
|
|
|
EGL_RECORDABLE_ANDROID is a boolean indicating whether the config may
|
|
be used to create an EGLSurface from an ANativeWindow that is a video
|
|
recorder as indicated by the NATIVE_WINDOW_IS_VIDEO_RECORDER query on
|
|
the ANativeWindow.
|
|
|
|
Section 3.4.1, Querying Configurations, change the last paragraph as follow
|
|
|
|
EGLConfigs are not sorted with respect to the parameters
|
|
EGL_BIND_TO_TEXTURE_RGB, EGL_BIND_TO_TEXTURE_RGBA, EGL_CONFORMANT,
|
|
EGL_LEVEL, EGL_NATIVE_RENDERABLE, EGL_MAX_SWAP_INTERVAL,
|
|
EGL_MIN_SWAP_INTERVAL, EGL_RENDERABLE_TYPE, EGL_SURFACE_TYPE,
|
|
EGL_TRANSPARENT_TYPE, EGL_TRANSPARENT_RED_VALUE,
|
|
EGL_TRANSPARENT_GREEN_VALUE, EGL_TRANSPARENT_BLUE_VALUE, and
|
|
EGL_RECORDABLE_ANDROID.
|
|
|
|
Issues
|
|
|
|
1. Should this functionality be exposed as a new attribute or as a bit in
|
|
the EGL_SURFACE_TYPE bitfield?
|
|
|
|
RESOLVED: It should be a new attribute. It does not make sense to use up a
|
|
bit in the limit-size bitfield for a platform-specific extension.
|
|
|
|
2. How should the new attribute affect the sorting of EGLConfigs?
|
|
|
|
RESOLVED: It should not affect sorting. Some implementations may not have
|
|
any drawback associated with using a recordable EGLConfig. Such
|
|
implementations should not have to double-up some of their configs to one
|
|
sort earlier than . Implementations that do have drawbacks can use the
|
|
existing caveat mechanism to report this drawback to the client.
|
|
|
|
3. How is this extension expected to be implemented?
|
|
|
|
RESPONSE: There are two basic approaches to implementing this extension
|
|
that were considered during its design. In both cases it is assumed that a
|
|
color space conversion must be performed at some point because most video
|
|
encoding formats use a YUV color space. The two approaches are
|
|
distinguished by the point at which this color space conversion is
|
|
performed.
|
|
|
|
One approach involves performing the color space conversion as part of the
|
|
eglSwapBuffers call before queuing the rendered image to the ANativeWindow.
|
|
In this case, the VisualID of the EGLConfig would correspond to a YUV
|
|
Android HAL pixel format from which the video encoder can read. The
|
|
EGLConfig would likely have the EGL_SLOW_CONFIG caveat because using that
|
|
config to render normal window contents would result in an RGB -> YUV color
|
|
space conversion when rendering the frame as well as a YUV -> RGB
|
|
conversion when compositing the window.
|
|
|
|
The other approach involves performing the color space conversion in the
|
|
video encoder. In this case, the VisualID of the EGLConfig would
|
|
correspond to an RGB HAL pixel format from which the video encoder can
|
|
read. The EGLConfig would likely not need to have any caveat set, as using
|
|
this config for normal window rendering would not have any added cost.
|
|
|
|
Revision History
|
|
|
|
#2 (Jamie Gennis, July 15, 2011)
|
|
- Added issue 3.
|
|
|
|
#1 (Jamie Gennis, July 8, 2011)
|
|
- Initial draft.
|