The runner downloads the video file from the url set in the paylaod
of a transcoding job. This url is pointing to our API and the runner
will make POST request to it with an jobToken and a runnerToken.
Doing this ensure we can verify the tokens and return the video file.
But returning the video file also means that we are using server
resources to serve the file. If the runner is able to follow the
redirect, we can do our usual verification and return a redirect
response to the url of the video file, the runner will download it
using his own resources.
More efficient than the current one where instance is not fast enough to
send all viewers if a video becomes popular
The new protocol can be enabled by setting env
USE_VIEWERS_FEDERATION_V2='true'
Introduce a result field in View activity that contains the number of
viewers. This field is used by the origin instance to send the total
viewers on the video to remote instances. The difference with the
current protocol is that we don't have to send viewers individually to
remote instances.
There are 4 cases:
* View activity from federation on Remote Video -> instance replaces
all current viewers by a new viewer that contains the result counter
* View activity from federation on Local Video -> instance adds the
viewer without considering the result counter
* Local view on Remote Video -> instance adds the viewer and send it to
the origin instance
* Local view on Local Video -> instance adds the viewer
Periodically PeerTube cleanups expired viewers. On local videos, the
instance sends to remote instances a View activity with the result
counter so they can update their viewers counter for that particular
video