1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
|
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.
|
