[MPlayer-dev-eng] libvo2 under way

[David Holm]

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