Thanks for the feedback. I already knew that FFmpeg was slow, even on dedicated servers, but PHP cannot speed up this process which runs separately on server as a command-line utility. About implementing
"queue method", this is not productive for many reasons:
1. Just because thumbnails process in "queue", does not mean all thumbnails will resize faster. Total resize time should be slower.
2. Queue method would just be a workaround to solve insufficient PHP
max-execution-time.
3. Browsers make "parallel" requests, because it's faster, and this is causing the parallel requests to resized videos.
4. What happens when videos get cached? Files app doesn't know that up front, so it would be queueing already-cached images instead of loading them in parallel.
5. It's simply not logical or practical to implement. Files app loads images as they appear on screen as unique image requests. It's not practical to block this behavior and attempt to build a javascript-based queue-system that blocks requests until they load in one after the other.
As noted earlier, as long as the thumbnails get created once, they get cached so they will load much faster after first visit.
Essentially, you need server resources that are sufficient to create thumbnails, from your specific videos, without exceeding the PHP max-execution-time.
A workaround solution would be to simply extend the max-execution-time using PHP
set_time_limt(). For example, locate the FFmpeg command in Files index.php:
$cmd = escapeshellarg( ...
Increase timeout:
set_time_limit(300); // seconds
$cmd = escapeshellarg( ...
No it won't speed up the process, but it will allow thumbnails to eventually get created without causing timeout. And after they are created once, they are cached of course. If your server is limited and you want video thumbnails, there is no other way around this apart from allowing additional processing time.
amwpsaa wrote:and there will be a part of the thumbnail size of 0, not displayed properly.
I don't think this is related. I have seen FFmpeg create 0kb thumbnails when it encounters video formats that it cannot process for some reason. We cannot detect this through PHP. Besides, if there is a PHP timeout while FFmpeg is processing, the PHP will stop processing without creating the thumbnail.
amwpsaa wrote: // ffmpeg command
$cmd = escapeshellarg(config::$config['video_ffmpeg_path']) . ' -i ' . escapeshellarg($path) . ' -threads 2 -an -ss 1 -s 480x320 -vf "thumbnail,scale=480:320:force_original_aspect_ratio=increase,crop=480:320" -r 1 -y -f image2 -vframes 1 ' . $cache . ' 2>&1';
So you added
-threads 2 and removed
-t 1? I don't see how "threads" will help much, because the lower the value, the less CPU used, but the slower the process will be. The total CPU required to process video thumbnail requests will remain the same. As for removing "-t 1" yes that can speed up requests, because FFmpeg doesn't have to fast-forward to 1 second into the video. However, my tests showed that without this value, thumbnails were often created from the very beginning of videos, often causing a black thumbnail.
My recommendation for you, is to try the
set_time_limt(300) option mentioned above. Yes it will still be slow, but they will eventually get created and cached. If you want to use FFmpeg to create videos from thumbnails, you need a server that has sufficient resources.