Breathing New Life into Legacy Media Servers John M. Morris Coordinator: Academic Technology & Web Services Drexel University Philadelphia, PA [email protected]

Breathing New Life intoLegacy Media Servers

John M. MorrisCoordinator: Academic Technology &

Web ServicesDrexel UniversityPhiladelphia, PA

[email protected]

11-Jan-06 Educause Mid-Atlantic 2

What You Are Going to See

• Drexel University Overview• How this project came about

– Project Exigency– Media file handling processes– Project Goals

• Project Phases• Phase 1 – Pre-Pilot and Pilot• Major System Components• Implementation Details• File Naming Convention• Locating Output• Types of encoding that can be done• How this project breathes new life into legacy media servers• Project Metrics• Phase 2 – More output types and a GUI interface• Demonstration


Drexel University Overview

• Private institution founded in 1891• Total graduate and undergraduate 15,000

students• 10 Colleges and 3 Schools:

Arts and SciencesBiomedical Engineering Science and Health SystemsBusinessEducationEngineeringHonorsInformation Science and TechnologyMedia Arts and DesignNursingProfessional StudiesPublic HealthMedicineLaw (beginning fall ’06)

• Co-op School– 5 yr. program– 3 6-month paid professional work experiences


Drexel University Overview

• First US institution with microcomputer requirement - 1983

• Campus entirely wireless - 2000• Internet2 connector school• Single sign-on portal• Commitment to mobility, education from

any place at any time, and meeting technology needs and expectations of tomorrow’s students

Can you say the word PODCAST?

This project started because a faculty member wanted to do podcasting and I saw a chance to significantly reduce staff involvement in media conversion and deployment!

It quickly evolved into something more!


Rich Media Automation Project Project Exigency• Significant personnel time required to handle

media file encoding and deployment.• Moderate personnel time required to manage

media servers and content.• Significant personnel time required to assist

faculty with access management to their media files.

• Over 5000 media files on 3 media servers representing >15,000 hours of video / audio accumulated over about 5 years.

• Growth in content encoding and deployment requests increasing rapidly due to new capture apps and increased interest in podcasting.


Pre-Pilot Typical Media Handling Process

Rawmedia

fileproduced

Mediafile

encoded

URLgiven

toinstructor

Encodedfile

deployed

Instructorputs

individualURLs into

CMS

Media givento supportstaff

Media movedto server

Instructoremailed withURL

Instructorcopies andpastes URLs

Mi Mi Ms

Ms

Ms

Ms

Mi

Mi

Mi

Mi = Manually Processed by Instructor

Ms = Manually Processed by Staff


Rich Media Automation Project Project Goals• Reduce personnel handling time!• Increase usability of existing media servers.• Prepare for changes in media encoding and

deployment technologies.• Make access to server based media artifacts

easier and to make all media content syndicatable (RSS 2.0).

• Use “off the shelf” encoders – keep it inexpensive!

• Write it in easy, manageable code

Bottom line: Create a simple-to-use media object repository out of our legacy media servers that will significantly reduce staff “hands on”.


Rich Media Automation Project Project R & D Phases• Phase 1 (Feb 2005 – Dec 2005)

– Minimize staff handling of media files.• Create “Drop Box” automation process requiring little or no

oversight by my faculty & tech support staff.• Develop RSS 2.0 syndicatable output with an HTML

equivalent.– Create an “Swiss Army Knife” encoder farm capable of

encoding various media formats into stream-able formats.• Phase 2 (Jan 2006 – August 2006)

– Increase ability to handle additional input / output types– Increase ability to handle metadata– Implement logging / indexing of content w/ search

capabilities– Create Web-based and App-based GUI application

interfaces to encoding and deployment processes.• Phase 3 (Sept 2006 – Dec 2006)

– Productize system and make available to other institutions.

OK, already!

What’s this thing look like?

Phase 1


Major System Components (Phase 1)

• “Drop Box” folder on public access machine.– Mountable locally (domain login)– Mountable remotely (VPN + domain login)– Secure– Permission managed (currently limited to

Pilot program faculty only)• Encoding farm (multiple encoding

platforms all running the same software and all watching the “Drop Box” for content)

• Media Server


Media Handling Process (Phase 1)

Rawmedia

fileproduced

Mediafile

encoded

URLgiven

toinstructor

Encodedfile

deployed

Instructorputs singleURL into

CMS*

Mediadropped into“Drop Box”

Media movedto server

Instructoremailed withURL

Instructorcopies andpastes URLs

Mi Mi A

A

A

A

A

N/A

Mi

Mi = Manually Processed by Instructor

A = Auto Processed by new process

* Only initial one


Media Server Environment (Phase 1)

• Real Networks Helix Server 9.0.8 w/ – 4000 max concurrent connections– 10 MB max overall output bandwidth– ~4500 + video / audio files (~14,000 hrs)

• Windows Media Server (MS Adv. Server 2003)– Concurrent users only limited by CPU &I/O

performance (2000 max practical)– Outbound bandwidth only limited by CPU & I/O

performance (10 MB max practical)– ~100 video presentations (~300 hrs)

