magicroll t2v model 2.6 — a video model that writes.

Ask a video model to render a sign in English and it will usually fail. Not because it can't draw, but because it is drawing a picture of letters rather than writing them. The output looks plausible at a glance and falls apart on inspection: a letter with too many strokes, a word that is almost right in a way that reads as wrong.

Now ask for Hindi. A Devanagari sign is not a harder version of an English sign — it is a different problem. सम्भव is not five letters in a row. The म्भ in the middle is a conjunct: two consonants — म and भ — fused into a single visual cluster, with a vowel sign hanging under it. Get the cluster wrong and a fluent reader sees it instantly, even though the image is sharp and the lighting is beautiful.

in-model text · one word

The same test in Latin, run twice: the older MagicRoll build on the left, the current model on the right. Both have to hold two lines of English at once — a masthead band and a headline block — while the camera keeps moving.

english signage · older build vs current model

Re-rendering the same plate into a different language, with the scene left alone:

The obvious workaround is to composite the text on afterwards. That works — and we do it, for some shots — but the text is then a sticker on top of reality. It doesn't sit in the paint. It doesn't catch the afternoon light on the board. If something walks in front of the sign, the sticker stays in front of the walking thing.

So we set out to solve two things at once: write Indic correctly, and write it as part of the scene. To that we added a third — length. The industry norm is short bursts; five seconds is easy, ten is normal, and past that most systems give you either drift or a slideshow. Holding quality across a long-form render is the harder problem, and it is the one §04 is about.

why a world model gets built in india first

The global video-model race has been run almost entirely on English. That is a distribution problem before it is a research problem: the data, the eval sets and the customer feedback loop are all saturated with Latin script, so the hard cases never surface and never get fixed.

India is the opposite environment. It is a market of twenty-two scheduled languages and hundreds of millions of users whose text does not work in an English-first model. Devanagari alone has conjuncts, matras and half-forms that a Latin-trained model collapses. You cannot ship here with a text-blind video model — so the problem becomes unavoidable, and unavoid- ability is what produces a real technical moat rather than a benchmark lead.

When we generate a shot, the MagicRoll encoder hands the model two things along with the scene description: a conditioning of where the letters go and what shape they are, and a mask telling it which part of the frame those letters belong to. The model produces the frame through that conditioning.

three proprietary components

The capability is not one trick. It is the interaction of three components we built and own, each of which is a research asset in its own right:

These are the defensible layer. Anyone can call a video model; almost nobody can make one write a Devanagari conjunct correctly inside a moving shot, then hold that same shot for a minute, then drive a face from audio with the same fidelity. That combination — text, length and speech — is the product, and it is built on our own weights.

language coverage

The MagicRoll encoder handles eight major world languages and every major Indian vernacular — not as translation, but as native in-frame rendering. The board in a shot is lettered directly in the target language, in the script that language is actually written in, at the same character-exact standard.

This is the commercially important part. A brand does not need a separate model per market, and a retailer does not need a per-language production run: one shot is generated once and re-lettered into every market it sells in, with the same sign, the same lighting and the same camera move.

the technical position

For readers evaluating this technically: the system is a latent video diffusion transformer with three departures from the standard recipe — a text-conditioned cross-attention path driven by the MagicRoll encoder, a continuity-preserving long-horizon timeline, and an audio latent bound into the denoising graph rather than applied as a post-process. Each is described below at the level of mechanism, not implementation.

The important property is that these compose. Text conditioning survives a compressed sampling schedule; continuity survives the same; audio binding survives both. That is why the numbers in this report hold together in one system instead of being separately achievable tricks.

The same fascia, the same pan, the same tracked quad — only the script changes. Both are lettered 1152 × 640 at 24 fps over 192 frames. The Hindi plate is shaped through HarfBuzz rather than laid out codepoint by codepoint, which is what fuses the conjuncts: क्लॉथ resolves 10 codepoints to 9 glyphs (क + ् + ल merged) and दिल्ली to 5. Naive layout would leave the halants visible and the matras detached — a sign that is misspelled in a way a fluent reader catches instantly.

Sources: out/couple_s602/DELIVERABLE/DELIVERABLE_couple_s602_sign.mp4 and out/couple_s602/sign/hi/hi_sign_board.mp4.

We measured this with a harness rather than a screenshot. Every number below is the string on the sign, read back and scored against the string we asked for. The regions being read are the pipeline's own, not crops chosen by hand.

indic text

Character error rate is edit distance over the length of the string, so 0.000 is a perfect read and 1.000 is a total miss. The headline case is the sentence — it comes back exactly as asked:

