Your Seedance 2.5 API task has completed, and the response points to a generated video. The file downloads, but the result still needs checking.
Perhaps the clip has no audible sound. Perhaps its duration differs from the requested duration. Perhaps it opens in a desktop player but fails in the application where customers will watch it.
These problems require inspecting the delivered media, not repeatedly submitting the same generation request.
This tutorial builds an output-checking workflow with FFprobe, Python, and FFmpeg. It starts with the original generated file and separates metadata inspection, decoding checks, audio review, and playback compatibility.
The workflow also applies when a supported Seedance route is accessed through an AI API gateway. Keep the task response, delivery URL, and downloaded asset connected throughout diagnosis.
1. Start with the original generated file
Use the original downloadable result from the task.
A browser preview, social-media copy, messaging-app download, or edited export may have different properties. It may be compressed, muted, resized, or re-encoded after generation.
Save the original file under a stable local name:
Keep a small record alongside it:
The eight-second value is an example delivery requirement. Replace it with the duration actually accepted for your request and model route.
Do not infer that every Seedance service accepts identical duration values or request parameters.
If your application does not yet preserve task identifiers and recover interrupted downloads, use the existing resumable Seedance API workflow first.
2. Separate generation from file delivery
A completed generation task and a correctly downloaded file are separate checkpoints.
If the download is incomplete, inspecting or transcoding it may produce misleading errors. Confirm that the transfer finished before diagnosing the model output.
Also confirm that the result is actually a video file. An expired delivery URL may return an HTML error page that your application accidentally saves with an .mp4 extension.
The extension does not establish the file’s content.
When the original result remains available, recover or repeat the download before creating another generation task. A transfer problem does not necessarily require another model inference request.
Preserve the original task record while investigating. It distinguishes a delivery issue from a new generation with different output.
3. Inspect the container and streams
Install FFmpeg using a method appropriate for your operating system. Confirm that both utilities are available:
Inspect the original file:
The FFprobe documentation describes these output sections.
The container describes the overall file. Individual streams describe its video, audio, and other media components.
Look for:
- A usable video stream.
- An audio stream when the delivery requires sound.
- Video dimensions and codec.
- Stream and container durations.
- Rotation or other display-related metadata.
Reading metadata does not decode the entire clip. It is a first inspection step, not a complete quality check.
4. Define a delivery policy before comparing results
A useful check needs an explicit expectation.
For example:
These values are a sample application policy. They are not claimed Seedance guarantees.
Your requirements may differ. A social preview, an advertising slot, and a clip intended for editing may tolerate different durations or formats.
Be careful with strict equality. Media duration can be represented through time bases and frame boundaries rather than a perfectly matching decimal string.
At the same time, a generous tolerance should not conceal a materially shorter result. Choose the tolerance according to the delivery requirement and investigate repeated mismatches.
Record this policy alongside the asset so that future checks use the same expectations.
5. Automate basic metadata checks
The following script checks the main video stream, its reported duration, and whether an audio stream exists.
It returns manual_review when essential metadata is unavailable.
Save it as check_video.py:
Run the example policy:
The result metadata_ok means only that these metadata checks passed. It does not mean the clip is ready to publish.
A nonzero exit status can help a batch workflow route the asset into a review queue.
6. Investigate duration differences carefully
Container duration and video-stream duration can differ.
An audio track may extend beyond the last video frame. A container-level value may therefore describe a different boundary from the visual material you intend to deliver.
That is why the script checks the video stream’s reported duration and prints the container duration separately.
When the video duration is missing, the script requests manual review. It does not treat an unknown value as zero or assume the container duration proves the visual duration.
For stricter delivery requirements, inspect frame timestamps and verify the actual visual endpoint.
Also confirm that the expected duration came from the accepted generation request. A value displayed in your application may differ from the payload actually sent.
Checking both the request record and the delivered asset helps identify where the mismatch began.
7. Distinguish missing audio from silent audio
Several different problems can appear as “no sound”:
| Observation | What it establishes |
|---|---|
| No audio stream | The file has no encoded audio track |
| Audio stream exists | Audio data is present, but it may be silent |
| Sound plays locally but not in your app | Investigate delivery and player behavior |
| Sound exists but speech is wrong | The clip needs content review |
| Audio ends early | Inspect the audio timeline and requirements |
If no audio stream exists, a codec conversion cannot recover speech or music that was never present in the original file.
Check whether audio was requested and supported by the selected route. If the request and task records establish an unexpected omission, preserve them for troubleshooting.
If an audio stream exists, inspect it instead of assuming it contains audible content.
The presence of an audio codec is a structural fact, not a quality assessment.
8. Use silence detection as a review aid
FFmpeg provides a silence-detection filter.
For a file with an audio stream, run:
This example reports intervals below a chosen noise threshold for at least one second.
The thresholds are review settings. Quiet dialogue, intentional pauses, and low-volume background music can produce silence reports without making a clip defective.
Use the timestamps to focus listening. Do not automatically reject every detected interval.
The official silence-detection documentation explains the available options.
This check cannot determine whether spoken words are correct, whether music fits the scene, or whether lip movement matches speech. Those are separate content questions.
9. Decode the file before approving delivery
A file can expose readable metadata and still fail during playback.
Run a decoding check:
The uppercase V selects a video stream while excluding attached pictures such as cover art. The optional audio mapping allows the command to process files without audio.
The command decodes the selected media and discards the output. It does not create a replacement video.
Check its exit status and diagnostics. The -xerror option instructs FFmpeg to stop and exit on an error.
A successful decode provides useful evidence about that file and decoder environment. It does not guarantee compatibility with every browser, device, or publishing platform.
10. Diagnose playback failures at the right layer
If the original file decodes successfully but does not play in your application, compare local playback with the delivered asset.
Check whether the application serves the same file and whether the player can access it. Inspect media and network errors before changing the generation prompt.
A download URL that expires before the user opens the page can cause playback failure even when the original video is valid.
For an ordinary SDR clip, test a separate compatibility copy:
This requires an FFmpeg build with the relevant encoders.
Keep the original. Re-encoding can change quality, size, and timing. HDR material requires an appropriate color-management workflow; this command is not a complete HDR-to-SDR conversion recipe.
Test the new file in the actual destination player rather than assuming the conversion resolved every issue.
11. Keep media checks separate from creative approval
A clip can pass metadata and decoding checks while remaining unsuitable for its purpose.
A product may change shape, text may be unreadable, a transition may fail, or the action may not match the prompt.
Technical checks should feed into a separate creative review.
A useful record distinguishes:
- Metadata passed.
- Decode passed.
- Audio reviewed.
- Target-player playback checked.
- Creative result approved.
This makes a rejection actionable. “Video failed” does not tell a developer whether to recover the download, adjust encoding, revise the prompt, or investigate the API request.
If the problem begins with reference images, use the existing Seedance image upload and URL troubleshooting guide.
12. Keep the original and derived files traceable
Once a clip enters an editing or delivery pipeline, several versions may exist.
Keep the generated original separate from compatibility copies, cropped exports, subtitle versions, and compressed previews.
Give each derived file a clear relationship to its source. Record the transformation used and the checks performed afterward.
A playback copy that passes in one browser should not replace the original generation record. The original remains useful when investigating whether a problem came from the model output or later processing.
For batch workflows, this traceability also prevents repeated work. An asset already rejected for a missing audio track should not silently return to the publishing queue under a new filename.
13. Apply the checks to a gateway workflow
When using 4SAPI, first confirm that your account route supports the Seedance model and generation features required by the application.
Retain the requested model, task identifier, delivery response, and original asset together.
The checks in this tutorial operate on the downloaded file. They do not require a universal video endpoint or assume every gateway accepts the upstream payload unchanged.
When a problem appears, use the saved evidence to locate it. A missing track, a failed download, and an expired delivery URL require different remedies.
Start with a small set of representative clips before expanding batch generation. Include the resolutions, durations, audio requirements, and destination players your application actually uses.
Frequently asked questions
Does a completed Seedance task mean the video is publishable?
No. It indicates a task outcome. Your application still needs to inspect the delivered asset and apply its acceptance requirements.
Can FFmpeg restore audio that is absent from the file?
No. It can process existing media, but it cannot recover generated audio that is not present.
Does an audio stream guarantee audible sound?
No. The stream may contain silence, very quiet material, or content that does not meet your requirements.
Should I regenerate after every playback error?
First identify whether the error comes from generation, downloading, encoding, asset delivery, or the player.
Validate one real output before scaling
Open the 4SAPI console, register or sign in, and verify the Seedance route and features available to your account.
Generate one bounded test clip, preserve its task record, and run the checks against the original file. Confirm duration, inspect audio, decode the media, and test playback in your application.
Once that path works, apply the same acceptance policy to additional clips so that failed outputs can be diagnosed consistently.




