If you are creating videos, converting existing files, or preparing video content for a website, one of the most important decisions is choosing the right format and compression settings. The smallest possible file is not necessarily the best file. It also needs to play reliably in browsers, work on smartphones, decode efficiently, and preserve enough visual quality for its intended purpose.
I investigated MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, x264 encoder presets, browser compatibility, mobile hardware decoding, and video quality measurement. I also performed practical compression experiments, encoding the same source video at multiple CRF values and comparing the results visually and through objective measurements.
My final decision was to prioritize MP4 with H.264 when a single video file needs to work across the widest practical range of browsers, phones, and external applications.
For short videos primarily intended for mobile viewing, where fast loading and small file sizes matter more than preserving every fine detail, I selected x264 CRF 30 after finding that I could not see a meaningful difference between CRF 22 and 30 during normal playback, even on a large desktop monitor.
However, that decision requires an important qualification: CRF 30 is not a recommendation for movies, premium video productions, or footage where maximum visual fidelity is important. For those use cases, a considerably more conservative value, often around CRF 20, may be a better starting point. I did not conduct a comparable investigation of feature films or high-quality cinematic footage, so those settings should be treated as starting points for separate testing.
This article explains the technical reasoning, the actual compression results, the limitations of those results, and how to choose an appropriate video format and quality setting for your own project.
1. Video Containers and Codecs Are Different Things
Before comparing MP4 and WebM, it is essential to understand the difference between a container and a codec.
A container stores video, audio, timestamps, and metadata together in a file. A video codec determines how the video frames are compressed and decoded.
For example, MP4 can contain H.264, HEVC, or AV1 video. These combinations have different compression characteristics and device requirements, despite sharing the same file extension.
| Component | Examples | Purpose |
|---|---|---|
| Video container | MP4, WebM, MOV, MKV | Packages video, audio, and timing data |
| Video codec | H.264, HEVC, VP9, AV1 | Compresses and decompresses video frames |
| Audio codec | AAC, Opus, MP3 | Compresses and decompresses audio |
| Video encoder | x264, x265, SVT-AV1, libvpx-vp9 | Implements video compression |
Changing a filename from .webm to .mp4 does not convert the video codec. Likewise, storing AV1 inside MP4 does not make the video playable on devices that lack AV1 decoding support.
When discussing video compatibility, always consider the complete combination: container, video codec, audio codec, codec profile, bit depth, and playback environment.
2. MP4 vs WebM: Which Is Better for Web Video?
Both MP4 and WebM are legitimate modern video containers. Neither is universally superior because their practical characteristics depend on the codecs used inside them.
MP4 with H.264: Maximum Practical Compatibility
MP4 containing H.264 video and AAC audio has an exceptionally broad compatibility history. It is supported by mainstream desktop browsers, mobile browsers, operating-system video players, and many third-party applications.
It is also commonly supported by hardware video decoders in smartphones and computers. Hardware decoding can reduce CPU usage, improve playback efficiency, and lower power consumption compared with software decoding.
The primary disadvantage is compression efficiency. Newer codecs can often achieve similar perceived quality at lower bitrates.
However, H.264 remains an excellent choice when reliable playback is more important than achieving the absolute smallest possible file.
WebM with VP9: Efficient and Browser-Friendly
WebM commonly contains VP8, VP9, or AV1 video, with audio typically encoded using Opus or Vorbis.
VP9 often provides better compression efficiency than H.264 at comparable visual quality. It is widely supported by current browsers, including modern versions of Safari.
It would be incorrect to claim that Safari categorically does not support WebM or VP9. Browser compatibility has improved significantly over time.
The more important limitation is compatibility outside the browser. Native operating-system applications, older devices, and third-party software may not handle WebM as consistently as conventional H.264 MP4.
For a browser-only application where playback capabilities can be controlled, WebM is a strong option. For a video that visitors may download and open in arbitrary software, MP4/H.264 remains more predictable.
The Practical Difference
| Requirement | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| Modern browser playback | Excellent | Very good |
| Older browser and device coverage | Generally stronger | More dependent on environment |
| Downloaded-file compatibility | Generally stronger | Less predictable across native apps |
| Compression efficiency | Good | Often better |
| Hardware decoding | Very widespread | Common, but device dependent |
| Best fit | One broadly compatible file | Efficient web delivery with known clients |
The key question is not whether WebM is a good format. It is whether its compression advantages justify the compatibility trade-offs in your specific environment.
3. H.264 vs H.265 vs VP9 vs AV1: Which Codec Should You Choose?
Each major video codec represents a different balance of compression efficiency, encoding cost, hardware support, software compatibility, and licensing.
| Codec | Compression Efficiency | Practical Compatibility | Typical Use |
|---|---|---|---|
| H.264 / AVC | Good | Excellent | General web video, mobile playback, downloads |
| H.265 / HEVC | Generally better than H.264 | Environment dependent | Compatible Apple devices, controlled environments, high-resolution video |
| VP9 | Generally better than H.264 | Very good in modern browsers | Browser-based video delivery |
| AV1 | Excellent potential efficiency | Increasing, with older-device limitations | Modern streaming and compatible devices |
These are qualitative comparisons, not universal bitrate rankings. Actual efficiency depends on the video content, encoder implementation, quality target, encoding preset, and measurement method.
H.264: Mature, Fast to Decode, and Widely Supported
H.264 is highly optimized and supported by an enormous range of hardware and software. Its maturity is an advantage when a video must work reliably without requiring a special playback application.
Its weakness is that newer codecs can often compress video more efficiently. H.264 is also subject to patent and licensing considerations, which should be reviewed for relevant commercial distribution scenarios.
H.265 / HEVC: Better Compression with Compatibility Trade-offs
HEVC can significantly reduce bitrate compared with H.264 at similar quality. It is particularly attractive for high-resolution content and environments where device compatibility is controlled.
Many Apple devices support HEVC very well. However, browser and external-application support varies across operating systems and installed decoding components. Licensing is another consideration.
HEVC can be an excellent choice, but I would not automatically make it the only downloadable video format for a general-purpose website.
VP9: A Practical Open Alternative
VP9 offers good compression and broad modern browser compatibility. It is a compelling option when videos remain within a browser and the playback environment is predictable.
Its main disadvantage for my use case was the uncertainty introduced when users download videos or open them in native applications that may not support WebM or VP9 consistently.
AV1: Excellent Efficiency but Not Universal Hardware Support
AV1 is one of the most promising modern video codecs. It can achieve substantial bitrate savings compared with older codecs, and hardware decoding support continues to expand.
Nevertheless, older devices may lack an AV1 decoder or require software decoding. High-resolution software decoding can consume more CPU power and battery, and may cause playback problems on weaker devices.
If you control your playback environment, AV1 deserves serious consideration. If one file must work across old and new devices and ordinary external video players, H.264 remains the safer default.
The MDN video codec guide provides useful details about these codecs and their browser requirements.
4. One Video Format or Multiple Versions?
This is one of the most important architectural decisions in video delivery.
When multiple versions are possible, a website can provide AV1 or VP9 for compatible devices and fall back to H.264 for other environments. This can improve compression efficiency while preserving broad playback coverage.
However, maintaining multiple versions introduces additional encoding, storage, caching, validation, and playback-selection complexity.
If you need exactly one finished video file per source, a compatibility-first strategy is often preferable.
I chose MP4/H.264 because I wanted a single file that would play in major browsers, on smartphones, and in common downloaded-video workflows without depending on alternative formats.
That is not a claim that MP4/H.264 provides the best compression. It is a decision that values predictable playback above the potential size advantage of a newer codec.
5. Why Mobile Video Has Different Priorities
Video compression should reflect how the content will actually be consumed.
A short clip viewed primarily on a smartphone has different requirements from a feature film watched on a large television. In the first case, loading quickly and using less mobile data may be more valuable than preserving subtle visual details. In the second case, image quality may be the primary objective.
For mobile-oriented short videos, smaller files can provide several advantages:
- Less data must be transferred before playback.
- Downloads may finish sooner on constrained connections.
- Less storage is needed on the device.
- Users consume less mobile data.
- Playback can become more resilient to limited throughput when the encoded bitrate is lower.
However, a smaller file does not guarantee that video will never buffer or freeze. Network variability, peak bitrate, server behavior, playback buffering, and device decoding performance also matter.
Mobile compatibility depends on more than the file extension: hardware decoding, codec profile and level, bit depth, chroma subsampling, resolution, frame rate, and peak bitrate all matter. A video displayed at 390 CSS pixels wide may occupy substantially more physical pixels on a high-density phone screen. Consequently, inspecting a frame reduced to 390 pixels wide is not necessarily equivalent to viewing the original video on that phone. Test actual devices and real playback conditions.
CRF controls quality rather than enforcing an exact maximum bitrate. A complex video can still contain demanding bitrate peaks even when its overall file size is relatively small. If reliable playback on particularly slow connections is essential, consider explicit bitrate or VBV constraints, appropriate resolution limits, and testing under realistic network conditions.
The central principle is simple: optimize for the intended viewing experience, not for an abstract maximum-quality target.
6. Understanding x264 CRF: Lower Is Better Quality, Higher Is Smaller
After choosing H.264, the next challenge is determining how aggressively to compress the video.
In x264, Constant Rate Factor, or CRF, controls the trade-off between retained visual detail and file size.
A lower CRF generally produces higher-quality, larger files. A higher CRF generally produces smaller files with greater compression loss.
CRF does not set an exact bitrate or output size. The encoder allocates bits according to the source material, so a simple scene and a highly detailed scene can produce very different file sizes at the same CRF.
CRF also does not determine fundamental decoder compatibility. Two properly encoded H.264 videos using CRF 22 and CRF 30 can have the same codec, profile, level, pixel format, dimensions, and frame rate.
The difference is primarily their compression quality and bitrate characteristics.
Importantly, CRF numbers are not directly comparable between different codec implementations. A CRF of 30 in x264 does not correspond to the same visual quality as a CRF of 30 in an AV1 encoder.
7. My Real Compression Experiment: CRF 22 Through 32
I wanted to determine how much compression I could apply before the difference became important during normal playback.
I used one short, previously compressed video and generated H.264 comparison files at CRF 22, 24, 26, 28, 29, 30, 31, and 32.
The key properties of the video were preserved, including resolution, frame rate, duration, and frame count. The comparison also used consistent encoder settings so the effect of the CRF change could be evaluated.
The results showed substantial differences in file size.
| CRF | Approximate Size Relative to Original | What It Means |
|---|---|---|
| 22 | 63% | More conservative compression and stronger detail retention |
| 24 | 49% | Smaller file with modest additional quality loss |
| 26 | 38% | Further savings while retaining considerable detail |
| 28 | 30% | Compact output with relatively strong source similarity |
| 29 | 26% | More aggressive compression |
| 30 | 23% | My preferred compromise for this tested content |
| 31 | 21% | Additional savings with lower source fidelity |
| 32 | 19% | Smallest tested output and the greatest measured quality loss |
These percentages are based on the tested source and must not be interpreted as typical savings for arbitrary videos. The table percentages are independently rounded; calculate precise relative savings from the underlying file sizes rather than dividing the rounded entries.
The most surprising result was that I could not see a meaningful visual difference between CRF 22 and CRF 30 during normal playback, even on a large desktop monitor.
I also examined more aggressively compressed versions, including CRF 32, without noticing a significant difference during ordinary playback of that particular clip.
That observation was important because the same videos were primarily intended for smaller mobile displays. If the quality reduction was not distracting on my desktop monitor, I had little reason to pay a substantial file-size penalty for additional detail that did not improve my intended viewing experience.
However, this was a subjective observation about one type of source material. It does not prove that all users, all smartphones, or all videos will behave the same way. High-density mobile screens and close viewing distances can still reveal artifacts, especially in fine details or gradients.
8. The Objective Measurements Confirmed Real Quality Loss
Not seeing a difference during playback does not mean two videos are mathematically identical.
I also compared the encoded outputs using objective image-quality measurements. As CRF increased, similarity to the source decreased.
For a consistently downscaled comparison intended to approximate a high-density mobile display, representative SSIM measurements were:
| CRF | Approximate SSIM | Output Size Relative to CRF 28 |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
The trend is clear: stronger compression reduced the measured fidelity of the encoded video. Close inspection also showed subtle differences in fine lines and texture.
Yet the ordinary viewing experience remained very similar for the tested source. This is precisely why objective measurements and subjective evaluation should be used together.
SSIM measures image similarity, not the complete human viewing experience. It cannot fully account for temporal artifacts, perceived sharpness, motion behavior, or the subjective importance of individual visual details.
VMAF is another useful perceptual-quality metric. Netflix released VMAF v1 models in June 2026, including a model designed around phone-viewing conditions. These models explicitly recognize that perceived quality depends partly on screen size and relative viewing distance.
A conservative encoded sample in the investigation had a reported mean VMAF of approximately 95, but a consistent VMAF series was not available for all the aggressive CRF settings. Therefore, I did not use VMAF to claim that CRF 30 or 32 reached any universal quality threshold.
The practical conclusion was narrower: the tested short video tolerated aggressive H.264 compression extremely well during normal playback.
9. Why I Chose CRF 30 for Short Mobile Videos
After comparing the files, my decision was CRF 30 for similar short videos primarily consumed on mobile devices.
The reasoning was straightforward:
- The videos were short and not intended to deliver cinematic image quality.
- Fast loading and smaller downloads were important.
- I could not see a meaningful difference between CRF 22 and 30 on a large desktop monitor.
- CRF 30 produced much smaller files than conservative settings.
- CRF 32 was also visually acceptable on the tested sample, but gave less confidence for more complex material.
Compared with CRF 28, CRF 30 reduced the tested output size by approximately 21%. Compared with CRF 22, it reduced the output by more than 60%.
For short mobile-oriented clips where the goal is a pleasant picture, quick loading, and reasonable bandwidth consumption, that was a worthwhile trade-off.
But the condition matters enormously: I chose 30 because of the actual viewing purpose and the results of the tested material, not because 30 is inherently the best CRF for smartphones.
A mobile device does not require CRF 30. It can display a much higher-fidelity encode perfectly well. CRF 30 is a deliberate decision to exchange some source fidelity for smaller files when that exchange is acceptable.
Before applying it to a collection containing substantially different content, I would test multiple representative clips, including difficult motion, dark scenes, gradients, text, and fine textures.
10. Why CRF 30 Is Not My Recommendation for Movies or High-Quality Video
This is the most important limitation of the experiment.
Do not take my CRF 30 result and apply it blindly to feature films, premium video content, professional footage, or videos intended for large-screen viewing.
Those types of content may contain subtle gradients, film grain, low-light scenes, complex motion, finely textured surfaces, and carefully graded colors. Preserving those details may be more important than saving a relatively small amount of bandwidth.
For conventional high-quality 1080p video, I would begin with a much more conservative x264 setting, around CRF 20, and evaluate values on either side according to the material.
A practical starting range might be CRF 18–22 when visual fidelity is important, although the appropriate value can fall outside that range depending on resolution, content, and requirements.
This suggestion is consistent with commonly published encoding guidance. For example, HandBrake's quality documentation recommends approximately RF 20–24 for many 1080p x264 use cases.
I did not run the same controlled investigation on feature films or premium cinematic footage. Therefore, I cannot claim that CRF 20 is universally optimal, that CRF 22 is always enough, or that any particular film would look unacceptable at CRF 30.
The correct method is to select representative scenes, encode several quality levels, compare them on the intended display, and determine the point where additional compression becomes visibly harmful.
If the video will be archived, edited again, or used as a source for future encodes, a high-quality master should be retained separately from the compressed delivery version.
11. Why I Used the x264 veryslow Preset
CRF controls one aspect of compression quality, while the x264 preset controls how much effort the encoder spends searching for efficient coding decisions.
x264 provides presets ranging from very fast to very slow. In general, slower presets use more CPU time and can deliver better compression efficiency at comparable visual quality.
I compared the medium and veryslow presets on the same source. At the tested quality setting, veryslow produced a smaller file.
For offline encoding performed once and reused many times, the additional processing time can be worthwhile.
That is why I selected -preset veryslow.
However, it is not universally optimal. If videos must be processed immediately, CPU resources are expensive, or an extremely large backlog must be handled, slow or medium may offer a better operational balance.
The preset primarily changes encoding complexity and compression efficiency. It does not turn H.264 into a different codec or make the resulting file inherently incompatible with mobile devices.
12. For Anime Video, I Use x264's Animation Tune
When the source contains drawn animation or anime-style imagery, I use -tune animation with x264.
This is distinct from the CRF setting. A tune changes certain encoder decisions to suit particular visual characteristics. The animation tune is intended for material featuring drawn edges, flat-colored regions, and stylized motion.
My preference is therefore:
- Anime or drawn animated video:
-preset veryslow -tune animation. - Ordinary live-action footage: do not automatically enable the animation tune; start with the encoder defaults or evaluate an appropriate tune separately.
It is important not to misunderstand what the tune does. -tune animation does not guarantee visibly better quality or smaller files. It changes encoder behavior, and the result depends on the material.
I performed a separate fixed-CRF comparison using the animation tune. In that particular comparison, enabling the tune made the resulting file approximately 6% larger and slightly improved the measured image similarity. The visual difference was small.
The main CRF 22–32 size comparison was performed without the animation tune. Therefore, the exact sizes and compression ratios from that experiment should not be assumed to remain identical when -tune animation is enabled.
Nevertheless, for anime footage, I prefer using the animation-specific tune and evaluating the resulting size and quality as part of that content's encoding profile.
Encoder tuning should always be viewed as a content-dependent adjustment rather than a universal quality upgrade.
13. My Recommended FFmpeg Settings for Short Mobile-Oriented Anime Video
For a conventional SDR anime video that actually needs transcoding, this command represents the profile I would use as a starting point:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4This command makes the key choices explicit:
-c:v libx264uses the software H.264 encoder.-preset veryslowprioritizes compression efficiency over encoding speed.-tune animationenables animation-oriented encoder adjustments.-crf 30applies the aggressive constant-quality target selected for this type of short video.-profile:v highselects a commonly supported H.264 profile for modern devices.-pix_fmt yuv420poutputs 8-bit 4:2:0 video.-map 0:v:0selects the first video stream.-map '0:a:0?'optionally selects the first audio stream.-c:a aac -b:a 128kencodes conventional AAC audio when audio is present.-movflags +faststartmoves MP4 initialization metadata toward the beginning of the file.
This is an example, not a universal command for every input. The exact needs of your source video may require additional handling.
In particular, HDR and 10-bit material should not be blindly converted to 8-bit SDR without appropriate color management: incorrect colors, lost highlight detail, or visible banding can result. Rotation metadata, variable frame rates, sample aspect ratios, interlaced sources, unusual audio layouts, and incompatible resolution limits also require attention.
When the source frame rate and dimensions are already suitable, preserving them generally makes comparisons easier and avoids unnecessary scaling or motion changes. Avoid forcing a constant frame rate on variable-frame-rate sources unless required: the conversion can duplicate or discard frames. If resizing, preserve display aspect ratio and ensure the dimensions are compatible with the chosen 4:2:0 pixel format. Very high resolutions, frame rates, or H.264 levels may exceed older devices' decoding limits, so compatibility sometimes requires deliberate downscaling or a lower frame rate.
14. A More Conservative FFmpeg Starting Point for High-Quality Video
If video fidelity is substantially more important than file size, begin with a lower CRF and evaluate the result.
For example, the following is a reasonable experimental starting point for conventional SDR live-action video:
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4The slow preset in this example is a practical general-purpose starting point, not a claim that it outperforms veryslow. Using veryslow would also be reasonable when additional encoding time is acceptable.
This high-quality profile is a recommendation to test, not a configuration proven by my short-video experiment.
For premium video, test CRF values around 18, 20, and 22, then choose based on the visible results. Difficult grain or motion may require different settings, and archival masters may require much less aggressive compression.
15. Do Not Re-Encode a Video Without a Reason
Lossy video compression is not free. Re-encoding a file that has already been compressed can introduce additional artifacts, even when the new output appears similar to the source.
Before transcoding, ask whether the original file already satisfies your compatibility, size, and quality requirements.
If the file already contains compatible H.264 video and AAC audio, and no visual transformation is necessary, stream copying may be better than another lossy encode.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4This operation copies the compressed streams without encoding them again. It can change the container arrangement while avoiding another generation of video compression loss.
It will not normally deliver the same file-size reductions as lowering the quality through a new encode.
If your existing video is already compact, compatible, and visually acceptable, keeping it may be the best optimization of all.
16. Validate Encoded Videos Instead of Trusting File Size Alone
A successful FFmpeg exit code does not automatically prove that a video meets every requirement.
Start by inspecting the output streams with FFprobe:
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4Verify the codec, pixel format, dimensions, frame rate, duration, and audio streams.
Next, decode the entire output to detect certain corruption or decoding errors:
ffmpeg -v error -xerror -i output.mp4 -f null -For compression experiments, compare outputs generated from the same source. Keep the important variables constant and change only one major setting at a time.
Watch the resulting video in motion, inspect fine details, and pay attention to gradients, dark regions, moving objects, and text.
If possible, use objective metrics such as SSIM, PSNR, or VMAF to supplement visual comparisons. Do not interpret a single high score as proof that all artifacts are invisible.
Finally, test the video on representative devices and in downloaded-file workflows. Browser support information is valuable, but actual playback testing is especially important when compatibility is a primary goal.
17. Make Sure Your MP4 Files Are Delivered Correctly
Good encoding settings cannot compensate for poor web delivery.
For ordinary progressive MP4 playback, configure the correct Content-Type: video/mp4 header and support HTTP byte-range requests where partial retrieval and seeking are required.
The FFmpeg +faststart option moves the MP4 initialization information toward the beginning of a conventional file. This helps progressive loading but does not improve visual quality or reduce bitrate.
A basic HTML video element can deliver one H.264 MP4:
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>The preload attribute is a browser hint rather than a strict download limit. Browser autoplay policies may also require the video to be muted or silent.
If a page contains multiple videos, avoid downloading all of them immediately. Loading videos only when needed can reduce mobile data consumption and improve perceived responsiveness.
For short mobile clips, optimizing download scheduling can be as important as reducing the encoded file size.
18. Which Video Format and Quality Should You Choose?
The correct answer depends on what you are optimizing for.
| Your Goal | Recommended Starting Point |
|---|---|
| One broadly compatible web and downloadable video | MP4 + H.264 + AAC when audio exists |
| Modern browser delivery with multiple format options | AV1 or VP9, with an H.264 fallback |
| Maximum compression on supported devices | Evaluate AV1 |
| Controlled HEVC-compatible playback environment | Consider MP4 + HEVC |
| Short mobile-oriented clips where file size matters most | Consider x264 CRF 30 after representative testing |
| Anime or drawn animated video | Evaluate x264 with -tune animation |
| High-quality films or premium video | Begin with a more conservative CRF near 20 and test |
| Offline encoding where CPU time is less important | Consider x264 slow or veryslow |
| Fast processing and limited CPU resources | Consider x264 medium or slow |
| Existing video already meets your requirements | Keep it or remux without re-encoding |
| Archival or future editing | Retain a high-quality master separately from delivery files |
19. My Final Decision and What the Experiment Actually Proved
After investigating video formats, compatibility, encoding efficiency, and real compression results, I selected a practical delivery profile for short mobile-oriented video.
The chosen format was MP4 with H.264, because predictable compatibility across browsers, phones, downloads, and external applications was more important than obtaining the smallest possible file using a newer codec.
The chosen encoder was libx264 with the veryslow preset, because the video could be encoded offline and the additional processing time was acceptable.
For anime video, I use the animation tune, while recognizing that it changes encoder behavior and does not guarantee smaller files or universally better visual results.
For short mobile-oriented videos, I chose CRF 30, because my comparison showed a substantial reduction in file size without a meaningful visual difference during normal playback, even when compared on a large desktop monitor.
That result does not mean CRF 30 is the ideal setting for movies or high-quality footage. For content where fine details, gradients, grain, and overall fidelity matter more, I would begin testing around CRF 20 or another appropriately conservative value. I did not perform a corresponding controlled study on cinematic footage, so I do not present that number as an experimentally proven optimum.
The most important conclusion is that there is no single universally best codec, format, or CRF value for all videos.
If you prioritize maximum compatibility and only want one file, MP4/H.264 is a strong default. If you can provide fallback formats and want better compression, investigate VP9 and AV1. If you are encoding short videos mainly viewed on phones, test whether a higher CRF produces sufficiently small files without harming the intended experience. If you are encoding films or premium footage, use more conservative quality settings and verify them carefully.
Choose the playback requirements first, the codec second, and the compression quality last. Then test the result on the devices and under the conditions that actually matter. That approach is more reliable than blindly adopting a codec or CRF value simply because it is newer, more efficient, or commonly recommended.