AUTHENTIC MEDIA
Under the hood

Why this is harder than it looks.

Authentic Media does, with a tiny team, what used to take a roomful of infrastructure engineers: take a video off your phone, caption and encode it right in your own browser, package it for adaptive streaming, and deliver it anywhere in the world — fast. The heavy media work happens on your device; Fastly’s edge stores it and serves it. Here’s why that’s genuinely hard, and how the pieces fit together — everything below is the public story, no secret sauce.

Why video is the hardest thing on the internet

More data, more compute, less patience. Almost every hard problem in computing shows up at once when you try to move video to millions of people.

Video is most of the internet

It isn’t a slice of online life — it’s the majority of it. Industry measurements (Sandvine, 2023) put video at roughly 65% of all internet traffic, and even higher on mobile networks.

Raw video is astronomically large

One minute of uncompressed 1080p at 60fps is about 6 gigabytes — a flood of ~3 gigabits every second, more than most home connections could carry for a single viewer. Compression isn’t optional; it’s the only reason streaming exists.

Codecs shrink it hundreds of times — at a steep cost

Codecs (H.264, HEVC, AV1) squeeze that firehose down to a few megabits — but the better the compression, the more compute it takes to create. Newer codecs like AV1 can take 20–100× longer to encode than older H.264.

Every upload is re-encoded, many times over

An uploaded file usually can’t be streamed as-is. It’s re-encoded into many versions for different devices, screens, and connection speeds — one of the most compute-heavy jobs in consumer software. We do it right in the creator’s browser, so there’s no encoding farm to run.

Adaptive streaming = a whole “ladder” per video

To play smoothly on a phone on spotty cell service and on a 4K TV on fiber, each video is cut into thousands of tiny segments at many resolutions at once — the “bitrate ladder.” The player quietly switches up and down it, second by second, to match your connection.

Viewers quit almost instantly when it stalls

People have little patience: a study of 23 million views (Krishnan & Sitaraman, 2012) found viewers start leaving once startup passes ~2 seconds, with each extra second driving roughly 6% more of them away.

One video, millions of simultaneous viewers

A video is encoded once but delivered to millions at the same moment, each pulling several megabits a second. Serving that from one place would melt the network — so it must fan out across a global CDN, in real time.

Live is even harder

With recorded video you have time to encode carefully; with live you have none — capture, compress, segment, and deliver as it happens, with no chance to redo a bad frame.

Captions and sourcing add more layers

Captions are generated by speech-to-text, timed to the frame, and packaged alongside every version; here, a source on every claim is its own step on top of all the encoding.

How it all works together

One video sets off a chain of expensive, specialized steps — most of them run right in your browser, on the device in your hand; the edge, close to you, stores the result and serves it to the world. No distant datacenter crunching your footage.

  1. 01
    You capture

    From your phone or browser, your video is recorded or picked right where you are — the file never has to leave your device to be processed.

  2. 02
    Captions, on your device

    Speech-to-text runs in your own browser, transcribing the audio and timing captions to the frame — so every clip is captioned and watchable with the sound off, and nothing is shipped off to be transcribed.

  3. 03
    Encoded in your browser

    Your browser re-encodes the video into a clean, web-ready rendition, plus a poster and a download — the heavy, expensive step, done with WebAssembly on the hardware you already have. No GPU farm, no central server.

  4. 04
    Handed to the edge

    Fastly’s edge — running our own code as WebAssembly, milliseconds from you — takes the finished files, stores them, and serves them. It stores and delivers; it doesn’t crunch your video.

  5. 05
    Packaged for adaptive streaming

    The renditions are cut into small HLS segments and a playlist — the “ladder” your player climbs up and down to match your connection.

  6. 06
    Delivered from the edge

    The finished video is cached across Fastly’s global network and served from a point of presence near you — close, fast, and able to absorb a crowd.

  7. 07
    Played, clean

    Your player auto-picks the right rung of the ladder and adapts as your bandwidth changes — no settings, no dials, no stats cluttering the video.

How we got here

None of this appeared overnight. On the left, how the internet and the cloud were built. On the right, how Fastly made the edge programmable — the piece that makes the pipeline above possible for a small team.

The internet & the cloud

