DEV Community: DemoVexa

Normalize Voiceover Loudness With ffmpeg loudnorm: A Two-Pass Recipe

DemoVexa — Mon, 02 Nov 2026 06:07:23 +0000

To normalize voiceover loudness with ffmpeg, run the loudnorm filter twice: once to measure the file, then again with those measurements fed back in so the filter can apply one clean, linear gain change. Pick a target in LUFS for where the video will play, cap the true peak a little below 0 dBTP, and check the output with a third measurement. The rest of this post is the commands and the reasons behind each number.

Key takeaways

Loudness is measured in LUFS, which tracks how loud audio sounds, not how high the peaks go.
Single-pass loudnorm works, but it adjusts gain on the fly and can pump. Two passes give a steadier result.
Normalize the narration track before mixing music under it, then normalize the final mix.
Always measure the output. A filter that ran without errors is not proof of the level.

Why does voiceover loudness drift between videos?
What do LUFS, LRA and true peak mean?
How do you run loudnorm in two passes?
Which target should you pick?
How do you check the result automatically?
FAQ

Why does voiceover loudness drift between videos?

Because every source is different. A text to speech provider returns files at its own level, and a laptop mic recording sits somewhere else. Change the voice or the room and the next video is louder or quieter than the last.

If someone watches two of your demos back to back and has to reach for the volume, that is a small tax on every video. I hit this when I swapped voices partway through a set of feature clips. Each file sounded fine alone. In sequence, one jumped out.

What do LUFS, LRA and true peak mean?

These three numbers come from the EBU R128 and ITU BS.1770 standards, and loudnorm reports all of them.

Measure	What it describes	Typical use
Integrated loudness (LUFS)	Average perceived loudness over the whole file	The main target you normalize to
Loudness range (LRA, in LU)	How much loudness varies between quiet and loud parts	Keep it low for speech so nothing gets lost
True peak (dBTP)	The highest level, including peaks between samples	Cap it below 0 to avoid clipping after encoding

Peak normalization only looks at the loudest sample, so equal peaks can sound very different. LUFS weights the measurement toward how ears actually hear.

How do you run loudnorm in two passes?

Pass one: measure

ffmpeg -hide_banner -i voice.wav \
  -af loudnorm=I=-16:TP=-1.5:LRA=11:print_format=json \
  -f null - 2> measure.log

Only the log is written. It ends with a JSON block holding input_i, input_tp, input_lra, input_thresh and target_offset.

Pass two: apply

Feed those values back in and set linear=true:

ffmpeg -hide_banner -i voice.wav \
  -af loudnorm=I=-16:TP=-1.5:LRA=11:measured_I=-23.4:measured_TP=-4.1:measured_LRA=6.2:measured_thresh=-34.0:offset=0.3:linear=true \
  -ar 48000 voice-norm.wav

The measured_ numbers are placeholders; use your own. With them, the filter applies one gain change across the file instead of riding the level.

Two notes:

Add -ar 48000. loudnorm upsamples internally, and without an explicit rate you can end up with a 192 kHz file.
If the file needs more gain than the true peak cap allows, the filter falls back to dynamic mode. The output log will say so. Fixing a very quiet source beats forcing it.

If you script this, parse the JSON with jq and pass the values through, so nobody copies numbers by hand.

Which target should you pick?

Pick by where the video plays, and keep it the same across your library.

Web embeds, docs and social feeds: around -16 LUFS integrated is a common choice for speech heard on laptops and phones.
Broadcast style delivery: EBU R128 specifies -23 LUFS. You will rarely need this for product demos.
Platforms that normalize on playback: some turn loud uploads down. Check their current docs.

For true peak, -1.5 or -1 dBTP leaves headroom for lossy encoders like AAC, which can push peaks slightly higher than the source.

With music, normalize the narration first, mix the music under it, then run the final mix through both passes. I covered the export side, codecs and containers, in choosing product demo video resolution and format.

How do you check the result automatically?

Run pass one again on the output and fail the build if it is off target:

out_i=$(ffmpeg -hide_banner -i voice-norm.wav -af loudnorm=print_format=json -f null - 2>&1 | sed -n '/^{/,/^}/p' | jq -r .input_i)
awk -v v="$out_i" 'BEGIN { exit (v < -17 || v > -15) }' || { echo "Loudness $out_i out of range"; exit 1; }

A one LU window is tight enough that nobody hears a jump, and loose enough not to fail on rounding.

At DemoVexa the narration comes from a connected voice provider or your own recording, exactly the mix of sources that drifts. The voiceover, script and render features page shows how voiceover fits the rest of the pipeline.

FAQ

Is single-pass loudnorm good enough?

For a preview, yes. For published files, two passes are steadier because the filter knows the whole file first.

Should I normalize before or after adding music?

Both. Voice alone first, then the final mix.

Why is my output file 192 kHz?

loudnorm resamples internally. Set the output rate with -ar 48000.

Does AAC encoding change loudness?

Integrated loudness barely moves, but peaks can rise a little. That is why the true peak cap sits below 0 dBTP.

Baltej Singh is the founder of DemoVexa, a desktop app and CLI that turns a local codebase into narrated product demo videos. He writes from Delaware, USA.

VideoObject Structured Data: Add It, Then Prove Google Reads It

DemoVexa — Thu, 29 Oct 2026 06:05:30 +0000

VideoObject structured data is a block of JSON-LD that tells Google what a video on your page is: its name, thumbnail, upload date, length and where the file lives. Adding it takes ten minutes. Proving that Google actually read it and indexed the video takes longer, and that second part is where most pages fall down. This post covers both.

Key takeaways

Google needs three properties at minimum: name, thumbnailUrl and uploadDate.
contentUrl or embedUrl is what lets Google fetch the video itself. Add at least one.
Valid markup is not the same as an indexed video. The video also has to be the main content of the page.
Check in three places: the Rich Results Test, URL Inspection, and the Video indexing report.

