[MPlayer-cygwin] Some questions about the MinGW port

[NoiseEHC]

So the Win32 all-other-player-killer requirements:
1. No vidix/opengl/sdl support, only use DirectX
2. Sound only via DirectX/fallback to WaweOut
3. Only video player, no music (NO .wav, .mp3...)
The idea here is that these require quite different UIs.
4. No playlists (it is useful only for music)
5. Probably a DirectX test program to build a buggy driver database
6. External GUI probably will not be enough since there are no 
fullscreen controls...
7. A classic player look or at least a skin which has a WIDE position 
slider...
(It is a common problem with players that they have a so narrow slider 
that it is
almost impossible to seek in long movies...)
8. Optionally save settings for movies
(It is missing from all of the players. For example one of my movie 
needs higher
contrast than the default, etc)
9. No encoder
10. Do not use installed codecs only in /codec
11. fast, Fast, FAST!!!

What do you think especially about 6?

>Maybe you don't even need to recompile MPlayer for this,
>just set
>brightness=value
>contrast=value
>etc. in your mplayer/config file
>Check man_page.html for details.
>  
>
Thanks, that worked :)

>Maybe it is the best you start with the prebuild libraries Reimar sent to this 
>list, but you are right I should write some build howto that explains the 
>various tweaks needed to compile the libs on mingw. Hopefully I find a bit of 
>time for this during the christmas holidays.
>Once you have all the libs in the correct place. A new binary can simply be 
>produced from cvs sources with
>./configure --enable-debug=3 --enable-static --with-codecsdir=codecs 
>--enable-runtime-cpudetection
>make
>  
>
Waiting mode.... :)

>For simple experiments the cygwin environment is maybe better because it 
>already includes many packages.
>  
>
I think MinGW is better not only it is smaller but no need for cygwin.dll.

>>As I know you also released an alpha MPlayer-GUI, is it a patch to the
>>current source three, or will I get it once
>>I will able to compile with --enable-gui???
>>
>>    
>>
>
>No, sorry, it was an experiment a few months ago and the patches are totally 
>outdated. The windows gui should stay outside the MPlayer tree and only 
>communicate with MPlayer using the slave mode.
>For the skinned gui there is still the dream of a new and clean all in one 
>external linux/macosx and windows gui
>  
>
Does it mean that there should be a Win32 C program which can consume 
the skins? What I thought is
that there should be a "Classic" Media Player look since many users 
(including me) just want to play
movies and not to look at beautiful nonrectangular windows...

>>My final goal would be to create a version which can render to a window
>>in a helper process so I could embed it to
>>Mozilla Firefox since all the players sux at best on windows.
>>    
>>
>
>Also see the -wid patch that has recently been sent to the dev-eng list and 
>now is included in cvs and pre6. A firefox plugin would rock.
>  
>
I looked at http://mplayerplug-in.sourceforge.net/ and the screenshots 
show a running FireFox window.
Probably all I should do is to port the build to MinGW.

>>ps:
>>Why does it need dnahelper.sys? Probably it would not be better than
>>DirectX.
>>
>>    
>>
>
>It doesn't need it. dhahelper.sys is only usefull for vidix with shitty 
>hardware, but most of the time vo gl2 and directx are the best vos.
>Maybe vidix shouldn't even be included in the official builds.
>  
>
What does shitty hardware mean? Are they unsupported under windows or 
have buggy drivers?
(for example reported DirectX capabilities do not match hardware...)

NoiseEHC


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-cygwin/attachments/20041229/07a11e3e/attachment.htm>