From Steeple

Contents 1 Institutional Podcasting: Suggested Project Workflows 1.1 Introduction to common elements of a workflow 1.2 Audio Encoding 1.3 Consistent Naming Strategy 1.4 Local Filestore 1.5 A central online filestore: media.podcasts 1.6 RSS

[edit] 1 Institutional Podcasting: Suggested Project Workflows

[edit] 1.1 Introduction to common elements of a workflow

In order to save time while managing work and help a team follow a plan, an agreed workflow is vital. This is especially true for teams dealing with a large amount of digitisation activity. A written workflow helps a project where there are many staff handling content and working with many complicated subprojects. Regardless of your specific processes for handling AV projects at an institutional level, there are common workflow elements required to allow files/projects to be located easily and efficiently.

It is important to start to think of multiple encodings per project to be handled so that different online versions can by provided. Users with greater infrastructure resources (more disk space, higher bandwidth, better players, etc) will appreciate downloading the higher quality versions. Whereas, those with less infrastructure resources will prefer the time saved by having access to smaller files.

To simplify the number of derivative versions needed by users, it is recommended to produce a limited range of different quality versions for different distribution uses. As well as the Master Edit version of the video content, there are four levels of encoded output for video podcasts and three levels for audio using this simplified workflow. These are outlined in the following tables.

Sample settings for encoding video

Level	Filenames	Resolution	Encoding details	Typical file-sizes
Master Edit	filename.dv or filename.mov	4:3 = Not defined, 16:9 = Not defined	DV or Uncompressed	~ 12000Mb/h
High	filename-high-video.mp4	4:3 = 640 x 480 px, 16:9 = 640 x 360 px	Bitrate: VBR using VBV @ 1500k. Peak 1800k.	~ 690Mb/h
Medium	filename-medium-video.mp4	4:3 = 640 x 480 px, 16:9 = 640 x 360 px	Bitrate: VBR using VBV @ 700k. Peak 900k.	~ 350Mb/h
Low	filename-low-video.mp4	4:3 = 320 x 240 px, 16:9 = 320 x 180 px	Bitrate: VBR using VBV @ 300k. Peak 450k.	~ 150Mb/h

Key things to note:

• The three levels (high, medium, low) all share these Encoding attributes: H264 encoded. Keyframes: Natural and Forced (every 20 frames). No. Of Reference Frames: 1. Profile: Baseline. B-frames: 1.
• For playback on iPods and similar media devices, a Baseline encoding profile is essential.
• For H264 files to support “scrubbing” (winding forwards and backwards through the video) you need to supply a good dose of keyframes at regular and frequent intervals. Most encoders support automatic scene (natural) changes and insert a keyframe there. However, video that doesn’t feature much movement (e.g. talking heads, lecturer at a lecture, etc) tends to feature few keyframes. Our value of 20 frames between keyframes is almost arbitrary, but aims to compromise between recovery gaps (how long it takes the player to refresh an image between keyframes) and compression. It does mean that any artifacts introduced by interrupted or skipping of playback should be fixed in under a second.

[edit] 1.2 Audio Encoding

Sample settings for encoding audio

Level	Filenames	Encoding details	Typical file-sizes
Master Edit	filename.aif or filename.wav	Uncompressed, PCM, 16bit, 44100Hz, Stereo	~10Mb/m ~600Mb/h
Medium	filename-medium-audio.mp3	Lame MP3. VBR 64-(128)-320k. 44100Hz. Joint Stereo. Stereo output	~780Kb/m ~47Mb/h
Low	filename-low-audio.mp3	Lame MP3. VBR 32-(32)-96k. 44100Hz. MS Stereo. Mono output.	~380Kb/m ~23Mb/h

At present the high quality audio version is identical to the master/archive copy.

[edit] 1.3 Consistent Naming Strategy

Whichever approach is followed, a uniform and systematic naming strategy is needed. Due to the contrasting systems underlying the work done, the need for understandable project names applied consistently is required to allow content to be located and tracked. Primarily, there are three distinct systems/locations to consider:

• Local filestore
• RSS
• media.podcasts.university.ac.uk

Generically, naming takes the following pattern: /unitcode/project_name_without_spaces

What is a project? This is a valid question, though not easily definable. Put simply, any set of related podcasts/media-files and their source materials. Thus a working project folder will contain a range of media and text files related to that work/topic. Folder paths and names should be identical on both Local filestore and media.podcasts, with RSS feednames mirroring the folder/project name. These folder names and file names will eventually form part of a public URL, and so should be understandable to people and sensible in appearance.

[edit] 1.4 Local Filestore

The main working copy of a project should be held in an accessible areas (available to all users that need it, opposed to the file appearing only on you local user desktop), ideally grouped together in a common folder (e.g. Projects). Once in that folder, the next level should be folders bearing unitcode names (e.g. UnitX,UnitY, SubjectAreaX, SubjectAreaY, etc) and then these folders contains project folders with a unique (but short) names.

