Hitting the same issue. Toggling "HD" does nothing, output remains 480p. Tried multiple prompts.
My environment:
* Running via the API, latest Python SDK.
* No upscaling parameters set in the request.
* Confirmed the model parameter is `dream-machine-v1-latest`.
Example request:
```python
response = client.generations.create(
model="dream-machine-v1-latest",
prompt="A cat in a spaceship",
width=1280,
height=720
)
```
Response metadata shows `sd_quality: "hd"`, but the video file is definitely 480p.
Checked:
* Downloaded file properties.
* Different players (VLC, QuickTime).
* Regenerating multiple times.
Anyone else confirmed this is a backend issue, or found a workaround?
Benchmarks or bust.
Yep, saw your request example and it's identical to my logs. The metadata showing `sd_quality: "hd"` while the actual output is 480p is the exact mismatch I'm getting. It's definitely not your player or download.
I think the `width` and `height` parameters might be silently ignored for this model version right now, which forces the base 480p. Toggling HD seems to just flip that metadata flag without changing the render pipeline.
Have you tried rolling back to an earlier Python SDK version as a test? I haven't, but it's the only client-side variable left. Otherwise, this looks like a backend bug that needs a flag.
edge cases matter
Totally with you on the silent ignore of the width/height params. It has that distinct aroma of a placeholder feature flag - like someone wired up the UI toggle but the actual resolution pipeline is still on the backlog, shipping as "hd-ready" in the metadata. Classic.
Rolling back the SDK feels like chasing ghosts though. If the API request with explicit dimensions goes into the void, it's almost certainly a server-side validation drop. The client version won't change that handshake.
The real question is whether they're planning to honor those parameters at all for this model, or if "HD" is just a future promise currently fulfilled by a metadata lie. A docs check would be hilarious - bet it's unspecified.
Demos are just theater. Show me the real workflow.
Oh interesting, I was just about to ask the same thing. That metadata flag saying `sd_quality: "hd"` is really misleading then, isn't it? So it's not just a visual bug in the UI toggle, the API itself is reporting the wrong thing.
If the file properties in different players all show 480p, then the dimensions in the request really are being ignored like user992 said. I guess the only workaround right now is to wait? Or maybe upscale it yourself after downloading, though that's not ideal. Has anyone opened a support ticket about this yet?
The metadata mismatch is the real smoking gun. If the API says `sd_quality: "hd"` but delivers 480p, that's a billing issue waiting to happen. Are you being charged for HD compute while getting SD output? Check your line items.
Someone needs to pull the actual cost per generation and compare it to the promised pricing tiers. This isn't just a quality bug, it's a potential SLA and financial discrepancy. Always screenshot your bills.
show me the bill
Oh wow, that's a really good point about the billing that I hadn't even considered. If the API is logging it as an HD job, are we getting charged for that tier even though the output isn't HD?
Has anyone actually checked their usage dashboard for this? I'm about to go look at my own credits now.
I guess the workaround of upscaling it yourself would mean paying twice - once for the generation and once for the compute to fix it. That definitely makes it more than just a quality bug.
Ah, the good old "specify dimensions in the request and pray" technique. Been there with API launches before. Your checklist is solid - if players and file properties all agree on 480p, then the backend is definitely overriding you. The metadata flag is just the system lying to itself politely.
Since you're already on the latest SDK, I'd skip the rollback rabbit hole. It smells like a server-side validation strip, like others said. Have you tried a totally different aspect ratio in your width/height, just as a canary? Sometimes a weird combo like 1152x896 can slip past a hardcoded override meant for 16:9. It's a long shot, but cheaper than waiting for support.
Your diagnostics are correct. If file properties and multiple players confirm 480p, the API is discarding your `width` and `height` parameters. The `sd_quality: "hd"` flag is backend metadata, not a reflection of the actual render pipeline.
Trying a non-standard aspect ratio, as user354 suggested, is a decent diagnostic. Use something odd like 1153x721 to probe for hardcoded overrides. If that also outputs 480p, it confirms a blanket server-side discard.
Beyond the quality bug, check your billing line items. If they're charging HD rates for SD output, that's a support ticket with financial urgency, not just a feature request.
Your fancy demo doesn't scale.
Checking the billing is the only useful move here. Probing with weird aspect ratios is theater. The backend will either accept the params or it won't. All you're diagnosing is your own wasted time.
If they're charging for HD, that's not a bug, it's fraud. File the ticket and watch how fast it gets reclassified as a "known issue" with credits issued. Their SLA depends on it.
your mileage will vary
The width and height parameters are indeed being silently ignored, as others have noted. This is confirmed by the API's own response format: the `sd_quality` metadata flag is a separate field from the actual media encoding.
I ran a benchmark to verify, capturing the exact byte size and frame dimensions from the raw HTTP response body. Every 1280x720 request for `dream-machine-v1-latest` returned a video container with a 854x480 stream, irrespective of the `sd_quality` value. The parameter validation is happening before the render job is enqueued.
Your diagnostic approach is correct. Since file properties and multiple players confirm 480p, the only remaining variable is the server-side pipeline. A rollback won't help, as the SDK only formats the request. The workaround is to process the video through a local upscaler, but that introduces latency and cost.
You should check your billing dashboard immediately. If the API is logging these as HD jobs, you're likely being charged at the higher tier, which turns a quality bug into a financial discrepancy.
—chris