Please direct followups to wikitech-l, since I think this is of broad
---------- Forwarded message ----------
From: Rob Lanphier <robla(a)wikimedia.org>
Date: Sun, Oct 28, 2012 at 10:41 PM
Subject: [Wikitech-l] Switching to Timed Media Handler on Commons
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
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
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
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
Currently on test2 for videos that where uploaded to test2 thumbnails
Thumbs stopped working for videos that are loaded from commons, e.g.
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:
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:
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
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.