Poslední příspěvky

21

/dev/null / podivná situace po FUSE-mount - n

« Poslední příspěvek od mikesznovu kdy Dnes v 08:02:11 »

Na Ubuntu (5.4.211  /  20.*něco)mi konkrétně nešel exfat, takže jsem si stáhl exfat fuse a mountnul 
sudo mount.exfat-fuse  /dev/sda1 /media/vopice
hlavní role prohlížeč Caja.

Vše normálně fungovalo. Tím myslím,  že šly třeba otevřít a mazat. V externím programu se otevřely. teď z hlavy neřeknu

le po odhlášní a přihlášení vidím v levém sloupci Devices prohlížeče Caja Devices  dvojmo "Karta" (což je FS label) ,
-jedna bez ikonky Eject s titulkem Mount and open Karta - v té vidím správně náhledy , v adressbaru mám  tužku, O,/, media, vopice, DCIM,>
-druhá  stitulkem  /media/vopice a bez ikonky Eject - ta nejde mountnut - ukazuje to Error mounting
Soubory mohu procházet a dokonce k nim Caja Ukazuje Náhledy.
Jenže nejde je otvírta, Shotwell hlásí blackscreen "Photo source missing :/media...JPG
MATE Image viewer hlásí IO Error
To samé i když tam lezu přes /Filesystem/media/vopice

Nefunguje ani přístup přes terminál. (zalogovaný po odhlášení/přihlášení jsem na stejné username) : errorreading "...JPG" I/O error

proč mountnutí funguje jen do prvního přihlášení v MATE? A proč před logoutem to fungovalo???

soubory mají práva 777 root:root

Tfuj Tfuj MATE, Tfuj Caja. to jsou samý bomby v Desktop Environmentu !

22

Sítě / Re:Výběr síťových prvků

« Poslední příspěvek od Molex1 kdy Dnes v 07:42:34 »

Zeptám se, zda tedy trváte na tom řešení od Ubiquiti ?
To řešení od TP-Linku Omada by mělo fungovat obdobně (je to také softwarově manageovaná síť) navíc myslím, že vzhledem k velikosti sítě je i vhodnější a navíc odpadne nutnost mít ještě ten PoE switch (několik PoE portů je přímo integrováno v routeru). Mě celkem překvapila kromě ceny hlavně výrazně nižší spotřeba proti Ubiquiti a proto toto zvažuji, že bych instaloval domů... Celkem by mě zajímaly zkušenosti, těch, kteří již TP-Link řešení Omada realizovali..

TP-Link ER7212PC
pak již jen ta APčka např. TP-Link EAP650

23

Desktop / Re:odpojit/zapojit přepnout klávesnici pro možnost měnit layout

« Poslední příspěvek od mikesznovu kdy Dnes v 07:42:16 »

Tak nakonec jsem musel opojit a vypojit ,klávesnici, aby to fungovalo. Tfuj tfuj linux
(to je hezké že jich je 37, ale nefungujou. taky jsem si našel svůj oblíbený Alt Shift jehlu v kupce sena, ale )

24

Desktop / Re:Nelze přepnout klávesnici a indikátor je k ničemu

« Poslední příspěvek od k3dAR kdy Dnes v 02:52:21 »

BTW: v Xfce to mam na par kliknuti, moznosti "modifikacnich klaves" sem napocital 37 ;-) ale hlavne lock/logout/reboot mi s tim nic neudela, jednou sem nastavil po instalaci a pak proste funguje :-)

25

Desktop / Re:Nelze přepnout klávesnici a indikátor je k ničemu

« Poslední příspěvek od RDa kdy Dnes v 01:32:54 »

Sice jsem nerebootoval, jen prubezne zamykal obrazovku, ale jazykove nastaveni ztraceno.. nefungovalo prepinani ani cestina. Skript z predesle zpravy pomohl. Zamknuti a odemknuti plochy ale nyni nezpusobilo ztratu jazykovych nastaveni.. takze nevim kdy se to muze ztratit :/

26

Software / Re:VP9 do HEVC bez komprese pomocí FFMpeg

