[MPlayer-dev-eng] Libvo2 draft

[Ivan Kalvatchev]

--- David Holm <dholm at telia.com> wrote:
> Ok, I've read through the documentation and here are
> my thoughts...
[snip]
> >They are simple enough. So I introduce to be
> implemented and these functions:
> >  query
> >  update_surface - renamed draw
> >  hw_decode
> >  subpicture
[snip] 

> >  update_surface - as in the note above, this is
[snip]
> >
> well, as it is now slices are implemented in a way
> such that it is 
> always a complete frame because it keeps the data
> from the previous call 
> and changes only the data within the slice.
> Are there hardware devices that support this?? if
> so, we just fetch it 
> using query (or control, whitchever gets chosen)
> 
> >
> >
> >  hw_decode - to make all dvb,dxr3, tv etc.
[snip]
> This sounds unneeded, check my example vo2_dxr3
> implementation, I 
> believe the current functions are sufficient,
> surface returns a memory 
> area to draw into and flip calls whatever functions
> are required by 
> hardware, I really see no need for this function at
> all.
> Future features are to be controlled by control(..),
> that's one of it's 
> purposes...
 You didn't get the idea. The main idea for this
driver is to remove all buffering, the driver won't
allocate any memory, get_surface will return only
video memory, and update_surface will draw it. In this
way both function should work only with image data and
not with mpeg packets, so that's why i make and
hw_decode. We could achieve direct drawing and when we
have internal buffer in ram if we call blit function
directly with it. lets show you: 
decoder->InternalBuffer-bitBlit->VideoSurface
"r I d" in libvo2 core analys

> >
> >  subpicture - this function will place subtitles.
[snip]
> I think this is also unnecessary, it's better this
> is handled by the 
> libvo2 core depending on the VO2CTRL_OVERLAY
> control. We want to get 
> away from device developers having to do stuff
> themselves the core might 
> as well do. If really needed I prefer implementing
> something like 
> VO2CTRL_OVERLAY_CALLBACK and passing it a callback
> function as parameter.
No no, this will work with X, but it will be useless
with vo2_gl, as it (will) draw(s) it as texture.
Libvo2 core will draw subtitles ONLY if there is NO hw
support.

> >1.2 control()
[snip]
> >  GET/SET_ATTRIBUTES - Xv overlays have contrast,
> >brightness, hue, saturation etc. these and others
> >could be controlled by this. If we want to query it
> >we must call GET_*, and the to check does our
> >attribute is in there (xv developers be careful, 2
> >or 3 of default attributes sometimes are not
queried
> >by X, but could be set).
> >
> Then why not expand this to GET/SET_BRIGHTNESS, HUE,
> SATURATION?? easier 
> to handle. The dxr3 also has these abilities...
I thouth on it before proposing it in this form. Here
are the resons:
1. Not all atributes are available on all devices,
there must be some kind of query and for them. This
will prevent us from double apply e.g. BRIGHTNES - 1st
in DivX4Linux and 2'd in the overlay:)
2. There are more atributes that these, like keycolor
- have you seen bsplayer ability to display move as
desktop. You can watch movie and to see some icons and
windows at the same time. To do this you will need to
make some tricks with keycolor.
Anyway it realy will be easyer to have them expanded,
but GET/SET_ATTRIBUTES should exists at all cost.
[snip]
> I'm working on a vo2_context struct which will set
the appropriate 
> function for the current device (i.e.
pixel_converter, filters etc) 
> I'll 
> extend it with the things in your list that are
missing...
Pleace post them to me. 
btw, your mail was too big for my mail, it was
truncated when i tried to reply.
  Best Regards
Ivan Kalvachev





__________________________________________________
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1