• Sonic Foundry Media Site Live server based on Windows Media Server (based on Windows Media Server – see above)– ~500 video presentations (1000 hrs)


Some Notes!

• Number of and configuration of media servers has not changed prior to nor during pilot program (except for some minor mime and mount point configuration on the Helix server).

• Servers online since:– Helix - late 2000.– Windows Media – late 2000– Media Site Live (Window Media)

• #1 – early 2003• #2 – late 2004

• Pilot project concentrated on Helix server since it contained > 90% of the content, has players on most platforms and serve almost any type of media (content – object).


Media Server Pros / Cons (1/2)

Real Networks Helix Server – Version 9– Pros

• Player & Server available on most platforms• Can serve (stream) almost any kind of media incl:

– Real, Windows Media, Macromedia SWF, audio MP3, Quicktime, MP2, H263/H264 (M4V, MP4), HTML, XML, PDF, TXT, …

• Mobile extensions to serve 3GPP *• E-commerce capable (add insertion, banners, …)• Skin-able players• Synchronized multimedia (SMIL)• Not linked to Microsoft servers or IIS.• Ad-hoc mount points for live production• Live, archived, and On-Demand w/ security and DRM• Content Push & Pull• Superior low bandwidth encoding

– Cons• Not FREE (at current spec – for edu’s ~$2000/yr)

* Version 11 (currently being installed)


Media Server Pros / Cons (2/2)

Windows Media Server – Windows Adv. Server 2003– Pros

• FREE• Easy to configure• Can serve HTTP but only through IIS• Live, Archived, and On-Demand w/ security and DRM• Content Push & Pull• Skin-able player• Ubiquitous on Windows Platforms

– Cons• Will only serve Window Media files.• Only Intel (Windows OS) platform• Mount points must be set up ahead of live production• Tied to MS IIS• Individual servers limited to about 2000 concurrent connections

depending on system specs.


Command Line Media Encoders

• Real Network – Real Producer Plus 10.0 (rm) ($)• Windows Media Encoder 9.0 (wmv) (Free)• Switch 1.05 (wav -> mp3) ($)• Tag (add metadata to mp3 files) ($)• Text-Aloud 2.048 (text -> mp3) ($)

– Plus AT&T voices ($)• On2 Technologies (various -> swf) ($$$)• Konvertor – xxx2wav (strip audio from avi, mov) ($)• pdfCamp 2.10 (various -> pdf) ($)• Cleaner XL 1.5 (various -> various) ($)

– Will replace On2 Technologies, Switch and WMEncoder in Phase 2

– Will be used to create mp4 & m4v


How the “Drop Box” WorksConcepts & Issues

• File Naming controls encoding and deployment

• Separation of public systems from encoding farm and media servers for security.

• Multiple encoders to keep up with processing demand.

