Status : Multimedia section

[Boaz Harrosh]

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):
>>
>>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++
>>    
>>
>
>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

>>2. 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.
>
>  
>
>>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.
>>    
>>
>
>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 at 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.