2011-01-16 18:03:08 +00:00
|
|
|
/*
|
2015-04-13 07:36:54 +00:00
|
|
|
* This file is part of mpv.
|
2011-01-16 18:03:08 +00:00
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is free software; you can redistribute it and/or modify
|
2011-01-16 18:03:08 +00:00
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
2015-04-13 07:36:54 +00:00
|
|
|
* mpv is distributed in the hope that it will be useful,
|
2011-01-16 18:03:08 +00:00
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
2015-04-13 07:36:54 +00:00
|
|
|
* with mpv. If not, see <http://www.gnu.org/licenses/>.
|
2011-01-16 18:03:08 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
#include <stdbool.h>
|
sub: add subtitle charset conversion
This code was once part of subreader.c, then traveled to libass, and now
made its way back to the fork of the fork of the original code, MPlayer.
It works pretty much the same as subreader.c, except that we have to
concatenate some packets to do auto-detection. This is rather annoying,
but for all we know the actual source file could be a binary format.
Unlike subreader.c, the iconv context is reopened on each packet. This
is simpler, and with respect to multibyte encodings, more robust.
Reopening is probably not a very fast, but I suspect subtitle charset
conversion is not an operation that happens often or has to be fast.
Also, this auto-detection is disabled for microdvd - this is the only
format we know that has binary data in its packets, but is actually
decoded to text. FFmpeg doesn't really allow us to solve this properly,
because a) the input packets can be binary, and b) the output will be
checked whether it's UTF-8, and if it's not, the output is thrown away
and an error message is printed. We could just recode the decoded
subtitles before sd_ass if it weren't for that.
2013-06-23 20:15:04 +00:00
|
|
|
#include <string.h>
|
2013-07-07 21:54:11 +00:00
|
|
|
#include <math.h>
|
2011-01-16 18:03:08 +00:00
|
|
|
#include <assert.h>
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
#include <pthread.h>
|
2011-01-16 18:03:08 +00:00
|
|
|
|
|
|
|
#include "config.h"
|
2013-06-11 19:39:54 +00:00
|
|
|
#include "demux/demux.h"
|
2013-06-01 17:54:18 +00:00
|
|
|
#include "sd.h"
|
|
|
|
#include "dec_sub.h"
|
2013-12-17 01:02:25 +00:00
|
|
|
#include "options/options.h"
|
2013-12-21 18:06:37 +00:00
|
|
|
#include "common/global.h"
|
2013-12-17 01:39:45 +00:00
|
|
|
#include "common/msg.h"
|
|
|
|
#include "misc/charset_conv.h"
|
2014-01-31 18:50:25 +00:00
|
|
|
#include "osdep/threads.h"
|
2011-01-16 18:03:08 +00:00
|
|
|
|
|
|
|
extern const struct sd_functions sd_ass;
|
2012-08-16 15:21:21 +00:00
|
|
|
extern const struct sd_functions sd_lavc;
|
2013-06-01 17:44:55 +00:00
|
|
|
extern const struct sd_functions sd_movtext;
|
2013-06-01 17:54:18 +00:00
|
|
|
extern const struct sd_functions sd_srt;
|
|
|
|
extern const struct sd_functions sd_microdvd;
|
2013-06-24 00:06:55 +00:00
|
|
|
extern const struct sd_functions sd_lavf_srt;
|
2013-06-01 17:54:31 +00:00
|
|
|
extern const struct sd_functions sd_lavc_conv;
|
sub: add sd_spu.c to wrap spudec, cleanup mplayer.c
This unifies the subtitle rendering path. Now all subtitle rendering
goes through sd_ass.c/sd_lavc.c/sd_spu.c.
Before that commit, the spudec.h functions were used directly in
mplayer.c, which introduced many special cases. Add sd_spu.c, which is
just a small wrapper connecting the new subtitle render API with the
dusty old vobsub decoder in spudec.c.
One detail that changes is that we always pass the palette as extra
data, instead of passing the libdvdread palette as pointer to spudec
directly. This is a bit roundabout, but actually makes the code simpler
and more elegant: the difference between DVD and non-DVD dvdsubs is
reduced.
Ideally, we would just delete spudec.c and use libavcodec's DVD sub
decoder. However, DVD playback with demux_mpg produces packets
incompatible to lavc. There are incompatibilities the other way around
as well: packets from libavformat's vobsub demuxer are incompatible to
spudec.c. So we define a new subtitle codec name for demux_mpg subs,
"dvd_subtitle_mpg", which only sd_spu can decode.
There is actually code in spudec.c to "assemble" fragments into complete
packets, but using the whole spudec.c is easier than trying to move this
code into demux_mpg to fix subtitle packets.
As additional complication, Libav 9.x can't decode DVD subs correctly,
so use sd_spu in that case as well.
2013-04-28 23:13:22 +00:00
|
|
|
|
2014-06-10 21:56:05 +00:00
|
|
|
static const struct sd_functions *const sd_list[] = {
|
2013-07-16 11:28:28 +00:00
|
|
|
#if HAVE_LIBASS
|
sub: add sd_spu.c to wrap spudec, cleanup mplayer.c
This unifies the subtitle rendering path. Now all subtitle rendering
goes through sd_ass.c/sd_lavc.c/sd_spu.c.
Before that commit, the spudec.h functions were used directly in
mplayer.c, which introduced many special cases. Add sd_spu.c, which is
just a small wrapper connecting the new subtitle render API with the
dusty old vobsub decoder in spudec.c.
One detail that changes is that we always pass the palette as extra
data, instead of passing the libdvdread palette as pointer to spudec
directly. This is a bit roundabout, but actually makes the code simpler
and more elegant: the difference between DVD and non-DVD dvdsubs is
reduced.
Ideally, we would just delete spudec.c and use libavcodec's DVD sub
decoder. However, DVD playback with demux_mpg produces packets
incompatible to lavc. There are incompatibilities the other way around
as well: packets from libavformat's vobsub demuxer are incompatible to
spudec.c. So we define a new subtitle codec name for demux_mpg subs,
"dvd_subtitle_mpg", which only sd_spu can decode.
There is actually code in spudec.c to "assemble" fragments into complete
packets, but using the whole spudec.c is easier than trying to move this
code into demux_mpg to fix subtitle packets.
As additional complication, Libav 9.x can't decode DVD subs correctly,
so use sd_spu in that case as well.
2013-04-28 23:13:22 +00:00
|
|
|
&sd_ass,
|
|
|
|
#endif
|
|
|
|
&sd_lavc,
|
2013-06-01 17:44:55 +00:00
|
|
|
&sd_movtext,
|
2013-06-01 17:54:18 +00:00
|
|
|
&sd_srt,
|
2013-06-24 00:06:55 +00:00
|
|
|
&sd_lavf_srt,
|
2014-06-15 19:10:38 +00:00
|
|
|
&sd_microdvd,
|
2015-04-08 20:18:20 +00:00
|
|
|
&sd_lavc_conv,
|
sub: add sd_spu.c to wrap spudec, cleanup mplayer.c
This unifies the subtitle rendering path. Now all subtitle rendering
goes through sd_ass.c/sd_lavc.c/sd_spu.c.
Before that commit, the spudec.h functions were used directly in
mplayer.c, which introduced many special cases. Add sd_spu.c, which is
just a small wrapper connecting the new subtitle render API with the
dusty old vobsub decoder in spudec.c.
One detail that changes is that we always pass the palette as extra
data, instead of passing the libdvdread palette as pointer to spudec
directly. This is a bit roundabout, but actually makes the code simpler
and more elegant: the difference between DVD and non-DVD dvdsubs is
reduced.
Ideally, we would just delete spudec.c and use libavcodec's DVD sub
decoder. However, DVD playback with demux_mpg produces packets
incompatible to lavc. There are incompatibilities the other way around
as well: packets from libavformat's vobsub demuxer are incompatible to
spudec.c. So we define a new subtitle codec name for demux_mpg subs,
"dvd_subtitle_mpg", which only sd_spu can decode.
There is actually code in spudec.c to "assemble" fragments into complete
packets, but using the whole spudec.c is easier than trying to move this
code into demux_mpg to fix subtitle packets.
As additional complication, Libav 9.x can't decode DVD subs correctly,
so use sd_spu in that case as well.
2013-04-28 23:13:22 +00:00
|
|
|
NULL
|
|
|
|
};
|
2011-01-16 18:03:08 +00:00
|
|
|
|
2013-06-01 17:54:18 +00:00
|
|
|
#define MAX_NUM_SD 3
|
2013-06-01 17:44:55 +00:00
|
|
|
|
2013-06-01 17:44:12 +00:00
|
|
|
struct dec_sub {
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_t lock;
|
|
|
|
|
2013-12-21 18:06:37 +00:00
|
|
|
struct mp_log *log;
|
2013-06-01 17:44:12 +00:00
|
|
|
struct MPOpts *opts;
|
|
|
|
struct sd init_sd;
|
|
|
|
|
sub: add subtitle charset conversion
This code was once part of subreader.c, then traveled to libass, and now
made its way back to the fork of the fork of the original code, MPlayer.
It works pretty much the same as subreader.c, except that we have to
concatenate some packets to do auto-detection. This is rather annoying,
but for all we know the actual source file could be a binary format.
Unlike subreader.c, the iconv context is reopened on each packet. This
is simpler, and with respect to multibyte encodings, more robust.
Reopening is probably not a very fast, but I suspect subtitle charset
conversion is not an operation that happens often or has to be fast.
Also, this auto-detection is disabled for microdvd - this is the only
format we know that has binary data in its packets, but is actually
decoded to text. FFmpeg doesn't really allow us to solve this properly,
because a) the input packets can be binary, and b) the output will be
checked whether it's UTF-8, and if it's not, the output is thrown away
and an error message is printed. We could just recode the decoded
subtitles before sd_ass if it weren't for that.
2013-06-23 20:15:04 +00:00
|
|
|
const char *charset;
|
2013-06-11 19:39:54 +00:00
|
|
|
|
2013-06-01 17:44:55 +00:00
|
|
|
struct sd *sd[MAX_NUM_SD];
|
|
|
|
int num_sd;
|
2013-06-01 17:44:12 +00:00
|
|
|
};
|
|
|
|
|
2013-06-11 19:39:54 +00:00
|
|
|
struct packet_list {
|
|
|
|
struct demux_packet **packets;
|
|
|
|
int num_packets;
|
|
|
|
};
|
|
|
|
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
|
|
|
|
void sub_lock(struct dec_sub *sub)
|
|
|
|
{
|
|
|
|
pthread_mutex_lock(&sub->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
void sub_unlock(struct dec_sub *sub)
|
|
|
|
{
|
|
|
|
pthread_mutex_unlock(&sub->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Thread-safety of the returned object: all functions are thread-safe,
|
|
|
|
// except sub_get_bitmaps() and sub_get_text(). Decoder backends (sd_*)
|
|
|
|
// do not need to acquire locks.
|
2013-12-21 18:06:37 +00:00
|
|
|
struct dec_sub *sub_create(struct mpv_global *global)
|
2013-06-01 17:44:12 +00:00
|
|
|
{
|
|
|
|
struct dec_sub *sub = talloc_zero(NULL, struct dec_sub);
|
2013-12-21 18:06:37 +00:00
|
|
|
sub->log = mp_log_new(sub, global->log, "sub");
|
|
|
|
sub->opts = global->opts;
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
|
2014-01-31 18:50:25 +00:00
|
|
|
mpthread_mutex_init_recursive(&sub->lock);
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
|
2013-06-01 17:44:12 +00:00
|
|
|
return sub;
|
|
|
|
}
|
|
|
|
|
2013-06-01 17:44:55 +00:00
|
|
|
static void sub_uninit(struct dec_sub *sub)
|
|
|
|
{
|
|
|
|
sub_reset(sub);
|
|
|
|
for (int n = 0; n < sub->num_sd; n++) {
|
|
|
|
if (sub->sd[n]->driver->uninit)
|
|
|
|
sub->sd[n]->driver->uninit(sub->sd[n]);
|
|
|
|
talloc_free(sub->sd[n]);
|
|
|
|
}
|
|
|
|
sub->num_sd = 0;
|
|
|
|
}
|
|
|
|
|
2013-06-01 17:44:12 +00:00
|
|
|
void sub_destroy(struct dec_sub *sub)
|
|
|
|
{
|
|
|
|
if (!sub)
|
|
|
|
return;
|
2013-06-01 17:44:55 +00:00
|
|
|
sub_uninit(sub);
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_destroy(&sub->lock);
|
2013-06-01 17:44:12 +00:00
|
|
|
talloc_free(sub);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool sub_is_initialized(struct dec_sub *sub)
|
|
|
|
{
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_lock(&sub->lock);
|
|
|
|
bool r = !!sub->num_sd;
|
|
|
|
pthread_mutex_unlock(&sub->lock);
|
|
|
|
return r;
|
2013-06-01 17:44:12 +00:00
|
|
|
}
|
|
|
|
|
2013-06-28 23:34:11 +00:00
|
|
|
static struct sd *sub_get_last_sd(struct dec_sub *sub)
|
2013-06-01 17:44:12 +00:00
|
|
|
{
|
2013-06-01 17:44:55 +00:00
|
|
|
return sub->num_sd ? sub->sd[sub->num_sd - 1] : NULL;
|
2013-06-01 17:44:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void sub_set_video_res(struct dec_sub *sub, int w, int h)
|
|
|
|
{
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_lock(&sub->lock);
|
2013-06-01 17:44:12 +00:00
|
|
|
sub->init_sd.sub_video_w = w;
|
|
|
|
sub->init_sd.sub_video_h = h;
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
2013-06-01 17:44:12 +00:00
|
|
|
}
|
|
|
|
|
2013-06-11 19:39:54 +00:00
|
|
|
void sub_set_video_fps(struct dec_sub *sub, double fps)
|
|
|
|
{
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_lock(&sub->lock);
|
2015-12-05 22:56:28 +00:00
|
|
|
sub->init_sd.video_fps = fps;
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
2013-06-11 19:39:54 +00:00
|
|
|
}
|
|
|
|
|
2013-06-01 17:44:12 +00:00
|
|
|
void sub_set_extradata(struct dec_sub *sub, void *data, int data_len)
|
|
|
|
{
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_lock(&sub->lock);
|
2013-06-01 17:44:12 +00:00
|
|
|
sub->init_sd.extradata = data_len ? talloc_memdup(sub, data, data_len) : NULL;
|
|
|
|
sub->init_sd.extradata_len = data_len;
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
2013-06-01 17:44:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void sub_set_ass_renderer(struct dec_sub *sub, struct ass_library *ass_library,
|
2015-07-06 19:55:37 +00:00
|
|
|
struct ass_renderer *ass_renderer,
|
|
|
|
pthread_mutex_t *ass_lock)
|
2013-06-01 17:44:12 +00:00
|
|
|
{
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_lock(&sub->lock);
|
2013-06-01 17:44:12 +00:00
|
|
|
sub->init_sd.ass_library = ass_library;
|
|
|
|
sub->init_sd.ass_renderer = ass_renderer;
|
2015-07-06 19:55:37 +00:00
|
|
|
sub->init_sd.ass_lock = ass_lock;
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
2013-06-01 17:44:12 +00:00
|
|
|
}
|
|
|
|
|
2013-06-03 19:49:39 +00:00
|
|
|
static void print_chain(struct dec_sub *sub)
|
|
|
|
{
|
2013-12-21 18:06:37 +00:00
|
|
|
MP_VERBOSE(sub, "Subtitle filter chain: ");
|
2013-06-03 19:49:39 +00:00
|
|
|
for (int n = 0; n < sub->num_sd; n++) {
|
|
|
|
struct sd *sd = sub->sd[n];
|
2013-12-21 18:06:37 +00:00
|
|
|
MP_VERBOSE(sub, "%s%s (%s)", n > 0 ? " -> " : "",
|
2013-06-03 19:49:39 +00:00
|
|
|
sd->driver->name, sd->codec);
|
|
|
|
}
|
2013-12-21 18:06:37 +00:00
|
|
|
MP_VERBOSE(sub, "\n");
|
2013-06-03 19:49:39 +00:00
|
|
|
}
|
|
|
|
|
2013-06-01 17:44:12 +00:00
|
|
|
static int sub_init_decoder(struct dec_sub *sub, struct sd *sd)
|
2011-01-16 18:03:08 +00:00
|
|
|
{
|
2013-06-01 17:44:12 +00:00
|
|
|
sd->driver = NULL;
|
sub: add sd_spu.c to wrap spudec, cleanup mplayer.c
This unifies the subtitle rendering path. Now all subtitle rendering
goes through sd_ass.c/sd_lavc.c/sd_spu.c.
Before that commit, the spudec.h functions were used directly in
mplayer.c, which introduced many special cases. Add sd_spu.c, which is
just a small wrapper connecting the new subtitle render API with the
dusty old vobsub decoder in spudec.c.
One detail that changes is that we always pass the palette as extra
data, instead of passing the libdvdread palette as pointer to spudec
directly. This is a bit roundabout, but actually makes the code simpler
and more elegant: the difference between DVD and non-DVD dvdsubs is
reduced.
Ideally, we would just delete spudec.c and use libavcodec's DVD sub
decoder. However, DVD playback with demux_mpg produces packets
incompatible to lavc. There are incompatibilities the other way around
as well: packets from libavformat's vobsub demuxer are incompatible to
spudec.c. So we define a new subtitle codec name for demux_mpg subs,
"dvd_subtitle_mpg", which only sd_spu can decode.
There is actually code in spudec.c to "assemble" fragments into complete
packets, but using the whole spudec.c is easier than trying to move this
code into demux_mpg to fix subtitle packets.
As additional complication, Libav 9.x can't decode DVD subs correctly,
so use sd_spu in that case as well.
2013-04-28 23:13:22 +00:00
|
|
|
for (int n = 0; sd_list[n]; n++) {
|
2013-06-01 17:44:12 +00:00
|
|
|
if (sd_list[n]->supports_format(sd->codec)) {
|
|
|
|
sd->driver = sd_list[n];
|
sub: add sd_spu.c to wrap spudec, cleanup mplayer.c
This unifies the subtitle rendering path. Now all subtitle rendering
goes through sd_ass.c/sd_lavc.c/sd_spu.c.
Before that commit, the spudec.h functions were used directly in
mplayer.c, which introduced many special cases. Add sd_spu.c, which is
just a small wrapper connecting the new subtitle render API with the
dusty old vobsub decoder in spudec.c.
One detail that changes is that we always pass the palette as extra
data, instead of passing the libdvdread palette as pointer to spudec
directly. This is a bit roundabout, but actually makes the code simpler
and more elegant: the difference between DVD and non-DVD dvdsubs is
reduced.
Ideally, we would just delete spudec.c and use libavcodec's DVD sub
decoder. However, DVD playback with demux_mpg produces packets
incompatible to lavc. There are incompatibilities the other way around
as well: packets from libavformat's vobsub demuxer are incompatible to
spudec.c. So we define a new subtitle codec name for demux_mpg subs,
"dvd_subtitle_mpg", which only sd_spu can decode.
There is actually code in spudec.c to "assemble" fragments into complete
packets, but using the whole spudec.c is easier than trying to move this
code into demux_mpg to fix subtitle packets.
As additional complication, Libav 9.x can't decode DVD subs correctly,
so use sd_spu in that case as well.
2013-04-28 23:13:22 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2011-01-16 18:03:08 +00:00
|
|
|
|
2013-06-01 17:44:12 +00:00
|
|
|
if (!sd->driver)
|
|
|
|
return -1;
|
|
|
|
|
2013-12-21 18:06:37 +00:00
|
|
|
sd->log = mp_log_new(sd, sub->log, sd->driver->name);
|
2013-06-01 17:44:12 +00:00
|
|
|
if (sd->driver->init(sd) < 0)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-11-23 20:37:15 +00:00
|
|
|
void sub_init_from_sh(struct dec_sub *sub, struct sh_stream *sh)
|
2013-06-01 17:44:12 +00:00
|
|
|
{
|
2013-06-01 17:44:55 +00:00
|
|
|
assert(!sub->num_sd);
|
2013-11-23 20:37:15 +00:00
|
|
|
assert(sh && sh->sub);
|
2013-06-01 17:44:55 +00:00
|
|
|
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_lock(&sub->lock);
|
|
|
|
|
2015-06-21 16:06:14 +00:00
|
|
|
if (sh->extradata && !sub->init_sd.extradata)
|
|
|
|
sub_set_extradata(sub, sh->extradata, sh->extradata_size);
|
2013-06-01 17:44:55 +00:00
|
|
|
struct sd init_sd = sub->init_sd;
|
2013-11-23 20:37:15 +00:00
|
|
|
init_sd.codec = sh->codec;
|
2015-12-05 22:56:28 +00:00
|
|
|
init_sd.sh = sh;
|
2013-06-01 17:44:55 +00:00
|
|
|
|
|
|
|
while (sub->num_sd < MAX_NUM_SD) {
|
|
|
|
struct sd *sd = talloc(NULL, struct sd);
|
|
|
|
*sd = init_sd;
|
|
|
|
sd->opts = sub->opts;
|
|
|
|
if (sub_init_decoder(sub, sd) < 0) {
|
|
|
|
talloc_free(sd);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
sub->sd[sub->num_sd] = sd;
|
|
|
|
sub->num_sd++;
|
|
|
|
// Try adding new converters until a decoder is reached
|
2013-06-01 17:54:18 +00:00
|
|
|
if (sd->driver->get_bitmaps || sd->driver->get_text) {
|
2013-06-03 19:49:39 +00:00
|
|
|
print_chain(sub);
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
2013-06-01 17:44:55 +00:00
|
|
|
return;
|
2013-06-01 17:54:18 +00:00
|
|
|
}
|
2013-06-01 17:44:55 +00:00
|
|
|
init_sd = (struct sd) {
|
|
|
|
.codec = sd->output_codec,
|
2013-06-02 21:01:37 +00:00
|
|
|
.converted_from = sd->codec,
|
2013-06-01 17:44:55 +00:00
|
|
|
.extradata = sd->output_extradata,
|
|
|
|
.extradata_len = sd->output_extradata_len,
|
2015-12-05 22:56:28 +00:00
|
|
|
.sh = sub->init_sd.sh,
|
|
|
|
.video_fps = sub->init_sd.video_fps,
|
2013-06-01 17:44:55 +00:00
|
|
|
.ass_library = sub->init_sd.ass_library,
|
|
|
|
.ass_renderer = sub->init_sd.ass_renderer,
|
2015-07-06 23:26:26 +00:00
|
|
|
.ass_lock = sub->init_sd.ass_lock,
|
2013-06-01 17:44:55 +00:00
|
|
|
};
|
2011-01-16 18:03:08 +00:00
|
|
|
}
|
2013-06-01 17:44:55 +00:00
|
|
|
|
|
|
|
sub_uninit(sub);
|
2013-12-21 18:06:37 +00:00
|
|
|
MP_ERR(sub, "Could not find subtitle decoder for format '%s'.\n",
|
2013-11-23 20:37:15 +00:00
|
|
|
sh->codec ? sh->codec : "<unknown>");
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
2011-01-16 18:03:08 +00:00
|
|
|
}
|
|
|
|
|
2013-06-23 22:47:08 +00:00
|
|
|
static struct demux_packet *get_decoded_packet(struct sd *sd)
|
|
|
|
{
|
|
|
|
return sd->driver->get_converted ? sd->driver->get_converted(sd) : NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void decode_chain(struct sd **sd, int num_sd, struct demux_packet *packet)
|
|
|
|
{
|
|
|
|
if (num_sd == 0)
|
|
|
|
return;
|
|
|
|
struct sd *dec = sd[0];
|
|
|
|
dec->driver->decode(dec, packet);
|
|
|
|
if (num_sd > 1) {
|
|
|
|
while (1) {
|
|
|
|
struct demux_packet *next = get_decoded_packet(dec);
|
|
|
|
if (!next)
|
|
|
|
break;
|
|
|
|
decode_chain(sd + 1, num_sd - 1, next);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-21 18:06:37 +00:00
|
|
|
static struct demux_packet *recode_packet(struct mp_log *log,
|
|
|
|
struct demux_packet *in,
|
2013-06-23 22:47:08 +00:00
|
|
|
const char *charset)
|
|
|
|
{
|
|
|
|
struct demux_packet *pkt = NULL;
|
|
|
|
bstr in_buf = {in->buffer, in->len};
|
2013-12-21 19:37:16 +00:00
|
|
|
bstr conv = mp_iconv_to_utf8(log, in_buf, charset, MP_ICONV_VERBOSE);
|
2013-06-23 22:47:08 +00:00
|
|
|
if (conv.start && conv.start != in_buf.start) {
|
|
|
|
pkt = talloc_ptrtype(NULL, pkt);
|
|
|
|
talloc_steal(pkt, conv.start);
|
|
|
|
*pkt = (struct demux_packet) {
|
|
|
|
.buffer = conv.start,
|
|
|
|
.len = conv.len,
|
|
|
|
.pts = in->pts,
|
|
|
|
.duration = in->duration,
|
|
|
|
.avpacket = in->avpacket, // questionable, but gives us sidedata
|
|
|
|
};
|
|
|
|
}
|
|
|
|
return pkt;
|
|
|
|
}
|
|
|
|
|
2013-06-23 23:04:17 +00:00
|
|
|
static void decode_chain_recode(struct dec_sub *sub, struct sd **sd, int num_sd,
|
|
|
|
struct demux_packet *packet)
|
2013-06-23 22:47:08 +00:00
|
|
|
{
|
2013-06-23 23:04:17 +00:00
|
|
|
if (num_sd > 0) {
|
2013-06-23 22:47:08 +00:00
|
|
|
struct demux_packet *recoded = NULL;
|
|
|
|
if (sub->charset)
|
2013-12-21 18:06:37 +00:00
|
|
|
recoded = recode_packet(sub->log, packet, sub->charset);
|
2013-06-23 23:04:17 +00:00
|
|
|
decode_chain(sd, num_sd, recoded ? recoded : packet);
|
2013-06-28 12:22:53 +00:00
|
|
|
talloc_free(recoded);
|
2013-06-23 22:47:08 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-23 23:04:17 +00:00
|
|
|
void sub_decode(struct dec_sub *sub, struct demux_packet *packet)
|
|
|
|
{
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_lock(&sub->lock);
|
2013-06-23 23:04:17 +00:00
|
|
|
decode_chain_recode(sub, sub->sd, sub->num_sd, packet);
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
2013-06-23 23:04:17 +00:00
|
|
|
}
|
|
|
|
|
2015-08-01 21:25:50 +00:00
|
|
|
static const char *guess_sub_cp(struct mp_log *log, void *talloc_ctx,
|
|
|
|
struct packet_list *subs, const char *usercp)
|
sub: add subtitle charset conversion
This code was once part of subreader.c, then traveled to libass, and now
made its way back to the fork of the fork of the original code, MPlayer.
It works pretty much the same as subreader.c, except that we have to
concatenate some packets to do auto-detection. This is rather annoying,
but for all we know the actual source file could be a binary format.
Unlike subreader.c, the iconv context is reopened on each packet. This
is simpler, and with respect to multibyte encodings, more robust.
Reopening is probably not a very fast, but I suspect subtitle charset
conversion is not an operation that happens often or has to be fast.
Also, this auto-detection is disabled for microdvd - this is the only
format we know that has binary data in its packets, but is actually
decoded to text. FFmpeg doesn't really allow us to solve this properly,
because a) the input packets can be binary, and b) the output will be
checked whether it's UTF-8, and if it's not, the output is thrown away
and an error message is printed. We could just recode the decoded
subtitles before sd_ass if it weren't for that.
2013-06-23 20:15:04 +00:00
|
|
|
{
|
|
|
|
if (!mp_charset_requires_guess(usercp))
|
|
|
|
return usercp;
|
|
|
|
|
|
|
|
// Concat all subs into a buffer. We can't probably do much better without
|
|
|
|
// having the original data (which we don't, not anymore).
|
|
|
|
int max_size = 2 * 1024 * 1024;
|
|
|
|
const char *sep = "\n\n"; // In utf-16: U+0A0A GURMUKHI LETTER UU
|
|
|
|
int sep_len = strlen(sep);
|
|
|
|
int num_pkt = 0;
|
|
|
|
int size = 0;
|
|
|
|
for (int n = 0; n < subs->num_packets; n++) {
|
|
|
|
struct demux_packet *pkt = subs->packets[n];
|
|
|
|
if (size + pkt->len > max_size)
|
|
|
|
break;
|
|
|
|
size += pkt->len + sep_len;
|
|
|
|
num_pkt++;
|
|
|
|
}
|
|
|
|
bstr text = {talloc_size(NULL, size), 0};
|
|
|
|
for (int n = 0; n < num_pkt; n++) {
|
|
|
|
struct demux_packet *pkt = subs->packets[n];
|
|
|
|
memcpy(text.start + text.len, pkt->buffer, pkt->len);
|
|
|
|
memcpy(text.start + text.len + pkt->len, sep, sep_len);
|
|
|
|
text.len += pkt->len + sep_len;
|
|
|
|
}
|
2015-08-01 21:25:50 +00:00
|
|
|
const char *guess = mp_charset_guess(talloc_ctx, log, text, usercp, 0);
|
sub: add subtitle charset conversion
This code was once part of subreader.c, then traveled to libass, and now
made its way back to the fork of the fork of the original code, MPlayer.
It works pretty much the same as subreader.c, except that we have to
concatenate some packets to do auto-detection. This is rather annoying,
but for all we know the actual source file could be a binary format.
Unlike subreader.c, the iconv context is reopened on each packet. This
is simpler, and with respect to multibyte encodings, more robust.
Reopening is probably not a very fast, but I suspect subtitle charset
conversion is not an operation that happens often or has to be fast.
Also, this auto-detection is disabled for microdvd - this is the only
format we know that has binary data in its packets, but is actually
decoded to text. FFmpeg doesn't really allow us to solve this properly,
because a) the input packets can be binary, and b) the output will be
checked whether it's UTF-8, and if it's not, the output is thrown away
and an error message is printed. We could just recode the decoded
subtitles before sd_ass if it weren't for that.
2013-06-23 20:15:04 +00:00
|
|
|
talloc_free(text.start);
|
|
|
|
return guess;
|
|
|
|
}
|
|
|
|
|
2015-12-05 22:56:53 +00:00
|
|
|
static void add_sub_list(struct dec_sub *sub, struct packet_list *subs)
|
2013-06-11 19:39:54 +00:00
|
|
|
{
|
|
|
|
struct sd *sd = sub_get_last_sd(sub);
|
|
|
|
assert(sd);
|
|
|
|
|
|
|
|
sd->no_remove_duplicates = true;
|
|
|
|
|
|
|
|
for (int n = 0; n < subs->num_packets; n++)
|
2015-12-05 22:56:53 +00:00
|
|
|
decode_chain_recode(sub, sub->sd, sub->num_sd, subs->packets[n]);
|
2013-06-11 19:39:54 +00:00
|
|
|
|
|
|
|
// Hack for broken FFmpeg packet format: make sd_ass keep the subtitle
|
|
|
|
// events on reset(), even if broken FFmpeg ASS packets were received
|
|
|
|
// (from sd_lavc_conv.c). Normally, these events are removed on seek/reset,
|
|
|
|
// but this is obviously unwanted in this case.
|
|
|
|
if (sd->driver->fix_events)
|
|
|
|
sd->driver->fix_events(sd);
|
|
|
|
|
|
|
|
sd->no_remove_duplicates = false;
|
|
|
|
}
|
|
|
|
|
2013-06-23 23:04:17 +00:00
|
|
|
static void add_packet(struct packet_list *subs, struct demux_packet *pkt)
|
|
|
|
{
|
|
|
|
pkt = demux_copy_packet(pkt);
|
2014-09-16 16:11:00 +00:00
|
|
|
if (pkt) {
|
|
|
|
talloc_steal(subs, pkt);
|
|
|
|
MP_TARRAY_APPEND(subs, subs->packets, subs->num_packets, pkt);
|
|
|
|
}
|
2013-06-23 23:04:17 +00:00
|
|
|
}
|
|
|
|
|
2013-06-11 19:39:54 +00:00
|
|
|
// Read all packets from the demuxer and decode/add them. Returns false if
|
|
|
|
// there are circumstances which makes this not possible.
|
2013-11-23 20:37:15 +00:00
|
|
|
bool sub_read_all_packets(struct dec_sub *sub, struct sh_stream *sh)
|
2013-06-11 19:39:54 +00:00
|
|
|
{
|
2013-11-23 20:37:15 +00:00
|
|
|
assert(sh && sh->sub);
|
2013-06-11 19:41:50 +00:00
|
|
|
struct MPOpts *opts = sub->opts;
|
|
|
|
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_lock(&sub->lock);
|
|
|
|
|
2015-12-05 22:54:00 +00:00
|
|
|
// Converters are assumed to always accept packets in advance
|
|
|
|
struct sd *sd = sub_get_last_sd(sub);
|
|
|
|
if (!(sd && sd->driver->accept_packets_in_advance)) {
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
2013-06-11 19:39:54 +00:00
|
|
|
return false;
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
}
|
2013-06-11 19:39:54 +00:00
|
|
|
|
2013-06-23 22:58:10 +00:00
|
|
|
struct packet_list *subs = talloc_zero(NULL, struct packet_list);
|
2013-06-11 19:39:54 +00:00
|
|
|
|
|
|
|
for (;;) {
|
2013-11-23 20:37:15 +00:00
|
|
|
struct demux_packet *pkt = demux_read_packet(sh);
|
2013-06-11 19:39:54 +00:00
|
|
|
if (!pkt)
|
|
|
|
break;
|
2015-12-05 22:56:53 +00:00
|
|
|
add_packet(subs, pkt);
|
|
|
|
talloc_free(pkt);
|
2013-06-11 19:39:54 +00:00
|
|
|
}
|
|
|
|
|
2015-12-05 22:56:53 +00:00
|
|
|
// movtext is currently the only subtitle format that has text output,
|
|
|
|
// but binary input. Skip charset conversion (they're UTF-8 anyway).
|
|
|
|
bool binary = sub->sd[0]->driver == &sd_movtext;
|
|
|
|
|
|
|
|
if (opts->sub_cp && !sh->sub->is_utf8 && !binary)
|
2015-08-01 21:25:50 +00:00
|
|
|
sub->charset = guess_sub_cp(sub->log, sub, subs, opts->sub_cp);
|
sub: add subtitle charset conversion
This code was once part of subreader.c, then traveled to libass, and now
made its way back to the fork of the fork of the original code, MPlayer.
It works pretty much the same as subreader.c, except that we have to
concatenate some packets to do auto-detection. This is rather annoying,
but for all we know the actual source file could be a binary format.
Unlike subreader.c, the iconv context is reopened on each packet. This
is simpler, and with respect to multibyte encodings, more robust.
Reopening is probably not a very fast, but I suspect subtitle charset
conversion is not an operation that happens often or has to be fast.
Also, this auto-detection is disabled for microdvd - this is the only
format we know that has binary data in its packets, but is actually
decoded to text. FFmpeg doesn't really allow us to solve this properly,
because a) the input packets can be binary, and b) the output will be
checked whether it's UTF-8, and if it's not, the output is thrown away
and an error message is printed. We could just recode the decoded
subtitles before sd_ass if it weren't for that.
2013-06-23 20:15:04 +00:00
|
|
|
|
2013-08-15 21:13:10 +00:00
|
|
|
if (sub->charset && sub->charset[0] && !mp_charset_is_utf8(sub->charset))
|
2013-12-21 18:06:37 +00:00
|
|
|
MP_INFO(sub, "Using subtitle charset: %s\n", sub->charset);
|
sub: add subtitle charset conversion
This code was once part of subreader.c, then traveled to libass, and now
made its way back to the fork of the fork of the original code, MPlayer.
It works pretty much the same as subreader.c, except that we have to
concatenate some packets to do auto-detection. This is rather annoying,
but for all we know the actual source file could be a binary format.
Unlike subreader.c, the iconv context is reopened on each packet. This
is simpler, and with respect to multibyte encodings, more robust.
Reopening is probably not a very fast, but I suspect subtitle charset
conversion is not an operation that happens often or has to be fast.
Also, this auto-detection is disabled for microdvd - this is the only
format we know that has binary data in its packets, but is actually
decoded to text. FFmpeg doesn't really allow us to solve this properly,
because a) the input packets can be binary, and b) the output will be
checked whether it's UTF-8, and if it's not, the output is thrown away
and an error message is printed. We could just recode the decoded
subtitles before sd_ass if it weren't for that.
2013-06-23 20:15:04 +00:00
|
|
|
|
2015-12-05 22:56:53 +00:00
|
|
|
add_sub_list(sub, subs);
|
2013-06-11 19:39:54 +00:00
|
|
|
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
2013-06-23 22:58:10 +00:00
|
|
|
talloc_free(subs);
|
2013-06-11 19:39:54 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2015-12-05 22:54:00 +00:00
|
|
|
bool sub_accepts_packet_in_advance(struct dec_sub *sub)
|
2013-04-28 19:12:11 +00:00
|
|
|
{
|
2015-12-05 22:54:00 +00:00
|
|
|
bool res = true;
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_lock(&sub->lock);
|
2015-12-05 22:54:00 +00:00
|
|
|
for (int n = 0; n < sub->num_sd; n++) {
|
|
|
|
if (sub->sd[n]->driver->accepts_packet)
|
|
|
|
res &= sub->sd[n]->driver->accepts_packet(sub->sd[n]);
|
|
|
|
}
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
2015-12-05 22:54:00 +00:00
|
|
|
return res;
|
2013-06-01 17:44:55 +00:00
|
|
|
}
|
|
|
|
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
// You must call sub_lock/sub_unlock if more than 1 thread access sub.
|
|
|
|
// The issue is that *res will contain decoder allocated data, which might
|
|
|
|
// be deallocated on the next decoder access.
|
2013-06-01 17:44:12 +00:00
|
|
|
void sub_get_bitmaps(struct dec_sub *sub, struct mp_osd_res dim, double pts,
|
2012-10-04 15:16:36 +00:00
|
|
|
struct sub_bitmaps *res)
|
2012-08-25 18:22:39 +00:00
|
|
|
{
|
2013-06-01 17:44:12 +00:00
|
|
|
struct MPOpts *opts = sub->opts;
|
2013-06-01 17:44:55 +00:00
|
|
|
struct sd *sd = sub_get_last_sd(sub);
|
2012-08-25 18:22:39 +00:00
|
|
|
|
2012-10-04 15:16:36 +00:00
|
|
|
*res = (struct sub_bitmaps) {0};
|
2013-06-01 17:44:55 +00:00
|
|
|
if (sd && opts->sub_visibility) {
|
|
|
|
if (sd->driver->get_bitmaps)
|
|
|
|
sd->driver->get_bitmaps(sd, dim, pts, res);
|
2012-08-25 18:22:39 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-06-01 17:44:12 +00:00
|
|
|
bool sub_has_get_text(struct dec_sub *sub)
|
2013-04-28 19:12:11 +00:00
|
|
|
{
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_lock(&sub->lock);
|
2013-06-01 17:44:55 +00:00
|
|
|
struct sd *sd = sub_get_last_sd(sub);
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
bool r = sd && sd->driver->get_text;
|
|
|
|
pthread_mutex_unlock(&sub->lock);
|
|
|
|
return r;
|
2013-04-28 19:12:11 +00:00
|
|
|
}
|
|
|
|
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
// See sub_get_bitmaps() for locking requirements.
|
2014-09-05 22:16:15 +00:00
|
|
|
// It can be called unlocked too, but then only 1 thread must call this function
|
|
|
|
// at a time (unless exclusive access is guaranteed).
|
2013-06-01 17:44:12 +00:00
|
|
|
char *sub_get_text(struct dec_sub *sub, double pts)
|
2011-01-16 18:03:08 +00:00
|
|
|
{
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_lock(&sub->lock);
|
2013-06-01 17:44:12 +00:00
|
|
|
struct MPOpts *opts = sub->opts;
|
2013-06-01 17:44:55 +00:00
|
|
|
struct sd *sd = sub_get_last_sd(sub);
|
2013-06-01 17:44:12 +00:00
|
|
|
char *text = NULL;
|
2013-06-01 17:44:55 +00:00
|
|
|
if (sd && opts->sub_visibility) {
|
|
|
|
if (sd->driver->get_text)
|
|
|
|
text = sd->driver->get_text(sd, pts);
|
2012-08-25 18:22:39 +00:00
|
|
|
}
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
2013-06-01 17:44:12 +00:00
|
|
|
return text;
|
2011-01-16 18:03:08 +00:00
|
|
|
}
|
|
|
|
|
2013-06-01 17:44:12 +00:00
|
|
|
void sub_reset(struct dec_sub *sub)
|
2011-01-16 18:03:08 +00:00
|
|
|
{
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_lock(&sub->lock);
|
2013-06-01 17:44:55 +00:00
|
|
|
for (int n = 0; n < sub->num_sd; n++) {
|
|
|
|
if (sub->sd[n]->driver->reset)
|
|
|
|
sub->sd[n]->driver->reset(sub->sd[n]);
|
|
|
|
}
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
2013-06-01 17:44:55 +00:00
|
|
|
}
|
|
|
|
|
2013-06-28 23:34:11 +00:00
|
|
|
int sub_control(struct dec_sub *sub, enum sd_ctrl cmd, void *arg)
|
|
|
|
{
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
int r = CONTROL_UNKNOWN;
|
|
|
|
pthread_mutex_lock(&sub->lock);
|
2013-06-28 23:34:11 +00:00
|
|
|
for (int n = 0; n < sub->num_sd; n++) {
|
|
|
|
if (sub->sd[n]->driver->control) {
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
r = sub->sd[n]->driver->control(sub->sd[n], cmd, arg);
|
2013-06-28 23:34:11 +00:00
|
|
|
if (r != CONTROL_UNKNOWN)
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
break;
|
2013-06-28 23:34:11 +00:00
|
|
|
}
|
|
|
|
}
|
sub: uglify sub decoder with locking
The plan is to make the whole OSD thread-safe, and we start with this.
We just put locks on all entry points (fortunately, dec_sub.c and all
sd_*.c decoders are very closed off, and only the entry points in
dec_sub.h let you access it). I think this is pretty ugly, but at least
it's very simple.
There's a special case with sub_get_bitmaps(): this function returns
pointers to decoder data (specifically, libass images). There's no way
to synchronize this internally, so expose sub_lock/sub_unlock functions.
To make things simpler, and especially because the lock is sort-of
exposed to the outside world, make the locks recursive. Although the
only case where this is actually needed (although trivial) is
sub_set_extradata().
One corner case are ASS subtitles: for some reason, we keep a single
ASS_Renderer instance for subtitles around (probably to avoid rescanning
fonts with ordered chapters), and this ASS_Renderer instance is not
synchronized. Also, demux_libass.c loads ASS_Track objects, which are
directly passed to sd_ass.c. These things are not synchronized (and
would be hard to synchronize), and basically we're out of luck. But I
think for now, accesses happen reasonably serialized, so there is no
actual problem yet, even if we start to access OSD from other threads.
2014-01-17 22:13:09 +00:00
|
|
|
pthread_mutex_unlock(&sub->lock);
|
|
|
|
return r;
|
2013-06-28 23:34:11 +00:00
|
|
|
}
|
|
|
|
|
2013-06-01 17:44:55 +00:00
|
|
|
#define MAX_PACKETS 10
|
|
|
|
#define MAX_BYTES 10000
|
|
|
|
|
|
|
|
struct sd_conv_buffer {
|
|
|
|
struct demux_packet pkt[MAX_PACKETS];
|
|
|
|
int num_pkt;
|
|
|
|
int read_pkt;
|
|
|
|
char buffer[MAX_BYTES];
|
|
|
|
int cur_buffer;
|
|
|
|
};
|
|
|
|
|
|
|
|
void sd_conv_add_packet(struct sd *sd, void *data, int data_len, double pts,
|
|
|
|
double duration)
|
|
|
|
{
|
|
|
|
if (!sd->sd_conv_buffer)
|
|
|
|
sd->sd_conv_buffer = talloc_zero(sd, struct sd_conv_buffer);
|
|
|
|
struct sd_conv_buffer *buf = sd->sd_conv_buffer;
|
|
|
|
if (buf->num_pkt >= MAX_PACKETS || buf->cur_buffer + data_len + 1 > MAX_BYTES)
|
|
|
|
goto out_of_space;
|
|
|
|
if (buf->read_pkt == buf->num_pkt)
|
|
|
|
sd_conv_def_reset(sd);
|
|
|
|
assert(buf->read_pkt == 0); // no mixing of reading/adding allowed
|
|
|
|
struct demux_packet *pkt = &buf->pkt[buf->num_pkt++];
|
|
|
|
*pkt = (struct demux_packet) {
|
|
|
|
.buffer = &buf->buffer[buf->cur_buffer],
|
|
|
|
.len = data_len,
|
|
|
|
.pts = pts,
|
|
|
|
.duration = duration,
|
|
|
|
};
|
|
|
|
memcpy(pkt->buffer, data, data_len);
|
|
|
|
pkt->buffer[data_len] = 0;
|
|
|
|
buf->cur_buffer += data_len + 1;
|
|
|
|
return;
|
|
|
|
|
|
|
|
out_of_space:
|
2013-12-21 18:06:37 +00:00
|
|
|
MP_ERR(sd, "Subtitle too big.\n");
|
2013-06-01 17:44:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
struct demux_packet *sd_conv_def_get_converted(struct sd *sd)
|
|
|
|
{
|
|
|
|
struct sd_conv_buffer *buf = sd->sd_conv_buffer;
|
|
|
|
if (buf && buf->read_pkt < buf->num_pkt)
|
|
|
|
return &buf->pkt[buf->read_pkt++];
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
void sd_conv_def_reset(struct sd *sd)
|
|
|
|
{
|
|
|
|
struct sd_conv_buffer *buf = sd->sd_conv_buffer;
|
|
|
|
if (buf) {
|
|
|
|
buf->read_pkt = buf->num_pkt = 0;
|
|
|
|
buf->cur_buffer = 0;
|
|
|
|
}
|
2011-01-16 18:03:08 +00:00
|
|
|
}
|