CTV Ad Looks Blurry on the TV? Compare the Source File with the Delivered Version

Follow the file, not the filename

A useful CTV quality investigation follows this chain:

Source master → platform transcodes or VAST media files → player or stitching-system selection → app/device scaling and processing → television panel

A problem can enter at any arrow. The filename BRAND_CTV_FINAL_1080P.mp4 proves only what somebody named an upload. It does not prove which bytes were encoded downstream, which rendition was eligible, which URL the player chose, or what the television received.

VAST makes this separation explicit. The IAB Tech Lab’s VAST 4.3 specification describes high-, medium-, and low-quality ready-to-serve media files, plus a raw high-quality mezzanine that publishers or ad-stitching systems can transcode for their environments. It also says a mezzanine should not be used for direct playback. (IAB Tech Lab: VAST 4.3 PDF) The later CTV addendum explains why this matters on large, high-resolution screens: a response may need to distinguish high-resolution creative from files intended for ordinary web video. (IAB Tech Lab: VAST CTV Addendum 2024 PDF)

The player may then choose among the offered files. Google’s IMA documentation says a VAST response can contain multiple media files with different bitrates and formats and that the SDK chooses an appropriate bitrate based on current network conditions unless the integration supplies other rendering preferences. (Google IMA: Specify bitrate and media format)

So the first question is not “Was the upload 1080p?” It is “What file did this playback use?”

A controlled source-versus-delivered comparison

To make the method concrete, this package includes an original eight-second fictional ad for Lumen & Field. It is deliberately designed with large type, small recipe copy, thin diagonal lines, and moving textured areas. Those details reveal different failure modes better than a flat color card.

The source and two derived candidates contain the same creative and duration:

All three are H.264 MP4 files at a constant 30 frames per second and run for 8.000 seconds. They are controlled teaching encodes, not files retrieved from a campaign or publisher.

At 00:04.000, the 640×360 candidate visibly softens the small shopping-list text and merges some of the thin line detail. That is not mysterious “TV blur.” It is a known lower-resolution file being displayed much larger than its native frame.

The full-dimension control teaches a different lesson. It still reports 1920×1080, yet it contains far fewer bits than the master. Pixel dimensions describe the frame grid; they do not describe how faithfully motion, gradients, texture, edges, or small type survived compression. “It is 1080p” is therefore necessary evidence in some workflows, but never sufficient evidence of source-equivalent quality.

For a reproducible review, open the controlled synchronized player. It exposes each video’s intrinsic dimensions and selected filename, keeps both files on one timecode, offers one-frame stepping, and switches the delivered side between the 360p and low-bitrate 1080p candidates. The test record documents what was and was not tested.

We also ran whole-sequence SSIM and PSNR comparisons. After scaling the 360p file to 1920×1080 with FFmpeg’s explicit bicubic filter, the source-versus-candidate result was SSIM 0.815810 and average PSNR 22.631343 dB. The 1080p low-bitrate control produced SSIM 0.984735 and average PSNR 39.026342 dB. These values describe this controlled sequence; they are not universal pass/fail thresholds and do not replace visual review on the intended playback path.

Retrieve the version that actually played

A useful escalation needs session evidence, not just the asset sitting in a shared drive. Build the record in this order.

1. Freeze and identify the source

Keep the exact approved master. Record its filename, byte size, duration, codec, dimensions, frame rate, bitrate, audio properties, and a SHA-256 hash. A hash prevents two different files named final.mp4 from being treated as the same source.

Also record the campaign, order, line item, placement, creative ID, and UniversalAdID where available. Without those identifiers, a platform team may investigate a different creative or serving path.

2. Capture what the serving system offered

Export or preserve the relevant serving-files list, VAST response, transcode table, or SSAI manifest through an authorized route. Record each candidate’s URL or file ID, native width and height, declared bitrate, MIME type, codec, and whether it was included or eligible for the placement.

This tells you what could play. It still does not prove what did play.

3. Capture the selected media for the affected play

