mpv/sub/ass_mp.h

70 lines
2.1 KiB
C
Raw Normal View History

/*
* Copyright (C) 2006 Evgeniy Stepanov <eugeni.stepanov@gmail.com>
*
* This file is part of MPlayer.
*
* MPlayer is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* MPlayer is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with libass; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
#ifndef MPLAYER_ASS_MP_H
#define MPLAYER_ASS_MP_H
#include <stdint.h>
#include <stdbool.h>
#include "config.h"
#include "subreader.h"
#ifdef CONFIG_ASS
#include <ass/ass.h>
#include <ass/ass_types.h>
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 MPOpts;
struct mp_eosd_res;
ASS_Track *mp_ass_default_track(ASS_Library *library, struct MPOpts *opts);
ASS_Track *mp_ass_read_subdata(ASS_Library *library, struct MPOpts *opts,
sub_data *subdata, double fps);
ASS_Track *mp_ass_read_stream(ASS_Library *library, const char *fname,
char *charset);
struct MPOpts;
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
void mp_ass_configure(ASS_Renderer *priv, struct MPOpts *opts,
struct mp_eosd_res *dim);
void mp_ass_configure_fonts(ASS_Renderer *priv);
ASS_Library *mp_ass_init(struct MPOpts *opts);
struct sub_bitmap;
struct sub_bitmaps;
void mp_ass_render_frame(ASS_Renderer *renderer, ASS_Track *track, double time,
struct sub_bitmap **parts, struct sub_bitmaps *res);
#else /* CONFIG_ASS */
/* Needed for EOSD code using this type to compile */
typedef struct ass_image {
int w, h;
int stride;
unsigned char *bitmap;
uint32_t color;
int dst_x, dst_y;
struct ass_image *next;
} ASS_Image;
#endif
#endif /* MPLAYER_ASS_MP_H */