Home › Datasets › Video Prompt Mastery
AI Filmmaking PackHow to Fine-Tune an LLM for AI Video Prompting
Writing structured prompts for AI video generation — camera movement, motion, temporal consistency, duration, and audio across current text-to-video models.
- 640 instruction-response pairs
- Format JSONL
- Pack AI Filmmaking
- Dataset $39 one-time
$39 for the dataset. Training is priced separately by model, starting at $47.
What can this kind of fine-tuning teach an LLM?
A general-purpose model may already know some of this subject. Fine-tuning serves a different purpose: it repeatedly demonstrates the kinds of requests, response patterns, terminology, decisions and workflows you want the model to handle more consistently.
For Video Prompt Mastery, the dataset focuses on writing structured prompts for ai video generation — camera movement, motion, temporal consistency, duration, and audio across current text-to-video models. Fine-tuning shapes recurring model behavior; it does not turn the model into a live database or guarantee correctness on every new case.
What training data should cover
Useful supervised fine-tuning data should resemble the work you expect the model to perform. This Rebiha dataset's domain definition is organized around 18 coverage areas:
- writing the four-part camera-motion formula: movement and speed, subject anchor, what's revealed, what stays locked; writing a prompt that specifies duration within a model's hard architectural clip-length limit; writing prompts that specify native audio generation versus planning for a separate audio pass; troubleshooting temporal flicker or morphing in a generated clip through prompt adjustment; writing model-specific negative prompts for artifact prevention like waxy skin, rubbery motion, or style drift
- avoiding contradictory camera-movement instructions stacked in a single prompt; writing an image-to-video prompt that constrains motion from a locked starting frame; writing prompts for multi-shot sequences with consistent temporal pacing; specifying physically plausible motion to avoid implausible or unnatural movement; writing prompts for slow-motion or time-lapse effects
- adapting a single scene concept across different video models' preferred prompt dialects; writing dialogue-timing prompts for a two-character conversation scene; writing prompts for multi-character action sequences without losing individual identity; explaining the trade-off between text-to-video and image-to-video for a given shot; writing prompts that specify a locked lighting setup and mood held across a clip's full duration
- diagnosing why a video generation produced a generic default like a static shot with no sound; writing prompts with camera-movement choices suited to vertical 9:16 versus widescreen 16:9 formats; explaining a current model's duration and audio-support limits when recommending an approach for a shot
How Rebiha prepared the training material
This page contains 640 instruction-response pairs from the existing Rebiha dataset. Its domain definition was designed around the coverage areas above so the training material spans multiple realistic tasks rather than one narrow prompt pattern.
Rebiha's broader dataset workflow uses structured quality review to help identify problems such as contradictions, unsupported claims, unsupported assumptions, calculation errors and other weak training examples. You can inspect real examples on this page before deciding whether the dataset fits your model and use case.
What is in this dataset
640 instruction-response pairs covering writing structured prompts for ai video generation — camera movement, motion, temporal consistency, duration, and audio across current text-to-video models. Each pair is a realistic instruction with a full written response, in the JSONL format used for supervised fine-tuning. No synthetic filler, no duplicated rows.
Example pairs
Real rows from the dataset, shown in full.
My Veo 3.1 shots keep looking static even when I write 'camera moves slowly forward.' What's the correct way to structure a camera move so the model actually animates the shot?
Use the four-part camera-motion formula: (1) movement and speed, (2) subject anchor, (3) what's revealed, (4) what stays locked. Write them in that exact order, separated by commas, as declarative instructions. Movement and speed: name the axis and rate — not 'slow push-in' but 'push-in from 2m to 0.5m over 5 seconds, constant acceleration.' Subject anchor: tie the lens to an element that grounds the motion — 'the camera tracks the protagonist's left eye, keeping it at frame-left third.' Reveal: state the new information entering frame — 'the push-in reveals a handwritten letter on the desk that was previously out of frame.' Locked: specify what must not move — 'the background window and its reflection stay optically locked and unchanged.' Example prompt: 'Push-in from 2m to 0.5m over 5 seconds, constant speed, camera tracks the protagonist's left eye, keeping it at frame-left third, the push-in reveals a handwritten letter on the desk previously out of frame, the background window and its reflection stay optically locked and unchanged.' Models like Seedance 2.0 respect this structure far better than vague 'slow dolly' language.
I'm generating a clip in Kling 3.0 and I need it to last exactly 8 seconds, but Kling's hard clip length is 10 seconds. When I write '8-second clip,' the output is sometimes 6 or 9 seconds. How do I force the model to respect duration?
Models have a hard architectural clip-length limit — for Kling 3.0 it's 10 seconds — but they interpret duration as a soft prior unless you anchor it to visible motion markers. Write the duration as an explicit start and end event rather than a standalone number. Structure it as: 'Total clip length exactly 8 seconds. Action begins at 0.0s: the door opens. Action completes at 8.0s: the door fully closes. No motion occurs after the 8.0s mark.' Additionally, specify a mid-point checkpoint: 'At 4.0s, the camera reaches the midpoint of its lateral tracking arc.' This temporal scaffolding forces the latent diffusion schedule to allocate frames proportionally. Avoid writing 'about 8 seconds' or 'around 8s' — that widens the tolerance window. If the model still returns 9 seconds, shorten the action description: fewer intermediate motion states compress the timeline. Example prompt: 'Total clip length exactly 8 seconds, 24fps. Action begins at 0.0s: a ceramic cup tips over on a wooden table. At 4.0s, the cup has rotated 45 degrees and the coffee surface ripples. Action completes at 8.0s: the cup lands on its side, coffee pooled, no further motion.'
I want to generate a documentary-style shot of a blacksmith forging steel, and I need realistic hammer clangs and forge fire audio inside the video itself, not a separate pass. How do I prompt for native audio in a model that supports it, versus one that doesn't?
First, check your model: Veo 3.1 and Kling 3.0 support native audio generation; Seedance 2.0 and Runway Gen-4.5 do not — for those, you must plan a separate audio pass. For native-audio models, write a dedicated audio sentence after the visual description, using the prefix 'Audio:' and specify temporal sync, sound sources, and ambience. Do not write 'add realistic sounds' — that is too vague. Example for Veo 3.1: 'Visual: medium close-up of a blacksmith striking a glowing steel billet on an anvil, sparks flying, camera static. Audio: synchronized metallic clang on each hammer strike, rhythmic at 1.2-second intervals, low furnace rumble at -12dB, subtle hiss of quenching steam at the end.' For non-native models like Gen-4.5, your prompt must include a placeholder for post-production: 'Leave visual headroom for audio: no on-screen dialogue, no lip movement, keep action clear so a separate sound pass can sync.' Then plan the audio pass separately in a tool like ElevenLabs or a DAW. Never assume a model with no audio support will invent sound — it will silently ignore it or create visual artifacts.
Who this is for
Builders who want their fine-tuned model to reliably perform this specific capability, as part of a broader assistant or agent.
Which models this works with
The dataset is plain JSONL, so it works with any instruction-tuned open model. On Rebiha you can train it directly on:
- Qwen — Qwen3.8, Qwen3.6, Qwen3.5, Qwen3, Qwen2.5, Qwen2.5-Coder
- Granite — Granite 4.1 (3B, 8B, 30B)
- OLMo — OLMo 3, OLMo 3.1
- GLM — GLM-4
- Gemma, Phi, DeepSeek, Mistral, and Llama families
Training uses LoRA, or QLoRA on a 4-bit base for larger models. Your base model's weights are never modified — training produces a separate adapter.
How it works
- Pick this dataset and a base model.
- Rebiha runs the job on a managed GPU. You set up nothing.
- Download your model: a ready-to-run GGUF, plus developer assets (adapter, tokenizer, configs).
Fine-tuning or RAG?
Use RAG when the model needs facts that change — your prices, your documents, today's inventory. Use fine-tuning when you want consistent behavior and structure without prompting for it every time. This dataset teaches the shape of this capability, not facts to look up.
How managed fine-tuning works
- Inspect the dataset examples and choose a compatible base model.
- Rebiha runs the training job on managed GPU infrastructure using LoRA or QLoRA as appropriate.
- Download portable model assets for your own workflow, including the available ready-to-run and developer outputs for the selected training path.
Fine-tuning or RAG?
Use fine-tuning when the objective is recurring behavior: response structure, domain patterns, terminology, workflow, or how the model approaches a class of requests. Use RAG when answers depend on changing or proprietary facts that should be retrieved at request time. The two approaches can also work together.
Know what goes in. Own what comes out.
You can inspect real examples before training, choose the model you want to adapt, and keep portable model assets when training is complete.
Related datasets
- General Instruction Following — 978 pairs
- Multi-Turn Conversation — 466 pairs
- Rewriting & Editing — 854 pairs
- Summarization — 781 pairs