On Sun, Sep 28, 2008 at 10:42 PM, Tim Starling tstarling@wikimedia.org wrote:
I was also completely opposed to any deal with Kaltura. But I'm not opposed to on-the-fly conversion from a free archival format to a non-free display format, and I think that's a totally different issue.
There are multiple issues with Kaltura. That fact that it is a hosted solution, that it's basically not open (No SVN activity in the last three months, only ever released that little flash player code and the trivial mediawiki embedder), that many people thought its 'slideshow' nature was a poor fit, that wikimedians haven't bothered using it, that it appears to be dead on the mediawiki sites that have deployed it... and that it requires proprietary codecs.
So I guess we disagree on the codecs issue, but probably not most of rest.
With display formats, there's no lock-in, we can drop support at any time, and the costs may well be laughably low or zero.
"The cost is $X, but if we don't pay it, then Y% will suddenly be unable to play our video!"
Y is much lower if people have been spending the last two years installing codecs, Java, or switching to Firefox but they will not install these things. Y is also lower when vendors are encouraged to support these formats out of the box because just-working with Wikipedia is nice.
Tim, I know I'm getting repetitive here, but if there were no lock-in you wouldn't be suggesting flash as a display format at all. You're not suggesting that it would further our mission to adopt parallel articles in DOCX, etc. It's the very fact that there is lock-in which leaves us stuck with these problems.
Increased adoption is the only way to avoid that lock-in.
...and If display format support is so easy, why can't I watch most content on archive.org without proprietary codecs? even though they have a transcoding infrastructure? Why is it that Wikipedia Weekly (and offsite radio show about Wikipedia) routinely had broken OGGs while the aac files always worked (I can't comment on their recent performance, but this was certainly the case many times in the past)?
Maybe by that time, the Thusnelda branch will be finished, and we'll have an codec library which is competitive with H.264 in terms of output quality.
Do you actually think the difference in quality per bitrate between the current Theora encoder and H.264 has any relevance to us?
We have video uploaded at 10mbit/sec in Ogg/Theora. Perhaps a leading edge H.264 could deliver the same quality with 7 mbit/sec. What difference does it make?
Beyond a certain quality vs bitrate threshold, basically, "can you offer watchable video over low end broadband?", improved quality doesn't buy much. Theora is well past that threshold, but unfortunately other possible free choices are not anywhere near it (MJPEG, etc).
Youtube's experience shows that if you want video that just works you need to be transcoding to ~250kbit/sec. All codecs perform fairly poorly a that bitrate, and the difference between H.264 and the current theora encoder is not very large (...and current Theora looks nicer than the VP6 youtube has been using at those bitrates for compatibility with flash 7(?), in any case).
The obvious way forward is to offer multiple bitrates: Low bitrates for video that just works, higher bitrates (served over WMF's least cost pipes) for higher quality for people with faster links or greater patience. Once you're doing that the quality differences between codecs should only decide choices among otherwise-equals.
We figured this out for still images how many years ago? :)
Nobody is going to stop working on libtheora just because we start transcoding our Theora videos to alternative formats.
If not a single line of code were ever committed again to libtheora it would be no great harm. The format works and doesn't need any more development to be working.
"It's the client that counts"
As you noted: changing the server side isn't that big a deal... Except that the server has to be compatible with the clients and changing an installed base of hundreds of millions of people (the audience of Wikipedia) take *years*. We're a good way into it, why stop now as we are gaining momentum, as pointed out by others in this thread?
A framework for transcoding into multiple formats may be useful at that time even if we don't want to use MPEG anymore, since we might want to start promulgating Dirac.
Other formats? Meh. Large scale conversions end up needing to be big batch jobs in any case. Other bitrates? *Absolutely essential* But we have none of that today.
Take a look at this: http://www.vquence.com.au/metrics-blog.html
It's a list of features Youtube has. Few of these have any flash interaction and I do not believe any are video format specific. I don't see anything that couldn't be done with HTML5 Video+JS and freely licensed formats.
Yet with only a couple of exceptions we have no parallel to most of these features, and I don't think youtube is widely considered a particularly featureful site. (Heck, they've recently dropped their parallel to our small upload limit, as I understand it!)
If we want to be serious about delivering good video support the current lack of client-side Theora support is not one of the largest barriers. There are many other important features that we lack which are true for any format, and which are difficult to solve.
By the time we get around to implementing all the other parts needed to do video well the codec issue may well be a moot one.
Thanks for taking the time to respond to me, I do respect your opinion, even though I think it's a very "server centric" one, and I don't agree with it's applicability as project policy. :)