Create a book


From Steeple

Jump to: navigation, search

Read our Blog - we're posting thoughts, ideas and notes right there, and we want you to give us your feedback.


[edit] 1 Lecture Capture at Oxford, Revisited

23 January 2012, by

<p>Those with a long memory will recall the work I posted about during September 2009 (see <a href=""></a>) where I discussed what we were doing within <a href="">OUCS</a> at <a href="">Oxford</a> to test various forms of lecture capture, and technologies to support that.

Since that point, quite a bit has changed. With a focus on our largest teaching space (<a href="">Isis</a>): 

  • We've gone through a few different recording / capture methods and technologies
  • New AV control system fitted
  • New Audio mixer and setup
  • New projectors and SMART board

Picking up on these points in reverse order...

2 New Projectors & SMART board

With the previous Epson projectors coming to the end of their working lives, a new set of three projectors was selected. A review by the <a href="">ITLP</a> team at OUCS led to the <a href="">Epson EB-450W</a> short-throw, widescreen models being selected. This allowed us to provide larger images on the wall for the more common 16:9 / 16:10 display formats favoured by modern monitors and laptops. So far we've been very pleased with both the brightness, contrast, clarity, and general operation of these new displays, and being able to hide two of them in the ceiling improves the appearence of the room (and reduces noise - something these projectors are fairly quiet about in the first place).

As an added bonus, these projectors support video display via Ethernet, so in the future it will be possible for us to send video data to them over the network connections. In the meantime, we're sticking with the analogue video cabling we already have kit installed for. The move to a more complete, modern, digital video setup is a long conversation for another time.

The SMARTboard is an upgrade to the previous model that has been in place for the past 5 years, and introduces both multitouch sensing, and a brighter, widescreen format. The surface is now a more solid metalic one, meaning it feels more robust to the touch, and is essentially a result of a change in the sensing methods used by the board (IR Laser, I believe). Combined with a short throw projector, this allows a presenter to use the board without being dazzled on turning towards the audience, and means there is very little shadow being cast whilst in use and thus less obscuring of content, making it easier to write/draw on the correct area.

<a href=""><img alt="Img_0148" height="666.666666666667" src="" width="500" /></a> <a href=""><img alt="Img_0150" height="375" src="" width="500" /></a> <a href=""><img alt="Img_0151" height="375" src="" width="500" /></a>

<a href="">See the full gallery on Posterous</a>

3 New Audio Mixer and setup

