18.1.2024, 11:17
(Tento příspěvek byl naposledy změněn: 18.1.2024, 13:21 uživatelem JiRo.
Důvod úpravy: Překlepy
)
Jak nejlépe nastavit video cache - <memorysize>
Všichni známe obvyklou poučku, podle které se má volit hodnota <memorysize>, tedy stanovení maximální bezpečné velikost paměti video cache. Spočítá se jako 1/3 volné paměti po spuštění Kodi. Navíc se ještě doporučuje, ponechat pro vypočtěnou hodnotu nějakou "vatu" a proto se spočítané hodnota násobí ještě koeficientem, jehož hodnota se doporučuje někde v rozmezí 0,9 - 0,85. Kromě toho, a to se samozřejmě explicitně neuvádí, je třeba myslet i na to, co za procesy v systému, ve kterém běží Kodi, ještě běží také a může být, asynchornně a na pozadí, spuštěno kdykoliv po startu Kodi. Týká se to zejméně těch systémů, u kterých ke spuštění nějakého procesu, který si může alokovat významné množství paměti RAM, může dojít. A tím spíše, čím je ta případná alokace větší. Tak takhle to známe a řídíme se tím, stejně jako řada nástrojů, které nám onu doporučovanou maximální hodnotu <memorysize> vypočtou nebo dokonce i nastaví. Je to skutečně tak? V současné aktulní verzi, tedy Kodi 20, a tím spíše pak ve verzi následující, Kodi 21? Není! Ono je to, s velikostí stanovení maximální hodnoty <memorysize>, pravděpodobně trochu jinak.
Pokud se totiž, při stanovení nutné paměti pro <memorysize> hovoří o trojnásobku, týká se to toho, kolik může video cache požadovat maximálně paměti. To číslo 3 je ale pozůstatek z požadavku starších verzí Kodi, kde byla v rámci přehrávání definovaná video cache jako trojice bufferů označovaných jako history buffer, current buffer a lookahead buffer. To už ale tak úplně neplatí, protože to rozdělení a správa video cache je teď už trochu jiná. Nicméně ten trojnásobek v požadavcích zůstal, byť ho fakticky Kodi už nevyžaduje. Z dlouhodobého testování se potvrzuje, že video cache u posledních několika verzí Kodi je limitována pouze volnou pamětí, případně absolutním limitem 1 GB, což mimochodem potvrzuje i verze Kodi 21, kde je i tento absolutní limit v nastavení vidět. Samozřejmě si uživatel musí nechat nějakou rezervu, protože obsazení paměti se v průběhu běhu Kodi a jeho doplňků může měnit. To platí neustále, aniž by ale bylo řečeno, jak velká ta rezerva musí být. To totiž závisí na celé řadě dalších okolností, z nichž řada může být řešena (asynchronně, tedy bez závisloti na tom, co se v Kodi právě děje, jaká funkce je tam spuštěna) mimo Kodi (viz předchozí odstavec).
A jak tedy vlastně video cache funguje dnes? Můžeme si ji představit jako cyklický či kruhový buffer, do kterého se po spuštění videa začnou načítat data. Zároveň si z něj data čtou. To provádí Kodi player. Zatímco data se do bufferu videocache zapisují rychlostí čtení ze zdroje, ta rychlost je násobkem (<readfactor>) rychlosti (bitstream) přehrávaného streamu, player je čte rychlostí odpovídající právě hodnotě bitstreamu. Algoritmus obsluhy cyklického bufferu je nastaven tak, že v něm zůstává uložena část dat již přehraného streamu. Pro tuto část je vyhrazeno maximálně 25 % velikosti video cache. Zbytek, pak je vyhrazen pro data, která jsou do video cache přednačítána. Zatímco té první části se říká zpětný (backward) buffer, té druhé dopředný (forward) buffer. Ve zdrojové kódu Kodi je pak pevně je definováno, jaká maximální velikost aktuálně nastavené velikosti video cache bude vyhrazena pro zpětný (backward) buffer. To je dnes 25 %. Pro dopředný (forward) buffer je pak vždy alokován rozdíl 100 % mínus aktuální obsazení zpětného bufferu. V průběhu přehrávání, na jeho počátku, nebo po velkém skoku v přehrávání vpřed a nebo zpět, tak může krátkodobě dojít k tomu, že dopředný buffer obsadí více než 75 %. To se stane v případě, když rychlost načítání dat do video cache je mnohem vyšší, než rychlost čtení z ní. Ta, jak jsme si už řekli, odpovídá hodnotě bitstream přehrávaného streamu. V tomto případě pak záleží jednak na nastavené hodnotě <readfactor> a pak samozřejmě na limitu rychlosti čtení dat ze zdroje dat absolutně. A abych to celé dosadil do praktické roviny, aktuální velikost dopředného bufferu můžeme v reálu, při přehrávání, vidět, pokud si v Kodi spustíme Player Debug Info (ctrl+shift+o) jako hodnotu položky forward. Tam si také můžeme ověřit, po ustálení hranice mezi dopředným a zpětným bufferem, že obsazení toho dopředného skutečně odpovídá 75 % alokované velikosti pro video cache, tedy hodnotě uložené v <memorysize> nebo hodnotě v nastavení (u Kodi 21).
Já sám jsem měl s tím, pochopit současnou funkci video cache, dost problémy. Měl jsem plno otázek, které jsme si při svých pokusech s přehrávání v Kodi a nastavením video cache kladl. Bohužel mi na ně nikdo, ani zde, ale ani na fóru kodi.tv nedokázal odpovědět. Až teprve řada testů a analýz zdrojového kódu Kodi mi na ně dala, neříkám, že absolutně správnou, ale spíše nejpravděpodobnější odpověď. Pokud někoho zajímá, jak jsem v této oblasti postupně dospíval ke konečnému poznání, může se podívat na Strategie využívání video cache.
A pokud někoho, při čtění mých úvah, napadla určitá spojitost se zmiňovaným historickým členěním video cache na history buffer, current buffer a lookahead buffer a dnesním rozdělením na backward a forward buffer, myslím, že jste na dobré cestě to pochopit. Celé to pak do sebe do určité míry zapadá. A tím spíše je pak jasné, odkud se vzala ona trojka (či jedna třetina) v onom stále ještě existujícím doporučení na to, jak parametry video cache nastavit.
Všichni známe obvyklou poučku, podle které se má volit hodnota <memorysize>, tedy stanovení maximální bezpečné velikost paměti video cache. Spočítá se jako 1/3 volné paměti po spuštění Kodi. Navíc se ještě doporučuje, ponechat pro vypočtěnou hodnotu nějakou "vatu" a proto se spočítané hodnota násobí ještě koeficientem, jehož hodnota se doporučuje někde v rozmezí 0,9 - 0,85. Kromě toho, a to se samozřejmě explicitně neuvádí, je třeba myslet i na to, co za procesy v systému, ve kterém běží Kodi, ještě běží také a může být, asynchornně a na pozadí, spuštěno kdykoliv po startu Kodi. Týká se to zejméně těch systémů, u kterých ke spuštění nějakého procesu, který si může alokovat významné množství paměti RAM, může dojít. A tím spíše, čím je ta případná alokace větší. Tak takhle to známe a řídíme se tím, stejně jako řada nástrojů, které nám onu doporučovanou maximální hodnotu <memorysize> vypočtou nebo dokonce i nastaví. Je to skutečně tak? V současné aktulní verzi, tedy Kodi 20, a tím spíše pak ve verzi následující, Kodi 21? Není! Ono je to, s velikostí stanovení maximální hodnoty <memorysize>, pravděpodobně trochu jinak.
Pokud se totiž, při stanovení nutné paměti pro <memorysize> hovoří o trojnásobku, týká se to toho, kolik může video cache požadovat maximálně paměti. To číslo 3 je ale pozůstatek z požadavku starších verzí Kodi, kde byla v rámci přehrávání definovaná video cache jako trojice bufferů označovaných jako history buffer, current buffer a lookahead buffer. To už ale tak úplně neplatí, protože to rozdělení a správa video cache je teď už trochu jiná. Nicméně ten trojnásobek v požadavcích zůstal, byť ho fakticky Kodi už nevyžaduje. Z dlouhodobého testování se potvrzuje, že video cache u posledních několika verzí Kodi je limitována pouze volnou pamětí, případně absolutním limitem 1 GB, což mimochodem potvrzuje i verze Kodi 21, kde je i tento absolutní limit v nastavení vidět. Samozřejmě si uživatel musí nechat nějakou rezervu, protože obsazení paměti se v průběhu běhu Kodi a jeho doplňků může měnit. To platí neustále, aniž by ale bylo řečeno, jak velká ta rezerva musí být. To totiž závisí na celé řadě dalších okolností, z nichž řada může být řešena (asynchronně, tedy bez závisloti na tom, co se v Kodi právě děje, jaká funkce je tam spuštěna) mimo Kodi (viz předchozí odstavec).
A jak tedy vlastně video cache funguje dnes? Můžeme si ji představit jako cyklický či kruhový buffer, do kterého se po spuštění videa začnou načítat data. Zároveň si z něj data čtou. To provádí Kodi player. Zatímco data se do bufferu videocache zapisují rychlostí čtení ze zdroje, ta rychlost je násobkem (<readfactor>) rychlosti (bitstream) přehrávaného streamu, player je čte rychlostí odpovídající právě hodnotě bitstreamu. Algoritmus obsluhy cyklického bufferu je nastaven tak, že v něm zůstává uložena část dat již přehraného streamu. Pro tuto část je vyhrazeno maximálně 25 % velikosti video cache. Zbytek, pak je vyhrazen pro data, která jsou do video cache přednačítána. Zatímco té první části se říká zpětný (backward) buffer, té druhé dopředný (forward) buffer. Ve zdrojové kódu Kodi je pak pevně je definováno, jaká maximální velikost aktuálně nastavené velikosti video cache bude vyhrazena pro zpětný (backward) buffer. To je dnes 25 %. Pro dopředný (forward) buffer je pak vždy alokován rozdíl 100 % mínus aktuální obsazení zpětného bufferu. V průběhu přehrávání, na jeho počátku, nebo po velkém skoku v přehrávání vpřed a nebo zpět, tak může krátkodobě dojít k tomu, že dopředný buffer obsadí více než 75 %. To se stane v případě, když rychlost načítání dat do video cache je mnohem vyšší, než rychlost čtení z ní. Ta, jak jsme si už řekli, odpovídá hodnotě bitstream přehrávaného streamu. V tomto případě pak záleží jednak na nastavené hodnotě <readfactor> a pak samozřejmě na limitu rychlosti čtení dat ze zdroje dat absolutně. A abych to celé dosadil do praktické roviny, aktuální velikost dopředného bufferu můžeme v reálu, při přehrávání, vidět, pokud si v Kodi spustíme Player Debug Info (ctrl+shift+o) jako hodnotu položky forward. Tam si také můžeme ověřit, po ustálení hranice mezi dopředným a zpětným bufferem, že obsazení toho dopředného skutečně odpovídá 75 % alokované velikosti pro video cache, tedy hodnotě uložené v <memorysize> nebo hodnotě v nastavení (u Kodi 21).
Já sám jsem měl s tím, pochopit současnou funkci video cache, dost problémy. Měl jsem plno otázek, které jsme si při svých pokusech s přehrávání v Kodi a nastavením video cache kladl. Bohužel mi na ně nikdo, ani zde, ale ani na fóru kodi.tv nedokázal odpovědět. Až teprve řada testů a analýz zdrojového kódu Kodi mi na ně dala, neříkám, že absolutně správnou, ale spíše nejpravděpodobnější odpověď. Pokud někoho zajímá, jak jsem v této oblasti postupně dospíval ke konečnému poznání, může se podívat na Strategie využívání video cache.
A pokud někoho, při čtění mých úvah, napadla určitá spojitost se zmiňovaným historickým členěním video cache na history buffer, current buffer a lookahead buffer a dnesním rozdělením na backward a forward buffer, myslím, že jste na dobré cestě to pochopit. Celé to pak do sebe do určité míry zapadá. A tím spíše je pak jasné, odkud se vzala ona trojka (či jedna třetina) v onom stále ještě existujícím doporučení na to, jak parametry video cache nastavit.