diff options
author | wm4 <wm4@nowhere> | 2012-10-04 17:16:32 +0200 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2012-10-16 07:26:31 +0200 |
commit | 17f5019b468d5269408b7dae53a24e17426de7d5 (patch) | |
tree | 65e34c482428e563e79356f19b4a9240d8f9ded2 /libaf | |
parent | 34b3a9c5e97dfae87afab64915dec624439eafa6 (diff) | |
download | mpv-17f5019b468d5269408b7dae53a24e17426de7d5.tar.bz2 mpv-17f5019b468d5269408b7dae53a24e17426de7d5.tar.xz |
sub: always go through sub.c for OSD rendering
Before this commit, vf_vo.c and vf_ass.c were manually calling the
subtitle decoder to retrieve images to render. In particular, this
circumvented the sub-bitmap conversion & caching layer in sub.c.
Change this so that subtitle decoding isn't special anymore, and draws
all subtitles with the normal OSD drawing API.
This is also a step towards removing the need for vf_ass auto-insertion.
In fact, if auto-insertion would be disabled now, VOs with "old" OSD
rendering could still render ASS subtitles in monochrome, because
there is still ASS -> old-OSD bitmap conversion in the sub.c mechanism.
The code is written with the assumption that the subtitle rendering
filter (vf_ass) can render all subtitle formats. Since vf_ass knows the
ASS format only, rendering image subs (i.e. RGBA subs) with it simply
fails. This means that with vo_xv (vf_ass auto-inserted), image subs
wouldn't be rendered. Use a dumb hack to disable rendering subs with a
filter, if we detect that the subs are not in ASS format. (Trying to
render the subs first would probably result in purging the conversion
cache on every frame.)
Diffstat (limited to 'libaf')
0 files changed, 0 insertions, 0 deletions