Hi all, Please direct followups to wikitech-l, since I think this is of broad interest there. Rob ---------- Forwarded message ---------- From: Rob Lanphier &lt;robla(a)wikimedia.org&gt; Date: Sun, Oct 28, 2012 at 10:41 PM Subject: [Wikitech-l] Switching to Timed Media Handler on Commons To: Wikimedia developers &lt;wikitech-l(a)lists.wikimedia.org&gt; Hi everyone, This is a fairly long email describing where we're at with Timed Media Handler, and what we plan for this week. The short version is: * We'll be deploying a few fixes tomorrow (Monday) * If all goes well, we'd like to deploy Timed Media Handler to Commons on Wednesday (9am PDT) * Short of deploying to Commons, we'd like to make some other significant deployment. I haven't yet run this plan by Jan (hi Jan!), so it's subject to change, but barring some unforeseen wrinkle, that's what we're rolling with. The long version: As Peter said earlier this week, the last big blocker for using Timed Media Handler (TMH) was the upgrade to Precise, which is now done (yay!) Currently on test2 for videos that where uploaded to test2 thumbnails work, e.g.: <http://test2.wikipedia.org/wiki/File:Citygroup_Center,_San_Francisco.ogv> Thumbs stopped working for videos that are loaded from commons, e.g. <http://test2.wikipedia.org/wiki/File:Folgers.ogv> The problem with the videos loaded from commons is that the expected thumb name starts with "Mid-", and that OggHandler on Commons doesn't support arbitrary pixel sizes in the request. Meanwhile, TMH assumes that it can request video thumbs by pixel size. Jan Gerber prepared a few fixes on Friday, and Aaron is going to deploy those on Monday. Here's all of Jan's recent commits: <https://gerrit.wikimedia.org/r/#/q/owner:J,n,z> I *think* that will clear up the last of our issues that are known blockers for wider deployment. On Thursday, Tim, Aaron and I had a conversation on #mediawiki about CPU time for thumbnailing based on some problems: <http://bots.wmflabs.org/~wm-bot/logs/%23mediawiki/20121026.txt> One minor thing we saw was that avconv (a fork of ffmpeg supported as a replacement for ffmpeg in Ubuntu) seems to have slightly better performance than ffmpeg. Jan plans to switch over to avconv. We also noticed that it's possible to mop up a ton of CPU time creating a video if the video is long enough (and maybe with only a single keyframe at the beginning). However, Jan pointed out that TMH uses command line switches that solve this problem by seeking a couple seconds before the target frame before decoding (using the -ss parameter on the input), and then decoding a couple seconds of video to get a good snapshot. Here's the command line: avconv -ss X -i video.ogv -ss Y -vframes 1 -an -f mjpeg out.jpg with X=Y-2 This provides a bit of a buffer so that we can be reasonably sure that avconv pulls in a keyframe, or at least has a chance to pull together a good snapshot based on several other frames. Assuming we get the last blocking bugs fixed tomorrow, then we should be able to go onto Commons on Wednesday, so that's our current plan. Let us know if there are issues with this. Thanks! Rob