One problem we faced for a while was that our rack mountable audio mixer had a slight fault (or perhaps deliberate design fault from its initial installation 6 years ago, it's hard to say) in that of the two "zones" for output, one of them did not contain the microphone feeds. The zone that fed the room audio speakers (and had the volume remote controlled via the AMX panel) featured all the microphone inputs and the selected stereo audio from the VGA matrix, but the second zone only outputted the audio from the VGA matrix. As we specifically wanted a set audio level for recording, taking a feed from the room audio wasn't really a good option, so we looked to replace the mixer as funding allowed. One issue with replacing the mixer was it's ability to accept remote control inputs - however, when the AMX control system failed (more below), this became a moot point for a while.

All of our other rooms feature a completely mixed audio stream to the room speakers, and the setup in place here had the audio being selected via the Extron VGA AV matrix, so users were occasionally surprised when they couldn't hear their movie/audio playing when they could see it on screen (a result of the way and order in which inputs and outputs were selected). A quick bit of research and some hasty shopping netted us an <a href="">Allen and Heath ZED14</a> desktop mixer, whose key attributes were having enough input channels to support the range of inputs Isis uses, and a USB audio interface (allowing for a digital link to a computer, nominally for recording purposes). 

Whilst the room audio is only mono, the two output channels for recording (see below) were both in stereo, and the Mac Mini being used for screen capture was able to use the USB audio connection - though not without a few flaws: the cable would often need to be unplugged and reconnected or the system restarted after a few days, otherwise the audio device "disappeared".

The other drawback that needed resolving was the lack of a remote control for room audio... but more on that later.

<a href=""><img alt="Img_0132" height="375" src="" width="500" /></a> <a href=""><img alt="Img_0158" height="163" src="" width="500" /></a> <a href=""><img alt="Img_0159" height="171" src="" width="500" /></a>

<a href="">See the full gallery on Posterous</a>

4 New AV Control System

Due to a failure in our 6 year old AMX Control system within the past few months, we were faced with a either a huge repair bill, or to replace the AMX setup with an equivalent for less cost. Our top tip, if you have a control system installed, make sure you get a copy of all the code and SDKs needed to be able to configure the setup yourself at a later date! This is something that has been a perenial problem with the AMX and one of the factors that caused us to select Extron as the replacement solution. 

A review of our previous setup led us to rationalise a few elements: the DVD / VHS player was deemed redundant, and could be removed; The auxiallry composite video inputs couldn't be located, so were presumed legacy and irrelvant; this left just one of the ceiling cameras with a feed to the front desk, and thefore the AV matrix that had been supporting these items could also be removed.

This left the Lutron lighting system, Elmo ceiling camera and the Extron VGA 4x4 matrix requiring RS232 control signals, and the three Epson projectors wanting ethernet based control signals. 

Our missing component was a means of controlling the room audio levels from outside of the AV cupboard, so a small Extron Audio mixer was also added to the mix (*groan*) allowing us to vary the feed from the ZED14 to the room Amplifier, and which was also controlled via an RS232 connection. 

Extron happen to have a (very small!) control box that supports 4 RS232 connections and up to 6 "virtual" ethernet devices, and we combined that with their <a href="">TLP 350mv</a> 3.5" touchpanel to complete our new setup. One feature we like is that this approach is modular, and that we can upgrade parts of this setup over time, and reuse pieces in other rooms - so a larger touchpanel may be on the shopping list in the future.

The software for configuring their systems is free and fairly straightforward to use, if incredibly tedious. Top tip: Remember that you are not programming these systems, you are configuring! It's akin to the difference between programming a video recorder to do scheduled recordings and writing an application to generate a calendar from multiple sources and then having your computer capture a video stream... One involves logic and code, the former requires a lot of button pressing.

Basic process is to use one application to design the GUI (can draw it all from scratch, or use a provided template), and then another to assign tasklists to each element of the GUI (e.g. turn projector on, set computer input, select matrix input 1, output 3, take video, unmute the audio, dim the lights... etc). To do this from scratch for Isis with a small amount of training beforehand took about 3 days to get to a workable setup (and having done initial testing and changes based on feedback from the teachers). Experience in Extron configuration would have halved this time, and it's ability to deploy the setups to multiple locations means you can easily manage multiple rooms via this setup (something we'll investigate at a later date).

Our setup is now in it's first extended test (i.e. how does it fare over a term's use), and we have a small list of things to tweak for our next period of downtime. So far it handles room lighting controls, audio (variable volume and an all out mute), camera positioning, and video input and output selections. We have hopes that a virtual remote control setup can be enabled via a web interface, but that is for another time (the basics are there and come as standard with the Extron setup).

<a href=""><img alt="Img_0161" height="475" src="" width="500" /></a> <a href=""><img alt="Img_0135" height="375" src="" width="500" /></a> <a href=""><img alt="Img_0164" height="375" src="" width="500" /></a> <a href=""><img alt="Img_0166" height="375" src="" width="500" /></a> <a href=""><img alt="Img_0167" height="375" src="" width="500" /></a> <a href=""><img alt="Img_0168" height="375" src="" width="500" /></a>

<a href="">See the full gallery on Posterous</a>

5 Changes to recording methods and technologies

In short...

  • We've dropped Podcast Producer as service to support our podcasting and lecture capture activities (problems with reliability of capture being among the reasons).
  • The Epiphan VGA2USB devices don't support capture in Quicktime X on 10.6 (Snow Leopard) ^1. 
  • Trying to use free alternatives to Quicktime in order to do screencapture has resulted in an 80% success ratio and requires a fair degree of technical skill to get into the systems, and set the recordings going - so not one touch and user-friendly. We also didn't find a paid-for application that suggested it would do any better (or that didn't rely on Quicktime).
  • The Elmo ceiling cameras^2 installed in the room are not suited to the low lighting levels typically used for presentations, and their 640x480 images aren't exactly detailed or sharp enough for our uses. Also, contrast problems caused by having a flat room and presenters moving in front of display areas, means they struggle to adjust for bright backgrounds and darker surroundings. So we've stopped trying to capture this input.
  • We have decided that for occasions when a person or room activity needs to be captured on video, this is best done using a portable video camera. To aide that, we've extended a stereo audio output feed to the back of the room that can be plugged into the camera (or into a digital audio recorder for those occasions when we want a backup to the AV kit up front).
  • With a focus on screen and audio capture, we are trialling an <a href="">Epiphan VGARecorder Lite</a> unit...

