(Nästan) värdelös streaming av webbkamera från webbläsaren. Del 2. WebRTC

En gång i en av de gamla och redan övergivna artiklarna skrev jag om hur enkelt och avslappnat man kan strömma video från canvas via websockets. I den artikeln pratade jag ytligt om hur man fångar video från kameran och ljud från mikrofonen med hjälp av MediaStream API, hur man kodar den erhållna strömmen och skickar den via websockets till servern. Men i verkligheten gör man så inte; för strömningar används antingen speciell mjukvara som måste installeras och konfigureras: på rak arm kan detta vara Open Broadcast Software, eller så används WebRTC, som fungerar direkt ur lådan, det vill säga som inte kräver installation av några plugins som Flash Player, som i december tas bort från Chromium-webbläsaren.

I dag ska vi prata om WebRTC.

Web Real-Time Communication (WebRTC) är inte en enda protokoll, utan en hel samling standarder, protokoll och JavaScript API:er som tillsammans möjliggör peer-to-peer video- och ljudkommunikation i realtid, och som också kan användas för att överföra alla typer av binära data. Vanligtvis fungerar webbläsare som peers, men det kan också vara en mobilapp, till exempel. För att organisera p2p-kommunikation mellan klienterna krävs att webbläsaren stöder olika typer av videouppspelning och ljudkodning, samt stöd för många nätverksprotokoll och säkerställer att hårdvaran fungerar med webbläsaren (via OS-lager): webbkameror, ljudkort. All denna teknik är dolt bakom JavaScript API:er för utvecklarens bekvämlighet.

Allt sammanfattas till tre API:er:

• MediaStream API — som vi diskuterade förra gången, jag kommer idag att skriva lite mer om det. Det används för att få video/audio-strömmar från "hårdvaran"

• RTCPeerConnection — möjliggör kommunikation mellan två klienter (p2p)

• RTCDataChannel — används för att överföra godtyckliga data mellan två klienter

Förberedelse av ljud- och videoströmmar för överföring

Allt börjar med "fångsten" av medieströmmarna från webbkamera och mikrofon. Råa strömmar passar självklart inte för att organisera videokonferenser; varje ström måste bearbetas: förbättra kvaliteten, synkronisera ljud med video, sätta synkroniseringsmarkeringar i videoströmmen och säkerställa att bithastigheten motsvarar den ständigt förändrade bandbredden. Allt detta hanteras av webbläsaren, så utvecklaren behöver inte ens tänka på att säkerställa kodning av medieströmmarna. Inuti en modern webbläsare finns det redan programskikt för fångst, kvalitetshöjning (ta bort eko och brus från ljudet, förbättra bilden), samt kodning av video och ljud. Skissen av skikten visas i figur 1:

Figur 1. Skikt för ljud- och videobearbetning i webbläsaren

All bearbetning sker direkt i webbläsaren, inga extra plugins krävs. Men det är fortfarande inte helt ljust 2020. Det finns webbläsare som fortfarande inte fullt ut stöder MediaStream API, du kan gå till länken och titta längst ner på kompatibilitetstabellen. Speciellt IE överraskar igen med besvikelser.

Med de erhållna strömmarna kan man göra mycket intressanta saker: man kan klona, ändra videoupplösning, manipulera ljudkvalitet, man kan ta och "koppla" Media Stream-strömmen till

https://jeeliz.com/ — killarna jobbar med realtids-CV på Javascript. De har ett helt arsenal av olika js-bibliotek för att arbeta med videoströmmar på canvas: ansikts- och objektdetektering, applicering av filter (masker, som på Instagram) osv. Ett utmärkt exempel på hur man utan extra plugins kan bearbeta video i realtid direkt i webbläsaren.

Canvas captureStream API — API-dokumentation för att fånga videoströmmen från canvas. Redan stöds i Chrome, Opera och Firefox.

RTCPeerConnection

Nu har vi kommit till frågan; hur ska man egentligen skicka video till en annan användare? Först och främst träder RTCPeerConnectionOm man ska vara kortfattad, så behöver ni i stort sett skapa ett RTCPeerConnection-objekt vid det här steget:

const peerConnection = new RTCPeerConnection({
  iceServers: [{
    urls: 'stun:stun.l.google.com:19302'
  }]
});

