[MPlayer-dev-eng] MPlayer GUI suggestion!

[David Holm]

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 
>>
>drivers in libvo2 is a way simpler than libvo. in libvo1 teh drivers should
>care of osd/sub rendering, finding the best resolution, blitting and scaling
>and converting image etc. in libvo2, the driver just provides requested
>number of buffers, and allow the codec or libvo2 core to draw into it.
>it should implemenbt the mandatory control() elements, like get ma xnumber
>of buffers, speed, accepted color spaces etc. i want to move as many common
>code to libvo2 core as possible. and make drivers much simpler and flexible.
>
I would like to point out that I think osd should be optionally handled 
by the libvo driver, because I'm going to use the DXR3/H+ Subpicture 
interface to draw onscreen data.

Also, I've asked before and ask again. Could someone enable mplayer to 
accept all supported formats, including those not video like mp3, ogg 
etc... It's MPlayer not VPlayer! And it's gonna kick xmms's ass (already 
does by my defenitions) ;)

>
>
>>(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.
>>
>no, unfortunatelly it's in early development stage. no osd/sub etc.
>to early to change yet. we should first stabilize libvo2 api, implement the
>common core, and then if all fo this seems to be ok, port the drivers from
>libvo.
>
>
>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
>