Things we like about the VGARecorder include it being an all in one device, small (and thus easy to fit into small cabinet spaces), firmware based with a web interface, supports streaming, can capture over a day's worth of video to its internal (flash) memory and can automatically upload recordings^3 to a remote storage system.

Things we don't like so far are the cost (a mac mini + VGA2USB + composite video capture card is cheaper, let alone a Matterhorn style capture box), that the web interface is rather clunky, slow and confusing (settings one page can have unanticipated results elsewhere, and you're almost forever hunting for the right section to change something related to another aspect), it's slow to reboot and start up (several minutes - rather odd for a flash based system I think), and that it doesn't appear to adapt to different resolutions in terms of adjusting the output recording size (this is still being investigated, but it's a one output size has to fit all approach apparentely).

<a href=""><img alt="Img_0133" height="375" src="" width="500" /></a> <a href=""><img alt="Img_0154" height="370" src="" width="500" /></a> <a href=""><img alt="Img_0170" height="390" src="" width="500" /></a> <a href=""><img alt="Img_0171" height="401" src="" width="500" /></a> <a href=""><img alt="Img_0172" height="234" src="" width="500" /></a> <a href=""><img alt="Img_0169" height="375" src="" width="500" /></a>

<a href="">See the full gallery on Posterous</a>

However, that all said, the device has only been in place for the past week, so we're going to do a more thorough test of it during the coming term. Given we are hosting the <a href="">Matterhorn Unconference</a> in a couple of weeks, and the <a href="">Galicaster</a> setup will be on demo too, it will be interesting to see how it compares and fares.

As always, feedback appreciated, especially on your own setups and experiences, and don't forget the Steeple mailing list is a good place to talk about these things too.



^1) After some protracted back and forth with Epiphan's email support, we discovered their marketing claim for Quicktime is misleading - they support Quicktime 7 in 32bit mode (so 10.5 effectively), and Quicktime X in 64bit mode on 10.7, but have given up on creating a driver for 10.6. This is unfortunate, as we've found Quicktime 7 to be unstable (crashes very easily) on 10.6, and we're not in favour of putting 10.7 on these Mac Minis yet (mostly due to licencing and installation issues, and a lack of support in general).

^2) There are two cameras installed in the room, but only one has wiring that goes to the main AV cupboard, thus the second camera (which is in a less useful location) has been left to languish as it too suffers from the problems of the more central one (contrast and clarity).

^3) User beware again here. An undocumented bug in the current firmware (2.2.2b) means that using the ARU (automatic recording upload) function with a user password containing symbols is likely to cause it to fail without an clear warnings. Fail on the uploading that is, the rest carries on fine. Simplifying your password to contain just alphanumerics works around this, but won't impress some institutional password policies.


<a href="">Permalink</a> | <a href="">Leave a comment  »</a>

[edit] 6 AV workflow in the University of Reading

5 October 2011, by

<p>by Dr David Wong

The workflow provides for an end-to-end solution where users submit their audio / video file on a university web page, and after a few minutes receive an email containining instruction on how to link the transcoded media file on their web page.

The systems components consist of:

  1. Workflow server (Ubuntu), provdes a platform for NSSDropbox 2 (from University of Delaware).
  2. A modified version of NSSDropbox 2 using LDAP security, provides upload facility (2.0GB limit per file). Each submission causes an email sent to a designated email account
  3. Script (Perl) in workflow server scans email account for new message,  extracts uploaded file out of NSSDropbox's internal storage, writes it to a designated directory, emails administrator a notification of the upload, and emails the user instruction on how to link the transcoded files from their web page
  4. Mac OS XServe, running Episode Engine, scans the designated directory regularly for new files, does transcoding, and writes transcoded files to an output directory
  5. The output directory is mounted on a web server, making the files available on the web
  6. Templates in University CMS, and VLE (Blackboard), enable end users to link the transcoded files from their web page
  7. JW Player

File formats:

  • Audio: accept mp3, wav and wma, and output to mp3
  • Video: accept mpg, mp4, avi, and output to mp4 h264 AVC (Levels 1.2 and 3), and AAC audio encoding. Some success with other input formats wmv, tod, mod etc.

