In video workflows (and audio too) the encoder is a logical building block that combines packetization and compression to convert a source video of one format into a distributable video format of another. It may be that the source is acquired from file or captured from a frame-grabber (which literally takes each frame of video and places it into the computer's memory), and then the stream of video frames is (typically) passed into a compression CoDec, with the resulting output then usually being wrapped in a transport format (for example, MPEG-TS) and finally multiplexed (“muxed”) into the delivery format (for example, RTMP or HLS).
Where the input to the encoding process can be facilitated over an IP network, rather than (for example) through a video capture card, meaning the source video is already in some form of suitable transport and delivery format for the encoder to acquire, and where the stream is recompressed then the service is usually termed “transcoding.”
Similarly “trans-muxing,” “trans-rating” and “re-packaging” all perform parts of this process with nuances that become more and more specific, but that all are subsets of the broad “encoder” model.
Live video encoders are typically connected directly to a non-IP camera source, and encode that source for IP workflows, and as a result are usually physically co-located with customers' production facilities. The transcoders and other “trans” features are, however, features that may be placed inside the networks and performed wherever there is suitable connectivity and resources.
Accordingly CDNs have increasingly baked into their network the capability to take a single-source stream from a customer and deliver the content in many bitrates and formats. This is common in all the major CDNs, and there are also some independent SaaS providers that can provide these services, particularly for on-demand archive library transcoding - viz-a-viz encoding.com, for example.
Over time encoding has become a SaaS model offered as a service by CDNs to their customers, which also tends to “clean up” the contribution feed, making the distribution role easier - the “garbage in-garbage out” reality that CDNs face traditionally impacted CDN's brand. Until virtual encoding and transcoding, etc., evolved, the CDNs were compromised if a client contributed a poor stream and it appeared that the CDN was responsible for it. This has led to a number of CDNs integrating such features - however, at this point in time most still prefer their client to take on the responsibility, and where they do, they offer such encoding in a few network centres and deliver all the variety of the outputs across their backbones.
A better architecture would be to try to deliver a single high bitrate mezzanine out to transcoders at the edges where the many varied options can be created much nearer to the audiences that actually want them.
Again, this is a change in architecture to plan for over the next few years as increased service velocity accelerates a trend toward optimization.