20.8.2023, 18:05
(Tento příspěvek byl naposledy změněn: 20.8.2023, 18:44 uživatelem JiRo.
Důvod úpravy: Překlepy, doplnění informace.
)
@meda Já se vyjádřím jen k té logice zápisu do cache. Na začátku přehrávání je pro dopředný buffer vyhrazeno 100 % paměti vyhrazené pro cache. Jakmile se začně přehrávat, tak to, co se už přehrálo se zapíše do zpětného bufferu a to co se přednáčítá zapisuje zase do dopředného bufefru. Ono to fyzicky není tak, že by se plnily dva buferry samostaně, ale představme si to jako "dvoudílné okno" putující po paměti vyhrazené pro cache, které se pohybuje a zároveň se mění poměr mezi oběma jeho částmi. Od počátečního rozdělení 0/100 do konečného 25/75. V okamžiku, kdy se skočí dopředu, záleží na tom, jestli se skočí až za část, která je načtená v dopředném bufferu, nebo se skočí do místa, které je ještě v dopředném bufferu načtené. Pokud je to ten první případ, tak se vše znuluje a začíná se znova. Pokud ten druhý, tak se to pomyslné okno jen posune, obsah dopředného bufefru se o ten posun sníží a pokračuje se v přednačítání, obsah zpětného bufferu se (a zase podle toho, jak je ten skok "dlouhý") buď vynuluje, nebo jen poměrně sníží. Ty bufffery jsou samozřejmě cyklické, tzn. že se v něm ten algoritmus pohybuje stále dokola.
A ještě poznámka k tomu, jak to, že někdy dojde k tomu, že se dopředný buffer naplní nad hodnotu 75 % a pak se začně postupně vyčerpávat až zpátky k hodnotě 75 %. Někdo se může zeptat, proč se to děje jen někdy a na čem to tedy vlastně závisí. I tady je ta odpoěď poměrně jednouduchá. Tady v tom případě záleží na tom, jak vysoký je datový tok vlastního streamu. Pokud je totiž dostatečně vysoký (oproti maximální rychlosti komunikace), tak se ten zpětný buffer zaplní dříve, než se stačí zaplnit ten dopředný. Tzn. že maximální zaplnění dopředného bufferu nikdy nepřekročí 75 %. Je-li ale ten datový tok vlastního streamu menší, tak dojde k tomu, že se dříve zaplní dopředný buffer než ten zpětný, tudíž ten algoritmus načítá dál přes limit 75 %, a to až do chvíle, než se to srovná. V okamžikui, kdy jsou oba bufferu naplněné, tak se ten dopředný přestane načítat, a to až do doby, než jeho zaplnění klesne na 75 %.
A protože mi ještě vrtá hlavou ta odpověď @meda: v jeho bodě 2, přemýšlel jsem ještě o jeho domněnce. A možná že by to mohl být klíč k té záhadě, jak to, že se někdy významně sníží rychlost načítání.
Jak @meda: píše, mohl by ten algoritmu na základě spočítaného poměru rychlosti načítání a rychlosti vlastního streamu skutečně usoudit, že není třeba načítat tak rychle a rychlost snížit. To ostatně koresponduje s podobnou teorií, kterou jsem před pár příspěvky také uvedl. Jenže já si myslel, že by tohle mohl dělat přímo Webshare, ale mně samotnému se to zdálo nepravdpěodobné ("To se pak člověk na něco upne..."). Ale Méďova teorie to vysvětluje smysluplně.
Takže další hraní bude s hodnotou readfactor, který by na tohle chování možná měl mít vliv... Až budu mít zase chuť na laborování, vyzkouším několik nastavení a pak tu budu informovat...
Jasně! Vyřešena i poslední záhada. Díky @meda: jsem se zamyslel nad tím, jakou roli má parametr readfactor a ještě pro jistotu si znova prošel jak Wiki, tak github, a teď už mi to dává smysl! A rovnou to i vyzkoušel u streamu z SCC, který jsem už jednou testoval (ben 10_ Alien Force 1x01 - průměrná bitrate má rozhodně pod 10 Mbps). A vyšlo to přesně tak, jak jsem předpokládali.
Při nastavené hodnotě readfactor = 20, se rychlost načítání pohybuje kolem 80 Mbps. Jakmile nastavím readfactor = 40, tak se rychlost posune k maximu mé linky, tedy lehce pod 150 Mbps, tedy stejně, jako u streamů s výrazně vyšším průměrným datovým tokem. Ještě to prověřím i při dalších kombinacích nastavení a rychlostech steramů, ale řekl bych, že mi to začalo dávat smysl.
A ještě poznámka k tomu, jak to, že někdy dojde k tomu, že se dopředný buffer naplní nad hodnotu 75 % a pak se začně postupně vyčerpávat až zpátky k hodnotě 75 %. Někdo se může zeptat, proč se to děje jen někdy a na čem to tedy vlastně závisí. I tady je ta odpoěď poměrně jednouduchá. Tady v tom případě záleží na tom, jak vysoký je datový tok vlastního streamu. Pokud je totiž dostatečně vysoký (oproti maximální rychlosti komunikace), tak se ten zpětný buffer zaplní dříve, než se stačí zaplnit ten dopředný. Tzn. že maximální zaplnění dopředného bufferu nikdy nepřekročí 75 %. Je-li ale ten datový tok vlastního streamu menší, tak dojde k tomu, že se dříve zaplní dopředný buffer než ten zpětný, tudíž ten algoritmus načítá dál přes limit 75 %, a to až do chvíle, než se to srovná. V okamžikui, kdy jsou oba bufferu naplněné, tak se ten dopředný přestane načítat, a to až do doby, než jeho zaplnění klesne na 75 %.
A protože mi ještě vrtá hlavou ta odpověď @meda: v jeho bodě 2, přemýšlel jsem ještě o jeho domněnce. A možná že by to mohl být klíč k té záhadě, jak to, že se někdy významně sníží rychlost načítání.
Jak @meda: píše, mohl by ten algoritmu na základě spočítaného poměru rychlosti načítání a rychlosti vlastního streamu skutečně usoudit, že není třeba načítat tak rychle a rychlost snížit. To ostatně koresponduje s podobnou teorií, kterou jsem před pár příspěvky také uvedl. Jenže já si myslel, že by tohle mohl dělat přímo Webshare, ale mně samotnému se to zdálo nepravdpěodobné ("To se pak člověk na něco upne..."). Ale Méďova teorie to vysvětluje smysluplně.
Takže další hraní bude s hodnotou readfactor, který by na tohle chování možná měl mít vliv... Až budu mít zase chuť na laborování, vyzkouším několik nastavení a pak tu budu informovat...
Jasně! Vyřešena i poslední záhada. Díky @meda: jsem se zamyslel nad tím, jakou roli má parametr readfactor a ještě pro jistotu si znova prošel jak Wiki, tak github, a teď už mi to dává smysl! A rovnou to i vyzkoušel u streamu z SCC, který jsem už jednou testoval (ben 10_ Alien Force 1x01 - průměrná bitrate má rozhodně pod 10 Mbps). A vyšlo to přesně tak, jak jsem předpokládali.
Při nastavené hodnotě readfactor = 20, se rychlost načítání pohybuje kolem 80 Mbps. Jakmile nastavím readfactor = 40, tak se rychlost posune k maximu mé linky, tedy lehce pod 150 Mbps, tedy stejně, jako u streamů s výrazně vyšším průměrným datovým tokem. Ještě to prověřím i při dalších kombinacích nastavení a rychlostech steramů, ale řekl bych, že mi to začalo dávat smysl.