Measure the downloaded file and compare it with a written delivery contract. A request for ten seconds in 16:9 does not prove that the result has those properties. Check duration, picture geometry, frame rate, and sound separately, then decide which differences are acceptable and which require a revised deliverable.
Separate requested values from observed values
Write the requested duration, aspect ratio, minimum dimensions, frame-rate requirement, and sound requirement before opening the media report. Include tolerances where the project allows them; do not invent a universal acceptable deviation after seeing the output.
As a measurement example, Imagild's documented single-run H3 test produced a file reported at 10.125 seconds, 1376 by 768 pixels, 24 fps, and 243 decoded frames. These observations describe one file, not a model benchmark or a guarantee about the website workflow.
For a ten-second, 16:9 brief, compare those observations like this:
| Property | Observation | Decision still needed |
|---|---|---|
| Duration | 10.125 seconds | Is 0.125 seconds extra allowed? |
| Coded dimensions | 1376 × 768 | Does the actual display geometry meet the brief? |
| Frame rate | 24 fps | Was that rate specified or acceptable? |
| Decoded frames | 243 | Does playback agree with the timing report? |
| Sound | Content not reviewed in the record | Listen before claiming acceptance |
Inspect the actual streams and geometry
Use media properties in an editor or, if already available, ffprobe. Its official documentation describes stream, container, and frame-count reports. An illustrative local-file command is:
ffprobe -v error -count_frames -show_streams -show_format -of json delivery.mp4
Also check pixel aspect and rotation. With square pixels and no display override, 1376:768 reduces to 43:24, not exact 16:9. A “landscape” label cannot settle that distinction.
Do not call a 768-pixel-high result 720p. If the contract requires a specific delivery size, write that size explicitly. Resizing creates a new deliverable and needs its own framing and playback check.
Verify duration without confusing the clocks
For a constant 24 fps sequence, 243 frames correspond to 10.125 seconds. Treat that calculation as a consistency check, not a replacement for stream timestamps or complete decoding.
Video and audio can have different endpoints. Inspect the intended final action, the last visible frame, and any sound tail. A container duration alone may not explain which track extends the file.
If ten seconds is a strict boundary, plan an exact revised ending. Trimming the extra interval is only acceptable if it preserves the required action and does not cut off a spoken word. Otherwise the creative ending needs adjustment.
Review sound as content, not merely a stream
An audio stream tells you that audio data exists. It does not prove correct words, appropriate music, usable volume, or synchronization.
Listen through the actual export and record those checks. The cited test explicitly reports that audio content was not reviewed, so its metadata cannot support a sound-quality pass. A silent delivery can pass only when silence was the intended requirement.
Choose strict acceptance or an approved adaptation
For a strict contract, mark every required field passed, failed, or unreviewed. For an adaptable edit, agree the crop, trim, or other change before calling the result accepted.
Keep native motion timing unless a different delivery rate is necessary. YouTube recommends retaining the recorded frame rate; changing a number alone does not improve movement.
Recheck the revised file and retain its measurements with the delivery notes. Technical conformity and creative correctness remain separate checks: exact duration and ratio do not establish accurate choreography, identity, or a convincing story.