Video Seeking and Keyframes: Why You Can't Jump to Minute 45

You drag the seek bar to minute 45 and let go. Sometimes the frame appears instantly. Sometimes the picture freezes, smears into coloured mush, or goes black for a beat before snapping into place. Sometimes the player quietly lands you at 44:52 instead — close, but visibly not where you dropped the handle. And sometimes a file refuses to start at all until a progress bar has crawled across the whole thing. Those four annoyances look unrelated. They are not. Video seeking and keyframes are the single structural fact underneath all of them, and once you can see it, every one of those behaviours becomes predictable rather than mysterious.

The fact is this: most frames in a video cannot be decoded on their own. A video file is not a stack of pictures you can flip to. It is a stack of instructions, most of which say “take the picture you already have and change these parts of it.” Ask for minute 45 directly and there is nothing there to show you — only a description of how minute 45 differs from a picture you never decoded.

Video seeking lands on the nearest keyframe before the requested moment and decodes forward to reach it

Most Frames in a Video Cannot Be Decoded on Their Own

Video compression works because consecutive frames are almost identical. Thirty frames of a person talking are thirty nearly-identical pictures; storing all thirty in full would be enormously wasteful. So codecs store differences instead, and they do it with three kinds of frame.

An I-frame (intra-coded) is a complete, self-contained picture. Decoding it requires nothing but itself — it is compressed the way a JPEG is compressed, using only information inside that one image. This is what people mean by a keyframe: a place where the decoder can cold-start.

A P-frame (predicted) says, in effect, like the last reference picture, but with these blocks moved here and these residual differences added. That “moved here” is motion compensation — the encoder finds where a block of pixels went between frames and stores the movement vector instead of the pixels. A P-frame is worthless without the frame it references.

A B-frame (bidirectional) is the aggressive one: it predicts from frames both before and after it in display order. A camera pan is far cheaper to describe if you can interpolate between the picture before and the picture after. B-frames are typically the smallest of the three, and they are the reason display order and decode order are not the same thing — a decoder must already hold a future frame before it can build a B-frame that sits in the past.

Only I-frames are self-contained; P-frames and B-frames are undecodable without the frames they reference

Frame type	Also called	What it needs to decode	Relative size	Safe to start playback here?
I-frame	Intra-coded, keyframe	Nothing but itself	Largest — often 5–10× a P-frame	Yes
P-frame	Predicted, inter-coded	The reference frame(s) before it	Much smaller	No
B-frame	Bidirectional	Reference frames before and* after* it	Smallest	No

One precision note for anyone reading tool output: in H.264 terms, the frame that truly resets the decoder — guaranteeing that nothing after it references anything before it — is an IDR (instantaneous decoder refresh) frame. A plain I-frame does not by itself carry that guarantee. In everyday tooling, “keyframe” means “a point this tool believes is safe to start at,” which is usually an IDR and occasionally something looser. It is a distinction worth knowing exists before you debug a seek that lands somewhere strange.

The GOP: The Unit a Video Is Actually Made Of

Frames are not scattered randomly. Encoders emit them in a repeating unit called a Group of Pictures — a GOP — which begins with an I-frame and runs until the next one. Everything inside a GOP is, directly or transitively, dependent on that opening I-frame.

GOP shape is conventionally described with two numbers: M, the distance between reference frames, and N, the distance between I-frames. A structure of M=3, N=12 produces the classic pattern IBBPBBPBBPBB — one I-frame, then P-frames every third slot, with pairs of B-frames filling the gaps (Group of pictures).

A group of pictures begins with a keyframe; a closed GOP is self-contained while an open GOP references the next group

GOPs come in two flavours, and the difference is exactly a seeking difference. A closed GOP is fully self-contained: no frame inside it references anything outside it, so a decoder handed that GOP and nothing else produces correct pictures. An open GOP lets the B-frames at its boundary reference the next GOP, which buys slightly better compression — those boundary frames get better predictions — at the cost of independent decodability. Open GOPs are why a stream that looks cleanly divided on paper can still stutter at a cut point.

This is the whole story of seeking, compressed into one sentence: a player cannot start at minute 45, so it starts at the last keyframe at or before minute 45 and decodes forward until it arrives. Everything you experience at the seek bar is a consequence of how far back that keyframe is, and how fast the decoder can chew through the gap.

