Since the video discussion has come up elsewhere, I thought I'd
forward this old message here where someone might find it of interest.
Since I never heard back on this I went ahead and coded an external
tools which extracts ogg metadata and image page data from files on
our system and outputs a [[json]] blob.
Example:
http://tools.wikimedia.de/~gmaxwell/cgi-bin/mediainfo.py?url=http%3A%2F%2Fu…
It extracts all the ogg tags, including the width and height from
videos that some players need in order to correctly size the output.
It also grabs the HTML on the images pages for embedding
description/licensing material in the player pop up window.
I did this so I'd have something to code the below proposed new
mediaplayer design stuff against. It would still be much better to
have the metadata extraction in mediawiki, however.
---------- Forwarded message ----------
From: Gregory Maxwell <gmaxwell(a)gmail.com>
Date: May 14, 2007 4:04 AM
Subject: Mediaplayer specs
To: tstarling(a)wikimedia.org
Sorry I didn't have more time to talk to you this evening regarding
media player stuff.
I wanted to drop you a quick note in case you decide to start coding
something, I don't want you going down the wrong path.
Increasingly I've been convinced that the Right Way(tm) to handle
audio/video player launching is largely through client side
javascript.
I can argue this from three primary angles:
#1 It's how most everyone else does it. Youtube, and a zillion other
sites that make video their business actually handle launch the player
(be it flash or whatever) via client side JS.
#2 It's the only reasonable way to handle inline players in articles .
We don't want articles with inline multimedia content spawning java
interpreters/plugins/etc until the users demand it. If we cause the
players to load as soon as the user loads the page we'll waste
bandwidth, cause performance problems, and risk crashing browsers (a
user with a broken browser that crashes when he clicks something he
can easily avoid is much better off than pages that crash as soon as
he loads them)
#3 It's the only reasonable way to handle detection of playback
methods. Today there are four distinct ways of playing video that I'm
supporting:
* <video/> tag. Part of WhatWG's HTML5 draft, includes support for
Theora+Vorbis as the baseline. Already supported by Opera 9.5 beta,
expected in FF3 (under active development).
* Application/Ogg support. Generic pluging handling ogg files, works
on most modern linux desktops, and for some folks who have QT + XiphQT
codecs installed.
* VLC plugin, works for people with the VLC plugin installed (Linux,
Windows, Mac?)
* Java works for almost anyone with almost any working Java VM.
The native players work better than the java player, and that will
continue to be the case for the future. A lot of folks also don't like
Java. Even once the video tag is widely supported in Firefox and opera
browsers we'd still need to keep java support around.
The only way to handle the auto-switching between playback methods is
with JS on the client side... at least the only way that doesn't break
the ability to cache pages served to readers.
So with all that in mind, I think the best way to support playback
would be something like this:
We adjust [[Media:iewjqiek.ogg|largebutton|loop|This is my title]] so
that it produces a link directly to the file like usual, but the
anchor tagt smuggles in the metadata the player needs to work well.
<a
href="http://upload.wikimedia.org/whatever/iewjqiej.ogg"
class="media media_type_video media_width_352 media_height_288
media_loop media_largebutton" title="This is my
title">Image:iewjqiek.ogg</a>
Then, javascript is provided to the client. Initially we could place
it in the site-customized monobook.js for easy development by
javascript mavens, but ultimately it would get migrated into the
skin's JS. (I can't see how to easily solve some issues like
localization via the standard localization interface without moving it
into the skin)
The javascript would, onload, scan the document for anchor tags with
class="media", extract the media URL and metadata, replace the link
with a 'play' icon which is hooked up to the machinery which handles
detecting a player and starting it when the user clicks.
Users without JS support end up seeing a nice friendly link directly
to the file... which they can hopefully use with some locally
installed player software. Playback on the image page would be
handled by having a media style anchor tag directly in the page.
Thoughts?