« Poslední příspěvek od Michal Šmucr kdy Dnes v 00:56:34 »

Nekóduju hodinová videa (a pořád používám kodek AVC  x264 / h264_qsv )  Já to ale beru tak, že (u mě quicksync) je brutálně rychlý, takže -look_ahead to sice znatelně zpomalí (možná o 30%).
..
-konstatní kvantitizér se už dávno nedoporučuje
..
-crf u quicksync nefunguje (zapisuje se jinak, asi přes -q:v)

Quicksync (QSV) je něco jiného než NVENC.
Alternativa k CRF (z x264, x265) je to, co jsi už psal, tzn ICQ a LA_ICQ s lookaheadem, parametr je -global_quality.

Bohužel u Intelu je QSV občas problematické, jsou rozdíly nejen mezi hardwary a bohužel i operačními systémy.
https://www.intel.com/content/www/us/en/developer/articles/technical/common-bitrate-control-methods-in-intel-media-sdk.html
ICQ s lookaheadem (LA_ICQ) na Windows funguje jen pro H264, pro HEVC se předá parametr, ale nic to neprovede. Tohle platí minimálně od Skylake až po Comet Lake. Jak je to u novějších XE grafik, nevím.

U NVENCu je v podstatě CBR, VBR (jen přidáš minrate, maxrate k -v:b) a pak zmníněný CQ, který je nejrychlejší. A pokud nevadí, že trochu víc lítá bitrate (pro nějaké archivní účely je to víceméně jedno, pokud to nestreamuješ, nebo nemáš nějaké omezení s konkrétním HW dekodérem). Nad rámec toho se dá zapnout ještě spatial a temporal AQ, což v podstatě dokáže dynamicky přizpůsobit alokaci přidáním na určité statické I snímky, nebo na gradienty v rámci snímku. Ale v podstatě to víceméně spíš přidává nad to, co vyhodnotí ten hlavní vybraný rc mechanismus. Takže ten se za určitých okolností dá i trochu podstřelit.
Ale je to všechno o vyzkoušení na konkrétním materiálu a samozřejmě požadavcích (malý bitrate, nízká latence, nejrychlejší kódování jde typicky proti sobě). A někdy i to, co se obecně nedoporučuje, může pro konkrétní situaci dobře zafungovat.

27

Software / Re:VP9 do HEVC bez komprese pomocí FFMpeg

« Poslední příspěvek od Michal Šmucr kdy Dnes v 00:29:28 »

Přesně tak. Ještě bych zvážil, pokud tolik nezáleží na času a CPU komprese:

• -preset slow - pomalejší běh ale menší výsledný soubor. Jedna z věcí kterou ovlivňuje je třeba ten tebou zmíněný rc-lookahead - viz https://x265.readthedocs.io/en/stable/presets.html

