Rivya References and Uploads Guide

Use this references and uploads guide before you choose a model that depends on image references, video references, or uploaded audio.

References and uploads are a core part of how Rivya tasks move from discovery into signed-in Studio execution.

They affect:

• model choice

• workflow choice

• prompt structure

• task cost

• whether the user should start in a public start page, model detail, or Studio

That is why uploads are not just a UI detail. They are part of the workflow logic.

One operational detail matters early:

• reference-aware pages may be public

• actual file upload currently requires sign-in

So a public start page can still be the right place to begin, but upload-based execution is not fully anonymous in the current product.

Three Upload Shapes

Today, reference and upload behavior in Rivya mainly falls into three shapes:

• image references

• video references

• audio uploads

Not every model supports all three.

That is why the model page matters before the task starts.

Image References

Many image and video workflows support image references.

Depending on the model, reference-image limits can vary a lot.

Right now, that range goes from:

• a single reference image

• larger multi-image workflows

This matters because “supports references” and “supports many references” are not the same thing.

Video References

Some video workflows can also accept video references or other extended reference modes.

These are not universal across the catalog.

That is why users should not assume that every video model can take the same kind of input just because it belongs to the same category.

Audio Uploads

Audio uploads matter most in workflows such as:

• audio cleanup

• audio isolation

• audio transformation

These are structurally different from prompt-first audio generation.

If the model expects uploaded audio, the form behaves differently on purpose.

Why the Form Changes by Model

Rivya's generation forms are model-driven.

That means the visible inputs depend on:

• what the selected model supports

• what file kinds it accepts

• how many files it can take

This is the correct behavior, because a prompt-only model and an upload-first model are not the same workflow.

Current Upload Kinds

The main upload kinds used in current product flows are:

• image

• video

• audio

These are normalized inside the product before they are sent into the final model request.

Current Upload Limits

The upload path currently enforces size and type checks by kind:

Image

• JPEG

• PNG

• WebP

• current default max size: 10 MB

• Nano Banana 2 and Nano Banana Pro currently allow up to 30 MB

Video

• MP4

• MOV / QuickTime

• WebM

• current max size: 50 MB

• Wan 2.6 currently uses a stricter 10 MB cap and accepts MP4, MOV / QuickTime, and MKV-style video uploads

Audio

• MP3

• MP4 audio

• WAV

• AAC

• OGG

• current default max size: 10 MB

These limits are about safe ingestion and routing, not just UI convenience.

References And Model Choice

Reference support often matters more than hype.

For example:

• if the workflow needs many image references, the right model is rarely chosen by brand reputation alone

• if the workflow needs uploaded audio, a standard TTS model is the wrong entry point

That is why the cleanest model-selection order is:

1. output type

2. reference or upload requirement

3. cost and quality fit

4. only then model preference

Public Pages vs Studio

Public start pages are good when you want:

• a first public landing page

• a direct model-specific entry

• a search-driven path into the right workflow

Studio is better when the task needs:

• signed-in upload and execution

• repeated iteration

• more continuity

• a fuller working context

This is especially true once the upload itself becomes part of a longer workflow.

Common Mistakes

Mistake 1: Assuming all models in a category accept the same file types

They do not.

Mistake 2: Picking a model before checking upload support

This often creates avoidable rework.

Mistake 3: Treating uploaded-audio workflows like prompt-only workflows

Those are different paths and should be treated differently.

Reference Workflow

A practical path in Rivya looks like this:

1. check the model page for reference support

2. choose the right public start page or Studio path

3. sign in before the actual upload step if account context is required

4. upload only the kinds the model actually supports

5. keep the prompt aligned with the uploaded context

6. review the result and iterate in the same workflow

Read Next

• Models

• Image Workflows in Rivya

• Video Workflows in Rivya

• Audio Workflows in Rivya

• Public vs Authenticated Workflows in Rivya

• Troubleshooting in Rivya

• AI Image Generator With Reference Images

Reference Upload Checklist

Before a task depends on a reference file or upload, check:

• Confirm whether the task needs an image reference, video reference, audio upload, or no file at all.

• Check the model page for supported file kinds and limits before preparing assets.

• Decide whether the task belongs on a public start page or signed-in Studio.

• Remove sensitive or unnecessary file content before upload.

• Keep the prompt aligned with what each uploaded file should control.

The goal is to make the file useful, allowed, and relevant before spending credits.

When To Recheck Upload Fit

Recheck upload fit when the selected model changes, a file is too large, a reference role is unclear, or the asset contains people, logos, private data, or client-owned material.

In those cases, review Safe Upload Guidelines and the relevant reference page before starting another run.