Recording & Streaming
UNDER REVIEW

Introduction

This chapter covers the primary components, ICT architecture considerations, and best practices for planning, designing, and deploying a lecture capture system.
A lecture capture system consists of three key components:
    Ingest is the capture of audiovisual sources and the creation of encoded digital video content
    Management is the session management, data storage, library categorisation, and delivery of encoded digital audiovisual content.
    Playback is the decoding of the stored AV content for viewing
Lecture capture and streaming systems can be both software and/or hardware deployments. In either case, the standards and best practices for both enterprise software management and commercial AV installations apply.
Other specialised recording systems such as multi-track audio recording, or CCTV security camera management systems are outside the scope of this chapter.

High-Level Checklist - Recording & Streaming

This chapter focuses on lecture capture as it relates to the digital recording of video, audio, and related content, metadata or annotations. Lecture capture is primarily used for reviewing a lecture session after the fact, distance learning, as well as many other education-related use-cases.
Use the following as a high-level checklist when planning for and designing a lecture recording and streaming solution:
    Determine key stakeholders and functional requirements
    Determine requirements for screen capture
    Determine requirements for camera capture
    Review the video capture checklist
    Review the audio capture and processing checklist
    Determine requirements for scheduled recordings
    Determine requirements for ad-hoc recordings
    Determine requirements for recording status lights
    Determine the appropriate recording and streaming solution(s)
    Determine content management and distribution methods
    Consider content playback methods
    Calculate recording and streaming data rates

Glossary of Terms

Term
Definition
Adaptive Bitrate (ABR) Streaming
Connection speed, quality, and device types may impact the ability to stream video at certain quality settings, ABR automatically adjusts the video quality as the video plays to match the connection quality.
Annotation
An image composition method for representing notes and markups of an image or video. Annotations are typically drawn freehand onto a touch interactive display, or using a stylus.
AV
Audiovisual (AV) encompasses the integrated hardware devices and software for managing the routing, processing, and presentation of video and audio content. It may also include associated AV network data streams, user control interfaces, and automation processes.
Bitrate;
Data rate
In computing, and transmission of data streams, bitrate is the number of data bits that are transferred per second.
Codec
Hardware or software designed to encode or decode a digital data stream. Codecs are used to encode a video signal so it can be streamed or saved as a video file, as well as decode a video file or incoming data stream so that it may be viewed.
CDN
A Content Delivery Network (CDN) is a distributed network specifically designed for video streaming delivery for (typically large) audiences connected over the internet.
Flipped Classroom
A blended learning strategy that reverses traditional pedagogy by encouraging students to watch recorded content prior to class and then carry out discussions and research during the live session with their educators and peers.
FTP
File Transfer Protocol (FTP) is a communications standard for sending digital files over a network.
Human Interface Device (HID)
A peripheral that connects to a computer to allow a user to interact and provide input. Examples include keyboard and mouse.
HLS
HTTP Live Streaming (HLS) is a web protocol for delivery of audio and video content to viewers via the internet.
HTTP communication
Hypertext Transfer Protocol (HTTP) is the foundation of data communication for the world-wide web.
ICT Architecture
Information and communications technology architecture encompasses the computers, servers, phone systems, and network switching and routing for an organisation’s network.
IP Address
An Internet protocol address (IP Address) is used for network communication between computer devices. The IP address allows a device to be identified on the network.
LAN
Local Area Network (LAN) is a network of interconnected computers within a building or department.
LMS
Learning Management System (LMS) is a term used to describe a portal for students and educators to access digital content related to their areas of study, often based on courses. An organisations lecture recording and streaming solution is often integrated into the LMS to ensure students have a single location to access their learning materials.
Multi-stream Recording
Multi-stream recording (a.k.a multi-camera recording) is a lecture recording method whereby multiple individual video sources are captured in real time and saved as a single recording session. During playback, all streams are frame-synchronised and viewers may freely switch between or overlay (PiP) the available video content streams.
Picture-in-Picture (PIP);
Windowing Processor
A combined video image composed of two or more video sources. Combined images may be side by side taking up half the viewable area, or one image may take up the entire viewable area with the other displayed on an inset window positioned in the corner.
QoS;
Traffic Shaping
Quality of Service is a method of prioritising specific, time-sensitive network data traffic to ensure it reaches its destination with minimal delay
Sample Rate
In digital audio, sample rate is the number of discrete audio samples captured per second of a continuous analogue signal. The sample rate must be greater than double the highest audio frequency that is intended to be captured (known as the Nyquist frequency or limit). 44.1kHz or 48 kHz are common audio sample rates for live and recorded audio; both able to capture 20 Hz - 20 kHz.
SD Card
Secure Digital (SD) memory card digital storage media
WAN
Wide Area Network (WAN) is a computer network that spans over large geographical distances
Webinar
Interactive online seminar or lecture delivered to viewers via the internet.

