[MPlayer-dev-eng] Re: [PATCH] SSA/ASS subtitles support

[Reimar Döffinger]

Hi,
On Sun, Jun 04, 2006 at 04:01:19PM +0400, Evgeniy Stepanov wrote:
> On Sunday 04 June 2006 14:02, Reimar Döffinger wrote:
> > Hmm. As I understood the code, you can just leave vf_ass out and it
> > should happen that way. Though I admit I didn't look closely at the
> > auto-loading code - in the future it would probably have to check if teh
> > vo already suuports the functionality and not load vf_ass then.
> 
> Exactly. I intend to add something like VFCAP_OSD and VFCTRL_DRAW_OSD.
> But we might still need to load vf_ass if we are going to use video pts from 
> the filter chain.

Well, another possibility (maybe the same as the other person replying
had in mind) would be create the structure to be drawn in vf_ass (as
before I guess, so sorry if I made you do some in the end pointless work
*g*), then call a VFCTRL_DRAW_EXTENDED_OSD, with a pointer to that struct
as argument, and if it fails draw it yourself. But that still leaves the
problem that the subtitle might not end up at the frame it should
appear. Also there is the problem that some vos can draw the OSD only
after they have all of the frame...
Another idea would be to just use such a VFCTRL to see if e.g. the vo
supports the "extended" OSD (could also be used to check if there is
a filter in between vf_ass and the vo that would break thinks, like the
mentioned vf_tile), and if yes pass the OSD to be drawn in the mp_image
structure (the vo would then also be responsible for freeing the data I
guess).
That's the best ideas I have so far, but there probably are even better
ones to be found *g*

> Btw, do I understand this right: the idea of VFCTRL_DRAW_OSD is to tell vf/vo 
> that OSD has changed, and it should be redrawn ? And this is useful for some 
> vo's that use overlays to put osd and therefore don't need to blend it into 
> each frame ?

VFCTRL_DRAW_OSD currently is called every frame, right after the frame
has been passed completely through the filter chain to the vo (which also means
that vf_expand has to use a different mechanism to draw the OSD - it
only "captures" any such message it gets to stop the vo from drawing the
OSD as well), regardless if the OSD changed or not, and causes the vf_vo
filter to call the draw_osd function of the vo.
If the OSD has changed can be queried by calling vo_osd_changed(0), but
this tends to be broken from time to time since only vo_gl seems to use
it.
In theory VFCTRL_DRAW_OSD could be used to update the OSD while the
frame is still the same, but in practice with will cause a corrupted
picture with anything except vo_gl.

Greetings,
Reimar Döffinger