[MPlayer-dev-eng] Writing a brand new D3D video output to fix Vista Aero disabling
Georgi Petrov
gogothebee at gmail.com
Tue Jun 3 11:28:54 CEST 2008
Hmm, is it right that in preinit I shouldn't create the render window
on the screen, but just initialize enough to support format query
afterwards?
Is it right that the first creation of window on the screen should
happen after the first "config" call with some height/width
parameters? And is it right that after each call of config (if this is
not the first one), I should release the window, close everything D3D
related and create it again?
On Tue, Jun 3, 2008 at 10:09 AM, Georgi Petrov <gogothebee at gmail.com> wrote:
> 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