Supported Ingest Formats
Before uploading content to Backlot, make sure you are using a supported file format and following the best practices for source files.
The following table lists supported ingest formats.
|VR 360 Video Codecs||
For more information about VR 360, see VR 360 Videos.
|Muxed/Container Formats||MP4, Mpeg, MOV, MPEG-2 Transport Stream, OGG, FLV, AVI, ASF, Material Exchange Format
(MXF), General Exchange Format (GXF), Matroska.
Note: For Transport Stream files, the extension .ts is not supported.
- File names should not begin with a white space.
- When ingesting with FTP or Aspera, file names should not contain the special character "&".
The following table lists supported file extensions.
|Video Files||wmv, avi, mov, moov, mpg, mpeg, m2t, m2v, vob, flv, mp4, mpg4, mkv, asf, m4v, m2p, 3gp, 3g2, f4v, mp3, m4a, wma, aac, mxf, wav, gxf, fcp, dv, aif, pek, and cfa|
|Frame Rate||Source file with only constant frame rate supported|
|VR 360 Video Files||
|Audio Files||m4a, mp3, wma, aac, wav, and ogg|
|Closed Caption Files||Ingesting Closed Caption Files|
|Thumbnail Files||jpg, jpeg, png, and gif|
Best Practices for Ingestion Source FilesThe following recommendations will help ensure that your source files are ready to provide the best possible results.
Progressive scan, de-interlaced
Source video should be progressive scan (progressive, non-interlaced, de-interlaced) before upload to Backlot. Although Ooyala can de-interlace the content when processing the source video, we recommend that, if you have the resources, you do this before ingesting. This allows you to confirm the quality of your video source assets at the quality control stage of your editorial workflow.
The majority of consumer-level digital displays (such as LED TVs) natively support progressive video. Interlaced content, if improperly de-interlaced, can result in poor quality of display.
If you have interlaced video and you would like help to de-interlace it at the time of ingestion, or if you need help identifying the quality of your video assets, please ask your Ooyala representative during your account trial period or setup.
Square pixel aspect ratio
Source video should have a square pixel aspect ratio. The pixel should not have a non-square aspect ratio, such as anamorphic.
The source video's metadata should not contain a display aspect ratio or rotational metadata. The pixels should be considered square throughout, and there should be no conflicting metadata about the transformation of the video. Conflicting metadata can decrease the quality of video output, because it is not always possible to automatically detect the issue. Typically only a human viewer would notice the type of visual distortion that can result from improper aspect ratio or rotational metadata.
The majority of consumer-level digital displays natively support square pixel aspect ratio content. The use of non-square, or anamorphic, pixels was invented to support technologies like Cinemascope film projection, in which the physical width of the storage medium (film) necessitated compacting the image horizontally to fit. This restriction does not apply in modern digital video, but the use of anamorphic pixels is still present in some video assets created for early television broadcast.
It is possible for the Ooyala ingestion service to force aspect ratio conversion, converting a video with non-square pixels to square pixel output streams. Ooyala support can manually enable this for you in our ingestion processes. If you need to request conversion of anamorphic to square pixels, please speak to your Ooyala representative during your account trial period or setup.