Frontend WebRTC medijos derybos: kodekų parinkimo algoritmo iššifravimas

Dinamiškame realaus laiko komunikacijos (RTC) pasaulyje WebRTC yra esminė technologija, leidžianti „peer-to-peer“ garso, vaizdo ir duomenų kanalus tiesiogiai interneto naršyklėse. Kritinis, tačiau dažnai sudėtingas aspektas, kuriant šiuos ryšius, yra medijos derybų procesas, ypač painus kodekų parinkimas. Šis procesas užtikrina, kad abi WebRTC skambučio šalys galėtų suprasti ir atkurti keičiamus medijos srautus. Frontend programuotojams giluminis šio algoritmo supratimas yra nepaprastai svarbus kuriant patikimas, aukštos kokybės ir universaliai suderinamas RTC programas.

Pagrindas: sesijos aprašymo protokolas (SDP)

WebRTC medijos derybų pagrindas yra sesijos aprašymo protokolas (SDP). SDP – tai tekstinis formatas, naudojamas multimedijos sesijoms aprašyti. Jis nėra skirtas pačios medijos perdavimui, o veikiau tų sesijų galimybių ir parametrų komunikacijai. Kai du „peers“ (dalyviai) inicijuoja WebRTC ryšį, jie apsikeičia SDP pasiūlymais ir atsakymais. Šiame apsikeitime detalizuojama:

• Siunčiamos medijos tipai (garsas, vaizdas, duomenys).
• Kiekvienam medijos tipui palaikomi kodekai.
• Tinklo adresai ir prievadai medijos siuntimui bei gavimui.
• Kiti sesijai specifiniai parametrai, pvz., šifravimas, pralaidumas ir kt.

Kodekų parinkimo algoritmas veikia šiame SDP apsikeitime. Kiekvienas dalyvis praneša apie savo palaikomus kodekus ir, po derybų serijos, jie pasiekia bendrą kodekų rinkinį, kurį abu gali naudoti. Čia ir kyla sudėtingumas, nes skirtingos naršyklės, operacinės sistemos ir aparatinė įranga gali palaikyti skirtingus kodekus su skirtingu efektyvumo ir kokybės lygiu.

Kodekų supratimas WebRTC kontekste

Prieš gilinantis į parinkimo algoritmą, trumpai apibrėžkime, kas yra kodekai ir kodėl jie yra tokie svarbūs:

• Kodekas (koduotojas-dekoderis): Kodekas yra įrenginys arba programa, kuri suspaudžia ir išskleidžia duomenis. WebRTC kontekste kodekai yra atsakingi už neapdorotų garso ir vaizdo duomenų kodavimą į formatą, tinkamą perdavimui tinklu (suspaudimas), ir vėliau tų suspaustų duomenų dekodavimą atgal į grojamą formatą priimančiojoje pusėje (išskleidimas).
• Paskirtis: Jų pagrindinė paskirtis yra sumažinti pralaidumą, reikalingą medijos srautams perduoti, todėl realaus laiko komunikacija tampa įmanoma net ir riboto pajėgumo tinkluose. Jie taip pat atlieka svarbų vaidmenį užtikrinant suderinamumą tarp skirtingų įrenginių ir platformų.

WebRTC paprastai palaiko įvairius garso ir vaizdo kodekus. Dažniausiai sutinkami yra šie:

Garso kodekai:

• Opus: De facto standartas WebRTC garsui. Tai universalus, atviro kodo ir nemokamas kodekas, skirtas tiek kalbai, tiek muzikai, siūlantis puikią kokybę esant įvairioms tinklo sąlygoms ir bitų spartai. Jis yra labai rekomenduojamas visoms WebRTC programoms.
• G.711 (PCMU/PCMA): Senesni, plačiai suderinami kodekai, bet apskritai mažiau efektyvūs nei Opus. PCMU (μ-law) yra paplitęs Šiaurės Amerikoje ir Japonijoje, o PCMA (A-law) naudojamas Europoje ir likusiame pasaulyje.
• iSAC: Dar vienas plačiajuostis garso kodekas, sukurtas „Google“, žinomas dėl gebėjimo prisitaikyti prie kintančių tinklo sąlygų.
• ILBC: Senesnis, siaurajuostis kodekas, skirtas mažam pralaidumui.

Vaizdo kodekai:

• VP8: Atviro kodo, nemokamas vaizdo kodekas, sukurtas „Google“. Jis plačiai palaikomas ir pasižymi geru našumu.
• VP9: VP8 įpėdinis, siūlantis geresnį suspaudimo efektyvumą ir aukštesnę kokybę esant panašiai bitų spartai. Tai taip pat atviro kodo ir nemokamas „Google“ kodekas.
• H.264 (AVC): Labai efektyvus ir plačiai pritaikytas patentuotas vaizdo kodekas. Nors jis labai paplitęs, jo licencijavimas kai kurioms programoms gali būti svarstytinas, nors dauguma naršyklių jį siūlo WebRTC.
• H.265 (HEVC): Dar efektyvesnis H.264 įpėdinis, bet su sudėtingesniu licencijavimu. HEVC palaikymas WebRTC yra ne toks visuotinis kaip H.264.

Kodekų parinkimo algoritmas veiksme

Kodekų parinkimo procesą daugiausia lemia SDP pasiūlymo/atsakymo modelis. Štai supaprastintas aprašymas, kaip tai paprastai veikia:

1 žingsnis: Pasiūlymas

Kai WebRTC dalyvis (pavadinkime jį dalyviu A) inicijuoja skambutį, jis sugeneruoja SDP pasiūlymą. Šiame pasiūlyme yra visų jo palaikomų garso ir vaizdo kodekų sąrašas, kartu su susijusiais parametrais ir pirmenybės tvarka. Pasiūlymas siunčiamas kitam dalyviui (dalyviui B) per signalizacijos serverį.

SDP pasiūlymas paprastai atrodo maždaug taip (supaprastintas fragmentas):

v=0
...
a=rtpmap:102 opus/48000/2
a=rtpmap:103 VP8/90000
a=rtpmap:104 H264/90000
...

Šiame fragmente:

• a=rtpmap eilutės aprašo kodekus.
• Skaičiai (pvz., 102, 103) yra payload tipai, vietiniai kodekų identifikatoriai šioje sesijoje.
• opus/48000/2 nurodo Opus kodeką su 48000 Hz diskretizavimo dažniu ir 2 kanalais (stereo).
• VP8/90000 ir H264/90000 yra įprasti vaizdo kodekai.

2 žingsnis: Atsakymas

Dalyvis B gauna SDP pasiūlymą. Tada jis išnagrinėja dalyvio A palaikomų kodekų sąrašą ir palygina jį su savo palaikomų kodekų sąrašu. Tikslas yra rasti aukščiausią bendrą kodeką, kurį gali apdoroti abu dalyviai.

Bendro kodeko parinkimo algoritmas paprastai yra toks:

1. Iteruojama per dalyvio A paskelbtus kodekus, paprastai ta tvarka, kuria jie pateikti pasiūlyme (kuri dažnai atspindi dalyvio A pirmenybę).
2. Kiekvienam kodekui iš dalyvio A sąrašo patikrinama, ar dalyvis B taip pat palaiko tą patį kodeką.
3. Jei randamas atitikmuo: Šis kodekas tampa pasirinktu kodeku tam medijos tipui (garsui ar vaizdui). Tada dalyvis B sugeneruoja SDP atsakymą, kuriame yra šis pasirinktas kodekas ir jo parametrai, priskiriant jam payload tipą. Atsakymas siunčiamas atgal dalyviui A per signalizacijos serverį.
4. Jei patikrinus visus kodekus nerandama atitikmens: Tai reiškia, kad nepavyko susitarti dėl bendro kodeko tam medijos tipui. Tokiu atveju dalyvis B gali arba praleisti tą medijos tipą savo atsakyme (faktiškai išjungdamas garsą ar vaizdą skambučiui), arba bandyti derėtis dėl atsarginio varianto.

Dalyvio B SDP atsakyme būtų nurodytas sutartas kodekas:

v=0
...
m=audio 9 UDP/TLS/RTP/SAVPF 102
...
a=rtpmap:102 opus/48000/2
...
m=video 9 UDP/TLS/RTP/SAVPF 103
...
a=rtpmap:103 VP8/90000
...

Atkreipkite dėmesį, kad atsakyme dabar nurodoma, kurį payload tipą (pvz., 102 Opus, 103 VP8) dalyvis B naudos sutartiems kodekams.

3 žingsnis: Ryšio užmezgimas

Kai abu dalyviai apsikeičia SDP pasiūlymais ir atsakymais ir susitaria dėl bendrų kodekų, jie nustato būtinus parametrus medijos mainams pradėti. Tada WebRTC posistemė naudoja šią informaciją medijos transportui (RTP per UDP) konfigūruoti ir „peer-to-peer“ ryšiui užmegzti.

Veiksniai, darantys įtaką kodekų parinkimui

Nors pagrindinis algoritmas yra paprastas (rasti pirmąjį bendrą kodeką), praktiniam įgyvendinimui ir faktiniam pasirinktam kodekui įtakos turi keli veiksniai:

