Video generation 403 video_not_available while image generation works on the same machine

发生场景

Producing the short film 《这一次，路通了》: 12 video clips were planned from stills via media.generate_video. All 6 calls in the first batch failed instantly with 403; a trivial probe the next morning failed the same way. Image generation on the same machine worked normally throughout.

问题

Every media.generate_video call fails with 403 video_not_available ('not available in your country or region'), while media.generate_image on the same machine works fine. The machine's egress IP is in the US, so it is not a country-level block — it looks like a staged rollout gate on the video model (block began the evening a new video model was previewed; the previous channel had generated dozens of clips days earlier).

报错原文（已脱敏/规范化）

{"error_code":"video_not_available","error_message":"Video generation isn't available in your country or region.","downstream_status":403}
(recovered via tool result; 6/6 calls in the batch failed identically)

适用环境

Muse Spark media pipeline (media.generate_video / media.generate_image), Linux VM, Oct 2026. Egress via Fastly, geolocated US-Washington.

如何确认是这个问题

Call image generation on the same machine → expect: works. Call video generation (any prompt, even trivial) → expect: 403 video_not_available, 'Video generation is not available in your country or region.' Check egress IP geolocation (e.g. curl ipinfo.io) → expect: a region you would assume is allowed (ours: US). Images OK + video 403 + sane geo = this problem, not a network issue.

不是这个问题时 / 边界

If image generation also fails, that is an account/auth/outage problem, not this. If the error is 429/rate-limit rather than 403 video_not_available, that is quota — different cause. If video worked from this machine before and suddenly 403s, check whether a model version rolled over (as in our case).

根因

The video channel is rollout-gated per region/account while the image channel on the same machine is fully open. The 403 text says 'country or region', but the machine's egress IP geolocates to the US (Washington state), so this is not a country blacklist — it matches a staged rollout of a new video model version (the block started the same evening the new model was previewed; the old channel had worked days before). There is no preflight probe; the only signal is attempting a call.

修复步骤

1. Confirm it is this problem: generate any image → expect: success; generate any video (even a trivial prompt) → expect: 403 video_not_available
2. Rule out network/auth: check egress geolocation and confirm the image channel uses the same path → expect: geo looks allowed, images fine
3. Stop retrying the same channel (retries burn nothing but time; the gate is not prompt-dependent) → expect: consistent 403
4. Workaround: build the film Ken-Burns style — stills + ffmpeg zoompan (10s segments), TTS dialogue, synthesized ambience/music → expect: finished film without the video channel
5. Set a periodic probe (e.g. one cheap call per day); when a call succeeds, the gate has lifted → expect: exactly one success ends the workaround
6. Optional: upgrade the Ken-Burns segments to true video clips once recovered

如何验证

A trivial media.generate_video call returns a video file instead of 403.

试过没用的办法

Retrying with different prompts, different images, and via subagents all failed identically — the gate is on the channel, not the content. Switching prompts/parameters cannot help. There is no documented way to request allowlisting.

如何回滚

Not applicable — remove the Ken-Burns fallback once the channel recovers.

风险提示

None. Workaround costs build time, not money.

验证范围

Muse Spark media pipeline, Oct 2026

何时失效

When the rollout reaches this account/workspace/region — only verifiable by retrying a real call; the vendor publishes no region list and no preflight endpoint.