diff options
author | Uoti Urpala <uau@mplayer2.org> | 2012-08-25 17:47:50 +0300 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2012-09-18 21:04:46 +0200 |
commit | 9bb03b7db40408b9dc4a0e1405a5bac754893e2b (patch) | |
tree | 87f36a068956b2783d48dac7f96dfa0bbd74d745 /playlist.h | |
parent | 44d8ec9272ad265aae02b064a0c5f4a80db5a107 (diff) | |
download | mpv-9bb03b7db40408b9dc4a0e1405a5bac754893e2b.tar.bz2 mpv-9bb03b7db40408b9dc4a0e1405a5bac754893e2b.tar.xz |
subs: libass: use a single persistent renderer for subtitles
To draw libass subtitles, the code used ASS_Renderer objects created
in vf_vo (VO rendering) or vf_ass. They were destroyed and recreated
together with the video filter chain. Change the code to use a single
persistent renderer instance stored in the main osd_state struct.
Because libass seems to misbehave if fonts are changed while a
renderer exists (even if ass_set_fonts() is called on the renderer
afterwards), the renderer is recreated after adding embedded fonts.
The known benefits are simpler code and avoiding delays when switching
between timeline parts from different files (libass fontconfig
initialization, needed when creating a new renderer, can take a long
time in some cases; switching between files rebuilds the video filter
chain, and this required recreating the renderers). On the other hand,
I'm not sure whether this could cause inefficient bitmap caching in
libass; explicitly resetting the renderer in some cases could be
beneficial. The new code does not keep the distinction of separate
renderers for vsfilter munged aspect vs normal; this means that
changing subtitle tracks can lose cache for the previous track.
The new code always sets some libass parameters on each rendering
call, which were previously only set if they had potentially changed.
This should be harmless as libass itself has checks to see if the
values differ from previous ones.
Conflicts:
command.c
libmpcodecs/vf_ass.c
libmpcodecs/vf_vo.c
mplayer.c
sub/ass_mp.c
Diffstat (limited to 'playlist.h')
0 files changed, 0 insertions, 0 deletions