1. Naršyklių įgyvendinimai ir numatytosios nuostatos

Skirtingos naršyklės („Chrome“, „Firefox“, „Safari“, „Edge“) turi savo vidinius WebRTC įgyvendinimus ir savo numatytąsias kodekų pirmenybes. Pavyzdžiui:

• „Chrome“/„Chromium“ pagrindu veikiančios naršyklės paprastai teikia pirmenybę VP8 ir Opus.
• „Firefox“ taip pat teikia pirmenybę Opus ir VP8, tačiau gali turėti skirtingas H.264 pirmenybes priklausomai nuo platformos.
• „Safari“ istoriškai turėjo stiprų H.264 ir Opus palaikymą.

Tai reiškia, kad tvarka, kuria naršyklė išvardija savo palaikomus kodekus SDP pasiūlyme, gali reikšmingai paveikti derybų rezultatą. Paprastai naršyklės pirmiausia nurodo pageidaujamus, efektyviausius ar dažniausiai palaikomus kodekus.

2. Operacinės sistemos ir aparatinės įrangos galimybės

Pagrindinė operacinė sistema ir aparatinė įranga taip pat gali turėti įtakos kodekų palaikymui. Pavyzdžiui:

• Kai kurios sistemos gali turėti aparatinį kodavimo/dekodavimo pagreitinimą tam tikriems kodekams (pvz., H.264), todėl juos naudoti yra efektyviau.
• Mobilieji įrenginiai gali turėti skirtingus kodekų palaikymo profilius, palyginti su staliniais kompiuteriais.

3. Tinklo sąlygos

Nors tai nėra tiesioginė pradinių SDP derybų dalis, tinklo sąlygos atlieka lemiamą vaidmenį pasirinkto kodeko našumui. WebRTC apima pralaidumo įvertinimo (BE) ir prisitaikymo mechanizmus. Kai kodekas yra pasirinktas:

• Adaptyvi bitų sparta: Šiuolaikiniai kodekai, tokie kaip Opus ir VP9, yra sukurti taip, kad pritaikytų savo bitų spartą ir kokybę pagal turimą tinklo pralaidumą.
• Paketų praradimo slėpimas (PLC): Jei paketai prarandami, kodekai naudoja metodus, kad atspėtų arba atkurtų trūkstamus duomenis, siekiant sumažinti suvokiamą kokybės pablogėjimą.
• Kodekų perjungimas (rečiau): Kai kuriais sudėtingesniais atvejais programos gali bandyti dinamiškai perjungti kodekus, jei tinklo sąlygos drastiškai pasikeičia, nors tai yra sudėtinga užduotis.

Pradinėmis derybomis siekiama suderinamumo; vykstančioje komunikacijoje išnaudojamas pasirinkto kodeko adaptyvumas.

4. Programai specifiniai reikalavimai

Programuotojai gali daryti įtaką kodekų parinkimui per JavaScript API, manipuliuodami SDP pasiūlymu/atsakymu. Tai yra pažangi technika, tačiau ji leidžia:

• Priversti naudoti konkrečius kodekus: Jei programa turi griežtą reikalavimą tam tikram kodekui (pvz., dėl sąveikos su senosiomis sistemomis), ji gali bandyti priversti jį pasirinkti.
• Teikti pirmenybę kodekams: Pakeisdama kodekų tvarką SDP pasiūlyme ar atsakyme, programa gali signalizuoti savo pageidavimus.
• Išjungti kodekus: Jei žinoma, kad kodekas yra problemiškas arba nereikalingas, jį galima aiškiai išjungti.

Programinis valdymas ir SDP manipuliavimas

Nors naršyklės didžiąją dalį SDP derybų atlieka automatiškai, frontend programuotojai gali gauti smulkesnį valdymą naudodami WebRTC JavaScript API:

1. `RTCPeerConnection.createOffer()` ir `createAnswer()`

Šie metodai generuoja SDP pasiūlymo ir atsakymo objektus. Prieš nustatant šiuos aprašymus `RTCPeerConnection` naudojant `setLocalDescription()`, galite modifikuoti SDP eilutę.

2. `RTCPeerConnection.setLocalDescription()` ir `setRemoteDescription()`

Šie metodai naudojami atitinkamai nustatyti vietinį ir nuotolinį aprašymus. Derybos įvyksta, kai sėkmingai iškviečiami abu `setLocalDescription` (pasiūlymo teikėjui) ir `setRemoteDescription` (atsakymo teikėjui).

3. `RTCSessionDescriptionInit`