Ano, výběr výpočetně náročnějšího presetu je samozřejmě další možnost. Ale většinou to opravdu začne dávat smysl v momentě, kdy jsem omezený velikostí/bitratem a mám třeba trochu komplikovanější scény (šum, déšť, kresba v tmavých plochách nebo hodně pohybu).
Ještě dodám, spíš pro info a tazatele, kdyby si s tím chtěl hrát (přestože zrovna u tohohle relativně jednoduchého videa z MSG, mi přijde, že by se to začalo výrazněji projevovat až tak na polovičním bitrate okolo 6-8 Mbit/s, pro pokusy bych dal spíš typově něco jako sport nebo jízdu na horské dráze

Pokud se u x265 jen přepne na vyšší preset (z medium na slow, případně slower), tak se bez úpravy CRF výsledný soubor typicky zvětší. Krom zmíněného delšího lookaheadu, to ovlivní např. i pohybovou analýzu - zapne to pokročilejší partitioning v prediktoru, star ME, zvýší se počet iterací v subpel ME atp.
Jinak řečeno, je tam víc detailů k zakódování.
Takže je třeba kompenzovat vyšším CRF nebo QP pro případné snížení velikosti, pokud o to jde.

• -x265-params pools=none (nebo třeba 4) - vypnutí multithreadingu, x265 nějak paralelizuje přes snímky a má pak prý horší kompresi, protože nemůže využít všech rozdílů mezi snímky

Tohle bych úplně nedělal. Sám jsem šoupal s poolem akorát v případě, kdy jsem řešil souběžný běh na dvou-socketovém transkódovacím serveru, s více souběžnými úlohami.

Ale k meritu věci. Ano teoreticky při nějakých hodně dynamických scénách a specifickém nastavení to může zhoršit predikci pohybu, i alokaci (RC). Ale mimo nějaké patologie to bude ve výsledku se budeme bavit max. o nějakých hodnotách třeba do procenta velikosti se stejnou degradací.
Pokud bych měl tvrdý velikostní limit, čas si s tím hrát a něco by se mi třeba začalo obrazově sypat, bylo by to až někde na konci těch možných optimalizací. Je tam x dalších a podle mě zásadnějších parametrů, které můžou ovlivnit kompresi (např. ten výčet, co ovládá, parametr film-grain, různé parametrizace přes vážení).
A když už bych chtěl tohle vypnout, tak spíš sáhnu po parametru --frame-threads a ten nastavím na 1 (nebo kolik chci).
Pokud nastavím pools=none, tak nejen že to komplet vše serializuju (včetně věcí, co nemají vliv na výstup) a bude to líné jak vandrácká hůl, protože komplet vypnu asynchronní workery, ale implicitně vyruším i paralelizaci při zpracování CTU (32x36 nebo 64x64 px ekvivalent makrobloku z MPEGu) v rámci snímku.
Tam se používá tzv. WPP, kdy se každý z nich se referencuje na dva okolní (první nad, druhý nad a vpravo). Takže jakmile se udělají první dva CTU, může se spustit další paralelní počítání na řádku pod ním. Což samozřejmě výrazně zrychlí kódování a obráceně i dekódování. Je tam s tím i nějaký drobný overhead ve streamu, protože se musí přidat nějaká metadata a pointery pro skoky na začátky každého řádku, plus se lehce může dál zvětšit stream, kvůli zvýšené entropii z paralelního kódování řádků (vs celého snímku).
Pokud ve streamu tyhle metadata a pointery vůbec nejsou, tzn. když se implicitně vypne WPP, tak pak nemůže paralelizovat ani dekodér a vypneš jednu z výrazných fíčur HEVC. Což já většinou nechci (bude samozřejmě rozdíl, jestli je tam nějaký HW offload, kterému to nevadí dekódovat sekvenčně po jednom CTU a jestli je tam třeba 480p vs 8K. atd.).

28

Server / Re:Certifikáty na RO filesystéme

« Poslední příspěvek od alex6bbc kdy 29. 09. 2024, 23:40:36 »

clientovi (web browser) staci mit certifikat od CA (certifikacni autority), ktery je soucasti instalace a nepotrebuje mit u sebe konkretni certifikat ziskany z letsencrypt. server posle clientovi svoje verejne info k certifikatu a client vyuzije CA k overeni.

29

Server / Certifikáty na souborovém systému jen ke čtení

« Poslední příspěvek od majvan kdy 29. 09. 2024, 22:58:10 »

Mám embedded zariadenie, ktoré má read-only root filesystem a ktoré bude nainštalované bez ďalšieho prístupu k nemu niekde v teréne.
Chcem dať naňho aplikačného klienta, ktorý komunikuje s https serverom, ktorý bude mať certifikát podpísaný od Let's Encrypt.

Ako zabezpečiť, aby bolo toto zariadenie stále schopné akceptovať certifikát https servera?
Akú periódu obnovy má Let's Encrypt certifikát? Ako funguje v Linuxe update trusted root certifikátov?

30

Desktop / Re:Proč mi zabiják OOM zabil Chromium

« Poslední příspěvek od CPU kdy 29. 09. 2024, 22:18:13 »

Chrom se dá vrátit do stavu před uzavřením, tj. znovu otevřít taby klávesovou zkratkou, pokud se tedy neobnoví rovnou sám.