mpv/sub/osd.c

572 lines
19 KiB
C
Raw Normal View History

/*
* This file is part of mpv.
*
* mpv is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* mpv 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 Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with mpv. If not, see <http://www.gnu.org/licenses/>.
*/
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <libavutil/common.h>
#include "common/common.h"
#include "stream/stream.h"
#include "osdep/timer.h"
#include "mpv_talloc.h"
#include "options/m_config.h"
#include "options/options.h"
2013-12-21 18:06:37 +00:00
#include "common/global.h"
#include "common/msg.h"
#include "common/stats.h"
#include "player/client.h"
#include "player/command.h"
#include "osd.h"
#include "osd_state.h"
#include "dec_sub.h"
#include "img_convert.h"
#include "draw_bmp.h"
#include "video/mp_image.h"
#include "video/mp_image_pool.h"
#define OPT_BASE_STRUCT struct osd_style_opts
static const m_option_t style_opts[] = {
{"font", OPT_STRING(font)},
{"font-size", OPT_FLOAT(font_size), M_RANGE(1, 9000)},
{"color", OPT_COLOR(color)},
{"outline-color", OPT_COLOR(outline_color)},
{"back-color", OPT_COLOR(back_color)},
{"outline-size", OPT_FLOAT(outline_size)},
{"border-color", OPT_ALIAS("outline-color"), .alias_use_prefix = true},
{"shadow-color", OPT_ALIAS("back-color"), .alias_use_prefix = true},
{"border-style", OPT_CHOICE(border_style,
{"outline-and-shadow", 1}, {"opaque-box", 3}, {"background-box", 4})},
{"border-size", OPT_ALIAS("outline-size"), .alias_use_prefix = true},
{"shadow-offset", OPT_FLOAT(shadow_offset)},
{"spacing", OPT_FLOAT(spacing), M_RANGE(-10, 10)},
{"margin-x", OPT_INT(margin_x), M_RANGE(0, 300)},
{"margin-y", OPT_INT(margin_y), M_RANGE(0, 600)},
{"align-x", OPT_CHOICE(align_x,
{"left", -1}, {"center", 0}, {"right", +1})},
{"align-y", OPT_CHOICE(align_y,
{"top", -1}, {"center", 0}, {"bottom", +1})},
{"blur", OPT_FLOAT(blur), M_RANGE(0, 20)},
{"bold", OPT_BOOL(bold)},
{"italic", OPT_BOOL(italic)},
{"justify", OPT_CHOICE(justify,
{"auto", 0}, {"left", 1}, {"center", 2}, {"right", 3})},
{"font-provider", OPT_CHOICE(font_provider,
{"auto", 0}, {"none", 1}, {"fontconfig", 2}), .flags = UPDATE_SUB_HARD},
{"fonts-dir", OPT_STRING(fonts_dir),
.flags = M_OPT_FILE | UPDATE_SUB_HARD},
{0}
osd: make the OSD and sub font more customizable Make more aspects of the OSD font customizable. This also affects the font used for unstyled subtitles (such as SRT), or when using the --no-ass option. This adds back some customizability that was lost with commit 74e7a1 (osd: use libass for OSD rendering). Removed options: --ass-border-color --ass-color --font --subfont --subfont-text-scale Added options: --osd-color --osd-border --osd-back-color --osd-shadow-color --osd-font --osd-font-size --osd-border-size --osd-margin-x --osd-margin-y --osd-shadow-offset --osd-spacing --sub-scale The font size is now specified in pixels as it would be rendered on a window with a height of 720 pixels. OSD and subtitles are always scaled with the window height, so specifying or expecting an absolute font size doesn't make sense. Such scaled pixel units are used to specify font border etc. as well. (Note: the font size is directly passed to libass. How the fonts are actually rasterized is outside of our control, but in theory ASS font sizes map to "script" pixels and then are scaled to screen size.) The default settings should be about the same, with slight difference due to rounding to the new scales. The OSD and subtitle fonts are not separately configurable. It has limited use and would double the number of newly added options, which would be more confusing than helpful. It could be easily added later, should the need arise. Other small details that change: - ASS_Style.Encoding is not set to -1 for subs anymore (assuming subs use VSFilter direction in -no-ass mode too) - use a different WrapStyle for OSD - ASS forced styles are not applied to OSD
2012-11-17 19:56:45 +00:00
};
osd: make the OSD and sub font more customizable Make more aspects of the OSD font customizable. This also affects the font used for unstyled subtitles (such as SRT), or when using the --no-ass option. This adds back some customizability that was lost with commit 74e7a1 (osd: use libass for OSD rendering). Removed options: --ass-border-color --ass-color --font --subfont --subfont-text-scale Added options: --osd-color --osd-border --osd-back-color --osd-shadow-color --osd-font --osd-font-size --osd-border-size --osd-margin-x --osd-margin-y --osd-shadow-offset --osd-spacing --sub-scale The font size is now specified in pixels as it would be rendered on a window with a height of 720 pixels. OSD and subtitles are always scaled with the window height, so specifying or expecting an absolute font size doesn't make sense. Such scaled pixel units are used to specify font border etc. as well. (Note: the font size is directly passed to libass. How the fonts are actually rasterized is outside of our control, but in theory ASS font sizes map to "script" pixels and then are scaled to screen size.) The default settings should be about the same, with slight difference due to rounding to the new scales. The OSD and subtitle fonts are not separately configurable. It has limited use and would double the number of newly added options, which would be more confusing than helpful. It could be easily added later, should the need arise. Other small details that change: - ASS_Style.Encoding is not set to -1 for subs anymore (assuming subs use VSFilter direction in -no-ass mode too) - use a different WrapStyle for OSD - ASS forced styles are not applied to OSD
2012-11-17 19:56:45 +00:00
const struct m_sub_options osd_style_conf = {
.opts = style_opts,
.size = sizeof(struct osd_style_opts),
.defaults = &(const struct osd_style_opts){
.font = "sans-serif",
.font_size = 55,
.color = {255, 255, 255, 255},
.outline_color = {0, 0, 0, 255},
.back_color = {240, 240, 240, 128},
.border_style = 1,
.outline_size = 3,
.shadow_offset = 0,
.margin_x = 25,
.margin_y = 22,
.align_x = -1,
.align_y = -1,
osd: make the OSD and sub font more customizable Make more aspects of the OSD font customizable. This also affects the font used for unstyled subtitles (such as SRT), or when using the --no-ass option. This adds back some customizability that was lost with commit 74e7a1 (osd: use libass for OSD rendering). Removed options: --ass-border-color --ass-color --font --subfont --subfont-text-scale Added options: --osd-color --osd-border --osd-back-color --osd-shadow-color --osd-font --osd-font-size --osd-border-size --osd-margin-x --osd-margin-y --osd-shadow-offset --osd-spacing --sub-scale The font size is now specified in pixels as it would be rendered on a window with a height of 720 pixels. OSD and subtitles are always scaled with the window height, so specifying or expecting an absolute font size doesn't make sense. Such scaled pixel units are used to specify font border etc. as well. (Note: the font size is directly passed to libass. How the fonts are actually rasterized is outside of our control, but in theory ASS font sizes map to "script" pixels and then are scaled to screen size.) The default settings should be about the same, with slight difference due to rounding to the new scales. The OSD and subtitle fonts are not separately configurable. It has limited use and would double the number of newly added options, which would be more confusing than helpful. It could be easily added later, should the need arise. Other small details that change: - ASS_Style.Encoding is not set to -1 for subs anymore (assuming subs use VSFilter direction in -no-ass mode too) - use a different WrapStyle for OSD - ASS forced styles are not applied to OSD
2012-11-17 19:56:45 +00:00
},
.change_flags = UPDATE_OSD,
};
const struct m_sub_options sub_style_conf = {
.opts = style_opts,
osd: make the OSD and sub font more customizable Make more aspects of the OSD font customizable. This also affects the font used for unstyled subtitles (such as SRT), or when using the --no-ass option. This adds back some customizability that was lost with commit 74e7a1 (osd: use libass for OSD rendering). Removed options: --ass-border-color --ass-color --font --subfont --subfont-text-scale Added options: --osd-color --osd-border --osd-back-color --osd-shadow-color --osd-font --osd-font-size --osd-border-size --osd-margin-x --osd-margin-y --osd-shadow-offset --osd-spacing --sub-scale The font size is now specified in pixels as it would be rendered on a window with a height of 720 pixels. OSD and subtitles are always scaled with the window height, so specifying or expecting an absolute font size doesn't make sense. Such scaled pixel units are used to specify font border etc. as well. (Note: the font size is directly passed to libass. How the fonts are actually rasterized is outside of our control, but in theory ASS font sizes map to "script" pixels and then are scaled to screen size.) The default settings should be about the same, with slight difference due to rounding to the new scales. The OSD and subtitle fonts are not separately configurable. It has limited use and would double the number of newly added options, which would be more confusing than helpful. It could be easily added later, should the need arise. Other small details that change: - ASS_Style.Encoding is not set to -1 for subs anymore (assuming subs use VSFilter direction in -no-ass mode too) - use a different WrapStyle for OSD - ASS forced styles are not applied to OSD
2012-11-17 19:56:45 +00:00
.size = sizeof(struct osd_style_opts),
.defaults = &(const struct osd_style_opts){
.font = "sans-serif",
.font_size = 55,
.color = {255, 255, 255, 255},
.outline_color = {0, 0, 0, 255},
.back_color = {240, 240, 240, 128},
.border_style = 1,
.outline_size = 3,
.shadow_offset = 0,
.margin_x = 25,
.margin_y = 22,
.align_x = 0,
.align_y = 1,
},
.change_flags = UPDATE_OSD,
osd: make the OSD and sub font more customizable Make more aspects of the OSD font customizable. This also affects the font used for unstyled subtitles (such as SRT), or when using the --no-ass option. This adds back some customizability that was lost with commit 74e7a1 (osd: use libass for OSD rendering). Removed options: --ass-border-color --ass-color --font --subfont --subfont-text-scale Added options: --osd-color --osd-border --osd-back-color --osd-shadow-color --osd-font --osd-font-size --osd-border-size --osd-margin-x --osd-margin-y --osd-shadow-offset --osd-spacing --sub-scale The font size is now specified in pixels as it would be rendered on a window with a height of 720 pixels. OSD and subtitles are always scaled with the window height, so specifying or expecting an absolute font size doesn't make sense. Such scaled pixel units are used to specify font border etc. as well. (Note: the font size is directly passed to libass. How the fonts are actually rasterized is outside of our control, but in theory ASS font sizes map to "script" pixels and then are scaled to screen size.) The default settings should be about the same, with slight difference due to rounding to the new scales. The OSD and subtitle fonts are not separately configurable. It has limited use and would double the number of newly added options, which would be more confusing than helpful. It could be easily added later, should the need arise. Other small details that change: - ASS_Style.Encoding is not set to -1 for subs anymore (assuming subs use VSFilter direction in -no-ass mode too) - use a different WrapStyle for OSD - ASS forced styles are not applied to OSD
2012-11-17 19:56:45 +00:00
};
bool osd_res_equals(struct mp_osd_res a, struct mp_osd_res b)
{
return a.w == b.w && a.h == b.h && a.ml == b.ml && a.mt == b.mt
&& a.mr == b.mr && a.mb == b.mb
&& a.display_par == b.display_par;
}
2013-12-21 18:06:37 +00:00
struct osd_state *osd_create(struct mpv_global *global)
{
static_assert(MAX_OSD_PARTS >= OSDTYPE_COUNT, "");
2008-06-24 05:29:36 +00:00
struct osd_state *osd = talloc_zero(NULL, struct osd_state);
*osd = (struct osd_state) {
.opts_cache = m_config_cache_alloc(osd, global, &mp_osd_render_sub_opts),
2013-12-21 18:06:37 +00:00
.global = global,
.log = mp_log_new(osd, global->log, "osd"),
.force_video_pts = MP_NOPTS_VALUE,
.stats = stats_ctx_create(osd, global, "osd"),
};
2023-10-21 02:55:41 +00:00
mp_mutex_init(&osd->lock);
osd->opts = osd->opts_cache->opts;
for (int n = 0; n < MAX_OSD_PARTS; n++) {
struct osd_object *obj = talloc(osd, struct osd_object);
*obj = (struct osd_object) {
.type = n,
.text = talloc_strdup(obj, ""),
.progbar_state = {.type = -1},
.vo_change_id = 1,
};
osd->objs[n] = obj;
}
osd->objs[OSDTYPE_SUB]->is_sub = true;
osd->objs[OSDTYPE_SUB2]->is_sub = true;
osd: use libass for OSD rendering The OSD will now be rendered with libass. The old rendering code, which used freetype/fontconfig and did text layout manually, is disabled. To re-enable the old code, use the --disable-libass-osd configure switch. Some switches do nothing with the new code enabled, such as -subalign, -sub-bg-alpha, -sub-bg-color, and many more. (The reason is mostly that the code for rendering unstyled subtitles with libass doesn't make any attempts to support them. Some of them could be supported in theory.) Teletext rendering is not implemented in the new OSD rendering code. I don't have any teletext sources for testing, and since teletext is being phased out world-wide, the need for this is questionable. Note that rendering is extremely inefficient, mostly because the libass output is blended with the extremely strange mplayer OSD format. This could be improved at a later point. Remove most OSD rendering from vo_aa.c, because that was extremely hacky, can't be made work with osd_libass, and didn't work anyway in my tests. Internally, some cleanup is done. Subtitle and OSD related variable declarations were literally all over the place. Move them to sub.h and sub.c, which were hoarding most of these declarations already. Make the player core in mplayer.c free of concerns like bitmap font loading. The old OSD rendering code has been moved to osd_ft.c. The font_load.c and font_load_ft.c are only needed and compiled if the old OSD rendering code is configured.
2012-03-22 05:26:37 +00:00
osd_init_backend(osd);
return osd;
}
void osd_free(struct osd_state *osd)
{
if (!osd)
return;
osd_destroy_backend(osd);
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
talloc_free(osd->objs[OSDTYPE_EXTERNAL2]->external2);
2023-10-21 02:55:41 +00:00
mp_mutex_destroy(&osd->lock);
talloc_free(osd);
}
void osd_set_text(struct osd_state *osd, const char *text)
{
2023-10-21 02:55:41 +00:00
mp_mutex_lock(&osd->lock);
struct osd_object *osd_obj = osd->objs[OSDTYPE_OSD];
if (!text)
text = "";
if (strcmp(osd_obj->text, text) != 0) {
talloc_free(osd_obj->text);
osd_obj->text = talloc_strdup(osd_obj, text);
osd_obj->osd_changed = true;
osd->want_redraw_notification = true;
}
2023-10-21 02:55:41 +00:00
mp_mutex_unlock(&osd->lock);
}
void osd_set_sub(struct osd_state *osd, int index, struct dec_sub *dec_sub)
{
2023-10-21 02:55:41 +00:00
mp_mutex_lock(&osd->lock);
if (index >= 0 && index < 2) {
struct osd_object *obj = osd->objs[OSDTYPE_SUB + index];
obj->sub = dec_sub;
obj->vo_change_id += 1;
}
osd->want_redraw_notification = true;
2023-10-21 02:55:41 +00:00
mp_mutex_unlock(&osd->lock);
}
bool osd_get_render_subs_in_filter(struct osd_state *osd)
{
2023-10-21 02:55:41 +00:00
mp_mutex_lock(&osd->lock);
bool r = osd->render_subs_in_filter;
2023-10-21 02:55:41 +00:00
mp_mutex_unlock(&osd->lock);
return r;
}
void osd_set_render_subs_in_filter(struct osd_state *osd, bool s)
{
2023-10-21 02:55:41 +00:00
mp_mutex_lock(&osd->lock);
if (osd->render_subs_in_filter != s) {
osd->render_subs_in_filter = s;
int change_id = 0;
for (int n = 0; n < MAX_OSD_PARTS; n++)
change_id = MPMAX(change_id, osd->objs[n]->vo_change_id);
for (int n = 0; n < MAX_OSD_PARTS; n++)
osd->objs[n]->vo_change_id = change_id + 1;
}
2023-10-21 02:55:41 +00:00
mp_mutex_unlock(&osd->lock);
}
void osd_set_force_video_pts(struct osd_state *osd, double video_pts)
{
atomic_store(&osd->force_video_pts, video_pts);
}
double osd_get_force_video_pts(struct osd_state *osd)
{
return atomic_load(&osd->force_video_pts);
}
void osd_set_progbar(struct osd_state *osd, struct osd_progbar_state *s)
{
2023-10-21 02:55:41 +00:00
mp_mutex_lock(&osd->lock);
struct osd_object *osd_obj = osd->objs[OSDTYPE_OSD];
osd_obj->progbar_state.type = s->type;
osd_obj->progbar_state.value = s->value;
osd_obj->progbar_state.num_stops = s->num_stops;
MP_TARRAY_GROW(osd_obj, osd_obj->progbar_state.stops, s->num_stops);
if (s->num_stops) {
memcpy(osd_obj->progbar_state.stops, s->stops,
sizeof(osd_obj->progbar_state.stops[0]) * s->num_stops);
}
osd_obj->osd_changed = true;
osd->want_redraw_notification = true;
2023-10-21 02:55:41 +00:00
mp_mutex_unlock(&osd->lock);
}
void osd_set_external2(struct osd_state *osd, struct sub_bitmaps *imgs)
{
2023-10-21 02:55:41 +00:00
mp_mutex_lock(&osd->lock);
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
struct osd_object *obj = osd->objs[OSDTYPE_EXTERNAL2];
talloc_free(obj->external2);
obj->external2 = sub_bitmaps_copy(NULL, imgs);
obj->vo_change_id += 1;
osd->want_redraw_notification = true;
2023-10-21 02:55:41 +00:00
mp_mutex_unlock(&osd->lock);
}
static void check_obj_resize(struct osd_state *osd, struct mp_osd_res res,
struct osd_object *obj)
{
if (!osd_res_equals(res, obj->vo_res)) {
obj->vo_res = res;
obj->osd_changed = true;
mp_client_broadcast_event_external(osd->global->client_api,
MP_EVENT_WIN_RESIZE, NULL);
}
}
// Optional. Can be called for faster reaction of OSD-generating scripts like
// osc.lua. This can achieve that the resize happens first, so that the OSD is
// generated at the correct resolution the first time the resized frame is
// rendered. Since the OSD doesn't (and can't) wait for the script, this
// increases the time in which the script can react, and also gets rid of the
// unavoidable redraw delay (though it will still be racy).
// Unnecessary for anything else.
void osd_resize(struct osd_state *osd, struct mp_osd_res res)
{
2023-10-21 02:55:41 +00:00
mp_mutex_lock(&osd->lock);
int types[] = {OSDTYPE_OSD, OSDTYPE_EXTERNAL, OSDTYPE_EXTERNAL2, -1};
for (int n = 0; types[n] >= 0; n++)
check_obj_resize(osd, res, osd->objs[types[n]]);
2023-10-21 02:55:41 +00:00
mp_mutex_unlock(&osd->lock);
}
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
static struct sub_bitmaps *render_object(struct osd_state *osd,
struct osd_object *obj,
struct mp_osd_res osdres, double video_pts,
const bool sub_formats[SUBBITMAP_COUNT])
{
int format = SUBBITMAP_LIBASS;
if (!sub_formats[format] || osd->opts->force_rgba_osd)
format = SUBBITMAP_BGRA;
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
struct sub_bitmaps *res = NULL;
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
check_obj_resize(osd, osdres, obj);
if (obj->type == OSDTYPE_SUB) {
if (obj->sub && sub_is_primary_visible(obj->sub))
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
res = sub_get_bitmaps(obj->sub, obj->vo_res, format, video_pts);
} else if (obj->type == OSDTYPE_SUB2) {
if (obj->sub && sub_is_secondary_visible(obj->sub))
res = sub_get_bitmaps(obj->sub, obj->vo_res, format, video_pts);
} else if (obj->type == OSDTYPE_EXTERNAL2) {
if (obj->external2 && obj->external2->format) {
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
res = sub_bitmaps_copy(NULL, obj->external2); // need to be owner
obj->external2->change_id = 0;
}
} else {
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
res = osd_object_get_bitmaps(osd, obj, format);
}
if (obj->vo_had_output != !!res) {
obj->vo_had_output = !!res;
obj->vo_change_id += 1;
}
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
if (res) {
obj->vo_change_id += res->change_id;
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
res->render_index = obj->type;
res->change_id = obj->vo_change_id;
}
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
return res;
}
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
// Render OSD to a list of bitmap and return it. The returned object is
// refcounted. Typically you should hold it only for a short time, and then
// release it.
// draw_flags is a bit field of OSD_DRAW_* constants
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
struct sub_bitmap_list *osd_render(struct osd_state *osd, struct mp_osd_res res,
double video_pts, int draw_flags,
const bool formats[SUBBITMAP_COUNT])
{
2023-10-21 02:55:41 +00:00
mp_mutex_lock(&osd->lock);
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
struct sub_bitmap_list *list = talloc_zero(NULL, struct sub_bitmap_list);
list->change_id = 1;
list->w = res.w;
list->h = res.h;
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
double force_video_pts = atomic_load(&osd->force_video_pts);
if (force_video_pts != MP_NOPTS_VALUE)
video_pts = force_video_pts;
if (draw_flags & OSD_DRAW_SUB_FILTER)
draw_flags |= OSD_DRAW_SUB_ONLY;
for (int n = 0; n < MAX_OSD_PARTS; n++) {
struct osd_object *obj = osd->objs[n];
// Object is drawn into the video frame itself; don't draw twice
if (osd->render_subs_in_filter && obj->is_sub &&
!(draw_flags & OSD_DRAW_SUB_FILTER))
continue;
if ((draw_flags & OSD_DRAW_SUB_ONLY) && !obj->is_sub)
continue;
if ((draw_flags & OSD_DRAW_OSD_ONLY) && obj->is_sub)
continue;
char *stat_type_render = obj->is_sub ? "sub-render" : "osd-render";
stats_time_start(osd->stats, stat_type_render);
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
struct sub_bitmaps *imgs =
render_object(osd, obj, res, video_pts, formats);
stats_time_end(osd->stats, stat_type_render);
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
if (imgs && imgs->num_parts > 0) {
if (formats[imgs->format]) {
talloc_steal(list, imgs);
MP_TARRAY_APPEND(list, list->items, list->num_items, imgs);
imgs = NULL;
} else {
2013-12-21 18:06:37 +00:00
MP_ERR(osd, "Can't render OSD part %d (format %d).\n",
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
obj->type, imgs->format);
}
}
list->change_id += obj->vo_change_id;
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
talloc_free(imgs);
}
// If this is called with OSD_DRAW_SUB_ONLY or OSD_DRAW_OSD_ONLY set, assume
// it will always draw the complete OSD by doing multiple osd_draw() calls.
// OSD_DRAW_SUB_FILTER on the other hand is an evil special-case, and we
// must not reset the flag when it happens.
if (!(draw_flags & OSD_DRAW_SUB_FILTER))
osd->want_redraw_notification = false;
2023-10-21 02:55:41 +00:00
mp_mutex_unlock(&osd->lock);
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
return list;
}
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
// Warning: this function should be considered legacy. Use osd_render() instead.
void osd_draw(struct osd_state *osd, struct mp_osd_res res,
double video_pts, int draw_flags,
const bool formats[SUBBITMAP_COUNT],
void (*cb)(void *ctx, struct sub_bitmaps *imgs), void *cb_ctx)
{
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
struct sub_bitmap_list *list =
osd_render(osd, res, video_pts, draw_flags, formats);
stats_time_start(osd->stats, "draw");
for (int n = 0; n < list->num_items; n++)
cb(cb_ctx, list->items[n]);
stats_time_end(osd->stats, "draw");
talloc_free(list);
}
// Calls mp_image_make_writeable() on the dest image if something is drawn.
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
// draw_flags as in osd_render().
void osd_draw_on_image(struct osd_state *osd, struct mp_osd_res res,
double video_pts, int draw_flags, struct mp_image *dest)
{
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
osd_draw_on_image_p(osd, res, video_pts, draw_flags, NULL, dest);
}
// Like osd_draw_on_image(), but if dest needs to be copied to make it
// writeable, allocate images from the given pool. (This is a minor
// optimization to reduce "real" image sized memory allocations.)
void osd_draw_on_image_p(struct osd_state *osd, struct mp_osd_res res,
double video_pts, int draw_flags,
struct mp_image_pool *pool, struct mp_image *dest)
{
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
struct sub_bitmap_list *list =
osd_render(osd, res, video_pts, draw_flags, mp_draw_sub_formats);
if (!list->num_items) {
talloc_free(list);
return;
}
if (!mp_image_pool_make_writeable(pool, dest))
return; // on OOM, skip
// Need to lock for the dumb osd->draw_cache thing.
2023-10-21 02:55:41 +00:00
mp_mutex_lock(&osd->lock);
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
if (!osd->draw_cache)
osd->draw_cache = mp_draw_sub_alloc(osd, osd->global);
stats_time_start(osd->stats, "draw-bmp");
if (!mp_draw_sub_bitmaps(osd->draw_cache, dest, list))
draw_bmp: rewrite draw_bmp.c is the software blender for subtitles and OSD. It's used by encoding mode (burning subtitles), and some VOs, like vo_drm, vo_x11, vo_xv, and possibly more. This changes the algorithm from upsampling the video to 4:4:4 and then blending to downsampling the OSD and then blending directly to video. This has far-reaching consequences for its internals, and results in an effective rewrite. Since I wanted to avoid un-premultiplying, all blending is done with premultiplied alpha. That's actually the sane thing to do. The old code just didn't do it, because it's very weird in YUV fixed point. Essentially, you'd have to compensate for the chroma centering constant by subtracting src_alpha/255*128. This seemed so hairy (especially with correct rounding and high bit depths involved) that I went for using float. I think it turned out mostly OK, although it's more complex and less maintainable than before. reinit() is certainly a bit too long. While it should be possible to optimize the RGB path more (for example by blending directly instead of doing the stupid float conversion), this is probably slower. vo_xv users probably lose in this, because it takes the slowest path (due to subsampling requirements and using YUV). Why this rewrite? Nobody knows. I simply forgot the reason. But you'll have it anyway. Whether or not this would have required a full rewrite, at least it supports target alpha now (you can for example hard sub transparent PNGs, if you ever wanted to use mpv for this). Remove the check in vf_sub. The new draw_bmp.c is not as reliant on libswscale anymore (mostly uses repack.c now), and osd.c shows an error message on missing support instead now. Formats with chroma subsampling of 4 are not supported, because FFmpeg doesn't provide pixfmt definitions for alpha variants. We could provide those ourselves (relatively trivial), but why bother.
2020-05-09 16:01:07 +00:00
MP_WARN(osd, "Failed rendering OSD.\n");
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
talloc_steal(osd, osd->draw_cache);
stats_time_end(osd->stats, "draw-bmp");
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
2023-10-21 02:55:41 +00:00
mp_mutex_unlock(&osd->lock);
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
talloc_free(list);
}
// Setup the OSD resolution to render into an image with the given parameters.
// The interesting part about this is that OSD has to compensate the aspect
// ratio if the image does not have a 1:1 pixel aspect ratio.
struct mp_osd_res osd_res_from_image_params(const struct mp_image_params *p)
{
return (struct mp_osd_res) {
.w = p->w,
.h = p->h,
.display_par = p->p_h / (double)p->p_w,
};
}
// Typically called to react to OSD style changes.
void osd_changed(struct osd_state *osd)
{
2023-10-21 02:55:41 +00:00
mp_mutex_lock(&osd->lock);
osd->objs[OSDTYPE_OSD]->osd_changed = true;
osd->want_redraw_notification = true;
// Done here for a lack of a better place.
m_config_cache_update(osd->opts_cache);
2023-10-21 02:55:41 +00:00
mp_mutex_unlock(&osd->lock);
osd: use libass for OSD rendering The OSD will now be rendered with libass. The old rendering code, which used freetype/fontconfig and did text layout manually, is disabled. To re-enable the old code, use the --disable-libass-osd configure switch. Some switches do nothing with the new code enabled, such as -subalign, -sub-bg-alpha, -sub-bg-color, and many more. (The reason is mostly that the code for rendering unstyled subtitles with libass doesn't make any attempts to support them. Some of them could be supported in theory.) Teletext rendering is not implemented in the new OSD rendering code. I don't have any teletext sources for testing, and since teletext is being phased out world-wide, the need for this is questionable. Note that rendering is extremely inefficient, mostly because the libass output is blended with the extremely strange mplayer OSD format. This could be improved at a later point. Remove most OSD rendering from vo_aa.c, because that was extremely hacky, can't be made work with osd_libass, and didn't work anyway in my tests. Internally, some cleanup is done. Subtitle and OSD related variable declarations were literally all over the place. Move them to sub.h and sub.c, which were hoarding most of these declarations already. Make the player core in mplayer.c free of concerns like bitmap font loading. The old OSD rendering code has been moved to osd_ft.c. The font_load.c and font_load_ft.c are only needed and compiled if the old OSD rendering code is configured.
2012-03-22 05:26:37 +00:00
}
bool osd_query_and_reset_want_redraw(struct osd_state *osd)
{
2023-10-21 02:55:41 +00:00
mp_mutex_lock(&osd->lock);
bool r = osd->want_redraw_notification;
osd->want_redraw_notification = false;
2023-10-21 02:55:41 +00:00
mp_mutex_unlock(&osd->lock);
return r;
}
struct mp_osd_res osd_get_vo_res(struct osd_state *osd)
{
2023-10-21 02:55:41 +00:00
mp_mutex_lock(&osd->lock);
// Any OSDTYPE is fine; but it mustn't be a subtitle one (can have lower res.)
struct mp_osd_res res = osd->objs[OSDTYPE_OSD]->vo_res;
2023-10-21 02:55:41 +00:00
mp_mutex_unlock(&osd->lock);
return res;
2013-12-12 23:19:17 +00:00
}
// Position the subbitmaps in imgs on the screen. Basically, this fits the
// subtitle canvas (of size frame_w x frame_h) onto the screen, such that it
// fills the whole video area (especially if the video is magnified, e.g. on
// fullscreen). If compensate_par is >0, adjust the way the subtitles are
// "stretched" on the screen, and letter-box the result. If compensate_par
// is <0, strictly letter-box the subtitles. If it is 0, stretch them.
void osd_rescale_bitmaps(struct sub_bitmaps *imgs, int frame_w, int frame_h,
struct mp_osd_res res, double compensate_par)
{
int vidw = res.w - res.ml - res.mr;
int vidh = res.h - res.mt - res.mb;
double xscale = (double)vidw / frame_w;
double yscale = (double)vidh / frame_h;
if (compensate_par < 0) {
assert(res.display_par);
compensate_par = xscale / yscale / res.display_par;
}
if (compensate_par > 0)
xscale /= compensate_par;
int cx = vidw / 2 - (int)(frame_w * xscale) / 2;
int cy = vidh / 2 - (int)(frame_h * yscale) / 2;
for (int i = 0; i < imgs->num_parts; i++) {
struct sub_bitmap *bi = &imgs->parts[i];
struct mp_rect rc = {
.x0 = lrint(bi->x * xscale),
.y0 = lrint(bi->y * yscale),
.x1 = lrint((bi->x + bi->w) * xscale),
.y1 = lrint((bi->y + bi->h) * yscale),
};
bi->x = rc.x0 + cx + res.ml;
bi->y = rc.y0 + cy + res.mt;
bi->dw = mp_rect_w(rc);
bi->dh = mp_rect_h(rc);
}
}
video: make OSD/subtitle bitmaps refcounted (sort of) Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
2020-04-26 21:34:32 +00:00
// Copy *in and return a new allocation of it. Free with talloc_free(). This
// will contain a refcounted copy of the image data.
//
// in->packed must be set and must be a refcounted image, unless there is no
// data (num_parts==0).
//
// p_cache: if not NULL, then this points to a struct sub_bitmap_copy_cache*
// variable. The function may set this to an allocation and may later
// read it. You have to free it with talloc_free() when done.
// in: valid struct, or NULL (in this case it also returns NULL)
// returns: new copy, or NULL if there was no data in the input
struct sub_bitmaps *sub_bitmaps_copy(struct sub_bitmap_copy_cache **p_cache,
struct sub_bitmaps *in)
{
if (!in || !in->num_parts)
return NULL;
struct sub_bitmaps *res = talloc(NULL, struct sub_bitmaps);
*res = *in;
// Note: the p_cache thing is a lie and unused.
// The bitmaps being refcounted is essential for performance, and for
// not invalidating in->parts[*].bitmap pointers.
assert(in->packed && in->packed->bufs[0]);
res->packed = mp_image_new_ref(res->packed);
talloc_steal(res, res->packed);
res->parts = NULL;
MP_RESIZE_ARRAY(res, res->parts, res->num_parts);
memcpy(res->parts, in->parts, sizeof(res->parts[0]) * res->num_parts);
return res;
}