`sdp` savybė `RTCSessionDescriptionInit` yra eilutė, kurioje yra SDP. Galite išanalizuoti šią eilutę, ją modifikuoti ir tada vėl surinkti.

Pavyzdys: VP9 pirmenybės teikimas prieš VP8

Tarkime, norite užtikrinti, kad VP9 būtų teikiama pirmenybė prieš VP8. Numatytasis SDP pasiūlymas iš naršyklės gali juos išvardyti tokia tvarka:

a=rtpmap:103 VP8/90000
a=rtpmap:104 VP9/90000

Galite perimti SDP pasiūlymą ir sukeisti eilutes vietomis, kad suteiktumėte pirmenybę VP9:

let offer = await peerConnection.createOffer();

// Modifikuokite SDP eilutę
let sdpLines = offer.sdp.split('\n');
let vp8LineIndex = -1;
let vp9LineIndex = -1;

for (let i = 0; i < sdpLines.length; i++) {
    if (sdpLines[i].startsWith('a=rtpmap:') && sdpLines[i].includes('VP8/90000')) {
        vp8LineIndex = i;
    }
    if (sdpLines[i].startsWith('a=rtpmap:') && sdpLines[i].includes('VP9/90000')) {
        vp9LineIndex = i;
    }
}

if (vp8LineIndex !== -1 && vp9LineIndex !== -1) {
    // Sukeiskite VP8 ir VP9 eilutes vietomis, jei VP9 yra po VP8
    if (vp9LineIndex > vp8LineIndex) {
        [sdpLines[vp8LineIndex], sdpLines[vp9LineIndex]] = [sdpLines[vp9LineIndex], sdpLines[vp8LineIndex]];
    }
}

offer.sdp = sdpLines.join('\n');

await peerConnection.setLocalDescription(offer);
// ... siųskite pasiūlymą nuotoliniam dalyviui ...

Dėmesio: Tiesioginis SDP manipuliavimas gali būti trapus. Naršyklių atnaujinimai gali pakeisti SDP formatus, o neteisingi pakeitimai gali sutrikdyti derybas. Šis metodas paprastai taikomas pažangiems naudojimo atvejams arba kai reikalinga specifinė sąveika.

4. `RTCRtpTransceiver` API (modernus metodas)

Tvirtesnis ir labiau rekomenduojamas būdas daryti įtaką kodekų parinkimui yra naudoti `RTCRtpTransceiver` API. Kai pridedate medijos takelį (pvz., `peerConnection.addTrack(stream.getAudioTracks()[0], 'audio')`), sukuriamas transiveris. Tada galite gauti transiverį ir nustatyti jo direction ir pageidaujamus kodekus.

Galite gauti palaikomus kodekus transiveriui:

const transceivers = peerConnection.getTransceivers();
transceivers.forEach(transceiver => {
    if (transceiver.kind === 'audio') {
        const codecs = transceiver.rtpSender.getCapabilities().codecs;
        console.log('Palaikomi garso kodekai:', codecs);
    }
});

Nors universalaus tiesioginio `setPreferredCodec` metodo ant transiverio visose naršyklėse nėra, WebRTC specifikacija siekia sąveikumo, priversdama naršykles gerbti SDP pateiktų kodekų tvarką. Tiesiogesnis valdymas dažnai gaunamas manipuliuojant SDP pasiūlymo/atsakymo generavimu per `createOffer`/`createAnswer` ir galbūt filtruojant/perrikiuojant kodekus prieš nustatant aprašymą.

5. `RTCPeerConnection` apribojimai (skirti `getUserMedia`)

Gaunant medijos srautus naudojant `navigator.mediaDevices.getUserMedia()`, galite nurodyti apribojimus, kurie gali netiesiogiai paveikti kodekų pasirinkimą, paveikdami prašomos medijos kokybę ar tipą. Tačiau šie apribojimai pirmiausia veikia patį medijos fiksavimą, o ne kodekų derybas tarp dalyvių.

Iššūkiai ir geriausios praktikos globalioms programoms

Globalios WebRTC programos kūrimas kelia unikalių iššūkių, susijusių su medijos derybomis:

1. Globalus naršyklių ir įrenginių susiskaldymas

Pasaulyje naudojama daugybė įrenginių, operacinių sistemų ir naršyklių versijų. Užtikrinti, kad jūsų WebRTC programa veiktų sklandžiai visame šiame susiskaldyme, yra didelis iššūkis.

• Pavyzdys: Vartotojas Pietų Amerikoje su senesniu „Android“ įrenginiu gali turėti skirtingus H.264 profilius ar kodekų palaikymą nei vartotojas Rytų Azijoje su naujausiu „iOS“ įrenginiu.

2. Tinklo kintamumas

Interneto infrastruktūra visame pasaulyje labai skiriasi. Vėlavimas, paketų praradimas ir prieinamas pralaidumas gali dramatiškai skirtis.

• Pavyzdys: Skambutis tarp dviejų vartotojų, naudojančių didelės spartos šviesolaidinį tinklą Vakarų Europoje, turės labai skirtingą patirtį nei skambutis tarp vartotojų, naudojančių mobilųjį tinklą kaimo vietovėje Pietryčių Azijoje.

3. Sąveika su senosiomis sistemomis

Daugelis organizacijų remiasi esama vaizdo konferencijų aparatine ar programine įranga, kuri gali pilnai nepalaikyti naujausių WebRTC kodekų ar protokolų. Norint įveikti šį atotrūkį, dažnai reikia įdiegti palaikymą labiau paplitusiems, nors ir mažiau efektyviems, kodekams, tokiems kaip G.711 ar H.264.

Geriausios praktikos:

• Teikite pirmenybę Opus garsui: Opus yra universaliausias ir plačiausiai palaikomas garso kodekas WebRTC. Jis puikiai veikia įvairiose tinklo sąlygose ir yra labai rekomenduojamas visoms programoms. Įsitikinkite, kad jis yra aiškiai matomas jūsų SDP pasiūlymuose.
• Teikite pirmenybę VP8/VP9 vaizdui: VP8 ir VP9 yra atviro kodo ir plačiai palaikomi. Nors H.264 taip pat yra paplitęs, VP8/VP9 siūlo gerą suderinamumą be licencijavimo problemų. Apsvarstykite VP9 dėl geresnio suspaudimo efektyvumo, jei palaikymas yra nuoseklus jūsų tikslinėse platformose.
• Naudokite patikimą signalizacijos serverį: Patikimas signalizacijos serveris yra labai svarbus efektyviam ir saugiam SDP pasiūlymų ir atsakymų mainams skirtinguose regionuose.
• Išsamiai testuokite įvairiuose tinkluose ir įrenginiuose: Simuliuokite realaus pasaulio tinklo sąlygas ir testuokite savo programą įvairiuose įrenginiuose ir naršyklėse, atspindinčiose jūsų globalią vartotojų bazę.
• Stebėkite WebRTC statistiką: Naudokite `RTCPeerConnection.getStats()` API, kad stebėtumėte kodekų naudojimą, paketų praradimą, virpėjimą ir kitus rodiklius. Šie duomenys yra neįkainojami nustatant našumo problemas ir su kodekais susijusias problemas skirtinguose regionuose.
• Įgyvendinkite atsargines strategijas: Siekdami geriausio, būkite pasiruošę scenarijams, kai derybos dėl tam tikrų kodekų gali nepavykti. Turėkite parengtus sklandžius atsarginius mechanizmus.
• Apsvarstykite serverio pusės apdorojimą (SFU/MCU) sudėtingiems scenarijams: Programoms su daug dalyvių arba reikalaujančioms pažangių funkcijų, tokių kaip įrašymas ar perkodavimas, naudojant atrankinio persiuntimo vienetus (SFU) arba daugiataškio valdymo vienetus (MCU), galima perkelti apdorojimą ir supaprastinti derybas kliento pusėje. Tačiau tai padidina serverio infrastruktūros išlaidas.
• Sekite naršyklių standartus: WebRTC nuolat tobulėja. Sekite naujienas apie naujų kodekų palaikymą, standartų pokyčius ir naršyklėms specifinį elgesį.

Išvada

WebRTC medijos derybų ir kodekų parinkimo algoritmas, nors ir atrodo sudėtingas, iš esmės yra skirtas rasti bendrą kalbą tarp dviejų dalyvių. Naudodamas SDP pasiūlymo/atsakymo modelį, WebRTC siekia sukurti suderinamą komunikacijos kanalą, identifikuodamas bendrus garso ir vaizdo kodekus. Frontend programuotojams, kuriantiems globalias programas, šio proceso supratimas yra ne tik apie kodo rašymą; tai apie projektavimą universalumui.

Pirmenybės teikimas patikimiems, plačiai palaikomiems kodekams, tokiems kaip Opus ir VP8/VP9, kartu su griežtu testavimu įvairiose globaliose aplinkose, padės pagrindus sklandžiai, aukštos kokybės realaus laiko komunikacijai. Įvaldę kodekų derybų niuansus, galite atskleisti visą WebRTC potencialą ir suteikti išskirtinę vartotojo patirtį pasaulinei auditorijai.