That also explains the three seek-bar symptoms. Snapping to a slightly wrong time means the player decided not to decode forward at all and simply showed you the keyframe. Stutter means it is decoding forward and hasn’t caught up. Precise and instant means the keyframe was close by.

Keyframe Interval Is a Dial, and Someone Already Turned It

How far apart keyframes sit is not a property of video. It is a choice made by whoever encoded the file, and it is a genuine trade with no free side.

Keyframes are expensive. An I-frame carries a whole picture with no help from its neighbours, so it costs several times what a P-frame costs. Insert them often and, at a fixed bitrate, every one of them steals bits from the frames around it — the same file gets visibly worse. Insert them rarely and you get better quality per bit, but you also get long stretches where nobody can enter the stream.

More frequent keyframes	Less frequent keyframes
Finer, faster seeking — less to decode forward	Coarser seeking; the player may decode seconds of video to reach your target
Faster startup: a viewer joining mid-stream waits less for an entry point	Slower joins, and worse channel-change latency in live delivery
Cleaner cuts for editing and lossless trimming	Cut points are constrained to keyframe boundaries
Faster recovery after packet loss or a corrupt segment	A single damaged reference can smear until the next keyframe
Worse compression at the same bitrate — more bits spent on full pictures	Better compression at the same bitrate

Keyframe interval is a trade — frequent keyframes buy fast seeking, sparse keyframes buy better compression

Encoders expose this dial under different names — FFmpeg’s generic -g (GOP size, in frames), libx264 and libx265’s own keyint and min-keyint, and scene-change detection that inserts extra keyframes at hard cuts because a cut is a point where prediction fails anyway. Defaults differ by encoder and change between versions, so check ffmpeg -h encoder=libx264 for the build you actually have rather than trusting a number from a forum post. And note the layering here, because it is the most common confusion in this whole subject: H.264 is a standard; x264 is an encoder that implements it. They do not have the same defaults, and they are not the same thing.

Why Streaming Formats Force Short GOPs

Segmented streaming — HLS, defined in RFC 8216, and MPEG-DASH — works by cutting a stream into independently downloadable chunks, each a few seconds long, listed in a playlist or manifest. The player fetches chunks, can switch to a different quality level between chunks, and can start at any chunk.

That last property has a hard prerequisite: every segment must begin with a keyframe. A segment starting on a P-frame would reference pictures the player may never have downloaded — it would be, quite literally, undecodable on arrival. So a streaming encoder does not get to choose a long GOP for compression reasons; the keyframe interval is pinned to a clean divisor of the segment duration, and it stays there.

Every streaming segment must begin with a keyframe, or it arrives undecodable

That constraint is also why streaming video generally seeks better than a downloaded file, despite travelling over a network. A two-second segment size means a keyframe at worst two seconds behind any point you click. It is also why live streaming trades latency against efficiency so directly: shorter segments mean faster joins and lower latency, at the cost of more keyframes, more per-segment overhead, and more requests — which is where ping, jitter, and packet loss start to matter as much as raw throughput. If you want the wider picture on how that throughput budget is actually spent, our guide to understanding internet bandwidth covers the arithmetic.

(One dating note for anyone citing the spec: RFC 8216 is in the process of being obsoleted — draft-pantos-hls-rfc8216bis was at revision 22 and sitting in the RFC Editor queue as of 2026-08-03. Check which document is current before quoting it as the authority.)

The `-ss` Trap: Why Flag Order Changes Everything in FFmpeg

FFmpeg exposes the fast-versus-exact seeking choice directly, and it does so through a piece of syntax that surprises almost everyone: the same flag means two different things depending on where you put it.

Everything below describes FFmpeg as currently documented — the release is 8.1 “Hoare,” released 2026-03-16 (ffmpeg.org/download.html). That pin matters more here than in most FFmpeg topics. Input-side seeking was for years a purely approximate, keyframe-snapping operation, and an enormous amount of still-circulating advice was written against that older behaviour. The current documentation describes something more capable.

Put -ss before -i and it is an input option. FFmpeg seeks inside that input file to the requested position, and since exact seeking usually is not possible, it “will seek to the closest seek point before position” — a jump straight into the file using the container’s index, with no decoding of everything in between (ffmpeg documentation). What happens to the surplus between that seek point and your actual target depends on -accurate_seek: with it enabled — the default when transcoding — that surplus “will be decoded and discarded,” so your output starts exactly where you asked. With -noaccurate_seek, or when you are stream-copying, the surplus “will be preserved” instead, and your output starts at the keyframe.

