Transcoding vs encoding in plain English: encoding compresses raw video, transcoding converts it, transmuxing repackages it. Learn which your CCTV system needs.
Encoding and transcoding are two of the most misused terms in video, and the confusion is expensive. Teams that think they need transcoding buy far more hardware than necessary. Teams that underestimate it ship streams that break. Buyers comparing cameras, recorders and video platforms often find the two words used as if they meant the same thing. They do not.
This guide clears it up in one pass: what encoding is, what transcoding is, why they cost such different amounts, where each happens, the formats that matter, hardware versus software, and the third term, transmuxing, that matters more than either for live CCTV.
Encoding takes raw video, uncompressed pictures straight from a camera sensor, and compresses it into a compact stream using a codec. "Codec" is short for coder decoder; the encoder is the coder half.
Raw video is enormous. Nobody records or sends it outside a few specialist studios, because the storage and bandwidth would be unaffordable. Every practical system compresses video before it leaves the camera.
Encoders shrink video by skipping what repeats. Neighbouring pixels in a frame usually look alike. Consecutive frames usually look almost the same, so the encoder records only what moved. And the eye is less sensitive to some detail, so the encoder spends fewer bits there.
In surveillance, the result is almost always H.264 or H.265 video, wrapped in a container such as MP4 or carried by a streaming protocol such as RTSP. Three things define an encoded stream: the format (H.264, H.265), the bitrate (how much data per second, which trades quality against size), and the profile (which features it uses, matched to what players can handle).
Cameras encode. Streaming platforms encode live sources. Some cloud recording services compress again after receiving camera video, which is transcoding.
Transcoding converts video that is already compressed into a different compressed version. It is unpack, then compress again. The transcoder decodes the video back to raw pictures, then encodes it with new settings.
You transcode when the original does not match what the viewer needs. A camera might send H.264 at 8 Mbps while a viewer on a weak connection needs far less. A recorder might store H.265 while an old player understands only H.264. A streaming service might need several versions at different quality levels for different devices.
Transcoding is far more demanding than encoding for two reasons. It adds a decoding step, and one input often becomes several outputs, multiplying the work.
It also costs quality. Every unpack and recompress loses something, because the second compression cannot recover what the first discarded, and it discards more. That is why the strongest video platforms avoid transcoding whenever they can, and transmux instead.
In one line: encoding turns raw video into compressed video; transcoding turns compressed video into different compressed video.
A typical surveillance system has five stages. Knowing which does what removes most of the confusion.
Capture and encode: the camera. The sensor captures raw pictures, the camera's processor adjusts exposure and colour, and its encoder compresses the result into H.264 or H.265, usually as a main stream and a lighter substream, sent over RTSP or ONVIF. This is encoding.
Receive: the video platform. If it will record and serve the video as it arrived, it does not transcode; it simply repackages the stream for storage and delivery. That is transmuxing.
Record. Modern systems store exactly what the camera produced, preserving quality and saving computing power.
Deliver: to the viewer. If every viewer can play the camera's format, the platform simply repackages the video into whatever protocol the viewer uses, such as WebRTC, HLS or MPEG-DASH. Only if a viewer needs a different format, data rate or size does the platform transcode.
Play: the viewer's screen. The player decodes the video and displays it. That is decoding, not encoding.
In a modern system, transcoding happens rarely, and only at delivery when a viewer cannot play what the camera sent. The best platforms keep the camera's original video intact from camera to screen.
Four formats matter in 2026: H.264, H.265, AV1 and VP9.
H.264 (AVC) is the workhorse. Introduced in 2003 and standardised by the ITU-T and ISO/IEC, it plays on every camera, recorder, browser and phone. It is the universal baseline.
H.265 (HEVC) is its successor, standardised in 2013 by the same bodies. It needs much less data than H.264 for similar quality, which is why high resolution surveillance increasingly defaults to it. Support is now mature, though patent licensing still causes friction for some.
AV1 is a royalty free format from the Alliance for Open Media (Google, Netflix, Amazon, Microsoft, Apple, Meta and others), standardised in 2018. It compresses even more efficiently but is far more demanding to encode, and it dominates large online streaming services more than surveillance.
VP9 is Google's predecessor to AV1, common on YouTube and rare in surveillance.
Cameras encode; video platforms decide whether to keep the camera's format or convert. That decision should follow your viewers: if they can all play H.265, keep it. Convert only for the viewers that genuinely need H.264.
Transcoding is demanding enough that the industry has invested heavily in dedicated hardware.
Software transcoding runs on the computer's main processor, using tools such as FFmpeg with x264, x265 or AV1 encoders. It is flexible, every setting can be tuned, and it is cheap for occasional jobs. It struggles with large live workloads, because a general purpose processor is not the most efficient tool for heavy video work.
Hardware transcoding uses chips built for the job: NVIDIA NVENC and NVDEC on graphics cards, Intel Quick Sync, AMD VCN, and dedicated video transcoding cards. It handles many more streams per machine with far better power efficiency.
The trade off is flexibility and some compression efficiency: hardware encoders offer fewer settings than the best software encoders.
The rule that works: hardware for busy live workloads, software for smaller jobs where quality per bit matters, such as archiving important footage.
Transmuxing is often confused with transcoding, but they are completely different in cost and in what they do to quality.
Transcoding unpacks and recompresses the picture: demanding, and it loses quality. Transmuxing repackages the compressed video into a different container without touching the picture: almost free, and no quality loss.
An example. A camera sends H.264 over RTSP. To show it in a browser over HLS, the platform packs the same H.264 into short segments listed in an HLS playlist. The video is unchanged, just repackaged: transmuxing. To show it over WebRTC, the platform repackages it again for WebRTC. Still transmuxing.
If the browser can play H.264, nothing needs transcoding at any stage. The platform only transcodes when the viewer cannot play what the camera produced.
Platforms that transmux by default deliver better pictures (no quality loss), lower running costs (almost no computing power) and faster live view (no unpack and recompress delay).
Always encode at the camera. The camera is the only place raw pictures become a compressed stream. This choice is made when you buy the camera.
Prefer transmuxing at the video platform. If viewers can play the camera's format, repackage it for delivery without touching the picture.
Transcode only when you must: the viewer cannot play the format, needs a much lower data rate, or needs a different picture size.
Match the tool to the job. Dedicated hardware suits busy live conversion; software suits one off conversions and archive jobs where quality matters most.
Cap transcoding deliberately. Systems that transcode by default, with no limit, waste computing power and money on work transmuxing would have done for free. Make transcoding a conscious decision, not a default.
Visylix is an automated AI video surveillance platform built in India, and its native streaming engine is built on one principle: keep the camera's original video intact.
Passed through, not reprocessed. Visylix takes video in over RTSP, RTMP, SRT, WebRTC (WHIP), GB28181, NDI and RIST, and delivers it over WebRTC (WHEP), HLS, LL-HLS, MPEG-DASH, HTTP-FLV and SRT, repackaging rather than recompressing whenever the viewer can play the camera's format. That preserves every detail of the original picture and delivers live view in under a second over WebRTC, down to under 200 ms.
Converted only when needed, and always capped. When a browser needs H.264 from an H.265 camera, Visylix converts just that stream, with a strict limit so conversion can never slow the rest of the system. Small video wall tiles use the camera's own lighter substream instead of converting at all.
AI that never slows the video. Visylix runs 22 AI analytics built in house, including face recognition, number plate recognition, object detection, person tracking, crowd detection, PPE detection, heat maps, pose estimation, intrusion detection and line crossing, on a separate path from live viewing, so AI never competes with live view for speed.
Everything else you would expect from a world class platform: 13+ streaming protocols, ONVIF camera control, and an interface in 55 languages including 13 Indian languages and 4 right to left scripts. Starter and Pro include unlimited cameras on the VMS licence, from ₹4,999 or $49 per month, with AI added per camera per month. Visylix ships as a Docker image on your own hardware. See https://visylix.com/pricing or reach the team at https://visylix.com/contact.
Related reading: HLS vs WebRTC, video bitrate for streaming and surveillance, CMAF, HEVC vs H.264, RTMP server setup and our streaming protocols comparison.
Encoding turns raw video into a compressed stream. Transcoding turns compressed video into a different compressed version, at a real cost in computing power and quality. Transmuxing repackages compressed video without touching the picture: almost free, with no quality loss.
Cameras always encode. Video platforms should transmux by default and transcode only when a viewer cannot play the camera's format, data rate or picture size.
Use dedicated hardware for busy live conversion and software for archive work where quality per bit matters.
Platforms that transmux first deliver better pictures, lower costs and faster live view.
Encoding compresses raw video, straight from a camera sensor, into a compact video stream using a format such as H.264 or H.265. Transcoding takes video that is already compressed and converts it into a different compressed version, usually to change the format, quality, size or frame rate. Encoding starts from raw video; transcoding starts from compressed video. Every camera encodes. Transcoding is added only when a viewer needs something different from what the camera sent.
Video encoding is compressing raw video into a much smaller stream using a codec (a compression format). Raw video is enormous, so every practical system compresses it before storing or sending it. Encoders shrink video by skipping what repeats: neighbouring pixels that look alike, frames that barely change, and detail the eye will not notice. The result is a stream in a standard format such as H.264 or H.265.
Video transcoding converts video that is already compressed into a different compressed version. The transcoder unpacks the video back to raw pictures, then compresses it again with different settings. It is needed when a viewer requires a different format, quality, size or frame rate from the original, for example converting H.265 to H.264 for an older player.
No. Encoding turns raw video into compressed video. Transcoding turns compressed video into different compressed video, which means unpacking and compressing again. That makes it far more demanding on computing power, and it loses some quality each time, because the second compression cannot recover what the first threw away.
Transmuxing repackages compressed video into a different "envelope" (container) without touching the picture itself. It costs almost nothing in computing power and loses no quality. For example, a platform receiving H.264 from a camera over RTSP and sending the same H.264 to a browser over HLS only needs to transmux. Transcoding is needed only when the viewer cannot play what the camera produced.
In three situations: the viewer cannot play the camera's format (for example an H.264 only player and an H.265 camera); the viewer needs a much lower data rate than the camera sends; or the viewer needs a different picture size. Everything else should be handled by transmuxing, which repackages video without changing it.
Software transcoding runs on the computer's main processor using tools such as FFmpeg. It is flexible and produces excellent quality, but it is demanding at scale. Hardware transcoding uses dedicated video chips, such as NVIDIA NVENC, Intel Quick Sync or AMD VCN. It handles far more streams per machine and uses less power, but offers fewer settings and usually slightly less efficient compression. Hardware suits busy live workloads; software suits smaller jobs where quality per bit matters most.
Only when it must. Visylix passes your cameras' video through untouched whenever the viewer can play it, simply repackaging it for delivery over WebRTC, HLS, LL-HLS, MPEG-DASH, HTTP-FLV or SRT. When a browser needs H.264 from an H.265 camera for live view, Visylix converts just that stream, with a strict cap so conversion can never slow anything else. Small video wall tiles use the camera's own lighter substream instead. The result is original picture quality and live view in under a second.
For most modern installations, H.265 (HEVC) on newer cameras. It needs far less bandwidth and storage than H.264 at similar quality, which matters for high resolution footage. H.264 remains the safest choice for compatibility with older players and recorders. The smart approach is to record in the camera's most efficient format and convert only for the specific viewers that need it.
It depends on the format (H.265 is harder work than H.264), the quality setting, the resolution and frame rate, and whether the job is live or a batch. Live transcoding of many streams is demanding, which is why the best surveillance platforms avoid it wherever possible and pass the camera's original video straight through.