DEV Community

Zhe
Zhe

Posted on

Two Different Video Problems: Upscaling Pixels and Extending Time

The bug report behind “make this video better”

That sentence can mean a source is too small, compression damaged edges, motion is uneven, or the clip ends too soon. An interface becomes easier to use when these intents are named before submission. This is an interface-level proposal, not a claim about a vendor backend.

Separate the two jobs

The public PhotoGenerator AI site exposes video tools. Upscale Video presents an upscale factor and frame-interpolation choices. Extend Video is positioned around making clips longer for Reels, demos, and Shorts.

A small state model keeps the jobs explicit:

type VideoJob =
  | { kind: "upscale"; factor: 1 | 2 | 3 | 4; fps: "original" | 30 | 60 }
  | { kind: "extend"; continuationGoal: string };

type JobState =
  | { status: "ready"; job: VideoJob }
  | { status: "processing"; job: VideoJob; requestId: string }
  | { status: "review"; job: VideoJob; previewUrl: string }
  | { status: "failed"; job: VideoJob; message: string };
Enter fullscreen mode Exit fullscreen mode

An upscale job has output settings; an extension job needs a continuation goal. The fields are a design proposal, not a product contract.

Validate by intent

For upscale, review text, faces, edges, color, and frame-to-frame coherence. Severe blur or missing frames cannot be assumed recoverable. For extend, ask what the added section should do and show the last source frame beside the first continued frame.

Keep recovery stateful

A retry should keep the selected file, settings, and continuation goal. Illustrative Playwright coverage:

test("preserves upscale settings after failure", async ({ page }) => {
  await page.getByLabel("Video file").setInputFiles("fixtures/soft.mp4");
  await page.getByRole("combobox", { name: /upscale factor/i }).selectOption("2");
  await page.getByRole("button", { name: /start/i }).click();
  await expect(page.getByText(/try again/i)).toBeVisible();
  await expect(page.getByRole("combobox", { name: /upscale factor/i })).toHaveValue("2");
});
Enter fullscreen mode Exit fullscreen mode

Selectors are illustrative. Do not turn a control label into a benchmark or commercial-rights guarantee. Upscaling changes delivery representation; extending changes temporal structure.

Make the review state useful

For an upscale job, show the source dimensions, selected factor, and frame option beside the preview. For an extension job, show the source end and continuation start as a paired comparison. A progress indicator is useful, but it is not a review criterion. A note such as “text is still unclear” or “the seam changes the shadow” identifies the next experiment better than a star score.

Test the boundaries, not only the happy path

Cover an empty upload, a large file, a source with no visible motion, a failed request, a retry, and a user leaving during processing. For extension, add cases where the last frame is static, the subject exits the frame, or a caption ends at the source boundary. For upscale, compare a clean source with a heavily compressed source and keep the expectation qualitative unless a controlled benchmark exists.

Communicate uncertainty in the interface

Good UX does not hide uncertainty behind a confident label. Explain that output depends on the source and selected settings, and remind users to review faces, text, moving edges, continuity, sound, and captions separately. A feature name is not a complete contract; inputs, preserved state, review evidence, recovery behavior, and boundaries are part of the contract.

Make comparison a product feature

For an upscale job, let a reviewer switch between source and output at the intended display size. For an extension job, make the source boundary visible and replay a few seconds around it. The point is not to expose every internal metric; it is to help a person answer one concrete question about the selected output.

The review model can record why a version was rejected: unreadable text, changed product geometry, unstable facial details, a lighting jump, or a caption that no longer fits. These categories become regression cases later. Keep source assets, job settings, and derived previews distinct in client state so cancellation and retry return to the original brief.

Document non-goals

The tool may improve a source or propose a continuation, but final audio mix, captions, color approval, legal review, and channel-specific export remain separate concerns. Clear non-goals reduce support questions and stop a preview from being treated as a finished campaign asset.

Keep analytics as explicit as the states

The product team can distinguish users who abandon an upscale preview because text remains unclear from users who reject an extension because the seam changes the scene. Those are different product questions and should not become one generic success event.

The review payload should also avoid storing more media than the workflow requires. Keep identifiers, settings, and reviewer notes governed by the product’s privacy and retention rules. A clear state model is useful only if the surrounding data handling is equally deliberate.

Top comments (0)