One kind of failure is especially frustrating. Your reference video plays perfectly on your own computer, but every generation fails, and the error is just InvalidParameter: Bad Request, with no hint about which parameter is wrong. Changing the prompt or the duration doesn't help, and neither does retrying.
We tracked down one definite cause: the video was trimmed, but never re-exported.
The cause: the trimmed-off part is still in the file
Some tools don't actually delete anything when you trim. They write a note into the file saying "start playback at second X" (an edit list), and the trimmed data stays at the start of the file.
- Your player follows that note and skips the beginning, so everything looks fine to you.
- The model's decoder ignores the note, reads data at the start that can't be decoded into a picture, and fails.
The upstream error doesn't name a parameter either, so nobody can see the problem from either end, and you're left retrying.
How to check your file
Run two commands with ffprobe (it comes with ffmpeg):
# 1. Timestamp of the first video packet: negative = this is your problem
ffprobe -v error -select_streams v:0 -show_packets -read_intervals "%+#1" \
-of csv=p=0 -show_entries packet=pts_time your-video.mp4
# 2. Count frames and packets: more packets than frames = undecodable leftover data
ffprobe -v error -select_streams v:0 -count_frames -count_packets \
-show_entries stream=nb_read_frames,nb_read_packets -of csv=p=0 your-video.mp4
We reproduced it locally: we took a normal video and cut its first 3.3 seconds without re-encoding.
| First packet timestamp | Frames / packets | Start time in the file | |
|---|---|---|---|
| Normal video | 0 | 1920 / 1920 | 0 |
| Quick-trimmed video | −3.3 s | 482 / 680 | 0 |
Look at the last column. The file's own start time still says 0, so the usual metadata looks clean. You have to check the first packet.
How to fix it yourself
Re-export it from your editor (export to a new file, don't just save), or re-encode it with ffmpeg:
ffmpeg -i your-video.mp4 -c:v libx264 -crf 14 -preset medium -pix_fmt yuv420p \
-c:a copy -movflags +faststart fixed-video.mp4
When re-encoding, the decoder follows the "start at second X" note, so you get exactly the part you kept. In our reproduction the fixed file had a first packet at 0, 482 frames / 482 packets and a length of 8.03 seconds, which is what the trim should have produced.
⚠️ Don't use -c copy -avoid_negative_ts make_zero. It's a popular "no re-encode" fix online, and it does make the timestamps look normal, but it puts the trimmed part back at the start. In our reproduction the frame count went from 482 back to 680, and the length went from 8 seconds to 11.3. The timeline is clean, but the content is no longer the clip you trimmed.
On XinYu: we fix it on upload
Since September 19, 2026, we check the first packet's timestamp on every uploaded video. If it's negative, we re-encode the file automatically at high quality (crf 14). On the video that originally failed, the result was 45.6 dB similar to the original, which is essentially invisible. Files without the problem are never re-encoded.
After the fix, we resubmitted that same problem video with the same settings, and it went through on the first try.
If you uploaded your video before that date, the old file isn't repaired automatically, and hitting retry on the node reuses the old copy, so it will keep failing. Just upload the same file once more. You don't need to re-export it first.
Other common reasons a reference is rejected
If the timestamps are fine, check these:
- Total length over the limit: Seedance 2.5 accepts up to 30 seconds of reference video in total. You'll be told before submitting if you go over.
- Edit source too short or too long: the source for a video edit must be 4 to 30 seconds long.
- Reference image aspect ratio: Seedance requires reference images between 0.40 and 2.50. See Why Seedance rejected your reference image.