Vi studerar VoIP-motorn Mediastreamer2. Del 11

Artikelmaterialet är hämtat från min Zen-kanal.

Datatransfer mekanism

• Data block dblk_t
• Message mblk_t
• Funktioner för arbete med meddelanden mblk_t
• Kö queue_t
• Funktioner för arbete med köer queue_t
• Filteranslutning
• Signalknutpunkt i databehandlingsgrafen
• Bakom kulisserna aktivitet av tickern
• Buffert (MSBufferizer)
• Funktioner för arbete med MSBufferizer

Tidigare artikeln Vi har utvecklat vårt eget filter. Denna artikel kommer att ägnas åt strukturen av den interna mekanismen för datatransfer mellan filter i mediastreamern. Detta kommer sedan att möjliggöra skrivandet av sofistikerade filter med mindre ansträngning.

Datatransfer mekanism

Datatransfer i mediastreamern utförs med hjälp av köer som beskrivs av strukturen queue_t. Genom köerna flyttas kedjor av meddelanden av typen mblk_t, som i sig själva inte innehåller signaldata, utan endast referenser till det föregående, nästa meddelande och till datablocket. Dessutom vill jag särskilt påpeka att det finns ett fält för en referens till ett meddelande av samma typ, vilket möjliggör organiseringen av en enkel länkad lista av meddelanden. En grupp meddelanden, sammanlänkade på detta sätt, kommer vi att kalla en tupel. Således kan vilket som helst element i kön vara ett enskilt meddelande mblk_t, eller också vara huvudet på en tupel av meddelanden mblk_t. Varje meddelande i tupeln kan ha sitt eget underliggande datablock. Varför vi behöver tupeln kommer vi att diskutera lite senare.

Som nämnts ovan innehåller själva meddelandet inte datablocket, istället innehåller det endast en pekare till det minnesområde där blocket lagras. I denna del liknar den övergripande bilden av mediastreamerns arbete en lager av dörrar i tecknad filmen 'Monsterföretaget', där dörrarna (datareferenser — rum) rör sig med galen hastighet längs hängande transportband, medan själva rummen förblir stilla.

Nu, när vi går igenom hierarkin underifrån och upp, låt oss utforska detaljerat de nämnda entiteterna i datatransfermekanismen i mediastreamern.

Datablock dblk_t

Datablocket består av en rubrik och en datarbuffert. Rubriken beskrivs av följande struktur,

typedef struct datab
{
unsigned char *db_base; // Pekare till början av databufferten.
unsigned char *db_lim;  // Pekare till slutet av databufferten.
void (*db_freefn)(void*); // Funktion för att frigöra minne vid borttagning av block.
int db_ref; // Referensräknare.
} dblk_t;

Strukturens fält innehåller pekare till början av bufferten, slutet av bufferten och funktionen för att ta bort databufferten. Den sista posten i rubriken db_ref – är en räknare för referenser, när den når noll fungerar det som en signal för att ta bort denna block från minnet. Om datablocket har skapats av funktionen datab_alloc() , kommer databufferten att placeras i minnet direkt efter rubriken. I alla andra fall kan bufferten ligga någon annanstans. I databufferten kommer signaldata eller andra data som vi vill bearbeta med filter att lagras.

Ett nytt instans av datablocket skapas med hjälp av funktionen:

dblk_t *datab_alloc(int size);

Som inparametern får den storleken på de data som blocket ska lagra. Minnet allokeras mer, för att i början av det allokerade minnet placera rubriken – strukturen datab. Men när andra funktioner används så sker det inte alltid, i vissa fall kan databufferten ligga separerat från datablocket. Strukturens fält konfigureras vid skapandet så att dess fält db_base pekar på början av datamängden, och db_lim på dess slut. Referensräknaren db_ref ställs in på ett. Pekaren till funktionen för att rensa data ställs in på noll.

Meddelandet mblk_t

Som nämnts har köens element typ mblk_t, som definieras enligt följande:

typedef struct msgb
{
  struct msgb *b_prev;   // Pekare till föregående element i listan.
  struct msgb *b_next;   // Pekare till nästa element i listan.
  struct msgb *b_cont;   // Pekare för att klistra in andra meddelanden till meddelandet, för att skapa tuple meddelanden.
  struct datab *b_datap; // Pekare till datablokens struktur.
  unsigned char *b_rptr; // Pekare till början av datamängden för att läsa data från bufferten b_datap.
  unsigned char *b_wptr; // Pekare till början av datamängden för att skriva data till bufferten b_datap.
  uint32_t reserved1;    // Reservfält1, mediastreamer placerar där serviceinformation. 
  uint32_t reserved2;    // Reservfält2, mediastreamer placerar där serviceinformation.
  #if defined(ORTP_TIMESTAMP)
  struct timeval timestamp;
  #endif
  ortp_recv_addr_t recv_addr;
} mblk_t;

Struktur mblk_t innehåller i början pekare b_prev, b_next, vilka är nödvändiga för att organisera en dubbellänkad lista (som är kön queue_t).

Sedan följer pekaren b_cont, som endast används när meddelandet går in i tuplen. För det sista meddelandet i tuplen förblir denna pekare noll.

Här ser vi en pekare till datablocket b_datap, vilket är anledningen till att meddelandet existerar. Därefter följer pekare till området inom datablocket. Fältet b_rptr anger platsen från vilken data kommer att läsas från buffern. Fältet b_wptr anger platsen där skrivning till buffern kommer att ske.

De återstående fälten är av servicekaraktär och relaterar inte till hur datatransmissionsmekanismen fungerar.

Nedan visas ett enskilt meddelande med namnet m1 och datablocket d1.

I nästa bild visas en tuppel av tre meddelanden m1, m1_1, m1_2.

Funktioner för att hantera meddelanden mblk_t

Ett nytt meddelande mblk_t skapas av funktionen:

mblk_t *allocb(int size, int pri); 

den allokerar ett nytt meddelande mblk_t med ett datablock av angiven storlek size, den andra argumentet — pri används inte i den aktuella versionen av biblioteken. Det ska förbli noll. Under funktionens gång kommer minne att avsättas för strukturen av det nya meddelandet och funktionen mblk_init(), som nollställer alla fält i den skapade instansen av strukturen och sedan, med hjälp av den nämnda tidigare, datab_alloc(), skapa databufferten. Därefter kommer fälten i strukturen att ställas in:

mp->b_datap=datab;
mp->b_rptr=mp->b_wptr=datab->db_base;
mp->b_next=mp->b_prev=mp->b_cont=NULL;

Vid utgången får vi ett nytt meddelande med initierade fält och en tom databuffert. För att lägga till data i meddelandet måste man kopiera dem till datablocket:

memcpy(msg->b_rptr, data, size);

w data — pekaren till datakällan, och size — dess storlek.
därefter måste man uppdatera pekaren till skrivpunkten så att den åter pekar på början av det lediga området i bufferten:

msg->b_wptr = msg->b_wptr + size

Om det krävs att skapa ett meddelande från en redan existerande buffer, utan att kopiera, används funktionen:

mblk_t *esballoc(uint8_t *buf, int size, int pri, void (*freefn)(void*)); 

Funktionen kommer efter skapandet av meddelandet och datablocket, att ställa in dess pekare till data vid adressen buf. D.v.s. i detta fall ligger databufferten inte efter fälten i datablocket, som det var vid skapandet av datablocket med funktionen datab_alloc()Den överförda funktionen buffert med data kommer att förbli där den var, men kommer att styra den nyss skapade blockhuvudet via pekare, som i sin tur går till meddelandet.

Ett meddelande mblk_t kan ha flera datablok i följd kopplade till sig. Detta görs av funktionen:

mblk_t * appendb(mblk_t *mp, const char *data, int size, bool_t pad); 

mp — meddelandet som kommer att få ytterligare ett datablok;
data — en pekare på det blok som en kopia kommer att läggas till i meddelandet;
size — storlek på data;
pad — flagga som anger att den tilldelade minnesstorleken ska justeras till en 4-byte-gräns (fyllning kommer att göras med nollor).

Om det finns tillräckligt med utrymme i den befintliga meddelandebufferten, kommer de nya uppgifterna att kopplas på efter de redan befintliga där. Om det fria utrymmet i meddelandebufferten blir mindre än size, skapas ett nytt meddelande med tillräckligt stor buffert och data kopieras till dess buffert. Detta nya meddelande kopplas till det ursprungliga via pekaren b_cont. I det här fallet omvandlas meddelandet till en tuple.

