Transcoding vs encoding explained clearly: encoding turns raw video into a compressed stream (H.264, H.265, AV1); transcoding turns one compressed stream into another. Plus transmuxing, hardware vs software transcoding, codec choice, and when each operation actually belongs in a VMS pipeline.
Encoding and transcoding are two of the most misused terms in video engineering, and the confusion is expensive. A team that thinks it needs transcoding when it actually needs encoding over-provisions hardware. A team that thinks it can just re-encode what actually requires transcoding under-provisions and ships a broken stream. VMS buyers evaluating cameras, NVRs, streaming platforms, and cloud services routinely find themselves comparing feature sheets that use the two words interchangeably, which they are not.
This guide fixes the confusion in one pass. It defines encoding, defines transcoding, explains why they are different operations with different cost profiles, walks through the video pipeline stages where each one happens, covers the codec landscape you actually need to know (H.264, H.265, AV1, VP9), explains hardware vs software transcoding, covers transcoding vs transmuxing (a third term that is routinely confused with the first two), and gives the honest engineering framework for deciding when your video system needs one, the other, or both.
Encoding is the process of taking raw video (uncompressed pixel data from a camera sensor, a graphics pipeline, or a screen capture) and compressing it into a video file or stream using a codec. Codec is short for coder-decoder, and the encoder is the coder half.
Raw video is enormous. A single second of 4K raw video at 30 frames per second is roughly 1 gigabyte. A single day of 4K raw video from one camera is roughly 86 terabytes. No one records or transmits raw video except in narrow production workflows, because the storage and bandwidth costs are prohibitive. Every practical video system compresses raw video into a codec-encoded stream before it leaves the sensor.
Video encoders reduce that data volume by 100x to 1000x by exploiting three types of redundancy. Spatial redundancy (pixels near each other in the same frame usually look similar) is compressed using techniques inherited from JPEG image compression: block-based transforms, quantization, and entropy coding. Temporal redundancy (consecutive frames usually look similar) is compressed by encoding motion vectors and residuals rather than full frames. Perceptual redundancy (the human eye is less sensitive to certain kinds of detail) is compressed by allocating fewer bits to information the viewer will not notice.
The output of encoding is a compressed video bitstream. In the surveillance world, that bitstream is almost always H.264 or H.265, packaged inside a container format (MP4, MKV, TS, or a streaming protocol container like RTP for RTSP or fMP4 for HLS or CMAF). In the broadcast world, that bitstream might also be AV1 or VP9. In the mobile world, HEVC (H.265) has become dominant. The encoder does not care about the delivery layer; the container format that wraps the encoded stream does.
The three most important properties of an encoded video stream are the codec (H.264, H.265, AV1, VP9), the bitrate (bits per second, which trades quality for file size), and the profile and level (which specify what encoding features and complexity limits the stream uses, matched to what decoders can handle). Cameras encode. NVRs sometimes encode. Cloud recording services usually re-encode after receiving from cameras (which is transcoding, covered below). Streaming platforms encode from live sources like ingest cameras. Every video producer somewhere in the pipeline is an encoder.
Transcoding is the process of converting an already-encoded video stream into a different encoded video stream. It is decode-then-re-encode. The transcoder takes an input stream in one format, decodes it back into raw video (or a partially-decoded intermediate), then re-encodes it into an output stream with different properties.
The reason to transcode is that the original encoded stream does not match what the consumer needs. A camera might encode in H.264 at 8 Mbps, but a mobile viewer might need H.265 at 500 kbps for a cellular connection. An NVR might record in H.265, but a legacy VMS client might only support H.264. A cloud service might receive H.264 from ingest and need to produce three or four different bitrate ladders for adaptive streaming to different viewer devices. In each case, the transcoder is the component that converts.
Transcoding is meaningfully more expensive than encoding for two reasons. First, transcoding is encoding plus a decoding step, so the compute cost is higher. Second, transcoding is usually a many-to-one or many-to-many operation where a single input stream produces multiple output streams at different bitrates and codecs (the bitrate ladder pattern common in adaptive streaming), so the aggregate compute cost is multiplied.
Transcoding also introduces quality loss. Every encode-decode-re-encode cycle causes generational loss (the compressed re-encoding cannot recover what the first encoder discarded, and the re-encoder discards more). Systems that avoid unnecessary transcoding preserve more of the original image quality, which is why the strongest VMS architectures avoid transcoding whenever possible and use transmuxing (covered below) instead.
Encoding turns raw video into compressed video. Transcoding turns compressed video into different compressed video. The input to encoding is uncompressed pixel data from a sensor, capture card, or graphics pipeline. The input to transcoding is an already-encoded stream from a camera, file, or upstream service. Every video pipeline has at least one encoder (usually in the camera). Whether it has a transcoder depends on whether downstream consumers need a different format than what the encoder produced.
The typical video pipeline in surveillance and enterprise streaming has five stages. Understanding which stage does encoding and which stage does transcoding is the fastest way to avoid the confusion the two terms cause.
Capture and encode (the camera). A modern IP camera has a sensor, an image signal processor, and an on-board encoder. The sensor produces raw video, the ISP processes it (auto-exposure, white balance, denoising), and the encoder compresses it into an H.264 or H.265 stream. This is encoding, not transcoding. The camera outputs one or more encoded streams (main stream, sub stream, thumbnail stream) over RTSP, ONVIF, or an equivalent protocol.
Ingest (the VMS or streaming server). The VMS receives the encoded stream from the camera. If it will record the stream as-is and serve it to clients as-is, it does not transcode. It just repackages the stream into whatever container format the storage and delivery layers require. This is transmuxing, not transcoding.
Recording (the NVR, VMS, or cloud storage). The recording stage writes the encoded stream to storage. Most modern systems record the stream exactly as the camera produced it, which preserves quality and minimizes compute cost. Some legacy systems re-encode on record for storage-format reasons, but the pattern is fading.
Delivery (the streaming layer to the client). The delivery layer serves the encoded stream to viewer clients. If every client can play the camera original codec, bitrate, and container format, no transcoding is required. The delivery layer just repackages (transmuxes) the encoded stream into whatever protocol the client needs (HLS, LL-HLS, WebRTC, MPEG-DASH). If clients need a different codec (H.264 for a legacy player, H.265 for a modern one), a different bitrate (low bitrate for cellular, high bitrate for LAN), or a different resolution (mobile-sized for a phone, full resolution for a workstation), the delivery layer transcodes the stream on the fly or from pre-transcoded variants.
Playback (the viewer client). The client decodes the encoded stream and displays it. This is decoding, not encoding or transcoding. The decoder needs to support whatever codec the delivery layer sent.
The stages where transcoding actually happens in a modern surveillance system are usually two: at ingest (rare, only when the camera codec is unsupported downstream), and at delivery (common, when the client cannot play what the camera produced). Systems designed to avoid transcoding, like modern native VMS architectures, keep the encoded stream in its original form from camera to client whenever possible, transmuxing rather than transcoding.
The codec choices that matter for encoding and transcoding decisions in 2026 are H.264, H.265 (HEVC), AV1, and VP9. Each has a place, and the choice affects both the compute cost and the delivery reach.
H.264 (AVC) is the workhorse codec of the surveillance and streaming industries. Introduced in 2003 and standardized by ITU-T (Recommendation H.264) and ISO/IEC (MPEG-4 Part 10), it is universally supported by every camera, NVR, VMS, browser, mobile device, and streaming service. Its compression efficiency is meaningful but not state of the art. Every video system supports H.264 as a baseline.
H.265 (HEVC) is the successor to H.264, standardized in 2013 by the same ITU-T and ISO/IEC bodies. It delivers roughly 40 to 50 percent better compression than H.264 at equivalent visual quality, which is why surveillance systems capturing high-resolution or high-frame-rate footage increasingly default to H.265. Its browser and player support is now mature, though patent licensing remains a friction point for some deployments. Modern VMS platforms and modern cameras support H.265 natively.
AV1 is a royalty-free codec developed by the Alliance for Open Media (Google, Netflix, Amazon, Microsoft, Apple, Meta, and others) and standardized in 2018. It delivers roughly 30 percent better compression than H.265 at equivalent visual quality but at meaningfully higher encoding cost. It is dominant in over-the-top streaming from Netflix and YouTube and is beginning to appear in surveillance workflows for archive compression. Real-time encoding of AV1 remains expensive.
VP9 is Google predecessor to AV1, standardized in 2013. It provides compression roughly equivalent to H.265 without the licensing complexity. It is dominant on YouTube and appears in some cloud video workflows. It rarely appears in surveillance workflows.
Cameras encode. NVRs and VMS platforms decide whether to store and deliver the camera native codec or to transcode. Transcoding decisions are usually driven by client compatibility: if 100 percent of clients can play H.265, avoid transcoding to H.264 to preserve quality and compute. If any legacy clients require H.264, the delivery layer either transcodes on the fly or maintains a pre-transcoded H.264 variant.
Transcoding compute cost is meaningful enough that the industry has invested heavily in hardware acceleration.
Software transcoding runs the encode and decode operations on the CPU, using libraries like FFmpeg libx264 (for H.264 encoding), libx265 (for H.265), and the AV1 encoders (aom-av1, SVT-AV1, rav1e). Software transcoding is flexible (you can tune every encoding parameter), cheap for occasional workloads, and universally supported. It is expensive for high-throughput workloads because CPU cycles are not the most efficient way to do the massive parallel computation that video encoding requires. Typical software H.264 encoding runs on the order of 30 to 200 frames per second per CPU core depending on preset and resolution.
Hardware transcoding offloads encoding and decoding to specialized silicon designed for the task. NVIDIA GPUs include NVENC and NVDEC blocks that handle H.264, H.265, and AV1 encoding and decoding. Intel Quick Sync Video provides similar acceleration on Intel iGPUs and discrete GPUs. AMD VCN (Video Core Next) handles the same job on AMD hardware. Dedicated video transcoding ASICs from vendors like NETINT and specialized cloud instances provide the highest per-watt throughput. Typical hardware transcoding runs on the order of 1000 to 4000 frames per second per accelerator depending on codec and quality preset, at roughly 5 to 10 times better power efficiency than software.
The tradeoff is quality and flexibility. Hardware encoders produce output that is roughly 10 to 30 percent less compression-efficient than the best software encoders at equivalent quality, because the fixed-function silicon supports fewer encoding modes. Hardware encoders are also less tunable. You get the presets the vendor exposes, not every parameter that libx264 offers.
The rule that consistently produces good outcomes for VMS and streaming deployments is to use hardware transcoding for high-throughput real-time workloads (live delivery to many clients, adaptive bitrate ladder generation for scale) and software transcoding for archive re-encoding workloads where the compute cost is bounded and the quality per bit matters (long-term storage of high-value footage).
Transmuxing (short for transport muxing) is often confused with transcoding, but the two operations are fundamentally different in cost and in what they do to the video quality.
Transcoding decodes and re-encodes the video pixels. Compute expensive. Introduces quality loss. Transmuxing repackages the encoded bitstream into a different container format without touching the video pixels. Compute nearly free. No quality loss.
An example: a camera produces H.264 in an RTSP transport. The VMS receives that stream. To deliver it to a browser client over HLS, the VMS needs to package the same H.264 bitstream into fragmented MP4 segments listed in an HLS manifest. That is transmuxing, the H.264 encoded video is passed through unchanged, just repackaged into a different container. To deliver the same stream over WebRTC, the VMS repackages it into RTP payloads with WebRTC-specific handling. Also transmuxing.
If the browser client can decode H.264, no transcoding is required at any stage. The VMS only needs to transcode when the client cannot decode what the camera produced, for example, if the client requires H.264 but the camera produced H.265, or if the client requires a lower bitrate than the camera original.
VMS architectures that transmux by default and transcode only when required deliver better image quality (no generational loss), lower compute cost (transmuxing is nearly free), and better latency (no decode-encode round-trip). This is one of the reasons why native streaming engines like the one in Visylix outperform FFmpeg-based or SRS-based systems on high-camera-count deployments: they treat transmuxing as the primary operation and transcoding as the exception.
The engineering framework for making the decision correctly in a surveillance or streaming system.
Always encode at the camera. No practical system transmits raw video from the sensor. The camera encoder is the only place where raw pixels become a compressed stream. This decision is made when the camera is procured, not at runtime.
Prefer transmuxing over transcoding at the VMS. If clients can play the camera native codec, transmux from the ingest transport (RTSP, ONVIF) into the delivery transport (HLS, WebRTC, MPEG-DASH) without touching the encoded pixels. This preserves quality and minimizes compute cost.
Transcode only when required. The three scenarios that genuinely require transcoding are codec mismatch (client cannot decode the camera codec), bitrate mismatch (client needs a bitrate different from what the camera produces), and resolution mismatch (client needs a resolution different from what the camera produces). Every other case should transmux.
Use hardware transcoding for real-time high-throughput workloads. Live delivery, adaptive bitrate ladder generation, and multi-viewer streams benefit meaningfully from GPU or ASIC transcoding. Use software transcoding for bounded batch workloads. Archive re-encoding, forensic export, and one-time format conversions benefit from software transcoding quality advantage without hitting real-time constraints.
Cap the transcoding compute budget explicitly. Systems that transcode by default and never cap the compute burn CPU, GPU, and cost budget on operations that transmuxing would satisfy. The design pattern that scales is to make transcoding an explicit decision, not a default.
Visylix is built around the principle that transcoding should be the exception, not the default. The native streaming engine transmuxes camera streams from ingest (RTSP, RTMP, ONVIF, GB28181) into delivery transports (WebRTC WHEP/WHIP, HLS/LL-HLS, HTTP-FLV, SRT, NDI, RIST) without decoding the video pixels whenever the client codec matches the camera codec. This preserves original image quality, keeps sub-500ms latency on WebRTC, and lets a single node handle 5,000+ concurrent streams and 1M+ concurrent connections.
When transcoding is genuinely required (a legacy H.264-only client viewing an H.265 camera, an adaptive bitrate ladder for scale-out delivery, a mobile client requiring reduced bitrate), Visylix uses GPU-accelerated hardware transcoding via NVENC and NVDEC on NVIDIA GPUs. Hardware acceleration is engaged only for the streams that require it, and the transcoding compute budget is bounded and observable in the platform metrics.
The 12 self-learning AI models (face recognition, ANPR, object detection, person tracking, crowd detection, PPE detection, heat maps, motion detection, pose estimation, unique person counting, intrusion detection, line crossing) run on the decoded frame stream that the AI inference pipeline extracts from the encoded video without disturbing the streaming path. AI inference and streaming operate on separate processing pipelines so that AI throughput does not compete with streaming latency budgets.
The result is a video pipeline that is meaningfully faster, meaningfully cheaper on compute, and meaningfully higher quality than architectures that transcode by default. Visylix supports H.264 and H.265 codecs on ingest, delivers over 10 streaming protocols (RTSP, RTMP/RTMPS, HLS, LL-HLS, WebRTC WHEP/WHIP, SRT, ONVIF, GB28181, NDI, RIST), and provides 55+ language UI coverage including 13 Indian languages and 4 RTL scripts.
For related architecture questions, see our guides to HLS vs WebRTC, video bitrate for streaming and surveillance, CMAF (Common Media Application Format), HEVC vs H.264, RTMP server setup, and the streaming protocols compared. Visylix is available for evaluation at https://visylix.com/pricing with Starter, Pro, Scale, and Enterprise tiers, USD and INR pricing (Razorpay for Indian customers), and 100 percent on-premise deployment via a Docker image on customer infrastructure. Reach the team at https://visylix.com/contact.
Encoding turns raw video from a sensor into a compressed video stream using a codec (H.264, H.265, AV1, VP9). Transcoding turns an already-encoded video stream into a different encoded video stream, and is compute-expensive because it is decode-plus-re-encode. Transmuxing repackages an encoded stream into a different container format without touching the video pixels, and is nearly free in compute cost with no quality loss. Modern VMS and streaming architectures transmux by default and transcode only when the client codec, bitrate, or resolution requires it. Cameras always encode; VMS platforms should prefer transmuxing over transcoding; delivery layers transcode only for genuine codec, bitrate, or resolution mismatches. Hardware transcoding on GPU (NVIDIA NVENC/NVDEC, Intel Quick Sync, AMD VCN) or dedicated ASIC is the right choice for real-time high-throughput workloads; software transcoding is the right choice for bounded archive or batch workloads where quality per bit matters. Systems that transcode by default burn compute and quality unnecessarily; systems that transmux by default and transcode only when required deliver better image quality, lower compute cost, and lower latency.
Encoding is the process of compressing raw video (uncompressed pixel data from a camera sensor or capture pipeline) into a compressed video stream using a codec such as H.264, H.265, AV1, or VP9. Transcoding is the process of taking an already-encoded video stream and converting it into a different encoded video stream, usually to change the codec, bitrate, resolution, or frame rate. Encoding takes raw video as input; transcoding takes encoded video as input. Every practical video system encodes at the source (usually in the camera or capture device). Transcoding is added only when downstream consumers need a different format than the source produced.
Video encoding is the process of compressing uncompressed video data into a smaller, more efficient format using a codec. Uncompressed video is enormous (a single second of 4K 30 fps raw video is roughly 1 GB), so every practical video system compresses raw video into an encoded stream before storing or transmitting it. Encoders reduce data volume 100x to 1000x by exploiting spatial redundancy (pixels near each other look similar), temporal redundancy (consecutive frames look similar), and perceptual redundancy (the human eye is less sensitive to certain kinds of detail). The output of encoding is a compressed bitstream in a standard codec format (H.264, H.265, AV1, or VP9).
Video transcoding is the process of converting an already-encoded video stream into a different encoded video stream. The transcoder decodes the input stream back into raw video (or a partially decoded intermediate representation), then re-encodes it into an output stream with different properties. Transcoding is required when a downstream consumer needs a different codec, bitrate, resolution, or frame rate than the original encoded source produced. Common transcoding scenarios include converting H.265 to H.264 for legacy player compatibility, generating multiple bitrate variants for adaptive streaming, downscaling high-resolution streams for mobile viewers, and converting between codecs during archive migration.
No. Encoding takes raw video as input and produces a compressed stream. Transcoding takes an already-compressed stream as input and produces a different compressed stream. Transcoding is technically encoding plus decoding, so it is more compute-expensive than encoding alone and it introduces generational quality loss (the re-encoding cannot recover information the first encoding discarded, and it discards more). Encoding happens at the source of the video (camera, capture card, screen recorder). Transcoding happens at intermediate stages of the video pipeline when downstream consumers cannot use what the source produced.
Transmuxing (short for transport muxing) is the process of repackaging an encoded video stream into a different container format without decoding or re-encoding the video pixels. Transmuxing is nearly free in compute cost and introduces no quality loss because the encoded video bitstream is passed through unchanged. Transcoding, in contrast, decodes and re-encodes the video pixels and is compute-expensive with generational quality loss. An example: a VMS receiving H.264 video over RTSP from a camera and delivering the same H.264 to a browser over HLS only needs to transmux (repackage into HLS fragments), not transcode. Transcoding is only required when the camera codec, bitrate, or resolution does not match what the client can play.
Transcoding is required in three scenarios: codec mismatch (the client cannot decode the codec the camera produced, for example a legacy H.264-only client viewing an H.265 camera), bitrate mismatch (the client needs a bitrate significantly different from what the camera produces, for example a mobile client on a cellular connection needing 500 kbps when the camera produces 8 Mbps), and resolution mismatch (the client needs a different resolution than the camera produces, for example a mobile-sized viewport). Any other scenario should be handled by transmuxing, which repackages the encoded stream without decoding or re-encoding.
Software transcoding runs encode and decode operations on the CPU using libraries like FFmpeg's libx264, libx265, or the AV1 encoders. It is flexible, tunable, and produces high-quality output but is compute-expensive at scale. Hardware transcoding offloads the encode and decode operations to specialized silicon such as NVIDIA NVENC/NVDEC blocks on GPUs, Intel Quick Sync Video, AMD VCN, or dedicated video transcoding ASICs from vendors like NETINT. Hardware transcoding delivers roughly 10 to 30 times higher throughput per system and roughly 5 to 10 times better power efficiency than software transcoding but produces output that is 10 to 30 percent less compression-efficient at equivalent quality because the fixed-function silicon supports fewer encoding modes than the best software encoders. Use hardware transcoding for high-throughput real-time workloads and software transcoding for bounded batch workloads where quality per bit matters.
Visylix transmuxes by default and transcodes only when required. When a client can play the camera's native codec and bitrate, Visylix repackages the encoded stream from the ingest transport (RTSP, RTMP, ONVIF, GB28181) into the delivery transport (WebRTC, HLS, LL-HLS, SRT, NDI, RIST, HTTP-FLV, MPEG-DASH) without decoding the video pixels. When a client requires a different codec, bitrate, or resolution than the camera produces, Visylix uses GPU-accelerated hardware transcoding via NVIDIA NVENC and NVDEC to convert only the streams that require conversion. This transmux-first architecture preserves original image quality, minimizes compute cost, and maintains sub-500ms WebRTC latency on high-camera-count deployments.
For most modern surveillance deployments, H.265 (HEVC) is the best choice on newer camera hardware. It provides roughly 40 to 50 percent better compression than H.264 at equivalent visual quality, which meaningfully reduces storage cost and bandwidth cost for high-resolution or high-frame-rate footage. H.264 remains the safer choice for maximum compatibility with legacy players, older NVRs, and low-power viewer clients. AV1 is emerging in archive workflows where the storage savings justify the higher encoding cost. The right approach for a mixed environment is to record in the camera's most efficient codec (usually H.265) and transcode to H.264 only for the specific clients that require it, using GPU acceleration to bound the compute cost.
Software H.264 encoding runs on the order of 30 to 200 frames per second per CPU core depending on preset (fast, medium, slow) and resolution (720p, 1080p, 4K). Hardware transcoding on NVIDIA NVENC runs on the order of 1000 to 4000 frames per second per accelerator depending on codec and quality preset, with a modern data center GPU handling 30 to 100 concurrent 1080p 30 fps streams. The right sizing depends on the codec (H.265 is more expensive than H.264, AV1 is more expensive than H.265), the quality preset (higher quality means slower), the resolution and frame rate, and whether the workload is real-time or batch. For real-time surveillance transcoding at scale, hardware acceleration is essentially mandatory; software transcoding is impractical above a few dozen streams.