...
| Bloc de code |
|---|
$> apt update |
Installation de nginx
| Bloc de code |
|---|
$> apt-get -t stretch-backports install nginx |
...
| Bloc de code |
|---|
$> apt-get install libnginx-mod-rtmp |
...
| Bloc de code |
|---|
$> vim /etc/nginx/snippets/rtmp.conf |
Fichier rtmp.conf originel
Ci-dessous le fichier de configuration originel qui utilise 3 encodages et n'est pas spécialement optimisé vis-à-vis de la latence (il faut compter entre 15 et 30 secondes de latence avec cette configuration) :
...
Cette configuration est largement éprouvée dans le temps, mais fait consommer plus de ressources (3 encodages) avec une certaine latence au final.
Fichier rtmp.conf optimisé pour réduire la latence
Ci-dessous le même fichier de configuration qui utilise 2 encodages et qui est spécialement optimisé vis-à-vis de la latence (il faut compter moins de 10 secondes de latence avec cette configuration) .
...
...
Si votre frontal POD est en HTTPS il faut configurer Nginx sur le serveur live pour servir du HTTPS et non du HTTP
...
Mise en place du comptage des spectateurs (A partir de 2.7.0 et supérieur)
Pod inclut une fonction qui permet de compter les spectateurs sur un direct en temps réel.
...
Ajouter une tâche CRON périodique (chaque minute recommandé, mais il est possible d'augmenter ou de diminuer le temps et régler les settings sur pod en conséquence (voir les points suivants ...) :
Info title Commande du CRON bash -c 'export WORKON_HOME=/home/%userpod%/.virtualenvs; export VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3.6; cd /home/%userpod%/django_projects/podv2; source /usr/local/bin/virtualenvwrapper.sh; workon django_pod; python manage.py live_viewcounter'
ATTENTION : Il est possible que vous ayez à modifier cette commande suivant vos chemins d'installation de POD.
- Réglez le setting VIEWERS_ONLY_FOR_STAFF, celui-ci prend les valeurs True ou False et permet de définir si la liste des spectateurs (disponible en appuyant sur l'oeil) est accessible à tous ou uniquement aux membres du personnel.
- Réglez le setting HEARTBEAT_DELAY, celui ci permet de définir le délai entre lequel un client va remonter son "signal" au serveur. Il est par défaut fixé à 45 secondes.
Réglez le setting VIEW_EXPIRATION_DELAY, il permet de définir le délai maximum pour lequel une vue va encore considérée comme présente sur le direct.
Info title Explication ! Afin de mieux comprendre ces notions de délais voici un exemple avec les paramètres par défaut : Le client (le terminal sur lequel l'utilisateur est en train de regarder le direct) va remonter un signal au serveur pod de manière périodique toutes les 45 (HEARTBEAT_DELAY) secondes. Chaque minute (temps du CRON), une tâche vérifie la validité de chaque spectateur pour déterminer si il est encore présent sur le direct. Pour cela, elle élimine tout les spectateurs qui n'ont pas remonté de signal depuis 60 (VIEW_EXPIRATION_DELAY) secondes.
A noter : Il est laissé la possibilité de modifier les délais pour pallier à d'éventuelles pertes de performances à cause de la remontée des vues. Si vous rencontrez des difficultés à ce niveau, n'hésitez pas à doubler les délais. Le comptage sera moins précis en temps réel mais vous gagnerez en nombre de requêtes.
...