Put -ss after -i and it becomes an output option with completely different mechanics: FFmpeg “decodes but discards input until the timestamps reach position.” It walks the file from the beginning, decoding every frame and throwing it away, until it arrives. Frame-accurate, and the cost scales with how deep you seek — which is precisely why “why is trimming a two-hour file taking forever” is such a common complaint, and why it feels so much like a computer that has mysteriously gone slow when it is really just an enormous amount of decoding nobody asked for out loud.

Input-side seeking jumps straight to a seek point while output-side seeking decodes and discards from the start of the file

Where `-ss` goes	What FFmpeg does	Speed	Accuracy	Reach for it when
Before `-i`, re-encoding	Seeks to the closest seek point before the position, then decodes and discards up to the target (`-accurate_seek`, the transcoding default)	Fast — independent of how deep you seek	Frame-accurate	Almost always, if you are re-encoding anyway
Before `-i`, with `-c copy`	Seeks to the closest seek point; the surplus is preserved, so output begins at a keyframe	Fastest	Keyframe-accurate	Fast, lossless trims where a shifted in-point is acceptable
Before `-i`, with `-noaccurate_seek`	Same seek; surplus preserved even while re-encoding	Fast	Keyframe-accurate	You explicitly want the keyframe boundary
After `-i` (output option)	Decodes and discards every frame from the start of the file until the timestamps reach the position	Slow, and slower the deeper you go	Frame-accurate	Rarely — this is mostly legacy advice now

The design principle is worth stealing. Fast-but-approximate and slow-but-exact are usually two settings on one knob, not two tools, and FFmpeg’s decision to expose both ends of that knob rather than pick one for you is the reason the flag ordering feels so strange. It is not a quirk of the parser. It is the trade-off, made visible.

Why Your Trimmed Clip Starts With a Frozen or Black Frame

Here is the specific failure that sends people to search engines. You run a fast, lossless trim — -ss before -i, -c copy to avoid re-encoding — and the resulting clip opens with a frozen frame, a grey or green rectangle, or a few seconds of smeared garbage before the video snaps to life.

Nothing is corrupt. The clip starts on a P-frame or a B-frame, and the reference frames those depend on were not copied into the output. The decoder is being handed instructions that say “modify the previous picture” when there is no previous picture. It does whatever its error-concealment path does — hold the last thing it had, show green, or show nothing — until the next keyframe arrives and gives it a clean slate.

A stream-copied clip that starts on a P- or B-frame freezes and smears until the next keyframe arrives

This is where the layering matters. -c copy is a stream copy: packets are moved from one container to another without being decoded or re-encoded, so it is instant and genuinely lossless. That is also exactly why it cannot fix this. There is no re-encode in which to construct a fresh I-frame at your chosen in-point. Lossy is lossy, and stream copy is not — but stream copy also cannot manufacture data the codec never stored.

You have three honest options, and they are all trade-offs rather than fixes:

Accept keyframe-aligned cuts. Ask the file where its keyframes are (next section) and choose in-points that land on them. Free, instant, lossless — you just do not get to pick arbitrary times.
Re-encode the clip. Drop -c copy and let FFmpeg build a new I-frame at your exact in-point. Frame-accurate, at the cost of encoding time and one generation of lossy quality loss.
Plan for it at encode time. If you control the source, -force_key_frames lets you place keyframes at times you know you will cut on, or simply shorten the interval. This is the same reason screen recordings and screencasts vary so much in how pleasantly they trim: capture tools make this choice for you, and rarely tell you which one they made.

Finding the Keyframes Yourself With `ffprobe`

You do not have to guess where the keyframes are. ffprobe — the inspection tool that ships alongside ffmpeg, built to print stream information “in human- and machine-readable fashion” (ffprobe documentation) — will list them.

The decoder-side approach uses -skip_frame nokey, which tells the decoder to throw away every frame that is not a keyframe, leaving only the ones you want:

ffprobe -v error -select_streams v:0 -skip_frame nokey \        -show_entries frame=pts_time,pict_type \        -of csv=print_section=0 input.mp4

