Commit Graph

4 Commits

Author SHA1 Message Date
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