Om du behöver lägga till ytterligare ett datablok i tuplen, måste du använda funktionen:

void msgappend(mblk_t *mp, const char *data, int size, bool_t pad);

den kommer att hitta det senaste meddelandet i tuplen (det kommer att vara noll) och anropa funktionen b_cont appendb() För att ta reda på storleken på uppgifterna i meddelandet eller tuplen kan du använda funktionen:.

int msgdsize(const mblk_t *mp);

den kommer att gå igenom alla meddelanden i tuplen och returnera det totala antalet data i data-bufferarna för dessa meddelanden. För varje meddelande beräknas datamängden så här:

mp->b_wptr - mp->b_rptr

 För att förena två tupler används funktionen:

mblk_t *concatb(mblk_t *mp, mblk_t *newm);

den kopplar tuplen

newm till slutet av tuplen och returnerar en pekare på det senaste meddelandet i den resulterande tuplen. mp Vid behov kan tuplen omvandlas till ett enda meddelande med ett enda datablok, detta görs av funktionen:

void msgpullup(mblk_t *mp,int len);

om argumentet

är lika med -1, så bestäms storleken på den tilldelade bufferten automatiskt. Om len är lika med -1, så bestäms storleken på den avledda bufferten automatiskt. Om len Om det är ett positivt tal kommer en buffert av denna storlek att skapas och data från tuplemeddelandena kommer att kopieras dit. Om bufferten tar slut kommer kopieringen att stoppas. Det första meddelandet i tuplen får en buffert av ny storlek med kopierade data. Övriga meddelanden kommer att raderas och minnet återförs till högen.

Vid borttagning av strukturen mblk_t beaktas referensräknaren för datablocket, om vid anropet freeb() den visar sig vara noll, raderas datan från bufferten tillsammans med instansen mblk_t, som pekar på den.

Initialisering av fälten i det nya meddelandet:

void mblk_init(mblk_t *mp);

Lägg till en ny datamängd till meddelandet:

mblk_t * appendb(mblk_t *mp, const char *data, size_t size, bool_t pad);

Om de nya data inte får plats i det tillgängliga utrymmet i meddelandets datBuffert, kopplas ett separat skapat meddelande med den nödvändiga storleken till meddelandet (pekaren till det tillagda meddelandet ställs in i det första meddelandet) meddelandet blir en tuple.

Lägg till en datamängd till tuplen:

void msgappend(mblk_t *mp, const char *data, size_t size, bool_t pad); 

Funktionen anropar appendb() i en loop.

Sammanfoga två tupler till en:

den kopplar tuplen

Meddelandet till slutet av tuplen kommer att anslutas till mp.

Skapa en kopia av ett enda meddelande:

mblk_t *copyb(const mblk_t *mp);

Fullständig kopiering av tuplen med alla datablokkar:

mblk_t *copymsg(const mblk_t *mp);

Elementen i tuplen kopieras med funktionen copyb().

Skapa en lätt kopia av meddelandet mblk_t. Vid detta kopieras inte datablocket, utan dess referensräknare ökas db_ref:

mblk_t *dupb(mblk_t *mp);

Skapa en lätt kopia av tuplen. Datablokkar kopieras inte, utan endast deras referensräknare ökas db_ref:

mblk_t *dupmsg(mblk_t* m);

Sammanfoga alla meddelanden i tuplen till ett meddelande:

void msgpullup(mblk_t *mp, size_t len);

Om argumentet len är lika med -1, bestäms storleken på bufferten automatiskt.

Ta bort meddelandet, tuplen:

void freemsg(mblk_t *mp);

Referensräknaren för datablocket minskas med ett. Om den når noll raderas även datablocket.

Beräkning av den totala datavolymen i meddelandet eller tuplen.

size_t msgdsize(const mblk_t *mp);

Hämta meddelandet från köns svans:

mblk_t *ms_queue_peek_last(q);

Kopiera innehållet i de reserverade fälten från ett meddelande till ett annat (det finns i dessa fält flaggor som används av medieströmmen):

mblk_meta_copy(const mblk_t *source, mblk *dest);

Kö queue_t

Kö-systemet i medieströmmen är implementerat som en ringdoubellista. Varje element i listan innehåller en pekare till en datablob med signalavläsningar. Det innebär att det bara är pekarna till databloben som flyttas i ordning, medan själva datan förblir stilla. Det vill säga att det endast är länkarna till dem som flyttas.
Strukturen som beskriver kön queue_t, visas nedan:

typedef struct _queue
{
   mblk_t _q_stopper; /* "Tom" element i kön, pekar inte på data, används endast för att styra kön. Vid initiering av kön (qinit()) ställs dess pekare in så att de pekar på sig själva. */
   int q_mcount;        // Antal element i kön.
} queue_t;

Strukturen innehåller ett fält — en pekare _q_stopper av typen *mblk_t, den pekar på det första elementet (meddelandet) i kön. Det andra fältet i strukturen är en räknare för meddelanden som finns i kön.
I bilden nedan visas kön med namnet q1, som innehåller 4 meddelanden m1,m2, m3, m4.

I nästa bild visas kön med namnet q1, som innehåller 4 meddelanden m1,m2, m3, m4. Meddelandet m2 är huvudknuten, som har ytterligare två meddelanden m2_1 och m2_2.

Funktioner för arbete med köer queue_t

Initiering av kön:

void qinit(queue_t *q);

Fältet _q_stopper (hädanefter kommer vi att kalla det "stoppare") initieras av funktionen mblk_init(), dess pekare för det föregående elementet och nästa element ställs in så att de pekar på sig själva. Räknaren för element i kön nollställs.

Tillägg av ett nytt element (meddelande):

void putq(queue_t *q, mblk_t *m);

Det nya elementet m läggs till i slutet av listan, pekarna för elementet ställs in så att stoppare blir dess nästa element och det blir det föregående elementet för stoppare. Räknaren för element i kön inkrementeras.

Uttag av ett element från kön:

mblk_t * getq(queue_t *q); 

det meddelande som står efter stoppare tas bort, räknaren för element minskas. Om det inte finns några element i kön förutom stoppare, returneras 0.

Insättning av meddelande i kön:

void insq(queue_t *q, mblk_t *emp, mblk_t *mp); 

Element mp infogas före elementet emp. Om emp=0, så läggs meddelandet till i slutet av kön.

Uttag av meddelande från huvudet av kön:

void remq(queue_t *q, mblk_t *mp); 

Räknaren för element minskas.

Läsa pekaren till det första elementet i kön:

mblk_t * peekq(queue_t *q); 

Borttagning av alla element från kön med radering av själva elementen:

void flushq(queue_t *q, int how);

Argumentet how används inte. Antalet köelement sätts till noll.

Makro för att läsa pekaren på det sista köelementet:

mblk_t * qlast(queue_t *q);

När man arbetar med meddelandeköer bör man komma ihåg att vid anrop av ms_queue_put(q, m) med en nullpekare till meddelandet, slutar funktionen i en oändlig loop. Ditt program kommer att låsa sig. Detsamma gäller ms_queue_next(q, m).

Filteranslutning

Den beskrivna kön används för att överföra meddelanden från en filter till en annan eller från en till flera filter. Filter och deras anslutningar bildar en riktad graf. Ingång eller utgång av filtret kallas med det generella ordet "pin". För att beskriva ordningen för anslutningar mellan filter, används begreppet "signalpunkt" i medieströmmaren. En signalpunkt är en struktur _MSCPoint, som innehåller en pekare på filtret och numret på en av dess pinnar, vilket beskriver anslutningen av en av ingångarna eller utgångarna av filtret.

Signalknutpunkt i databehandlingsgrafen

typedef struct _MSCPoint{
struct _MSFilter *filter; // Pekare på medieströmmarfiltret.
int pin;                        // Numret på en av ingångarna eller utgångarna av filtret, dvs. pin.
} MSCPoint;

Pinnarna på filtren numreras från noll.

Anslutningen av två pinnar via en meddelandekö beskrivs av strukturen _MSQueue, som innehåller meddelandekön och pekare på två signalpunkter som den ansluter:

typedef struct _MSQueue
{
queue_t q;
MSCPoint prev;
MSCPoint next;
}MSQueue;

Vi kallar denna struktur för en signal-länk. Varje medieströmmarfiltret innehåller en tabell med ingångslänkar och en tabell med utgångslänkar (MSQueue). Storleken på tabellerna anges vid skapandet av filtret, detta har vi redan gjort med hjälp av den exporterade variabeln av typen MSFilterDesc, när vi utvecklade vår egen filter. Nedan visas strukturen som beskriver vilket filter som helst i medieströmmaren, MSFilter:

