There are basically two kinds of transcoding interface, the one that originally showed up in Xtrend receivers, but now also can be found in Mut@nt and Zgemma receivers, which Wanwizard calls here "xtrend" style, but I'd rather call it "enigma" style, because the complete interface is inside enigma itself, with a patch from the Xtrend developers at the time. The other interface was first found in VU+ receivers, which WanWizard therefor calls "vu+" style, but which I call "broadcom" style, because apparently it's supplied this way by Broadcom in their SDK. All other vendors are using this interface.
For the "enigma" style interface you don't need an external interface, the handling of fetching the stream from the demux and pushing it into the encoder is done inside the driver and enigma only needs to fetch the encoded stream from the encoder. For the "broadcom" style, we need to have enigma tune to the service, set up the demux, fetch the raw data from there, push it into the encoder and then fetch it from the encoder's output. This in theory could have been integrated into enigma itself, but I am not enough familiar with enigma to do that, so I made the code into a separate binary. If there are volunteers, please step forward, it would be appreciated.
The machines marked as "broadcom" style transcoding have the streamproxy installed and started automatically. The other transcoding capable machines have the streamproxy in the feed, so the users can install it themselves if they want to. The streamproxy does support "enigma" style machine as well, but not natively, it just forwards the session to enigma. The reason why this may be useful is because some smartphone apps do support the "broadcom" style interface and not always the "enigma" style transcoding. Also, it supplies a universal interface to all transcoding capable machines.
Without using streamproxy, "enigma" style machines support transcoding by adding a few parameters to a normal streaming request, on port 8001.
Streamproxy by default (configurable...) listens on port 8002 and 8003, where by default, requests are handled as transcoding requests. Using both port 8002 and 8003 is a historic compatibility thing, where the original VU+ "transtreamproxy" required live trancoding requests to be on 8002 and file transcoding requests on 8003. Streamproxy does not enforce that, both ports act the same way.
In compatibility mode (usually used), only a serviceref is passed and depending on the configuration, that service is transcoded (service can be live or file). There is also a native mode where, on any of all configured ports, you can explicitly request for streaming, transcoding, live or file. This is the preferred interface, but nobody is using it.
So, now you know everything.