By Robert T. Wilson and Ellen Dubinsky

Introduction & Background

Maxwell Library serves approximately 10,000 students of Bridgewater State University (BSU). In addition to the traditional library services offered to students, faculty, and staff of the university, the library began collaborating with the campus IT services to provide streaming video content in the early 2000s. In the fall of 2008, the library rolled out Maxwell Video Streaming (MVS), taking on full responsibility for administering the service.

Per the Library Director’s message, disseminated in the library’s fall 2008 newsletter, “[a]lthough not technically a new service, the Library is now managing the entire process: from requests, to verifying copyright compliance, to streaming content, to providing links, to organizing directory structures, to cleanup and maintenance issues.” The library purchased a Helix Universal Server, which was then administered by the campus IT systems group, in order to stream RealPlayer (.rm) files. Though the library provided the monies for the server, other campus entities, such as the radio station, jumped on the opportunity to use the Helix server as well. Students in classes with streaming content were required and instructed how to download RealPlayer to their computers. At that time students were required to have a laptop computer.

The library’s acquisition department purchased video content with the appropriate streaming rights, taking care to follow legal guidelines. The circulation staff had to carefully monitor the streaming of personal videos (titles owned by faculty but not the library), limiting the viewing window to ten days, and not allowing reuse in subsequent semesters for the same course. The limitation to a ten-day window was based on the Library Director’s interpretation and consideration of both the TEACH Act (2002) and the doctrine of Fair Use (17 U.S. Code §107) [1]. That interpretation may have been faulty, but it was the policy adopted when the MVS service was started. The limitations of the short viewing window and re-use served as a catalyst for faculty to request the library purchase those video titles with appropriate streaming rights. Streaming content from materials owned by the library were usually made available for the length of the semester. At the end of each semester, the staff moved these files from the Helix server to another server for “archiving” and possible later reuse. Streaming file versions of personal copies of films were removed from the Helix server and were not archived.

The library circulation staff was charged with transcoding video (VHS tapes and DVDs) to the RealPlayer file format. The URLs for streaming content were shared with faculty via email. The intention was that faculty would embed the URLs within their learning management system (LMS), Blackboard or Moodle, and class sites. In reality, faculty shared the URLs via email, personal websites, and other channels. Though the library staff was cognizant of copyright restrictions and the potential risk of infringing U.S. copyright law, there were no safeguards in place to restrict streaming video content access to just the registered and authenticated students in any class. Additionally, faculty (especially part-time faculty who taught classes at multiple regional higher education institutions) were suspected of sharing the BSU Library’s streaming content URLs freely with non-Bridgewater classes.

It did not take long for staff within the library to express serious concern about potential copyright infringement and the risks that the MVS service presented. In April 2008, three academic publishers had brought suit against Georgia State University for “pervasive, flagrant and ongoing unauthorized distribution of copyrighted materials” through the library’s e-reserve system (Burtle [updated 2017]). While the Georgia State case involved fair use and electronic reserves, fear spread throughout U.S. academic libraries that publishers and distributors would aggressively start pursuing infringement cases or focus on other library services (Smith 2011) [2].

To fully protect the library (and the university) from a copyright infringement claim, we were concerned that:

• streaming content be restricted to only the authenticated students enrolled in a particular course;
• streaming content be available only during the applicable academic semester;
• streaming versions of personal-copy material be available only during a ten-day window and only for one semester;
• users not be able to download and save streaming video files; and
• URLs leading to the streaming content not be discoverable or shared by users.

Any of the above conditions might put the library in the precarious position of having reproduced or distributed the copyrighted content, two of the explicit entitlements of a copyright holder per 17 U.S. Code § 106 [3]. The provision of a streaming service itself (and the showing of films and videos in their entirety) could be defended as within fair use [4], but unrestricted distribution was indefensible.

Current State & Need for Change

Within two years of the launch of the MVS service, several members of the library staff, the circulation staff, the Library Director, Systems Librarian, and Digital Services Librarian, were actively investigating improvements. Usage was increasing as more faculty were requesting streaming content for their courses. Concerns regarding copyright infringement were growing and the problems with emailing URLs, restricting access to only students enrolled in a particular class, low quality video resolution, and management of the ten-day streaming windows for personal videos (not library-owned content) were not going away.

At that time (2010-2011), the library and IT tried to collaborate on the planning and implementation of a better streaming service – one with better copyright protections, better video quality, platform agnostic files, etc. However, at that time relations between the library and campus IT were not always productive and meetings were often contentious. Little progress was made during two plus years of meetings.

