End User - Streaming Video Content

This use case was discussed during DCAT Meeting August 2014 

On the technical side of this, people argued that the video to be streamed may not always reside in DSpace directly. Different options:

• The video is a DSpace bitstream and gets streamed straight from DSpace
• The item links out to a stream stored on an internal institutional streaming server
• The item links out to a video stored on a platform not controlled by the institution (Vimeo, youtube, ...)

Terrence W Brady made it clear that handling the permissions for streaming may get trickier if the file is not stored as a DSpace bitstream. Also, even if it is, the current "READ" permission may be too limited and there could be need for DOWNLOAD vs STREAMING permissions.

Kim Shepherd is looking at this from the committer/developer perspective and wants to support flexible configurations to enable DSpace to deal with these different situations. File conversions and being able to guarantee that streaming works for particular formats is tricky because some file formats are containers for other formats/encodings.

Streaming protocols that were discussed included HLS, RTMP and DASH

From a preservation standpoint, I would favor that DSpace holds a copy of the object, or at the least, has a reference to a URI to the object. There's plenty of benefits of DSpace managed content, i.e. verify that file still exists, verify file integrity / checksum. Also, if its necessary to pre-process the video before it can be viewed (i.e. YouTube needs atleast 10 minutes to process an uploaded video), then DSpace could have (curation) tasks that send the video to a video encoding/streaming web service (institutional - unlikely to have integration API, remote - likely to have integration API). Another reason for DSpace to be a broker, is that if you had to alter the permissions of the object, then perhaps DSpace could push a message to the video web service (if integrated) to restrict the video.

The low-tech solution is progressive download, where DSpace has the video in the repo, and you add a player to the Item view page, and the video buffers, and plays in the browser, you won't be able to seek/jump to position in the video until the video has progressively downloaded to that position. Realistically, progressive download (with video stored in DSpace), might be sufficient to solve the community need for video.

Perhaps yet-another-option is if you could built some type of video streaming/transcoding engine inside of DSpace. Though, there's no guarantee that that is possible, or the performance would be sufficient, and is a bit of scope creep of the DSpace mission. I'm thinking something similar to a JPEG2000 server embedded in DSpace.

Note: End User - Visitor can play media hosted on an external streaming media server has some details for content on a media server.