Skip to main content

VOD Status

When a video is uploaded and processed, the status field reflects the current state of the file: Workflow:
When playback starts:Playback becomes available immediately when the video reaches Viewable status, even if only a subset of renditions is ready.Additional renditions are appended automatically to manifest.m3u8 and master.mpd as processing completes. When all renditions are available, the status transitions to Ready. So no waiting for Ready is required to start playback.
Example of a response for a video under processing:
If the video fails while uploading and checking, it will remain in “empty” status with details in the “error” field. Most commonly, this happens when an end user uploads a non-video file or has a connectivity issue. In that case, re-upload the video from the origin, or delete the entity and create a new one with the correct video file. Example of the response if an error occurs during video processing:

Uploading process

Process of uploading is described in the Upload video via API article. Briefly:
  1. You create a video (TUS upload or copy from external origin_url).
  2. Backend schedules transcodes for the target quality set.
  3. Each rendition becomes an item in converted_videos. Fields update as jobs run.

Renditions status

Each video entity is transcoded into several qualities – each such individual quality is called a rendition. So for a video entity there is always a set of renditions with specified parameters: quality and size. An array of renditions for each playback of the video entity in API has name of converted_videos. Each element contains playback metadata for the rendition and status of processing. Status lifecycle per rendition:
  • processing – transcode job accepted and running for this quality.
  • complete – rendition finished. mp4_url becomes available and the quality is appended to HLS/DASH manifests.
  • error – rendition failed. Inspect the item’s error string. 
When playback starts:Playback can be started once at least one rendition is complete. Additional renditions appear automatically as they complete. No need to wait for all renditions are ready.
What you can read from each rendition (read more in API GET /streaming/videos/{video_id}):
  • Dimensions and approximate bitrate proxy: width, height, size.
  • Completion percent: progress (0–100).
  • Availability: status, mp4_url presence.
  • Failure reason: error.
  • Name/label for UI or logging: name (e.g., vod720p). 
Transcoder workers report the state of each rendition. The API translates these states into processing, complete, or error, and updates the converted_videos array in the response of GET /streaming/videos/{video_id}. Completion events can also be delivered via webhooks. Read more about Webhooks here. 

Long video processing

The duration of video transcoding is directly proportional to the length of the original video. A 1 minute video will be processed in a matter of seconds. A 10 hour video will take a long time to process, possibly tens of minutes due to a queue of other videos. All renditions are queued at the same time. Remember that the lower the quality, the easier it is to transcode and the faster you can get the result. That’s why SD and other medium resolutions often become available faster than 1080, 2K and 4K.

Error handling

During upload and processing, the API may return errors in the error field of the video object or in a specific rendition (converted_videos[i].error).
Each error indicates the reason why the system was unable to fetch, parse, or process the video file.
If a video remains in empty or pending state for long period, inspect the check the error field and check corresponding converted_videos[].status values for details. In most cases, the video cannot be processed correctly due to problems with the original file. It may not fit to recommended input parameters. If you encounter an error, first check the error message against the list below. Then validate your input (URL, headers, original video file) and retry the operation. If the issue persists or is caused by quota limitations, contact the Support Team. One important class of failures is source inconsistency inside a single file. The transcoder expects the source video characteristics to remain stable for the whole duration of the asset. If the file changes pixel format, color range, codec parameters, or similar technical properties in the middle of playback, transcoding may fail and the video may remain in Error status. For example, if a source changes from yuv420p to yuvj420p near the end of the file, simple reprocessing may fail again because the uploaded source itself is inconsistent. In such cases, the correct fix is usually to re-export the file with stable parameters or trim the broken segment and upload the corrected version. Example:
Other problems you can see in UI and solution are described in the VOD issues article.

Demo video with “viewable” status

We prepared a demo video which has the status viewable and was not fully processed. In this demo video, one quality has a deliberate conversion error. HTML player:
The video itself is already available for playback and download, you can see in the player above. However, the rendition “vod1080p” encountered a storage space limitation problem and has an “error” status. Status:
  • Entity status: viewable
  • Renditions status:
    • vod360p: complete
    • vod480p: complete
    • vod720p: complete
    • vod1080p: error
In master.m3u8 you will see 3 completed renditions:
In API you will see details of the issue: