1
0
mirror of https://github.com/mpv-player/mpv synced 2024-12-25 08:12:17 +00:00
Commit Graph

17 Commits

Author SHA1 Message Date
wm4
572802e866 osd_libass: avoid libass warnings if scripts set ASS text early
Lua scripts can call osd_set_external() early (before the VO window is
created and obj->vo_res is filled), in which case the PlayResX field
would be set to nonsense, and libass would print a pointless warning.

There's an easy and a hard fix: either just go on and pass dummy values
to libass (basically like before, just clamp them to avoid the values
which make libass print the warning). Or attempt to update the PlayRes
field to correct values on rendering (since at rendering time, you
always know the screen size and the correct values). Do the latter.

Since various things use PlayRes for scaling things, this might still
not be fully ideal. This is a general problem with the async scripting
interface.
2017-07-16 13:33:19 +02:00
wm4
60452f640f osd: move some internal declarations to internal headers 2017-01-26 16:34:31 +01:00
wm4
90b968a67a player: show subtitles on VO if --force-window is used
If a VO is created, but no video is playing (i.e. --force-window is
used), then until now no subtitles were shown. This is because VO
subtitle display normally depends on video frame timing. If there are no
video frames, there can be no subtitles.

Change this and add some code to handle this situation specifically. Set
a subtitle PTS manually and request VO redrawing manually, which gets
the subtitles rendered somehow.

This is kind of shaky. The subtitles are essentially sampled at
arbitrary times (such as when new audio data is decoded and pushed to
the AO, or on user interaction). To make a it slightly more consistent,
force a completely arbitrary minimum FPS of 10.

Other solutions (such as creating fake video) would be more intrusive or
would require VO-level API changes.

Fixes #3684.
2016-10-26 20:44:05 +02:00
wm4
56616b0b01 osd: fix OSD getting stuck with --blend-subtitles=yes
If --blend-subtitles=yes is given, vo_opengl will call osd_draw()
multiple times, once for subtitles, and once for OSD. This meant that
the want_redraw flag was reset before the OSD was rendered, which in
turn meant that update_osd() was never called. It seems like removing
the per-OSD object want_redraw wasn't such a good idea. Fix it by
reintroducing such a flag for OSDTYPE_OSD only.

Also, the want_redraw flag is now unused, so kill it.

Another regression caused by commit 9c9cf125. Fixes #3535.
2016-09-16 17:17:32 +02:00
wm4
9c9cf125ad osd: slightly simplify update logic
Remove the per-part force_redraw flags, and instead make the difference
between flagging dirty state and returning it to the player frontend
more explicit. The big issue is that 1. the OSD needs to know the dirty
state, and it should be cleared strictly when it is re-rendered
(force_redraw flag), and 2. the player core needs to be notified once,
and the notification must be reset (want_redraw flag).

The call in loadfile.c is replaced by making osd_set_sub() set the
change flag. Increasing the change flag on dirty state (the force_redraw
check in render_object()) should not be needed, because OSD part
renderers set it correctly (at least now).

Doing this just because someone pointed this out.
2016-09-15 14:50:38 +02:00
wm4
37cf92c07a sub: change how libass output is converted to RGBA in some cases
This affects VOs (or other code which render OSD) which does not support
the LIBASS format, but only RGBA. Instead of having a converter stage in
osd.c, make mp_ass_packer_pack() output directly in RGBA.

In general, this is work towards refcounted subtitle images.

Although we could keep the "converter" design, doing it this way seems
simpler, at least considering the current situation with only 2 OSD
formats. It also prevents copying & packing the data twice, which will
lead to better performance. (Although I guess this case is not important
at all.)

It also fixes --force-rgba-osd-rendering when used with vo_opengl,
vo_vdpau, and vo_direct3d.
2016-07-03 19:32:31 +02:00
wm4
c57304a591 sub: pack libass bitmaps directly in sd_ass.c and osd_libass.c
Change all producer of libass images to packing the bitmaps into a
single larger bitmap directly when they're output. This is supposed to
help working towards refcounted sub bitmaps.

This will reduce performance for VOs like vo_xv, but not for vo_opengl.
vo_opengl simply will pick up the pre-packed sub bitmaps, and skip
packing them again. vo_xv will copy and pack the sub bitmaps
unnecessarily - but if we want sub bitmap refcounting, they'd have to be
copied anyway.

The packing code cannot be removed yet from vo_opengl, because there are
certain corner cases that still produce unpackad other sub bitmaps.
Actual refcounting will also require more work.
2016-06-30 21:38:50 +02:00
wm4
876a3bafc5 osd: cleanup: make OSDTYPE_ constants private to OSD code
No need to have them everywhere. The only exception/annoyance is
MAX_OSD_PARTS, which is now basically duplicated (and at runtime
initialization is checked with an assert()).
2016-03-08 22:01:57 +01:00
wm4
75a36662cb osd, lua: manage multiple ASS overlays set with set_osd_ass() calls
Until now, there was only 1 global ASS overlay that could be set by all
scripts. This was often perceived as bug when multiple scripts tried to
set their own ASS overlay.

