[vlc-devel] Mac OS X blank white screen problem with fix

[Juha Jeronen]

On 01/21/2011 12:39 AM, Scott Herscher wrote:
> Well I was going by the opengl.h implementation in 1.5.5.  It also had the following lines:
>
> #ifdef __APPLE__
> /* On OS X, use GL_TEXTURE_RECTANGLE_EXT instead of GL_TEXTURE_2D.
>     This allows sizes which are not powers of 2 */
> # define VLCGL_TARGET GL_TEXTURE_RECTANGLE_EXT
>
> /* OS X OpenGL supports YUV. Hehe. */
> # define VLCGL_FORMAT GL_YCBCR_422_APPLE
> # define VLCGL_TYPE   GL_UNSIGNED_SHORT_8_8_APPLE
>
> # define VLCGL_TEXTURE_COUNT (2)
> #else
>
>
>    
Ok.

> but, it used the constant "3" as the third argument in glTextImage2D().
That's interesting. It seems the updated version never worked, then :)

> The OpenGL docs were a little vague about what the constant "3" means, so it's hard to say what the right value should be.  I'm not sure why the value was changed from "3" to VLCGL_FORMAT.
>    
Yeah.

Hmm, looking at the glTexImage2D() doc ( 
http://www.opengl.org/sdk/docs/man/xhtml/glTexImage2D.xml ), it says 
(note the final parenthetical remark):

---8<---8<---8<---

If an application wants to store the texture at a certain resolution or 
in a certain format, it can request the resolution and format with 
internalFormat. The GL will choose an internal representation that 
closely approximates that requested by internalFormat, but it may not 
match exactly.
(The representations specified by GL_LUMINANCE, GL_LUMINANCE_ALPHA, 
GL_RGB, and GL_RGBA must match exactly. The numeric values 1, 2, 3, and 
4 may also be used to specify the above representations.)

---8<---8<---8<---

So "3" == GL_RGB.

As for why internalFormat accepts confusing values, I found this:

http://www.berkelium.com/OpenGL/GDC99/internalformat.html

According to that page, internalFormat used to be called "components", 
and valid values were just the integers 1..4 until OpenGL version 1.1, 
where the symbolic internalFormats were first introduced.

Also, (note the first sentence)

---8<---8<---8<---

Please note that your choice of setting for internalformat is 
independent of your choice of type and format; even if you choose to 
store a texture at low resolution, you must still present the data using 
standard types and formats (e.g. four bytes per texel if the type/format 
is GL_UNSIGNED_BYTE, GL_RGBA).

---8<---8<---8<---

So it seems that "internalFormat" and "format" are two different things, 
and care should be taken to distinguish them.

It also seems, judging from the behavior, that Apple might have never 
implemented the format GL_YCBCR_422_APPLE as a valid value for the 
"internalFormat" parameter, although it is a valid "format".

This also explains why opengl.c works on other platforms - for them, 
GL_RGB (which is functionally identical to "3", so nothing has changed 
since 1.1.5) gets passed in as internalFormat.

Googling for "GL_YCBCR_422_APPLE internalformat" gives
http://lists.apple.com/archives/mac-opengl/2010/Jul/msg00003.html

which says, in a quoted message,

---8<---8<---8<---

 > glTexImage2D(texEnum,        // GLenum target,
 >             0,            // GLint level,
 >             GL_RGBA,        // GLint internal format,
 >             texWidth,        // GLsizei width,
 >             texHeight,        // GLsizei height,
 >             0,            // GLint border,
 >             GL_YCBCR_422_APPLE,
 >             GL_UNSIGNED_SHORT_8_8_APPLE,
 >             pData );        //const GLvoid *pixels

---8<---8<---8<---

Another search result: see GL_CreateTexture() in
http://svn.libsdl.org/branches/gsoc2009_ps3/SDL/src/video/SDL_renderer_gl.c

which says

---8<---8<---8<---

     case SDL_PIXELFORMAT_UYVY:
         if (renderdata->GL_APPLE_ycbcr_422_supported) {
             internalFormat = GL_RGB;
             format = GL_YCBCR_422_APPLE;

     // ...

---8<---8<---8<---

So, it seems that the correct "internalFormat" is GL_RGB (or GL_RGBA 
depending on what the renderer wants to do) even if "format" is 
GL_YCBCR_422_APPLE.

Thus, changing internalFormat back to the numeric value "3", as 
suggested in the diff, shouldn't have any undesirable side effects. An 
equivalent alternative is to pass GL_RGB, which is maybe slightly more 
self-documenting (although with some potential confusion, since YCBCR is 
not RGB).

Now only to wait for an official dev to comment on this ;)

  -J