This document provides an overview of the timeline for asynchronous tasks, using a transcoding task to illustrate how to interpret task status and estimate processing time. Status fields, progress indicators, and query methods may vary across task types. Always refer to the specific product documentation and the actual API responses.
Overview
Alibaba Cloud ApsaraVideo VOD, Alibaba Cloud Intelligent Media Services, and Alibaba Cloud Media Processing offer a variety of asynchronous media processing capabilities. When you submit an asynchronous task, the service processes it in the background and returns the result upon completion.
A successful submission only confirms that the service has accepted the task. It does not mean the task will start immediately, nor does it guarantee completion within a fixed time.
An asynchronous task is a form of offline processing. Unlike a synchronous API, the completion time of an asynchronous task is influenced by multiple factors, including task scheduling, fluctuations in task volume, task complexity, source file characteristics, and parameter configurations. The total completion time may be significantly longer than the processing time after the task enters the actual processing stage.
Asynchronous tasks are not suitable as blocking dependencies in time-sensitive business workflows. Do not use the processing speed reference values in this document to estimate delivery times in a production environment.
Scope
This document applies to media processing tasks initiated and executed asynchronously in Alibaba Cloud ApsaraVideo VOD, Alibaba Cloud Intelligent Media Services, and Alibaba Cloud Media Processing, including but not limited to:
Media transcoding tasks.
Media editing tasks.
Snapshot and image sprite tasks.
Media analysis tasks.
AI-assisted asynchronous media processing tasks.
Other media processing tasks submitted and retrieved through an asynchronous mechanism.
If separate documentation exists for a specific capability, follow those instructions.
General timeline
Read this entire section before you initiate tasks and design your business workflow.
The total time for an asynchronous task typically consists of two parts:
total task time = waiting time + processing timeWhere:
waiting time: The time a task spends in the queue after submission but before it enters the actual processing stage.
processing time: The time consumed to execute the task itself after it enters the actual processing stage.
Receiving a task ID only confirms that the task was successfully created.
The perceived completion time is the total task time, not just the processing time.
Performance reference values are for illustrative purposes only. They do not constitute a service commitment, Service Level Agreement (SLA) metric, delivery guarantee, or basis for compensation.
Even if a task's specifications are similar to a reference example, the total completion time may be significantly longer due to increased waiting time.
If your business has strict deadlines, build in buffer time and design your system with asynchronous decoupling, timeout fallbacks, and service degradation plans.
Difference between "total completion time" and "processing time"
Understanding this distinction is key to managing expectations for asynchronous tasks.
References to processing speed, speed multipliers, or example times in this document describe only a task's performance characteristics after it enters the actual processing stage.
The time required to receive a result depends on:
How long the task waits in the queue before processing begins.
How long the task takes to process once it starts.
Therefore:
Reference processing time ≠ Total completion time.
You cannot use reference processing times to predict a task's delivery time.
Tasks with identical specifications submitted at different times can have significantly different total completion times.
General waiting time
After a task is submitted, the service schedules it for processing based on the task type, overall task volume, and internal processing strategies.
The waiting time may increase in the following situations:
A large number of tasks are submitted in a short period.
Task volume fluctuates significantly during the same time period.
A high proportion of computationally complex tasks are in the queue.
A successful task submission does not mean that the task has started processing.
The waiting time can vary depending on the submission time, task type, task volume, and differences in processing pipelines.
Do not resubmit the same task while it is waiting. This can cause duplicate processing and increase the overall waiting time.
Use an asynchronous callback to receive task results instead of high-frequency polling.
To understand the current service status, consider the following points:
Waiting time is affected by many factors, such as task volume and task characteristics. An increase in waiting time alone is not a reliable indicator of a service issue. To confirm the current service status, contact technical support.
If a service issue with a widespread impact occurs, Alibaba Cloud will notify affected users via internal messages, SMS, or other channels.
General processing time
The actual processing time depends on the task type, source file characteristics, and task configuration. Different capabilities have different models for estimating task duration.
Common influencing factors
Factor | Pattern | Description |
Source file duration | Longer duration usually means longer processing time | One of the main factors for most media processing tasks. |
Output specifications | Higher specifications usually mean longer processing time | For example, higher resolutions or more complex output formats. |
Processing algorithm complexity | More complex algorithms usually mean longer processing time | For example, advanced transcoding or complex analysis. |
Custom parameters | More complex parameters usually mean longer processing time | For example, enhancement parameters or multi-stage processing. |
Source file characteristics | More complex characteristics can lead to greater time variation | For example, bitrate, frame rate, container format, or stream structure. |
Task type | Different task types have different time models | You cannot directly compare the times of transcoding, editing, snapshot, and analysis tasks. |
Differences between task types
Transcoding tasks: The processing time usually depends on the video duration, resolution, encoding format, transcoding algorithm, and template parameters.
Editing tasks: The processing time is also affected by the number of clips, whether re-encoding is required, whether edits cross keyframes, and multi-clip stitching.
Snapshot, image sprite, and analysis tasks: The time estimation methods may differ from those for transcoding. Refer to the specific product documentation to see if progress fields, status fields, and processing stages are available.
Task status and progress
Status fields, progress indicators, query methods, and result notification mechanisms may differ across asynchronous task types.
The state logic described in this document illustrates the common processing stages of an asynchronous task. Not all asynchronous tasks use this state model.
Generally, an asynchronous task goes through the following stages:
Note:
Some tasks may have a progress field that you can query.
Some tasks may only return a few statuses, such as Processing, Succeeded, or Failed.
For some tasks, "Waiting" is not a distinct status but a phase determined by combining the status field with other fields.
For specific status definitions, refer to the actual API responses and the relevant product documentation.
Example: Transcoding tasks
This section illustrates how to interpret the status and estimate the duration of transcoding tasks. Other asynchronous tasks may use different mechanisms.
Transcoding task status
For example, after submitting a transcoding task, the status field in the query result might show "Transcoding".
Note that a "Transcoding" status means the task has entered the transcoding process, but not necessarily that the actual transcoding has started.
You can use the TranscodeProgress field to further determine the task's stage:
Task status | TranscodeProgress | Description | Recommended interpretation |
Transcoding/Submitted | 0 | Not yet transcoding. | Waiting |
Transcoding/Percent/Running | > 0 | Transcoding is in progress. | Transcoding |
Succeeded status | 100 or task completion | Transcoding finished successfully. | Succeeded |
Failed status | - | Transcoding terminated due to an error. | Failed |
For transcoding tasks, waiting is typically not a standalone status. It is a phase determined by combining the task status and transcoding progress.
Transcoding speed reference
These reference values describe the processing speed of a transcoding task after it starts, under typical test conditions. They do not include waiting time, do not represent the total task completion time, and do not constitute a service commitment.
For a typical H.264 720p transcoding scenario, the processing speed characteristics of different transcoding algorithms are as follows:
Transcoding algorithm | Speed reference | Description |
Standard Transcoding | About 3x speed | Reflects only the processing-stage speed under typical conditions. |
Narrowband HD 1.0 | About 1.5x speed | Processing time is usually longer than standard transcoding. |
Narrowband HD 2.0 | Usually much less than 1x speed | Processing time is usually longer than the source video duration. The actual time depends on the task. |
Speed multiplier
Speed = Multiplier of video duration that can be processed per unit of time
Example:
3x speed means that for every 1 minute of processing, about 3 minutes of video content can be processed.
Therefore, for a 30-minute video, the theoretical processing time is about 10 minutes, excluding waiting time.The preceding reference values apply only to typical H.264 720p transcoding scenarios.
Do not use these values to estimate the total task completion time.
For higher resolutions, more complex encoding, or more intensive parameter configurations, the processing speed is usually lower than the reference values.
Differences in the bitrate, frame rate, container format, and stream structure of the source video can all significantly affect processing time.
The processing complexity of Narrowband HD 2.0 is typically much higher than that of standard transcoding and Narrowband HD 1.0.
For actual processing time, refer to the task status query or completion notification results.
FAQ
1. Will a 10-minute, 720p transcoding task always finish in 3 to 4 minutes?
Not necessarily.
The "about 3x speed" reference value describes a task's processing speed after it starts, under typical conditions. It does not include the waiting time before processing begins, nor does it represent the total completion time of a task in a production environment.
The actual time until the result is available is the total completion time of the task. Do not use the processing speed reference to predict delivery times.
If the total task time exceeds your business expectations, refer to the General troubleshooting section for guidance, or contact technical support.
2. Why does my transcoding task status show "Transcoding" but the TranscodeProgress is always 0?
For a transcoding task, a status of "Transcoding" means the task has entered the transcoding workflow, but it does not mean that the actual transcoding has started.
When TranscodeProgress = 0, the task is still in the waiting stage. When TranscodeProgress > 0, the task has entered the actual transcoding processing stage.
3. My task specifications are similar to the reference scenario, but why is the actual completion time much longer?
Possible reasons include, but are not limited to:
The task experienced a long waiting time before processing started.
The actual characteristics of your source file differ from the typical reference scenario.
The task parameters or template configuration are more complex than usual.
Fluctuations in task volume during the same period caused the total completion time to increase.
To further identify the cause, we recommend that you contact technical support and provide the task ID for assistance.
4. Does an increased waiting time always indicate a service issue?
Not necessarily.
Waiting time is affected by many factors, such as task volume and task characteristics. An increase in waiting time alone is not a reliable indicator of a service issue. To confirm the current service status, we recommend that you contact technical support for assistance.
5. Can I use the processing speed reference to guarantee my business delivery times?
No.
The processing speed reference is only for helping you understand task processing characteristics. It should not be used as a basis for production delivery times, business SLAs, or commitments to end-users.
For business scenarios with strict time requirements, build buffer time into your architecture and implementing timeout fallbacks and service degradation mechanisms.
6. Can I interpret the status of other asynchronous tasks the same way as transcoding tasks?
Not necessarily.
The use of "Transcoding" and "TranscodeProgress" in the example is specific to transcoding tasks.
For editing, snapshot, image sprite, media analysis, and other asynchronous tasks, the status fields, progress fields, and interpretation methods may be different. Refer to the query API and documentation for each specific task.
Key operations
Submit a task
When you submit an asynchronous task through the API, the service returns a task ID.
The task ID is the unique identifier for querying status, correlating notifications, and troubleshooting. Please store it securely.
Get results
After a task is processed, the service can send a result notification if a callback URL is configured. You can use this callback to automatically detect task completion without continuous polling.
Using callbacks
We recommend using the callback method to get results in a production environment.
If the callback URL is unreachable, the service automatically retries according to a predefined policy.
If delivery fails after multiple retries, use the query API to actively check the final task status.
Callback notifications may be delayed or delivered more than once due to network fluctuations or issues on the client side.
Your client-side callback logic should perform an idempotency check based on the task ID.
The final task status should be based on the result returned by the query API.
For details on callback configuration and retry mechanisms, see Callback Configuration.
Query a task
You can actively query the current status and result of a task by using its task ID. This is useful in the following scenarios:
You have not configured a callback notification.
You have a callback configured but need to check the current progress.
The task duration exceeds your business expectations.
As a fallback method when callback notifications fail.
Querying task information
The query API primarily returns task status, progress, and result information. If a task takes significantly longer than expected, we recommend troubleshooting by checking the task status changes, submission time, and task configuration. If you are still unable to determine the cause, you can contact technical support and provide the task ID for analysis.
General troubleshooting
If a task takes longer than expected, follow these steps:
1. Confirm task completion
Query the current status or result of the task using its task ID:
If the task is complete, get the result and evaluate the total time taken.
If the task failed, check the error code and error message.
If the task is not yet complete, continue to the next step to determine if it is in the waiting or processing stage.
2. Determine stage by task type
For transcoding tasks: You can check the "Transcoding" status and "TranscodeProgress" field to determine if the task has entered the actual processing stage.
For other asynchronous tasks: Refer to the fields returned by the query API and the documentation for that specific task. Do not apply the same interpretation method used for transcoding tasks.
3. Identify causes by task characteristics
Symptom | Possible cause | Recommended action |
No result for a long time | Task volume fluctuation, increased waiting time, service issue, or high task complexity | Check the service status page. Contact technical support if necessary. |
Processing time is much longer than usual | Complex source file, intensive parameters, or high task complexity | Check the source file and configuration. Contact support if necessary. |
Task failed | Source file issue, parameter error, or processing error | Check the error code documentation and fix as suggested. |
No result from query | Incorrect task ID or task was not submitted successfully | Verify the submission result and task ID. |
4. Information for technical support
When contacting technical support for troubleshooting, provide the following information:
Task ID.
Task submission time.
Task type (for example, transcoding, editing, snapshot, or analysis).
Source file duration, resolution, and encoding format.
Template configuration or processing parameters.
Specifies whether to submit items in a batch.
Description of the issue and its impact.
Recommended integration methods
Method | Description | Use case |
Asynchronous callback (Recommended) | The service sends the result after the task completes. | Production environments and regular business scenarios. |
Polling | Periodically query the task status and result. | Debugging, testing, and as a fallback for callback failures. |
Integration recommendations
In a production environment, prioritize using asynchronous callbacks.
Avoid high-frequency polling to reduce unnecessary requests.
Implement idempotency controls when submitting tasks to avoid duplicates.
For batch tasks, stagger submissions to avoid creating a large queue in a short time.
Establish a mechanism for task timeout monitoring, alerting, and manual fallback.
For critical business scenarios, reserve sufficient buffer time and design a service degradation plan.
Do not use processing speed references for production delivery commitments.
SLA and scope of responsibility
If you suspect a task delay is caused by a service issue, contact technical support and provide the task ID and related information for assistance.
Service availability, liability, and compensation are governed by the official service agreement and Service Level Agreement (SLA).
The task duration descriptions, processing speed reference values, examples, and FAQs in this document are for reference only. They help explain the asynchronous task processing mechanism and do not constitute a standalone commitment to completion times, or a basis for service or business compensation.
Recommendations
To reduce the business impact of asynchronous task time fluctuations:
Use asynchronous decoupling in your system design to handle media tasks.
Use callbacks or status queries to get task results instead of synchronous blocking.
Reserve extra buffer time for peak periods, batch tasks, and complex tasks.
Establish mechanisms for task timeout alerts, manual intervention, and business fallbacks.
For more information, refer to the relevant product documentation.