264 File Documentation

---

Technical details

Feature	Value
Full name	Raw H.264 / AVC video elementary stream
File extension	.264 (identical to .h264)
MIME type	video/h264
Format type	Raw elementary stream: NAL units, no container
Standard	ITU-T Rec. H.264 / ISO/IEC 14496-10 (MPEG-4 Part 10, AVC)
Developer	ITU-T VCEG & ISO/IEC MPEG (Joint Video Team)
Finalised	2003
Open standard	Yes — published ITU-T / ISO-IEC specification
Written by	CCTV/IP cameras, DVRs, NVRs, encoders dumping codec output
Contains audio	No — video only
Contains timing	No — no frame rate, duration or seek index
NAL start code	00 00 00 01 (4-byte) or 00 00 01 (3-byte)
First NAL units	SPS (type 7, byte 0x67) then PPS (type 8, 0x68)
Byte format	Byte-stream (Annex B) with emulation-prevention bytes
Lossless fix	Remux into MP4/MKV with -c copy (no re-encode)
Related extensions	.h264, .mp4, .mkv, .ts
Specification	itu.int/rec/T-REC-H.264

What is a .264 file?

A .264 file is a raw H.264 video elementary stream: the direct output of an H.264 encoder, with nothing wrapped around it. H.264 (also called AVC, or MPEG-4 Part 10) was finalised in 2003 as ITU-T Recommendation H.264 and ISO/IEC 14496-10, and it is one of the most widely used video compression standards. A .264 file is the same thing as a .h264 file; the two extensions name one format. The .264 spelling is the one that CCTV cameras, DVRs and NVRs most often write when they export a clip.

The key word is elementary. Unlike an MP4 or an MKV file, a .264 stream has no container: no box structure, no audio track, and no frame-timing index. It is a bare sequence of coded video data. That is exactly why generic players and editors often refuse to open it or show no duration, and why the practical answer is almost always to wrap the stream into a real container.

NAL units and the Annex B byte stream

An H.264 stream is a sequence of NAL units (Network Abstraction Layer units). Each NAL unit is one self-contained piece of coded data: a parameter set, a coded slice of a picture, or metadata. In a raw .264 file the units are stored in the “Annex B” byte-stream format, where each unit is preceded by a start-code prefix so a decoder can find unit boundaries by scanning bytes.

[00 00 00 01] [NAL] [00 00 00 01] [NAL] [00 00 01] [NAL] ...
 start code    unit   start code    unit   3-byte sc  unit

The start code is 00 00 00 01 (four bytes) or 00 00 01 (three bytes). Because those byte patterns could otherwise appear inside coded data, the encoder inserts emulation-prevention bytes: any sequence 00 00 00, 00 00 01, 00 00 02 or 00 00 03 inside a unit’s payload is written as 00 00 03 xx, and the decoder strips the inserted 03 before parsing. This is what lets a decoder scan for start codes without ever mistaking payload bytes for a boundary.

The first byte after each start code is the NAL header. Its low five bits are the nal_unit_type, which names what the unit is. A stream normally opens with a Sequence Parameter Set (type 7, header byte 0x67) and a Picture Parameter Set (type 8, 0x68) before any picture data.

NAL type	Header byte	Contents
1	0x41	Coded slice of a non-IDR picture (P/B frame)
5	0x65	Coded slice of an IDR picture (keyframe)
7	0x67	Sequence Parameter Set (SPS)
8	0x68	Picture Parameter Set (PPS)
6	0x06	Supplemental Enhancement Information (SEI)
9	0x09	Access unit delimiter

SPS and PPS: what the parameter sets carry

The parameter sets are the configuration a decoder needs before it can interpret any frame. The Sequence Parameter Set describes properties that hold for a whole sequence: the profile and level (which decoding features are used and the maximum bitrate/resolution the decoder must handle), the picture width and height in macroblocks, the chroma format, and the frame-numbering scheme. The Picture Parameter Set holds per-picture decoding parameters: entropy coding mode (CAVLC or CABAC), the number of reference-picture lists, and quantisation defaults. Coded slices reference a PPS by id, and each PPS references an SPS by id, so the two parameter sets must reach the decoder before the slices that depend on them. In a raw .264 file they sit at the very front, which is why the file typically begins 00 00 00 01 67.

What the stream does not contain: timing, audio and an index

Everything a normal video file offers beyond the coded pixels is missing from a raw .264. There is no frame rate: the stream carries coded frames in decode order but does not state how many should play per second, so a muxer has to be told or guess. There is no duration and no seek index, so a player cannot show a timeline or jump to a point without decoding from the start. There is no audio at all; H.264 is a video codec, and a raw elementary stream never carries a soundtrack. If a CCTV recording had audio, it was in a separate file or a separate stream.

These absences are the whole reason a .264 file is awkward. The coded frames are perfectly valid; what they lack is the surrounding bookkeeping that a container such as MP4 provides. Supplying that bookkeeping is what remuxing does.

Remuxing into MP4 or MKV without re-encoding

The correct fix is to remux: copy the existing coded frames into a container, adding the timing and index metadata, without touching the video itself. Because nothing is re-encoded, remuxing is lossless and near-instant. With ffmpeg:

ffmpeg -i in.264 -c copy out.mp4          # wrap into MP4, no re-encode
ffmpeg -framerate 25 -i in.264 -c copy out.mp4   # supply the missing frame rate
ffmpeg -i in.264 -c copy out.mkv          # MKV is the most forgiving target

The -c copy flag is what makes it lossless: it copies the H.264 bitstream unchanged and only writes new container structure around it. Because the raw stream carries no timing, the muxer picks a default frame rate unless told otherwise, which is why footage sometimes plays too fast or too slow after a naive remux; setting -framerate to the camera’s real fps corrects it. If an odd stream trips up the MP4 muxer, MKV accepts almost anything and is the safe fallback. For evidence footage from surveillance systems, remuxing with -c copy preserves the original frames byte-for-byte, which re-encoding would not.

Playing a raw stream directly

VLC can usually play a .264 file without remuxing, because it includes a demuxer that scans for the Annex B start codes and feeds the NAL units straight to its H.264 decoder. If VLC does not pick it up automatically, selecting the H.264 demuxer in its input settings forces the issue. This is convenient for a quick look, but the file still has no timeline and no audio, so for sharing or editing the remux to MP4 or MKV remains the real solution.

Frequently asked questions

Is .264 the same as .h264?

Yes. Both are the same raw H.264 elementary stream in the Annex B byte-stream format; only the extension differs. DVRs and CCTV systems tend to write .264, while encoders often write .h264. Treat them identically: play in VLC, remux to MP4 with ffmpeg.

Why is there no sound in my .264 file?

A raw H.264 stream is video only, by design. H.264 is a video codec and an elementary stream never carries an audio track. If the recording had audio, it was a separate file or in a different container export from the camera.

My remuxed video plays too fast or too slow. Why?

The raw stream carries no frame rate, so the muxer guessed one. Re-remux and state the camera’s real rate: ffmpeg -framerate 25 -i in.264 -c copy out.mp4, replacing 25 with the correct fps.

Why won’t it open in Windows Media Player?

Windows Media Player expects a container and cannot read a bare elementary stream. Open it in VLC, or remux it to MP4 first with ffmpeg; after that it plays in any normal player.

References

• ITU-T H.264 — Advanced video coding for generic audiovisual services
• FFmpeg — formats and remuxing documentation
• VideoLAN — VLC media player

Feedback

Was this page helpful?

Yes No

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.