To compress a screen recording, compare delivery encodes against the smallest text viewers must read. File size alone is a poor success measure. A much smaller demo is unusable if the feature name, selected option or result becomes indistinct on a phone.
Keep an untouched master, choose a difficult sample, and change one encoding variable at a time. This lets you identify the source of damage rather than guessing which of several simultaneous changes made the recording worse.
The worksheet here is a reproducible method, not a reported benchmark. It includes no invented file sizes, measured quality scores or claim that a particular setting guarantees readable output.
Check whether the original is readable first
Open the master at the size a viewer will actually see. If the interface already uses tiny labels across a wide desktop, compression is not the first problem. Zoom the application appropriately and record a focused action, or redesign the framing before testing encodes.
Do not confuse pixel dimensions with useful detail. A large canvas can contain a small app window. Enlarging that window later does not create the original information a closer recording would have captured.
The mobile software-demo recording guide helps prepare a source that survives narrow viewing. Use it before spending time tuning a file that cannot explain its own action.
Pick a difficult sample instead of the easiest frame
Choose a short section with the elements that matter: a small product label, a menu opening, a cursor moving and a brief scroll. A static title screen may compress beautifully while telling you nothing about the interface sequence.
For an original practice fixture, create a dummy dashboard with labels such as “Owner,” “Due Friday” and “Export selected.” Include no real customer records. Record selecting a row, opening a menu and displaying the result.
Use the same sample for every encode. If you compare different scenes, changes in movement and visual complexity can affect both file size and appearance, making the comparison hard to interpret.
Run a controlled quality ladder
One approach is a small H.264 quality ladder in FFmpeg. The following commands are examples for a local file you own; they do not upload it or claim that these settings are platform requirements.
ffmpeg -i demo-sample.mov -c:v libx264 -preset medium -crf 18 -c:a aac -b:a 128k demo-q18.mp4
ffmpeg -i demo-sample.mov -c:v libx264 -preset medium -crf 22 -c:a aac -b:a 128k demo-q22.mp4
ffmpeg -i demo-sample.mov -c:v libx264 -preset medium -crf 26 -c:a aac -b:a 128k demo-q26.mp4
These examples keep the named codec and preset consistent while changing the quality parameter. They deliberately avoid adding a crop, resize or frame-rate conversion. If your installed FFmpeg lacks this encoder, use the appropriate installed encoder and its documentation rather than copying incompatible options.
Lower or higher numeric controls can mean different things in different encoders. Consult the tool's documentation. Do not apply a remembered range from an unrelated codec and call it an equivalent quality setting.
Inspect the same evidence in every version
Fill in your own results rather than assuming a winner:
| Review item | Master | First encode | Second encode | Third encode |
|---|---|---|---|---|
| File size | Record locally | Record locally | Record locally | Record locally |
| Small label readable | Check | Check | Check | Check |
| Menu remains distinct | Check | Check | Check | Check |
| Cursor follows cleanly | Check | Check | Check | Check |
| Scroll stays understandable | Check | Check | Check | Check |
| Final result identifiable | Check | Check | Check | Check |
Play the files as well as pausing them. A paused screenshot can conceal motion damage or an abrupt change. Review at normal phone size before inspecting enlarged pixels.
HandBrake's documentation makes a useful related point: constant-quality output size varies with the source. The same setting is not a promise of a particular megabyte count. Keep the actual result in the worksheet.
Change dimensions only when the quality test calls for it
If every encode retains unnecessary empty desktop around the app, a deliberate crop may improve the presentation. Treat that as a new test series. Preserve the relevant controls and compare it against the original framing.
Do not reduce dimensions simply because a smaller file is possible. The button label that tells the viewer what happened may be the first detail to disappear. Nor should an upscaled export be described as recovered original detail.
For shape changes, use the horizontal-to-vertical guide. Reframing and compression solve related but different problems; keep their decisions visible in your notes.
Check the final production path
A clear delivery sample can still be damaged by another export later. Use the accepted master or approved intermediate for assembly rather than a copy downloaded from a previous social post. Inspect the final rendered output again.
Prolifik Video Hook & Demo accepts your own product recording and places it after a hook. The workflow has upload and duration limits, so inspect the current requirements before selecting the file. It also replaces the recording's audio with music or silence; keep original narration requirements separate from image-quality decisions.
Once the recording is readable and within the current input limits, prepare it for Video Hook & Demo. Preserve the master and the test notes so the next edit does not begin from the most compressed copy.
Use a readable recording as the demo source
Keep the untouched master and accepted delivery copy, then inspect them against the actual Hook & Demo requirements.
Prepare a Hook & Demo recordingFacts checked 2026-10-24. Worked examples are illustrative unless a real source is identified.
- FFmpeg encoder and libx264 options Checked 2026-10-24
- HandBrake: Adjusting quality Checked 2026-10-24
- Prolifik recording upload requirements Checked 2026-10-24