Asynchronous task processing

Overview

ApsaraVideo VOD, IMS, and MPS support asynchronous media processing. You submit a task through an API call, and the service processes it in the background.

A successful task submission means the task has been accepted, not that processing has started or will finish within a fixed time.

Asynchronous tasks run as offline jobs. Total completion time depends on task scheduling, workload fluctuations, task complexity, source file characteristics, and parameter configuration, and can far exceed actual processing time.

Do not use asynchronous tasks as blocking conditions in latency-sensitive workflows or use the speed benchmarks in this document to estimate production delivery timelines.

Scope

The following asynchronous media processing tasks in ApsaraVideo VOD, IMS, and MPS are covered, including but not limited to:

Media transcoding tasks.
Media editing and compositing tasks.
Snapshot and sprite sheet tasks.
Media analysis tasks.
AI-assisted media processing tasks.
Other media processing tasks that use an asynchronous submission and retrieval model.

Processing pipelines, duration characteristics, status fields, progress indicators, query methods, and notification mechanisms may differ across task types. If capability-specific documentation provides separate guidance, follow that documentation.

General timing guidelines

Review this section before submitting tasks and design your business logic accordingly.

The total time to complete an asynchronous task typically consists of two parts:

Total completion time = Queue wait time + Actual processing time

Where:

Queue wait time: The time between task submission and the start of actual processing.
Actual processing time: The time spent executing the task after processing begins.

Important

A returned task ID only confirms that the task was created successfully.
The completion time you experience is the total completion time, not just the processing time.
Processing speed benchmarks describe typical processing characteristics. They do not constitute service commitments, SLA guarantees, delivery assurances, or grounds for compensation.
Even when task specifications closely match the benchmark scenarios, the total completion time can be significantly longer because of increased queue wait time.
If your business has strict timing requirements, build in buffer time and implement asynchronous decoupling, timeout fallbacks, and graceful degradation.

Total completion time vs. processing time

Understanding this distinction is essential for working with asynchronous tasks.

Speed multipliers and time estimates in this documentation refer only to the speed after actual processing begins.

The time before results become available depends on:

How long the task waited before processing started.
How long the task took to process.

Therefore:

Processing time benchmarks do not equal total completion time.
Processing time benchmarks cannot be used to calculate delivery timelines.
Identical tasks submitted at different times may have noticeably different total completion times.

Queue wait time

After a task is submitted, the service schedules it based on task type, current workload, and processing policies.

Wait times may increase when:

A large number of tasks are submitted within a short period.
Workload fluctuations occur during the same time window.
A high proportion of complex tasks are in the queue.

Note

A successful submission does not mean the task has entered the processing stage.
Wait times can vary based on submission timing, task type, task volume, and processing pipeline differences.
Do not resubmit the same task during the wait period. Duplicate submissions can cause redundant processing and further increase overall wait times.
Use asynchronous callbacks to receive task results instead of high-frequency polling.

To check the current service status:

Increased wait times alone do not necessarily indicate a service issue. Contact technical support to confirm service status.
If a widespread service disruption occurs, Alibaba Cloud notifies affected users through in-console messages, SMS, or other channels.

Actual processing time

Actual processing time depends on task type, source file characteristics, and task configuration.

Common factors that affect processing time

Factor	Pattern	Description
Source file duration	Longer files take longer to process.	A primary factor for most media processing tasks.
Output specifications	Higher output specifications take longer.	For example, higher resolution or more complex output formats.
Algorithm complexity	More complex algorithms take longer.	For example, advanced transcoding or complex analysis.
Custom parameters	More complex parameters take longer.	For example, enhancement parameters or multi-stage processing.
Source file characteristics	More complex characteristics increase variance.	For example, bitrate, frame rate, container format, and stream structure.
Task type	Different task types have different performance models.	Transcoding, editing, snapshot, and analysis tasks are not directly comparable.

Differences across task types

Transcoding tasks: Processing time typically correlates with video duration, resolution, codec, transcoding algorithm, and template parameters.
Editing tasks: Additional factors include the number of segments, whether re-encoding is required, whether cuts cross keyframe boundaries, and multi-segment concatenation.
Snapshot, sprite sheet, and analysis tasks: Duration estimation differs from transcoding. Available progress fields, status fields, and stage breakdowns depend on the specific capability and its documentation.