struct _MSFilter{
    MSFilterDesc *desc;    
    /* Pekare till filterbeskrivningen. */
    /* Skyddade attribut, de kan inte flyttas eller tas bort, annars fungerar plugins fel. */
    ms_mutex_t lock;      /* Semafor. */
    MSQueue **inputs;     /* Tabell med ingångslänkar. */
    MSQueue **outputs;    /* Tabell med utgångslänkar. */
    struct _MSFactory *factory; /* Pekare till fabriken som skapade detta instans av filtret. */
    void *padding;              /* Används inte, kommer att användas om skyddade fält läggs till. */
    void *data;                 /* Pekare till en godtycklig struktur för att lagra interna filterdata och mellanresultat. */
    struct _MSTicker *ticker;   /* Pekare till tickern, som inte får vara null när funktionen process() anropas. */
    /* privata attribut, de kan flyttas och ändras när som helst */
    MSList *notify_callbacks; /* Lista med återkopplingsfunktioner som används för att hantera filterhändelser. */
    uint32_t last_tick;       /* Nummer på den senaste takten när process() anropades. */
    MSFilterStats *stats;     /* Filterstatistik. */
    int postponed_task; /* Antal uppskjutna uppgifter. Vissa filter kan skjuta upp databehandling (anrop av process()) över flera takter. */
    bool_t seen;  /* Flagg som används av tickern för att markera att denna instans av filtret redan har hanterats på denna takt. */
};
typedef struct _MSFilter MSFilter;

När vi i C-programmet har kopplat ihop filtren enligt vår plan (men inte kopplat tickern), har vi därmed skapat en riktad graf, vars noder är instanser av strukturen MSFilter, och kanterna är instanser av länkar MSQueue.

Bakom kulisserna aktivitet av tickern

När jag sa till dig att tickern är en taktkälla för filtren, var det inte hela sanningen om den. Tickern är ett objekt som kör funktionerna process() för alla filter i schemat (grafen) som den är kopplad till. När vi kopplar tickern till ett filter i grafen, visar vi tickern grafen som den från och med nu kommer att hantera tills vi kopplar bort den. Efter att ha kopplat, börjar tickern inspektera den tilldelade grafen och skapar en lista över de filter som ingår i den. För att inte "räkna" ett filter två gånger, markerar den upptäckta filter genom att sätta en flagga seen. Söket genomförs i länktabeller som varje filter har.

Under sin introduktionstur kontrollerar tickern om det finns åtminstone ett filter bland filtren som fungerar som en källa för datablokker. Om inga hittas, betraktas grafen som felaktig och tickern avslutar sin funktion.

Om grafen visade sig vara "korrekt", anropas en funktion för varje hittat filter för att initiera det. preprocess(). Så snart det är dags för nästa bearbetningscykel (som standard var tionde millisekund), anropar tickern en funktion. process() för alla tidigare funna källfilter och sedan för de övriga filtren i listan. Om filtret har ingångslänkar, upprepas anropet av funktionen process() tills dess att köerna för ingångslänkarna är tomma. Därefter går den vidare till nästa filter i listan och "rullar" detta tills ingångslänkarna är fria från meddelanden. Tickern går från filter till filter tills listan är slut. Bearbetningen av cykeln avslutas här.

Nu går vi tillbaka till tuplarna och pratar om varför en sådan entitet lades till i medieströmmen. I allmänhet stämmer inte datavolymen som algoritmen som arbetar inuti filtret behöver överens med storleken på buffrarna för de inkommande datablokkerna. Låt oss säga att vi skriver ett filter som gör snabb Fourier-transformering, vilket per definition bara kan bearbeta datablokker vars storlek är en exponent av två. Låt oss säga 512 prover. Om data genereras från en telefonlinje, kommer buffern för varje inkommande meddelande att ge oss 160 prover av signalen. Det finns en frestelse att inte hämta data från ingången förrän det finns ett tillräckligt antal data. Men i det här fallet uppstår det en konflikt med tickern, som utan framgång kommer att försöka rulla filtret tills ingångslänken är tom. Tidigare betecknade vi denna regel som den tredje principen för hur filtret fungerar. I enlighet med denna princip måste funktionen process() för filtret hämta alla data från ingångsköerna.

