diff options
author | wm4 <wm4@nowhere> | 2014-01-17 23:13:09 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2014-01-17 23:21:17 +0100 |
commit | 92a9f11a0b4fda60c8880014be5920dcf3e95253 (patch) | |
tree | 790e1c362c0d23a12c03781c93183912f40edac3 /sub/osd_libass.c | |
parent | 49ebbce3e049c7f8fba0c001d1e70994e2473eee (diff) | |
download | mpv-92a9f11a0b4fda60c8880014be5920dcf3e95253.tar.bz2 mpv-92a9f11a0b4fda60c8880014be5920dcf3e95253.tar.xz |
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.
Diffstat (limited to 'sub/osd_libass.c')
0 files changed, 0 insertions, 0 deletions