Use the production player’s supported logs or API. In a Google IMA HTML5 integration, for example, the selected ad object can expose getMediaUrl() after the STARTED event. The same interface documents getVastMediaBitrate(), getVastMediaWidth(), and getVastMediaHeight() for the selected media as represented in the VAST response. (Google IMA Ad interface)

Other environments may provide a player debug overlay, device log, network trace, SSAI session manifest, segment identifier, or publisher-side decision log. Use the mechanism supported by that environment. Do not assume a generic browser preview reproduced a television app’s selection logic.

For intermittent blur, capture the affected session’s timestamp, time zone, app version, device model, OS or firmware, player or SDK version, connection type, request/session/impression ID, and the first useful timecode. “It happened on Roku yesterday” is not enough to correlate the play.

4. Retrieve and probe the delivered media, when authorized

A signed media URL or ad request can contain tokens, identifiers, and tracking endpoints. Retrieve it only through an approved channel, redact secrets before sharing, and do not publish a live request merely to prove that it exists.

Once you have the actual file, inspect it with a media probe rather than relying on the operating system’s thumbnail. FFmpeg describes ffprobe as a tool that gathers stream and container information in human- or machine-readable form. (FFmpeg: ffprobe documentation) One useful command is:

ffprobe -v error \
  -show_entries format=filename,duration,size,bit_rate:stream=index,codec_name,profile,codec_type,width,height,pix_fmt,avg_frame_rate,bit_rate,sample_rate,channels \
  -of json delivered.mp4

Save the output and hash the delivered file. Compare duration as well as picture properties; a mismatch can reveal that you retrieved the wrong cut.

5. Compare the same moment under the same display conditions

Pause the source and delivered file at the same timecode. Display them at the same physical or CSS size. Check small type, logos, faces, hair, fabric, foliage, smoke, gradients, fast motion, and dark areas. A source shown at native size beside a tiny rendition shown at one-third scale is not a fair comparison.

Then play through the sequence. A still frame can expose resolution loss, but motion-related blocking, mosquito noise, texture smearing, duplicate frames, and cadence problems require playback. Keep “observed in a frame,” “observed in motion,” and “reported by metadata” as separate statements.

A specification pass does not close the case

CTV requirements vary by publisher, supply source, and file role. Google’s current CTV guidance recommends at least one MP4 asset at 15 Mbps or higher and warns that additional renditions may be required by the publisher. The same page separately lists a 15–30 Mbps mezzanine range and lower ready-to-serve ranges, including 2.5–3.5 Mbps for a 1080p high-quality rendition. (Google: Connected TV creatives) Those figures make sense only when you keep a high-quality source/mezzanine distinct from a ready-to-serve encode.

Innovid’s published pre-roll specification asks for 1920×1080, constant frame rate, and CBR above 15 Mbps, while explicitly noting that the listed requirements are based on Hulu guidelines and can change. (Innovid: Understanding Innovid Video Specs) Amazon’s Streaming TV and Prime Video page provides another illustration of supply-specific variation: it lists a 15 Mbps minimum for Prime Video, 8 Mbps for several other streaming-TV sources, and 50 Mbps as the recommended bitrate for Prime Video campaigns. (Amazon Ads: Streaming TV and Prime Video ad specs)

There is no single magic bitrate that diagnoses every blurry CTV ad. The relevant questions are:

• Which specification applied to this publisher, placement, format, and date?
• Was the source or mezzanine compliant for its role?
• Which ready-to-serve rendition was present and eligible?
• Which media did the affected player actually select?
• Did that concrete file preserve the source well enough?

A platform acceptance badge or successful upload answers only part of that list.

Fix the fault domain you can prove

Once the comparison points to a stage, fix that stage instead of changing everything at once.

When the source is already soft

Return to the highest-quality timeline or render, not a previously compressed delivery file. Confirm that the art was created at sufficient resolution rather than enlarged from a smaller raster. Remove accidental interlacing, telecine, blended frames, or duplicate-frame conversions. Both Google’s CTV guidance and Innovid’s specification call out cadence and interlacing problems. (Google: Connected TV creatives; Innovid: Understanding Innovid Video Specs)