Dessutom kan man inte hämta bara 512 värden från ingången, eftersom de måste hämtas i hela block, det vill säga filtret måste hämta 640 värden och använda 512 av dem, medan resten sparas tills en ny portion data ackumuleras. Därför, förutom sin huvudfunktion, måste vårt filter också tillhandahålla stödjande åtgärder för mellanlagring av ingångsdata. Utvecklarna av medieströmmen och lösningen på denna gemensamma uppgift har utvecklat ett speciellt objekt – MSBufferizer (buffer), som löser denna uppgift med hjälp av tuples.

Buffert (MSBufferizer)

Detta objekt kommer att ackumulera ingångsdata inuti filtret och börja skicka dem för bearbetning så snart mängden information är tillräcklig för att köra filtreringsalgoritmen. Medan bufferten samlar data kommer filtret att arbeta i tomgångsläge och inte använda någon processorkraft. Men så snart funktionen för att läsa från bufferten returnerar ett värde som är olika från noll, börjar funktionen process() filtrera och bearbeta data från bufferten i portioner av rätt storlek, tills de är uttömda.
De hittills oanvända data förblir i bufferten som det första elementet i tuple, till vilket härföljer följande block av ingångsdata.

Strukturen som beskriver bufferten:

struct _MSBufferizer{
queue_t q; /* Meddelandekö. */
int size; /* Total storlek på data i bufferten för tillfället. */
};
typedef struct _MSBufferizer MSBufferizer;

Funktioner för arbete med MSBufferizer

Skapande av en ny instans av bufferten:

MSBufferizer * ms_bufferizer_new(void);

Minnet allokeras, initieras i ms_bufferizer_init() och en pekare returneras.

Initieringsfunktion:

void ms_bufferizer_init(MSBufferizer *obj); 

Kön q, fält size initieras till noll.

Lägg till meddelande:

void ms_bufferizer_put(MSBufferizer *obj, mblk_t *m); 

Meddelandet m läggs till kön. Den beräknade storleken av datablokkerna läggs till size.

Överföring till bufferten av alla meddelanden från datakön q:

void ms_bufferizer_put_from_queue(MSBufferizer *obj, MSQueue *q);   

Överföring av meddelanden från kön q till bufferten görs med hjälp av funktionen ms_bufferizer_put().

Läsa från bufferten:

int ms_bufferizer_read(MSBufferizer *obj, uint8_t *data, int datalen); 

Om storleken på de ackumulerade i bufferten data är mindre än den begärda storleken (datalen), så returnerar funktionen noll, och datakopiering till data utförs inte. Annars utförs sekventiell kopiering av data från tupplarna som finns i buffertminnet. Efter kopiering tas tupplarna bort och minnet frigörs. Kopieringen avslutas när datalen byte har kopierats. Om utrymmet tar slut mitt i en datablokk, kommer i detta meddelande datablokken att förkortas till den återstående icke-kopierade delen. Vid nästa anrop fortsätter kopieringen från denna punkt.

Läsa antalet data som är tillgängliga för närvarande i buffertminnet:

int ms_bufferizer_get_avail(MSBufferizer *obj); 

Returnerar fältet size buffertminnet.

Kasta bort en del av data som finns i buffertminnet:

void ms_bufferizer_skip_bytes(MSBufferizer *obj, int bytes);

Det angivna antalet bytes data extraheras och kastas bort. De äldsta data kastas bort.

Ta bort alla meddelanden i buffertminnet:

void ms_bufferizer_flush(MSBufferizer *obj); 

Datacounten återställs till noll.

Ta bort alla meddelanden i buffertminnet:

void ms_bufferizer_uninit(MSBufferizer *obj); 

Återställning av dataräknaren utförs inte.

Ta bort buffertminnet och frigöra minnet:

void ms_bufferizer_destroy(MSBufferizer *obj);  

Exempel på användning av buffertminnet kan hittas i källkoden för flera mediastreamerfilter. Till exempel i filtret MS_L16_ENC, som utför byteordning i nätverksordning, i värdordning: l16.c

I nästa artikel kommer vi att titta på hur man bedömer belastningen på tickern och hur man hanterar överdriven beräkningsbelastning i mediastreamern.

Källa: habr.com