Robert Shearman wrote:
Dear Robert I meant to drop you a note, ask what is the status. But you bit me to it.
I have 7 years experience in writing DS filters.
Nice! Hopefully I will be able to call on that experience in the future?
Feel free any hour of the day
I am currently working on enhancing C++ on wine. I have ATL/WTL/MFC compiling and working under winelib. I have compiled COM controls generated by ATL VC++ wizards. I have some problems with the typelibs and so. But this is beside the subject. I would be happy to help in any way I can. I have lots of code that is not MS's. Also I have MS Direct Show Classes compiling and linking under Winelib (again some problems with the typelibs.)
I have my own copyrighted DirectShow video render that is implemented on top of DirectDraw. It uses the Overlay Surfaces YUV or RGB what ever is available/requested. It will also fall back to HW (HardWare) memory surfaces that are not overlay. I did not yet implement the Memory surfaces support. (didn't need to but it should be easy to add them).
Just for future reference, what are the pros/cons to using overlays rather than a plain off-screen surface?
There are 3 distinctions that should be made here. 1) YUV vs RGB - All professional video formats are YUV. conversion takes CPU and looses quality. This and the fact that all Video HW since 1997 support YUV conversion/display in HW, gives me the creeps to think that the CPU should do it. YUV was made for video.
2) HW buffer vs MEMORY buffer - this is mainly performance. Only the copy of full D1 (MPEG2) buffer to AGP will take 12% CPU no matter what system you have. In some very few Cards/driver combination it is done by DMA but then it still takes the AGP/PCI/DRAM bus. So best is have an HW buffer and decode directly to it, as done with Overlay-Mixer WinXP Video-Renderer and my filter. Also when using an HW decoder/grabber the Decoder can DMA directly to AGP with no CPU intervention and with no 2 pass video.
3) Overlay vs off-screen. Well the possible applications with Overlay buffers are endless. Since video is written to a lower surface and is viewed through a transparent color (key color) on the higher surface one can do things like Overlay a web page over video. (All you have to do is define your page background color as the transparent color), have a video desktop, have weird shaped video windows, subtitles ... . Also since blit of video data does not destroy normal Graphics, all the management of z order and clipping is much more efficient. All Linux players support overlay - MPlayer, Xine, and others.
I could release that code under wine I guess. If so I would also release the windows version of it. But before I do that, there are some issues to resolve (in order of importance):
- C++ code must be accepted - This is not an area that C is good
enough, and in any way I don't know C I am only good in C++
I'm afraid there is little chance of getting C++ code into Wine.
See my answer later in the mailing list to Mike and Lionel
- What is the status of the DDraw lib. Will it support HW and Overlay
2D surfaces? (does it support HW BOB)
I don't think DDraw distinguishes between HW and software surfaces, but I may be wrong. YUV and overlays aren't supported.
- I am some what dependent on MS DirectShow Classes. (Derivation) I
have a lot, self implemented, but some of the basic stuff I used. I guess I could reimplement them but it will take time. Do you know what is the license issues with this code. I know that I have delivered them to many paying clients, and it was checked by the legal department. I all ways thought that, that code is: Do what you like no liability what so ever.
I haven't checked the license, but I'm pretty sure that it wouldn't be free enough to include in Wine. I have created base classes for the IPin, IMediaSeeking and IMemAllocator interfaces, but they are probably in no way compatible with the MS provided ones. From the docs it seems that MS used C++ virtual functions for the functions that you need to extend. I have done this using function pointers passed to the pin init function. It would probably be possible to convert some code over to C and the Wine system, but perhaps it would be easier if I just ask you questions if I have a problem. Would that be possible?
Again ask away. About the license. I have decided to go head and rewrite all components that I use from MS SDK any way. ( A Karma thing). It will be in C++ for sure. Min while if any one needs a free (as in beer) Video-Render to distribute with his application. Contact me at ( boaz@ElectroZaur.com) and I'll send it. Eventually I'll also put a web page for it.
About the Graph manager: I'll think about it. I can certainly do it. But It is a big project. Do you know of a Company that would like to finance such a thing to some extent.
I don't know of any company, I'm afraid.
( condition 1 above applies C++ only).
Could you not just close your eyes and pretend? :)
I'll think about it any way. Maybe it is not as big as I think. (Usually projects are much bigger then I think they are)
You can take each function at a time and try to implement each function in terms of other functions (the documentation from the DirectX SDK is a big help here). If you think of it like that then it isn't a big task, just a number of small tasks :)
Rob
As you said I'll start function by function. I will write it in C++. Than when it's done, and if It comes to that, I'll translate it to C. I have done it before. Apart from declaration of the classes. it is almost Search & replace job. I have had to do it before.
And if any company needs that JOB DONE SOONER. Please be ready to support this project, it can be done but it will take time, and currently it will be done on my spare time.