What does VideoObject markup look like?
Which properties actually matter?
How do you add key moments?
How do you confirm Google read it?
Why is my video not indexed?
FAQ

What does VideoObject markup look like?

It is a JSON-LD script tag in the page head or body. Here is the shape I use for a product demo page:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "Exporting a release clip from the CLI",
  "description": "A two minute walkthrough of rendering a release clip from a local repo.",
  "thumbnailUrl": ["https://example.com/media/release-clip-poster.jpg"],
  "uploadDate": "2026-10-20T09:00:00-04:00",
  "duration": "PT2M04S",
  "contentUrl": "https://example.com/media/release-clip.mp4",
  "embedUrl": "https://www.youtube.com/embed/VIDEO_ID"
}
</script>

Two details trip people up. duration uses ISO 8601, so two minutes and four seconds is PT2M04S, not 2:04. And uploadDate should carry a timezone offset. Without one, Google has to guess.

If you render pages with a framework, generate this block from the same data that renders the player. Hand-written JSON-LD drifts the moment someone swaps the video and forgets the markup.

Which properties actually matter?

Three are required, a few more change what Google can do with the video.

Property	Required?	What it does
`name`	Yes	Title shown in results
`thumbnailUrl`	Yes	Image for the result; must be crawlable
`uploadDate`	Yes	When the video was first published
`description`	Recommended	Context for matching queries
`duration`	Recommended	Shown as a length badge
`contentUrl`	Recommended	Direct link to the video file
`embedUrl`	Recommended	Link to the player, such as a YouTube embed
`hasPart` (Clip)	Optional	Key moments with timestamps

The thumbnail has to be reachable by Googlebot. If your media folder is blocked in robots.txt, or the image sits behind a signed URL that expires, the markup validates and the thumbnail still fails.

How do you add key moments?

Add hasPart with one Clip per section. Each clip gets a name, a start offset and an end offset in seconds, plus a URL that jumps to that time.

"hasPart": [
  {
    "@type": "Clip",
    "name": "Pick the repo",
    "startOffset": 0,
    "endOffset": 35,
    "url": "https://example.com/demo?t=0"
  },
  {
    "@type": "Clip",
    "name": "Render and export",
    "startOffset": 35,
    "endOffset": 124,
    "url": "https://example.com/demo?t=35"
  }
]

This only helps if your player honors the t parameter. Test the URLs by hand before shipping. If the video is on YouTube, chapters in the description usually do this job for you.

How do you confirm Google read it?

Run three checks, in this order:

Rich Results Test. Paste the live URL. It should detect a Video item with no errors. Warnings about optional fields are fine.
URL Inspection in Search Console. Request indexing, then check the "Video indexing" section once the page has been crawled.
Video indexing report. This lists pages where Google found a video and whether it indexed it, with a reason when it didn't.

The first check only proves the syntax. The second and third tell you what Google decided.

Why is my video not indexed?

The most common reason I see is "Video isn't on a watch page". Google indexes videos for pages where the video is the main content. A demo clip in the hero of a feature page, surrounded by marketing copy, often gets labeled this way even with perfect markup.

Other reasons worth checking:

The thumbnail URL returns an error or is blocked.
The player loads only after a click or a consent banner, so Googlebot never sees a video element.
The video is too small on the page or placed far below the fold.

The practical fix for product sites is a dedicated page per demo: one video, a short description, a transcript and the markup. I wrote up how that fits with getting product videos into Google rich results, including which pages deserve their own watch page.

At DemoVexa we render demo videos from a local codebase, so the script, timings and chapter names already exist as data. Feeding them into JSON-LD is a small step, and it is part of why I care about getting code-generated product demo videos indexed properly.

FAQ

Does VideoObject markup work for YouTube embeds?

Yes. Use embedUrl with the YouTube embed link. Google often finds YouTube videos without markup, but the markup ties the video to your page.

Is JSON-LD better than microdata for video?

Google accepts both. JSON-LD is easier to generate and keep in sync because it sits in one block instead of being spread across HTML attributes.

How long does video indexing take?

It varies by site and crawl frequency. Request indexing in URL Inspection and check the Video indexing report after the page is recrawled.

Do I need a separate thumbnail for the markup?

You need one crawlable image URL. Reusing the player's poster image works well and keeps the result consistent with what visitors see.

Baltej Singh is the founder of DemoVexa, a desktop app and CLI that turns a local codebase into narrated product demo videos. He writes from Delaware, USA.

Transparent Background Video Export: Alpha Channels, ProRes 4444 vs WebM VP9

DemoVexa — Mon, 26 Oct 2026 06:16:14 +0000

A transparent background video stores a fourth channel, alpha, next to the color data, so an editor or browser knows which pixels to show. In practice you choose between two files: ProRes 4444 in a MOV for editing, and VP9 in a WebM for the web. This post covers how alpha is stored, the ffmpeg commands I use to make and verify each file, and the mistakes that make transparency quietly disappear.

Key takeaways

Alpha only survives if the pixel format carries it. Look for yuva, not yuv.
ProRes 4444 is the editing format: high quality, very large files.
VP9 in WebM is the web format: small files, alpha in Chromium browsers, none in Safari.
ffmpeg's built-in VP9 decoder ignores alpha, so force libvpx-vp9 when reading a transparent WebM.

What is an alpha channel in a video file?
Should you export ProRes 4444 or WebM VP9?
How do you encode each format with ffmpeg?
How do you check that the alpha survived?
What goes wrong most often?
FAQ

What is an alpha channel in a video file?

An alpha channel is a per-pixel opacity value stored alongside the color. Zero is fully transparent, the maximum is fully opaque, and values in between give you soft edges and shadows.

Most delivery video has no alpha at all. H.264 in an MP4 is normally encoded as yuv420p: brightness plus two color channels and nothing else. So "export with transparency" is a question about codec and pixel format, not a checkbox.

Alpha can be straight or premultiplied. If an editor reads it the wrong way, you get a dark or light fringe around anti-aliased edges, so check the clip's alpha interpretation setting before blaming the encoder.