This was kind of hard to solve because the script could set its own ASS
PlayResX/Y, which makes it impossible to share a single ASS_Renderer for
multiple scripts. The OSC unfortunately makes use of this feature (and
unfortunately can't be fixed because it's a POS), so we're stuck with
this complication.

Implement the worst-case solution and fix this by creating separate ASS
track and renderer objects for each script that wants to set an ASS
overlay.

The z-order is decided by the order the scripts set their text first.
This is essentially random, unless you do it at script init, and you
pass scripts in a specific order. Script initialization is currently
serialized (as a feature), so the first loaded script gets lowest
Z-order.

The Lua script API interestingly remains the same. (And also will remain
undocumented, unsupported, and potentially volatile.)
2016-03-08 22:00:02 +01:00
wm4
ed254f29a9 osd: restructure and move ASS objects into its own struct
All ASS objects used by the OSD renderer go into struct ass_state.

Preparation for the following commit.
2016-03-08 22:00:02 +01:00
wm4
f5bfe01932 osd: refactor how mp_ass_render_frame() is called
Instead of passing an explicit cache to the function, the res parameter
is used. Also, instead of replacing its contents, sub bitmaps are now
appended to it (all assuming the format doesn't actually change).

This is preparation for the following commits.
2016-03-08 21:59:55 +01:00
wm4
2b07d3eb47 osd: use the same ASS_Renderer for OSD text and progbar
Reduces memory usage and startup times. The implementation is a bit
weird, because both OSD parts have conflicting requirements on the used
ASS styles.
2015-11-28 19:24:31 +01:00
wm4
5a89150a46 player: remove OSD subtitle render path
This was used with --no-sub-ass (aka --no-ass). This option (which is
not yet removed) strips all styling from the subtitles, and renders them
as plaintext only. For some reason, it originally seemed convenient to
reuse all the OSD text rendering code (osd_libass.c). While this was
indeed simple, it had a bad influence on the rest of the code. For
example, it had to decide whether to go through the OSD code path, or
the proper subtitle renderer in sd_ass.c.

Kill the OSD subtitle renderer. Reimplement --no-sub-ass and also
"secondary" subtitles in sd_ass.c. fill_plaintext() contains some rather
minor code duplication with osd_libass.c for setting up a dummy
ASS_Event and escaping the stripped text. Since sd_ass.c already has to
handle "normal" text subtitles, and has code for stripping ASS tags,
this remains all relatively simple.

Remove all the unnecessary crap from the rest of the code.
2015-11-17 01:56:23 +01:00
wm4
f792f56440 player: remove higher-level remains of DVD/BD menu support
Nobody wanted to restore this, so it gets the boot.

If anyone still wants to volunteer to restore menu support, this would
be welcome. (I might even try it myself if I feel masochistic and like
wasting a lot of time for nothing.) But if it does get restored, it
should be done differently. There were many stupid things about how it
was done. For example, it somehow tried to pull mp_nav_events through
all the layers (including needing to "buffer" them in the demuxer),
which was needlessly complicated. It could be done simpler.

This code was already inactive, so this commit actually changes nothing.
Also keep in mind that normal DVD/BD playback still works.
2015-08-03 23:49:14 +02:00
wm4
51befc9deb osd: simplify an aspect of change detection handling
There was a somewhat obscure optimization in the OSD and subtitle
rendering path: if only the position of the sub-images changed, and not
the actual image data, uploading of the image data could be skipped. In
theory, this could speed up things like scrolling subtitles.

But it turns out that even in the rare cases subtitles have such scrolls
or axis-aligned movement, modern libass rarely signals this kind of
change. Possibly this is because of sub-pixel handling and such, which
break this.

As such, it's a worthless optimization and just introduces additional
complexity and subtle bugs (especially in cases libass does the
opposite: incorrectly signaling a position change only, which happened
before). Remove this optimization, and rename bitmap_pos_id to
change_id.
2015-03-18 13:15:20 +01:00
wm4
716285782d video/out: change aspects of OSD handling
Let the VOs draw the OSD on their own, instead of making OSD drawing a
separate VO driver call. Further, let it be the VOs responsibility to
request subtitles with the correct PTS. We also basically allow the VO
to request OSD/subtitles at any time.

OSX changes untested.
2014-06-15 20:53:15 +02:00
wm4
7f4a09bb85 sub: uglify OSD code path with locking
Do two things:
1. add locking to struct osd_state
2. make struct osd_state opaque

While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses
lots of osd_state (and osd_object) members. To make sure everything is
accessed synchronously, I prefer making osd_state opaque, even if it
means adding pretty dumb accessors.

All of this is meant to allow running VO in their own threads.
Eventually, VOs will request OSD on their own, which means osd_state
will be accessed from foreign threads.
2014-01-18 01:27:43 +01:00