From four wired-together computers to renting compute by the hour.

  • 1969
    ARPANET’s first message

    U.S.-funded researchers wired four university computers together and pioneered “packet switching” — chopping data into small pieces that travel independently. It became the basic idea behind the whole internet.

  • 1974
    TCP/IP is designed

    Vint Cerf and Bob Kahn published TCP/IP, a shared “language” that lets completely different networks talk to one another — making one big internetwork possible.

  • 1983
    The internet’s “flag day”

    On Jan 1, 1983 every machine on ARPANET switched to TCP/IP on the same day — the moment many treat as the true birth of the modern internet.

  • 1984
    Domain names (DNS)

    Paul Mockapetris invented the Domain Name System — the internet’s phonebook — so you could type “example.com” instead of memorizing numbers.

  • 1989–91
    The World Wide Web

    At CERN, Tim Berners-Lee proposed the Web — linking documents with clickable hyperlinks — put the first website online, and gave the software away for free.

  • 1993
    Mosaic, the first popular browser

    Mosaic showed pictures alongside text and made the web point-and-click, pulling millions of ordinary people online and kicking off the web boom.

  • 1998
    Akamai builds the first CDN

    When one popular site could be flooded by a sudden crowd and crash, Akamai invented the content delivery network — copying files onto servers around the world so you load them from somewhere nearby.

  • 2006
    Amazon launches cloud computing

    AWS began renting storage and compute by the hour, so companies could stop buying servers and rent exactly what they needed, when they needed it.

  • 2007
    Streaming + the smartphone

    Netflix started streaming and the iPhone put the full internet in your pocket — together they sent traffic, and especially video, soaring.

  • 2017
    WebAssembly is finished

    Browser makers shipped WebAssembly: a way to run programs at near-native speed inside a tightly sealed sandbox — soon a key building block for running code safely almost anywhere.

  • 2018
    Code moves to the edge

    Platforms began using WebAssembly to run your code not in one distant datacenter but at hundreds of locations near users — “edge computing” — so apps respond in a blink worldwide.

Fastly & the programmable edge

A CDN you could program — then a place to run real code, microseconds from the viewer.

  • 2011
    Fastly is founded

    Artur Bergman (ex-CTO of Wikia) starts Fastly to build a faster, programmable kind of CDN — a network you could configure yourself, in real time.

  • 2012
    Built on Varnish + instant purge

    Built on the open-source Varnish cache and its config language, Fastly could push custom logic to the edge in seconds and wipe stale content network-wide in about 150 milliseconds — cache aggressively, yet stay live.

  • 2013
    Real-time observability

    Customers got live streaming logs and real-time visibility into the edge, instead of the delayed reports legacy CDNs offered.

  • 2019
    IPO, and Compute@Edge

    Fastly went public, and unveiled Compute@Edge — running your own code at the edge with WebAssembly, claiming a ~35-microsecond startup (Fastly’s figure), effectively no “cold start.”

  • 2020
    Edge compute goes GA + security

    The WebAssembly edge-compute runtime reached general availability, and Fastly added a web application firewall and attack protection alongside delivery.

  • 2021
    How much runs through it

    A brief outage publicly revealed how much of the web routes through Fastly — momentarily affecting sites and services people use every day.

  • today
    Delivery + compute + security

    Today it’s one edge cloud: content delivery, edge compute, and security — running customer code milliseconds from users on every continent.

hundreds of Tbps

of edge network capacity (Fastly’s public figures) — enough headroom to absorb huge spikes and attacks without slowing down.

dozens of POPs

“points of presence” on six continents, placed close to internet users almost everywhere in the world.

microseconds

to start your WebAssembly code (Fastly’s claim) — millionths of a second, so there’s no “cold-start” lag for the viewer.

~150 ms

to purge cached content across the entire global network — the speed of caching with the freshness of live data.

“fewer, bigger POPs”

Fastly’s philosophy: a smaller number of very powerful locations, so each caches far more and serves faster on average.

Why this is bleeding-edge

Until recently, building this whole pipeline — re-encode every upload, auto-generate captions, package an adaptive ladder, and deliver it worldwide — meant standing up racks of servers in many regions and stitching together a CDN: realistically, only big companies with dedicated infrastructure teams could do it. Two things changed. WebAssembly got fast enough to re-encode video and run speech-to-text right inside the creator’s browser, so the heaviest work no longer needs a server farm at all. And tiny programs compiled to WebAssembly now run within microseconds at hundreds of locations around the globe, right next to the viewer, on a network with hundreds of terabits per second of capacity — a secure, sandboxed runtime fast and cheap enough to run per-request, sitting on a planet-scale network. Together that’s what lets one person caption, encode, and globally deliver video that used to need a small army and a roomful of hardware.

How problem reports work

There’s a “Report a problem” button on every page. When you use it, your note — and, if you choose, a screenshot you take — is sent to a separate reports service we use to track issues. We read every report, reproduce it, fix it on the live edge, add a test so it can’t come back, and mark the report resolved. No ad trackers, no behavioral profiling, no following you around — a report is something you deliberately send, not something collected in the background. If you leave an email we can reply; if you don’t, the report is anonymous.

Sources for the figures above: internet-traffic share — Sandvine Global Internet Phenomena (2023); startup-delay abandonment — Krishnan & Sitaraman, ACM IMC (2012); codec encode cost — public codec comparisons (AV1 vs. H.264); Fastly network, instant purge, and Compute@Edge figures — Fastly’s own public materials and SEC filings. Scale numbers are Fastly’s public claims and change over time. Raw-video and compression figures are illustrative, derived from typical streaming bitrates.

Report a problem

0/2000