[FFmpeg-devel] [PATCH 3/3] lavd: add opengl device

Lukasz Marek lukasz.m.luki at gmail.com
Sat Jan 25 01:00:27 CET 2014


On 24.01.2014 02:12, Michael Niedermayer wrote:
> On Thu, Jan 23, 2014 at 11:45:02PM +0100, Lukasz Marek wrote:
>> On 19.01.2014 17:35, Lukasz M wrote:
>>> On 19 January 2014 14:46, Lukasz M <lukasz.m.luki at gmail.com
>>> <mailto:lukasz.m.luki at gmail.com>> wrote:
>>>
>>>     On 19 January 2014 03:46, Lukasz M <lukasz.m.luki at gmail.com
>>>     <mailto:lukasz.m.luki at gmail.com>> wrote:
>>>
>>>         Updated patch attached. I hope I handled every remark.
>>>
>>>         Tested on
>>>         SDL window: Windows (mingw), Ubuntu 12.04, Ubuntu 13.10, Mac 10.7
>>>         External context: qt 4.8 app on Ubuntu 13.10, iOS ipad
>>>         simulator, iPad 2 device.
>>>
>>>         I will submit examples later, but I wanted to use
>>>         write_uncoded_frame, so examples are more focused on device, not
>>>         on demuxing, muxing etc...
>>>
>>>
>>>       libavdevice/avdevice.h           |    2 +-
>>>       libavformat/avformat.h           |    2 +-
>>>
>>>     I just noticed I squashed things to wrong commit, I will resubmit it
>>>     with these changes removed.
>>>
>>>
>>> patch rebased on newer control message API and removed 2 changes
>>> mentioned above.
>>>
>>
>> Another rebase. Any comments btw?
>
> about opengl itself, not from me, iam no opengl expert
> others around here know opengl much better ...
>
>
> [...]
>
>> +#if defined(__APPLE__)
>> +#if HAVE_OPENGL_GL3_H
>> +#include <OpenGL/gl3.h>
>> +#else
>> +#include <OpenGLES/ES2/gl.h>
>> +#endif
>> +#else
>> +#include <GL/gl.h>
>> +#include <GL/glext.h>
>> +#endif
>> +
>> +#if HAVE_SDL
>> +#include <SDL.h>
>> +#endif
>> +#if HAVE_GLXGETPROCADDRESS
>> +#include <GL/glx.h>
>> +#endif
>> +#if defined(__MINGW32__)
>> +#include <windows.h>
>> +#endif
>> +
>
> these checks on __APPLE__ and __MINGW32__ smell wrong
> code should generally not check on platform type but on the actual
> things that you need like header availability or whatever

Fixed

>
>
> [...9
>
>> +#define BUFFER_OFFSET(i) ((char *)NULL + (i))
>
> iam not sure this is strictly allowed in C99

Yes, it is a hack, but it common pattern for opengl VBO code.
Here is nice discussion about this problem:
http://stackoverflow.com/questions/8283714/
I followed solution at the end of second answer, but not sure what
is better (or worse).
On the other hand this macro is even defined in Apple's templates so...

> [...]
>
>> +static av_cold void opengl_get_texture_params(OpenGLContext *opengl)
>> +{
>> +    switch(opengl->pix_fmt) {
>> +    case AV_PIX_FMT_YUV420P:    case AV_PIX_FMT_YUV444P:
>> +    case AV_PIX_FMT_YUV422P:    case AV_PIX_FMT_YUV410P:
>> +    case AV_PIX_FMT_YUV411P:    case AV_PIX_FMT_YUV440P:
>> +    case AV_PIX_FMT_YUVA420P:   case AV_PIX_FMT_YUVA444P:
>> +    case AV_PIX_FMT_YUVA422P:
>> +    case AV_PIX_FMT_GBRP:       case AV_PIX_FMT_GBRAP:
>> +#if defined(GL_RED)
>> +        opengl->format = GL_RED;
>> +#elif defined(GL_LUMINANCE)
>> +        opengl->format = GL_LUMINANCE;
>> +#else
>> +        opengl->format = 0x1903; //GL_RED
>> +#endif
>
> why is this handled differently than for example a missing M_PI ?

I moved these ifs to the beginning and added a comment about it.
For planar formats I create as many textures as many planes there is.
Each texture provides one component Y/Cb/Cr/A or R/G/B/A.
In general textures at shader may be sampled for all RGBA components,
but I assumed only R is sampled and it contains one of the components 
(depending which texture you sample)
And now, when you upload texture to gpu, you need to define its format.
You may choose from: GL_RED, GL_LUMINANCE, GL_INTENSITY (types with just 
one component as there is only one in each plane)
Depending on it you will have different values on RGBA values that can 
be sampled at shader

GL_RED produces RGBA = [value, 0, 0, 1]
GL_LUMINANCE produces RGBA = [value, value, value, 1]
GL_INTENSITY may also be used RGBA = [value, value, value, value]

Each of them gives wanted component on R.

And finally to answer your question. On some platforms not all of them 
are available. For example on Mac OSX there is only GL_RED while it is 
missing in iOS framework. iOS provides GL_LUMINANCE without GL_RED.
I prefer to use the type that is available on given platform.
I haven't tested what would happen when GL_RED is used on iOS tho (or 
vice versa).

I hope it is more or less clear now.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-lavd-add-opengl-device.patch
Type: text/x-patch
Size: 63942 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140125/c84d83d7/attachment.bin>


More information about the ffmpeg-devel mailing list