Instagram pulled VP9 in 5 days — same Reel reverted

Same Reel, same shortcode, different codec — again

Walk it through with us. April 23, 11:30 UTC — H.264 baseline served. Eight hours on, same day: the Reel had switched to VP9 gen2. Skip five days. Mid-morning April 28 UTC we pulled it again, back on H.264. About 24 hours after that, from a CDN edge across the country, still H.264.

We documented the first half of that arc in [our last post](https://instayolo.com/blog/instagram-vp9-transition-caught-live) — a single 60-second @natgeo Reel (shortcode `DH56yy7p3lZ`) flipping codec between two parse calls 8 hours apart. The hypothesis at the time: Meta is rolling VP9. Quietly. Watch this space.

Five days later the watch paid off, just not the way we expected. Same Reel. Same `xpv_asset_id` field locked at `1170775294179927`. Same `asset_age_days` ticking honestly upward (386 → 392 — six days, six increments, no funny business). The `vencode_tag` field — the encoding profile baked into the signed CDN URL's base64-encoded `efg` parameter — now reads `ig-xpvds.clips.c2-C3.dash_baseline_1_v1` again. Plain H.264 baseline. The VP9 string is gone.

Why we trust this isn't a regional fallback

Meta serves the same asset from many edges — and edges occasionally diverge during rollouts. So a single H.264 result on a single edge doesn't kill the VP9 hypothesis. To rule that out we pulled the Reel twice, 24 hours apart, from edges 4,000 km apart. First fetch: `scontent-lga3-2` (a New York / Long Island PoP). Second fetch: `scontent-sjc6-1` (San Jose). Two different physical buildings. Two different network paths.

Both returned `dash_baseline_1_v1`. Both at exactly `1356360 bps` video bitrate. Both at exactly `59330 bps` audio bitrate. Identical down to the byte. If this were edge-level codec divergence, the SJC and LGA edges wouldn't agree — and they do.

The asset_age_days difference between the two pulls is exactly 1, which is the precision the field exposes. So 24h elapsed in the real world translated to one day-tick in Meta's internal clock for this asset. Sanity check passed.

What the efg decode actually showed

Side-by-side, the JSON we got out of base64-decoding the `efg` query parameter:

**4/23 second pull (VP9 era, from blog #9):** `vencode_tag: "ig-xpvds.clips.c2-C3.dash_vp9-basic-gen2_1080p"`, video bitrate ~1.49 Mbps, asset_age_days `386`, xpv_asset_id `1170775294179927`.

**4/28 pull (LGA edge):** `vencode_tag: "ig-xpvds.clips.c2-C3.dash_baseline_1_v1"`, video bitrate `1356360` bps (~1.36 Mbps), asset_age_days `391`, xpv_asset_id `1170775294179927`.

**4/29 pull (SJC edge):** identical to 4/28 except `asset_age_days: 392`. Same `vencode_tag`. Same `bitrate`. Same `xpv_asset_id`. Same `vi_usecase_id: 10099`. Same `duration_s: 60`.

Translation. The VP9 variants Meta generated between 4/23 noon and 4/23 evening — they no longer fronted by the URL generator. The H.264 baseline is back as the served representation. Whether the VP9 files still sit in cold storage on Meta's side, we can't tell from the outside. The CDN's `urlgen` service is no longer pointing at them.

Three things this could mean

Theory one: completed A/B test. Meta encoded VP9 variants for some slice of Reels (popular, recent, certain creator tiers — pick your hypothesis), measured the result for a few days, decided the bandwidth savings didn't beat the playback-compatibility cost, flipped urlgen back. The `vp9-basic-gen2` profile name implies this is iteration two of Meta's VP9 pipeline — meaning gen1 was already tested and rolled back at some prior point. We're watching gen2 do the same dance.

Theory two: per-asset rotation. The VP9 file still exists in Meta's CDN backend, but the urlgen service decides serve-time which codec to hand out. Decision input could be region, network conditions on the requesting edge, time-of-day, asset popularity in the last N hours, or a thousand other things. In this view VP9 isn't gone — it's just dormant for this specific asset right now.

Theory three: a real rollback. Storage cost, encoder bug, decoder complaints, executive whim. Meta yanked the VP9 variants out of urlgen's pointer table. The encoded files might even be deleted from the CDN's hot tier and waiting to expire from cold storage.

Telling these apart from outside Meta is hard. We can't ask urlgen what's behind its decision. What we can do: keep pulling the same shortcode periodically — daily for a week — and see if VP9 ever comes back. If it does, theory two wins. If a month passes with strict H.264, theory one or three. We're going to do the boring part.

The bitrate is the weird part

720p H.264 pre-flip ran at 1,356,360 bps. Post-rollback? Same 1,356,360 bps — exact same number. Same bitrate budget, same asset, same delivery profile. Meta hasn't re-run the H.264 encoder. Urlgen just stopped pointing at the VP9 variants and went back to the original master.

Which means the VP9 variants Meta produced on 4/23 were strictly additional storage. They didn't replace H.264; they sat alongside it. The flip we saw was urlgen choosing the VP9 representation. The flip back is urlgen choosing the original H.264. The compute budget went into making VP9 files that briefly served traffic and now don't.

Sensible if you think of it as a small-scale test that ran on the cheap. Less sensible if you imagined it was a full migration.

What this changes for you

Nothing breaks. Downloads of this Reel today come back as H.264 baseline MP4 — same file profile our pipeline has been delivering for months. ffprobe will report `codec_name=h264`, `profile=Baseline`, `level=3.1` or thereabouts. Plays everywhere video plays.

If you pulled the same Reel between 4/23 evening and 4/27, you might have a VP9 MP4 on disk somewhere. That copy is now an artifact — a snapshot of a 5-day window where this specific asset was VP9-served. Don't expect to reproduce it from a fresh download today.

For tools that hardcode codec assumptions in their UI: if you wrote "Meta is rolling VP9" anywhere visible, you might want to soften it. The verb is "experimenting," not "rolling." We're updating ours accordingly.

How to check this on any Reel yourself

Open the Reel URL in any parse-exposing tool. Ours sits at `/api/parse` (POST `{"url":"..."}`); yt-dlp does the same job from the command line. Get the resulting MP4 URL. Find the `efg=` query parameter. Base64-decode the value (URL-decode it twice first — the parameter is double-encoded by Meta's URL signer). The decoded JSON includes `vencode_tag`. That string tells you which encoding profile is being served.

`dash_baseline_1_v1` — H.264 baseline, the default for years.

`dash_vp9-basic-gen2_<resolution>` — VP9 second-generation, the variant we caught alive on 4/23 and watched die by 4/28.

`dash_av1-*` — AV1, which we haven't seen in the wild on Reels but which Meta has experimented with on web-surfaced clips before. If you hit one, [tell us](/contact) — we'd track it.

`dash_hevc-*` — HEVC. Meta yanked this in 2024. Hit one anyway? Congrats, you've got a fossil.

Want every other field in the `efg` payload broken down? [The CDN URL signature anatomy post](https://instayolo.com/blog/instagram-cdn-url-signature-anatomy) walks the whole thing.

Why this kind of observation matters

Search results for "Instagram codec" in 2026 are mostly Reddit threads from 2019, marketing copy from competing downloader tools claiming "4K HEVC support" (Instagram's CDN doesn't ship 4K HEVC, see our [4K myth post](https://instayolo.com/blog/the-4k-instagram-reel-myth)), and academic papers from the early VP9-versus-H.265 debates. Almost nobody is doing live observability against Meta's actual delivery pipeline. The pipeline ships changes whenever Meta wants and reverts them whenever Meta wants, and unless you're decoding signed URLs you don't see any of it.

Catching a VP9 transition in an 8-hour window was one observation. Catching the same asset reverted 5 days later is the second observation. Stitched together they're a story: Meta's codec pipeline is alive, mutable, and not running on the schedule any of the public guides suggest. Anyone shipping product against "Instagram videos are H.264" or "Instagram is moving to VP9" is operating on stale information either way.

Our policy: report what we measure. Update when the measurement changes. The blog post you're reading now is what that policy looks like in practice — public correction five days after the original post, same author, same evidence chain, no quiet edit to the original. The first post stays up unedited because it was true on 4/24. This one says what's true on 4/29.

What we'll watch next

Daily pull on this same shortcode for the next 14 days. Looking for: VP9 reappearing (theory two), AV1 first sighting (worth a fresh post), or month-long H.264 stability (theory one or three).

Spot-checks on other popular Reels. Are any still on `dash_vp9-basic-gen2_*` today? If yes, the rollback was per-asset rather than fleet-wide. If no, fleet-wide.

The `oil_urlgen_app_id` field across all our pulls is a constant `936619743392459`. That number identifies which Meta app generated the URL — same value across all our tests means urlgen treats Reels uniformly regardless of who's asking. If we ever see a different value, that'd be a hint that some other Meta surface (Threads? Story-archive? Internal tooling?) gets different codec selection logic.

The asset itself — that 391-day-old @natgeo clip from late March 2025 — is now our reference point for codec drift. Every observation we make against it builds the longitudinal record. Six days in, six data points, two state transitions. The next transition will tell us a lot.

**Expert tip**: if you're doing similar observability on any other social platform's CDN, the first thing to look for is a versioned encoding-profile string somewhere in the URL or response payload. Meta calls theirs `vencode_tag`. TikTok has something similar in their bytevc1 pipeline. Once you find that field, you have a microscope. Use it.