summaryrefslogtreecommitdiffstats
path: root/sub/sd_ass.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2012-10-04 17:16:32 +0200
committerwm4 <wm4@nowhere>2012-10-16 07:26:31 +0200
commit17f5019b468d5269408b7dae53a24e17426de7d5 (patch)
tree65e34c482428e563e79356f19b4a9240d8f9ded2 /sub/sd_ass.c
parent34b3a9c5e97dfae87afab64915dec624439eafa6 (diff)
downloadmpv-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 'sub/sd_ass.c')
0 files changed, 0 insertions, 0 deletions