Should you export ProRes 4444 or WebM VP9?

Export ProRes 4444 when the file goes into an editor, and VP9 WebM when it goes onto a web page.

	ProRes 4444 (.mov)	VP9 with alpha (.webm)
Compression	Intraframe, near lossless	Interframe, lossy
ffmpeg pixel format	`yuva444p10le`	`yuva420p`
Color resolution	Full (4:4:4)	Subsampled (4:2:0)
File size	Very large	Small
Best home	Premiere, Final Cut, DaVinci Resolve	Web pages in Chrome and Edge
Weak spot	Disk space and upload time	No alpha in Safari or Final Cut

For scale, Apple's ProRes white paper puts ProRes 4444 at 1080p and 29.97 fps at a target of about 330 Mbps, before alpha.

The color resolution row matters for UI video. With 4:2:0, small colored labels get slightly soft, while white and gray text holds up well.

How do you encode each format with ffmpeg?

Start from a transparent PNG sequence and encode it twice.

# ProRes 4444 with alpha
ffmpeg -framerate 30 -i frames/%05d.png \
  -c:v prores_ks -profile:v 4444 -pix_fmt yuva444p10le demo.mov

# VP9 with alpha, constant quality mode
ffmpeg -framerate 30 -i frames/%05d.png \
  -c:v libvpx-vp9 -pix_fmt yuva420p -crf 30 -b:v 0 demo.webm

Two details matter:

The -pix_fmt flag is what keeps alpha. Leave it out and ffmpeg may pick a format without it.
With libvpx-vp9, -b:v 0 next to -crf gives constant quality. Without it, a default bitrate acts as a ceiling.

How do you check that the alpha survived?

Run ffprobe, and know that the two files report alpha differently.

ffprobe -v error -select_streams v:0 \
  -show_entries stream=codec_name,pix_fmt:stream_tags=alpha_mode \
  -of default=nw=1 demo.webm

For the MOV, you want a pixel format starting with yuva. For the WebM, ffprobe usually reports yuv420p even when alpha is present, because WebM stores alpha as extra data beside each frame. The real signal is TAG:alpha_mode=1.

Then pull a frame and view it on a checkerboard:

ffmpeg -c:v libvpx-vp9 -i demo.webm -frames:v 1 check.png

The -c:v libvpx-vp9 before -i matters. Without it, ffmpeg's native VP9 decoder drops alpha and your PNG comes out on solid black.

What goes wrong most often?

These are the failures I see most:

Expecting transparency from an H.264 MP4. If the target only takes MP4, export green screen and key it.
A converter or upload pipeline that transcodes to yuv420p and silently drops alpha.
Previewing a WebM in Safari or Final Cut and deciding the file is broken.
Trusting <source> order on the web. Safari needs a separate file, such as HEVC with alpha, so pick the file with a small script and test in each browser.

In the app I build, the Export step offers a transparent MOV in ProRes 4444, a transparent WebM in VP9 and a green screen MP4. The walkthrough on exporting a product demo on green screen or with a transparent background covers the in-app steps, and the full list of code-to-video export options and formats is on the features page.

FAQ

Does MP4 support a transparent background?

Not with H.264, which most MP4 files contain. Use ProRes 4444 for editing, VP9 WebM for Chromium browsers, or HEVC with alpha for Apple devices.

Why does my transparent WebM show a black background?

Usually the decoder dropped alpha. In ffmpeg, put -c:v libvpx-vp9 before -i. Safari doesn't support WebM alpha, so serve it a different file.

Is ProRes 4444 lossless?

No. Its alpha channel is stored losslessly, but the color data is compressed. It is visually near lossless, so for editing the difference is rarely visible.

Which format should I send to a video editor?

Ask what they edit in. ProRes 4444 suits Premiere, Final Cut and Resolve. If you don't know their setup, a green screen MP4 works almost everywhere.

Baltej Singh is the founder of DemoVexa, a desktop app and CLI that turns a local codebase into narrated product demo videos. He writes from Delaware, USA.

How to Demo a Developer Tool, CLI or API on Video

DemoVexa — Sat, 17 Oct 2026 06:00:40 +0000

Developer products are hard to show because the interesting part is often invisible. Here's how to make terminals, code and API calls readable on video, and what developers actually want to see.

A SaaS dashboard is easy to put on video. There are buttons, charts and something to click. A CLI, an SDK or an API is harder. The product is a command, a few lines of code or a JSON response, and the useful part (what it saves you from doing) doesn't appear on screen at all.

This post covers how to plan and lay out a demo for a developer product so it's readable, honest and short.

Disclosure: I build DemoVexa, a tool that can turn your code into product demo videos. Most of this post is about planning and readability, which applies whatever you use.

Key takeaways

Show the problem, the smallest working example and the result. Developers care about how few steps it takes.
Terminal and code text must be readable on a phone: large font, short lines, and only the lines that matter.
Show real commands and real output shapes, using sample data. Don't fake output your tool can't produce.
Pair the video with copyable code in the post or README, because nobody can copy text out of a video.

Key takeaways
What do developers want to see in a demo?
How do you structure a developer tool demo?
How do you make terminal and code text readable?
How do you show an API, which has no UI?
Should you record your terminal or animate it?
What should go in the post or README alongside the video?
A few common mistakes
FAQ

What do developers want to see in a demo?

Developers watching a demo are usually asking a few practical questions:

How do I install it? One command, or a long setup?
What's the smallest thing that works? The "hello world" of your tool.
What does the output look like? Real shapes, real errors, real formats.
How does it fit my stack? Language, framework, CI, editor.
What does it replace? The script or manual step they do today.

A good developer demo answers three or four of these and skips the marketing.

How do you structure a developer tool demo?

A simple structure that works for most CLIs, SDKs and APIs:

Part	What's on screen	Rough share of the video
The problem	The manual way, or the error people hit today	10 to 15%
Install or setup	One command or one config block	10 to 15%
The smallest example	The core command or a few lines of code	30 to 40%
The result	Output, a file created, a dashboard updated	20 to 30%
Where to go next	Docs link, repo, a more advanced example	5 to 10%

