DirectX plugins

Gildas Bazin gbazin at netcourrier.com
Fri May 18 08:30:43 CEST 2001


On Fri, 18 May 2001 03:53:13 Xavier Marchesini wrote:
> 
> Thank you very much for the patch. At the moment, a whole new video
> output is being coded by Samuel Hocevar (<sam at via.ecp.fr>), which will

I would very much like to hear about this new video output. There are a few
things I would like to see included in this new video output (not that much
though).

> have a lot a new features. I'm currently working on a DirectX (in fact,
> DirectDraw with DDOverlay Surface) plugin that will adapt to that new
> video output. Be sure your code will be very appreciated and used.
> 
> > Basically the video plugin is a DirectDraw plugin and for now it is
> only
> > working if you have a video card with YUV hardware overlay (which I
> beleive
> > most people have). 
> 
> As DirectX doesn't emulate overlay, I think we will check the hardware
> capabilities of the video card, and, depending on the answer, we will
> choose to use DirectDraw or SDL. 

This what I was planning to do: fall back using a plain DirectDraw surface
to copy the RGB converted pictures. And at one time it was kinda working
with my plugin but I was writting directly into the DirectDraw primary
surface and I don't think it's something that should be done.

The simplest way to handle that I suppose would be to create a double
buffered secondary surface in video memory if possible, and to copy the RGB
pictures into these surfaces (buffers). DirectDraw would then take care of
the blitting between these surfaces and the primary surface. I guess in a
normal situation this blitting would be hardware accelerated and thus won't
cost too much.

I don't think SDL is needed anymore, because it is basically doing the same
as the directx plugin but with more overhead.

> 
> The main problem is, as you said it, the fact that SDL under Win32 is
> quite buggy, and I haven't the time now to try to fix those bugs.
> 

It's not that bad... I only found this Overlay bug (or maybe missing
feature). The main problem I had with SDL is that you really have to read
its source code to be sure you are using it in the right way. The API is
not enough detailed. For example some functions have platrform limitations
but you cannot find them in the documentation....
Anyway I think its nice to have SDL support for portability reasons. But
concerning the Win32 port I don't see any reasons why we should need
anything else than the DirectX plugin.

> > And it's not yet optimized (no double buffering, and
> > we'll also have to had Shane Harper's optimizations for YUV overlay).
> 
> Why should we ? I think DirectX's handling of the YUV overlay is quite
> good, and the performances would be sufficient under Windows.
> 

The performance seems to be correct enough, even though I haven't test it
with a real DVD (I've been  using the THX vob trailer ;-)
But it could still improve because we make a copy of the YUV picture which
isn't required. The plugins receives a YUV buffer containing the picture
and copy it to another buffer. This step isn't required but instead the
mpeg decoder should store the YUV picture directly into the Overlay buffer.

> > The audio plugin is also functionnal but sometime the sound doesn't
> start
> > at the same time as the video.
> 
> The DirectX Audio Output is at this moment under the responsability of
> Boris Dorès <babal at via.ecp.fr> ; I think he'll be really keen on your
> plug-in.
> 

Great there are a few things I don't understand concerning the audio
output... but this will be for another mail.

> > Another thing: if you want these plugins to work you also have to
> include
> > my former patch (hack) for the video_output initialisation. ( on
> Windows
> > you have to create the video window in the same thread you will poll
> the
> > event otherwise you won't receive any of them ).
> > 
> > PS: I also included another patch which correct Win32 compilation
> problems
> > and which also includes the video_output initialisation patch.
> > PPS: I will also put a binary version of the VLC compiled with these
> > patches on the ftp site. (Because I know it's not an easy task to
> compile
> > it for Win32 (well it is but you need to have mingw32 install whith the
> > DirectX and SDL stuff)
> > PPPS: all the files (except the patch) where in directory named "windx"
> > under "plugins" on my machine.
> 
> We are at the moment trying to make a version of the VLC compiling under
> windows, with the Bcc compiler ; we'll have then to modify your patches.
> 

I've got nothing against a Bcc port, but do you plan to keep the mingw32
support. Personnaly I feel better when using GNU tools and I must say I
very much like to be able to cross-compile the Win32 VLC on my linux
computer.

> I don't think the changes you submitted will be integrated in the CVS
> right now, because of the new video output ; but your code will really
> help me in the task of writing that new plug-in.
> 

Oh too bad :_(
But even if the video output interface is changed, it shouldn't be too hard
to adapt the plugin to the new scheme because all the basic features should
stay the same: YUV overlay or surface blitting... ( just trying to convice
you ;-)


> Thank you again for your patches.
> 

Thanks for your quick answer.

> For the VideoLAN Team, 
> 
> -- 
> Xavier MARCHESINI
> 
> 
> 
> 






More information about the vlc-devel mailing list