Abonare Newsletter

Selecteaza Domeniu:

Transportul Video over IP – Noi Directii

 

Nu a fost niciodata o sarcina banala sa transmitem video prin retelele IP. Nevoia de a muta datele de tip text a condus la aparitia retelelor IP. Cu toate acestea, atunci cand vocea a fost mutata cu succes si eficient prin aceste retele, inginerii au inceput sa se intrebe daca si continutul video ar putea fi transportat pe ele. Conferintele video si IPTV-ul au fost construite pe conceptul ca, daca reteaua nu era predispusa la pierderi, IP-ul folosind o interfata de conectare UDP (User Datagram Protocol) poate furniza video in mod eficient. Vidyo a demonstrat ca Internetul ar putea transporta videoconferinte daca a fost utilizata codarea video scalabila la sursa. Totusi, lucrurile s-au schimbat cu adevarat atunci cand Netflix a inceput streaming-ul video. Cei de la Netflix au folosit HTTP/ TCP, care este similar cu aproape toate celelalte aplicatii web. Radiodifuzorii si producatorii de servere de streaming au inceput sa utilizeze metoda, numita acum rata de biti adaptabila/ adaptive bitrate (ABR).

 

In ciuda acestui fapt, TCP nu a tinut pasul cu schimbarile tehnologiei de retea, asa cum ne-am asteptat. In jurul anului 2010, Jim Gettys, atunci la Bell Labs, a descoperit ca performanta TCP suferea din cauza incapacitatii protocolului de a face fata tampoanelor mari in retea. TCP detecteaza congestionarea traficului de retea prin observarea pachetelor pierdute. Modifica rata de expediere prin scaderea vitezei. Cu toate acestea, aceste tampoane mari indica faptul ca protocolul TCP este lent si poate reduce ocazional rata de expediere prea mult. Asadar, raspunsul este sa nu folosim TCP? Nu neaparat. Vazand ca singura alternativa este UDP, care este un protocol foarte sensibil la pierderi, transportul pe Internet continua sa fie o problema.

 

Doua noi abordari au fost propuse pentru a rezolva aceasta dilema. Una vine din industria IT; cealalta este oferita de industria AV. Prima vine de la Google. Protocolul lor TCP BBR (bandwidth bottleneck & RTT) utilizeaza ideea ca aglomerarea/ congestia poate fi detectata prin estimarea continua a ratei de livrare a fluxului. Experimentele lor au aratat ca TCP BBR furnizeaza aproximativ aceeasi performanta ca protocolul TCP traditional, dar cu o latenta mult mai mica. 

 

Cea de-a doua directie a fost propusa de Haivison si Wowza si este promovata prin intermediul grupului pe care l-au organizat – Alianta SRT (SRT Alliance). Cateva zeci de producatori s-au alaturat aliantei si s-au angajat sa sprijine protocolul SRT. SRT (Secure Reliable Transport) se bazeaza pe UDP. Asadar, evita problemele care s-au dezvoltat in cazul TCP. De asemenea, presupune costuri mai mici decat TCP. STR este un protocol de incredere, care asigura practic livrarea video. Se poate adapta, de asemenea, la fluctuatiile latimii de banda.

 

 

Ambele abordari par solide din punct de vedere tehnic. Totusi, ele trebuie testate mai mult pentru a vedea daca fac fata problemelor reale ale Internetului. De exemplu, cum va imparti fiecare latime de banda cu alt trafic, precum transferurile de fisiere in cloud, traficul de afaceri in tunelurile VPN si fluxurile de rata de biti adaptabila? Desi aceste lucruri pot fi dificil de simulat in laborator, ele nu sunt imposibile. Astfel de teste trebuie efectuate iar rezultatele trebuie sa fie puse la dispozitia utilizatorilor. In viitorul apropiat, comunitatea IT poate solicita aceasta testare inainte de adoptarea acestor protocoale.