video metadata & distribution
by: Jamie King (jamie at jamie.com), Jan Gerber (j at thing.net)
A current concern for many video producers is how to better share and distribute materials, both to reach wider audiences and to facilitate better cooperation and learning. Huge increases in the speed of consumer-grade bandwidth and disk storage space, as well as innovations in distribution software, mean that distributing video online is now a viable option.
As the success of proprietary services like YouTube Revver and Vimeo show, there is now a strong online demand for video content so that it can be easily accessed and exchanged online (see Recommendations, below).
In producing these recommendations, we took into account certain guiding principles. Our framework has to be:
• as easy as possible to understand and implement for video producers and distributors,
• applicable to as many different kinds of content as possible without being unwieldy, and
• workable in the real world.
We were aware of a few other initiatives in this area, and took pains to review their work and not to duplicate it unnecessarily.
Our recommendations attempt to choose from what we see as the best of others’ systems. We do not offer them as a fait accompli but as an object for further discussion.
‘RSS’ has become a catch-all term for a variety of ways of marking-up content in a semi-standardized format that can be viewed and organised through client software. Programs called feed readers or aggregators can check a list of feeds and display updated items that they find. Such readers are available for various operating systems, typically as stand-alone programs or extensions to existing programs such as web browsers. Many browsers have integrated support for RSS feeds.
However, RSS is not as unified a standard as its single name would suggest. In fact, as Mark Pilgrim explains:
there are actually nine incompatible versions of RSS, all of which are incompatible with various other versions. RSS 0.90 is incompatible with Netscape’s RSS 0.91, Netscape’s RSS 0.91 is incompatible with Userland’s RSS 0.91, Netscape’s RSS 0.91 is incompatible with RSS 1.0, Userland’s RSS 0.91 is incompatible with RSS 0.92, RSS 0.92 is incompatible with RSS 0.93, RSS 0.93 is incompatible with RSS 0.94, RSS 0.94 is incompatible with RSS 2.0,
and RSS 2.0 is incompatible with itself. See 'The Myth of RSS Compatibility'
The potential for confusion caused by different versions — none of which has a standardised schema — is obvious. There are a profusion of attributes and elements available across RSS versions. Given the necessity of producing a simple, comprehensible schema for marking up video metadata, this is a serious issue for us.
What is more, RSS 2.0 is copyright its creators and may not, according to this license, be modified. We know that the sort of communities developing and working with this standard will see this as a key detractor, since many of us hold with Free/Libre and Open processes. Ethical qualms aside, it also raises a substantial pragmatic concern. Since this process is precisely involved in developing an open standard for video metadata, working with a closed standard is illogical.3
The Atom syndication format was specifically designed to address the general incoherence of RSS. As Robert Sayre writes:
early syndication and publishing protocols faced various problems related to interoperability, scalability, and extensibility. The Atom format and protocol builds on earlier efforts to establish an open, extensible, interoperable, and clearly specified framework for Web-logging applications. Atom has already been deployed on a wide variety of platforms. By closely examining previous syndication formats and protocols, the Atompub working group has been able to ‘pave the footpaths’, and design a standard built around well-known and proven usage patterns. Robert Sayre, ‘Atom: The Standard in Syndication’, IEEE Internet Computing, vol. 9, no. 2, 2005, pp. 71-78.
In our considerations, we have to weigh on the one hand the fact that RSS is confusing and unstandardised. If RSS is chosen, then which version of RSS should you use? RSS 0.9x, RSS 1.x, or RSS 2.0? Which RSS extensions and non-RSS namespaces should you use, if any? On the other hand, if Atom is selected, are there sufficient tools available that support
it? Despite the emergence of Atom as an IETF Proposed Standard and the decision by major companies such as Google to embrace it, use of the older and more widely known RSS 1.0 and RSS 2.0 formats has continued. Many sites choose to publish their feeds in only a single format. For example CNN, the New York Times, and the BBC offer their web feeds only in RSS 2.0 format.
Because the Atom standard looks toward a future in which it will be adopted by a community of video producers, we suggest that the community seriously consider adopting it for encoding its metadata. This may seem controversial, especially bearing in mind our ‘real world’ principle. However, on balance, the case for adopting Atom over RSS is fairly strong. While recognise the shortcomings of Atom: while each of the various web syndication feed formats has attracted enthusiastic advocates convinced of the capabilities of their respective formats, no one would dispute that RSS predominates. But in mitigation, given most video producers do not currently mark up their content in any coherent fashion, if Atom is the best way to create a rigorous, clear and consistent framework for marking up video metadata, we think it should be used.
The following table may help in any considerations on this topic.
|| RSS 2.0
|| Atom 1.0
|| Copyrighted by Harvard University. Intentionally frozen.
|| Is a recognised, open and evolvable IETF Standard (RFC 4287) standard that has undergone the IETF standardization process
|| Connection to existing XML standards and RFCs is not well-defined
|| has clearly defined relationships to other XML standards (Namespaces in XML, XML Base, XML Encryption, XML Digital Signatures, and XML 1.0 itself) and several RFCs
|| Numerous feeds
|| Limited but growing number of feeds
| Client Software
|| Less prevalent but growing rapidly, with other supporters announced
| Publishing Protocols
|| MetaWeblog and Blogger; frequent reports of interoperability problems and feature shortcomings.
|| Atom Publishing Protocol leverages HTTP and REST; authentication may be required for any or all operations; implementation free so available for all platforms; IETF standardization process
|| specification includes no standard schema so elements and attributes vary considerably across different RSS versions.
|| specification includes a (non-normative) ISOStandard RelaxNG schema
| Required Content
|| requires feed-level (channel) title, link, and description, but does not require that any of the fields of individual items in a feed be present.
|| requires that both feeds and entries include a title (which may be empty), a unique identifier, and a last-updated timestamp; more reliable for distinguishing duplicate feeds
| HTML or XML ‘Payload’
|| may contain either plain text or escaped HTML, but with no way to indicate which;
cannot contain actual well-formed XML markup that we need here.
| may either directly contain or link to a payload consisting of: plain text, with no markup (the default) escaped HTML, as is commonly used with RSS 2.0, well-formed, displayable XML
| Full or Partial Content
|| Description element may be complete text, summary, or absent
|| clear distinction between summary and content
| Autodiscovery of Feed
|| non-standard implementation
|| optional self pointer, so a newsreader can autosubscribe given only the contents of the feed
| Namespaces and Extensibility
|| no RSS namespace; numerous extensions, but no central place to discover extensions from various XML namespaces
|| Atom is in an XML namespace and may contain elements or attributes from other XML
namespaces. If in future we wish to experiment with further taxonomic classification (e.g. Dublin Core) this is useful.
|| No specific provision. RSS 2.0 can be encrypted or signed like any other web
| Atom 1.0 specification includes rules for applying standard XML Encryption and XML Digital Signature to entries; alternatively, the feed can be encrypted or signed, like RSS 2.0, as a bag of bits
| Other Security Considerations
|| No specific provision.
|| Specifically addressed by RFC 4287 in Section 8 (HTML and XHTML content, spoofing,URI/IRI, etc.)
| Creator Identification
|| used inconsistently in practice, so not reliable; provides the ability to specify email
addresses for a feeds <managingEditor> and <webMaster>, and for items <author>; some
publishers prefer not to share email addresses, and use <dc:creator> from the Dublin Core extension instead.
| Provides <author> and <contributor> elements at both the feed and entry level (to describe a person, corporation, or similar entity) with one required child element, <name>, and two optional elements: <uri> and <email>.
Video Metadata Fields
What follows is the ‘core’ of this report, which is a list of the fields that we consider useful or necessary in marking up video files so that they can be easily shared and discovered. We express these fields in plain language, offer a description, and our assessment of whether it is ‘required’ or not. (‘Required’ here is merely technically normative, in that it indicates specifically fields without which the schema will ‘break’, that is, will not have the core functionality we need.)
Videos are published in a ‘feed’, which is a collection of video items. Each feed carries metadata, which are data (information) about the videos themselves.
|| The name of the channel, e.g., ‘Activist Central’
|| A short description of the channel, e.g., ‘For everything
that’s new and hip in the world of the activist.’
| Link To Site
|| The URL to the website on which the channel is based
| Publication Date
|| The date this feed was last updated
|| Who (which group or person) published this feed
| Link to self
|| The feed knows at which internet location it lives.
|| A representative icon for the channel.
|| Language or dialect of the item.
The metadata for each Video is composed of the following fields.
FIELD DESCRIPTION REQUIRED
Title Title of video YES
Description A short plain- language description of the video. YES
Link Link to a web page about this video YES
Video Link A direct link to the downloadable file, via HTTP,
BitTorrent or other, as new protocols emerge.
There can be more than one video link per entry
Publication Date Date on which the item was first published YES
Author Author of the video YES
License e.g. Creative Commons Share-alike. NO
Length Hours, minutes, seconds NO
Video Format Technical information about video, e.g.,
codec, bitrate, framerate, width, height
Audio Format Technical information about audio, e.g.,
codec. bitrate, samplerate, channels
Date of Creation year/date the video was made NO
Country country or countries of production NO
Thumbnail a still or animated image from the video NO.
Subtitles link to subtitle, includes language attribute
There can be more than one subtitle link per
Keywords A set of keywords that provide a pithy
description of the item.
Credits Roles like producer, director, etc. NO
Documentary, Fiction, Cartoon, etc.
if possible base it on http://imdb.com/Sections/
| License e.g. Creative Commons Share-alike.
|| Brief human readable summary and a link to the longer license.
How This Would Look
Those horrified by code should look away now. This example is a modified version of one that appears in RFC 4287.
<?xml version="1.0" ?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:media="http://search.yahoo.com/mrss/">
<link href="http://example.org/atom.xml" rel="self"/>
<title>Atom-Powered Robots Run Amok</title>
<link href="http://example.org/2003/12/13/atom03" rel="alternate"/>
<link href="http://example.org/video/ph34r_my_podcast.ogg" length="1337" rel="enclosure" type="application/ogg"/>
<media:thumbnail height="54" url="http://example.org/video/newscast-2006-10-11.fr.jpg" width="72"/>
<link href="http://example.org/video/newscast-2006-10-11.fr.srt" hreflang="fr" length="1337" rel="enclosure" type="text/plain"/>
<link href="http://example.org/video/newscast-2006-10-11.de.srt" hreflang="de" length="1337" rel="enclosure" type="text/plain"/>
Possible Entry Elements Described in Detail
Identifies the entry using a universally unique and permanent URI. Two entries in a feed
can have the same value for ID if they
represent the same entry at different points in time.
Contains a human readable title for the entry. This value should not be blank.
<title>Atom-Powered Robots Run Amok</title>
Videos are linked to with a special relation called an ‘enclosure’, and a type that for video material.
<link rel="enclosure" type="application/ogg" length="1337" href="http://example.org/video/newscast-2006-10-11.ogg"/>
Indicates the last time the entry was modified in a significant way. This value need not change after a typo is fixed, only after
a substantial modification. Generally, different entries in a feed will have different updated timestamps.
Names one author of the entry. An entry may have multiple authors. An entry must contain at least one author element unless there is an author element in the enclosing feed, or there is an author element in the enclosed source element.
Identifies a related Web page.
<link rel=”alternate” href="http://example.com/blog/1234"/>
Conveys a short summary, abstract, or excerpt of the entry. Summary should be provided if there either is no content provided for the entry
Subtitles are actually another enclosure link, the language of the subtitle should be specified with the hreflang attribute.
<link rel="enclosure" type="text/plain" length="1337" hreflang="fr" href="http://example.org/video/newscast-2006-10-11.fr.srt"/>
This is a still of the video.
<media:thumbnail url="http://example.org/video/newscast-2006-10-11.fr.jpg" width="72" height="54" />
Highly relevant keywords describing the media object with typically a maximum of ten words. The keywords and phrases should be comma delimited
<media:keywords>kitty, cat, big dog, yarn, fluffy</media:keywords>
Notable entity and the contribution to the creation of the media object. Current entities can include people, companies, locations, etc. Specific entities can have multiple roles, and several entities can have the same role. These should appear as distinct <media:credit> elements. It has 2 optional attributes.
<media:credit role="producer" scheme="urn:ebu">entity name</media:credit>
Conveys information about rights, e.g. copyrights, held in and over the entry. This consists of two parts, a link to the license used and a text field with a short form.
<link rel="license" type="application/rdf+xml" href="http://creativecommons.org/licenses/by-sa/2.5/rdf" />
Copyright (c) 2005. Some rights reserved. This feed is licensed under a Creative Commons Attribution-ShareAlike 2.5
Use License. It contains material originally published by Jane Smith at http://www.example.com/entries/1 under the Creative Commons Attribute License.
Links with further details
More information about the Atom: http://atomenabled.org/developers/syndication/
All elements with media prefix are described in more detail at http://search.yahoo.com/mrss
More on Item Keywords
In our discussions we considered in some detail schemas like that broadly fall under the term ‘Semantic Web’. We do not think that it is worth attempting to engage the ongoing attempts to create a stringent taxonomy for content. We think this is
better left to academic groups that have no immediate necessity to make their schema work in the real world. Adopting Atom we would later be able to inter-operate with such a content schema if that later became something we wanted.
The approach we take to classification is ‘folksonomic’. Roughly put, this involves producers selecting their own descriptive keywords (‘tags’)according a methodology they themselves define. In many systems (e.g. Flickr, Del.icio.us), users are able to see what kinds of tags other users have adopted as they enter their own, or to select from lists of popular tags. This creates some casual normativity without being overbearingly stringent. Of course there is a danger of users mis-classifying their content, but adhering to a more stringent framework doesn’t prevent this and only increases the onerousness of marking up video. We think onerousness is to be avoided. It will scare off potential collaborators.
We also think that given the fields above, a short description and these tags, most of our needs – in terms of discovering and sharing video – will be well met. Imagining that we have 20 groups that are consistently marking and publishing their video content with the fields outlined above in the Atom format, we could then bring together these feeds into new resources. We can sort by tag, creator, date, genre and so forth. We can imagine third party re-aggregating applications working rather well with these data.
Examples & Projects
Democracy and ‘Broadcast Machine’
The Democracy video platform already makes use of RSS feeds, which it terms 'Channels', to bring videos from publishers to users. Democracy offers a channel publishing tool called Broadcast Machine which generates feeds in a format that uses RSS 2.0 with the Yahoo Media extension and the Universal Subscription Mechanism.
According to the project managers, the decision to use RSS 2.0 was made because it allows the presentation of ‘rich metadata’ along with the associated video file. (We think it was also made because RSS is so popular.) RSS items corresponds to a single video item.
Fig 1, A ‘channel’ produced by Broadcast Machine viewed through Democracy Player.
Here, viewed through Democracy Player, we see how a feed that has been marked up with Broadcast Machine looks. There is a channel name (‘Reality Hacks’), item name (e.g., ‘No House! No Land! No Vote!’), item description (e.g., ‘Voices from the housing struggle’), thumbnail, date of publication, video format (e.g. MSVIDEO), file size, and a link to the
file. While the specification we describe here contains more information and will have greater utility, we can see the advantage here of marking up metadata about video in a consistent way. The Democracy project achieves a consistent ‘channel’ without levying any control over its contributors’ feeds. Equally, contributors benefit from having their video discoverable away from their sites in modes and context that they may not even have considered.
In composing this document, we looked at some of the sites of groups we were told to consider stakeholders in this process. This brief review indicated that there are still some considerable hurdles to jump before this community would be as a whole in a position to implement a standard such as the one discussed here.
For example, some sites use proprietary Windows Media streams, or other streams that does not actually allows users to download the video they want to see. This effectively prevents them from being used for syndication. Many sites do not currently produce any kind of feed at all about the videos they offer. What this indicates to us is that, as well as considering formal metadata requirements, we also need to discuss together
‘information culture’ within video producing and distributing groups -- from the formats used to encode video for consumption by users, to practices of openness, to basic modes of internet distribution such as HTTP and Bittorrent. Such requirements were ‘beneath the scope’ of the document here but we believe they are essential if we are to meet our aims
The recommendations here were created for discussion purposes. If we can agree ultimately on the best route to take, we can collaborate with or produce extensions for video content management systems enabling co-operating parties to markup their video according to our specifications easily and simply.
The benefits of this to all of us are immense. We will be able to create, subscribe to, and recombine feeds of each others’ video material and display the results on our own pages or wherever we like. Viewers will be able to find their way to our content much more easily, from unexpected constituencies.
It is important, above all, that a system be designed that is useable for all concerned, since what breeds success (adoption) in this area is usage. Many schemas have withered after lack of adoption due to being too esoteric, and hence not building grassroots support. We would like to begin at the grassroots and that is is why we seek your input and support at this stage.
Yahoo Media Extension
Universal Feed Parser