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

[Evgeniy Stepanov]

On Sunday 04 June 2006 23:18, Reimar Döffinger wrote:
> 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.

Still, the filter's pts is the most accurate value one can get in mplayer, as 
far as I understand. Currently vf_ass is added to the end of the chain 
(nearest to the vo), so nothing should affect its interaction with vo.

> Also there is the problem that some vos can draw the OSD only 
> after they have all of the frame...

They can store the pointer somewhere and use it later, when they get the whole 
frame. vf_ass can guarantee that it will be valid until the beginning of the 
next frame.

Another idea: vo capable of "extended osd" could call rendering functions from 
libass itself when it is ready and blend the resulting bitmaps immediately. 
This could be wrapped in a nice call like get_extended_osd_bitmaps(double 
pts). vf_ass is only added if vo does not support this.

> 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).

This makes sense only if something between vf_ass and vo is messing with 
frames. I hope we can avoid this situation completely by adding vf_ass to the 
very end of the filter chain.