7 Advantages

  1. Episode Engine's preset formats and workflows transcode files that conform to h264 standards.
  2. JW Player provides for a large number of platforms.
  3. Very low load on servers. 
  4. Apart from staff costs, main expenditures are XServe and Episode Engine.
  5. Multiple workflows based on media type or requirements (e.g. teaching and learning, audio only, video).

8 Issues

  1. Episode Engine is not easy to use, nor flexible; its warning and error messages can be confusing and far from instructional. In cases where it is stuck with a job that's difficult to transcode, it could hang and requires intervention by aborting the job. It's possible to modify / create workflows which requires root access, and I didn't pursue that.
  2. Episode Engine strips out metadata contained in file.
  3. Workflow server (running NSSDropbox 2) is inside the firewall to minimise security issues. Off-campus users can upload if they log in using VPN.
  4. Not really an issue, but for people new to Perl and scripting (or those thinking about implementing NSSDropbox 2), we did spend a lot of time (weeks) modifying NSSDropbox 2 code, adding extra bits (and removing/disabling others), and hours of testing. And time spent learning Perl.

9 Migration test case

Two years ago, most of the univeristy video files were hosted externally. With Episode Engine and Helix, we began hosting the assets in-house. By mid September 2011, we have about 700 AV files stored on a disk attached to the Helix streaming server (a majority of these originally migrated from another project dedicated to teaching and learning). Most of these files are in mp4 (video) or mp3 (audio) formats as for about 1.5 year we stop transcoding file in Real format and also ceased streaming, giving preference to wider standards. This paves the way for a relatively easy introduction of the "AV Dropbox" scheme (easy in the sense that we didn't have to re-transcode the files)

Migration consists of requirements analysis with stakeholders, and commissioning of servers (workflow & upload using NSSDropbox, and web) and storage areas (Netapp, one for upload and one for transcoded files). Other issues came into play including the use of a "friendly URL" (we decided on, and proxying the workflow (or not, being the motion at the moment), and re-transcoding a small number of old files to mp4 / mp3.

Going live was an event that demanded some added attention as updating the CMS and Blackboard templates (to point to new server URLs) meant currently available AV files needed to continue to work with the new URL. A great deal of checking went in to ensure going forward does not result in going back swiftly! Apart from some templates that were non-standard, the go-live went unnoticed and was a quiet success.

10 Next step

JW Player remains an attractive asset. With HTML5 (and mobile platforms) becoming mainstream, we are looking at what's possible. There is significant requirements from the corporate office to provide for these outlets. A bought-in solution is unlikely, nor something that potentially gives security concerns. Cloud solution maybe possible, so long uploaded files are not stored on remote servers. appears to be attractive with regard to workflow.

Dr David Wong
Multimedia: Corporate Information Systems Support
IT Services, University of Reading


<a href="">Permalink</a> | <a href="">Leave a comment  »</a>

[edit] 11 The impact of cookie law

24 May 2011, by

<p>(borrowed from our Listening for Impact blog... <a href="">The impact of Cookie law</a>)

You may or may not be aware of recent changes to EU and UK regulations regarding the use of Cookies on websites. Cookies are small text files sent out to user’s machines and posted back to the server with each webrequest. These tend to feature on nearly every website for one purpose or another, but they are fairly common on websites that are trying to track their user’s actions – e.g. through some form of analytics.

Andrew Cormack from JISC’s regulatory team has written a fairly clear update on the current situation which can be read on JISC’s blog at <a href=""></a>. Whilst the situation is still a little in flux, institutions are going to need to be aware of how they use cookies on their various web portals and be prepared to defend their approaches if challenged from May 26th onwards.



<a href="">Permalink</a> | <a href="">Leave a comment  »</a>

[edit] 12 Your technical help is requested...

16 February 2011, by

<p>Hello fellow Steeplers.

You may remember that I'm working on a project to improve reporting on the impact of podcasting (<a href="">Listening for Impact</a> @ <a href="">JISC</a>). I am in the process of writing an application to do a lot of the heavy data analysis from various sources (Apple spreadsheets, Apache Log files, Google Analytics, etc), but I've got a little bit of a challenge that I expect some of you can help with.

I am trying to identify a range of User Agents that appear in our hosting logs, but that aren't identifiable using the tools I presently have. I have documented the latest on this on the LfI website and would ask you take a look at <a href="">User Agent Analysis – Part 2: Name those agents</a> to see if you can help us (and ideally save me a lot of time on Google and experimentation!).



<a href="">Permalink</a> | <a href="">Leave a comment  »</a>

[edit] 13 What is Google playing at?

27 January 2011, by

<p>I said earlier it hasn't been quiet lately. Another hot topic received a shove recently when <a href="">Google announced they were removing support</a> for the h264 video codec from their Chrome webrowser in favour of their own WebM format (oh, and Theora). This simply means that HTML 5 <video> tag content will not playback without needing some third party software/plugin (where said content is in the globally dominant and arguably superior h264 format).

I can only conclude this is not a good thing.

Why? Well here's a few observations resulting from a community discussion of this topic...

  • Desktop browsers that are not Internet Explorer or Safari still account for <50% of the <a href="">desktop web browsing population</a>. Microsoft and Apple are very much in the h264 camp (both members of the Licensing Authority behind the codec) and their support isn't likely to change.
  • Abobe Flash (for all its sins and weaknesses) still has the largest internet browser penetration and it supports h264 video, but not Google's WebM (yet?).
  • Mobile browsing is on the increase and these devices rely on dedicated hardware sub-processors to reduce battery drain for things like video playback. You've guessed it, nearly all the hardware out today is directed at h264 playback (and recording too). WebM or otherwise hardware support is still yet to be seen, and certainly doesn't exist in any significant numbers.
  • There's no cost to distributing h264 content via the Web, and there's a guarantee from the authority behind it that there won't be. There is a cost to producing that content, and to supplying software that can play it, but these are knowns and not too significant (unless you're Mozilla?).
  • Patents haven't yet been tested and WebM's royalty free status isn't assured because of this (yes, slightly FUD here).
  • Quality for size is still in h264's favour and likely to remain that way for the next 1-2 years from what I can see.
  • Consumer level hardware is based around h264 (BluRay, AVCHD camcorders/cameras, some Digital TV broadcasts).
  • HTML5 take up is still very low, so reliance on browsers to support a video format natively is still rather an optimistic expectation. But, this is a growing segment, and whilst Chrome and Firefox usage isn't high, it is significant.

I would say that h264 is still the most relevant video format for the next 1-2 years, but that flash is going to gain as a fallback player mechanism within Chrome and Firefox browsers as HTML 5 usage grows. If people want to provide WebM options, that may be of benefit (but assumes your webportals are going to browser sniff for compatibility and supply the relevant format - doable, but perhaps optimistic at this stage?).

Note, I'm completely side-stepping the hypocrisy of why Google is doing this, and any debates about openness of formats (they're nicely addressed in this <a href="">ARS Technica article</a>).

