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%2Fup...
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@gmail.com Date: May 14, 2007 4:04 AM Subject: Mediaplayer specs To: tstarling@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?
wikitech-l@lists.wikimedia.org