Poslední příspěvky

1

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.

2

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.).

3

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.

4

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?

5

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.

6

Server / Re:Virtualizace Hyper-V vs. VM

« Poslední příspěvek od Vít Šesták (v6ak) kdy 29. 09. 2024, 21:59:32 »

V Linuxu je ještě virtualizace postavená na XEN, což je na stejné úrovni jako KVM+QEMU. XEN není součástí upstream jádra, musí se patchovat/binární stahovat někde jinde. Ale asi bych to zkrátil tak, že XEN je mrtev...

Xen je hypervisor, běží tedy nad Linuxem.

Pachovat – jaké patche? Kdysi dávno tu byl Xenlinux, znamenalo to separátní patche, ale to bylo do kernelu verze 2.6.18. Tedy docela dávno. Dnes místo toho máme pvops, které jsou součástí upstreamu. Navíc ne vždy jsou potřeba.

Navíc Xen má dnes mnoho způsobů virtualizace (původní legacy PV, plná virtualizace HVM a pak různé mezistupně, zejména PVH), pro HVM není potřeba speciální kernel, tam rozjedete třeba i Windows.

Druhá věc je, jak rozumně a uživatelsky přívětivě Xen nastavit. Přímo upravovat konfiguráky jsem nezkoušel. Umí to Qubes OS, ale je tam docela znát, že Windows pro ně není priorita.

7

Hardware / Re:Nový monitor na práci vývojáře

« Poslední příspěvek od ondrej _ kdy 29. 09. 2024, 21:23:29 »

Co místo dvou monitorů použít jeden ultraširokoúhlý?

Vyhýbal jsem se tomu kvůli sdílení obrazovky přes MS Teams, Zoom apod. Potřebuji při sdílení přepínat mezi aplikacemi, takže je potřeba sdílet celou obrazovku – a žádná z mně známých aplikací pro videokonference neumí sdílet jen půlku obrazovky. Ale alespoň některé širokoúhlé obrazovky umí vedle sebe zobrazovat dva různé vstupy, takže by šlo k počítači připojit jakoby dvě obrazovky, akorát by mezi nimi nebyl žádný rámeček ani mezera.

Máte někdo s takovým použitím pro vývoj zkušenost? Nebo tam vidíte nějaký problém?

Problém je, že teď mám hlavní monitor 4K, ale ultraširoké displeje se dělají jen 2×QHD (resp. viděl jsem jeden ultraširoký displej s 8K, ale za cenu asi tak dvou počítačů).

Skusal som to na mojom 30" a je mozne na vyber viacere moznosti ako rozdelit plochu(na polovicu alebo dve rozne velkosti vyrezu v jednom z rohov) ale na to je naozaj potrebny dostatocne velky monitor aby tie plochy boli dostatocne velke.

Pre mna je nevyhoda jedneho velkeho monitora v tom, ze nepotrebnu plochu nemozem vypnut ako druhy monitor. Nie vzdy tu celu velku plochu vyuzivam.

8

Sítě / Re:Firewall: může server být neviditelný?

« Poslední příspěvek od smoofy kdy 29. 09. 2024, 20:04:56 »

Ale zalezi

Tazatel umi nakonfigurovat jen svuj stroj (A), treba tak, ze bude vse zahazovat.
Vedle existuje hypoteticka adresa (B), ktera ale do site neni zapojena, resp. je vypnuta a neni tam aktivni ani WOL.

A ted existuje posledni router R, kterym jsou stroje s adresami A a B pripojeny do site.

Pokud budu skenovat adresy A a B, tak bude odezva z routru R jina - takze JSEM schopen rozlisit, zda stroj bezi, nebo nebezi.

Ono totiz existuji nizsi sitove vrstvy, ktere nemuzete odfiltrovat (napr. arp), pokud chcete zachovat funkcnost stroje A pro nejakou podmnozinu klientu.

Aby neslo tohle poznat - rozeznat stavy A vs B, tak by tazatel musel mit pod svoji spravou i posledni router R, a nastavit tam par specifickych pravidel.

Dulezite je urcit, jak presne budu scanovat

9

Sítě / Re:Firewall: může server být neviditelný?

« Poslední příspěvek od Filip Jirsák kdy 29. 09. 2024, 19:23:41 »

Tazatel umi nakonfigurovat jen svuj stroj (A), treba tak, ze bude vse zahazovat.

Aby neslo tohle poznat - rozeznat stavy A vs B, tak by tazatel musel mit pod svoji spravou i posledni router R, a nastavit tam par specifickych pravidel.

To je jen váš dohad, že tazatel chce konfigurovat cílový stroj a ne router.

Pokud budu skenovat adresy A a B, tak bude odezva z routru R jina - takze JSEM schopen rozlisit, zda stroj bezi, nebo nebezi.

Pokud by router odpovídal u vypnutého stroje třeba ICMP Destination host unreachable, nic vám nebrání tu samou odpověď poslat z cílového serveru při REJECTu pomocí --reject-with místo standardního ICMP Destination port unreachable.

10

Hardware / Re:Nový monitor na práci vývojáře

« Poslední příspěvek od anonacct kdy 29. 09. 2024, 17:07:52 »

Prohnutý širokoúhlý 40" je můj tip - jakmile si na to zvykneš už se nebudeš chtít vrátit zpět.