Key Stakeholders

Below is a list of stakeholders commonly involved in the planning, deployment, and maintenance of a lecture capture system:

Facilities Management and Project Teams

    Responsible for the design and maintenance of facilities to support the pedagogical outcomes of academic staff and students.
    Responsible for coordinating the design and implementation of architecture, build and services to support integrated technologies and performance criteria/standards.

End Users

    Collaborate with educational and ICT/AV designers to help define the functional requirements of the recording solution.
    Use the solution and provide feedback to educational and ICT/AV designers to improve the service/solution.

Educational Designers

    Provide insights into the educational pedagogy, trends and preferences of the institution and wider tertiary community.
    Collaborate with ICT/AV Designers in defining features, functionality and user experience of enterprise solutions.

AV and ICT Design, Support & Management

    Responsible for the design, implementation and support of integrated technology.
    Collaborate with educational designers and end users, providing technical solutions to deliver an enterprise learning solution for students and staff.
    Ensure appropriate hardware and software is in place to support the desired user experience of end users and educational designers.

Functional Requirements

Common Objectives & Use Cases

Below is a list of common objectives for lecture capture and streaming:
    Record presenter voice(s)
    Record audience voices
    Record presenter physical gestures
    Record presentation and class material of lectures and seminars.
    Record study information, discussions, and whiteboards from tutorials & studio sessions
    Recording must start/stop according to a schedule
    Recording must be triggered ad-hoc
    Live-streaming AV content to students
    Live-streaming AV content to internet for guest participants
    Review educational session audio, video and content at a later date.
    View per-recorded content for use in flipped classroom scenarios.
