...

$> apt update

Installation de nginx

$> apt-get -t stretch-backports install nginx

...

...
THIRD_PARTY_APPS = ["xxx","xxx","live"]
...

Gérer le pilotage du direct et la gestion des enregistrements

Il faut d'abord ajouter le type de type de matériel pour matériel pour le streaming dont vous disposez (2 choix actuellement).

Cela limitera les choix dans l'admin du site

...

Ensuite il faut se rendre dans l'administration de Pod , :

• créer un bâtiment
• puis un diffuseur rattaché à ce bâtiment en précisant l'url de lecture du flux de direct

...

Important, selon le type de matériel choisi vous devrez préciser la configuration en json (dans "Paramètres de configuration du pilotage").
La liste des paramètres à déclarés est proposée lorsque l'on sélectionne un type de matériel.

Voici un exemple de configuration pour les deux matériel supportés.
Cela permet de piloter le démarrage et l'arrêt de l'enregistrement.

# exemple pour WOWZA:   
{
"server_url":"http://stream01.univ.fr:8087",
"application":"rec_salles_video",
"livestream":"sallevideo.stream"
}

# exemple pour SMP: 
{
"server_url":"http://255xxx.255xxx.255xx.1x", 
"sftp_port":"22022", 
"user":"compte_admin", 
"password":"mdp_admin", 
"record_dir_path":"/recordings", 
"rtmp_streamer_id":"1", 
"use_opencast":"trueOrFalsetrue" 
}

 avec WOWZA:

ici Ici le fileSystem sur lequel est stocké le fichier vidéo doit être commun entre Wowza et Pod.

Le paramétrer dans le "DEFAULT_EVENT_PATH" du fichier settings_local.py

 avec SMP Extron:

si vous utilisez des SMP vous SMP vous pouvez récupérer le fichier vidéo issue d'un évènement (live) de 2 manières :

...

récupération via SFTP 

Pod se connecte au serveur SMP pour récupérer le fichier vidéo et l'encoder en tant que vidéo liée à l'évènement).

...

• vérifier que le port est bien déclaré et ouvert entre les 2 serveurs
• "use_opencast" doit être à false
• "rtmp_streamer_id" peut être vide

...

récupération via le

...

module openCast (studio) (A partir de 3.7.0)

Le SMP, s'il dispose de la fonctionnalité de push (modèle Extron 351 par exemple), envoie directement le fichier dans le studio de Pod qui va l'encoder et le lier à l'évènement.

...

• "use_opencast" doit être à "true"
• "sftp_port" peut être vide
• "rtmp_streamer_id" doit être correctement défini 
• "rtmp_streamer_id" doit être correctement défini 

Pour connaître le 'rtmp_streamer_id', vous pouvez appeler l'url suivante de votre SMP et voir quel streamer est configuré en rtmp (dans le 'pub_url') : 

http://xxx.xxx.xx.x/api/swis/resources?uri=/streamer/rtmp/1&uri=/streamer/rtmp/2&uri=/streamer/rtmp/3&uri=/streamer/rtmp/4&uri=/streamer/rtmp/5&uri=/streamer/rtmp/6

Vous devez aussi Vous devez ajouter un Enregistreur (Recorder) dans l'admin de Pod avec l'Ip du SMP (définir un Salt, Login, Password)

...

• 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. 

...