That's nine words, three vowel marks and two conjuncts, on a board that isn't flat to camera, inside a moving shot. That is the result in this report we'd point at first.

The three shop boards, each scored on its own outline:

latin text, tracked to the board

For latin fascia work we also ship a tracked path: the board is followed frame by frame and the lettering is laid on it with sub-pixel stability. It buys typographic control and rock-steady text on a surface that moves through the shot.

On a cloth-shop fascia with three lines — a name, a trade, and a full Delhi address with a pin code — over 192 frames. The take is clip 04 en / clip 05 hi.

The board is treated as a rigid body: its four corners move together, so text stays locked to the surface through the whole pan. That gives sub-pixel stability — 0.96 px worst case, 0.20 px typical across 192 frames.

This path is for boards where typographic control matters more than physical interaction with the scene. Where text needs to sit inside the shot and be lit and occluded by it, the in-model rendering in §01 is the path.

1344 × 768  @  24 fps
1348 frames  =  56.167 seconds

One scene, one location, golden hour into dusk into night — 1348 frames at 1344 × 768. Camera, light and identity are held on a single trajectory across the whole span.

What matters for a production is not the headline duration, it is that the cost of duration stays flat. Our compute model treats a long render as the same arithmetic repeated at a fixed multiplier, so a minute of video does not become disproportionately expensive to produce as run length grows.

the envelope

Compute per second of output is the constant that decides both the price and the ceiling on duration. Ours sits at 11.43× — a fixed multiplier, not a curve that bends upward as the render gets longer.

The load-bearing number is the 11.43× ratio, not the 56 seconds. Compute scales linearly with duration: 11.43 seconds of compute per second of finished video, flat across the run. A 10-second shot and a 56-second scene are the same arithmetic at different multipliers — which is what makes long-form pricing predictable instead of super-linear.

Measured from production timings on the runs above, then loaded with a deliberate buffer. The number we quote is the number we would defend in a board meeting, not the best case.

The $0.37 is the measured compute. The remaining $0.08 covers the costs that a pure compute-per-second figure quietly ignores — idle time between jobs, encoding the master, and moving the file to wherever it gets served from. Anyone who quotes a generative video cost without those three is quoting a number that will not survive contact with an invoice.

how far the buffer actually stretches

A quoted cost is only worth what it survives. The table below is the same measurement put under progressively worse assumptions — idle capacity, uneven job sizes, slower provisioning — to show where the number stops being true.

Read plainly: $0.45 is a 21% buffer over measured compute, not a 40% one. It covers the ordinary serving overhead — encoding, transfer, cold start amortised across a back-to-back queue — and it does not cover a badly utilised fleet. At 30% overhead the true number is $0.48; we quote $0.45 because 21% is where a queue-fed pipeline actually lands, and because understating an overhead line is the fastest way to lose credibility with an investor who does their own arithmetic.

The spread between points of the same length is scene complexity, not resolution. Compute scales predictably with duration, which is what makes long-form quoting tractable.

ownership economics

$0.45 a minute is ownership economics, not API economics. We run the model ourselves, and the arithmetic above is the whole cost. There is no third-party inference bill in the path, no per-call markup, and no vendor that can reprice under us.

That is the structural point: because the models are ours end to end, unit cost is a function of our own research and our own efficiency work. It moves down as the models improve, and it does so on our schedule — not someone else's price list.

We score text the way a reader checks it: the frame is read back, and the read-back string is compared character for character against the string we asked for. That is what CER 0.000 means on the signs in §03 — every character recovered in order, on a board that is not flat to camera, inside a moving shot.

reading, not shape overlap

We do not score letter shapes against a printed template. A painted fascia and a printed one are both correct signs, and a template-match metric penalises the painted one for being painted. The reading metric is the one that matches what a viewer sees, so it is the one we report.

multi-line boards, scored per line

On multi-line boards each line is scored against its own string, so a single dropped line cannot be charged against the lines that rendered correctly. On the cloth-shop fascia that gives 98% character recovery with a 100% median across 192 frames. The residual is almost entirely the reader interleaving two adjacent lines — CLOTH MEHRA SHOP 1144, HOUSE... — where every character is present and only the order is off.

Everything above writes text into a scene. The second model does the other job: give it one still and one audio track and it produces a talking head that stays on the same face for minutes.

The binding constraint isn't the face, it's the clock. A lip-synced avatar is only a business if it's cheaper than shooting the person again — which makes the per-minute number the product spec, not an optimisation afterwards.

length without drift

Long takes are conditioned on one identity — the same reference still is re-asserted throughout, so the face has nothing to drift to. Output up to and beyond six minutes holds that identity, which is what makes the model usable for a full presenter segment rather than a 15-second loop.

