traceypooh / deriver-archive Goto Github PK

As far as I can tell, the thumbnail generation code in Thumbnails.inc and Video.inc is inefficient, converting the whole video into frames as JPGs and then choosing frames out of those. This apparently can take a very long time (with the code allocating at minimum 1 hour and at least 1.5x the source video length for it). Additionally, it's inefficient, as in many cases the goal is to generate one frame every 30 seconds (and in items with a large number of videos, this gets reduced to two thumbnails per video). (I"m not 100% sure it actually creates every single frame, but the generated frame numbers makes me think it does. It might be that the -r argument specifying a lower framerate only dumps frames every so often, but it uses the input frame. At least it seems like it is decoding the whole video, which seems unneeded for thumbnails.)

FFMpeg supports a -ss argument to seek to a specific time. This takes a time duration, and more importantly "will be parsed using keyframes, which is very fast" (at least when used for the input). The seek time can just be a length in seconds (including a fractional part); for instance ffmpeg -ss 855.99 -i video.mp4 -vframes 1 test.jpg. Note that this was added around ffmpeg 2.1, which was released in 2013 or so, after this code was written.

Something like this could work (though it'd need modification, and it won't generate the same filenames as before, and I don't know PHP):

def generate_thumbnails(filename, frameLimit, frameEvery):
    # frameLimit is an int, frameEvery may be a float
    for i in range(frameLimit):
        subprocess.check_call("ffmpeg", "-ss", str(frameEvery * i), "-i", filename, "-vframes", "1", "thumbs/" + filename + "_" + str(i) + ".jpg")

This does run ffmpeg multiple times, rather than just once, but I think seeking will still be a lot faster.

I haven't actually tried this on my machine, so if this isn't actually a valid optimisation sorry for the inconvenience.