[Foundation-l] Freedom, standards, and file formats

[Gregory Maxwell]

On Sun, Sep 28, 2008 at 10:42 PM, Tim Starling <tstarling at 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. :)