Your Video Looks Fine Locally but Blurry after Upload: What Platforms Do to It

The most common explanation is an adaptive bitrate (ABR) transcode ladder, a set of quality levels and renditions the player chooses between based on the user’s access connection and software size. For a more detailed breakdown, let’s look at how this pipeline breaks down the uploaded original into a stack of options, many of which don’t match the creator’s original settings.

The upload is not the final encode

When a video is uploaded to many online video platforms, it enters an adaptive bitrate streaming pipeline. The platform first stores the uploaded master in object storage, then transcodes this source into an ABR ladder - a range of resolutions, bitrates, and encoding profiles that ultimately become the options available for playback. Once the transcoding is complete, the platform generates adaptive bitrate manifests and segments, which are then delivered to users’ video players over a content delivery network (CDN).

This means that the upload is just the beginning of the pipeline. The original video is not set as a final destination in the ABR ladder - it is transcoded into multiple renditions, each with unique resolutions and bitrates. The player later selects a rendition conditioned on the loaded size and the browsers present connection speed.

Focus on platform transcode pipeline: upload file, adaptive-bitrate ladder, rendition selection, ABR manifests and segments, CDN delivery and never on focal length, audio mixing or anything else.

What platforms actually publish as renditions

One thing that’s quickly apparent about adaptive bitrate ladders: they don’t just include the 1080p source the creator uploaded. Even platforms that claim to upload 4K or 8K videos still resample them into lower resolutions, often several lower ones.

Dolby’s OptiView documentation outlines a typical ABR ladder: an adaptive bitrate ladder typically includes 1920×1080 at 4,500 kbps and 30 fps, 1280×720 at 2,500 kbps and 30 fps, and 640×360 at 1,000 kbps and 30 fps. They recommend stream settings of 480×270 at 500k and 25 fps, 640×360 at 900k and 25 fps, 960×540 at 1800k and 25 fps, 1280×720 at 4500k and 25 fps, and 1920×1080 at 8500k and 25 fps.

The streaming media company ImageKit offers a practical example of an adaptive bitrate streaming pipeline: They cover five variants – 240p, 360p, 480p, 720p, and 1080p. Within these spatial sizes, ImageKit also specifies an agreed target bitrate: 240p targets 200K, 360p targets 400K, 480p targets 800K, 720p targets 3300K, 1080p targets 5500K, 1440p targets 12000K, and 2160p targets 18000K.

Microsoft Stream sets bitrate targets when publishing Microsoft Teams meeting recordings: they are delivered as 1080p adaptive bitrate stream at about 1 Mbps. General video recordings hosted on OneDrive and SharePoint, on the other hand, are delivered as 1080p adaptive bitrate streams as well – another example of the fallback to 1080p.

Why the player did not choose the best version

In classically wired adaptive streaming, a defined A/B bitrate ladder is built by the platform, streaming over multiple tracks. Metadata like render timecodes and reference overlays guide the video player in selecting from this ladder.

Just because the platform offers 4K at 60 fps doesn’t guarantee the end user sees it - the video player still needs to defeat the reference frame by reference frame. Player size, connection strength, and overall streaming conditions dictate how many bits per second the platform of choice consumes.

If a video is being played in a small player, the highest resolution will be poor, even if the highest rendition in the ABR orchestration ladder is available. Lower target render targets might be a great end outcome from the end-user frame for that particular session, but video designers should not assume them.

When the player size is smaller than the current size, Video.js says, it will only switch up one size greater – behavior that demonstrates why even the 1280×720 rendition of a 3840×2160 feed on a small browser results in such a visible loss in image quality. Which rendition a player actually selects depends on viewing size, feed availability, encoder strength on the input, and servo-speed - in short, all the things that could still be guessed after encoding has finished but before final playback.

The visible failure modes

Given this adaptive playback system, we can start digging into the visible issues. Object slicing, poor edge management, and poor flow from frame to frame are happening because of a series of compression and decompression passes from transcode to playback, not just the input.

First, fast motion on screen can cause variable interactions that are often under bitrate control. Tactile texture on edges, like pixels, struggle as the bitrate ladder descends. The larger reason behind this migrating image quality is that we think about bitrate as a constraint of content, while it’s really an influencing factor in playback.

Video platforms, especially smaller ones, often underdeliver on the quantized slice part of ABR. This means, on-screen, that can often look like blocking or sliicing: From a video fidelity point of view, these are the most visible errors.

Finally, motion smearing and lower bitrate, with egregious multicoding, bleed into compression artifacts reflected on screen. Bright edges, sharp items, and high-contrast scenes get the worst of this edge glyphing.

Practical export choices

So how does this reveal itself in the exporting and uploading process. In short, one must assume a document will not be treated as it is uploaded. Even though the master is stored, it will get transcode, there is no production control over the input, so avoid pre-compression as much as possible. Denoise before export, and assume that any noise or loss found in decoding will reveal itself most obviously in large scene renditions.

Assuming 4K delivery guarantees a 4K result is a mistake. Save the local master, but ensure the quality ladder, as rendered into the platform cloud, provides the pixel accuracy you need – and watch for the files and ladders which platform documentation reveals are sketchy.

Platform documentation silence

This article went into deep dive into generic adaptive bitrate pipelines, while finding documentation that identifies input restrictions, output results, and abusive gross streaming behaviors important for video quality. What we don't see is a clear statement that providing clear evidence improves quality on-platform without direct communication between the creator and the streaming platform.

Video sharing platforms often prioritize universal playback over high quality video for creators, prioritizing themselves and universal playback at the expense of creators. For more information,