# Frame Relay Notes — full text

> Frame Relay Notes is an independent educational publication about video containers, codecs, conversion, and compression decisions. It provides no upload service, downloader, DRM bypass, software sales, or sponsored rankings and is not connected with any former converter, app, service, or business on this domain.

# Burned-In vs Soft Subtitles: Tracks and Sidecars

> Burned-in subtitles are part of the video image; soft subtitles remain separately selectable when the playback system supports them. A sidecar holds timed text in a separate file. Choose by the viewer’s needs and the destination’s documented support, not the filename alone. Preserve authorized originals and caption assets, then check the delivered result before replacing any working copy.

Source: https://videos-converter.net/burned-in-vs-soft-subtitles/  
Publisher: Frame Relay Notes  
Published: 2026-09-08  
Updated: 2026-09-08

## What is the difference between burned-in and soft subtitles?

Burned-in subtitles are part of the video image; soft subtitles remain separately selectable when the playback system supports them. A sidecar holds timed text in a separate file. Choose by the viewer’s needs and the destination’s documented support, not the filename alone. Preserve authorized originals and caption assets, then check the delivered result before replacing any working copy.

A request to “include the subtitles” needs one more conversation. Does the recipient want one fixed presentation, several language choices, or a caption file to manage separately? Those are different deliverables. This guide compares the packaging choices and provides an original paper worksheet; it does not report software or playback tests.

## What are the three delivery arrangements?