Keep it short. A 60 to 90 second demo of one task usually beats a ten minute tour.

How do you make terminal and code text readable?

Most developer demos fail on readability, not content. Text that's fine on your monitor is unreadable on a phone or in a small embedded player.

Large font. Bigger than you think. Test by watching the video on your phone.
Short lines. Wrap long commands, or use shorter example paths and names.
Fewer lines. Show the five lines that matter, not the whole file.
Highlight the change. When one line matters, highlight or zoom on it.
High contrast. A plain dark or light theme, not a busy custom one.
Slow typing, or none. Real typing speed is too fast to follow. Either type slowly or show the command appearing line by line.

How do you show an API, which has no UI?

An API demo needs something visible on both sides of the call. Common options:

Request and response side by side. The request on the left, the formatted JSON response on the right.
Code, then effect. A few lines of SDK code, then the thing it changes, such as a record appearing in a dashboard.
A sequence diagram. For flows like authentication, a simple animated diagram of who talks to whom.

Use sample keys and sample data. Never show real tokens, even expired ones. The API authentication demo guide on the DemoVexa blog goes deeper into showing auth flows without exposing secrets.

Should you record your terminal or animate it?

Both are reasonable, and the choice depends on the tool:

Record when the real behaviour is the point: timing, streaming output, an interactive prompt.
Use a terminal recorder that saves text rather than pixels when you want sharp, resizable output for docs.
Animate when you want a polished, narrated video that matches a script line by line and survives UI or output changes.

For animated videos, some tools turn your code into product demo videos instead of recording anything. For a developer product, that means recreating the terminal and output as animated scenes with sample data, then timing them to a voiceover. The tradeoff is that the output on screen is a recreation, so check that it matches what your tool really prints.

There's a longer walkthrough of how to make a demo video for a CLI tool on the DemoVexa blog.

What should go in the post or README alongside the video?

The video gets attention. The text gets people to actually try it. Next to the video, include:

The install command as a copyable code block.
The smallest working example from the video, exactly as shown.
A link to the full docs.
Version numbers for anything version sensitive.

A few common mistakes

Starting with the architecture instead of the result.
Using a real project with long, messy paths on screen.
Showing output your tool doesn't actually produce, or hiding errors it does produce.
Talking over a silent, static terminal for 20 seconds.
Forgetting that viewers can't copy anything from a video.

FAQ

How long should a developer tool demo video be?

For one task, 60 to 90 seconds is usually enough. Longer tutorials work on YouTube or in docs, but a short demo of the core workflow is better for a README or landing page.

How do I make terminal text readable in a demo video?

Use a large font, a high contrast theme and short lines, and show only the lines that matter. Watch the result on a phone before publishing.

How do you demo an API that has no user interface?

Show the request and response side by side, or a few lines of SDK code followed by the visible effect. For auth flows, an animated sequence diagram can explain who talks to whom.

Should I show real API keys in a demo?

No. Use sample or obviously fake keys and sample data, even if a real key is expired or scoped.

How to Make a Product Demo Video with Remotion (and When Not to Build It Yourself)

DemoVexa — Sat, 17 Oct 2026 05:57:26 +0000

Remotion lets you write videos as React components. Here's how a product demo maps onto it, what the hard parts are, and what to check in the license before you start.

If you build a React app, there's an appealing idea: why not make the product demo in React too? Your components already exist. Remotion is a framework that renders React components frame by frame into video, so in principle you can reuse your UI, animate it and export an MP4.

That idea works. It's also more work than it first looks. This post walks through how a demo maps onto Remotion, the parts that take the most time, and when it makes sense to use a tool instead of writing it all yourself.

Disclosure: I build DemoVexa, which is product demo video software that writes the Remotion code for you. Everything in the first part of this post applies whether you use it or not.

Key takeaways

Remotion renders React components into video, so a product demo becomes a set of components animated over time.
The hard parts are not rendering. They're the story, recreating screens with sample data, and timing animation to narration.
Check Remotion's license: it's free for individuals and for profit companies with up to 3 employees, and larger companies need a Company License.
Build it yourself for full control. Use a tool if you want the script, voice and timing handled for you.

Key takeaways
How does a demo map onto Remotion?
Can you reuse your real components?
What are the hard parts?
What should you check in the license?
When does it make sense to build it yourself?
What does a tool add on top of Remotion?
FAQ

How does a demo map onto Remotion?

In Remotion, a video is a React component that receives the current frame. You decide what's on screen at each frame. A demo usually breaks down like this:

A composition for the whole video, with a width, height, frame rate and duration.
A sequence per scene, placed at a start frame with a length.
Screen components that look like your app: a sidebar, a table, a form.
Animation helpers that move a cursor, type text or highlight a button based on the frame.
Audio for narration and music.

A minimal scene might look like this:

import { AbsoluteFill, Sequence, useCurrentFrame, interpolate } from "remotion";

export const Demo = () => (
  <AbsoluteFill>
    <Sequence from={0} durationInFrames={90}>
      <InvoicesScene />
    </Sequence>
  </AbsoluteFill>
);

const InvoicesScene = () => {
  const frame = useCurrentFrame();
  const opacity = interpolate(frame, [0, 15], [0, 1]);
  return <div style={{ opacity }}>{/* your invoices table */}</div>;
};

You preview it in Remotion's studio in the browser and render with the Remotion CLI.

Can you reuse your real components?

Sometimes, but often not directly. Real components tend to depend on things a video doesn't have:

Dependency	Why it's a problem in a video	Common fix
API calls and data fetching	No backend while rendering	Pass sample data as props
Auth and user context	No logged in user	Wrap in a fake provider
Global CSS and theme setup	Styles may not load the same way	Import the theme into the video project
Animation libraries tied to real time	Remotion renders by frame, not by clock	Drive animation from the current frame
Browser only APIs	Rendering happens in a headless browser, but some APIs still behave differently	Stub them in the video project