In 2013, after some personnel changes within campus IT, productive meetings resumed. Campus IT not only proposed using an outside vendor to offer solutions but also agreed to fund a pilot project. Greystone Solutions was contracted during the summer of 2013 and testing of several options began within months. By April 2014, a project plan was in place and testing began on a workflow using Amazon Web Services (AWS). MP4 video files were uploaded into an AWS Simple Storage Service (S3) bucket. Staff could mark individual files as “public” and in the case of personal-copy video content, manually set start and end dates for public accessibility at the appropriate times. The files were then made available for playback through AWS CloudFront distribution. At the end of the semester, files could be marked inactive and moved from active bucket into an archive bucket for possible use in subsequent semesters.

In fall 2014, Maxwell Library went live with AWS with many video files being re-transcoded at a higher quality. Though an improvement over the previous service in terms of video quality and file management, copyright concerns remained. Library staff had hoped to gain direct access to the courses within Blackboard so that the URLs could be directly embedded into the appropriate course sites. Access to the video content would be limited to only the students enrolled in each particular class since the class rosters were automatically populated in Blackboard at the start of each semester. In theory, URL sharing by email would be unnecessary.

However, direct embedding of the videos never occurred because the Library staff never gained access to Blackboard courses. Many faculty used personal websites or another LMS (such as Canvas) for their courses and continued requesting the URLs for the streaming content. Even when faculty did embed the video URLs into their Blackboard course sites, an unforeseen problem arose: the default video player in Blackboard allowed downloading of the video files and in some browsers allowed accessing the URL of the video content. Attempts to embed an alternative video player (such as JWPlayer [5]) into Blackboard were unsuccessful.

With the arrival of a new Emerging Technologies and Systems Librarian in the spring of 2016, the inherent problems of the MVS streaming service were again investigated. To address this, URLs for video content were placed behind the EZproxy server, thus partially restricting access to authenticated BSU students. Additionally, in an effort to further obscure the URLs, faculty were provided URLs generated by the URL shortener TinyURL [6]. Lastly, the settings for the AWS Cloudfront CDN distribution server were adjusted to restrict access depending on geographic location of a user’s IP address, but those settings were not granular or customizable without additional customization and development which were resources not available to the library. These changes mitigated some of the issues and concerns, but did not fully resolve main concerns. To prompt a more earnest review of other providers, soon after these changes were introduced Adobe announced an official end of life for Flash in 2020 (Warren 2017) which further affected the long-term viability of MVS configuration as streaming video content relied on an Adobe Real-Time Messaging Protocol (RTMP) or Adobe Flash Media Server distribution through CloudFront [7]. Depending on the browser and machine Flash settings, streaming content through RTMP as well as with JWPlayer or alternatives successfully was extremely inconsistent. With no indication from AWS that it was developing an HTML5 media player or something less dependent on Flash, seeking yet another alternative became necessary.

Identifying an Alternative

While so many solutions and acquisition models for streaming video now exist (Ferguson and Erdmann 2016), maintaining control and ownership of the service was still a goal. So, in seeking alternatives, that model was front and center. AWS’s CloudFront has been the premier method of streaming video as far back as 2009 (Bouthillier 2010), but plenty of competition has sprouted up in the years since. Additionally, streaming technology has come a long way. Flash as the dominant format of playback has been waning as devices used for video playback have changed and as HTML5 has become more widespread. Standards and technologies utilizing HTML5 have become more prominent. In regards to streaming, Dynamic Adaptive Streaming over HTTP (DASH) which is an ISO standard for adaptive streaming intended to replace proprietary technologies like Adobe’s RTMP (Ozer 2011) was appealing.  Identifying a service that made use of DASH versus a proprietary technology or Flash-reliant one would be an ideal solution.

The requirements in regards to resolving copyright concerns were still clear on what the ideal service should do, but now there were additional caveats regarding technology that affected long-term viability and user experience. The configuration in AWS only met our needs relating to its low cost and simple staff workflow. In reviewing comparable services, Microsoft’s Azure Media Services [8] and Vimeo Pro [9] stood out as the most viable in addressing library copyright and streaming technology needs and in having large enough communities to draw knowledge and support from if necessary. In testing, Azure Media Services not only contained its own HTML5 media player supporting DASH but allowed a more robust set of configurations and options for customization than Vimeo Pro. While Azure Media Services right out of the box can be used in a similar manner to how Vimeo Pro functions, the storage, web services, and API possibilities as well as the potential of tying into the full range of Azure services made it possible to create a Vimeo-like platform if needed or desired. In the end, Vimeo is a hosted video playback and streaming service while Azure and AWS are  IaaS providers Vimeo or similar services may use as their infrastructure to offer their services. Serendipitously, within a month of looking into Azure as an alternative, campus IT expressed their intention to migrate the university’s infrastructure to Azure where feasible. Being able to rely on their expertise and assistance if ever necessary made Azure more appealing and less of an unknown than Vimeo Pro or further developing services through AWS.

