[MPlayer-dev-eng] Libvo2 draft

[Ivan Kalvatchev]

--- Arpi <arpi at thot.banki.hu> wrote:
> Hi,
> 
> > I'm gonna put this text as attachment to force you
> to
> > copy only the parts you want to reply;)
> no problem, my mailer includes text atatchments as
> normal mail text :)
That's why i did gzip it :)
> btw, next time please find the key called ENTER and
> press it more times :)
> i don't like to read 173572 char long lines :(
Oh my god i have two!!! which one should i use HEELp!!
:)))
btw, it looks better with some kind of text editor.

> >   update_surface - as in the note above, this is
[snip]
> hmm. good idea for the case when surface is created
> by codec (internal
> buffers) not libvo2. but how do you want to make
> difference between drawings
> with update_surface and get_surface ?
> i think get_surface and flip_image (really
> display_surface) are mandatory,
> and update_surface or rendering directly to the
> surface si optional.
In fact my idea is given vid mode to have get_surface
OR update_surface, as it is driver dependent. 
If we can get_surface then we will use get_surface, if
there is only draw() function then we will use
update_surface(). Libvo2 core will call these function
and for codec view there will be only
draw()/draw_slice().


> 
> >   subpicture - this function will place subtitles.
> > It must be called once to place them and once to
> > remove them, it should not be called on every
frame,
> > the driver will take care of this. 
> >     Currently I propose this implementation: we
> > get array of bitmaps. Each one have its own
starting
> > x, y and it's own height and width, each one (or
all
> > together) could be in specific imgfmt (spfmt). THE
> > BITMAPS SHOULD NOT OVERLAP! This may not be hw
> > limitation but sw subtitles may get confused if
they
> > work as 'c' filter (look my libvo2 core).
> WHY SHOULDN'T OVERLAP ? It actually DOES overlap
> now!!!
> as it's drawn by characters, and characters has
> (optional) thin glow/shadow
> which will overlap with char at left/right. This way
> their
> glow/shadow will construct a nice outline.
> 
> i think we must allow overlapping bitmaps, or solve
> this problem at libvo2
> core - so rendering strings (array of chars) to
> single bitmaps.
I write this with the idea of few bitmaps(16), all
strings rendered in larger blocks.
The overlapping limitation could be safely removed,
as this is only for software render that copies the
image from one buffer to another(video surface). in
this case we will have:
 memcpy();subtitle(dst+ofs,src+ofs);memcpy();
//dst+=...
btw, i have no idea how different devices will act on
overlapping subtitles, but for the know ones i think
that it is safe.

> > I would like to hear the GUI developers. Could we
[snip] (i will read it at home with more carefully:)
> we need fullscreen switch control function too.
hmm, you don't mean GET/SET_RESOLUTION?
My idea is to have separate mode for yv12 window and
yv12 fullscreen. If we want to switch from window to
fullscreen then mplayer should call libvo2 core and it
will choose mode that have fullscreen. 
Why? Look at vo_sdl.c, it can switch window-
fullscreen by key press but it actually create new
surface.
Look at avifile it have 3 modes:
window,maximized,fullscreen.
so do you want maximize or fullscreen?
[snip] //later
> 
> > query_format -> not usable in this form, this
> function mean that all negotiation will be performed
> outside libvo2. Replace or find better name. 
> > close -> open/close :)
> it was added just for compatibility, and planned to
> be removed when we
> updated mlayer code to use libvo2.
> 
> > choose_buffering - all buffering must stay hidden.
> > The only exception is for hw_decode. In the new
> > implementation this functions is not usable.
> i think it's very important to implement in core.
> it will interface and implement the compatibility
> layer between codecs and
> libvo2 drivers. it should find the optimal buffering
> of driver (number and
> type of buffers) and codec (direct/indeirect
> rendering, access to internal
> buffer or copy by slices etc...) and set up optional
> software colorspace
> conversion and scaling, deinterlacing etc.
> 
> at least in my plans :)
I meen it too, lets change it to negotiate(), as it
sounds more critical:)

> > FILTER 1..x - processing:{ c-copy(buff1,buff2),
> p-process(buff1) }, 
> 
> i'm not sure. postprocessing depends on codecs a lot
> (uses some internal
> quant. data of codecs, and some codecs ahve it
> built-in, like win32 ones and
> divx4linux).
Is it problem to add adtitonal plane for quant data? I
meen really a plane with w,h,stride:) This will make
the things more standart and easy to maintain. 
If we get quant plane we'll make PP if we don't - we
won't:)
I included postprocessing as filter becouse we could
save us one copy :
decoder->B->postprocess->Surface_video. I know that
postprocessing works on bytes but mmx optimizations
read more data. 
Even more we could break postprocess on small filters:
vertical_deblock, horizontall_deblock, etc..

> >   If we want direct rendering we need normal
> > buffer, no filters, and (at least) 2 video
surfaces.
> > (we may allow 'p' filter like subtitles).
> it works with one buffer too (but ugly). more over,
> most codecs only works
> with static buffers, so direct rendering is only
> possible with single
> surface. divx4 and directshow works with multiple
> surfaces too. vfw doesn't.
> 
> direct rendering with 1 surface is always faster
> than 2 or more, so we
> should allow it for people with really slow sys.
> (kabi said that divx is
> playable on p166mmx with single buffer direct
> rendering...)
> 
=== message truncated ===
//my mailer did this ^
btw i will reply this, next time:)





__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com