mpv/sub/dec_sub.h

94 lines
2.4 KiB
C
Raw 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>
struct sh_sub;
struct osd_state;
struct ass_track;
enum sub_bitmap_format {
SUBBITMAP_EMPTY = 0,// no bitmaps; always has num_parts==0
SUBBITMAP_LIBASS, // A8, with a per-surface blend color (libass.color)
SUBBITMAP_RGBA, // B8G8R8A8, can be scaled
SUBBITMAP_OLD, // I8A8 (monochrome), premultiplied alpha
SUBBITMAP_OLD_PLANAR, // like previous, but bitmap points to old_osd_planar
SUBBITMAP_COUNT
};
// For SUBBITMAP_OLD_PANAR
struct old_osd_planar {
unsigned char *bitmap;
unsigned char *alpha;
};
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
typedef struct mp_eosd_res {
int w, h; // screen dimensions, including black borders
int mt, mb, ml, mr; // borders (top, bottom, left, right)
} mp_eosd_res_t;
struct sub_bitmap {
void *bitmap;
int stride;
int w, h;
int x, y;
// Note: not clipped, going outside the screen area is allowed
int dw, dh;
union {
struct {
uint32_t color;
} libass;
};
};
typedef struct sub_bitmaps {
int render_index; // for VO cache state (limited by MAX_OSD_PARTS)
enum sub_bitmap_format format;
bool scaled; // if false, dw==w && dh==h
struct sub_bitmap *parts;
int num_parts;
// Provided for VOs with old code
struct ass_image *imgs;
// Incremented on each change
int bitmap_id, bitmap_pos_id;
} mp_eosd_images_t;
struct sub_render_params {
double pts;
struct mp_eosd_res dim;
double normal_scale;
double vsfilter_scale;
bool support_rgba;
};
static inline bool is_text_sub(int type)
{
return type == 't' || type == 'm' || type == 'a';
}
void sub_decode(struct sh_sub *sh, struct osd_state *osd, void *data,
int data_len, double pts, double duration);
void sub_get_bitmaps(struct osd_state *osd, struct sub_bitmaps *res);
void sub_init(struct sh_sub *sh, struct osd_state *osd);
void sub_reset(struct sh_sub *sh, struct osd_state *osd);
void sub_switchoff(struct sh_sub *sh, struct osd_state *osd);
void sub_uninit(struct sh_sub *sh);
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
struct sh_sub *sd_ass_create_from_track(struct ass_track *track,
bool vsfilter_aspect,
struct MPOpts *opts);
#ifdef CONFIG_ASS
struct ass_track *sub_get_ass_track(struct osd_state *osd);
#endif
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