Azure Media Services Configuration & Pilot

In summer 2017, with support from IT and in the brief testing conducted, steps were taken to get up and running with Azure. The steps were similar to AWS S3, CloudFront, and previous JWPlayer configuration work. First, a Media Service had to be created. Once an Azure account was created, creating a Media Service is necessary to stream content. A storage component is created at this time as well for files which are referred to as assets in Azure. However, other storage in Azure can be used. In AWS, this is the equivalent of the S3 and CloudFront services, but unlike them, Media Services is a dedicated space for preparing and managing media content. Next, a user must activate the Streaming Endpoint that is created when the Media Service is turned on. As far as the uploading assets and encoding for multi-bitrate streaming, this is all that is needed. There are options to use external media players as well as using .NET or REST for uploading and encoding assets. These were not explored in the pilot, but suggested how robust the environment could be. The final prerequisite was using an existing server of creating a cloud-instance server to host the HTML files for video playback. Our particular server was a low specification Linux Ubuntu server with Apache web services installed. Access to the server’s HTTP/HTTPS traffic was restricted to the library’s EZproxy server IP allowing the library staff to restrict access to the content to authorized faculty and students only by piggy-backing on the CAS single-sign on (SSO) authentication service EZproxy was using. As an added UX perk, Blackboard was also using CAS. So, user’s accessing content from a URL in blackboard would already be logged into the authentication service.

Figure 1. Comparison of AWS CloudFront and Azure Media Services Configurations.

Once the services needed were in place, the manual workflow for adding and making content available was as follows:

1.  Upload an Asset – In our case this was MP4 files.
2.  Encode the asset using the Media Encoding Standard and Adaptive Streaming tool – This process depending on file size could take some time to complete. One can view the progress of in the Jobs area of the Media Services dashboard. Once the process is complete, a new Asset will appear in the Assets folder as multi-bitrate MP4.
3.  Upload Captions – There are a few additional options for file management, but for accessibility and user experience purposes, being able to easily upload captions if the file was available was very appealing.
4.  Publish, select Streaming, select start and end publish dates.
5.  In the Published URLs section of the asset, view/copy the streaming URL.
6.  Test playback – The embedded Azure Media Player can be activated within the dashboard by selecting the asset and then play.
7.  HTML file – Once the video is playing as desired, library staff would then embed the copied streaming URL into the video source area of an HTML file template provided below. The template could be customized similar to JWplayer comparable players with branding and sizing.

Azure Media Player HTML file example

Figure 2. Example HTML for Azure Media Player Embedded Streaming Video.

Once the HTML file was named and saved, library staff would then upload to the MVS server via FTP/SFTP. That URL, once proxied, could be shared with faculty in whatever way the faculty member preferred. As previously mentioned, this server is only accessible via HTTP/HTTPS from the EZproxy server IP. The result will be a file only accessible to users with valid institutional credentials and will look something like this:

https://yourezproxyurl.edu/login?url=http://mvs.bridgew.edu/somevideo.html.

For the pilot, It was determined that of the faculty utilizing the service, on average, they streamed five items each fall and spring semester. By using the average number of items streamed per faculty member (5) and the average number of faculty that use the service a semester (30), an estimate in costs per semester could be achieved. Working with a faculty member teaching film studies courses who heavily uses MVS, five items of varying quality, length, and therefore file size, were converted to multi-bit streaming files for playback in the Azure Media Player. Working with one faculty member who is versed in the use of the service and familiar with past issues allowed for valuable qualitative feedback from the faculty member and their students regarding ease of access and user experience.

Findings & Future Work

Streaming via Azure Media Services fully resolved security, access and management concerns by allowing for improved management of access by allowing start and end dates of when the file would be available which would control costs of streaming files and address copyright requirements for when and how long items are available as well as reduce workload on staff managing the service. As a bonus, being able to fully control access through EZproxy also had the added option to use groups to more granularly set user authorization either by course number or by a list of student usernames enrolled in a course.

The System Librarian checked in weekly with the faculty member who agreed to participate in the pilot to identify and address any issues experienced. There were no reports of issues in playback or access by faculty member or students, and according to the faculty member, the new method created a more comparable experience to consumer and subscription streaming services. No problems comparable to playback issues seen in AWS related to Flash or JWPlayer were experienced. The items being available in multiple bitrates improved service for users with lower bandwidth available for video playback, and the service included an option to address always important accessibility needs like the ability to upload subtitle transcript files.