Task status and progress

Status fields, progress indicators, query methods, and result delivery mechanisms vary across task types.

The following status logic illustrates common stages. Not all tasks follow the same model.

Asynchronous tasks typically go through these stages:

Keep in mind:

Some tasks expose a queryable progress field.
Some tasks return only a limited set of statuses, such as processing, completed, or failed.
For some tasks, the "waiting" state is not a discrete status value. You determine it by combining the status field with other fields.
Check the actual API response and product documentation for exact status definitions.

Transcoding task example

The examples in this section apply only to transcoding tasks. Other task types may use different mechanisms.

Transcoding task states

When you submit a transcoding task, the status field in the query result may show Transcoding.

A Transcoding status indicates that the task entered the pipeline, not that actual transcoding has started.

Use TranscodeProgress to determine the current stage:

Status	TranscodeProgress	Meaning	Interpretation
Transcoding/Submitted	0	The task has not started actual transcoding.	Waiting
Transcoding/Percent/Running	> 0	The task is being transcoded.	Processing
Completed	100 or task complete	Transcoding finished successfully.	Completed
Failed	-	Transcoding terminated abnormally.	Failed

For transcoding tasks, waiting is typically not a discrete status enum value. Infer it by combining task status with transcode progress.

Transcoding speed benchmarks

Important

These benchmarks describe processing speed under typical test conditions after actual processing begins. They exclude queue wait time, do not represent total completion time, and are not service commitments.

The following table lists the processing speed for different transcoding algorithms, using H.264 720p as a reference:

Algorithm	Processing speed benchmark	Description
Standard transcoding	Approximately 3x speed	Reflects processing-stage speed under typical conditions only.
Narrowband HD 1.0	Approximately 1.5x speed	Actual processing time is typically longer than standard transcoding.
Narrowband HD 2.0	Typically well below 1x speed	Processing time usually exceeds source video duration. Actual results vary.

Speed multiplier explained

Speed multiplier = multiple of video duration processed per unit of processing time

Example:
3x speed means approximately 3 minutes of video content is processed per 1 minute of processing time.
A 30-minute video, excluding queue wait time, would take approximately 10 minutes to process.

Note

These benchmarks apply only to the typical H.264 720p transcoding scenario.
They cannot be used to estimate total task completion time.
Higher resolution, more complex codecs, or heavier parameters typically result in lower processing speeds.
Differences in source video bitrate, frame rate, container format, and stream structure can significantly affect processing time.
Narrowband HD 2.0 is typically much more computationally intensive than standard transcoding and Narrowband HD 1.0.
Check the task status query or completion notification for actual processing times.

FAQ

1. Will a 10-minute 720p transcoding task always finish in 3-4 minutes?

Not necessarily.

The "approximately 3x speed" benchmark describes processing speed after the task enters actual processing. It excludes queue wait time and does not represent total completion time.

Actual time to results depends on total completion time. Do not use speed benchmarks to estimate delivery timelines.

If total time exceeds expectations, follow the General troubleshooting steps or contact technical support.

2. Why does my transcoding task show Transcoding status with TranscodeProgress stuck at 0?

A Transcoding status means the task entered the pipeline, not that actual transcoding has started.

When TranscodeProgress = 0, the task is still in the waiting stage. When TranscodeProgress > 0, actual transcoding is in progress.

3. Why is my task taking much longer than the benchmark, even with similar specifications?

Possible reasons include:

The task waited in the queue for an extended period before processing began.
The source file characteristics differ from the typical benchmark scenario.
Task parameters or template configuration is more complex than standard settings.
Workload fluctuations during the same time window increased total completion time.

For further investigation, contact technical support and provide the task ID.

4. Does increased wait time always indicate a service issue?

Not necessarily.

Wait times depend on workload and task characteristics. An increase alone does not indicate a service issue. Contact technical support to confirm service status.

5. Can I use processing speed benchmarks to commit to business delivery times?

No.

Speed benchmarks describe processing characteristics. Do not use them as production delivery timelines, SLAs, or commitments to end users.

For strict timing requirements, build buffer time into your architecture and implement timeout fallbacks and graceful degradation.

6. Can I use the transcoding status model for other asynchronous tasks?

