Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Status: Work In Progress.Completed

The video image/poster/thumbnail feature will allow users to see static image on video component before they click play just like youtube. To show the poster on video component (as first frame) we'll provide a way to upload image for particular video via "Video Uploads" page. Since our design for this feature adds a significant infrastructure requirement, we're giving it a dedicated design document.   

Epics:

Manual upload: 

Jira Legacy
serverSystem JIRA
serverId13fd1930-5608-3aac-a5dd-21b934d3a4b4
keyEDUCATOR-203

Auto generated 

Jira Legacy
serverSystem JIRA
serverId13fd1930-5608-3aac-a5dd-21b934d3a4b4
keyEDUCATOR-438

Functionality

  • On Video Uploads page, upload an image for particular video to use as video poster/thumbnail (or replace the existing one)
  • The video image would be specific to course run i.e. changing/adding new image would't impact the other course(s).
  • When a thumbnail is added to a video on the upload page, it should update any component where the video is used.
  • Basic interaction mockup here: http://6qnr7j.axshare.com/thumbnail_upload.html
  • Video pipeline is generating 3 random images from uploaded video and using one of them by default.
  • Moderation: minimal MVP for now

...

  • Show the image on Video component editor (so it's easy for course authors to search for an uploaded video - instead of copy-pasting the video-id)
  • We might need to serve the video image in different sizes, keeping this in mind, we'll design the structure much flexible to accommodate this change.
  • Video pipeline will generate 3 random images from uploaded video and then user(s) can select particular image from those generated onesSelect from auto-generated images.

Upload Video Image End Point

...

  • The uploaded images will include the client_max_body_size directive which limits upload size. The value passed to that directive is also given to the CMS as a second line of defense.
  • The image name will have timestamp which will be stored as part of the image URL. 
  • In production, CDN domains will be used in image URLs. The CDN will be configured to cache on unique image URLS, so that whenever a user uploads a new image, the CMS/LMS starts serving image URLs with the new image URL, causing the CDN to cache a new image.

  • When serving images from disk, caching is configured using the expires nginx directive. When serving images from a CDN/S3, caching is configured by including Cache-Control: max-age in the headers. The value is in seconds in both cases.
  • In prod, stage, and load-test, images will be stored in the same bucket under the prodstage, and load-test prefixes. One CDN serves the entire bucket. In edge, all images are at the top level of the bucket. Edge has its own CDN. In the sandbox environment, each sandbox's IAM role allows it to upload to the appropriate bucket only by prefixing all files with the sandbox's IP address. A single CDN serves the entire bucket. ??
  • Terraform changes will be required to configure the S3 buckets. As an example we'll look into this PR https://github.com/edx-ops/terraform/pull/340

...