[MPlayer-dev-eng] A proposal for the OSD

Alban Bedel albeu at free.fr
Fri Mar 14 08:03:00 CET 2003


Hi D Richard Felker III,

on Thu, 13 Mar 2003 11:55:41 -0500 you wrote:

> It sounds like OSD would still be slow, and in fact slower than the
> current method with vo_mga and other similar vo's.
Why ? only if the vo doesn't support any DR at all.
Let's take the classic IPB atm you can do DR only with x11 and xv afaik
but osd is display is buggy (That's normal). In this case if osd has to be
displayed, vf_vo shouldn't accept the dr from the codec, but get instead
a temp buffer from the vo. After decoding vf_vo copy the decoded image in
the TEMP buffer and give it for osd drawing. Finnaly this buffer is gaven
to the vo when the osd is drawn.
Ok if the vo doesn't support DR of TEMP buffer that will be slow. Also
note that the extra copy described above isn't a reqierment. You have to
do that in some case if you want to display a perfect osd but if you don't
care you can still draw the osd in a buffer where you shouldn't like it is
now.
Ok i talked perhaps too much of the worst case and not enougth of the best
one ;) But if such a thing is in place dr could be enabled by default
because vf_ve will have all it need to know if it can allow the dr or not.
> The nicest would be
> if we could have a function that copies the image and alpha-merges the
> OSD all in one step.
My idea doesn't need alpha merge at all. Osd will be drawn over the
rendered image. The main difference with the current system is to remove
this ugly callback stuff in the vo. Just look, about every vo use the
same code for osd drawing. The difference is only the buffer address in
the draw_alpha callback.
> Especially if we could support he G200's nonsense
> U/V packing in "YV12" mode...
Dunno what you are talking about but if the hardware support some stuff
that are useful for osd drawing then you can implement that in the vo.
Let's talk of a good case now ;)
For example take a card wich can do screen2screen blit with source
colorkey. A vo for such card could have a STATIC osd buffer wich is blited
over the frame at display time. A the osd buffer is STATIC the osd will be
drawn only when a change append to the osd (ie 1 fps for the timer).
If the card use stretch blit it could give the buffer where the scaled
picture is draw (after it have been drawn). In this case it would be a
TEMP buffer (from the osd pov) so the osd has to be draw for every frame
but it's unscaled.

Anyway imho the important thing atm is to move from this old callback
stuff to an mp_image_t based system where vo's have to implement
something for the osd only if they use some special hw feature. Otherwise
the vo doesn't even need to be aware that there is an osd.

	Albeu


More information about the MPlayer-dev-eng mailing list