UX Design

 https://edx-wiki.atlassian.net/wiki/display/UX/Video+Uploads+in+Studio

Assumptions

1. Video Production process happens before course content creation.  The set of actors (video producers and course authors) may or may not be different individuals.
2. Videos will need to be used across course runs and possibly across courses.
3. An out-of-band manual handshake needs to occur between the VEDA team and the Course Team to properly setup YouTube channels, 3play (for transcript translation), and possibly accounting.
4. Video Producers will upload multiple video files at once.

Video Module

One of the primary building blocks used to deliver course content on the edx platform is the Video Module (an xModule).  Course Authors add a video module to a unit in a course and configure it with various metadata such as video URLs, transcript files, and video download settings.  Currently, course authors manually enter URLs of all encodings of their video into the Video Module's Advanced editor.  The various encodings of a video could be a YouTube link, mp4 and webm versions, and various speeds (.75x, 1x, 1.25x, 1.5x).  While they can manually upload transcripts for the videos, the platform also automatically checks for the existence of transcripts at the given YouTube location. 

See the docs for more information.

VEDA (Video Encoding Processor)

VEDA is a Video Encoding Processing framework that, given a video file, spawns workers to create various video encodings and transcript translation jobs.  Theoretically, VEDA is course-agnostic since videos can be shared across multiple courses and multiple runs of a course.  It is currently not organization-agnostic since "institution"-specific out-of-band accounting and configuration steps must take place before VEDA can be used by an organization.

ARCH NOTE: The VEDA process does not (and need not) run on the same server cluster as the other edX servers, since all communications happen through RESTful APIs.

BEFORE Mobile

Before Mobile came into the picture, VEDA was an optional (paid?) service used by several partners.

...

1. 1. 1. Video producers upload their video file to the institute's folder on the FTP server.
      2. VEDA would create its various encodings and maintain the various video URLs.
      3. The VEDA team would email each institute a spreadsheet with the status and URLs of their various videos and encodings.
      4. The institute could also access a (publicly accessible) webpage with the status of their videos.
      5. The Course team would need to manually enter all the VEDA-supplied URLs into the appropriate video modules.

WITH Mobile via Studio

Now with Mobile in play, it is essential to create video encodings for the various supported screensizes of our edx clients.  As we continue to add support for additional devices in the future (e.g., tablets), our list of required encodings may continue to increase.  As a result, having course teams manually enter and manage all the video URLs of the various encodings is no longer acceptable.  Hence these changes in the video pipeline.

...

Currently, VEDA generates its own ID for keeping track of videos.  For now, VEDA requires a hard-coded structure of its ID.

VAL (Video Abstraction Layer)

VAL is a course-agnostic abstraction layer that is used as a storage and querying service that manages the mapping between edx-Video-ID and Video encoding files.  It now lives in the edx-platform and has RESTful APIs that are called by VEDA and the platform. 

Although theoretically, a single VAL instance can be used by multiple edx deployments (e.g., Stage, Prod, Edge, Sandboxes), it is currently tied to a deployment.  This means, for example, the VAL instance on Stage would not have edx-Video-ID data for videos that were uploaded on Prod.  PROD NOTE: Because of this deployment configuration, we must change course XML import/export to include VAL data along with the course content.  This will be a backward incompatible change since old servers will not know that the VAL data is included and needs to be imported.

Mobile API Endpoint

The Mobile API endpoint needs to return all the videos that are accessible to a given user in a given course.  In order to make this scalable, the API will call the get_items method on the modulestore, which may need to be optimized to return the precise video information needed by the API.  This approach is different than what is currently implemented in Beta.  Currently, in Beta, VAL maintains a table of course-id to edx-video-id mappings in addition to maintaining a mapping between edx-video-id and encodings.  The proposal here is to have the API instead query the modulestore to retrieve all video descriptors with an edx-video-id configured within a course.  The benefits of this change are:

• Allows VAL to once again be course-agnostic as it was before.
  
• Aligns better with the new shift in our modulestore design (introduced by Split) where content is stored independently of course structure.
• Supports rerunning of a course.
  

Performance Considerations

The following areas will need to be carefully optimized for scalability and performance:

• Uploading multiple video files to S3, including API:1@STUD_S3 and API:4@B_S3.
  
• Database queries by VAL to retrieve data for a given set of edx-video-ids: DBR:2@VAL.  API:12@STUD_VAL should support pagination.
• Querying the modulestore for a list of video modules with edx-video-ids in a given course.
  

Advanced Setting

There is a new advanced setting that needs to be configured in order to enable the Video Uploads page in Studio.

...