• KISS (Keep It Simple $^&*@#)


Automation Architecture Overview - 1

To Do

Public Server

To Do

Encoder 1

To Do

Encoder 2

To Do

Encoder n“Course”Name

Helix Server

Html / xml

Done

Encoders watch ToDo folder and copycontent to local ToDo folder for processing


Some Process Details - 1

• Faculty/Staff drop one or more media files into the drop box for processing.

• Two independent “Scheduled” processes running on encoders:– Watch the remote “ToDo” folder (A)– Watch the local “ToDo” folder (B)

• If Watcher (A) finds a well-formed file in the remote “ToDo” folder, it LOCKS it (adds a .lock to the end of the file name) and copies it to the encoder’s local “ToDo” folder.

• By locking the file, the other encoders will not act on it.



To Do

Public Server

To Do

Encoder 1

To Do

Encoder 2

To Do


Helix Server

Html / xml

Done

Encoders process media file and place results onto Helix server



• Process (B) on each of the encoders watches its “ToDo” folder continuously.

• Selects & Processes one file at a time.• Encoding based on info contained in the file

name - FNC*• Output sent to Helix server

– Content folder name based on info found in the file name – FNC*

– An XML file is created for each FOLDER and updated automatically every time a new content file is added to that folder

– An HTML equivalent is regenerated every time the XML file is updated.

FNC: File Naming Convention – see later slide



To Do

Public Server

To Do

Encoder 1

To Do

Encoder 2

To Do


Helix Server

Html / xml

Done

Encoders clean up by moving processed fileto Done



Encoder cleans up after itself– Copies processed files from remote

“ToDo” to remote “Done” and removes locks.

– Removes processed files from its local “ToDo” folder.

– Takes a 2 minute breather and then looks for the next file to be processed (contained in its local “ToDo” folder.)

So how does the system know where to put the resulting files?

The File Naming Convention


The File Naming Convention

• Three parts– The “Course Identifier”– The “Control Character”– The “Event Name” (the actual media

file)

• Example– EGMT501!Lecture1.avi

• EGMT501 -> Content Folder Name• ! -> encoding control character• Lecture1.avi – Event Name


Locating Output

• EGMT501!Lecture1.avi• Creates a EGMT501 folder on the Helix server if it

doesn’t already exist.• The “!” tells the encoders to create two RM files (56k &

256k) and strip the audio off into an MP3 file.• Put all of the output files into the EGMT501 folder – name

them by removing the encoding control character and replacing the extension with the corresponding appropriate extension (e.g. -56k.rm) EGMT501Lecture1-56k.rm

• In a folder called HTTPXML, create a folder named EGMT501 (if it doesn’t already exist) and create or update the XML & HTML files that make it possible to easily deploy the content. Note: the name of the XML and HTML files is the same name as the folder – thus making the location of the RSS syndication file (XML) or the web file (HTML) apparent from the start!


What Types of Encoding Can Be Done?

• Various Video formats into RM, WMV, SWF & MP4/M4V (video podcasting) files.

• Audio can be stripped from Video files to produce MP3 files (audio podcasting).

• Document, Excel, PowerPoint & HTML files can be converted into PDF format.

• Document files can be converted into MP3 files (Text to Voice)!

• Metadata can be included in XML & HTML syndication files by adding a “description” file along with content file.


So How Does This Breathe Life Into Legacy Media Servers?• Significantly reduces staff handling of media

files.• Uses media server characteristics to stream as

many types of content as possible.• “Publishes” content via dynamically updated

RSS 2.0 compliant XML file (e.g. News Readers, iPods, iTunes, Firefox …) – enables Podcasting!

• “Publishes” content by providing an HTML equivalent to the XML file.

• Greatly simplifies access to content.• Turns legacy server into Reusable Media

Object Repository.


Rich Media Automation Project Pre-Pilot Metrics Pre-Pilot (Feb 2005 – Jun 2005)

– 5 active faculty– >400 artifacts dropped and processed– Three encoders running simultaneously (1.8 GH P4’s, XP

Pro)– Informal – develop on the fly– Conversions:

• avi -> rm, wmv, mp3 (strip), swf• mov, qt -> rm• wav -> mp3• doc, ppt, xls, txt, rtf, html -> pdf• doc, txt, rtf, html -> mp3

– Estimated staff time savings: 400 * 30min/item = 200 hrs.


Rich Media Automation Project Pilot Project Metrics Pilot (July 2005 – Dec 2005)

– 25 active faculty– >1000 artifacts dropped and processed– >2500 artifacts created– Three encoders running simultaneously (1.8 GH P4’s, XP

Pro)– Formal agreement w/ faculty using system– Continue to develop on the fly– Conversions:

• avi -> rm, wmv, mp3 (strip), swf• mov, qt -> rm• wav -> mp3• doc, ppt, xls, txt, rtf, html -> pdf• doc, txt, rtf, html -> mp3• avi, qt, mov -> mp4, m4v

– Estimated staff time savings: 1000 * 30min/item = 500 hrs.

Rich Media Automation Project

Phase 2


Rich Media Automation ProjectPhase 2 (Jan 2006 – Aug 2006)

• Increase ability to handle additional input / output types

• Increase ability to handle metadata• Implement logging / indexing of

content w/ search capabilities• Create Web-based and App-based

GUI application interfaces to encoding and deployment processes.


Rich Media Automation ProjectPhase 3 (Sept 2006 - forward)

Productize system and make available to other institutions ($?).

The Value Added Proposition

Why all of this was a valuable initiative pedagogically and

educationally!


The Value Added Proposition

• Robustness and ease-of-use drives usability and success

• Significant savings in terms of personnel time.

• Faculty who typically would not involve themselves in “high” technology can / do adopt.

• Adds content richness and engagement to web-based classes by providing a variety of media formats.

• “Cool” technology engages students more! (edutainment factor)

Rich Media Automation Project

Demonstration


Rich Media Automation Project Demos

• Example of Text -> MP3– http://broadcast.drexel.edu:8080/httpx

ml/techupdates/techupdates.html

• Examples of Mixed Content– http://broadcast.drexel.edu:8080/httpx

ml/TurnItIn/TurnItIn.html

Copyright – Drexel University – All Rights Reserved

http://broadcast.drexel.edu:8080/httpxml/techupdates/techupdates.html

http://broadcast.drexel.edu:8080/httpxml/techupdates/techupdates.html

http://broadcast.drexel.edu:8080/httpxml/TurnItIn/TurnItIn.html

http://broadcast.drexel.edu:8080/httpxml/TurnItIn/TurnItIn.html


What You Saw!

• Drexel University Overview• How this project came about

– Project Exigency– Media file handling processes– Project Goals

• Project Phases• Phase 1 – Pre-Pilot and Pilot• Major System Components• Implementation Details• File Naming Convention• Locating Output• Types of encoding that can be done• How this project breathes new life into legacy media servers• Project Metrics• Phase 2 – More output types and a GUI interface• Demonstration

The End

Questions?

John MorrisDrexel University32nd & Chestnut Sts.Korman 126Philadelphia, PA 19104

[email protected]

215-895-2369

mailto:[email protected]

Documents

Breathing New Life into Legacy Media Servers John M. Morris Coordinator: Academic Technology & Web Services Drexel University Philadelphia, PA [email protected]