Many people end up writing simplified "video versions" of their screens that look the same but take plain props. That's fine, and it's often faster than making real components render cleanly outside the app.

What are the hard parts?

Rendering is the easy part. The time goes into:

The story. Deciding which screens to show, in what order, and why. No framework helps here.
Sample data. Believable names and numbers for every table and chart.
Timing to narration. If there's a voiceover, each click and caption should land on the right word. That means knowing where each word starts in the audio and converting it to frames.
Formats. A 16:9 layout doesn't work as 9:16. Each format needs its own arrangement.
Maintenance. When the real UI changes, the video version of each screen has to change too.

What should you check in the license?

Remotion is not MIT licensed. According to its license page (checked October 2026), the Free License covers individuals, for profit organisations with up to 3 employees, non profits, and evaluation before commercial use, and it allows commercial videos. Other companies need a Company License, sold through remotion.pro. The page also notes that the license will change slightly in Remotion 5.0, and it has an FAQ for edge cases. Read the current terms before you build anything for a company.

When does it make sense to build it yourself?

Building a demo in Remotion yourself makes sense when:

You want full control over every frame and animation.
You'll make a small number of videos and maintain them like code.
You have someone who enjoys this kind of work and has time for it.

It makes less sense when you need many videos, several languages, or frequent updates, and nobody has time to keep the video project in sync with the app.

What does a tool add on top of Remotion?

Some tools use Remotion underneath and automate the parts above. DemoVexa is one: it's product demo video software that writes the Remotion code for you. Claude reads your app's code, writes the script, and a build agent recreates your screens in React and animates them with Remotion, timing each move to the voiceover. You review the brief, script and scene plan instead of writing components.

FAQ

What is Remotion?

Remotion is a framework for making videos with React. You write components that render based on the current frame, preview them in a browser studio and render them to video files.

Is Remotion free to use?

According to Remotion's license page, it's free for individuals, for profit organisations with up to 3 employees, non profits and evaluation, including commercial videos. Other companies need a Company License. Check the current terms, since the page says they change slightly in Remotion 5.0.

Can I use my app's real React components in a Remotion video?

Sometimes. Components that fetch data, need a logged in user or animate on real time usually need sample data props, fake providers or frame based animation before they render cleanly in a video.

Do I need to know Remotion to make code-generated demo videos?

Not with every tool. In DemoVexa, Claude builds the video in React with Remotion, and you change it by editing the brief and script or by asking for the change in plain words. The DemoVexa FAQ on making demo videos from code covers what else you need.

Screen Recorder or Code-Generated Demo: Which Should You Use?

DemoVexa — Thu, 15 Oct 2026 17:53:06 +0000

An honest side by side of recording your screen and rebuilding your UI from code, with the cases where each one is the better choice.

There are now two very different ways to make a product demo video. You can record your screen while you use the app, or you can have a tool rebuild the app's screens from its source code and animate them. Both produce an MP4. They get there in completely different ways, and that changes what each one is good at.

This isn't a post that ends with "always use code". Screen recorders are the right tool for a lot of jobs. The goal is to make the choice on purpose.

Disclosure: I make DemoVexa, which is demo video software that rebuilds your UI from code, so I have a side in this. I've tried to be fair about where a screen recorder is the better choice.

Key takeaways

Screen recorders capture exactly what's on screen, quickly, with almost no setup.
Code-generated demos rebuild the UI from source, which makes them easier to update and keeps real data off screen.
Recorders win for quick, informal and one off videos. Code-generated demos win for videos you'll keep and update.
Many teams will use both, for different kinds of video.

Key takeaways
How does each approach work?
How do they compare side by side?
When is a screen recorder the better choice?
When is a code generated demo the better choice?
What does each one cost you?
Where does DemoVexa sit?
A simple way to decide
FAQ

How does each approach work?

A screen recorder captures pixels from your display, usually with your voice and sometimes your webcam. What you do is what the viewer sees. Tools range from the recorder built into your operating system to dedicated apps with editing, captions and sharing.

A code-generated demo starts from the product's code. A tool reads it, writes or takes a script, adds a voice, and recreates the screens as animation. Nothing is captured from a display. The output looks like the app because it's built from the same components, labels and styles.

How do they compare side by side?

	Screen recorder	Code-generated demo
Setup	Install and press record	Point the tool at the code, write a brief
First video	Minutes, if the take goes well	Longer, because it builds the scenes
What's on screen	Whatever was on your screen	Recreated screens with sample data
Mistakes in a take	Re-record or edit around them	Fix the script or scene plan and rebuild
After a UI change	Record again	Rebuild from the latest code
Sharpness	Depends on your display and zoom	Drawn at the output size
Live behaviour	Shows real responses and real data	Shows a recreation, not live responses
Your face on camera	Usually supported	Usually not the point
Skills needed	Presenting, editing	Reviewing a script and scenes

Neither column is better everywhere. The rows that matter depend on the video you're making.

When is a screen recorder the better choice?

Quick, informal videos. Explaining a bug to a teammate, answering a support question, giving feedback on a design.
Anything with your face. A founder update or a personal sales follow up works better with a real person on camera.
Live behaviour. If the point is that a real integration responds, or real data loads, a recording shows that honestly.
One off videos. If nobody will watch it after this week, the update cost doesn't matter.
No access to the code. If you can't get the code or a good description of the product, recording is the practical option.

When is a code generated demo the better choice?

Videos you'll keep. Landing page demos, docs videos and onboarding clips stay useful for months, so the cost of updating them matters most.
Products that change often. If the UI changes every few weeks, rebuilding from code is easier than re-recording.
Several formats. When you need 16:9, 9:16 and 1:1, a tool that lays out each format separately avoids awkward crops.
Several languages. Rewriting a script and voice per language is easier than recording a person in each one.
Privacy. When your real environment holds customer data you can't show, recreated screens with sample data avoid the problem.

What does each one cost you?

Not in money, which varies by tool, but in time and attention:

Screen recording costs most in the recording and editing session, and again every time the product changes.
Code-generated demos cost most in setup and review: pointing the tool at the right code, reading the script, checking the scene plan and the final video.

If a video will be redone many times, the second pattern usually ends up cheaper. If it's made once, the first one usually is.

Where does DemoVexa sit?

DemoVexa is product demo video software that rebuilds your UI from code instead of recording it. It's a desktop app for macOS, Windows and Linux, with a CLI. It reads a local code folder, Claude writes the script, ElevenLabs can voice it (or you record your own voice, or use captions only), and the screens are recreated as animated React components and rendered as MP4s in 16:9, 9:16 and 1:1. The page on why it makes videos from code instead of screen recordings explains the reasoning in more detail.

It's not a screen recorder, and it doesn't try to replace one for quick, personal videos.

A simple way to decide

Ask two questions about the video:

Will anyone still watch it in three months?
Will the screens it shows change before then?

If both answers are yes, a code-generated demo is worth trying. If either answer is no, a screen recorder is probably the faster choice.

FAQ

Is a code-generated demo better than a screen recording?

Not in general. It's better for videos you'll keep and update, and for avoiding real data on screen. A screen recording is better for quick, personal and one off videos, and for showing live behaviour.

Can I use both approaches in the same product?

Yes. A common split is code-generated demos for landing pages, docs and launches, and screen recordings for support replies, internal updates and anything with a person on camera.

Do code-generated demos look like the real app?

They're built to. Because they use the app's own labels, layout and styles, they look like the product, but they're a recreation, so it's worth comparing them to the real app before publishing.

What do I need to make a code-generated demo with DemoVexa?