While streaming through Azure Media Service addressed many concerns of the library staff, uploading, converting, and creating an HTML file for playback added considerable time for processing each new video request where AWS consisted of transcoding a file to MP4, uploading to S3, and making the URL available in CloudFront. To fully implement the service, considerable upfront costs both in time, staffing, and fees generated by converting each file to multi-bitrate would be required. Regarding fees, streaming costs were found to be much more expensive than current AWS setup. The bulk of the cost appeared due to upload and encoding of the MP4 files to multi-bitrate MP4 files with the cost of streaming, asset storage, and our cloud web server for HTML files accounting for the rest. Since the vast majority of our archive and any new requests would need to be uploaded and encoded, this suggested a very large upfront cost in time and money. It was not explored at the time of the pilot whether it was possible to encode the MP4 files to multi-bitrate MP4 files that were compatible for playback in Azure Media Player before uploading into Azure with third party tools like ffmpeg [10]. If possible, there would be an increased cost per upload as multi-bitrate files are larger in size than single-bitrate. However, this as an option would reduce the cost in encoding, and likely, the overall cost of the service.

The total cost to operate the pilot was $295.00 for the Fall 2017 semester streaming of five items. That number multiplied by the average number of faculty using the service was $8,850 per semester. That figure is multiple times costlier than the AWS MVS configuration. With a large percentage of the cost due to uploading and converting the MP4 files, what would likely be seen is a shift in the cost breakdown from conversion to storage, but due to new items being purchased on a frequent basis, a significant reduction in cost would be unlikely.

Despite Azure Media Services meeting our functional requirements and fully addressing long-held concerns, the cost projections as well as the additional cost in staff time per new item request were reason enough to cease the pilot and explore other options and services. Though the cost relative to other streaming services is quite reasonable especially with how robust the service can be, it was a cost Maxwell Library was not prepared to fund at that time. Shortly after the pilot was completed, a test plan was created to review Vimeo Pro which offers a flat subscription fee that, if found to provide the service, security, accessibility, and user experience required and demanded by faculty and students, may serve as a viable and perhaps more sustainable option due to the library’s budget and staffing.

Bibliography

Bouthillier L. 2010. How to get Started with Amazon Cloudfront Streaming. Streamingmedia.com [Internet]. [cited 2018 Sep 1].
(COinS)

Burtle L. [updated 2017 Oct 29]. GSU Library Copyright Lawsuit. [cited 2018 Sep 1].

Ferguson J, Erdmann A. 2017. Streaming Video in Academic Libraries. American Libraries Magazine [Internet]. Cited 2018 Aug 30]. (COinS)

Ozer J. 2011. What is MPEG DASH? Streamingmedia.com [Internet]. [cited 2018 Aug 31]. (COinS)

Smith, K. 2011. A Nightmare Scenario for Higher Education. Scholarly Communications @ Duke [Internet]. [cited 2018 Sep 2]. (COinS)

Warren, T. 2017. Adobe will finally kill Flash in 2020. The Verge [Internet]. [cited 2018 Sep 5]. Available from:.
(COinS)

Notes

[1] For more information about the TEACH ACT, see http://www.gpo.gov/fdsys/pkg/BILLS-107s487es/pdf/BILLS-107s487es.pdf.  For more information about Fair Use, see https://www.law.cornell.edu/uscode/text/17/107.

[2] For more information, see “What’s at Stake in the Georgia State Copyright Case.” The Chronicle of Higher Education.

[3] Available here:  https://www.law.cornell.edu/uscode/text/17/106).

[4] For more information, see The Society for Cinema and Media Studies’ Statement of Best Practices for Fair Use in Teaching for Film and Media Educators.

[5] Available here: https://www.jwplayer.com/video-solutions/html5-video-player/

[6] Available here:  https://tinyurl.com/

[7] For more information see: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-rtmp.html

[8] Available here: https://azure.microsoft.com/en-us/services/media-services/

[9] Available here: https://vimeo.com/

[10] Available here: https://www.ffmpeg.org/

About the Authors

Robert T. Wilson (robert.wilson@mtsu.edu) is Assistant Professor, Systems Librarian at Middle Tennessee State University. He is formerly the Emerging Technologies & Systems Librarian at Bridgewater State University’s Maxwell Library. http://rtwilson.info

Ellen Dubinsky (edubinsky@email.arizona.edu) is the Associate Librarian, Scholarly Communications at the University of Arizona. She is formerly Digital Services Librarian at Bridgewater State University’s Maxwell Library.