Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Škaredé skratky, trošku vysvetlenia.
Keďže vývoj Xorg ide míľovými krokmi vpred, čo sa týka nových infraštruktúr ako napr. TTM, GEM, DRI2, KMS a iné, rozhodol som sa trošku vysvetliť niektoré skratky, ktoré niekomu vôbec nič nepovedia.
KMS (Kernel Mode-setting) je pravdepodobne najviditeľnejšou novinkou, ktorá nás poteší. Každý používateľ Linuxu si iste niekedy všimol, že pri štarte OS obrazovka niekoľkokrát preblikne. Jedná sa o zmenu rozlíšenia na monitore - kernel si nastavý pre framebuffer jedno rozlíšenie a potom príde Xorg a ten si zase iné. Pri prepínaní na virtuálne konzoly sa to deje znovu. A tento problém rieši práve KMS - nastavovanie rozlíšenia (a tuším aj obnovovacej frekvencie) je spravované len kernelom a Xorg môže len požiadať o zmenu módu. Avšak práve táto zmena vyžaduje aby sa s video pamäťou pracovalo v jadre.
TTM (Translation Table Maps) bolo odpoveďou na riešenie manažmentu video pamäte v jadre od Tungsten Graphics. Aj napriek tomu, že API pre TTM bolo komplikované a vývojári sa stažovali, tak ho začali používať. Intel prišiel s GEM (Graphics Execution Manager), ktorý mal jednoduchšie API a (ževraj) viac vyhovoval potrebám moderných grafických kariet. Názorom proti GEM bolo, že bol písaný len s ohľadom na potreby Intel kariet. Samozrejme dnes už vieme, že od jadra 2.6.28 je GEM zahrnutý, čo znamená, že všetky ovládače napísané pre TTM by mali byť prepísané na použitie GEM. No nie nevyhnutne - napr. driver xf86-video-api využíva tzv. "GEM-ified TTM". Driver tak volá TTM, no volania sú prevádzané na GEM, čo potvrdilo, že GEM je vhodný aj na iné karty ako tie od Intelu. Chaos, čo? ;)
Myslím, že už dosť ľudí počulo o DRI (Direct Rendering Infrastructure), ktoré je zodpovedné za akcelerované vykresľovanie toho, čo je na obrazovke (najmä 3D). Xorg nemôže priamo pristupovať k harvéru (len kernel môže) a tak bol vymyslený DRM (Direct Rendering Manager) v podobe dvoch modulov pre kernel - jeden všeobecný a druhý špecifický pre dané železo. Ďalej je potrebný ešte userspace driver pre grafickú kartu, ktorá komunikuje s DRM a nakoniec už len nejaký X server, ktorý všetko preposiela až k hardvéru.
DRI2 je teda nové DRI (kto by to bol povedal? :) ) a rieši problémy, ktoré vyplývali zo starého dizajnu. Neviem konkrétne povedať, čo sa zmenilo alebo aká je nová architektúra, takže dúfam, že sa vyjadrí niekto vzdelanejší v diskusií. :)
Avšak môžem povedať, že jednou zo zmien je vykresľovanie. To sa nedeje priamo do framebufferu (resp. priamo na obrazovku), no do pamäte, ktorú spravuje GEM. Tým pádom môže kompozitný manažér robiť všeliaké pekné veci... ;)
Z pohľadu na API sú to dve totožné veci. Avšak líšia sa v implementácií - kým EXA používa starú architektúru, UXA (UMA Acceleration Architecture) používa spomínaný GEM. Len spomeniem, že EXA je náhradou za starú akceleračnú architektúru XAA.
Samozrejme to nie je všetko - existuje ešte kopa ďalších vecí, ktoré by tu mohli byť spomenuté ako napr. Gallium3D, XI2, XGE, MPX, Glucose, Wayland, či možno ešte ďalšie ako VA-API, XvMBC, VDPAU... Avšak to by bolo veľa písmenkového guľášu naraz. ;)
Tiskni
Sdílej:
VDPAU doporučuji, můj Athlon X2 5200+ EE nestíhal přehrávat Resident Evil 1 v 1080p (se škálováním na 720p kvůli malé obrazovce) - nestíhal to ve Windows ani v Linuxu přes VLC ani mplayer, takže chyba není v OS. Pak jsem si zkompiloval nejnovější beta driver od nvidie, mplayer s podporou VDPAU a video spustil - nehrálo, ale díky Davidovi se to podařilo zprovoznit (patří mu mé díky) a jede to opravdu rychle.
Není to rychlé, ale jede to přesně tak jak to jet má. Jinak pro přehrávání pomocí CPU doporučuji nejnovější svn snapshot a -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all
.
Abych ale jen nechválil, stále mi s VDPAU nejde Battlestar Galactica v 720p, vždy se zobrazí první sekunda filmu a pak se to stopne a mplayer se ukončí (nespadne však, ani nic nezahlásí, jako by si myslel, že je konec streamu, přitom to bez VDPAU přehraje celé).
Zaplní se buffer a rozhodí se synchronizace. Pauzni to pomocí mezerníku a pak zase odpauzuj. Obraz dožene zvuk a pak to zase normálně běží.
Jinak pro autora blogu jediná otázka: Proč je to v blogu a ne tady?
Podla referencii od mojho brata tie optiony pre mplayer sice urychlia prehravanie, ale za cenu viditelneho zhorsenia obrazu.
Je pravda, že třeba u některých videí z Applu to vidět je, protože se mimo přeskočení několika testů a přidáním několika předpokladů přeskakuje také deblocking filtr, ale u HD ripů s podílem šumu pomalu větším než signálu jsem si ještě jediného bloku nevšiml. Také je pravda, že u takových videí už je to trošku náročnější na rozkódování. Ale myslím si že jako cena za přehrání videa o vyskoém rozlišení na pomalém HW je to velice dobrá cena(Trailery z Applu o 1080p přehraju na jednom jádře Turionu X2 o 800Mhz)
Ma NB s Pentiom 1GHz (tusim, mozno 1.1GHz alebo nieco take, neviem uz presne). A ten procak nestiha - raz cas (par sekund) trhne obraz, ked mplayer zahodi par framov. Takze po tych optionoch nestiha o nieco menej, ale za cenu viditelne kockovanejsieho obrazu.
Jasně, ono záleží hodně i na Levelu a počtu bloků ve snímku. Přiznávám, že když jsem si pustil teď v noci HD rip s LCD na plný jas, tak šum byl viditelně roztaženější(efekt rozkódování o menším rozlišení…i když nevím rozlišení čeho, protože hrany byly furt stejně ostré a ani z nich nevyčuhovala barevná složka). Na druhou stranu ve dne a nebo na mém CRT jsem si toho vůbec nevšiml a kontrast se dá zvýšit vždy. Cena za výkon je to IHMO docela dobrá. Starost mi ovšem dělá, že se také přeskakují nějaké referenční snímky, takže v tmavých místech s tím imbecilním šumem se to po pár pohybech kamery pěkně rozmázne a zvláště v tmavých částech už si takového fleku jde všimnout. Ale na procesoru o 1,6Ghz s oběma jádry jsem právě shlédl celý HD rip(takže se muselo jak dekódovat video, tak i audio, muselo se to vykreslovat na vo, musel se mixovat zvuk do dvou kanálu a ještě s hrtf filtrem) a měl ještě slušnou rezervu. A to mi ještě jede v 32-bitovém módu.
$ ./mplayer -vfm ffmpeg -lavdopts threads=2:lowres=3:fast:skiploopfilter=all -ac null -vo null -cache 8129 -endpos 100 -benchmark ~/Videa/Resident_Evil_Extinction/Resident.Evil.Extinction.2007.Blu-ray.1080p.DTS.x264-CtrlHD.mkv MPlayer dev-SVN-rUNKNOWN-4.1.3 (C) 2000-2009 MPlayer Team CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-60 (Family: 15, Model: 104, Stepping: 1) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 … V: 100.0 0/ 0 102% 0% 0.0% 0 0 48% BENCHMARKs: VC: 100.783s VO: 0.015s A: 0.000s Sys: 1.400s = 102.198s BENCHMARK%: VC: 98.6154% VO: 0.0146% A: 0.0000% Sys: 1.3698% = 100.0000% Exiting... (End of file) $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 104 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60 stepping : 1 cpu MHz : 800.000 cache size : 512 KB
Právě hledám vhodnější video výstup(prej vidx a nebo vdpau), protože xv dost žere. Už jen kdyby integrovali i větší cache pro dekódovaná data(paměti mám furt dost)…pak by to třeba s přežvýkaným audiem a s menšími obtížemi šlo i na těch 800Mhz.
$ ./mplayer -vfm ffmpeg -lavdopts…
Doprčic. Co je to ten editor zase za krám?:
$ ./mplayer -vfm ffmpeg -lavdopts threads=2:lowres=3:fast:skiploopfilter=all -ac null -vo null -cache 8129 -endpos 100 -benchmark ~/Videa/Resident_Evil_Extinction/Resident.Evil.Extinction.2007.Blu-ray.1080p.DTS.x264-CtrlHD.mkv MPlayer dev-SVN-rUNKNOWN-4.1.3 (C) 2000-2009 MPlayer Team CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-60 (Family: 15, Model: 104, Stepping: 1) CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1 Compiled for x86 CPU with extensions: MMX MMX2 3DNow 3DNowEx SSE SSE2 … V: 100.0 0/ 0 102% 0% 0.0% 0 0 48% BENCHMARKs: VC: 100.783s VO: 0.015s A: 0.000s Sys: 1.400s = 102.198s BENCHMARK%: VC: 98.6154% VO: 0.0146% A: 0.0000% Sys: 1.3698% = 100.0000% Exiting... (End of file) $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 104 model name : AMD Turion(tm) 64 X2 Mobile Technology TL-60 stepping : 1 cpu MHz : 800.000 cache size : 512 KB …
Zaplní se buffer a rozhodí se synchronizace. Pauzni to pomocí mezerníku a pak zase odpauzuj. Obraz dožene zvuk a pak to zase normálně běží.
Každou sekundu to pauzovat nebudu, nejsem magor (teda vlastně jsem, ale stejně ... )
git clone git://repo.or.cz/mplayer cd mplayer git checkout -t -b mt origin/mt git submodule init git submodule update ./configure && make..... mplayer -lavdopts threads=2 ....Jako bonus k tomu dostaneš vylepšenou pauzu
Muzes to hodit do slovniku?
Ok, dám... Len to musím nejako krajšie sformulovať a vyhodiť balast.
Dôvodov, že to nejde môže byť viacero. Napr. na mojom systéme nevyužívam ani jednu zo spomínaných lebo binárny driver pre moju nvidiu nič z toho nepodporuje. A driver nouveau je zase pre mňa nepoužiteľný. :)