# Introduction

Media Server can send records to another Media Server for further processing. For example, you can run face detection on one Media Server and then send the records describing detected faces to another Media Server that runs face recognition.

In this architecture, the Media Server that ingests the source media is referred to as the "upstream" server, and the Media Server that you send records to is referred to as the "downstream" or "remote" server.

This feature, called chaining, can be useful in cases where:

- The downstream server is equipped with hardware, such as a graphics card, that enables it to perform some types of analysis much faster than the upstream server(s). Chaining can help you make best use of your hardware.
- The downstream server has access to resources, such as face databases, that are not available to the upstream server(s).

Consider a scenario where you want to run face detection and recognition on the video recorded by ten cameras. You could have several Media Servers ingesting video and running face detection. You could then send all of the detected faces to a single Media Server that is equipped with a GPU and has access to your face recognition databases. Face recognition is much faster when performed with a GPU, so with this configuration you only need a single Media Server to perform the face recognition step.

NOTE: Audio data cannot be transferred between Media Servers. This means that you cannot run analysis operations such as language identification, speaker identification, and speech-to-text on a downstream Media Server. The rolling buffer encoder cannot be used on a downstream Media Server, and other encoding engines can be used only if you set `AudioInput=none`.

Transferring data between Media Servers involves some overhead, so chaining performs best when the amount of data transferred between the servers is small and the downstream Media Server performs resource-intensive analysis tasks. In the previous scenario, the upstream Media Server sends images of detected faces to the downstream server so that they can be identified. You should configure each upstream server to send only the best frame for each detected face, rather than every frame in which a face appears. You should also crop the images before sending them, so that each image includes only a detected face and not the entire scene. This significantly reduces the amount of data that is transferred between the servers.

If your use case requires only a moderate amount of analysis to be performed by the downstream Media Server, or the downstream Media Server requires a large proportion of the data that is ingested upstream, it can be more efficient to do all of the analysis on a single server.

There are two ways to configure chaining: one-way chaining and feedback chaining. The following table describes the differences between these configurations.

Feature | One-way chaining | Feedback chaining
--- | --- | ---
Licensing | A visual channel on the downstream server is required for each `process` action running upstream. (When you start processing on the upstream server, a processing session also begins on the downstream server. This remains active until all processing has finished). | A visual channel on the downstream server can handle requests from several `process` actions running upstream, but requests from upstream servers must wait if more requests are received than visual channels are available. (Each processing session on the downstream server processes a single record. A processing session exists on the downstream server only while a record is being processed).
Architecture | The upstream Media Server sends records to the downstream server, and processing continues on the downstream server. Information is not returned to the upstream server. Configure your output tasks on the downstream server. (If you configure a response output task on the downstream server, the information is returned to you by the upstream server because you do not receive a response from the downstream Media Server). | The upstream Media Server sends records to the downstream server, which performs analysis and returns the results so that processing can continue on the upstream server. Configure your output tasks on the upstream server.
Media Server sends all records to the downstream server as soon as they are ready to be processed. Tracking and integration work as you would expect on a single server. | Media Server sends one record to the downstream server, and waits for it to be analyzed and the results to be returned before sending another. This means that records are considered to be independent. Feedback chaining is therefore unsuitable when analysis depends on tracking and integration (analyzing many frames to produce a single result). An example of an analysis task that depends on tracking and integration is number plate recognition (ANPR). You can use analysis engines on the downstream server that have tracking capabilities, but these capabilities provide no benefit and tracking results are not available.
You can send multiple tracks to the downstream server. | You can send only one track to the downstream server.
Configuration | The upstream Media Server sends records downstream using the `Post` output engine. The downstream server receives them using the `Receive` ingest engine. | The upstream Media Server sends records downstream using the `RemoteAnalysis` analysis engine. The downstream server receives them using the `Receive` ingest engine.

To divide processing between two servers, you must create two configurations. The configuration for the downstream Media Server must be saved in the folder specified by the `ConfigDirectory` parameter in the `[Paths]` section of the configuration file (on the downstream Media Server that you are sending records to). You cannot include the configuration for the downstream server in the `process` action you send to the upstream server.

_FT_HTML5_bannerTitle.htm