So, the game changing conditions (1 or more required) as far as I can see would be:

  • Microsoft opts to natively support Web M
    - quite possible via plugins, but unclear if this will be prevalent.
  • Adobe implements WebM support in Flash
    - they were listed as a partner in the original <a href="">WebM announcements</a>.
  • W3C set the HTML 5 standard for to require Web M (or even h264).
  • Google declares that it will protect Web M from any patent challenges and associated costs
    - after all, the M.O. of patent lawsuits is to wait till there's enough juicy targets to squeeze money out of before litigating, and who wants to be caught down that road?
  • Mobile device manufacturers start mass producing discrete graphics processors for Web M and these products flood the market
    - enough names were mentioned in the launch announcements.

...and we're ignoring that the MPEG are undoubtably working on a superior successor to their h264 standard anyhow and that may be another game changer and most likely far in advance of anything WebM will be capable of.

Where does this leave us?

  • On the mobile side alone, I would suggest that h264 is going to be more crucial for those who produce tiny resolution videos for distribution to areas with poor bandwidth.
  • For the foreseeable future (1-2 years?) h264 formats will be playable on the vast majority of browsers and devices, though increasingly reliant on the likes of Flash for fallback support.
  • Web M needs to mature further before it is worth committing time, effort and resources to providing alternative versions of your content in this format (in addition to the mainstream h264).
  • If Google and Mozilla don't change their stances again, we're going to have a very fractured user experience for web based video (not unlike now... *sigh*).

Remind me again, wasn't the future supposed to be brighter and more harmonious with HTML 5? ;-)

Whilst I'm on the HTML 5 topic, why is there so little interest in the similar mess around the <audio> tag?...



<a href="">Permalink</a> | <a href="">Leave a comment  »</a>

Read our Blog - we're posting thoughts, ideas and notes right there, and we want you to give us your feedback.