Last modified: 2013-05-28 12:53:29 UTC
extracting frames from the video file is expensive and with swift even more so. To reduce the number of frames that are extracted from the video directly, smaller frames should be extracted from a thumbnail: request thumbnail at 140px would result in: video -> thumbnail at video resolution (this would only have to happen once) thumbnail at video resolution -> thumbnail at requested size
Maybe we should also be looking into a server solution that could read the video asset directly. Even with the proposed improved workflow, thumbnails are going to be very costly on large assets with swift today since we download the whole asset to the machine doing the thumbnailing. But it would be good to fix this bug as an intermediate solution. I see it helping out where vidoes are embedded with the default time. Maybe not so helpful for arbitrary seconds embedded used once in a particular article context.
Yes, avconv can read from http sources, so instead of passing a local file we could pass the public video url or even swift url. Since right now ogg thumbs are not created with avconv this would only be a partial solution. Not sure how well this would perform compared to the local checkout though. Ah also, bugzilla does not sync with gerrit: here a first patch https://gerrit.wikimedia.org/r/#/c/31646/ for scaling thumbs instead of extracting them.
Reading over http sounds better then downloading the whole file on the back-end ... as long as ranged requests are supported at whatever http layer we hit ;)
moving http seeking discussing to its own bug (https://bugzilla.wikimedia.org/show_bug.cgi?id=41744)
