2012-08-25 16:47:50 +02:00
|
|
|
#ifndef MPLAYER_DEC_SUB_H
|
|
|
|
|
#define MPLAYER_DEC_SUB_H
|
|
|
|
|
|
2012-09-28 21:19:36 +02:00
|
|
|
#include <stdbool.h>
|
|
|
|
|
#include <stdint.h>
|
|
|
|
|
|
2021-05-27 07:56:41 +02:00
|
|
|
#include "player/core.h"
|
2013-11-24 12:58:06 +01:00
|
|
|
#include "osd.h"
|
2012-10-04 17:16:40 +02:00
|
|
|
|
2013-11-23 21:37:15 +01:00
|
|
|
struct sh_stream;
|
2013-12-21 19:06:37 +01:00
|
|
|
struct mpv_global;
|
2013-06-01 19:44:12 +02:00
|
|
|
struct demux_packet;
|
2017-02-07 17:05:17 +01:00
|
|
|
struct mp_recorder_sink;
|
2013-06-01 19:44:12 +02:00
|
|
|
struct dec_sub;
|
|
|
|
|
struct sd;
|
|
|
|
|
|
2013-06-29 01:34:11 +02:00
|
|
|
enum sd_ctrl {
|
|
|
|
|
SD_CTRL_SUB_STEP,
|
2013-07-15 01:48:25 +02:00
|
|
|
SD_CTRL_SET_VIDEO_PARAMS,
|
2015-11-17 01:54:02 +01:00
|
|
|
SD_CTRL_SET_TOP,
|
2015-12-27 01:25:32 +01:00
|
|
|
SD_CTRL_SET_VIDEO_DEF_FPS,
|
sub: make filter_sdh a "proper" filter, allow runtime changes
Until now, filter_sdh was simply a function that was called by sd_ass
directly (if enabled).
I want to add another filter, so it's time to turn this into a somewhat
more general subtitle filtering infrastructure.
I pondered whether to reuse the audio/video filtering stuff - but better
not. Also, since subtitles are horrible and tend to refuse proper
abstraction, it's still messed into sd_ass, instead of working on the
dec_sub.c level. Actually mpv used to have subtitle "filters" and even
made subtitle converters part of it, but it was fairly horrible, so
don't do that again.
In addition, make runtime changes possible. Since this was supposed to
be a quick hack, I just decided to put all subtitle filter options into
a separate option group (=> simpler change notification), to manually
push the change through the playloop (like it was sort of before for OSD
options), and to recreate the sub filter chain completely in every
change. Should be good enough.
One strangeness is that due to prefetching and such, most subtitle
packets (or those some time ahead) are actually done filtering when we
change, so the user still needs to manually seek to actually refresh
everything. And since subtitle data is usually cached in ASS_Track (for
other terrible but user-friendly reasons), we also must clear the
subtitle data, but of course only on seek, since otherwise all subtitles
would just disappear. What a fucking mess, but such is life. We could
trigger a "refresh seek" to make this more automatic, but I don't feel
like it currently.
This is slightly inefficient (lots of allocations and copying), but I
decided that it doesn't matter. Could matter slightly for crazy ASS
subtitles that render with thousands of events.
Not very well tested. Still seems to work, but I didn't have many test
cases.
2020-02-16 01:02:17 +01:00
|
|
|
SD_CTRL_UPDATE_OPTS,
|
2013-06-29 01:34:11 +02:00
|
|
|
};
|
|
|
|
|
|
2020-05-14 22:14:49 +02:00
|
|
|
enum sd_text_type {
|
|
|
|
|
SD_TEXT_TYPE_PLAIN,
|
|
|
|
|
SD_TEXT_TYPE_ASS,
|
|
|
|
|
};
|
|
|
|
|
|
2019-09-21 20:11:18 +02:00
|
|
|
struct sd_times {
|
|
|
|
|
double start;
|
|
|
|
|
double end;
|
|
|
|
|
};
|
|
|
|
|
|
2016-03-03 18:48:56 +01:00
|
|
|
struct attachment_list {
|
|
|
|
|
struct demux_attachment *entries;
|
|
|
|
|
int num_entries;
|
|
|
|
|
};
|
|
|
|
|
|
2021-05-27 07:56:41 +02:00
|
|
|
struct dec_sub *sub_create(struct mpv_global *global, struct track *track,
|
sub: align ytdl-hook secondary subs to the top
29e15e6248 prefixed youtube-dl's subs url with an edl prefix to not
download them until they're selected, which is useful when there are
many sub languages. But this prefix broke the alignment of secondary
subs, which would overlap the primary subs instead of always being
placed at the top. This can be tested with
--sub-file='edl://!no_clip;!delay_open,media_type=sub;secondary_sub.srt'
When a sub is added, sub.c:reinit_sub() is called. This calls in
init_subdec() -> dec_sub.c:sub_create() -> init_decoder() ->
sd_ass:init(). Then reinit_sub() calls
sub_control(track->d_sub, SD_CTRL_SET_TOP, &(bool){!!order}) which sets
sd_ass_priv.on_top = true for secondary subs.
But for EDL subs the real sub is initialized again when in
dec_sub.c:sub_read_packets() is_new_segment() returns true and
update_segment() is called, or when sub_get_bitmaps() calls
update_segment(). update_segment() then calls init_decoder(), which
calls sd_ass:init(), so sd_ass_priv is reinitialized, and its on_top
property is left false. This commit sets it to true again.
For URLs that need to be downloaded it seems that the update_segment()
call that reinitializes sd_ass_priv is always the one in
sub_read_packets(), but with local subs sub_get_bitmaps() is usually
called earlier (though there shouldn't be a reason to use the EDL URL
for local subs), so I added the order parameter to sub_create(), rather
than adding it to all of update_segment(), sub_read_packets() and
sub_get_bitmaps().
Also removes the cast to bool in the other sub_control call, since
sub/sd_ass.c:control already casts arg to bool when cmd is
SD_CTRL_SET_TOP.
2021-08-10 22:11:53 +02:00
|
|
|
struct attachment_list *attachments, int order);
|
2013-06-01 19:44:12 +02:00
|
|
|
void sub_destroy(struct dec_sub *sub);
|
|
|
|
|
|
sub: make preloading more robust
Subtitles can be preloaded, which means they're fully read and copied
into ASS_Track. This in turn is mainly for the sake of being able to do
subtitle seeking (when it comes down to it, subtitle seeking is the
cause for most trouble here).
Commit a714f8e92 broke preloaded subtitles which have events with
unknown duration, such as some MicroDVD samples. The event list gets
cleared on every seek, so the property of being preloaded obviously gets
lost.
Fix this by moving most of the preloading logic to dec_sub.c. If the
subtitle list gets cleared, they are not considered preloaded anymore,
and the logic for demuxed subtitles is used.
As another minor thing, preloadeding subtitles did neither disable the
demux stream, nor did it discard packets. Thus you could get queue
overflows in theory (harmless, but annoying). Fix this by explicitly
discarding packets in preloaded mode.
In summary, now the only difference between preloaded and normal
demuxing are:
1. a seek is issued, and all packets are read on start
2. during playback, discard the packets instead of feeding them to the
subtitle decoder
This is still petty annoying. It would be nice if maintaining the
subtitle index (and maybe a subtitle packet cache for instant subtitle
presentation when seeking back) could be maintained in the demuxer
instead. Half of all file formats with interleaved subtitles have
this anyway (mp4, mkv muxed with newer mkvmerge).
2016-03-06 14:50:36 +01:00
|
|
|
bool sub_can_preload(struct dec_sub *sub);
|
|
|
|
|
void sub_preload(struct dec_sub *sub);
|
2023-09-30 15:58:56 +02:00
|
|
|
bool sub_read_packets(struct dec_sub *sub, double video_pts, bool force);
|
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 23:34:32 +02:00
|
|
|
struct sub_bitmaps *sub_get_bitmaps(struct dec_sub *sub, struct mp_osd_res dim,
|
|
|
|
|
int format, double pts);
|
2020-05-14 22:14:49 +02:00
|
|
|
char *sub_get_text(struct dec_sub *sub, double pts, enum sd_text_type type);
|
2023-08-26 15:17:01 +02:00
|
|
|
char *sub_ass_get_extradata(struct dec_sub *sub);
|
2019-09-21 20:11:18 +02:00
|
|
|
struct sd_times sub_get_times(struct dec_sub *sub, double pts);
|
2013-06-01 19:44:12 +02:00
|
|
|
void sub_reset(struct dec_sub *sub);
|
2015-12-26 18:35:36 +01:00
|
|
|
void sub_select(struct dec_sub *sub, bool selected);
|
2017-02-07 17:05:17 +01:00
|
|
|
void sub_set_recorder_sink(struct dec_sub *sub, struct mp_recorder_sink *sink);
|
Implement backwards playback
See manpage additions. This is a huge hack. You can bet there are shit
tons of bugs. It's literally forcing square pegs into round holes.
Hopefully, the manpage wall of text makes it clear enough that the whole
shit can easily crash and burn. (Although it shouldn't literally crash.
That would be a bug. It possibly _could_ start a fire by entering some
sort of endless loop, not a literal one, just something where it tries
to do work without making progress.)
(Some obvious bugs I simply ignored for this initial version, but
there's a number of potential bugs I can't even imagine. Normal playback
should remain completely unaffected, though.)
How this works is also described in the manpage. Basically, we demux in
reverse, then we decode in reverse, then we render in reverse.
The decoding part is the simplest: just reorder the decoder output. This
weirdly integrates with the timeline/ordered chapter code, which also
has special requirements on feeding the packets to the decoder in a
non-straightforward way (it doesn't conflict, although a bugmessmass
breaks correct slicing of segments, so EDL/ordered chapter playback is
broken in backward direction).
Backward demuxing is pretty involved. In theory, it could be much
easier: simply iterating the usual demuxer output backward. But this
just doesn't fit into our code, so there's a cthulhu nightmare of shit.
To be specific, each stream (audio, video) is reversed separately. At
least this means we can do backward playback within cached content (for
example, you could play backwards in a live stream; on that note, it
disables prefetching, which would lead to losing new live video, but
this could be avoided).
The fuckmess also meant that I didn't bother trying to support
subtitles. Subtitles are a problem because they're "sparse" streams.
They need to be "passively" demuxed: you don't try to read a subtitle
packet, you demux audio and video, and then look whether there was a
subtitle packet. This means to get subtitles for a time range, you need
to know that you demuxed video and audio over this range, which becomes
pretty messy when you demux audio and video backwards separately.
Backward display is the most weird (and potentially buggy) part. To
avoid that we need to touch a LOT of timing code, we negate all
timestamps. The basic idea is that due to the navigation, all
comparisons and subtractions of timestamps keep working, and you don't
need to touch every single of them to "reverse" them.
E.g.:
bool before = pts_a < pts_b;
would need to be:
bool before = forward
? pts_a < pts_b
: pts_a > pts_b;
or:
bool before = pts_a * dir < pts_b * dir;
or if you, as it's implemented now, just do this after decoding:
pts_a *= dir;
pts_b *= dir;
and then in the normal timing/renderer code:
bool before = pts_a < pts_b;
Consequently, we don't need many changes in the latter code. But some
assumptions inhererently true for forward playback may have been broken
anyway. What is mainly needed is fixing places where values are passed
between positive and negative "domains". For example, seeking and
timestamp user display always uses positive timestamps. The main mess is
that it's not obvious which domain a given variable should or does use.
Well, in my tests with a single file, it suddenly started to work when I
did this. I'm honestly surprised that it did, and that I didn't have to
change a single line in the timing code past decoder (just something
minor to make external/cached text subtitles display). I committed it
immediately while avoiding thinking about it. But there really likely
are subtle problems of all sorts.
As far as I'm aware, gstreamer also supports backward playback. When I
looked at this years ago, I couldn't find a way to actually try this,
and I didn't revisit it now. Back then I also read talk slides from the
person who implemented it, and I'm not sure if and which ideas I might
have taken from it. It's possible that the timestamp reversal is
inspired by it, but I didn't check. (I think it claimed that it could
avoid large changes by changing a sign?)
VapourSynth has some sort of reverse function, which provides a backward
view on a video. The function itself is trivial to implement, as
VapourSynth aims to provide random access to video by frame numbers (so
you just request decreasing frame numbers). From what I remember, it
wasn't exactly fluid, but it worked. It's implemented by creating an
index, and seeking to the target on demand, and a bunch of caching. mpv
could use it, but it would either require using VapourSynth as demuxer
and decoder for everything, or replacing the current file every time
something is supposed to be played backwards.
FFmpeg's libavfilter has reversal filters for audio and video. These
require buffering the entire media data of the file, and don't really
fit into mpv's architecture. It could be used by playing a libavfilter
graph that also demuxes, but that's like VapourSynth but worse.
2019-05-18 02:10:51 +02:00
|
|
|
void sub_set_play_dir(struct dec_sub *sub, int dir);
|
2022-01-19 18:23:52 +01:00
|
|
|
bool sub_is_primary_visible(struct dec_sub *sub);
|
2021-01-13 16:59:08 +01:00
|
|
|
bool sub_is_secondary_visible(struct dec_sub *sub);
|
2013-06-01 19:44:12 +02:00
|
|
|
|
2013-06-29 01:34:11 +02:00
|
|
|
int sub_control(struct dec_sub *sub, enum sd_ctrl cmd, void *arg);
|
2012-09-01 19:49:04 +02:00
|
|
|
|
2012-08-25 16:47:50 +02:00
|
|
|
#endif
|