[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:00:12 CEST 2008
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