summaryrefslogtreecommitdiffstats
path: root/sub/osd_state.h
Commit message (Collapse)AuthorAgeFilesLines
* options: move most subtitle and OSD rendering options to sub structswm42018-01-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Remove them from the big MPOpts struct and move them to their sub structs. In the places where their fields are used, create a private copy of the structs, instead of accessing the semi-deprecated global option struct instance (mpv_global.opts) directly. This actually makes accessing these options finally thread-safe. They weren't even if they should have for years. (Including some potential for undefined behavior when e.g. the OSD font was changed at runtime.) This is mostly transparent. All options get moved around, but most users of the options just need to access a different struct (changing sd.opts to a different type changes a lot of uses, for example). One thing which has to be considered and could cause potential regressions is that the new option copies must be explicitly updated. sub_update_opts() takes care of this for example. Another thing is that writing to the option structs manually won't work, because the changes won't be propagated to other copies. Apparently the only affected case is the implementation of the sub-step command, which tries to change sub_delay. Handle this one explicitly (osd_changed() doesn't need to be called anymore, because changing the option triggers UPDATE_OSD, and updates the OSD as a consequence). The way the option value is propagated is rather hacky, but for now this will do.
* osd_libass: avoid libass warnings if scripts set ASS text earlywm42017-07-161-0/+1
| | | | | | | | | | | | | | | | 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.
* osd: move some internal declarations to internal headerswm42017-01-261-0/+6
|
* player: show subtitles on VO if --force-window is usedwm42016-10-261-0/+1
| | | | | | | | | | | | | | | | | | | | | 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.
* osd: fix OSD getting stuck with --blend-subtitles=yeswm42016-09-161-4/+1
| | | | | | | | | | | | | 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.
* osd: slightly simplify update logicwm42016-09-151-3/+2
| | | | | | | | | | | | | | | | 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.
* sub: change how libass output is converted to RGBA in some caseswm42016-07-031-6/+0
| | | | | | | | | | | | | | | | | 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.
* sub: pack libass bitmaps directly in sd_ass.c and osd_libass.cwm42016-06-301-1/+3
| | | | | | | | | | | | | | | | 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.
* osd: cleanup: make OSDTYPE_ constants private to OSD codewm42016-03-081-0/+12
| | | | | | 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()).
* osd, lua: manage multiple ASS overlays set with set_osd_ass() callswm42016-03-081-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | 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.)
* osd: restructure and move ASS objects into its own structwm42016-03-081-3/+8
| | | | | | All ASS objects used by the OSD renderer go into struct ass_state. Preparation for the following commit.
* osd: refactor how mp_ass_render_frame() is calledwm42016-03-081-1/+1
| | | | | | | | 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.
* osd: use the same ASS_Renderer for OSD text and progbarwm42015-11-281-1/+1
| | | | | | Reduces memory usage and startup times. The implementation is a bit weird, because both OSD parts have conflicting requirements on the used ASS styles.
* player: remove OSD subtitle render pathwm42015-11-171-1/+1
| | | | | | | | | | | | | | | | | | | 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.
* player: remove higher-level remains of DVD/BD menu supportwm42015-08-031-3/+0
| | | | | | | | | | | | | | | 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.
* osd: simplify an aspect of change detection handlingwm42015-03-181-2/+1
| | | | | | | | | | | | | | | | | | 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.
* video/out: change aspects of OSD handlingwm42014-06-151-2/+0
| | | | | | | | | 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.
* sub: uglify OSD code path with lockingwm42014-01-181-0/+68
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.