Creative design matters too. Fine legal text, hairline rules, dense texture, and low-contrast detail are less resilient across compression and living-room viewing distance. That does not excuse a bad transcode, but it does mean the master should be evaluated as television creative, not only at 100% zoom on a desk monitor.

When the delivered file is softer than the source

Inspect the generated transcodes or serving files. Confirm that the high-quality CTV rendition was successfully created, included for serving, accepted by the publisher, and associated with the correct placement. If the workflow supports a mezzanine, provide the true high-quality source rather than upscaling or rewrapping a low-bitrate file.

Do not create a “new master” by transcoding the poor delivered file again. Every additional lossy generation can preserve or compound the damage.

When the wrong rendition was selected

Verify the rendition metadata and selection rules. Check whether the high file had the expected MIME type, codec, dimensions, bitrate declaration, SSL URL, and publisher eligibility. In an integration that exposes bitrate preferences, treat those settings as player-specific controls—not as a universal switch that overrides publisher, device, or network constraints.

Most importantly, retest with selected-media logging enabled. Seeing the high-quality file in a VAST document is not the same as seeing it selected during the affected play.

When both confirmed files are sharp

Move downstream. Reproduce on the same publisher app and device, then change one variable at a time: device, app version, connection, casting or HDMI path, television resolution, overscan or scaling, and picture mode. Preserve the original failing configuration before changing settings.

A phone photo of a television is useful for locating the symptom, but it is weak quality evidence by itself. Camera focus, exposure, shutter interaction with the panel, viewing angle, and image messaging compression can all alter the photo. Pair it with the selected-media record and a controlled playback comparison.

Send a report that can be acted on

The downloadable CTV blur issue report contains both a completed controlled example and a reusable template. Its core structure is deliberately simple:

1. Supported finding: what the same-timecode source-versus-delivered comparison establishes.
2. Not yet established: the remaining causal question.
3. Requested owner and action: the specific log, transcode change, rendition decision, or device retest needed.
4. Acceptance condition: what a successful retest must show.

For the controlled example, a defensible escalation reads like this:

At 00:04.000, source SHA-256 6daf…1b8 is sharp, while selected-candidate SHA-256 0e26…1a4 is 640×360 and visibly soft when displayed at the same size. This establishes degradation in the candidate file or its enlargement, but not why a production player selected it. Please return the selected-rendition evidence for the affected session and confirm whether the high CTV file was eligible and included.

That is more useful than “The TV made our 1080p ad blurry.” It gives each team a testable boundary, names the missing evidence, and prevents the source, ad server, publisher, player, and television from being collapsed into one vague problem.

The release gate

Before approving another export or closing the ticket, make sure you can answer five questions:

1. What exact source file and hash were approved?
2. What exact media URL, rendition ID, or stitched asset played in the affected session?
3. What do both files show at the same timecode and display size?
4. Is the difference present in the bytes, only in live playback, or both?
5. Which owner controls the first stage where the difference appears?

A blurry CTV ad is not solved by proving that a sharp master exists. It is solved by locating the first point where the observed image stops matching that master—and attaching enough evidence for the owner of that point to reproduce the change.

Sources

• Video creatives — Google Display & Video 360 Help; accessed September 9, 2026.
• Connected TV creatives — Google Display & Video 360 Help; accessed September 9, 2026.
• Specify bitrate and media format — Google IMA SDK for HTML5; updated September 1, 2026; accessed September 9, 2026.
• Ad interface reference — Google IMA SDK for HTML5; accessed September 9, 2026.
• VAST 4.3 — IAB Technology Laboratory, 2022; accessed September 9, 2026.
• VAST CTV Addendum 2024 — IAB Tech Lab, 2024; accessed September 9, 2026.
• Creative Specifications (Video) — Quantcast; updated September 1, 2026; accessed September 9, 2026.
• Understanding Innovid Video Specs — Innovid Knowledge Base; updated December 15, 2025; accessed September 9, 2026.
• Streaming TV and Prime Video ad specs — Amazon Ads; accessed September 9, 2026.
• ffprobe Documentation — FFmpeg; accessed September 9, 2026.