Page tree
Skip to end of metadata
Go to start of metadata
Title (Goal)DSpace should allow for streaming of video content
Primary ActorEnd User
Scope 
Level 
Story (A paragraph or two describing what happens)

For major video formats, DSpace should allow end-users to stream the content (like Youtube) rather than always requiring that users download the entire file.

  • If a video file is public, anyone should be allowed to stream it
  • If a video file is private (unable to be downloaded unless you have special rights), there should be an option to still allow anyone to stream it. This would allow for the general public to watch the video, but be unable to actually download it. However, by default, private videos are not streamable unless the public streaming option is enabled.

 

 

 

 

 

4 Comments

  1. 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, ...)

    Terry 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

     

     

  2. 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.

  3. This is also connected with IIIF and DSpace (IIIF is widening its scope to video content - see http://iiif.io/community/groups/av/charter/