[MPlayer-dev-eng] MPlayer GUI suggestion!

David Holm dholm at telia.com
Fri Nov 2 17:15:22 CET 2001


Arpi wrote:

>Hi,
>
>we're working (at least should work but no time) on the new libvo2.
>we don't want to change or improve old libvo. the new libvo2 has
>powerfull control() interface for sepcial things like your ideas.
>it also supports direct rendering... but someone really should
>work on it. i've ported mga driver and got it work, but nothing more.
>it needs lots of things to do - implement buffer management code, including
>various scaling and colorspace conversion, add osd/sub code with ability to
>render under the image, and update subs only when changes... there were
>lots of ideas for libvo2 but nobody is interested enough and hes enough time
>to really do something :(
>
>i'm personally like demuxer/muxer coding much better than rtfm-ing X
>programming manuals and suck with the incompatible window managers...
>
Ok, how will the transform from libvo to libvo2 (always wondered what 
that was ;) be for us driver developers? And does libvo2 drivers work 
(enough) with the current mplayer, because then I really see no point in 
going on using the libvo interface but instead starting to transfer my 
code to libvo2.

>
>
>>Hi,
>>ok, first of all, who is working on the gui?
>>Second, the important part. I was spawning some ideas in my head this 
>>morning concerning the gui.
>>1. The current gui should be a general GUI available to themers and 
>>other graphics inspired users, and also geared towards full 
>>compatibility with all supported platforms.
>>query_video_driver_options(i), you get the drift. 2. My idea was that 
>>there should ALSO be a GUI api consisiting of prototypes like say 
>>query_video_drivers(int &i). Alternate gui's should be loaded using 
>>dlopen (meaning they are compiled as shared objects stored in say 
>>$PREFIX/share/mplayer/plugins etc, I've worked a lot with pluggable 
>>modules before and could give some tips and pointers. I might also get 
>>involved in the development of this AFTER I'm satisified with the dxr3 
>>a/v plugins I'm working on. (My idea was to load gui's using mplayer 
>>-gui <guiname> for plugins and -gui for the standard (as it is now)
>>This way there could be lots of cool plugins ( my idea was something 
>>resembling m$ latest bloatware mplayer7 with limited browsing functions 
>>of a page about online media etc using mozilla-dev ) and then someone 
>>set up a page located at the mplayer.hu server which this gui would be 
>>locked too (we don't want another mozilla based browser, just a cool 
>>online updating media guide). This will also require another feature 
>>which I personally see as pretty damn important. vo_* plugins SHOULD be 
>>able to return raw RGB24 so we don't have to popup another video-out 
>>window when using the gui (the current media player lookalike gui sucks 
>>since video isn't within the gui as it should be but in a separate window).
>>Hopefully someone will pick up on this and add this to the video_out 
>>api, then bear in mind (since I'm working on the dxr3 plugin ;), 
>>query_output should have at least two outputs, raw rgb OR make the vo_* 
>>driver draw the video at location x,y on screen using widht,height, the 
>>dxr3 uses and overlay cable to play video on the monitor so it won't hog 
>>the video board or cpu...
>>
>>//David Holm
>>
>>_______________________________________________
>>MPlayer-dev-eng mailing list
>>MPlayer-dev-eng at mplayerhq.hu
>>http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>>
>>
>
>
>A'rpi / Astral & ESP-team
>
>--
>mailto:arpi at thot.banki.hu
>http://esp-team.scene.hu
>_______________________________________________
>MPlayer-dev-eng mailing list
>MPlayer-dev-eng at mplayerhq.hu
>http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>






More information about the MPlayer-dev-eng mailing list