Multimedia

This page discusses how to improve the multimedia content of Wikimedia projects, through content, policies, and improvements to the MediaWiki software. For now, the main possibility is sounds, but videos may become more common shortly, so they should be borne in mind in any strategy we come up with.

The problem

The MediaWiki software currently include very good support for handling static images, with the increasingly flexible extended image syntax treating these as far more than just "uploaded files". However, these features do not fit well with the needs of other multimedia content, such as sounds or videos. These currently get a description page called Image:<name>, and the only special syntax is the Media: convention for bypassing that description. This does not encourage the wider use of such content, which is a shame.

Additionally, Wikimedia only allows the use of open formats, such as Ogg Vorbis, because this best fits with the general aim of allowing access to all, by preventing lock-in from proprietary standards like MP3. However, the Ogg format is often not supported by users' existing sound software, making it important that we explain to our users and contributors what they need to create and play back these files. Most people are accustomed to, and probably already have, facilities for MP3 playback and recording, but have never heard of Ogg Vorbis.

Changes in the way sounds (and other multimedia) are presented to the community need to go hand in hand with software developments.

In Wiktionary, one of the objectives is to inform about the pronounciation of words and phrases; this will result in thousands of small sound files. As every wiktionary may have eventually all words in all languages, the only logical place to have these sound files is in one central place: the Commons. Currently we can not access sound from the Commons.

Format policy

The policy to encourage Ogg Vorbis exclusively is, of course, not set in stone; nor has it been determined that this approach should be emulated in selecting video formats. There are advantages and disadvantages:

• Arguably, the use of any single format inevitably produces articles which are not neutral but which instead endorse only the single selected format.
  • This could be seen, however, as equivalent to our licensing exclusively under the GFDL - we are actively encouraging this form of licensing, but through our actions not our content.
  • Alternatively, the support for a particular type of sound could be seen as part of the infrastructure of the site, and not the content; it is not controversial, for instance, to "only offer HTML" - as long as we stick to standards-compliant usage that doesn't deliberately favour or disfavour any browser.
• Why isn't the sound offered in all widely used formats, so it is available to all without any need to explain it? We aren't going to be gone in ten years, so lossless contribution formats which can be delivered in all widely supported download formats, including new formats not yet developed, best achieve our goal of providing the content.
  • Since lossy<->lossy conversion leads to further and further loss of quality, this would require uploads to be in some lossless format.
    • PCM wave (.wav) is the normal format for uncompressed sound. Is this commonly supported on all platforms? Is it really all that standard? (any automated converter would need to cope with all possible variations on the format, such as bit-rates, float vs int, etc)
    • lossless compression codecs (e.g. FLAC, which is free) are generally even less well-known and well-supported than Ogg, so this may potentially create more difficulties for those uploading sounds. Yet, they're lots smaller, and that saves bandwidth.
  • Automated conversion would be both expensive in terms of CPU time (for the actual conversion) and hard-disk space (to cache the results of the conversion, which would be multiple encodings of every sound)
  • A tool which was able to create the most popular formats (e.g. for sound: MP3, WMA, RealAudio, QuickTime) would require licences from the relevant companies (Fraunhoffer, Microsoft, RealNetworks, Apple); most popular video formats are similarly restricted by licence (e.g. the popular "DivX" codec for MPEG-4 video)
    • Theora is a free format which isn't encumbered by this problems.
• Jimbo Wales, the project's founder, is among those who support our encouraging open formats for our content, on the grounds that this encourages the wider freedoms such formats grant (Free Software, etc). He states that for him "The gold standard is whether I can use a format with free software." [1]
• In order to avoid people uploading files in weird (like TIFF) or legaly encumbered (like MP3), a method to only allow uploads of files in authorized formats (like PNG or Vorbis could be implemented.

Sound help pages

One of the first things we can do is to create standard, easy-to-understand help pages which can be referred to every time a sound is included. Similar pages for videos can follow, but videos are so far less common, and policy is needed first. Ultimately, it would be nice if these help pages were linked to automatically, but for now they can just be encouraged by policy on individual projects.

• Some existing attempts at such pages: w:en:Wikipedia:Sound; wikt:nl:WikiWoordenboek:Geluid

Using two help pages would allow us to separate out two "use cases":

1. A reader comes across a sound, and is unable to play it; they don't need lecturing in why we do what we do, just pointing to appropriate software for their system.
2. An editor wishes to contribute sounds to a project, but doesn't know how they should do it; they need to have policies explained to them, including what format to use; they also need pointers to software, in order to create/convert their sounds for uploading in the appropriate format.

For an example of what each of these might look like, see /Help:Listening to sounds and /Help:Adding sounds

Issues

• How will this fit in with video, and any other kinds of multimedia we decide to encourage next?
  • Perhaps have similar help files for each, and have any automatic or manual inclusions point to the right one.

Evangelism

• In a mailing list post, Pete/Pcb21 suggested that we could:

  "Provide a mechanism for users to give feedback. "Can't play OGG?. Can't download the plugin? Please let us know where you are trying to access Wikipedia from (home/school/college/etc)" We could then even have a standard form letter to send to sysadmins of the school/college in question."

Software features

Play "Example.ogg" (info) (help)

Insert brief caption here.

• We need to promote other media to the same level of support as images: [[Sound:Foo]] or [[AV:Foo]] needs to render with appropriate formatting, not just be a link - just like [[Image:Foo]] already does.
  • The help page could be automatically linked from this generated formatting.
  • The result might look something like that to the right.
  • Similar could just be achieved using a template (as demonstrated by the simplicity of creating this mockup), but in the long-term it would be nice if this was a fully-configurable feature.

"wiki-player"

• One of the things that has come up in discussions is the possibility of offering our own player, or plugin. This could mean not only offering a local download, but actually supporting it as though it was part of the site.

Plugins

• Another thing to consider is embedding markup for a plugin where a sound is included in a page, so that the user can play the sound within the same window.
  • This would need to be an opt-in preference, with a fall-back of just a formatted link to the file, as above.
  • We could insert markup for one of multiple plugins (quicktime, realplayer, etc) based on user preferences.
    • This would be technically complex, and would imply support for all those plugins, creating yet more work.
  • Alternatively, we could build our own wiki-player plugin, and just have optional support for embedding that.
  • Plugins for IE often require clicking yes to a security warning about ActiveX controls. That's a bad idea. The equivalent of linking to the file doesn't have that "train to make poor choices" problem and also makes it easy to save the file rather than continually playing it from Wikimedia servers and using more bandwidth which donors must pay for.

Video policy

We don't seem to have one. We should.

• What format should we recommend?
  • Having one standard format makes creating help pages much easier.
  • As with sounds, we'll want to support a format that is as free as possible.
    • We'll want to support the most widely used formats if the idea is to deliver things people can use.
• We should not favor any formats. Neutrality is key to our success and any endorsement of a single format makes all articles featuring only that format non-neutral.