[HandBrake’s subtitle documentation](https://handbrake.fr/docs/en/latest/advanced/subtitles.html) distinguishes permanent image rendering from selectable output tracks. Its terminology is useful, but the destination still needs to be specified.

| Arrangement | Where the subtitle information goes | Question to settle before delivery |
|---|---|---|
| Burned-in, or hard subtitles | Into the video picture | Is a fixed presentation actually requested? |
| Embedded soft track | A separate track inside the container | Does the intended player support this track format? |
| Sidecar | A separate timed-text file accompanying the media | How will the recipient associate and deliver both assets? |

“Embedded” is an especially ambiguous handoff word. Ask whether it means text painted into the image or an independently selectable stream packaged with the video. Write the answer explicitly rather than accepting a tick beside “subtitles included.”

For a project folder, our editorial preference is to retain the authorized clean source and separate caption assets even when a fixed viewing version is requested. Name each output by its purpose. A presentation copy and an editable source should not depend on someone remembering which file they opened last.

## Are captions and translated subtitles the same choice?

Purpose and packaging are separate axes. W3C’s Web Accessibility Initiative describes captions as synchronized speech plus relevant non-speech audio information. Its guide uses “subtitles” for translation, while acknowledging regional differences in terminology. A dialogue translation should not simply be assumed to contain the information a viewer needs when they cannot hear the audio. [WAI caption guidance](https://www.w3.org/WAI/media/av/captions/)

For the handoff, ask two independent questions: “What information must this text communicate?” and “How must the viewer receive it?” Record the intended language, audience and content scope before choosing the package. A menu item called English does not answer all three.

WAI also warns that automatically generated captions need accuracy review. Changing the delivery arrangement is not a substitute for that review. If accessibility requirements are part of a commissioned project, involve the responsible accessibility specialist; this comparison is not a compliance determination.

## Why does the exact subtitle format matter?

A subtitle is not necessarily a string of editable letters. HandBrake distinguishes bitmap formats such as PGS from text formats such as SRT. Its current documentation says PGS cannot pass through to MP4, whereas multiple PGS tracks can pass through to MKV. That is a documented HandBrake output distinction, not a promise about every converter or player.

For a real request, complete a compatibility sentence: “This subtitle format, in this output container, must work in this named application and version.” If a recipient only supplies an extension, ask for the missing destination information.

Our [guide to conversion without quality loss](/convert-video-without-quality-loss/) explains the wider container-and-stream decision. Keep the subtitle decision visible alongside it. A successful picture transfer is not evidence that every requested text asset has survived.

Do not approve an alternative merely because its name appears in an export menu. Ask the person responsible for delivery to document what changes, what stays selectable, and which original assets will be retained.

## What does an SRT sidecar actually contain?

The Library of Congress’s preliminary SRT description, updated May 27, 2025, describes a text file containing numbered entries, start and end times, subtitle text, and separators. The file does not contain the video or audio itself. It also notes that formatting presentation can depend on the application. [Library of Congress SRT description](https://www.loc.gov/preservation/digital/formats/fdd/fdd000569.shtml)

That makes two inventory entries sensible: one for the media and one for the sidecar. In our proposed record, both receive the same project identifier but keep distinct filenames, revision numbers and purposes. This is an organizational convention, not an assertion that every player automatically matches files by those names.

Keep the delivered text file as well as the working version. If a colleague later reports a missing phrase, the record should identify which revision they received, not just which video title they remember.

## Does putting SRT into MKV preserve the original file?

Not as an intact sidecar by definition. Matroska’s documented SRT mapping puts the subtitle text into its block data in UTF-8; the timing becomes block timestamps and durations. This is a representation of the subtitle information inside the container, rather than simply the complete original text file tucked away unchanged. [Matroska subtitle mapping](https://www.matroska.org/technical/subtitles.html)

Our practical conclusion is to keep the source sidecar independently. An embedded track may satisfy the viewing requirement while the original file remains useful for comparison and revision history. Those are different reasons to retain an asset.

In a handoff note, separate “text and timing checked” from “original file preserved.” Neither phrase should stand in for the other. This distinction also prevents an archive folder from being mistaken for a viewing-only delivery.

## What changes for a web page?

MDN documents HTML’s track element as a way to associate WebVTT timed-text files with media. Its fields distinguish the track’s kind, language and user-visible label. Multiple tracks can be supplied; the documentation also describes user preferences in track selection. This is a particular web delivery mechanism, not a statement that an arbitrary video player accepts any sidecar. [MDN track reference](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/track)

A useful question for the web publisher is therefore: “Which timed-text file did you associate with this particular media revision?” Follow it with the intended label and language. Ask for a check on the actual published presentation, not only confirmation that a file was received.

There is no page code to run here. The publisher should follow current documentation for their implementation and report the resulting behavior.

## How can a three-cue record expose an incomplete handoff?

The following is an original fictional planning example, not a caption file, media test, translation or recommended reading-speed schedule. All times are elapsed seconds from the same imaginary clip start.

| Cue | Start | End | Fictional text | Duration |
|---|---:|---:|---|---:|
| A | 1.000 | 3.000 | The red folder is ready. | 2.000 seconds |
| B | 4.500 | 6.000 | Paper rustles. | 1.500 seconds |
| C | 8.000 | 10.500 | Let us check the final page. | 2.500 seconds |

Subtracting start from end gives 2.000, 1.500 and 2.500 seconds: 6.000 seconds of scheduled display in total. The gaps are 1.500 and 2.000 seconds. Nothing in that arithmetic establishes synchronization with real speech, sufficient reading time or complete caption coverage.

For this example, suppose the fictional request is an English caption option that viewers can select. A delivery report should answer:

- Which exact media and text revisions were used?
- Are all three entries present with their intended wording and timing?
- How is the option identified to the viewer?
- Was its selection checked in the named destination?
- Where are the retained source assets?

If the report only says “three entries exported,” the selection requirement remains unanswered. If it says “English option present,” the content check remains unanswered. Mark those as unresolved questions, not passed tests.

## What should the final acceptance note say?

Our suggested acceptance note separates content, timing, presentation and preservation. For each, record the reviewer, the exact output revision, the destination checked and any unresolved issue. Do not replace those fields with a single “looks fine.”

For content, compare the requested text with the delivered version. For timing, describe what was actually reviewed rather than extrapolating from the first cue. For presentation, record the observed selection and display behavior in the destination. For preservation, identify the retained originals and backups.

The [file-size decision guide](/reduce-video-file-size/) helps keep caption requirements separate from compression targets. Do not silently remove an accessibility asset to meet a smaller-file request; bring the conflict back to the person setting the delivery requirements.

Work only with media and text you are authorized to process. Respect licenses and access controls, and do not submit private recordings to an unapproved service. Keep originals and backups before changes. A format decision does not grant permission to copy, distribute or bypass protection.

For related terminology, the [Format Basics collection](/format-basics/) provides the next layer. The useful endpoint is a precise handoff: what the text contains, where it is stored, how the intended viewer accesses it, and what was actually checked.

## Sources

Primary documentation checked September 8, 2026: HandBrake’s current subtitle guide; W3C WAI’s caption guidance, updated September 17, 2024; the Library of Congress’s May 2025 SRT description; Matroska’s subtitle mapping; and MDN’s track reference, modified April 24, 2026. All are linked beside their supported claims. The inventory and three-cue worksheet are original editorial examples, not rendered-output testing.

## Frequently asked questions

**Are embedded subtitles always burned into the picture?**

No. Ask whether embedded means a separately selectable track inside the container or text rendered into the picture. The wording alone is ambiguous. Put the intended arrangement in the delivery record, name the destination, and request an actual check there rather than inferring behavior from the filename.

**Does a translated subtitle track replace captions?**

Do not assume so. W3C WAI distinguishes caption content, including relevant non-speech audio, from a dialogue translation, while noting that terminology varies regionally. Specify the intended audience and information required. Packaging the translation differently does not establish that it meets the caption requirement.

**Is an SRT file a complete video?**

No. The Library of Congress describes SRT as text with subtitle timing information, not a file containing the video or audio. Treat the sidecar and media as distinct assets in your inventory. Identify their matching revisions and confirm the recipient’s documented delivery requirements.

**Will a web page use any subtitle file automatically?**

Do not assume that. MDN documents HTML text tracks using WebVTT files associated with the media, with separate information for language, kind and label. Ask the publisher which file and media revision were connected, and what was checked in the actual presentation.

**Does the three-cue example prove that captions work?**

No. It is a fictional paper record with checked arithmetic, not a playback or accessibility test. Its purpose is to separate questions about wording, timing, selection and retained originals. A real acceptance report needs the actual destination, output revision and review findings, including unresolved issues.


---

# Convert Video Without Quality Loss: What Is Possible

> Video conversion avoids image-quality loss only when compatible compressed streams can be copied into a new container without re-encoding, a process called remuxing. If you change codec, resolution, frame rate, color data, or burn content into the picture, the video must usually be transcoded and a lossy output may incur generation loss. Preserve the original, inspect every stream, test a representative clip, and verify timing, metadata, subtitles, audio, and target-device playback.

Source: https://videos-converter.net/convert-video-without-quality-loss/  
Publisher: Frame Relay Notes  
Published: 2026-07-19  
Updated: 2026-08-26

## Copy compatible streams instead of re-encoding them

You can convert video without image-quality loss only when the job does not require lossy re-encoding. If the existing video and audio streams are compatible with the destination container, a tool can remux—copy those streams into a new container. When codec, resolution, frame rate, color representation, or other media data must change, transcoding creates a new encode and may introduce generation loss.

The guides in [format basics](/format-basics/) begin by identifying what is actually inside the file.

## Separate container from codec

A container holds one or more streams plus timing and metadata. Common filename extensions often identify the container, while the video stream inside may use one of several codecs. Two files with the same extension can therefore behave differently on the same device.

Before converting, inspect:

- container;
- video codec and profile;
- audio codec and channel layout;
- resolution and frame rate;
- bit depth and color information where relevant;
- subtitle, chapter, timecode, and metadata streams;
- duration and variable- or constant-frame-rate behavior.

Use a trusted media-inspection tool and the current documentation for the player, editor, or platform receiving the file. An extension change alone does not convert anything; it merely gives the container a new nametag and hopes nobody asks follow-up questions.

## Use remuxing when the destination accepts every stream

Remuxing rewrites the container structure while copying selected media streams. Because the compressed video samples are copied rather than decoded and encoded again, the image data does not undergo another lossy generation.

That does not guarantee perfect equivalence in every other respect. A new container may not support the same subtitles, attachments, chapters, metadata fields, timecode, edit lists, or unusual timing. Verify every stream you need before and after the operation.

Remuxing also cannot make an unsupported codec playable merely by placing it in a familiar container. Compatibility depends on the combination of container, codec, profile, level, audio, and device capabilities.

## Know when transcoding is required

Transcoding is usually required when you need to change the codec, reduce resolution, alter frame rate, burn in captions, change color representation, or meet a platform’s encoding specification. The source is decoded and encoded into a new stream.

Lossless codecs and mathematically lossless settings exist, but their files may be large and poorly supported for delivery. “Lossless setting” also does not recover detail already discarded by the source. A blocky low-bitrate file cannot be converted into the missing original by giving the output a more ambitious bitrate.

## Preserve the original and make a test clip

Copy the source to protected storage and never write output over the only original. Create a short representative test containing motion, fine texture, gradients, dark areas, speech, music, cuts, and captions that matter to the project.

Compare:

| Check | What to verify |
|---|---|
| Streams | Expected video, audio, subtitle, and chapter tracks exist |
| Timing | Start, end, synchronization, seeking, and variable timing behave |
| Image | Motion, edges, gradients, noise, and dark detail remain acceptable |
| Audio | Channels, language, sync, loudness behavior, and gaps are correct |
| Metadata | Orientation, dates, captions, tags, and color signaling survived as needed |

Use the actual target players and devices. A file opening in one desktop application proves only that one application opened it.

The [file-size reduction guide](/reduce-video-file-size/) covers intentional compression, while [compression workflows](/compression-workflows/) keeps those tradeoffs separate from remuxing.

## Verify before deleting anything

Check duration, stream counts, synchronization, representative frames, playback through the whole timeline where stakes justify it, and hashes for any streams expected to be copied byte-for-byte. Follow the chosen tool’s documentation for verifying stream copy.

Keep the source until the output has passed review and the retention plan explicitly permits deletion. “Conversion completed” is a software status, not an archival verdict. The progress bar saw many things, but it did not watch your subtitles at minute forty-seven.

## Frequently asked questions

**What is the difference between remuxing and transcoding?**

Remuxing copies existing compressed streams into a different compatible container without decoding and re-encoding the picture. Transcoding decodes media and creates a new encoded stream, usually because codec, resolution, frame rate, color, captions, or another property must change. Remuxing can preserve video samples exactly, but container-specific metadata and unsupported stream types still require careful verification.

**Does changing MP4 to MOV reduce quality?**

Not necessarily. If the contained video and audio streams are compatible and copied unchanged, moving them between supported containers can avoid another image encode. If the software transcodes the streams, quality and size can change. Inspect the codecs and export mode rather than judging by extensions alone, then verify stream details and playback in the intended application.

**Can a higher bitrate restore lost video quality?**

No. A higher output bitrate can reduce additional compression damage during a new encode, but it cannot reconstruct source detail already discarded. Upscaling and filtering may change appearance without recovering the original information. Preserve the best available source, avoid unnecessary generations, and evaluate a representative test clip rather than assuming a larger file contains newly recovered detail.

**Is lossless video conversion always practical?**

No. Mathematically lossless codecs or settings can produce large files and may not meet the compatibility, bandwidth, or processing limits of the destination. A stream-copy remux is efficient when streams are already compatible; otherwise an archival master and a separate delivery encode may be more practical. Choose from documented requirements rather than treating one file as every workflow’s ideal.

**How do I verify a converted video?**

Compare source and output stream inventories, duration, synchronization, seeking, subtitles, chapters, audio channels, orientation, metadata, and color signaling. Play representative difficult sections on the actual target devices. When streams were meant to be copied exactly, use the tool’s documented stream-level verification method. Keep the original until authorized review and retention rules allow any deletion.


---

# Pixel Aspect Ratio vs Display Aspect Ratio Explained

> Pixel aspect ratio describes the shape used to display one pixel; display aspect ratio describes the width-to-height shape of the whole picture. For a full, unrotated raster, display aspect ratio equals stored width divided by stored height, multiplied by pixel aspect ratio. Do not infer the intended shape from dimensions alone. Work only with authorized media, preserve originals, and check the source interpretation and destination documentation before changing settings or accepting an output.

Source: https://videos-converter.net/pixel-aspect-ratio-vs-display-aspect-ratio/  
Publisher: Frame Relay Notes  
Published: 2026-09-08  
Updated: 2026-09-08

## What is pixel aspect ratio versus display aspect ratio?

Pixel aspect ratio describes the shape used to display one pixel; display aspect ratio describes the width-to-height shape of the whole picture. For a full, unrotated raster, display aspect ratio equals stored width divided by stored height, multiplied by pixel aspect ratio. Do not infer the intended shape from dimensions alone. Work only with authorized media, preserve originals, and check the source interpretation and destination documentation before changing settings or accepting an output.

This is a desk-researched interpretation guide with original arithmetic examples. It is not a report of encoding tests, and the sample numbers are not repair settings for an unidentified file.

If a converted image looks too wide or too narrow, begin by separating three questions: how many samples are stored, what shape each represents, and what shape the picture is meant to have.

## Which ratio describes which part of the image?

[Adobe's current Premiere documentation](https://helpx.adobe.com/premiere/desktop/edit-projects/intro-to-editing/aspect-ratios.html) distinguishes the frame's aspect ratio from the aspect ratio of its pixels. It also explains that a misinterpreted pixel ratio can cause an incorrect frame shape.

| Property | What it describes | Illustrative notation |
|---|---|---|
| Stored dimensions | Columns and rows in the raster | 720 × 576 |
| Pixel aspect ratio, PAR | Display width relative to height of one pixel | 64:45 |
| Display aspect ratio, DAR | Displayed picture width relative to height | 16:9 |

FFmpeg uses **sample aspect ratio**, abbreviated SAR, for the pixel-ratio concept. In this article, SAR means that, not a separate abbreviation for storage aspect ratio. Read the tool's definition rather than assuming every source uses the same acronym.

Square pixels have a ratio of 1:1. With square pixels, dividing stored width by stored height gives the full raster's display ratio directly. With non-square pixels, it does not.

Our [format basics collection](/format-basics/) covers the surrounding container and codec vocabulary. File extension, compression format, and picture geometry answer different questions.

## How do you calculate the displayed shape?

The [FFmpeg setdar and setsar documentation](https://ffmpeg.org/ffmpeg-filters.html#setdar_002c-setsar) gives this relationship:

> DAR = stored width ÷ stored height × SAR

Use the exact fraction where available. A colon in 16:9 means the same ratio as the fraction 16/9; it is not a pixel count.

The examples below assume an unrotated picture using the complete stored raster. They deliberately exclude crop regions, clean-aperture interpretation, and other transformations. They are mathematical illustrations, not a rule assigning one pixel ratio to every historical video standard.

For a square-pixel example:

> 1920 ÷ 1080 × 1 = 16/9

For a second raster, begin with its stored ratio:

> 720 ÷ 576 = 5/4

Now compare three possible pixel-ratio interpretations:

| Stored raster | Pixel ratio | Calculation | Resulting DAR |
|---|---|---|---|
| 720 × 576 | 1:1 | 5/4 × 1 | 5:4 |
| 720 × 576 | 16:15 | 5/4 × 16/15 = 80/60 | 4:3 |
| 720 × 576 | 64:45 | 5/4 × 64/45 = 320/180 | 16:9 |

The stored dimensions did not change between rows. The display interpretation did. That is why “the file is 720 × 576” is an incomplete answer to “what shape should it be?”

Do not infer a camera, broadcast standard, disc specification, or intended composition from this table. Use the source's actual documentation and metadata. A real format may define an active picture differently from this deliberately simple full-raster model.

## What happens if you force square pixels without resizing?

Consider only the fictional 720 × 576, 64:45 example above. Its intended full-raster display ratio is 16:9. If you keep the stored dimensions but replace the pixel ratio with 1:1, the formula gives 5:4 instead.

That change does not preserve the original geometry.

To express the same 16:9 rectangle with square pixels while retaining a height of 576, the mathematical width is:

> 576 × 16/9 = 1024

So **1024 × 576 with 1:1 pixels** and **720 × 576 with 64:45 pixels** describe the same full-raster display shape in this example. They do not describe identical stored images or promise identical quality.

The wider stored raster would require a resizing decision, not merely a new interpretation of the existing sample count. The example establishes geometry only; it does not choose a resampling filter, codec, bitrate, or delivery format.

## Why are interpretation, scaling, and cropping different?

Keep these decisions separate:

- **Interpretation:** what shape the existing samples represent.
- **Scaling:** what stored dimensions the output will use.
- **Cropping:** which part of the picture remains.
- **Placement:** how that picture fits within the destination frame.

FFmpeg states that setdar changes the sample aspect ratio without changing the frame's pixel dimensions. Later filters can change the resulting ratio again. This does not make every workflow using a ratio control a lossless metadata edit: the complete export process still matters.

Our guide to [conversion without quality loss](/convert-video-without-quality-loss/) explains the broader distinction between copying compatible streams and generating a new encode.

Cropping deserves its own review. [HandBrake's current resizing guide](https://handbrake.fr/docs/en/latest/advanced/resizing-video.html) describes automatic black-bar detection as an estimate that can be wrong and provides a preview route. Do not accept a crop merely because it was chosen automatically. Examine relevant edges, text, and changes of framing across the recording.

No combination of pleasing proportions and fewer bars establishes that every required part of the image survived.

## What should you inspect before choosing an output?

Make an original geometry record for each source rather than applying one remembered setting to a batch:

| Record field | What to capture |
|---|---|
| Source identity | A filename or internal identifier, not a public upload |
| Tool context | Inspector or editor name and installed version |
| Stored dimensions | Reported width and height |
| Pixel ratio | Exact reported fraction, or explicitly unknown |
| Intended display shape | Supporting source or delivery documentation |
| Other interpretation | Rotation, crop, or active-image information needing review |
| Destination | Required frame shape, pixel convention, and receiving application |

A media inspector can help collect information. The [ffprobe documentation](https://ffmpeg.org/ffprobe.html) describes reporting container and stream information in readable or machine-readable forms. An inspector report is evidence about the file, not independent proof that every recorded value is correct.

If the pixel ratio is missing or conflicting, write “unknown” in your working record. Do not silently replace it with square pixels. Seek the export specification, capture documentation, or help from the source creator or a qualified post-production specialist.

Use trusted, current tools with media you are authorized to process. Do not upload private footage merely to get a convenient property readout.

## How do you verify a separate delivery copy?

Our suggested review order is source interpretation first, destination requirements second, and output inspection third. Keep the original and backup unchanged.

Record one proposed change and its reason. For example, “destination requires square pixels; preserve documented display shape” is useful. “Make it look normal” does not identify what changed or why.

Compare the output at the intended viewing size and in the receiving workflow. Check the image boundaries as well as proportions. Review captions, graphics, and any shots whose composition makes a crop important. Also retain the usual duration, audio, synchronization, and stream checks; geometry is only one part of acceptance.

A preview that fits your editor's window is not proof that the exported file meets the destination's requirements. Follow the documentation for the installed application and inspect the actual separate output before approving it. The [compression workflows collection](/compression-workflows/) keeps this verification distinct from choosing a smaller file.

There is no need to delete a source as part of understanding its aspect ratio. Keep any later retention decision separate from this inspection task.

## Frequently asked questions

### Does 720 × 576 always mean 4:3 video?

No. Those numbers describe the stored raster. In this guide's full-raster examples, 720 × 576 with pixel ratio 16:15 displays at 4:3, while pixel ratio 64:45 gives 16:9. Real format and active-image conventions still matter. Identify the actual source instead of assigning a ratio from the dimensions alone.

### Does changing display aspect ratio add pixels?

Not necessarily. FFmpeg documents that its setdar filter changes sample aspect ratio rather than the frame's pixel dimensions. That statement concerns the filter, not the entire export path or every application. Scaling to a different stored width or height is a different operation. Preserve the source and verify what the selected workflow actually writes.

### Should every video use square pixels?

No universal setting fits every source and destination. Square pixels simplify the relationship between stored dimensions and display shape, but a valid non-square-pixel source should not be relabeled blindly. Obtain the receiving specification, establish the source's intended geometry, and decide whether the delivery requires an actual square-pixel resample.

### Can black bars prove that an aspect ratio is wrong?

No. Bars may be part of the stored image or added while fitting a correctly shaped picture into a differently shaped viewing area. Inspect the source and playback settings before cropping. Preserve captions and relevant image edges; removing visible bars without understanding their origin can change the composition or discard content.

### What if two players show the same file differently?

Record both applications and their display settings, then compare the source's dimensions, pixel ratio, and relevant display interpretation. Different appearance is a reason to investigate, not proof that one player is automatically correct. Use the documented source and delivery requirements; keep the original and verify any separate output in the actual receiving workflow.

## Sources

Primary documentation opened and read September 8, 2026:

- [Adobe Premiere: aspect ratios, updated April 8, 2026](https://helpx.adobe.com/premiere/desktop/edit-projects/intro-to-editing/aspect-ratios.html).
- [FFmpeg filters: setdar and setsar](https://ffmpeg.org/ffmpeg-filters.html#setdar_002c-setsar).
- [HandBrake: resizing video](https://handbrake.fr/docs/en/latest/advanced/resizing-video.html).
- [FFmpeg: ffprobe documentation](https://ffmpeg.org/ffprobe.html).

## Frequently asked questions

**Does 720 × 576 always mean 4:3 video?**

No. Those numbers describe the stored raster. In this guide's full-raster examples, 720 × 576 with pixel ratio 16:15 displays at 4:3, while pixel ratio 64:45 gives 16:9. Real format and active-image conventions still matter. Identify the actual source instead of assigning a ratio from the dimensions alone.

**Does changing display aspect ratio add pixels?**

Not necessarily. FFmpeg documents that its setdar filter changes sample aspect ratio rather than the frame's pixel dimensions. That statement concerns the filter, not the entire export path or every application. Scaling to a different stored width or height is a different operation. Preserve the source and verify what the selected workflow actually writes.

**Should every video use square pixels?**

No universal setting fits every source and destination. Square pixels simplify the relationship between stored dimensions and display shape, but a valid non-square-pixel source should not be relabeled blindly. Obtain the receiving specification, establish the source's intended geometry, and decide whether the delivery requires an actual square-pixel resample.

**Can black bars prove that an aspect ratio is wrong?**

No. Bars may be part of the stored image or added while fitting a correctly shaped picture into a differently shaped viewing area. Inspect the source and playback settings before cropping. Preserve captions and relevant image edges; removing visible bars without understanding their origin can change the composition or discard content.

**What if two players show the same file differently?**

Record both applications and their display settings, then compare the source's dimensions, pixel ratio, and relevant display interpretation. Different appearance is a reason to investigate, not proof that one player is automatically correct. Use the documented source and delivery requirements; keep the original and verify any separate output in the actual receiving workflow.


---

# How to Reduce Video File Size: A Decision Guide

> Reduce video file size by defining the delivery requirements, preserving the original, and testing a representative clip. Remove only authorized unneeded duration or streams, lower resolution only when the target does not need the pixels, keep frame rate unless compatibility or motion goals justify a change, and select codec, quality, preset, and audio settings together. Estimate size from total average bitrate times duration divided by eight, then verify the actual output on target devices.

Source: https://videos-converter.net/reduce-video-file-size/  
Publisher: Frame Relay Notes  
Published: 2026-07-19  
Updated: 2026-08-26

## Define the delivery target before changing settings

To reduce video file size, first decide the required duration, resolution, frame rate, codec compatibility, visual quality, audio, captions, and target device. Then encode a representative short clip while changing one main variable at a time. File size falls when average bitrate falls, duration shortens, or streams are removed; every choice needs a reason because the encoder cannot know which detail matters to your audience.

The workflows in [compression workflows](/compression-workflows/) keep the source untouched and the delivery goal visible.

## Estimate size from bitrate and duration

For a rough estimate:

> file size in bytes ≈ total bitrate in bits per second × duration in seconds ÷ 8

If total average bitrate is 5,000,000 bits per second and duration is 600 seconds:

> 5,000,000 × 600 ÷ 8 = 375,000,000 bytes

That is 375 MB using decimal megabytes, before small container overhead and variation. Total bitrate includes video, audio, and other relevant streams. Variable-bitrate encodes target an average or quality behavior, so final size may differ from a simple prediction unless the method tightly controls bitrate.

State whether a tool reports decimal MB or binary MiB. The file has not grown merely because two unit systems are arguing over its wardrobe.

## Remove what the delivery does not need

Trim accidental lead-in, dead time, duplicate endings, or unneeded takes when editorially authorized. Remove only streams the destination does not require, such as redundant audio languages or attachments, after confirming retention and accessibility needs.

Do not discard captions, descriptive audio, chapters, or metadata merely because their size looks nonzero. Accessibility and workflow value can outweigh a small saving. Preserve a complete master separately.

## Match resolution to real viewing needs

Reducing pixel dimensions can save substantial data when the destination displays a smaller frame. It also permanently removes spatial detail from that output. Use the platform or playback specification and test fine text, screen recordings, faces, and detailed motion.

Do not upscale first and compress afterward. Extra pixels created by scaling do not restore source detail, and they may ask the encoder to spend bits describing interpolation.

## Keep frame rate unless there is a reason to change it

Reducing frame rate can lower data demand, but it changes motion portrayal and may create judder or timing complications. Preserve the source timing when compatibility allows. For variable-frame-rate material, verify whether the editor or destination requires conversion and test audio sync across the full duration.

Never guess that every file labeled “30 fps” contains an identical timing structure. Inspect the stream.

## Choose codec and quality together

Newer or more efficient codecs may deliver similar subjective quality at a lower bitrate than an older alternative, but compatibility, encoding time, hardware support, licensing, editing performance, and decoder power differ. Verify the target specification and the installed encoder’s current documentation.

Within one codec, a slower preset may improve compression efficiency without changing the intended quality target, but it increases encoding time. A quality setting can produce different file sizes across easy and difficult content. Noise, grain, water, foliage, and rapid motion are expensive dinner guests.

## Treat audio as its own decision

Inspect channel layout, sample rate, codec, language tracks, and target playback. Speech may tolerate a different audio bitrate from complex music, but do not collapse stereo or surround channels without an authorized delivery requirement and a listening test.

Audio can dominate only in unusually low-bitrate video or multi-track files, so reducing it blindly may hurt intelligibility while barely changing the total.

The [quality-loss guide](/convert-video-without-quality-loss/) explains why a remux does not reduce an unchanged stream’s size; [format basics](/format-basics/) separates that container change from compression.

## Compare a short clip before encoding everything

Test source and output at normal size and on target devices. Inspect motion, gradients, dark scenes, fine lines, text, faces, audio sync, captions, and seeking. Record settings and resulting size so comparisons remain reproducible.

Keep the original and write output to a new path. When the sample passes, encode the full file and repeat verification at several points. Delete nothing until review and retention policy agree. A smaller file that lost the one subtitle track someone needed is not optimized; it is merely efficient at causing a second meeting.

## Frequently asked questions

**What determines a video file’s size?**

Duration and the combined amount of data stored for video, audio, subtitles, metadata, and container overhead determine size. For a rough bitrate-controlled estimate, multiply total average bits per second by duration in seconds and divide by eight for bytes. Variable-quality and variable-bitrate outputs can differ because content complexity changes how much data the encoder uses.

**Does lowering video resolution reduce file size?**

It can, because fewer pixels may require less data at a comparable visual target, but the result depends on codec and settings. Lower resolution permanently removes spatial detail from that output. Match the frame to the real delivery requirement and test fine text, faces, detailed texture, and target display size. Preserve the original rather than replacing it.

**Should I lower frame rate to compress video?**

Only when the delivery requirement and motion test justify it. Lower frame rate changes motion portrayal and can introduce judder or timing problems. Preserve source timing when possible, inspect variable-frame-rate material, and test synchronization throughout the file. Reducing bitrate or choosing a more efficient supported codec may be preferable when motion cadence is important.

**Why did my compressed video become larger?**

The output may use a higher bitrate, less efficient codec or preset, larger resolution, different frame rate, lossless mode, extra audio tracks, or container overhead. Quality-based encodes also spend more data on complex, noisy, or fast-moving scenes. Compare complete stream information and recorded settings rather than assuming a file labeled ‘compressed’ must be smaller.

**How can I compress video without overwriting the original?**

Write the output to a new filename or separate directory, confirm adequate storage, and preserve a backup of the source. Test a short clip first, then verify the full output’s duration, streams, sync, captions, metadata, and playback before any cleanup. Use explicit paths and review the tool’s overwrite behavior; never let a convenience default decide the fate of the only master.


---

# Variable vs Constant Frame Rate: Which to Use

> Constant frame rate (CFR) gives every frame the same display interval, while variable frame rate (VFR) allows intervals to change. Neither is inherently better. Preserve VFR when the complete playback or editing workflow supports the source timestamps. Convert to a documented CFR when an editor, device, platform, or delivery specification requires it. Because CFR conversion may drop, duplicate, blend, or synthesize frames, preserve the original and test motion, duration, audio sync, captions, and target-device playback.

Source: https://videos-converter.net/variable-vs-constant-frame-rate/  
Publisher: Frame Relay Notes  
Published: 2026-09-05  
Updated: 2026-09-05

## The difference is in frame timing

Constant frame rate (CFR) video presents frames at evenly spaced intervals. Variable frame rate (VFR) video allows those intervals to vary. Neither mode is automatically higher quality. Preserve the source timing when the destination accepts it; convert to a documented constant rate when an editor, platform, device, or delivery specification requires CFR.

The practical question is not whether one acronym sounds more professional. It is whether every part of the intended workflow reads and writes the timestamps correctly.

## Frame rate is more than one summary number

A media inspector may report a frame rate such as 30 fps, but that display can be a nominal or average value. It does not by itself prove that every frame remains on screen for exactly 1/30 second. To distinguish CFR from VFR, inspect the stream's timestamps or frame durations with a current media-analysis tool.

Apple's [QuickTime file-format documentation](https://developer.apple.com/documentation/quicktime-file-format/video_variable_frame_rate_indication) defines constant rate as video whose samples have the same display duration and variable rate as video in which at least one sample duration differs. That is a useful definition because it focuses on timing, not the filename extension.

Container, codec, and frame-rate mode are separate properties. MP4 and Matroska files can carry timed video streams; H.264 and HEVC describe video compression; CFR or VFR describes how frames are scheduled for presentation. Renaming an extension changes none of those facts.

## When should you keep variable frame rate?

Keep VFR when it is valid in the source and the complete destination workflow supports it. Screen recordings, phones, and capture tools may vary timing rather than create frames at a rigid cadence. Preserving those timestamps can avoid an unnecessary frame-rate conversion.

This is especially sensible for direct playback or delivery when the player and platform explicitly accept the existing stream. It may also allow remuxing if the destination container supports every stream, as explained in our guide to [converting video without quality loss](/convert-video-without-quality-loss/).

Do not assume that selecting a familiar extension makes VFR safe for every editor. Test the actual file in the actual ingest, edit, export, and playback path. A file that plays correctly in a desktop player has passed one test, not the workflow.

## When should you convert to constant frame rate?

Convert to CFR when the receiving specification requires a fixed rate, or when a tested editor or device cannot handle the source timing reliably. Some non-linear editing workflows, older devices, broadcast processes, and frame-indexed analysis tools expect evenly timed frames.

The [HandBrake frame-rate documentation](https://handbrake.fr/docs/en/latest/technical/frame-rates.html) describes CFR as making the output exactly one frame rate throughout and identifies import into a non-linear editor as a special reason to use it. The same documentation distinguishes peak frame rate (PFR), which limits the maximum while preserving source timing below that limit.

Choose the target rate from the destination requirement or timeline, not from habit. 23.976, 24, 25, 29.97, 30, 50, 59.94, and 60 are distinct rates. Treating 29.97 as an informal spelling of 30 can accumulate timing differences in long or tightly synchronized work.

## CFR conversion must change the frame sequence

Turning uneven frame timing into an even cadence is not a metadata-only repair. The converter must decide what picture occupies each output time. Depending on the tool and settings, that can mean dropping frames, duplicating frames, blending neighboring frames, or synthesizing intermediate frames.

FFmpeg's current [command-line documentation](https://ffmpeg.org/ffmpeg.html) states that setting an output rate during video encoding duplicates or drops frames to achieve that constant rate. Its per-stream `fps_mode` documentation likewise defines CFR as duplicating and dropping frames to reach the requested cadence. Read the documentation for the installed version because option behavior and defaults can change.

Dropping can remove a moment; duplication can create a hold; blending can create a double image; interpolation can invent motion that was not captured. None is universally correct. Use the least disruptive method that meets the delivery requirement, then inspect difficult motion at normal speed and frame by frame.

## A new frame rate usually means a new video encode

Preserving timestamps during a compatible remux can avoid re-encoding the picture. Conforming VFR to CFR usually changes frame timing or the frame sequence and therefore requires a video encode. That introduces the same codec, quality, bitrate, color, and generation-loss decisions as any other transcode.

Do not overwrite the source. Write a short representative test to a new path, include fast motion and long continuous audio, and compare it with the original. If file size matters, frame-rate conversion is only one variable; our [video file-size guide](/reduce-video-file-size/) explains how duration, total bitrate, resolution, codec, and audio contribute.

## Test sync across the whole duration

Audio drift is not proof that VFR itself is defective. It can come from missing or rewritten timestamps, a recorder's clock, an importer's assumptions, an incorrect forced input rate, dropped packets, or a conversion setting. Diagnose before converting.

Check at the beginning, middle, and end of a long file. Look for a fixed offset, which may point to a start-time problem, versus drift that grows over time, which suggests a rate or clock mismatch. Also test seeking, cuts, captions, transitions, and export because correct preview playback does not guarantee a correct rendered file.

Record the source properties, tool version, preset, chosen rate, frame-rate mode, and output results. A reproducible log is far more useful than a filename ending in “fixed-final-3.”

## Use a simple decision sequence

First, inspect rather than infer: identify the container, codec, timestamps, reported average and nominal rates, audio timing, and duration. Second, obtain the destination's current requirements. Third, preserve VFR if the full path supports it; otherwise make a CFR test at the required rate with an explicit conversion method. Finally, compare motion, duration, synchronization, captions, and playback on the target device.

CFR is a compatibility choice, not a quality badge. VFR is a timing model, not a flaw. The correct output is the one whose timing survives the workflow while the untouched source remains available if another destination asks a different question.

## Frequently asked questions

**Is variable frame rate lower quality than constant frame rate?**

No. VFR and CFR describe frame timing, not picture quality. Quality depends on the captured images and any compression or processing. Converting VFR to CFR may change the frame sequence and require a new encode, which can affect motion and image quality. Preserve source timing unless the destination has a reason to require CFR.

**Why can a VFR video show 30 fps in an inspector?**

The displayed number may be an average or nominal rate. A 30 fps summary does not prove that every frame lasts exactly 1/30 second. Inspect frame timestamps or sample durations with a current media-analysis tool, and distinguish the reported average rate from a genuinely constant cadence.

**Should I convert phone video to CFR before editing?**

Only if the editor, project, or delivery path requires it or a representative test exposes a timing problem. Many workflows accept VFR; others work more reliably with CFR. Check current application documentation, preserve the source, convert a short sample at the required timeline rate, and verify sync and motion before processing every clip.

**Does converting VFR to CFR fix audio drift?**

Not automatically. Drift can result from bad timestamps, clock mismatch, dropped packets, import assumptions, or a forced rate as well as unsupported VFR. Determine whether sync has a fixed offset or worsens over time, inspect timestamps, and test the beginning, middle, and end before choosing a conversion.

**Can VFR be changed to CFR without re-encoding?**

Usually not when the frame timing or sequence must be conformed. Creating an even cadence may require frames to be dropped, duplicated, blended, or synthesized, followed by a new video encode. A remux can preserve compatible compressed streams and their timing, but it does not perform a genuine VFR-to-CFR conversion.


---