[MPlayer-dev-eng] [RFC] EOSD improvements

[Nicolas George]

Le quintidi 15 thermidor, an CCXVIII, Reimar Döffinger a écrit :
> > IMHO, if all agree that OSD and EOSD should be merged, the only issue to
> > discuss is now: what is the best way to do it?

Since you start to answer the question "how to do it", I assume that you
agree on the premise "we want to do it".

> I'm not sure it's going to work well, OSD is supported by a lot of
> hard-to-test VOs and stuff like that.

I looked into the various VO, and found this:

The following VOs do not support OSD at all, either ignoring it utterly or
issuing a fatal error:

3dfx    ggi     jpeg        mpegpes  pnm       v4l2      xvidix
bl      gif89a  matrixview  null     tdfx_vid  winvidix  zr
cvidix  ivtv    md5sum      png      tga       xover     zr2
mga     xmga

The following VOs seem tu use a set of generic functions to draw the OSD
bitmaps in a memory buffer, just like vf_expand does:

dga        fbdev   kva     svga    wii  xvr100
directfb2  fbdev2  quartz  tdfxfb  x11  yuv4mpeg
directx    gl2     s3fb    vesa    xv

The following VOs actually do something special for OSD:

aa:       renders text in ASCII
caca:     draws the progress bar, ignores the rest
vdpau:    draws in a texture
direct3d: draws in a texture
gl:       draws in a texture
sdl:      draws in SDL overlays
dxr2:     delegates to a secondary VO
xvmc:     not sure what, but overlays something
dfbmga:   not sure what, but overlays something
dxr3:     not sure what, but overlays something

Apart from aa (and caca), who actually uses the text instead of the alpha
mask, all the VOs do some sort of alpha blending of the OSD bitmap. They all
have a function called draw_alpha or similar. This function could probably
serve as base for EOSD rendering in these VOs.

> My idea would be to figure out a way to push the vob/DVB/... subtitles
> the way the are now through the EOSD pipeline instead of OSD,
> the results of such an attempt should give us at least some idea what
> probably works and what does not.

That was pretty much my idea.

> It might (though I have some doubts) make sense to e.g. implement a
> filter that provides an OSD "renderer" like -vf expand does, but instead
> of rendering it it converts it into EOSD subs.

I did not think of a video filter for that task, but the idea is worth
remembering, especially in that it gives an easy way to turn the feature on
and off.

> Though there might still be a problem due to the OSD having multiple
> parts and then there's the EOSD and I think they're all supposed to be
> merged together to one single EOSD command.
> It might be not too hard due to the way the OSD works, but honestly I
> don't have it all in my head so I would really know.

With the way EOSD works at this time, it is just impossible: there is no
EOSD command carrying the overlay data: when VFCTRL_DRAW_EOSD is triggered,
it calls ass_mp_render_frame to get the overlay data to render.

Note that OSD is even worse: it calls vo_draw_text with a callback function
that do the alpha blending.

Both are, IMHO, horrible spaghetti code with data flowing in both
directions.

Here is my suggestion:

Patch #1: make EOSD data flow in a single direction, disentangling EOSD from
          libass, and factoring some redundant code in the process.

Patch #2: implement some trivial (yet useful) feature to test that it
          actually works. For example a "add_overlay_bitmap" slave command.

Patch #3: implement the aforementioned video filter that turns OSD elements
          to EOSD.

Later possible patches:

          - Turn the draw_alpha of various VOs to native EOSD.

          - Add support of other bitmap format to EOSD.

What do you think about it?

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100802/aab7f78d/attachment.pgp>