[MPlayer-dev-eng] Writing a brand new D3D video output to fix Vista Aero disabling
Georgi Petrov
gogothebee at gmail.com
Tue Jun 3 09:09:41 CEST 2008
Ooops, I saw that in preinit you initialize the values of
*.drv_caps... Sorry about the stupid question. Forget it :)
On Tue, Jun 3, 2008 at 10:00 AM, Georgi Petrov <gogothebee at gmail.com> wrote:
> Ok, I made I nice progress - now I have separate vo_d3d.c file, which
> gets compiled and I can give the option -vo d3d. I figured out almost
> everyhing I will need from the D3D side, but I'll have some question
> in the following days.
>
> Here is the first one. Sasha, as I saw, you made the whole win32 port
> and vo_directx.c, so may you may know better. About the format query,
> you've written this struct:
>
> typedef struct directx_fourcc_caps
> {
> char* img_format_name; //human readable name
> uint32_t img_format; //as MPlayer image format
> uint32_t drv_caps; //what hw supports with this format
> DDPIXELFORMAT g_ddpfOverlay; //as Directx Sourface description
> } directx_fourcc_caps;
>
>
> static directx_fourcc_caps g_ddpf[] =
> {
> {"YV12 ",IMGFMT_YV12 ,0,{sizeof(DDPIXELFORMAT),
> DDPF_FOURCC,MAKEFOURCC('Y','V','1','2'),0,0,0,0,0}},
> {"I420 ",IMGFMT_I420 ,0,{sizeof(DDPIXELFORMAT),
> DDPF_FOURCC,MAKEFOURCC('I','4','2','0'),0,0,0,0,0}}, //yv12 with
> swapped uv
> {"IYUV ",IMGFMT_IYUV ,0,{sizeof(DDPIXELFORMAT),
> DDPF_FOURCC,MAKEFOURCC('I','Y','U','V'),0,0,0,0,0}}, //same as i420
> {"YVU9 ",IMGFMT_YVU9 ,0,{sizeof(DDPIXELFORMAT),
> DDPF_FOURCC,MAKEFOURCC('Y','V','U','9'),0,0,0,0,0}},
> {"YUY2 ",IMGFMT_YUY2 ,0,{sizeof(DDPIXELFORMAT),
> DDPF_FOURCC,MAKEFOURCC('Y','U','Y','2'),0,0,0,0,0}},
> {"UYVY ",IMGFMT_UYVY ,0,{sizeof(DDPIXELFORMAT),
> DDPF_FOURCC,MAKEFOURCC('U','Y','V','Y'),0,0,0,0,0}},
> {"BGR8 ",IMGFMT_BGR8 ,0,{sizeof(DDPIXELFORMAT), DDPF_RGB, 0, 8,
> 0x00000000, 0x00000000, 0x00000000, 0}},
> {"RGB15",IMGFMT_RGB15,0,{sizeof(DDPIXELFORMAT), DDPF_RGB, 0, 16,
> 0x0000001F, 0x000003E0, 0x00007C00, 0}}, //RGB 5:5:5
> {"BGR15",IMGFMT_BGR15,0,{sizeof(DDPIXELFORMAT), DDPF_RGB, 0, 16,
> 0x00007C00, 0x000003E0, 0x0000001F, 0}},
> {"RGB16",IMGFMT_RGB16,0,{sizeof(DDPIXELFORMAT), DDPF_RGB, 0, 16,
> 0x0000001F, 0x000007E0, 0x0000F800, 0}}, //RGB 5:6:5
> {"BGR16",IMGFMT_BGR16,0,{sizeof(DDPIXELFORMAT), DDPF_RGB, 0, 16,
> 0x0000F800, 0x000007E0, 0x0000001F, 0}},
> {"RGB24",IMGFMT_RGB24,0,{sizeof(DDPIXELFORMAT), DDPF_RGB, 0, 24,
> 0x000000FF, 0x0000FF00, 0x00FF0000, 0}},
> {"BGR24",IMGFMT_BGR24,0,{sizeof(DDPIXELFORMAT), DDPF_RGB, 0, 24,
> 0x00FF0000, 0x0000FF00, 0x000000FF, 0}},
> {"RGB32",IMGFMT_RGB32,0,{sizeof(DDPIXELFORMAT), DDPF_RGB, 0, 32,
> 0x000000FF, 0x0000FF00, 0x00FF0000, 0}},
> {"BGR32",IMGFMT_BGR32,0,{sizeof(DDPIXELFORMAT), DDPF_RGB, 0, 32,
> 0x00FF0000, 0x0000FF00, 0x000000FF, 0}}
> };
>
>
> And then there is query_format:
>
> static int
> query_format(uint32_t format)
> {
> uint32_t i=0;
> while ( i < NUM_FORMATS )
> {
> if (g_ddpf[i].img_format == format)
> return g_ddpf[i].drv_caps;
> i++;
> }
> return 0;
> }
>
> Sorry about the long post. As I understand, you always check if the
> queried MPlayer's image format is the same as DirectX one's and if it
> is, "return g_ddpf[i].drv_caps". This whole function seems pointless
> to me, because in the structure ALL *.drv_caps is == 0 and even if the
> required format isn't found, you return 0 as well...
>
> So my question is - why do you always return zero? Shouldn't I check
> to see if the queried format is actually supported? There is nice
> function "IDirect3D9_CheckDeviceFormat", which does exactly this.
>
> And my second question - why 0, when we have those defines from format query:
>
> // set, if the given colorspace is supported (with or without conversion)
> #define VFCAP_CSP_SUPPORTED 0x1
> // set, if the given colorspace is supported _without_ conversion
> #define VFCAP_CSP_SUPPORTED_BY_HW 0x2
>
> For example vo_gl.c driver's logic is to return 0 when some format is
> NOT supported and 1 (VFCAP_CSP_SUPPORTED) when it is...
>
> Also - should I return 2, when there is really HW support? I mean -
> what's the difference between 1 (VFCAP_CSP_SUPPORTED) and 2
> (VFCAP_CSP_SUPPORTED_BY_HW)?
>
> On Sun, Jun 1, 2008 at 2:50 PM, Georgi Petrov <gogothebee at gmail.com> wrote:
>> Thanks guys, I've already started. Today my first task is to compile
>> with VS2008 a simple D3D app that only initializes the library,
>> because I've never did such thing before.
>>
>> Now I read vo_tga, vo_directx, vo_gl and soon I'll have some questions.
>>
>> libvo.txt seems like a real mess, but it's a starting point after all :)
>>
>>>-vo gl:yuv=2 definitely will work with ATI, and I think it works with
>>>Intel, too (though I have not tested personally).
>>
>> I'll investigate further when I have at least partially working D3D
>> implementation. When it comes to vo_gl and vo_directx, at least I
>> already know where to ask my questions :)
>>
>>
>>
>>>Making D3D the default AFAICT means dropping support for GeForce 3 and
>>>anything similarly old/weak without doing yuv->rgb in software.
>>>It certainly is an option, though it may be better to either leave such
>>>decisions to others (e.g. smplayer not defaults to vo gl on Vista it
>>>seems - unfortunately with slow settings) or extend the way the default
>>>vo is selected to make better decisions (e.g. adding a get_score
>>>function and trying the vos in order of the score they returned).
>>>There is also the question which D3D version you intend to use and if
>>>and how a generic MPlayer build can still run on Win9x.
>>
>> Hmm, this doesn't sound good. I think that the best option is to
>> implement (if this is not already done) HW/OS detection and in case of
>> Vista for example, default to D3D. On XP and lower default to
>> DirectDraw. About dropping anything lower than Geforce 3 - do you mean
>> that only HW supporting DX8 and upwards can use D3D for video output?
>> For example - if we take a Geforce 4 MX440 (DX7 card), does it mean
>> that it won't support DirectX 9 Surface, which is needed for our
>> driver to work? I'm completely new to DirectX programming and I'll
>> experiment as much as I can. At least I have many friends with
>> different classes of video cards and I can borrow them for a while :)
>>
>>>What kind of card is that? The newer (PCIe) cards at least on Linux only
>>>support a kind of emulated overlay that has none of these problems, it
>>>has only an arbitrary limit of 32 simultaneous videos (unfortunately, it
>>>does not support setting of hue/saturation/contrast/brightness/gamma,
>>>though this seems more like a driver than hardware limitation).
>>
>> This is on Geforce 7600GS. On XP the overlay is not emulated when
>> dealing with DirectDraw7. It's very real. I think that Geforce 8xxx
>> (DX10 class) doesn't have HW overlay anymore and use sharders.
>>
>> In XP when using DirectDraw7 happens exactly this - you have ONE
>> overlay and the first video takes it. It can be even configured to be
>> displayed on the TVOUT scaled up automatically. Every video afterward
>> doesn't get overlay.
>>
>> In Vista when I launch video through DirectDraw7 and move it to the
>> second video out (the TVOUT), the whole windows is green and the video
>> doesn't appear on the TV. It's actually impossible to watch the video
>> on the second display!!!!! When using VLC with D3D video out, no such
>> thing happens - if I move the window to the second display (the TV),
>> it works.
>>
>> My objective is to write as general purpose driver as possible and
>> still with the best performance/compatibility. As far as I understand:
>>
>> - performance wise we don't lose anything compared to DirectDraw7
>> - compatibility wise we may loose video cards before DX8. This should
>> be checked first.
>> - compatibility wise we gain support for Vista Aero as well as more
>> than one HW overlay
>> - may be gain/lose more
>>
>>
>>
>>
>>
>>
>> On Sun, Jun 1, 2008 at 2:22 PM, Reimar Döffinger
>> <Reimar.Doeffinger at stud.uni-karlsruhe.de> wrote:
>>> On Sat, May 31, 2008 at 03:41:24AM +0300, Georgi Petrov wrote:
>>>> Do you mean that with ATi hardware/drivers -vo gl:yuy=1 doesn't work
>>>> at all? If it doesn't, that's one of the other reasons I want to
>>>> develop D3D driver - because it's supported for sure even in the most
>>>> retarded drivers for Vista (nothing against ATi. I mean something like
>>>> SiS if they are still alive...).
>>>
>>> -vo gl:yuv=2 definitely will work with ATI, and I think it works with
>>> Intel, too (though I have not tested personally).
>>> A big problem with Vista is that enabling vsync seems to eat up 10% CPU
>>> in some kernel driver.
>>> Since vsync is not needed with Aero enabled, you should try
>>> -vo gl:yuv=2:force-pbo:swapinterval=0 (for ATI cards you will also need
>>> to add ati-hack, this is probably due to yet another driver bug).
>>>
>>>> VLC's D3D module doesn't use VMR as well as far as I can
>>>> understand the source code.
>>>
>>> Not using VMR (or is that only since EVR or whatever the next version is
>>> called) also means you do not get on-GPU deinterlacing, no advanced scaling
>>> (unless you write your own scalers) etc.
>>>
>>>> Once I have working D3D module and the performance is as expected on
>>>> par with the -vo directx's current DirectDraw, I supposse that it
>>>> would make sense after extensive testing to make it the default
>>>> drawing mode for Windows, because DirectDraw is dying from my
>>>> perspective. It doesn't hurt Windows XP, but for Vista it's a real
>>>> pain.
>>>
>>> Making D3D the default AFAICT means dropping support for GeForce 3 and
>>> anything similarly old/weak without doing yuv->rgb in software.
>>> It certainly is an option, though it may be better to either leave such
>>> decisions to others (e.g. smplayer not defaults to vo gl on Vista it
>>> seems - unfortunately with slow settings) or extend the way the default
>>> vo is selected to make better decisions (e.g. adding a get_score
>>> function and trying the vos in order of the score they returned).
>>> There is also the question which D3D version you intend to use and if
>>> and how a generic MPlayer build can still run on Win9x.
>>>
>>>> Also - if I'm not mistaken DirectDraw offers HW accelerated overlay
>>>> only for the FIRST player instance. Every other MPlayer instance
>>>> doesn't get HW overlay (because it's only one available) and the video
>>>> looks terrible. Especially upscaled. Try it - launch MPlayer, then
>>>> launch another instance with another video (both instances using -vo
>>>> directx) and observe the second one's quality. If you can't tell the
>>>> difference, hit "f" for full screen and enjoy terrible quality :)
>>>>
>>>> This is all related to XP. In Vista the second video doesn't work at
>>>> all! It's all green (colorkey) and nothing happens :)
>>>
>>> What kind of card is that? The newer (PCIe) cards at least on Linux only
>>> support a kind of emulated overlay that has none of these problems, it
>>> has only an arbitrary limit of 32 simultaneous videos (unfortunately, it
>>> does not support setting of hue/saturation/contrast/brightness/gamma,
>>> though this seems more like a driver than hardware limitation).
>>>
>>> Greetings,
>>> Reimar Döffinger
>>> _______________________________________________
>>> MPlayer-dev-eng mailing list
>>> MPlayer-dev-eng at mplayerhq.hu
>>> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>>>
>>
>
More information about the MPlayer-dev-eng
mailing list