What would prove a video was preserved?
Choose evidence that supports the specific claim you are testing.
3 min read · Updated November 3, 2026For technical readers who want to distinguish an unchanged media payload from a similar-looking output.
Define what “the same” means
Two files can look similar while containing different encodes. They can also contain unchanged encoded samples inside different containers. State which of those properties you intend to test before choosing a comparison.
For example, equal width, height and frame rate confirm some basic properties. They do not rule out another encode with the same settings. A visual comparison can reveal a difference, but failing to see one does not prove byte identity.
| Claim | Useful test | Insufficient on its own |
|---|---|---|
| Same dimensions | Read width and height from each identified stream. | The filename or export preset. |
| Same appearance | Compare matching frames under controlled viewing conditions. | A single compressed screenshot. |
| Preserved encoded media | Compare encoded samples, configuration and timing. | Equal resolution and average bitrate. |
| Identical complete file | Compare a cryptographic whole-file hash. | Matching video samples while metadata differs. |
Why the whole-file hash can change
A file hash includes the container index, metadata, padding and media data. Fulres deliberately changes supported container structure, so a different complete-file hash is expected. That difference alone cannot establish whether the encoded tracks changed.
Conversely, matching picture samples without checking track identity, codec configuration and timing is an incomplete test of playable equivalence. Keep video and audio comparisons separate, and include every relevant track.
Keep an unambiguous comparison pair
Record source and output identities before running an inspection. Do not compare against an older editor export or a platform rendition that merely shares the same name. Keep the source read-only and write any inspection reports to separate files.
When inspecting remote media, redirects and fallbacks matter. If the requested stream fails and another URL succeeds, the successful result belongs to the other stream. It must not be used as verification of the original request.
- Source and output are clearly identified.
- All relevant audio/video tracks are included.
- Codec configuration and timing are considered alongside payloads.
- Fallback media cannot silently replace the test subject.
Optional: inspect packet evidence with FFprobe
For a technical investigation on files you already possess, FFprobe can list packet timestamps and hashes of packet data without rewriting the input. Run the command for each file and compare corresponding streams carefully. Container packetization can differ, so a simple text diff of reports is not a complete preservation verifier.
This is a diagnostic starting point, not an alternate export feature in Fulres. The app does not offer prepared-file downloads or a public-post hash comparison against your local original.
ffprobe -v error -show_streams -show_packets -show_data_hash sha256 -of json "source.mp4"What Fulres confirms today
The preparation engine verifies its output before marking it ready. Its supported processing paths check media preservation and timing while allowing the planned container changes. A failed verification must remain a failure, even if a file was produced.
The public checker has a different purpose: it reports available post and stream evidence. It does not prove the published media is identical to your selected source. Establishing that stronger claim would require the relevant files and a reproducible comparison across the publication boundary.