Hi,
Here is the new layout of the Multimedia section of the "Status Dll's" page. May I ask what you guys here think of it?, constructive criticism?
Tom
What about the DirectShow and DMO side of things. Should they not be listed to complete the Multimedia picture?
Mainly the filters in Quartz.dll and other basic filters that come with the OS.
if you want me to, I can make a list of the Basic filters and Interfaces that are needed (and the dlls they are implemented in. but that is not Important in DS) . I'm not sure which of them get Installed when you download a new Media player from MS, and which ones are strictly OS. I do know that the status must be good if CrossOver is able to run Windows-Media-Player.
Tom wrote:
Hi,
Here is the new layout of the Multimedia section of the "Status Dll's" page. May I ask what you guys here think of it?, constructive criticism?
Tom
Boaz Harrosh wrote:
What about the DirectShow and DMO side of things. Should they not be listed to complete the Multimedia picture?
Hi,
DirectShow = Quartz.dll And DirectShow is listed under the DirectX section of the status page as Quartz.dll is a part of DirectX.
http://www.winehq.com/site/status_dlls
But have no fear, I plan to expand the DirectX section next and list msdmo, devenum, d3d9 and so on. :-) But in the future im going to just go with Quartz.dll and not DirectShow as people ask me to also list quartz......
Mainly the filters in Quartz.dll and other basic filters that come with the OS.
If you can code im sure Robert would welcome the help :)
if you want me to, I can make a list of the Basic filters and Interfaces that are needed (and the dlls they are implemented in. but that is not Important in DS) .
Well so far we have only lised components that have to some degree been implemented in wine. Here is where I will cheat and ask, should I also list components that are not implemented? 0% items.......
I'm not sure which of them get Installed when you
download a new Media player from MS, and which ones are strictly OS. I do know that the status must be good if CrossOver is able to run Windows-Media-Player.
Yip.. And if you install the divx codecs into cx-plugin it will play divx movies :)
Tom
-----Original Message----- From: wine-devel-admin@winehq.org [mailto:wine-devel-admin@winehq.org]On Behalf Of Tom Sent: 02 December 2003 09:50 To: Boaz Harrosh Cc: Wine Development Subject: Re: Status : Multimedia section
Boaz Harrosh wrote:
What about the DirectShow and DMO side of things. Should they not be listed to complete the Multimedia picture?
Hi,
DirectShow = Quartz.dll And DirectShow is listed under the DirectX section of the status page as Quartz.dll is a part of DirectX.
http://www.winehq.com/site/status_dlls
But have no fear, I plan to expand the DirectX section next and list msdmo, devenum, d3d9 and so on. :-) But in the future im going to just go with Quartz.dll and not DirectShow as people ask me to also list quartz......
Mainly the filters in Quartz.dll and other basic filters that come with the OS.
If you can code im sure Robert would welcome the help :)
Definitely! If anyone would like to help with this please get in contact with me so I can help explain how I've implemented certain things so far, about locking, etc. The main things that are left to do to play 90% of media files out there are implementing the filter graph manager, the reference clock and the audio and video renderers (I have a hacky version of the video renderer in my local tree but it is not ready for submitting as a patch). Anyone that likes COM and graph algorithms should love the filter manager!
I'm not sure which of them get Installed when you
download a new Media player from MS, and which ones are strictly OS. I do know that the status must be good if CrossOver is able to run Windows-Media-Player.
That must not be using the code in the Wine tree as it won't play any movies at the moment :(
Rob
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. 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). 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):
1. 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++ 2. What is the status of the DDraw lib. Will it support HW and Overlay 2D surfaces? (does it support HW BOB) 3. 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.
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. ( condition 1 above applies C++ only). 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)
Robert Shearman wrote:
-----Original Message----- From: wine-devel-admin@winehq.org [mailto:wine-devel-admin@winehq.org]On Behalf Of Tom Sent: 02 December 2003 09:50 To: Boaz Harrosh Cc: Wine Development Subject: Re: Status : Multimedia section
Boaz Harrosh wrote:
What about the DirectShow and DMO side of things. Should they not be listed to complete the Multimedia picture?
Hi,
DirectShow = Quartz.dll And DirectShow is listed under the DirectX section of the status page as Quartz.dll is a part of DirectX.
http://www.winehq.com/site/status_dlls
But have no fear, I plan to expand the DirectX section next and list msdmo, devenum, d3d9 and so on. :-) But in the future im going to just go with Quartz.dll and not DirectShow as people ask me to also list quartz......
Mainly the filters in Quartz.dll and other basic filters that come with the OS.
If you can code im sure Robert would welcome the help :)
Definitely! If anyone would like to help with this please get in contact with me so I can help explain how I've implemented certain things so far, about locking, etc. The main things that are left to do to play 90% of media files out there are implementing the filter graph manager, the reference clock and the audio and video renderers (I have a hacky version of the video renderer in my local tree but it is not ready for submitting as a patch). Anyone that likes COM and graph algorithms should love the filter manager!
I'm not sure which of them get Installed when you
download a new Media player from MS, and which ones are strictly OS. I do know that the status must be good if CrossOver is able to run Windows-Media-Player.
That must not be using the code in the Wine tree as it won't play any movies at the moment :(
Rob
- What is the status of the DDraw lib. Will it support HW and Overlay
2D surfaces? (does it support HW BOB)
Overlay 2D surfaces are not supported anymore. It's been on my TODO list for a long time now to re-add them but never got the motivation to work on it (as I never use Wine to play videos :-) ).
Lionel
-----Original Message----- From: Boaz Harrosh [mailto:boaz@hishome.net] Sent: 02 December 2003 19:20 To: Robert Shearman Cc: twickline@skybest.com; wine-devel@winehq.org Subject: Re: Status : Multimedia section
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?
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?
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.
- 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?
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
On Thu, 2003-12-04 at 18:39, Robert Shearman wrote:
- 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.
It might be worth revisiting this issue at some point. Microsoft themselves use C++ heavily inside parts of Windows (like OLE). Wine already includes many different languages (C, x86 assembly, bison/flex grammars, perl, bash etc), adding another would not be a new thing.
We also have a problem in that in one day we'll want to do MSHTML and every free HTML rendering engine of sufficient power is written in C++, so C++ will be needed in order to interface with it.
Don't get me wrong, I'm not the biggest fan of C++, but the iirc the traditional reasons for not including C++ in Wine are:
* Support for it is bad in the free software toolchain (no longer an issue) * Not as many people know it as C (but even fewer know assembly and we use that all over the place) * Windows is written in C (it's also written in c++ though, esp the more modern parts).
Have I missed any other problems with it?
On Fri, Dec 05, 2003 at 10:45:26AM +0000, Mike Hearn wrote:
- Support for it is bad in the free software toolchain (no longer an
issue)
- Not as many people know it as C (but even fewer know assembly and we
use that all over the place)
- Windows is written in C (it's also written in c++ though, esp the more
modern parts).
Have I missed any other problems with it?
Well, the most common concern about it is the continuous ABI changes in the C++ libraries... Which were promised to be ended with GCC 3.3 but seems still to shift a bit.
After, is there a way in the 'free' C++ compiler to match COM objects with C++ objects ?
Lionel
I second Mike on this. I think it is cardinal to the wine project. If wine fails to correctly address this in the future (accept C++ projects) there will come a time that some one will split wine yet again. winehq - some windows implementation. wine++ - winehq + C++ projects for a more robust wine.
C++ ABI changes does not concern wine nor windows. Actually COM was defined exactly in the manner that will not be affected by C++ ABI. One can say that COM is the lowest common denominator of the C++ compilers. GCC has been producing COM compatible ABI for years. On windows as well as in Linux and other x86 platforms. The Mozilla project has been counting on this since the beginning. It is not a theoretically if. It is working today. I have MFC and ATL/WTL compiled under Linux fully supporting COM-controls. Windows binaries that is. Linux compiled controls I don't yet have because of the TLBS but I'll get to it eventually. Actually wine headers today support C++ compilation for all Interface declarations. Also the WDL will produce C++ compatible headers.
About mixing of C++ objects with COM Objects it is done exactly has on windows. If you stick to the COM rules you can do what you like (internally). If you are concerned with C++ run-time like STL and GLIBC++, than C++ programmers know these problems and how to avoid them. There are bigger projects than wine that has written the books about these issues. One just has to follow the rules and avoid the mistakes of the past. These things happen in C too. Just now we had an issue with RH 9 new GLIBC and a special code was written to detect that in runtime. The maintainer of the C++ code will have to watch for these things. And they will be discovered and patched soon enough.
Lionel Ulmer wrote:
On Fri, Dec 05, 2003 at 10:45:26AM +0000, Mike Hearn wrote:
- Support for it is bad in the free software toolchain (no longer an
issue)
- Not as many people know it as C (but even fewer know assembly and we
use that all over the place)
- Windows is written in C (it's also written in c++ though, esp the more
modern parts).
Have I missed any other problems with it?
Well, the most common concern about it is the continuous ABI changes in the C++ libraries... Which were promised to be ended with GCC 3.3 but seems still to shift a bit.
After, is there a way in the 'free' C++ compiler to match COM objects with C++ objects ?
Lionel
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.
-
Boaz Harrosh -
Lionel Ulmer -
Mike Hearn -
Robert Shearman -
Tom