mpv/sub/dec_sub.h

48 lines
1.3 KiB
C
Raw Permalink Normal View History

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
2012-08-25 14:47:50 +00:00
#ifndef MPLAYER_DEC_SUB_H
#define MPLAYER_DEC_SUB_H
#include <stdbool.h>
#include <stdint.h>
#include "sub/sub.h"
struct sh_sub;
struct ass_track;
struct MPOpts;
struct demux_packet;
struct ass_library;
struct ass_renderer;
struct dec_sub;
struct sd;
enum sd_ctrl {
SD_CTRL_SUB_STEP,
SD_CTRL_SET_VIDEO_PARAMS,
};
struct dec_sub *sub_create(struct MPOpts *opts);
void sub_destroy(struct dec_sub *sub);
void sub_set_video_res(struct dec_sub *sub, int w, int h);
void sub_set_video_fps(struct dec_sub *sub, double fps);
void sub_set_extradata(struct dec_sub *sub, void *data, int data_len);
void sub_set_ass_renderer(struct dec_sub *sub, struct ass_library *ass_library,
struct ass_renderer *ass_renderer);
void sub_init_from_sh(struct dec_sub *sub, struct sh_sub *sh);
bool sub_is_initialized(struct dec_sub *sub);
bool sub_read_all_packets(struct dec_sub *sub, struct sh_sub *sh);
bool sub_accept_packets_in_advance(struct dec_sub *sub);
void sub_decode(struct dec_sub *sub, struct demux_packet *packet);
void sub_get_bitmaps(struct dec_sub *sub, struct mp_osd_res dim, double pts,
struct sub_bitmaps *res);
bool sub_has_get_text(struct dec_sub *sub);
char *sub_get_text(struct dec_sub *sub, double pts);
void sub_reset(struct dec_sub *sub);
int sub_control(struct dec_sub *sub, enum sd_ctrl cmd, void *arg);
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
2012-08-25 14:47:50 +00:00
#endif