Not necessarily.

The Transcoding and TranscodeProgress fields are specific to transcoding tasks.

For editing, snapshot, sprite sheet, analysis, and other asynchronous tasks, status fields, progress indicators, and interpretation methods may differ. Check the query API and product documentation for each task type.

Key operations

Submit a task

When you submit an asynchronous task through the API, the service returns a task ID.

Save this task ID securely. It serves as the unique identifier for status queries, result notifications, and troubleshooting.

Result notifications

If you have configured a callback URL, the service pushes a result notification when the task completes. Use callbacks to detect completion without polling.

Callback guidelines

Use callbacks as the primary method to receive results in production environments.
If the callback URL is unreachable, the service retries automatically based on a predefined policy.
If delivery fails after multiple retries, use the query API to check the final task status.
Callbacks may be delayed or delivered more than once due to network or client-side issues.
Implement idempotency checks in your callback handler, using the task ID as the key.
The query API is the authoritative source for final task status.

Callback configuration covers setup and retry mechanisms.

Query a task

Query task status and results by task ID in these scenarios:

You have not configured callback notifications.
You have configured callbacks but want to check the current progress proactively.
The task is taking longer than expected.
Callback notifications failed to deliver and you need a fallback method.

Task information queries

The query API returns task status, progress, and results. If a task takes longer than expected, review its status changes, submission time, and configuration. Contact technical support with the task ID if the cause is unclear.

General troubleshooting

When a task takes longer than expected, follow these steps:

Step 1: Check whether the task has completed

Query the task status or result by task ID:

If the task completed, retrieve the result and evaluate the total duration.
If the task failed, review the error code and error message.
If the task is still running, proceed to the next step to determine whether it is in the waiting or processing stage.

Step 2: Determine the current stage based on task type

For transcoding tasks: Combine the Transcoding status with TranscodeProgress to determine whether actual processing has started.
For other asynchronous tasks: Check the query API response fields and documentation for each task type. Do not apply the transcoding model directly.

Step 3: Identify possible causes based on task characteristics

Symptom	Possible cause	Recommended action
No results for an extended period	Workload fluctuations, increased wait time, service disruption, or complex task	Check the service status page. Contact technical support if needed.
Processing time significantly longer than typical tasks	Complex source file, heavy parameters, or high task complexity	Review the source file and configuration. Contact support if needed.
Task failed	Source file issues, parameter errors, or processing exceptions	Review the error code description and follow the remediation steps.
Query returns no results	Incorrect task ID or the task was not submitted successfully	Verify the submission result and task ID.

Step 4: Information to provide when contacting support

To help technical support investigate the issue, provide the following information:

Task ID.
Task submission time.
Task type (transcoding, editing, snapshot, analysis, or other).
Source file duration, resolution, and codec.
Template configuration or processing parameters.
Whether tasks were submitted in batch.
Observed symptoms and scope of impact.

Recommended integration patterns

Method	Description	Use case
Asynchronous callbacks (recommended)	The service pushes results after the task completes.	Production environments and live business workflows.
Polling	Query task status and results on a schedule.	Debugging, testing, and fallback when callbacks fail.

Integration best practices

Use callbacks as the primary method in production.
Avoid high-frequency polling.
Implement idempotency controls when submitting tasks to prevent duplicate submissions.
Stagger batch submissions to avoid short-term queue buildup.
Set up timeout monitoring, alerts, and manual intervention.
Allow sufficient buffer time for critical business scenarios and design graceful degradation strategies.
Do not use speed benchmarks for production delivery commitments.

SLA and responsibility boundaries

If you suspect a service disruption caused delays, contact technical support with the task ID and related information.
Service availability, liability, and compensation are governed by the formal service agreement and SLA.
Task timing descriptions, speed benchmarks, examples, and FAQ content in this document are informational. They do not constitute completion time commitments, compensation grounds, or liability guarantees.

Tips

To minimize the impact of task latency on your business:

Use asynchronous decoupling for media processing tasks in your system design.
Use callbacks or status queries to detect task results instead of blocking synchronously.
Allow extra buffer time for peak periods, batch submissions, and complex tasks.
Implement timeout alerts, manual intervention, and fallback mechanisms.

For further questions, refer to the relevant product documentation.