That prints one line per keyframe: its presentation timestamp in seconds, and its picture type. Those timestamps are your legal cut points for a lossless trim.

There is a cheaper route that skips decoding entirely. Because the container already records which packets are keyframes, you can read the index instead of the pictures:

ffprobe -v error -select_streams v:0 \        -show_entries packet=pts_time,flags \        -of csv=print_section=0 input.mp4

Keyframe packets carry a K in the flags column. This is dramatically faster on large files, because nothing is being decoded — but it is only as good as the container’s own index, which brings us to the twist.

The Twist: The Index at the Wrong End of the File

Everything above assumed the player knows where the keyframes are. That knowledge does not come from the codec. It comes from the container — and here the containers diverge completely.

The dependency lives in the codec; the index lives in the container. That split — a container is not a codec, MP4 and Matroska hold streams while H.264 and AV1 compress them — is why the same H.264 video can seek beautifully in one file and miserably in another.

Container	How random access is indexed	What that costs you
MP4 / MOV	Per-track sample tables inside the `moov` metadata block record which samples are keyframes — a precomputed map of the whole file	Instant, precise seeking once `moov` has been read; nothing works before that
Matroska / WebM	A separate `Cues` element: an index of `Cluster` positions, each `CuePoint` carrying a `CueTime`, `CueTrack`, and `CueClusterPosition`. The spec recommends — a non-mandatory “SHOULD” — that every keyframe be referenced (Matroska: Cues)	Seeking is a lookup; but a file with missing or incomplete `Cues` degrades to scanning
MPEG-TS	No seek index at all. A flat multiplex of fixed 188-byte packets whose clock signal, the Program Clock Reference, exists to synchronise decoders rather than to locate content	Players estimate a byte offset, jump there, and scan forward for the next keyframe — the format where the seek bar is openly approximate

MPEG-TS is not broken; it made a boundary choice. It was designed for broadcast, for a stream that has not finished happening yet, where “seek to minute 45” is not a question the format can be asked. (The packet-level specifics there — 188 bytes, PAT/PMT, PCR — are stable, widely-documented engineering background; the formal text, ITU-T H.222.0 / ISO/IEC 13818-1, is paywalled, so treat them as background rather than quoted spec.)

Now the payoff. MP4’s index is wonderful — and by default it is written at the end of the file. FFmpeg’s own format documentation says so plainly: the metadata is “usually written at the end of the file” (ffmpeg formats documentation). There is a good reason for it. A muxer does not know the final size, duration, or sample layout until it has finished writing every sample, so writing the index last means writing it once.

MP4 metadata written at the end of a file cannot be read until the whole file arrives; faststart moves the index to the front

For local playback this is invisible. Your operating system can read the end of a file as cheaply as the beginning, so the player grabs moov, then plays. Over HTTP, it is a disaster. The player cannot locate any frame — including the very first one — until it has an index that lives at the far end of a file it has not finished downloading. That is the file that “takes forever to start,” while a visually identical file next to it starts instantly. Same codec, same bitrate, same resolution, same everything a normal person can inspect. Different byte layout.

The fix is one flag. -movflags +faststart runs “a second pass moving the index (moov atom) to the beginning of the file,” and FFmpeg documents its cost honestly: it “can take a while, and will not work in various situations such as fragmented output” (ffmpeg formats documentation). That second pass is why it is not the default — it means reading and rewriting the entire file after the encode has already finished.

Fragmented MP4 dodges the problem from the other direction rather than fixing it. In fragmented output, “a fragmented file consists of a number of fragments, where packets and metadata about these packets are stored together” — self-describing chunks that never need the end of the file to make sense of the beginning. That is the same architecture segmented streaming needs anyway, which is why DASH and modern HLS deployments lean on fragmented MP4 rather than shipping monolithic files with a relocated index.

The generalisable lesson is worth more than the flag: metadata-after-payload is a layout decision with a hidden assumption about how it will be read. It is optimal for random-access local reads and catastrophic the moment reads become “forward, over a network.” Any format with a trailing manifest — media container, archive, log, database file — has this same failure mode waiting for its first streaming consumer.

What This Means for You

Seeking never jumps to a time. It jumps to the nearest keyframe at or before that time and decodes forward. The wait, the stutter, and the snap are all measures of how far back that keyframe was.
Keyframe interval is somebody’s trade-off, made before you ever opened the file. Frequent keyframes buy seeking and startup speed; sparse keyframes buy compression. There is no setting that gets both.
In FFmpeg, flag order is semantics. -ss before -i seeks; -ss after -i decodes-and-discards. Both are frame-accurate now when re-encoding — a change most circulating advice predates.
A frozen or black opening frame after a -c copy trim is not corruption. It is a P- or B-frame with no reference frame. Cut on a keyframe, or re-encode.
Ask the file, don’t guess. ffprobe -skip_frame nokey lists keyframe timestamps; reading packet flags does the same thing without decoding, and much faster.
If a file is slow to start over a network, check the index position before blaming the bandwidth. -movflags +faststart on the MP4 muxer is a one-flag fix for a problem that looks like a hosting failure.

📚 Further Reading

ffmpeg Documentation — the authoritative text on -ss as an input versus output option, -accurate_seek / -noaccurate_seek, and -force_key_frames.
ffmpeg Formats Documentation — -movflags +faststart, the default moov-at-end behaviour, and fragmented MP4.
ffprobe Documentation — -show_frames, -show_packets, -show_entries, and the output writers used in the commands above.
FFmpeg Download & Release Page — which release is current; seeking behaviour has changed across the project’s history, so version matters.
Matroska: Cues — the Cues/CuePoint seeking index, in the format’s own words.
ISO/IEC 14496-12 (ISO catalogue) — the formal ISO Base Media File Format standard behind MP4’s metadata and sample tables. Paywalled; the catalogue entry is the citable public record.
RFC 8216 — HTTP Live Streaming — the segmented-delivery model that makes every segment boundary a keyframe boundary.
Group of Pictures and MPEG Transport Stream — background on GOP notation and on the container that deliberately carries no seek index.
Understanding Internet Bandwidth for Engineers and Architects — where the bits a keyframe interval spends actually go.

❓ Frequently Asked Questions

What is a keyframe in a video?

A keyframe — an I-frame — is a frame compressed using only information inside itself, so it can be decoded with no other frame present. Every other frame type (P and B) is stored as a set of differences from other frames and is undecodable without them. Keyframes are therefore the only places a decoder can cold-start, which makes them the only places a player can truly begin playback.

Why does my video player jump to the wrong spot when I seek?

Because it jumped to the nearest keyframe at or before your target and stopped there rather than decoding forward to your exact time. If keyframes in that file sit ten seconds apart, the worst-case error is ten seconds. Players that decode forward to the exact frame trade that inaccuracy for a delay instead — which is the stutter you sometimes see rather than a jump.

Should I just use a very short keyframe interval so seeking is always fast?

Only if you know what you are buying it with. Keyframes are several times larger than predicted frames, so at a fixed bitrate every extra keyframe takes bits away from everything around it and the file looks worse. Streaming encoders accept that cost deliberately because segment boundaries require it. An archival encode usually should not.

Why does `-ss` behave differently before and after `-i` in FFmpeg?

Because position determines whether it is an input option or an output option, and those are genuinely different operations. Before -i, FFmpeg seeks inside the input using the container’s index and starts from the closest seek point — fast, and frame-accurate when re-encoding thanks to -accurate_seek. After -i, it decodes and discards frames from the start of the file until the timestamps reach your position — frame-accurate, but the cost grows with how deep you seek.

Why does my trimmed clip start with a frozen or black frame?

Because a stream copy (-c copy) cut the file at a P- or B-frame whose reference frames were left behind. The decoder receives instructions to modify a picture it does not have, and shows whatever its error concealment produces until the next keyframe arrives. Cut on a keyframe timestamp, or drop -c copy and re-encode so a fresh I-frame is built at your in-point.

Why do some MP4 files take forever to start playing over the internet?

Because MP4 metadata — the moov index that says where every frame lives — is written at the end of the file by default. Over a network a player cannot locate even the first frame until it has that index, so playback waits on the download. -movflags +faststart rewrites the file with the index at the front, and fragmented MP4 avoids centralising the index at all.

How do I find the exact keyframe timestamps in a file?

ffprobe -v error -select_streams v:0 -skip_frame nokey -show_entries frame=pts_time,pict_type -of csv=print_section=0 input.mp4 prints one line per keyframe. Reading packet flags instead — -show_entries packet=pts_time,flags, looking for a K — gets the same list from the container’s index without decoding anything, which is far faster on large files.

📚 Recommended Resources

Disclosure: some links below are Amazon affiliate links. If you buy through them, I earn a small commission — at no extra cost to you — which helps keep this site running.

Start with the free material — that is the honest recommendation here. Frame types, GOP structure, and container indexing are unusually well covered by free primary sources, and thinly covered by the printed shelf: several standard video texts predate HEVC and AV1 entirely, and there is no mature book on AV1 or VVC at all. Work through these first, and buy a book only if you want the deeper theory in print.

Digital Video Introduction — Leandro Moreira’s free, illustrated walkthrough of exactly the machinery this article rests on: temporal redundancy, I/P/B frame types, motion compensation, and GOP structure, with runnable examples. If the “most frames cannot be decoded on their own” idea is new to you, this is where to see it worked through properly. Actively maintained, translated into several languages, and the only widely-used introduction that treats AV1 as a first-class citizen.
FFmpeg’s own documentation — ffmpeg-all — every flag in this article on one nightly-regenerated page: -ss as an input versus output option, -accurate_seek / -noaccurate_seek, -force_key_frames, -skip_frame, and -movflags +faststart. When a forum post and this page disagree about seeking behaviour, this page is right — and since input-side seeking genuinely changed over the project’s history, that matters more here than almost anywhere else.
A Digital Media Primer for Geeks — Xiph.org’s free primer on sampling and quantization. It does not cover seeking, but it builds the intuition underneath it: why storing thirty near-identical pictures in full is wasteful in the first place, which is the whole reason P- and B-frames exist for you to trip over later.

The H.264 Advanced Video Compression Standard

Iain E. Richardson · 2nd edition, Wiley, 2010 · Hardcover, 352 pp

The book to read if you want the frame-dependency machinery in full rigour rather than in outline. Everything this article treats as a given — intra versus inter prediction, motion vectors and residuals, reference-picture management, and the IDR distinction that the “keyframe” shorthand papers over — is developed here at specification level, by the author whose H.264 books became the standard reference. The precision note in this article about IDR versus a plain I-frame is exactly the kind of thing this text will not let you stay vague about.

One honest caveat: it is an H.264 text, published in 2010. It predates HEVC and AV1 entirely. The structural ideas transfer — every modern codec still has self-contained and predicted pictures — but do not buy it expecting coverage of newer codecs.

Video Demystified: A Handbook for the Digital Engineer

Keith Jack · 5th edition, Newnes, 2007 · Paperback, 944 pp

The practical engineer’s handbook for the layer this article’s container section lives in — MPEG stream structure, transport streams, and the packet-level plumbing behind the claim that MPEG-TS carries no seek index at all. If the 188-byte packets and the Program Clock Reference in the container table left you wanting the full picture of how a broadcast multiplex is actually assembled, this is the book that lays it out end to end.

Read the date honestly: the 5th edition is from 2007. It is excellent on the MPEG-2/H.264-era broadcast stack it was written for and has nothing to say about HEVC or AV1. Buy it as a reference for transport-layer and signal-side engineering, not as a current codec book.

Introduction to Data Compression

Khalid Sayood · 5th edition, Morgan Kaufmann, 2017 · Paperback, 790 pp

The theory behind the sentence this whole article turns on — that a video is a stack of instructions, not a stack of pictures. Sayood builds up from information theory through predictive and differential coding, which is the formal account of why storing “how this frame differs from that one” beats storing the frame, and therefore why decodability became a chain in the first place. General compression theory rather than a video-specific text, which is the point: the same ideas turn up in audio, images, and file formats you will meet later.

Coding Video: A Practical Guide to HEVC and Beyond

Iain E. Richardson · Wiley, 2024 · Hardcover, 448 pp

The most current codec text on the shelf, and the natural follow-on if the H.264 book above leaves you wondering how much of this survived into modern codecs. It walks the block-based coding pipeline — prediction, transform, quantization, entropy coding — for HEVC, including the reference-picture and random-access structures that are the direct descendants of the GOP described here.

One caveat worth stating plainly: the publisher’s own description does not promise substantive AV1 or VVC coverage, so treat “and Beyond” as an HEVC-centric book with a forward glance rather than a guide to the newer codecs. For AV1, the free AOMedia specification is the literature.