A project folder should contain a number of consistent elements (folder name in brackets):

• Unmodified source material (Originals)
• Legal documents and notes (Legal)
• The final edited master files (MasterEdit). The naming of these files needs to be done in a short and sensible fashion as their name will be carried onto the published files (with suitable appendices and file extensions). There should be NO SPACES in these names. If needed, use an underscore (_) character instead of a space. This is a derived from simplifying issues related to URL names and paths.
• Final set of encoded1 outputs made from the contents of the MasterEdit folder (FinalOutputs)
• A number of folders containing working edits, partial material, project files, tests, etc. These can take a range of names to suit whoever is working on the material.

As a rule, we are not deleting any temporary work or test files. Whilst space allows we are moving these to “Junk” folders in the relevant section of the project folder (i.e. there can be multiple junk folders in a project folder). If at some point storage space becomes critical, a sys-admin may target these folders for deletion.

Thus we can have....

/Projects
	/unit
		/project_alpha
			/Originals
				/some_input.mov
			/Legal
				/ApprovalForm.doc
			/MasterEdit
				/Junk
					/project_alpha_oldedit.dv
				/introduction.dv
				/introduction.aif
			/FinalOutputs
				/introduction-low-video.mp4
				/introduction-medium-video.mp4
				/introduction-high-video.mp4
				/introduction-low-audio.mp3
				/introduction-medium-audio.mp3
			/Freds working edits
				/clip1.mov
				/clip1_2-too-short.mov
				/alpha.imovie-project
		/another_project
			/Originals
			/Legal
			/MasterEdit
			/FinalOutputs
	/another-unitcode
etc…

[edit] 1.5 A central online filestore: media.podcasts

The centrally hosted, publicly available online filestore is referred to as media.podcasts. The accessible URL for the public portion of the filestore is http://media.podcasts.university.ac.uk/. There are two top-level folders in this example: archive and pub. The aim is to copy portions of the local filestore in both the [archive] and [pub] folders, thus under all three we should see a series of folders representing the unitcodes, and in those folders the project folders, and in those folders, the files. However, we are only interested in copying the files encoded for public consumption to [pub] and just the master edit files to the [archive] tree (as we can regenerate the processed content from these if needed). Thus, using the previous example we would have:

/media.podcasts.university.ac.uk
	/pub
		/unit
			/project_alpha
				/introduction-medium-video.mp4
				/introduction-high-video.mp4
				/introduction-medium-audio.mp3
			/another_project
	/archive
		/unit
			/project_alpha
				/introduction.dv
				/introduction.aif
			/another_project
etc 

The key here is that the RSS will point to the files in /pub/unitcode/projectname/.

(for a special video project with three feeds – see RSS section)

[edit] 1.6 RSS

RSS does not support more than one media enclosure per item. Consequently, it is not possible to include both an audio and video file in the same item (only using RSS). However, in RSS 2.0, additional namespaces are supported, and the Yahoo media namespace can be used to add multiple enclosures per item. Atom, a more recent format, also has the ability to have several 'enclosures' per 'item', i.e. several <link rel="enclosure"> tags per <entry>. Further information and comparisons can be found here: http://www.ict4e.net/wiki/Enclosures_in_yahoo_media,_rss,_and_atom

If you have a system that doesn't support multiple enclosures, you have had to create a number of RSS feeds for each project delivery format. Similarly, if you are delivering content for iTunesU, then each RSS feed appears as a tab in an iTunesU entry for a project/topic. This might range from 1-4 RSS feeds per project.

1. Audio only
2. Video
3. For special projects – audio, video & high quality video
4. Transcript pdf

RSS Feeds need to be created using the consistent naming strategy that starts “unitcode/project_name” and is then appended with:

“-audio” for the audio only feed “-video” for the standard video feed “-high-video” for the high quality video feed.

So, the project “another_project” for “unitx” becomes the following feeds…

unitx/another_project-audio
unitx/another_project-video
unitx/another_project-high-video

It is also possible that files generated in this project can be referenced by other RSS feeds. However, this doesn’t imply that there is a matching folder structure for these meta-feeds. Once these feeds are created, individual media items have to be added to each feed, so for each episode in your podcast stream there will be up to three media items created (individually and manually) for the corresponding encoded file. A project may decide to use a smaller set of available media, for instance; only the following encoding outputs may be in the core set of institutional newsfeeds:

• RSS feed -> Encoded File in the enclosure
• projectname-audio - > projectname/filename-medium-audio.mp3
• projectname-video - > projectname/filename-medium-video.mp4
• projectname-high-video - > projectname/filename-high-video.mp4