Good point.
IIRC, we only offer 3 potential thumbnails for HD recordings exactly because it's so slow.
It appears that the same ffmpeg command is being run, once for each thumbnail (
As far as I can see the explanation must be a combination of (a) 81 times more pixels to process (b) perhaps the H.264 decoder is less efficient with the MIPS instruction set: the CPUs have some built-in vector instructions that the MPEG2 decoder might be using, or it might just be better optimised, being older, whereas H.264 comes from the GHz/GB era of CPUs.
We also have
IIRC, we only offer 3 potential thumbnails for HD recordings exactly because it's so slow.
It appears that the same ffmpeg command is being run, once for each thumbnail (
ts method mkbmp()):
Code:
# -ss input offset, -i input file, -y overwrite existing, $bmpfile output
/mod/bin/ffmpeg -loglevel fatal -ss $offset -i $file -frames 1 -pix_fmt argb -vf vflip -s 140x78 -y $bmpfileWe also have
ts method mkbmps() which makes 5 thumbnails with one call to ffmpeg. Perhaps this approach would be quicker overall, but we don't want the web server to time out while calculating the thumbnails (hence individual calls). In fact, that method isn't used anywhere; ISTR it was replaced with individual calls for just that reason.
Last edited: