Cut HEVC

How to Cut an HEVC File Online

1. Upload Your HEVC File: Drag and drop or click "Add Files" to select a .hevc raw elementary stream — exports from FFmpeg's hevc_mp4toannexb/extract_extradata filters, x265 CLI output, NVIDIA NVENC/AMD AMF dumps, Intel Quick Sync samples, codec test vectors, and IP-camera Annex B byte streams all work. Containerized H.265 (.mp4, .mkv, .mov, .ts) is also accepted and the H.265 elementary stream is extracted automatically. Batch is supported — drop in multiple .hevc files at once.
2. Set Start Time and Duration: Enter a start time and a duration to keep. Both fields accept seconds (12.5) or HH:MM:SS.sss format (00:00:30.500) for millisecond precision. Add multiple cut segments to extract several non-contiguous regions from the same bitstream in a single pass — useful for pulling specific GOPs out of a long test vector.
3. Pick Output Settings (Optional): By default the cut is frame-accurate and the video is re-encoded as H.265 at the visually-lossless default preset (CRF 17), written out as a fresh self-contained Annex B stream. Pick different settings if you need a codec change: H.264 (universal playback), AV1 (~30% smaller than HEVC at equivalent quality), VP9, MPEG-4, or HEVC at a new bitrate. Pair with a resolution preset (2160p, 1440p, 1080p, 720p, 480p, percentage, or custom width/height) and a quality preset (Highest → Lowest), CRF slider (18 = visually lossless, 23 = default, 28 = smaller), constant bitrate, or target file-size percentage.
4. Cut and Download: Click Cut. Files process on our servers — download individually or as a ZIP. No sign-up, no watermark, no length cap on the output. The output keeps the .hevc extension and stays Annex B by default.

Why Cut a Raw HEVC Stream?

A .hevc file is the raw HEVC/H.265 elementary stream in Annex B byte-stream format — NAL units prefixed with 0x000001 startcodes and no container around them, per the ITU-T H.265 / ISO/IEC 23008-2 spec, Annex B. That format is what x265, NVENC, the FFmpeg hevc_mp4toannexb bitstream filter, and most IP-camera pipelines emit. Cutting here decodes the stream and re-encodes the kept range at the visually-lossless HEVC default, producing a clean, frame-accurate Annex B clip. Note that it is a re-encode — the original NAL units are not preserved byte-for-byte, so when bit-exact extraction matters (conformance work, decoder-bug repro) cut locally with ffmpeg -c copy instead. Common reasons to cut a raw HEVC bitstream:

• Codec regression testing and bug isolation — When an HEVC decoder hangs, crashes, or produces visual artefacts on frame 3,847, cutting a 50-frame window around that frame gives you a small repro clip to attach to a bug report instead of a 4 GB original. Because the cut re-encodes, byte-level decoder faults may not reproduce in the clip — use this page when a visually representative window is enough, and ffmpeg -c copy locally when the bug depends on the exact source NAL units.
• Conformance and test-vector trimming — JCT-VC and AOMedia reference test vectors are often multi-GB; teams routinely cut representative sub-sequences (one IDR period, one B-pyramid, one tile-partitioned slice) for unit tests and CI fixtures.
• FFmpeg / GStreamer pipeline analysis — Engineers debugging a transcode chain often dump raw .hevc after hevc_mp4toannexb to inspect NAL units in HEX. Cutting to the suspect range lets HEVC ES Viewer, gpac, or 265dump load the file in seconds.
• IP-camera and surveillance review — Reolink, Hikvision, and Dahua cameras commonly export Annex B .hevc per-channel. Cut the 15-second window of an incident out of an 8-hour recording without processing the whole feed.
• Broadcast and remux extraction — Engineers pulling HEVC payloads from MPEG-TS or DASH segments work with raw Annex B by default. Cutting in the Annex B domain avoids a round-trip through a container and back.
• Sharing developer repro clips — A 5-second HEVC cut at 1080p is typically under 5 MB, which fits under Discord's 10 MB free upload cap (dropped from 25 MB in April 2024), Gmail's 25 MB inline cap, and most GitHub-issue attachment limits.

If you need the cut wrapped into a playable container afterwards, run it through HEVC to MP4 or HEVC to MKV. For the timeline-editor experience without the raw-bitstream framing, see Trim HEVC, or Compress HEVC for size-only reduction.

Default Cut vs Custom Settings — When to Use Which

Property	Default settings	Custom settings
Speed	Proportional to clip length	Proportional to clip length and codec
Quality	Re-encoded at the visually-lossless HEVC preset (CRF 17)	Whatever CRF / bitrate you choose
Cut precision	Frame-accurate	Frame-accurate
VPS / SPS / PPS parameter sets	Freshly written by the encoder (self-contained output)	Freshly written by the encoder
SEI messages (HDR10, HDR10+, DV RPU, timecode)	Not reliably carried through the re-encode	Not reliably carried through the re-encode
10-bit / 12-bit Main10 / Main12 profiles	Output is standard 8-bit 4:2:0	Output is standard 8-bit 4:2:0
Output codec	Stays H.265 / HEVC, stays Annex B	H.264, H.265, AV1, VP9, MPEG-4, etc.
Best for	Quick frame-accurate clips at source-matching quality	Codec change for compatibility, smaller file

Every cut decodes and re-encodes the kept range, so the output can start on any frame — no IDR/CRA alignment required. Stream-copy tools, by contrast, can only start at an IDR (Instantaneous Decoder Refresh) or CRA (Clean Random Access) NAL unit and snap to the nearest one; with a re-encode the GOP layout of the source (1-2 s for cameras, 5-10 s for low-bitrate IP-camera encoders) doesn't affect the cut point.

HEVC Profile / Source Cut Reference

Source	Typical GOP	Profile / bit depth	Cut behavior
x265 CLI output (--keyint 250)	~10 sec at 25 fps	Main / Main10	Frame-accurate re-encode; long source GOPs don't limit the cut point
FFmpeg hevc_mp4toannexb dumps	Matches source GOP	Whatever source uses	Frame-accurate re-encode; source NALs not preserved byte-for-byte
NVENC / AMF / QuickSync HEVC	1-2 sec	Main / Main10	Frame-accurate re-encode
IP-camera Annex B (Reolink / Hikvision)	2-10 sec	Main	Frame-accurate re-encode
UHD Blu-ray remux extract	1-2 sec	Main10, HDR10 / HDR10+ / DV	Frame-accurate re-encode; HDR metadata not reliably preserved
Apple ProRes / iPhone capture transcoded to.hevc	1-2 sec	Main / Main10	Frame-accurate re-encode
JCT-VC reference test vectors	Varies (often 8-32 sec)	Main / Main10 / Main12 / 4:2:2	Frame-accurate re-encode; not conformance-preserving — use ffmpeg -c copy for that

Frequently Asked Questions

Does cutting a .hevc file re-encode the bitstream?

Yes — every cut decodes the stream and re-encodes the kept range at the visually-lossless default preset (CRF 17); there is no stream-copy path. That makes the cut frame-accurate and the output visually indistinguishable from the source, but the NAL units are freshly encoded, not byte-identical to the source. For codec testing, where a re-encode would mask the exact bug you're trying to capture, cut the repro window locally with ffmpeg -c copy -ss ... -t ... instead.

Will the VPS, SPS, and PPS parameter sets be carried into the cut output?

The output has its own: because the cut re-encodes, the encoder writes fresh VPS/SPS/PPS NAL units at the start of the output, so the cut decodes standalone — you don't need the original file to play it. They are newly generated, not the source's parameter sets carried verbatim, and source SEI prefix messages (HDR10 mastering display, HDR10+ dynamic metadata, Dolby Vision RPU, picture timing) are not reliably carried through the re-encode.

Why does my cut start a second or two earlier than the timestamp I entered?

With XConvert it shouldn't — the cut re-encodes the kept range, so the output starts at your exact timestamp. Snapping is stream-copy-cutter behavior: those tools can only start the output at an IDR or CRA keyframe (the only NAL units a decoder can independently initialise from), so they rewind to the nearest preceding one — up to 10 seconds with x265 --keyint 250 at 25 fps. Here the source GOP layout doesn't affect the cut point.

What's the difference between .hevc, .h265, and .265?

All three are conventional extensions for raw HEVC Annex B elementary streams — same byte format, different naming preferences. FFmpeg writes .hevc by default; some tools and reference encoders write .h265 or .265. None of them carry audio, subtitles, or timing — there's no container. If your file has audio or chapters it's almost certainly inside .mp4, .mkv, .mov, or .ts instead; XConvert auto-detects and extracts the H.265 elementary stream from any of those.

Will HDR10, HDR10+, and Dolby Vision metadata survive the cut?

Not reliably. The cut re-encodes the HEVC stream, and HDR10 static metadata (Mastering Display Colour Volume + Content Light Level SEI), HDR10+ dynamic tone-mapping SEI, and Dolby Vision RPU NAL units generally do not survive a re-encode — and no tone-mapping is applied either, so the output is a plain SDR-range encode that can look flat or washed out on HDR sources. If preserving the HDR layer is the point, cut locally with ffmpeg -c copy (which does carry those NAL units) and keep the untouched source.

Can I cut a 10-bit Main10 HEVC bitstream?

You can upload one — 10-bit Main10, 12-bit Main12, and 4:2:2/4:4:4 chroma profiles all decode fine — but the re-encoded output is standard 8-bit 4:2:0, so the source bit depth and chroma sampling are not preserved. If the output must stay Main10 bit-exact (grading intermediates, conformance work), cut locally with ffmpeg -c copy instead.

How do I get the cut to play in QuickTime, Windows Media Player, or a browser?

Raw .hevc Annex B is a developer/analysis format — most consumer players won't open it directly because there's no container, no audio track, no duration metadata, and no MOOV box. Once you've cut the bytes you need, run the output through HEVC to MP4 or HEVC to MKV to wrap it in a player-friendly container. Windows 10/11 also needs Microsoft's HEVC Video Extensions codec ($0.99 in the Microsoft Store) for built-in playback; free alternatives are VLC, MPV, and PotPlayer.

What's the maximum .hevc file size I can cut?

There's no fixed cap. Cutting runs on our servers, so the practical limit is upload size and connection speed and patience for the upload. Multi-GB encoder dumps and 50-80 GB UHD Blu-ray HEVC extracts both work — processing time scales with the length of the segment you keep, not the full source duration. For very large sources, consider pre-cutting with ffmpeg -i in.hevc -c copy -ss... -t... out.hevc locally to shrink the upload.

Can I cut multiple non-contiguous segments from the same .hevc file in one pass?

Yes. The trim controls accept multiple segments — add a second range (start + duration) and the cut concatenates both regions into one output .hevc. Each segment is re-encoded, so segments can start on any frame — no IDR/CRA alignment needed — and the result is a single self-contained bitstream. Useful for extracting specific test ranges (e.g., the IDR period containing frames 0-30 plus the one containing frames 1000-1030) into a single regression fixture.

Should I cut the raw .hevc or cut the containerised MP4/MKV instead?

Cut in whichever domain you'll consume the output in. If your downstream tool (codec analyser, conformance checker, NAL dumper) wants raw Annex B, cut the .hevc directly. If you need a playable file with audio and timing, work from the MP4/MKV — see Trim HEVC for the container-aware workflow, or cut here and run HEVC to MP4 on the output. Avoid round-tripping: cutting MP4 → demuxing to .hevc → re-cutting Annex B is wasted work that risks SEI loss at the container boundary.