Transcoders vs Encoders: What’s the difference?
In today’s video market, I hear the words transcode and encode interchanged all the time. Although they both produce a compressed video file, there are some subtle differences between the two words that are worth exploring.
First some basics.
A video file can be sized differently depending on the number of distinct pixels in each dimension that can be displayed (width ´ height) along with the number of frames that are played per second. A video file needs to be encoded and compressed at some point along the distribution cycle as files are generally too large in raw format to be transferred as is.
When you encode a video file, the video or audio format is changed from an uncompressed, un-encoded format to a compressed encoded format. This is accomplished by using a hardware or, more typically, a software codec. When you transcode a video file, on the other hand, the file converts video or audio from one compressed encoded format to another compressed encoded format.
All devices have decoders that are able to read the compressed format and to decompress the video file so it can be displayed. The decoder is able to do this as the compressed video format follows a standard such as MPEG-2, H.264, VP9, etc.
Additionally, video files are stored within a container format which is a wrapper around the video and audio data that provides information about the file and can contain multiple video and audio streams. Some example container formats are mp4, mov, avi, and ogg.
Transmuxing is yet another term used in the industry and changes only the container format but not the underlying file.
So when do you use encoding, transcoding, or transmuxing? It depends on what you are trying to achieve and where you are on the distribution chain.
Encoding is used when the video is first created and is transferred off the device. For example, a video taken on a smart phone will be encoded prior to being transferred to YouTube. Once the video is uploaded to YouTube it is then transcoded to different resolutions and different formats. Both of these use an encoder to do the actual compression of the file being distributed.
Transmuxing, on the other hand, does not compress the video at all, but only changes the packaging. For example, many companies may want to share existing mp4 files through HTTP Live Streaming. In order to do this, the format of the file must be stored within an MPEG-2 transport stream. In this case, only the container format is being adjusted.
Video demand continues to grow, and with that growth comes additional demand for transcoding services. The explosion of video on demand and the increase in live sporting event viewing in HD are keeping the transcoding services very busy. Not only do those services need to contend with encoding a video in multiple formats, resolutions, and bitrates, but they also have to deal with the different types of viewing (on-demand or live). One thing, though, is constant: the need for a well-performing encoder.
So while the technical difference between encoding and transcoding is that encoding starts with an uncompressed file and transcoding starts with an already compressed file, they both need an encoder that can compress well.
In practice, encoding a raw file allows much greater compression than transcoding an already-compressed file. If a file has already been compressed, the amount of additional compression that can be achieved on it is naturally less. In many transcoding applications, the video content provider must compress an already-compressed video even further to satisfy network bandwidth constraints (and often with an additional real-time requirement). As a result, transcoded files at low bitrates often show poor quality because video quality has been traded off to achieve the low bitrates. Thus, it is important for the encoder to perform well (achieve decent quality) at low bitrates for transcoding applications, whereas good encoder performance (excellent quality) at high bitrates is more important for other applications such as video-on-demand.
Where Our Technology Fits
We’re often asked where our software fits into the process, and the short answer is “wherever a file is being encoded or transcoded” – any place where compression and/or image quality are important. Our software integrates into existing encoders to improve compression while preserving image quality.
Standard encoding specifications such as MPEG-2, H.264, and HEVC achieve compression through a combination of predicting “current” data to be encoded and transforming the residual signal to minimize encoding cost. Accurate prediction reduces the magnitude of the residual signal, making the job of all downstream steps (transform, quantization, variable length encoding) easier.
Our technology works within the encoder to overcome the intrinsic limitations of standard encoding without interfering with those downstream steps.
If you liked this blog post from Richard, subscribe to our blog for instant updates on new posts like this.