Skip to content

Home

Jump to bottom
Cyril Duchon-Doris edited this page May 30, 2020 · 6 revisions

Concepts

  • user action
  • watcher state
  • sync intent
  • sync state
  • sync command

user action

Une action utilisateur explicite (click sur le bouton play/pause, clic sur la barre temporelle pour “seek”). Cette action entraine une modification du watcher state. Ces actions ne devraient (presque) JAMAIS être communiquées au serveur, car elles ne suffisent pas à décrire l’état du système. Dans ce cas en revanche, elles peuvent exprimer une intention de synchronisation (cf sync intent)

Valeurs : PLAY/PAUSE/SEEK

watcher state

Par défaut à “inconnu” lors du bootstrapping de l’extension et de la création de la room. le watcher state correspond à l’état de visionnement/chargement de la vidéo d'un watcher, et toutes ses mises à jour devraient être notifiées au serveur via websocket, et le serveur devrait recopier ces valeurs bêtement sans les changer (mais avec qqs subtilités en +, par exemple un flag qui indique si le watcher est en sync ou pas)

Valeurs proposées : UNKNOWN/BUFFERING/READY/PLAY_SCHEDULED/PLAYING (default: UNKNOWN)

Contient toujours :

  • info de la timestamp de la vidéo
  • heure locale de l'utilisateur

sync intent

Représente l’état souhaité de la synchronisation vidéo par l'owner de la vidéo.

Valeurs proposées : PLAY/PAUSE (default: PAUSE)

sync state

L’état qui caractérise le mieux possible l'état de la synchronisation vidéo. La grosse différence, est que par exemple, on pourrait avoir reçu l’info que tous les watchers sont READY, mais pour autant on ne veut pas démarrer la vidéo (donc PAUSED).

Valeurs proposées : PAUSED/(WAITING/PLAY_SCHEDULED)/PLAYING (waiting et play scheduled sont ~les mêmes et pourraient être rassemblées) (default: PAUSED)

Contient

  • Quel que soit le state : URL vidéo
  • Si en PLAY_SCHEDULED/PLAYING : info de la timestamp à laquelle le démarrage la vidéo est/a été schédulée et l'heure UTC correspondante
  • Un numéro de version qui servira à invalider des commandes (défaut: 0)

sync commands

Un ordre fourni par le serveur, donc le but est de synchroniser les watcher states ET le sync states selon les intentions utilisateur.

Valeurs proposées : SCHEDULE_PLAY/PAUSE/CHANGE_VIDEO

Précautions

  • Une sync command doit toujours être envoyée APRES mise à jour du sync state + intent
  • Avant qu'un sync command soit envoyée, le numéro de version de la room doit être changé et indiqué dans la commande
  • Après qu'une sync command soit envoyée, les watchers doivent envoyer notif de state via le bon numéro de version

A noter

  • Quand un friend rejoint une room, son browser devrait avoir uniquement besoin du sync state + sync intent pour décider de quoi faire et essayer de rejoindre les autres.

Flows

  • play / syncPlay
  • pause
  • seek
  • join room in sync play / catch-up

Concernant le “play”

  1. Un utilisateur clique sur “play” de youtube --> 2cas.

    a. Soit la vidéo joue direct (ce qui veut dire qu’on avait en réalité bien buffer la vidé / on était en ready) --> il faut annuler le play() et envoyer au serveur que le watcher est dans le statut watcher:READY

    b. Soit la vidéo ne joue pas direct (ce qui veut dire qu’on est en train de buffer) --> il faut envoyer au serveur qu’on est en watcher:BUFFERING. Puis, une fois que la vidéo se lance, on retombe dans 1a

Si tout le monde a synchronisé un état “READY” et que le sync intent est ou devient "PLAY" :

  1. Le serveur envoie une commande cmd:SCHEDULE_PLAY et passe en syncState:PLAY_SCHEDULED, et il indique via un flag au niveau des watchers, quels sont ceux qui sont censés commencer le sync play
  2. Les watchers mettent leur état en watcher:PlayScheduled afin d'acknowledge la commande SchedulePlay. On pourra peut-être avoir un feedback sur le content script (genre un 5..4..3..2..1)

Une fois que la vidéo est censée se lancer

  1. Les browsers déclenchent réellement la vidéo, et envoient un évènement websocket pour confirmer que la vidéo a bien été lancée (état watcher:PLAYING)
  2. lorsque le serveur reçoit suffisamment de watcher:PLAYING, alors il bascule en syncState:PLAY_SCHEDULED. Sinon, alors [TBA]

Cas particulier de l'owner de la vidéo.

Si l'owner de la vidéo clique sur le bouton play, alors cela doit switcher le sync intent en play/pause (en essayant d'être le plus logique possible, cf cas du buffering VS play, etc)

Concernant le pause

  1. Un utilisateur clique sur “pause” chez lui
    • Dans tous les cas, la vidéo est mise en pause immédiatement en local,
    • On envoie une mise à jour de state en watcher:PAUSED au serveur. Le serveur réinitialise le flag de synchronisation de ce watcher au besoin si ce n'est pas l'owner
    • Le serveur ne change rien à l'intent ni son état, SAUF si tout le monde est passé en paused/unknown

Si celui qui a envoyé la mise à jour de state est l'owner

  1. Le server envoie la commande PAUSE aux watchers et change le sync intent en PAUSE
  2. les autres browsers reçoivent la commande , et essaient de basculer ASAP en watcher:PAUSED tout en seekant

Concernant le seek

Si un utilisateur seek la vidéo et n'est pas l'owner, alors cela doit update sont statut en watcher:UNKNOWN

SI l'utilisateur est l'owner

  • Un évènement spécial est envoyé depuis l'owner au serveur (route dédiée) qui aura pour effet de
    • incrémenter un numéro de version sur le syncState
    • Repasser TOUS les watchers en watcher:UNKNOWN, et refuser tt mise à jour de watcher qui ne fournirait pas le bon numéro de syncState à jour
  • Le serveur envoyer une commande PAUSE, qui doit déclencher la MAJ du numéro de version, et doit indiquer les références du seek.
  • Suite à la réception de cet event, les clients doivent resyncer leur état

Communications

  • Popup --> background script (change room, etc)
  • Content Script --> Background script (intercept video player events, video player state)
  • Background script --> Popup/Content script (room joined, syncPlay)
  • Extension (BG script) --> Server (joinRoom, updateWatcherState, getRoom, updateSyncIntent)
  • Server --> BG Script (syncCommands)
Clone this wiki locally