En av alternativen är att ange iceServers – det här är servrar som hjälper till att säkerställa anslutningen mellan två webbläsare som befinner sig bakom NAT. Med andra ord, hur vet man IP-adressen till sin kontakt om denne är bakom hans internetleverantörs NAT? ICE-protokollet kommer till hjälp. För övrigt, ICE hör egentligen inte till WebRTC, men mer om det senare.

Tidigare fick vi Usermedia-strömmar:

navigator.mediaDevices.getUserMedia({ video: true, audio: true }).then(stream => {
  // Usermedia-strömmar, vanligtvis video och ljud 
  const tracks = stream.getTracks();

   for (const track of tracks) {
     // varje spår kopplas till peerConnection
     peerConnection.addTrack(track);
   }
}).catch(console.error);

Därefter aktiveras händelsen onnegotiationneeded på peerConnection, där vi i händelsehanteraren måste skapa ett offer (i SDP-termer – Session Description Protocol) och tilldela det i peerConnection via metoden setLocalDescription. Vi kommer att diskutera SDP, vad det är och om formaten offer och answer senare.

Efter att LocalDescription har tilldelats peerConnection samlar webbläsaren ice-kandidater, vilket innebär att den hittar olika vägar för kommunikation genom NAT. Händelsen onicegatheringstatechange aktiveras. I händelsehanteraren för onicegatheringstatechange tillåter vi anslutning till webrtc-signaling-servern för att utbyta session description mellan peer-enheterna:

peerConnection.oniceconnectionstatechange = (event) => {
      console.log('Connection state: ', peerConnection.iceConnectionState);

      if (peerConnection.iceConnectionState === 'connected') {
        // Можем активировать кнопку Start broadcast
        setBroadcasting(true);
        setBroadcastingBtnActive(true);
      }
    };

// Событие срабатывает сразу, как только добавился медаиапоток в peerConnection
peerConnection.onnegotiationneeded = (event) => {
      // Создаем и назначаем SDP offer
      peerConnection.createOffer().
        then((offer) => peerConnection.setLocalDescription(offer)).
        catch(console.error);
    };

// Событие срабатывает каждый раз, как появляется ICE кандидат
peerConnection.onicegatheringstatechange = (ev) => {
      let connection = ev.target;

      // Now we can activate broadcast button
      if (connection.iceGatheringState === 'complete') {
        let delay = 50;
        let tries = 0;
        let maxTries = 3;

        let timerId = setTimeout(function allowStreaming() {
          if (isOnline) {
            setBroadcastingBtnActive(true);
            return;
          }

          if (tries < maxTries) {
            tries += 1;
            delay *= 2;
            timerId = setTimeout(allowStreaming, delay);
          } else {
            // TODO: show user notification
            console.error("Can't connect to server");

            alert("Can't connect to server");
          }
        }, delay);
      }
    };

webrtc-signaling-servern är en server som är nödvändig för att säkerställa att session description överförs mellan båda peer-enheterna, detta kan vara en enkel websocket eller en xhr-server skriven i valfritt programmeringsspråk. Dess uppgift är enkel: att ta emot session description från en peer och skicka den till den andra.

Efter utbytet av Session descriptions är båda parter redo att sända och ta emot videoströmmar. När sidan som tar emot videoströmmen tar emot händelsen ontrack på peerConnection, kan vi i händelsehanteraren tilldela de mottagna spåren till

Länkar och litteratur:

https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection — dokumentation RTCPeerConnection

https://github.com/pion/webrtc — implementering av WebRTC-protokoll på Go

https://webrtcforthecurious.com/ — en bok från skaparna av pion

https://hpbn.co/ — boken High Perfomance Browser Networking. I detalj behandlar den frågor som rör hög prestanda för webbapplikationer. I slutet beskrivs WebRTC. Boken är förstås gammal (2013), men förlorar inte sin aktualitet.

I nästa del vill jag ge lite mer teoretisk bakgrund och praktiskt gå igenom hur man tar emot och bearbetar videoström på servern med hjälp av pion, samt transcoding i HLS via ffmpeg för att sedan sända till tittare i webbläsaren.

För de otåliga: min mycket råa prototyp för videoöverföring från webbkamera via server baserad på pion till twitch (detta är bara ett experiment).

Källa: habr.com