Pages

20 October 2009

The way we should manage video

For some time now I've been talking about this idea on how an organisation should handle video (or all media it produces for that matter), I think I may have blogged it before - I know I tried to use the Heywire 8 meeting as a venue to bring it forward, and I had high hopes that NZ Telecom would show interest, or that Digital NZ would make it possible, but I haven't heard anything back from any of them. Perhaps those secretive Kiwis are forging ahead without me.. just like they did to some poor old Australian with the pavlova.

Recently my colleagues as University of Canberra have asked me to write the idea up in a one pager for use in a proposal. If you have any pointers on the idea, please comment in a link.

The way we should manage video

Someone wanting to upload a video at UC goes to the UC website and clicks upload. The select the file they wish to upload and then go through an extensive list of servers to send that file to. (UC website, Moodle, National Archives, Youtube, Internet Archive, Blip.tv, Facebook.. add their own server). When they click upload the file is pushed across the selected platform carrying with it a link to UC, and when finished they receive an email with a summary of file locations and embed codes. They use whichever one they like in their own sites, or leave it at that. The point of this is getting content out across the Internet in ways that suite the preferences of both the individual publishers and the viewers, as well as establishing a strong UC presence across popular media platforms. This is also a good form of backup, especially considering the addition of the Internet Archive and the National Archives.

A free web service that does most of this already exists at http://tubemogul.com. The thing that is needed on such a service however, is the ability to add other servers.

Given that most organisations use a Proxy server to manage Internet use, it is possible to use this file distribution idea to manage bandwidth use. For example, if someone on campus requests a file it is delivered from campus servers. If the request is from off campus somewhere, then the file is delivered from off campus servers thus saving UC outgoing and incoming data costs.

2 comments:

Web casting, or broadcasting over the internet, is a media file (audio-video mostly) distributed over the internet using streaming media technology. Streaming implies media played as a continuous stream and received real time by the browser (end user). Streaming technology enables a single content source to be distributed to many simultaneous viewers. Streaming video bandwidth is typically calculated in gigabytes of data transferred. It is important to estimate how many viewers you can reach, for example in a live webcast, given your bandwidth constraints or conversely, if you are expecting a certain audience size, what bandwidth resources you need to deploy.

To estimate how many viewers you can reach during a webcast, consider some parlance:One viewer: 1 click of a video player button at one location logged onOne viewer hour: 1 viewer connected for 1 hour100 viewer hours: 100 viewers connected for 1 hour…

Typically webcasts will be offered at different bit rates or quality levels corresponding to different user’s internet connection speeds. Bit rate implies the rate at which bits (basic data units) are transferred. It denotes how much data is transmitted in a given amount of time. (bps / Kbps / Mbps…). Quality improves as more bits are used for each second of the playback. Video of 3000 Kbps will look better than one of say 1000Kbps. This is just like quality of a image is represented in resolution, for video (or audio) it is measured by the bit rate.