HD signal inspection
HD is a label, not a complete output specification. Before a source is accepted or resized, that label needs to resolve to an actual coded raster, scan or frame behavior, aspect treatment and receiver result.
This guide identifies and validates one named HD path. It does not choose among every possible resolution or promise that a larger raster will improve a weak source.
Resolve the HD label before using it
The first clue comes from the system that supplied the label: a camera menu, encoder preset, file property, platform UI or display specification. Capture the literal label and the output it claims to describe, then inspect the media or signal itself. Marketing names and display-panel dimensions can resemble production formats without establishing what was encoded.
An HD label must be resolved to the named BT.709 system parameters, including raster and scanning/frame characteristics, before it can be used as an output acceptance value. The reference standard and measured result belong in separate fields. One defines parameter families; the probe or signal monitor shows what this output carries.
Record raster, scan and frame rate separately
The record separates width and height, progressive or interlaced behavior, frame or field rate and any pixel-aspect or display-aspect signaling reported by the approved inspection tool. Raw output and tool version stay attached. Compressing these properties into one friendly string hides the fact that two outputs with the same raster can behave differently in motion.
A source with motion and fine detail makes those differences visible; a static frame can hide field-order or deinterlacing problems. If the workflow converts interlaced input, the deinterlacer and resulting cadence need their own fields. A missing property remains unknown until the actual receiver is inspected, rather than being filled from a preset name.
| Property | Source value | Output value | Evidence |
|---|---|---|---|
| Raster | Measured width × height | Measured width × height | Raw inspection |
| Scan/cadence | Observed and signaled | Observed and signaled | Motion sample |
| Aspect | Sample/display data | Player presentation | Frame capture |
Distinguish coded video from display size
A browser can draw a video at a CSS size that differs from the coded raster. A laptop panel can contain a different number of pixels from the stream. An editor can show a proxy. Record these layers separately: coded media, application canvas, rendered viewport and physical display.
Measure the player rectangle and note browser zoom or operating-system scaling when validating a web surface. A clean fit does not prove pixel-for-pixel presentation, and a soft enlarged preview does not prove the encoder emitted a smaller raster. The acceptance record should identify where scaling occurs and whether that scaling is intentional.
- Coded raster
- The width and height carried by the video stream.
- Canvas
- The application or compositor working area.
- Viewport
- The rectangle where the receiver draws the image.
- Panel
- The physical display and its own scaling behavior.
Trace scaling and aspect-ratio changes
The trace follows the source through switcher, compositor, encoder, transcoder, packager and player. At each stage, it records preserve, resize, crop, pad or aspect reinterpretation. Comparing the same frame after every explicit transform keeps the change visible, especially when the fixture includes text, circles and a framing marker.
If OBS is part of the path, Set the OBS canvas and output deliberately, then Inspect the configured OBS output. The base canvas and encoded output should not be assumed to match. A settings view and an inspected recording or received stream from the same run provide the evidence.
Bitrate comes later. Once the raster and cadence are fixed and validated, Plan bitrate after the raster is fixed. Raising bitrate cannot reverse a crop or restore source detail removed by an earlier resize.
Inspect the delivered output
The delivered asset or live output needs a decode independent of the production preview. Width, height, scan/cadence and aspect metadata come first, followed by the motion-and-detail fixture on the target receiver. One frame at a known timestamp from the source, post-transform output and final surface makes the comparison concrete.
The review looks for stretched geometry, unintended bars, crop, soft scaling, line twitter, motion artifacts and unreadable overlays. Each observation should be described before it is assigned to resolution. Comparing decoded output with the receiver screenshot separates encoded changes from display scaling.
- Verify picture and audio continuity for the whole fixture.
- Confirm overlays remain inside the intended frame.
- Check a narrow and a large presentation surface.
- Record the receiver version and selected quality.
- Repeat after a reconnect or reload for a live path.
Approve or reject the named HD path
Approval joins source and output probe records with one frame grab, then names the raster, scan/frame rate, aspect handling, scaling step and device playback result. Exact checksums or session identifiers, tool versions and the accepting person make the result repeatable.
The failure threshold deserves the same care as the pass. A path that preserves raster but introduces stretch, crop, cadence conversion or an unreadable overlay is not approved. Keeping the rejection frame and transform settings lets the correction be judged against the same evidence rather than a different scene.
Only the named path is approved. A 1080 output on one browser says nothing about a different cadence, mobile decoder or 720 fallback. Missing source detail should be recorded as a limitation instead of turned into an “HD quality” claim. When a transform is intentional, its reason and the untouched master remain visible.
