[MPlayer-dev-eng] libvo2 under way

[Arpi]

Hi,

first: please don't cross-posts more!

about libvo2.
1. please read my 'long' mail about it, which i've sent it about a week ago.
  i don't want to see the base ideas disappearing.
2. wait with that plugin gui stuff. we should get working libvo2 first, gui
dosn't matter now.

> Hi,
> I just got permission from Arpi to take charge of libvo2 development. As 
> some of you know libvo2 focuses more on the hardware used than just 
> being a mere mplayer<->hardware implementation. I'm thinking of features 
> as query_format() in libvo where you had to have support for n different 
> formats for the device to be usable. In libvo2 we are going to approach 
> this problem in a whole different way, we are going to tell mplayer 
> which format(s) out device supports.
> Say for instance you are writing a device for a hardware mpeg decoder 
> (such as I am for the dxr3/h+), in libvo you will have to implement alot 
> of different converters to get the output you requier. In libvo2 we tell 
> mplayer that (in the case of the dxr3) we want mpegpes packets for video 
> playback, making it up to mplayer to convert the stream to the 
> appropriate format. This produces a number of extremely useful features 
> say encoder X encodes an mpeg1 stream 12% faster than encoder Y using 
> input format K, then mplayer could automatically choose X for the job.
> Another feature of libvo2 will be overlays/raw output, this is mostly a 
> movement towards a pluggable gui where the developer designs the gui and 
> it's functionality, not just the theme. Why raw output you might ask 
> when mplayer already converts K to X? Well, alot of cards have a number 
> of acceleration options, again referring to the DXR3 (it's an MPEG-1, 
> MPEG-2 AC3 hardware decoder card for those of you not familiar with it) 
> uses an overlay cable to produce output on your monitor, meaning that it 
> will put 0% load on the video board, also when playing mpeg-(1/2) you 
> will have a VERY low cpu-usage. Other cards might support hardware 
> scaling, pixel conversion and so on, the list goes on.
> 
> What I need from both you the developers and you the users are any 
> thoughts, ideas, (scanned) napkins with scribbles on them. As 
> development moves along I will post info on changes, features etc. I 
> will also make cvs commits whenever reaching a point where I think a 
> reasonable amount of new features have been implemented (I will do my 
> best to document the api along the road, there will also be a "Moving 
> from libvo to libvo2" book available from O'Reilly Publ.... just 
> kidding, but I'll try to put together an easy to use libvo->libvo2 guide 
> for you.
> If I get no feedback either by ideas, or by reading my code I will 
> assume you cannot come up with a more genious way of solving that 
> particular problem. Remember, it's up to you to help me and the other 
> developers make this a better product, and move to a pluggable gui-api 
> which I personally am looking forward to.
> 
> Well, it's getting late here in sweden, and I have had my first look at 
> the current libvo2 status, and read through the cvs-howto. But now I 
> really have to go to bed, but expect development moving at a high pace, 
> but libvo2 will not be finalized (standardized) until "significant" 
> people have had a look at it and found it flawless, so it's not like you 
> have until the upcoming weekend to come with ideas etc.
> 
> Sleep tight
> //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