diff options
author | wm4 <wm4@nowhere> | 2014-01-26 18:58:40 +0100 |
---|---|---|
committer | wm4 <wm4@nowhere> | 2014-01-26 18:58:40 +0100 |
commit | 1e73da47dab00554028452dbb882d6885a454ab8 (patch) | |
tree | 1b2e7145f1733fd7ec0e03010ac2b3bc8f3a1480 /common/playlist.c | |
parent | b4ea5018f262ad783858d60dabdd530332735003 (diff) | |
download | mpv-1e73da47dab00554028452dbb882d6885a454ab8.tar.bz2 mpv-1e73da47dab00554028452dbb882d6885a454ab8.tar.xz |
sub: fix crash with certain uses of --vf=sub
If, for some reason, the subtitle renderer attempts to render a
subtitle before SD_CTRL_SET_VIDEO_PARAMS was called, it passed a
value calculated from invalid values. This can happen with --vf=sub
and --start. The crash happens if 1. there was a subtitle packet that
falls into the timestamp of the rendered video frame, 2. the playloop
hasn't informed the subtitle decoder about the video resolution yet
(normally unneeded, because that is used for weird corner cases only,
so this code is a bit fuzzy), and 3. something actually requests a
frame to be drawn from the subtitle renderer, like with vf_sub.
The actual crash was due to passing NaN as pixel aspect to libass,
which then created glyphs with ridiculous sizes, involving a few
integer overflows and unchecked mallocs.
The sd_lavc.c and sd_spu.c cases probably don't crash, but I'm not
sure, and it's better fix them anyway.
Not bothering with sd_spu.c, this crap is for compatibility and will
be removed soon.
Note that this would have been no problem, had the code checked whether
SD_CTRL_SET_VIDEO_PARAMS was actually called. This commit adds such a
check (although it basically checks after using the parameters).
Regression since 49caa0a7 and 633fde4a.
Diffstat (limited to 'common/playlist.c')
0 files changed, 0 insertions, 0 deletions