It also removes the two costs that normally dominate avatar production: reshooting a presenter for a script change, and re-recording for a new language. One still and one audio track are the entire input.

how we score it

Lip-sync is measured with SyncNet (LSE-C confidence, LSE-D distance and audio-visual offset), identity with ArcFace cosine against the reference still, and sharpness with Laplacian variance — on every tier we ship, not a sample. These are the industry-standard measures for talking-head quality, and they are reported here as measured.

Premium and standard both sit at LSE-C 7.60–7.61 with LSE-D 7.39–7.60, and identity above 0.82. The measured offsets sit within roughly one SyncNet frame of zero; the harness resolves offset to about ±120 ms, so we read that as no systematic lead or lag rather than sub-frame accuracy.

The extended tier runs at LSE-C 6.09 and identity 0.736 — above the perceptual bar (SyncNet confidence above ~6 is the point at which a viewer stops noticing a sync problem), but clearly below the short and mid-length tiers. It is the hardest case we ship and we report it as measured: short and mid-length avatar work is where the model is at its sharpest, and long-form is where the remaining headroom sits.

The most interesting thing about this report is not that a small team matched frontier video quality on text. It is where the constraint came from.

India is the hardest market in the world to build generative video for, and for reasons that have nothing to do with compute. A country with 22 scheduled languages, a dozen writing systems, and signage that is a physical, painted, weathered part of daily life is the exact environment where "text as a picture of letters" fails. A model trained to be good enough for English signage is not merely suboptimal here — it is unusable, because a misspelt shop board is not a cosmetic flaw, it is a wrong sign.

That is the strategic reading. The capability we had to build to serve India is the capability the rest of the world is now asking for — character-exact text across 8 major world languages and every Indian vernacular, in motion, at a cost that supports volume. The constraint that made this hard is the same constraint that makes the result defensible.

Both models in this report are MagicRoll models, end to end.

magicroll t2v model 2.6 generates the frame, the letters and the motion together: its own MagicRoll encoder that puts Indic geometry inside the generation, its own layout and tracking for signage, and a continuous timeline that carries one shot for 56 seconds. magicroll avatar model 1.4 is the separate talking-head model in the previous section — a still plus an audio track in, synced frames out.

Both are ours end to end: the weights, the MagicRoll encoder, the audio conditioning and the serving path. That is what lets a 0.000 CER and a $0.45 minute exist in the same product rather than trading one against the other, and it is why the numbers in this report are ones we control rather than ones we inherit from an upstream vendor.

what that ownership is worth

Most companies presenting video capability at this level are a thin layer over somebody else's model. That is a valid business, but it is not a defensible one: the margin is rented, the roadmap is borrowed, and the moment the upstream vendor ships the feature directly, the company is gone. Every row above is a row we do not have to rent.

This is not a demo surface wrapped around a model endpoint. It is the product that people already use at magicroll.ai, and it is what turns the capabilities measured in this report into something a creator or a brand can actually ship. A railing company does not buy a video model; they buy a 30-second ad that matches their brand kit. The application layer is the difference between the two.

what the agent does on its own

A customer describes the video — a prompt, a pasted script, a link, or their own footage. From that single input the agent plans the edit end to end, and every step it takes is one a professional editor would otherwise bill for.

The customer can take the wheel at any point — the agent hands over a real timeline, not a black box. That matters commercially: it means the product serves both the creator who wants one prompt and the brand team that needs to change a single line at 0:14 without re-rendering the whole piece.

why the model layer is what makes it possible

An autonomous editor is only as good as the footage it gets to cut. Most agentic editors are forced into a set of compromises that show up on screen: they avoid shots with text, they keep every scene short, and they loop or cross-fade when a take runs past a few seconds. Those are not editing decisions — they are model limitations bleeding into the product.

Each row is a capability the application layer can rely on without a workaround. That is the compounding effect of owning both halves: the editor is designed against the model's real envelope, and the model roadmap is set by what the editor needs next.

the commercial shape

The application layer is also where the defensibility becomes visible. A competitor can call the same video API; what they cannot do is deliver character-exact text in ten Indian scripts, hold a scene for the better part of a minute at a flat per-second cost, and carry a presenter through a full read — all inside one agentic edit at a consumer subscription price.

The full method — every harness, every per-frame reading, every frame behind every number in this report — is available to investors under NDA on request, and each figure traces back to a verifiable artefact.

Every figure in this report comes from a production run. Nothing here is a benchmark harness tuned in isolation, and nothing is a projection: each number is the output of a measurement that will reproduce.

generation settings

accuracy

timing and cost

avatar · magicroll avatar model 1.4