A recording and streaming system may also be utilised for additional applications:
    Record detailed actions of instructor, or students (simulation lab) for detailed review.
    Peer-to-peer student-created video learning opportunities.
    Record remote participants and their shared content (distance learning).
    Mobile recording (user's device tablet / phone)
    Viewer participation through comments, annotation, et al
    Speech-to-text video search and indexing
    Artificial intelligence to generate closed-captions (including language translation)
    Artificial intelligence to computer speech translation (speech synthesis)
    Use of a human-based transcription service to provide accurate closed-captions for hearing impaired students

Applicable Room Types

Lecture recording (and streaming) has traditionally been commonplace in spaces with a predominantly didactic nature, e.g. auditoria, lecture theatres and seminar rooms.
Interactive learning environments such as laboratories, learning studios and tutorial rooms may in the past have lacked a recording solution by design, as the impetus is on active student engagement within the learning environment.
The ubiquity of conferencing solutions for distance education, software/cloud recording options and a focus on student preferences for content view and review all mean that as ICT/AV designers it is important to have a flexible and scalable solution available that can be applied to most scenarios and room typologies, as required.

Key System Components

A lecture capture system is composed of three key components:
    Ingest: Encoding and recording of video, audio, and data sources
    Management: Content storage, transcoding, cataloging, and delivery
    Playback: Decoding and playback of video data

Ingest Methods and Best Practice

Ingest covers the AV sources, video encoding, and digital file creation aspect of a lecture capture system.

Common Input Sources and Processing

Common sources and processing equipment deployed for digital video ingest are below:
    Sources:
      Resident Computer
      Portable devices (laptop, tablet, phone)
      Overhead or table-mounted document cameras
      Cameras - pan/tilt/zoom
      Cameras - fixed shot
      Webcams
      Mobile device camera and microphone
      Video conference device output
    Signal processing equipment:
      Audio visual switchers / matrix switchers route video source inputs to recording outputs
      Digital video to USB converters
      Video distribution amplifiers may be used to mirror in-room presentation video feed
      Annotation processors capture touchscreen or keyboard/mouse activity and render a digital annotation overlay onto an incoming video signal
      Window Processors combine multiple video sources into a single video output

Screen Capture

One of the primary requirements of a lecture recording system is that it must be able to record the content that is presented to students in a teaching space - known as ‘screen capture’.

Desktop Capture

Desktop Capture of the Resident PC in a venue is one of the most ubiquitous and cost-effective uses for lecture recording in educational institutions. It is achieved via recording software installed on the Resident PC which connects to the institutions lecture recording system for management and distribution.
Desktop capture is typically unable to switch to alternative video input source when used, so is unsuitable in applications where recording other sources is required.

Single Screen Capture

Lecture recording in a single screen venue is relatively straight forward, with solutions available for capturing a mirrored output of what is presented in a physical teaching space. The use of a video matrix or switcher with a spare output available that mirrors what is sent to the primary display into the recording input is a suitable approach. This can be ingested into a hardware recorder’s digital video input or a capture card for use with recording software.
When using USB capture cards with software to mirror screen outputs, the Resident PC will be shown via the video routing system, so desktop capture can be disabled to avoid confusion for students when reviewing content.

Multi-Screen Capture

Multi-screen venues allowing the simultaneous display of different pieces of content are very common, and often larger capacity venues when compared to single-screen venues.
Most modern hardware and software capture systems (as well as Universal Communications or webinar applications) feature the ability to ingest at a total of two video streams. This allows the capture of either :
    a single content source
    dual content sources
    a single ‘live’ video image
    a single piece of content and a ‘live’ video image
Where an organisation wishes to capture live video content as well as both pieces of content being shown locally to students, a limitation arises which requires thoughtful consideration, and stakeholders to be engaged for feedback.
A decision needs to be made as to whether a third stream is required, and if so, how this will be achieved. The following applies to systems that do not support a third camera/content stream.
A non-exhaustive, unordered list of some approaches are presented below. Their suitability will be highly dependent on each organisation’s preferences for student experience as well as AV system designs and standards. Members are encouraged to share their ideas with each other to improve learning outcomes for all.
    1.
    Software logic that monitors the video content sent to local display systems and ensures presenter (or audience) camera and content are displayed, unless two different pieces of content are displayed simultaneously.
    2.
    Camera feed always displays, with the content which was last presented to an in-room display mirrored on the content feed.
    3.
    Multi-screen venues will only capture one of any multi-display systems. In this scenario it is highly recommended to standardise on the same display, e.g. stage left or audience left, and consider any implications for GUI design.

Camera Capture

Providing students a “talking head” shot and/or wider contextual camera shots of a presenter and audience may help improve engagement and offer remote students a richer learning experience when compared with only seeing presentation content.
Camera systems that highlight the current speaker by automated framing and tracking are preferred wherever feasible.
A description of different camera types, tracking options and positioning can be found in the Cameras section of the Video Conferencing chapter.
Each organisation may have its own standards and protocols relating to camera capture of staff and students. Always seek approval from the appropriate representatives to ensure local privacy policies are upheld, where they exist.

Virtual Cameras

A ‘virtual camera’ allows a network encoded camera to be presented to a software application as another option alongside USB devices plugged into that computer. Virtual cameras are generally achieved using a piece of software and their use may be suitable for organisations who are comfortable with the additional software configuration and management required for selecting available network streams.
The benefit of virtual cameras is that they may reduce some of the USB hardware extenders, converters and in-room runs required to present a physical connection to a resident computer.
Always test virtual camera applications with the cameras you intend to use and check with recording appliance manufacturers for compatibility and support.

Lighting for Camera Capture

The addition of camera capture for recording purposes must be supported by increased attention when designing lighting systems in teaching spaces. See System Contrast Ratio Examples and the Lighting the Presenter for further information on other applications.

Video Capture Checklist

Digital video capture best practice checklist:
    Confirm the camera, processing or video-outputting device specifications match the quality requirements for recorded content.
    Confirm any video processing or signal extension (e.g. HDBaseT) present in the signal chain will not compress, degrade, or downscale the recorded content.
    Confirm the video resolution, colour bit rate, and frame rate matches the quality requirements for recorded content.
    Confirm the video encode data rate and compression matches the quality requirements for recorded content.
    Consider HDCP strategy for venues with recording / live streaming and ensure all steps in the signal chain are configured correctly (See HDCP Considerations for Recording and Streaming below).
    Calculate the estimated hours of recorded content to be created each week. Confirm the total recorded content disk space requirements will not exceed the ICT architecture data storage or transmission rate as the library of recorded content grows.
    A copy of encoded video content may be archived at the highest possible quality to future proof the video content library should the ICT architecture be upgraded.

HDCP Considerations for Recording and Streaming

High-bandwidth Digital Content Protection (HDCP) will block the digital video output of a device if an unauthorised receiving device is detected. All lecture capture, low-bandwidth streaming and video recording devices are not authorised to record/stream content that is HDCP encrypted.
It is illegal to use adapters, converters, or software to bypass or disable HDCP, as this is considered a circumvention of Digital Rights Management (DRM).
Some major computer manufacturers will only attempt to enable HDCP when content with DRM is played. This scenario allows the enabling of HDCP on a digital video input which will disable recording/streaming of content when DRM-enabled content is played, and otherwise record non-DRM content (slides, documents, non-commercial video content).
It is also common for major technology manufacturers to enable HDCP by default on their devices. When combined with an HDCP-enabled digital video input, an HDCP handshake takes place and an encrypted content channel is established. This will disable the ability of the recording or streaming device to present content from that input. This scenario requires a solution, as university venues are required to be agnostic in the brands of computers preferred by their users.
A solution and organisational positionis required to address this. A few solutions are provided below, used in conjunction with each other or with other novel approaches:
    Consider how often DRM content is shown in-venue to inform your strategy
    Where DRM content is regularly required (e.g. film studies specialist spaces), provide dedicated HDCP-enabled devices and/or input (e.g. Blu-ray or HDMI input with HDCP enabled).
    Where DRM content is never used, disable HDCP on digital user-presented digital video inputs
    Where DRM content may be used
      consider providing a button or mode on the User Interface for the venue(s) that allows HDCP to be enabled or disabled. This could be an enable/disable button related to a digital video input source selection, or a mode button selected at the start of a session to tell the system that copyright content will be presented, OR
OR
    implement an automated process based on context e.g. if a scheduled recording is occurring, or an ad-hoc capture is triggered, HDCP is disabled on all or some inputs. This may be associated with a message informing the user of the system's state.

Window Processors

Window Processors allow a variety of content arrangements, including Picture-in-Picture (PiP), side-by-side and quad split, among others.
Whilst hardware and software-based Window Processors may allow additional content channels to be recorded, it is important to remember that there is no way to reverse the embedding of the content and selected overlay method, once captured. This may result in presentation content being rendered too small to read, presentation slides/content being obscured by a smaller window or confusion from audiences when attempting to adjust window sizes on playback.
If using Picture-in-Picture processing, consider combining only camera sources to ensure presentation content integrity is maintained.
If only two video streams are required, utilising both inputs of a software or hardware recorder is recommended as it allows more flexibility on playback, higher video quality and can be more cost-effective.

Audio Capture and Processing Checklist

Audio capture best practice checklist is provided below.
    Microphones:
      When a single person’s voice must be heard clearly and distinctly, use lapel, headset or handheld microphones with cardioid, supercardioid, or hypercardioid capsules. Cardioid is often the best choice as it is most forgiving for poor microphone technique, often with a pick-up angle of 120-130 degrees. In smaller rooms, beam forming microphones may be appropriate for presenters if audience capture is also required.
      When audience audio from the room must be captured (e.g. a group discussion or practical demonstration), an appropriate audience microphone solution must be employed. See ‘Microphones’ in Audio for Conferencing for further information on microphone options.
      Where possible, reduce any ambient room noise as it will be captured by microphones and reduce the signal-to-noise ratio of recordings.
    Where possible, reduce acoustic reflections from sound within the room. See Acoustics in Teaching Spaces for further information.
    Line level Audio:
      Ensure recorded audio is free of any hum or noise that may be caused by poor grounding
      Wherever possible, use balanced line level in the signal chain from input devices to the recording device. This will improve the signal to noise (SNR) ratio of recorded and streamed content, as well as minimise audio artefacts which can be distracting for audiences.
    Processing and Mixing:
      Employing Digital Signal Processing is recommended to produce optimal audio and provide routing options to other devices e.g. hearing augmentation, amplifiers, line outputs etc. The ‘Mixing’ section of Audio for Conferencing explores some
      Ensure signals are equalised naturally and simple high-pass filters are engaged at appropriate frequencies to filter out unwanted low frequency and handling noise.
      Avoid overuse of dynamics processing and noise gates which can sound unnatural if set inappropriately for quiet or loud talkers.
      Use microphone priority settings to ensure the presenter microphone will duck all other microphones when used.
      Use modest noise-reduction processing only if required for noisier environments. Over-use of noise reduction can be processor-intensive so should be used sparingly.
      Employ gating auto-mixers with a NOM (Number of Open Mics) of at least 2 and 3 at the most.

Scheduled Recordings

A basic requirement of any lecture recording systems is that it must be schedulable based on the timetabled courses of a class. Whilst this is not always supported directly, off-the-shelf third-party integrations as well as custom processes are commonplace in educational organisations throughout Australia and New Zealand.
Automated scheduling of lecture capture based on timetabling systems allows presenters and audiences the comfort of knowing the session will be recorded without them needing to do anything but focus on educating and learning.
Automated recording also reduces overhead of mundane administrative tasks and allows recording system admins to focus on more important tasks pertaining to support of the service.
Scheduled recordings are also useful for one-off or a series of events, and can be achieved via both hardware and software solutions.
The decision as to whether to record none, some or all sessions is largely an organisational decision and ICT/AV technology managers must ensure they are able to support the required capacity and frequency.

Ad-Hoc Recordings

Ad-hoc recordings are still required from time to time (e.g. last-minute class changes, non-scheduled sessions, guest speakers or students wishing to capture their presentations).
Hardware recorders can be used for ad-hoc capture by implementing simple web links to allow users to log in to the recording system portal and trigger a capture.
Another simple way to handle ad-hoc recordings can be to utilise the software application provided by lecture capture systems to record and save media locally to a USB stick or to the resident computer for upload to learning management system or cloud storage services.

Recording Status Lights

Recording lights provide feedback to in-room presenters and audiences so they are aware that a recording is currently in progress. A series of third-party USB devices are supported and can typically be found on the websites of lecture capture manufacturers and service providers.
Recording lights may be compatible with hardware recording appliances, or are often plugged into a resident computer which runs a small application to relay the status of a hardware recording software to the USB light.
When deploying recording lights, consider the following as a general guideline - local decisions may differ:
    Decide which feedback status is important for users - an example is below:
      solid green light - system is detecting audio, video and is ready to record;
      flashing green light - a recording is about to start;
      solid red - a recording is currently taking place;
      flashing red - a recording is paused;
      solid yellow - error: system is unable to detect audio and/or video.
    Establish with educational designers whether the light requires text (e.g. RECORDING IN PROGRESS) or if a simple colour-changing light is suitable.
    Ensure the presenter and audience can see the light, but it is not in a distracting location (e.g. directly between the presenter and audience).
    Ensure the recording light’s position and brightness is set appropriately to avoid adversely affecting any cameras that are used within the venue.
    Standardise the deployment of lights across the fleet once parameters are defined and agreed upon for a consistent user experience.

Recording and Streaming Solutions

When considering a recording solution, an understanding of the desired audio, video and content capture is required. The tables below align functional requirements with appropriate AV solutions for each approach; software or hardware.
Best practice provides students with as near an experience as possible to that within the physical room in which the recording took place; including sound, and vision of the presenter, audience (where discussion takes place) and content sources.
In all scenarios a Digital Signal Processor (DSP) is recommended to allow high quality audio, signal processing and routing to other audio outputs (e.g. amplifiers, hearing augmentation). See Audio Systems and Public Address for more information.
The solutions recommended in this section can be used consistently across all spaces, or a combination can be used to best fit the technology fit-out of a space type.

Software-based Recording and Streaming Solutions

Software client solutions have evolved significantly to the point where an organisation may choose to deploy software-only solutions to much of their learning environments, provided they meet the defined use cases. Recording software common features include:
    Software running on computer device, or mobile device (tablet or phone)
    Desktop capture (including audio)
    Capture connected audio and video devices (USB webcam, USB capture cards, USB sound cards, direct audio and microphone inputs etc.)
    ad-hoc (via software) and schedulable capture available
Software recording solutions must share the computer system’s processing, memory and video card which makes this approach potentially less reliable than dedicated hardware devices.

Define the Scope

Ingest Method and Combined Sources

Define the video, audio, and data source requirements for input to the recording system:
AV Sources
Description
AV System Design Requirements
Fixed Ingest Sources
Video and audio source is permanent and consistent
Video and audio signals may be connected directly to lecture capture appliance (hardware) and/or computer with recording software
Switchable Ingest Sources
Video and audio sources may be any one selected from available sources. May have the ability to switch sources during recording session
Video: AV switcher, matrix switcher, Audio: Mixer, Audio Digital Signal Processor (DSP)
Fixed Combined Ingest Sources
Video sources may be combined (PiP) and audio sources may be mixed as video is encoded
Video: AV PiP or windowing processor
Audio: Mixer, Audio Digital Signal Processor (DSP)
Distributed Recording (Multi-Camera Recording)
Multiple video and audio sources may be recorded as a single session / stream. Viewers may switch between sources during playback
Video and audio signals may be connected directly to multi-input lecture capture appliance (hardware) and/or uploaded to video content management system (software)
Annotation – Video Overlay
Video content may be recorded with a digital annotation overlay
Video: Annotation video processor with HID input from touchscreen or keyboard/mouse

Content Management and Distribution

Define the method of managing and distributing recorded video content:
Content Management Method
Description
Video Content Management Requirements
User-Managed
Encoded video file and session data is saved to onboard storage, SD card, or USB storage. May be saved direct to lecture capture appliance or user’s computer
Distributed freely by USB storage media, email, shared drive, or cloud-based storage service
On-premises Video Content Management Server
Encoded video file and session data may be uploaded to a centralised on-premises video content management system
Web browser-based video content management and delivery platform.
Server software installed to on-premises computer hardware
Cloud-based Content Delivery Network (CDN)
Encoded video file and session data may be uploaded to a third-party cloud-based CDN platform (ie YouTube, Vimeo, et al)
Web browser-based video content management and delivery platform.
Server software accessed via cloud-based computer hardware
Live-Streaming – One-to-Many
Encoded video is streamed and recorded in real-time to a third-party CDN. The CDN manages distribution of the live-stream to audiences connected via the internet.
Live-streams may be saved as a video file for viewing after the fact
Web browser-based, video content management and delivery platform with support for live-streaming.
Server software accessed via cloud-based computer hardware
Webinar – Many-to-Many
Encoded video of instructor content is streamed and recorded in real-time to a third-party CDN. A group of connected users may view the instructor content, and interact in real-time. Connected users may interact with the group through chat, camera, voice, and/or file-sharing.
Webinars may be saved as a video file for viewing after the fact
Webinar content delivery platform facilitating instructor-led seminars over the internet and the capability for viewers to interact and engage with the group.
Server software accessed via cloud-based computer hardware
Data – Comment Sections
Users may comment on the video
Web browser-based video content management and delivery platform with support for comment sections
Data – Live Comments (Superchat)
Users may discuss or comment on a live-streamed video in real-time providing more context for their comments
Web browser-based, video content management and delivery platform with support for live-streaming and live-commenting

Viewing and Streaming

Define the method of viewing and streaming video content:
Viewing Method
Description
Viewing Requirements
Lecture Capture Appliance
Playback of encoded video file and session data through lecture capture appliance
AV system for presentation of lecture capture appliance output
Video Playback Application – Filesystem
Playback of encoded video file and session data video by opening the content in a video playback application installed on the end-user PC or mobile device
Video playback application installed on end-user PC or mobile device
Video Content Management and Delivery System – Web Browser-based
Playback of encoded video file and session data through web browser-based video delivery platform.
Content delivery server may be on-premises or cloud-based
PC or mobile device running a compatible web browser application (ie Chrome, Safari, Firefox, et al)

Recorded Content Creation Rate

Calculate the estimated creation rate of recorded content as follows:
      Given N is number of rooms featuring lecture capture
      Given H is amount of average hours of recorded content per day per room
      Given R is the estimated total amount of recorded content per day
      R = N x H
    Example: If there were 5 rooms with lecture capture capability creating an average of 3 hours of video content per day, the organisation estimates that a total of 15 hours of video content will be added to its content library per day.

Data Retention Policy

Determine the length of time the recorded content may be available for viewing before it is archived or permanently deleted.

Quality Requirements

Define the quality requirements for encoded video recorded content:
    Video codec
    Image resolution
    Frame rate
    Colour bitrate
    Video compression:
      Data rate (Kbps, or Mbps)
    Audio quality:
      Option to remove audio track
      Mono, stereo, or multi-channel
      Uncompressed (WAV, PCM, AIFF)
      Compressed (MP3, AAC)
      Bitrate
      Samplerate
The higher the quality of encoded video, the more storage space required per second of recorded content. An organisation’s decisions when determining the quality requirements for lecture capture should take into account any ICT architecture limitations (disk storage and data traffic transmission capacity).

Encoded Video File Size Calculations

Calculate encoded video file sizes by the following:
      Given D is the encoded video data rate in Mbps
      Given M is the encoded video length in minutes
      Given F is the file size of video content in GB
      F = D x M x 0.0075
    Example: A 3-hour of video encoded at 7.35Mbps will be 9.92GB
The calculation may be inverted to conform to ICT architecture limitations.
Calculate total minutes of recorded content by the following:
      M = F / (D x 0.0075)
    Example: If the total disk space available is 2TB, and the data rate is 7.35Mbps then a total of 36,281 minutes (604 hours) of content may be stored.
Calculate optimum data rate by the following:
      D = F / (M x 0.0075)
    Example: If the total disk space available is 2TB, and 1,000 hours of content must be stored, then the optimum data rate is 4.44Mbps

Key Components

A lecture capture system is composed of three key components:
    Ingest: Encoding and recording of video, audio, and data sources
    Management: Content storage, transcoding, cataloging, and delivery
    Playback: Decoding and playback of video data

Ingest Methods & Best Practice

Ingest covers the audiovisual sources, video encoding, and digital file creation aspect of a lecture capture system.

Video Encoding Hardware and Software

Lecture capture ingest may be achieved by hardware appliance, or software:
    Hardware appliance common features:
      Digital video inputs (HDMI, DVI, or SDI)
      Analogue audio inputs (mic or line level)
      Capture connected USB video and audio devices (webcam, microphones, et al)
      Digital video output port
      Line level output port
      Ethernet port (video streaming over IP network, upload to shared file system or ftp, third party control)
      Storage (onboard, SD card, or USB storage media)
      PiP function (multiple digital video inputs)
    Recording software common features:
      Software running on computer device, or mobile device (tablet or phone)
      Recording function may be included as a feature of Unified Communications or webinar software
      Capture desktop (share screen)
      Capture connected USB video and audio devices (webcam, microphones, et al)
      Capture digital video input
      PiP function

Multi-Stream Recording

Multi-stream recording (aka multi-camera recording) is a lecture recording method whereby multiple individual video sources are captured in real time and saved as a single recording session. During playback, all streams are frame-synchronised and viewers may freely switch between or overlay (PiP) the available video content streams.
Example: A recorded lecture session includes two available video streams. One is the presenter’s shared screen showing a slide deck, the other is a camera showing the presenter’s face. The slide deck may contain important visual information, by making a selection via the video playback software the viewer chooses to show only this and hides the video showing the presenter’s face.
This feature requires that the ingest hardware or software is compliant with the video content management system.

Encoded Video Best Practice

Video encoding best practice as it relates to lecture capture:
    Confirm the video resolution, colour bitrate, and framerate matches the quality requirements for recorded content
    Confirm the video encode data rate and compression matches the quality requirements for recorded content
    Calculate the estimated hours of recorded content to be created each week. Confirm the total recorded content disk space requirements will not exceed the ICT architecture data storage or transmission rate as the library of recorded content grows
    A copy of encoded video content may be archived at the highest possible quality to futureproof the video content library should the ICT architecture be upgraded

Video Capture Methods

Digital video capture best practice:
    Confirm the camera, or video-outputting device specifications match the quality requirements for recorded content
    Confirm any video processing or signal extension (ie HDBaseT) present in the signal chain will not compress, degrade, or downscale the recorded content
    Confirm the video resolution, colour bitrate, and framerate matches the quality requirements for recorded content
    High-bandwidth Digital Content Protection (HDCP) will block the digital video output (DisplayPort, DVI, HDMI) of a device if an unauthorised receiving device is detected. All lecture capture, and video recording devices are not authorised to record content with HDCP-enabled
    It is illegal to use adaptors, convertors, or software to bypass or disable HDCP
Common sources and processing equipment deployed for digital video ingest:
    Sources:
      Cameras – pan/tilt/zoom
      Cameras – fixed shot
      Overhead document cameras
      Webcams
      Mobile device camera and microphone
      Computer presentation content
      Media playback devices
      Video conference
    Signal processing equipment:
      Audio visual switcher / matrix switcher (switch between video source inputs)
      Picture-in-Picture (PiP) / windowing processor (combines multiple video sources into a single video signal)
      Annotation processor captures touchscreen or keyboard/mouse activity and renders a digital annotation overlay onto an incoming video signal
      Video distribution amplifier (may be used to deploy a redundant video encoding device for critical applications)

Audio Capture Methods

Audio capture best practice:
    Microphones:
      When a single person’s voice must be heard clearly and distinctly, use lapel or handheld microphones with cardioid, supercardioid, or hypercardioid capsules. Position the microphone just below the person’s chin or clipped to the lapel.
      When noise from the room must be captured whether it be a group discussion or room activity, use omnidirectional or multi-array microphones. These may be suspended from the ceiling or placed on a table centre to the general noise source area.
      Where possible, reduce the loudness of any ambient room noise captured by microphones
      Where possible, reduce acoustic reflections from sound within the room. ### Refer to Chapter on Acoustics ###
    Line level Audio:
      Ensure recorded audio is free of any hum or noise that may be caused by poor grounding
      Where possible, use balanced line level for signal transmission
    Use a noise-gate to filter out any ambient room sound
Common sources and processing equipment deployed for audio capture:
    Sources:
      Microphones (wired or wireless)
      Audio playback devices (PC, media player, et al)
    Signal processing equipment:
      Audio Digital Signal Processor (DSP)
      Audio mixer
      Audio distribution amplifier

Video Content Management Systems

Video content management systems covers the file data storage, library categorisation, and video delivery aspect of a lecture capture system. Comprehensive content management systems may also include user access, transcoding, and metadata.

Video Content Management Best Practice

    Categorisation
      Define the video categories
      Categorisation may be achieved by metadata features of the video content management platform, by specific naming of the video file, or by named folders on a file system
      Categorisation may be by instructor, date, subject, class, or by student. The organisation is free to determine the best method of categorising the video library
      A video library without categorisation will make it difficult for users to find the right content
    Codec and file formats:
      Use consistent file formats and codecs
      If uploaded videos are of varying codecs, data rates, and quality settings consider transcoding each video file to a uniform format and quality
      If the content management platform features Adaptive Bitrate (ABR), transcoding processes will be handled automatically

User-Managed Distribution Method

At the end of a lecture capture session, an encoded video file is created and saved to the connected storage of the encoding device. The file may then be distributed, edited, or deleted as required.
User-managed distribution considerations:
    Files may be distributed by email, shared file system, or cloud-based file storage
    Suited to small or infrequent lecture capture requirements
    Access to video files, and intellectual property controls may be difficult to manage
    File naming and quality standardisation and consistency may be difficult to manage

On-premises Video Content Management Server

Enterprise-class server software to manage a library of digital video content data.
On-premises content management server features and considerations:
    Commonly accessed via web-browser interface
    Accessed over LAN, WAN, or internet network connection
    User accounts (software feature dependent):
      Administrators may set video access controls per video per user
      Viewing history
      Preferences
      Notifications
      Comments
    Facilitates categorisation and indexing of video content library
    Includes search and browsing features to find indexed videos and content
    Video file download to user’s device
    Web-browser video playback features (software feature dependent)
    Common video streaming protocols:
      RTSP Real Time Streaming Protocol
      RTMP Real Time Messaging Protocol
      MMS Microsoft Media Server
      HTTP Live Streaming (HLS)
      MPEG-DASH (open standard used by Netflix, Google, Microsoft, Samsung, et al)
      Smooth Streaming and ABR adaptive bitrate
      WebRTC plugin-free peer-to-peer communication (not suitable for large, complex audiences)
    Commonly uses SQL database for indexing and categorisation
    Must be factored into ICT architecture design:
      Video data rate and compression and how this may impact disk storage, and network traffic transmission rates
      QoS and traffic shaping to prioritise video packets

Cloud-based Content Delivery Network (CDN)

Third-party video content management service and distributed network for video streaming. Facilitates video delivery via the internet and HTTP communication to large audiences.
Cloud-based CDN features and considerations:
    Commonly accessed via web-browser interface
    Accessed over internet network connection only
    User accounts (software feature dependent):
      Admin may set video access controls per video per user
      Viewing history
      Preferences
      Notifications
      Comments
    Facilitates categorisation and indexing of video content library
    Includes search and browsing features to find indexed videos and content
    Video file download to user’s device
    Web-browser video playback features
    Live-streaming features (CDN platform dependent)
    Webinar features (CDN platform dependent)
    Common video streaming features:
      Chunked delivery (segmented video delivery allows users to jump to any section of a video and begin streaming)
      HTTP communication (allows information to be sent across internet, local LAN or corporate WAN
      Nonlinear stateless interaction (client may request next video segment independently of the previous requested segment)
      Cache-friendly (modern streaming works with HTTP caches)
      Adaptive Bitrate (ABR) playback (connection speed, quality, and device types may impact the ability to stream video at certain quality settings, ABR automatically adjusts the video quality as the video plays)
    Common Video Streaming Protocols:
      HTTP Live Streaming (HLS)
      MPEG-DASH (open standard used by Netflix, google, Microsoft, Samsung, et al)
      Smooth Streaming and ABR adaptive bitrate
    Must be factored into ICT architecture design:
      QoS and Traffic Shaping to prioritise video packets
    Reduces ICT architecture resource requirements

Playback Methods

Video content playback covers the file data delivery, decoding, and playback aspect of a lecture capture system.
Playback of recorded video content depends largely on the content management method, and ICT architecture and guidelines regarding the distribution of digital video assets. A user-managed distribution method may mean that video files are emailed to recipients to view on their personal devices. A video content management system may allow users to playback videos from a large library via a web-browser interface.

Hardware Appliance

A media player device capable of decoding and playback of digital video files and content. A lecture capture hardware appliance is commonly also capable of playback of recorded content.
Hardware appliance common features:
    Digital video output port (HDMI, DVI, DisplayPort)
    Line level output
    Ethernet port (streaming, upload to shared network file system or ftp, third party control)
    Storage (onboard hard drive, shared network file system, SD card, or USB storage media)
    Limited video codec compatibility

Video Playback Software

The digital video files may be played directly from a file system and operating system of a computer device. Video playback software is used to open and decode the video file for playback on the user’s computer.
Video playback software considerations:
    Video files may be stored on the user’s computer or USB storage media
    Low impact to ICT architecture and network traffic
    Playback of video files does not require network connection (once transferred to user’s computer)
    Flexibility to use software for decoding and playback of any video codec
    User access, and intellectual property controls may be difficult to enforce

Video Delivery via Content Management System

The Video Content Management System is accessed via web-browser interface. Playback of recorded video content is achieved in-browser by using standard HTTP communication. Recorded video content is accessed through a web-browser connecting over LAN, WAN, or internet.
Content Management System common features:
    May be referred to as “Corporate YouTube” or “Private YouTube”.
    Many content management solutions have adopted features that are commonplace for video sharing websites
    Commonly accessed via user’s PC, or mobile device
    Commonly accessed via web-browser application, although some content management solutions may feature an application for viewing video content
    May integrate live-streaming capability via Content Delivery Network (CDN)
    May feature playback of multi-stream recording sessions whereby the user may select from multiple video streams during playback
    May include webinar instructor-student interactivity
    May include Unified Communications features
    User accounts
      Admin may set video access controls per video per user
      Viewing history
      Preferences
      Notifications
      Comments
    Consistent user experience for all users
    Ubiquitous intellectual property controls may be deployed (ie video playback must be in-browser)
Last modified 2mo ago