A copy of the code on your computer (or the product's website and documents), Claude Code with a Claude Pro or Max plan or an Anthropic API key, and optionally an ElevenLabs key for AI voices. The page on requirements for making demo videos from code lists them in full.

Why Most Features Ship Without a Demo Video (and What Actually Helps)

DemoVexa — Thu, 15 Oct 2026 17:36:53 +0000

It's not laziness. A demo video is a five job pipeline, and developers only signed up for one of those jobs.

A feature gets merged. Someone says "we should make a quick demo for this." A week goes by. Then the next release goes out. Then the UI changes, and the demo you never made would have been out of date anyway.

If you build software, you've probably seen this happen. The feature is in the changelog and maybe in the docs, but there's no video showing it working, so plenty of users never find it.

I don't think this happens because developers don't care. I think it happens because a demo video looks like one task and is actually five.

Key takeaways

A demo video looks like one task, but it's really five: story, script, voice, footage, and editing with formats.
Screen recordings go stale with every release, so the real cost is remaking the video, not making it once.
Writing the story and script as text before recording, and keeping each video to one feature, makes demos cheaper to redo.
Treat demos like docs: when a release changes a screen, the demo for that screen goes on the update list.

Key takeaways
A "quick demo" is five jobs
The screen recording trap
What actually helps
Where DemoVexa fits
A quick checklist for your next feature
FAQ

A "quick demo" is five jobs

Here's what a decent product demo actually needs:

A story. What problem is this feature solving, for whom, and in what order should the screens appear? This is product marketing work.
A script. Words that match each scene, short enough that people don't drop off.
A voice. Either you record yourself, which most of us hate, or you find someone who will.
The footage. Usually a screen recording. Which means clean sample data, a clean browser, no notifications, and a cursor that doesn't wander.
Editing and formats. Cuts, zooms, captions, and then a 16:9 version for YouTube, a vertical one for Shorts or Reels, and maybe a square one for LinkedIn.

Each of these is a separate skill. A developer can do all five, but they'll be slow at three of them, and the whole thing competes with the next ticket. So the demo slips.

The screen recording trap

Most of us start with step 4 because it feels like the "real" work. Open the app, hit record, click through the feature.

Then the problems show up:

You fumble a click on take three, so you restart.
Your local database has test rows called "asdf" and "test test 2" that you don't want on camera.
Someone's real email address is visible in a table.
You finish recording and realise you never explained why the feature matters.

Each of these has a fix that you can set up once:

Problem	Fix
A fumbled click ruins the take	Record scenes separately, so one mistake costs one scene
Test rows like "asdf" on camera	A seed script or demo account with believable data
Real customer data visible	A demo account that never holds real data
The "why" never gets explained	Write who, before and the one moment before recording
The video shows an old UI after a release	Put the demo on the list of things to update when that screen changes

And the biggest one: the recording goes stale with every release. You rename a button or move a menu, and now the video shows something that doesn't exist. You either re-record, or you leave an outdated video up and hope nobody notices. Usually it's the second.

This is why I think a lot of teams quietly give up on demos after the first few. The cost isn't just making the video once. It's making it again every time the product changes. That repeat cost is the main argument for making product videos from code instead of screen recordings, which I'll come back to below.

What actually helps

Here are habits that help, whatever tools you use.

Write the story before you touch the app

Before recording anything, write three lines:

Who is this for?
What were they doing before this feature existed?
What is the one moment that shows the feature working?

That third line is your video. Everything else is setup. If you can't write it down, a recording won't fix it.

Keep it short and about one thing

In my view, a demo for a single feature should usually be under a minute or two. One feature, one flow, one result. If you need to show five things, make five videos. Short videos are also much easier to keep current, because when one screen changes you only redo one of them.

Use sample data on purpose

Make a seed script or a demo account with believable data: realistic names, realistic numbers, nothing private. You'll reuse it for every demo, screenshot and docs page. It's a small piece of work that saves you from blurring things out later.

Separate the script from the footage

If the voiceover and the visuals are recorded together, any change means redoing both. Write the script as text first. Then the visuals can be redone without re-recording your voice, and the voice can be fixed without touching the visuals.

Plan for every format at the start

If you know you need a vertical version, design for it from the start. Cropping a 16:9 recording to 9:16 almost always cuts off the thing you're trying to show.

Treat demos like code that needs maintenance

This is the mindset shift that matters most, in my opinion. A demo is not a one off asset. It's tied to your product the same way docs are. When a release changes a screen, the demo for that screen should be on the list, the same way a docs update would be.

If that sounds like too much work, it's a sign the way you make demos is too expensive to repeat.

Where DemoVexa fits

That last point is the idea behind DemoVexa, product demo video software built around rebuilding a video after a release instead of re-recording it. It's a desktop app (and a CLI) that reads your code and docs, writes a script, adds a voiceover, and rebuilds your UI as animated React components instead of recording the screen. Since version 0.3.5 it can also start from a product's website and uploaded documents, though screens recreated that way are less exact than when it reads the code. When the product changes, you rebuild the video from the latest code.

I'm not saying you need a tool for this. The habits above work with a plain screen recorder too. The point is that the cost of a demo has to be low enough that you'll actually make the next one.

A quick checklist for your next feature

[ ] Three lines written: who, before, the one moment
[ ] Demo account or seed data ready, nothing private on screen
[ ] Script written as text before recording
[ ] Under two minutes, one feature only
[ ] Formats decided up front (16:9, 9:16, 1:1)
[ ] Added to the "update when this screen changes" list

If your team has a way of keeping demos current that works, I'd like to hear it in the comments.

If you want to see what rebuilding a demo from code looks like, DemoVexa has a 14 day free trial, no card needed.

FAQ

Why do product demo videos go out of date so quickly?

A screen recording captures the UI exactly as it was on the day you recorded it. Any renamed button, moved menu or changed flow makes the video show something users can't find. Unless updating demos is part of the release routine, old videos tend to stay up.

How long should a single feature demo be?

There's no fixed rule. In my view, one feature should usually fit in under a minute or two, showing one flow and one result. If you need longer, it's often a sign the video covers more than one feature.

Do I have to record my own voice for a product demo?

No. You can record yourself, use a text to speech voice, or skip narration and rely on captions and music. Whichever you pick, writing the script as text first makes it easier to change later.

Can I just crop a 16:9 demo into a vertical video?

You can, but cropping a wide recording to 9:16 usually cuts off part of the screen you're trying to show. A vertical version works better when each scene is laid out for the taller frame, with the important part of the screen larger and centred.

Is there a way to make a demo video without screen recording?

Yes. Some tools rebuild the interface instead of capturing it. DemoVexa, for example, reads your app's code and recreates the screens as animated React components with sample data, so there is no recording step. The FAQ on making demo videos from code covers requirements and pricing.

Treat Your Demo Environment Like a Test Fixture

DemoVexa — Thu, 15 Oct 2026 15:11:46 +0000

When a feature demo takes far more takes than it should, the cause is often the app, not the person recording it. A toast from a background job slides in. A table sorts differently than it did last time. A timestamp says "3 minutes ago" in one take and "11 minutes ago" in the next. A dev overlay sits in the corner of every frame.

Developers already know this kind of problem. It's the same thing that makes tests flaky: state you don't control. So the fix is the same too. Treat the demo environment like a test fixture: known data, a known starting point, and nothing that changes between runs.

This post is about that setup. It helps a lot if you record your screen, and most of it still helps if you create demo videos from code instead.

Key takeaways

Most demo retakes come from app state you don't control, the same thing that makes tests flaky.
A seed script plus a reset command means every take starts from exactly the same state.
Fixed dates, a fixed clock, a production build and a fixed window size remove most surprises on screen.
Demo the feature flags your users actually have, and check the flow with a scripted walk through before recording.

Key takeaways
What "deterministic" means for a demo
1. A seed script you can run in one command
2. A reset command
3. Pin the screen
4. Freeze time and quiet the background
5. Match feature flags to what users will see
6. Check it like a test
If you don't record at all
FAQ

What "deterministic" means for a demo

A test is deterministic when the same input gives the same output every run. For a demo, that means the same data, the same screen and the same timing every time. Things that commonly break it:

Relative times ("2 hours ago") and today's date
Random IDs, avatars or colours generated per user
Sort orders that depend on when rows were inserted
Background jobs, websockets and polling that push updates mid take
Feature flags that differ between your machine and production
UI that only exists in development: error overlays, devtools buttons, debug banners

Click through your flow once and write down every one of these you see. That list is your to do list for the rest of this post.

Here's how each one maps to a fix covered below:

Source of flakiness	Fix
Relative times and today's date	Fixed demo day in the seed data, plus a fixed clock
Random IDs, avatars or colours	Fixed values in the seed script
Insert order sorting	Explicit positions or created dates
Background jobs, websockets, polling	A demo mode that turns live updates off
Flags that differ from production	Flag values checked in with the demo config
Development only UI	A production build run locally

1. A seed script you can run in one command

Create the demo data in code, not by clicking around in the app. A seed script is reviewable, repeatable and safe to commit, as long as it holds no real customer data.

// scripts/seed-demo.js
const DEMO_DAY = new Date("2026-03-02T10:00:00Z");

const companies = [
  { name: "Northwind Studio", plan: "Team", seats: 12 },
  { name: "Harbor and Pine", plan: "Solo", seats: 1 },
  { name: "Lumen Labs", plan: "Team", seats: 8 },
];

function daysBefore(days) {
  return new Date(DEMO_DAY.getTime() - days * 86400000);
}

A few rules that make seed data look right on camera:

Believable names. "Test Co" and "asdf" pull attention away from the feature. Made up but plausible names don't.
Fixed dates. Build every date from one fixed demo day, so "last week" means the same thing every time you run it.
Stable order. Give rows explicit positions or created dates, so lists don't reshuffle between takes.
Nothing real. No customer names, emails or internal URLs, even ones that look harmless.

2. A reset command

The seed script gets you a good starting state once. The reset command gets you back to it after every take.

{
  "scripts": {
    "demo:reset": "node scripts/reset-demo.js && node scripts/seed-demo.js"
  }
}

Scope the reset to a demo account or tenant, and make it refuse to run against production. The whole point is that take two starts exactly like take one, without you undoing by hand whatever the last take changed.

3. Pin the screen

Run a production build locally. Development builds often show framework overlays and indicators. A production build looks like what users see.
Fix the window size. If you automate the flow with Playwright, set the viewport in the config. If you click by hand, keep one browser profile just for demos: no extensions, no bookmarks bar, no personal logins.
Pick one zoom level and keep it for every scene and every video.
Quiet the OS. Turn on Do Not Disturb or Focus, close chat apps, and hide anything on the desktop.

4. Freeze time and quiet the background

Relative timestamps are the classic flaky demo problem. If you drive the flow with Playwright, its clock API can pin the time:

await page.clock.setFixedTime(new Date("2026-03-02T10:00:00Z"));

If you click by hand, add a demo mode to the app that reads a fixed "now" from an environment variable. While you're there, turn off the things that push surprise updates into the frame:

if (process.env.DEMO_MODE === "1") {
  // fixed clock, no live updates, no onboarding tours
}

Stub slow third party calls with fixed responses too, so a spinner never hangs in the middle of a scene.

5. Match feature flags to what users will see

Demo the state your users actually get. If a flag is on locally but off for customers, the video promises something they can't find. Write the flag values the demo depends on into the demo config, so they're checked in next to the seed data and not living in someone's local settings.

6. Check it like a test

Before you record, walk the flow once with a script. A short Playwright test that clicks through each step and takes a screenshot will catch most surprises: a missing row, a wrong label, a banner you forgot about. Playwright can also record video of a test run, which is meant for debugging, so check whether the quality is good enough for your use before you rely on it.

A short checklist for the day you record:

[ ] npm run demo:reset ran without errors
[ ] Production build, fixed window size, one zoom level
[ ] Clock fixed, live updates off
[ ] Flags match production
[ ] Screenshot walk through looked right

If you don't record at all

Some tools skip screen capture entirely. DemoVexa is one of them: it reads your code and rebuilds the screens as animated React components with sample data, so there's no recording session to stabilise. I wrote a separate guide on creating software demo videos without screen recording on the DemoVexa blog, which covers that workflow from planning to export.

The fixture mindset still applies there. Clear, consistent labels in your UI, realistic sample data and docs that describe each task in order make any demo easier to get right, whether a person or a tool is putting it together.

What usually breaks your demo takes? I'm curious which items people would add to the list above.

FAQ

How do I make demo data look realistic?

Create it with a seed script instead of by hand. Use plausible made up names and numbers, build every date from one fixed demo day, and give rows a fixed order. Keep real customer names, emails and internal URLs out of it completely.

How do I stop timestamps changing between demo takes?

Fix the clock. If you drive the flow with Playwright, page.clock.setFixedTime() pins the time the page sees. If you click by hand, add a demo mode to your app that reads a fixed "now" from an environment variable.

Should I record a demo on a development build or a production build?

A production build, run locally against your demo data. Development builds often show framework overlays, indicators and debug UI that users never see.

Can Playwright record video of a test run?

Yes. Playwright can save a video of each test run, set through the video option in its config or the recordVideo option when creating a browser context. It's designed for debugging, so check whether the quality suits your use before relying on it for a public demo.

How do I keep customer data out of a product demo video?

Use a separate demo account or tenant filled only by your seed script, and check every screen before you record. Tools that rebuild the UI rather than recording it, such as DemoVexa, show sample data instead of your real customers.

DEV Community: DemoVexa

Normalize Voiceover Loudness With ffmpeg loudnorm: A Two-Pass Recipe

Key takeaways

Contents

Why does voiceover loudness drift between videos?

What do LUFS, LRA and true peak mean?

How do you run loudnorm in two passes?

Pass one: measure

Pass two: apply

Which target should you pick?

How do you check the result automatically?

FAQ

Is single-pass loudnorm good enough?

Should I normalize before or after adding music?

Why is my output file 192 kHz?

Does AAC encoding change loudness?

VideoObject Structured Data: Add It, Then Prove Google Reads It

Key takeaways

Contents

What does VideoObject markup look like?

Which properties actually matter?

How do you add key moments?

How do you confirm Google read it?

Why is my video not indexed?

FAQ

Does VideoObject markup work for YouTube embeds?

Is JSON-LD better than microdata for video?

How long does video indexing take?

Do I need a separate thumbnail for the markup?

Transparent Background Video Export: Alpha Channels, ProRes 4444 vs WebM VP9

Key takeaways

Contents

What is an alpha channel in a video file?

Should you export ProRes 4444 or WebM VP9?

How do you encode each format with ffmpeg?

How do you check that the alpha survived?

What goes wrong most often?

FAQ

Does MP4 support a transparent background?

Why does my transparent WebM show a black background?

Is ProRes 4444 lossless?

Which format should I send to a video editor?

How to Demo a Developer Tool, CLI or API on Video

Key takeaways

Contents

What do developers want to see in a demo?

How do you structure a developer tool demo?

How do you make terminal and code text readable?

How do you show an API, which has no UI?

Should you record your terminal or animate it?

What should go in the post or README alongside the video?

A few common mistakes

FAQ

How long should a developer tool demo video be?

How do I make terminal text readable in a demo video?

How do you demo an API that has no user interface?

Should I show real API keys in a demo?

How to Make a Product Demo Video with Remotion (and When Not to Build It Yourself)

Key takeaways

Contents

How does a demo map onto Remotion?

Can you reuse your real components?

What are the hard parts?

What should you check in the license?

When does it make sense to build it yourself?

What does a tool add on top of Remotion?

FAQ

What is Remotion?

Is Remotion free to use?

Can I use my app's real React components in a Remotion video?

Do I need to know Remotion to make code-generated demo videos?

Screen Recorder or Code-Generated Demo: Which Should You Use?

Key takeaways

Contents

How does each approach work?

How do they compare side by side?

When is a screen recorder the better choice?

When is a code generated demo the better choice?

What does each one cost you?

Where does DemoVexa sit?