[MPlayer-dev-eng] MPlayer GUI suggestion!

[Arpi]

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.

> (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