-lavdopts threads option limit too small

[Jinxin Zheng]

Summary of the bug:
I use mplayer to play an HEVC 10bit test video. The system configuration is dual E5-2670 @2.6GHz with 16 cores/32 hyper-threads, and 64GB memory. However mplayer cannot play it very smoothly.

I tried to increase the -lavdopts threads option to 16, things get better but there are still noticeable lags. When I tried to increase the threads option to 32, mplayer refuses to play.

How to reproduce:

$ mplayer -lavdopts threads=32 UHD_PQ_Lovely_Swiss.ts
The threads option must be <= 16: 32
Error parsing option on the command line: -lavdopts
MPlayer 1.2.1-4.9.3 (C) 2000-2016 MPlayer Team

I can see from the system monitor that mplayer is certainly not fully utilizing my CPU. And I don't believe it's impossible to play the test video on my computer smoothly. So I searched the source code a little bit and modified libmpcodecs/vd_ffmpeg.c at this line:

{"threads" , &lavc_param_threads , CONF_TYPE_INT , CONF_RANGE, 1, 16, NULL},

changed 16 to 64. Then mplayer accepts the -lavdopts threads=32 option and the video plays much more smoothly, except some 'Too many buffered pts' warnings. Then I found the warning in the code and modified libmpdemux/stheader.h at

typedef struct sh_video {

...
double buffered_pts[32];
...

and changed the size of the buffered_pts array to 64. Now the playback seems perfect. So I think this is a performance bug that should be fixed in mplayer.

[reimar]

I bumped the limit to 32, but you are really in a small minority to have that issue, and the HT cores being particularly useful is rather a corner-case caused by the HEVC codec being quite unoptimized.
I'll mark it as fixed, even though it would be possible to make the limit arbitrary there are quite some issues like cache and memory use with high values so it might not be so good to encourage people to use unreasonable values.