Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Copyright © 1998-2024 CDR server s.r.o.
Všechna práva vyhrazena.
ISSN 1804-5405.
Informace, že na zpracování jednoho snímku je 0,017–0,033 sekundy, je prosím pěkně odkud?
Hadam, ze prvni hodnota je pro rychlost prehravani 60 snimku za sekundu a druha pro 30 a to jsou tak nejak obecne pouzivane hodnoty u videa.
To možná jsou, ale z toho přece nijak nevyplývá, že grafika ten snímek nemůže zpracovávat déle.
A které ze slov Real Time ušlo Vaší pozornosti?
A co má zpracovávání v reálném čase společného s dobou trvání jednoho snímku? Proč myslíte, že jej nelze zpracovávat déle?
Ze by, kdyz se to nestihne do 1/30 s, to uz pak nebylo v realnem case?
Takže přehrávání se zpožděním o jeden snímek je ještě reálný čas, ale zpoždění o pět snímků už reálný čas není?
Když si pustíte zvuk do sluchátek přes Bluetooth, tak to není přehrávání v reálném čase? I když je latence třeba 200 ms, zatímco vzorkování zvuku je na 48 kHz?
Adame, tomu se říká dopravní zpoždění, a to na dobu pracovního taktu nemá žádný vliv. Jinak řečeno: i když zpozdíš přehrávání např. o 10 sekund (jako výpočetní "bonus"), tak oněch 10 sekund se ti nutně rozpočte mezi všechny snímky, tedy čím delší video, tím je takový "bonus" méně významný.
Dám ti jiný, zcela krásně představitelný příklad: dopravníkový pás, na jedné straně fůra písku a lopaťák, na druhé straně lopaťák a bezedná míchačka betonu (v rámci zjednodušení neřešme dávkování vody a cementu). Jakmile začne pískový lopaťák házet, tak ten míchačkový má přesně tolik času, jak dlouho bude trvat dopravení první kupky písku dopravníkem. Pak už musí házet ve stejném taktu jako pískový lopaťák, nechce-li mít u sebe na zemi zvětšující se kupku nezpracovaného písku. Může si samozřejmě "našetřit takty" a nějakou kupku na začátku nechat vytvořit, ale jakmile kupka dosáhne určeného maxima, tak už opět musí házet v taktu s prvním lopaťákem.
Ty jako kluk z dědiny to určitě pochopíš! :-)
Tak tak. A je uplně jedno, co se s tou lopatou písku děje, a jak dlouho po tom pásu jede, a jestli ji nejdřív vezme lopaťák, pak jede po pásu, a pak padá do míchačky, jestli se mezi tím ještě prolejvá vodou, přimíchává se k tomu cement a bůhví co, pokud se to na jedné straně sype na ten pás stejným tempem a na druhé straně to z toho pásu stejným tempem padá.
A teď si ještě představ, že si ty pásy můžu vedle sebe postavit dva a k nim dát dva lidi. Musejí oba pořád házet stejným tempem, aby to do míchačky padalo stejně rychle?
Jistěže můžeš, pokud je na to místo (tomu se zase říká bottleneck). Jenže v našem případě těch lopaťáků máš už teď tisíce (CUDA cores) a stejně to nestačí.
Chytrému napověz ...
https://video.pmgstatic.com/files/videos/001/461/1461431/157726744_c6de5...
Tak asi logicky pokud přehrávám film, tak se chci dívat a nebudu čekat déle na další snímek, protože grafická karta ho zrovna vylepšuje ne? Takže to prostě musí stihnout v tomhle časovém horizontu, resp možná i kratším, aby stíhala dopředu vylepšovat snímky.
A proč bych musel čekat na další snímek déle?
Z výrobní linky škodovky padá jedno auto za minutu. Ale stejně z toho nevyplývá, že se Felicia musí vyrobit za necelou minutu.
Nikoliv. Z toho jednoznačně vyplývá, že fabrika vyrobí jedno auto za minutu. Že jedno konkrétní auto se vyrábí třeba měsíc, to tě jako pozorovatele výstupu z fabriky nezajímá. To tě začne zajímat až tehdy, kdy to jedno konkrétní auto bude tvá objednávka. Jenže ty nečekáš na jeden vzorek, ty sleduješ "film" z aut vystupujících z fabriky.
Správně. Fabrika vyrobí auto za minutu, a my se díváme na to, jak fabrika vyrábí auto za minutu. A je uplně buřt, že měsíc trvá, než to projde výrobní linkou.
Ano, buřt to je do okamžiku než ty jako pozorovatel filmu spustíš prázdnou výrobní linku červeným tlačítkem... A jistě mi nechceš tvrdit, že ten nvidiácký tool má předpočítány všechny filmy dopředu (tj. již rozjetou výrobu).
Jak jsem už psal, ty máš problém pochopit významy pojmů takt a dopravní zpoždění a pleteš je dohromady. Ten zásadní je ten, že jako divák filmu jej spouštíš, a tím definuješ dopravní zpoždění. To může být řekněme do 15 s (více osobně nemám nikdy v plánu čekat, než se cokoli nakešuje, předpočítá apod.). Takže těchto 15s bank k dobru" můžeš rozpočíst mezi např. 120minutový snímek natočený při 24fps. To je 0,042s na snímek + 15/(120*60*24)s "alikvotní podíl z banku", což vychází na krásných 8,68e-5s (tedy 86,8 mikrosekund, tedy naprosto zanedbatelný časový úsek). Tvé nevyřčrené očekávání, že zpracování prvních snímků trvá déle než těch dalších je zcela mimo, stejně jako očekávání, že CUDA/AI whatever je schopno v rámci 0,042s komplexně zpracovat byť jen jeden frame, nebo dokonce více framů do foroty...
Heh. Jediné, co říkám, je, že ten čip může najednou zpracovávat nakrásně třeba pět snímků, a každý může být v jiné fázi. Souběžně se bude první dekódovat, u druhého nějaké filtrování na shaderech, u třetího už dělat dělat nějaký odhad pohybových vektorů na flow akcelerátoru, u čtvrtého z toho dělat nový upsamplovaný snímek na tensor cores, a pátý vykreslovat. A v dalším kole se každý posune o krok dál. A pak je na zpracování jednoho snímku čas srovnatelný s trváním pěti snímků, a stejně to zvládá sypat stejným tempem, jaké má video.
Jediné, co to ve finále udělá, je, že bude přehrávání zpožděné o tři snímky oproti stavu, kdy to jde z dekodéru rovnou na vykreslení.
Já tě naprosto chápu, a proto se ti snažím už poněkolikáté vysvětlit, že žiješ v hlubokém omylu. Totiž těchto X fází se tak jako tak prostě musí vejít v součtu časů do času jednoho framu, jinak se ti někde budou hromadit horníci v dole. :-)
Najdi si někde na netu teorii kanbanu aplikovanou na běžící výrobní pás. On se ti to snažil naznačit už Melkor. Má-li ti v taktu jedné minuty vypadávat výrobek který se vyrábí měsíc, tak všechny operace finální výrobní linky musí v úhrnu logicky trvat ne déle než měsíc. Trvá-li film 2 hodiny, tak veškeré úkony k jeho zobrazení v taktu 24 fps musí proběhnout v daném čase 2 hodin (+ řekněme pár sekund), a z toho zase plyne, že alikvotní čas na zpracování jednoho snímku nesmí překročit 1/24 s.
"Totiž těchto X fází se tak jako tak prostě musí vejít v součtu časů do času jednoho framu"
To je asi jako tvrdit, že pokud má z linky padat jedno auto za minutu, nesmí výroba auta v součtu trvat déle než jednu minutu.
Je krásný, že alikvotní čas nesmí překročit 1/24 s, ale pořád to neznamená, že se na jednom snímku nemůžou ty výpočty dělat třeba sekundu, když se jeho přehrání o sekundu zpozdí a souběžně je rozpracovaných dalších 24 snímků, které se v dalším kroku posunou o jeden snímek dál.
Zatímco u těch aplikací, co to nedělají v reálném čase, je nikdo souběžně zpracovávat 24 snímků nenutí.
Ježiši, Adame! Co se stane u stage, kde ten jeden konkrétní výpočet bude trvat déle? No budou se ti tam postupně hromadit úkoly od následujících snímků až do doby, kdy se nestihne zpracovat podklad pro další snímek (čili bottleneck). Ty nemáš žádnou "sekundu k dobru", ty máš přesný časový rozvrh, kdy se ten či onen snímek má zobrazit! Když ho nedodáš, tak už není co zobrazovat. když jeden snímek budeš procesovat 1 s, kde se budou procesovat ty další?
Nebo ty si snad naivně myslíš, že to zpracování na grafice má ještě nějaké paralelizovatelné rezervy?
Ano. A když každá stage bude trvat méně než 1/24 s, tak těch stage může být v podstatě libovolné množství.
Já nebudu najednou procesovat jen jeden snímek. Já můžu najednou procesovat klidně deset snímků, když bude každý v jiné stage.
Pak to může ve všech stage úhrnem vesele strávit 10/24 s, stačí jen, když to bude stíhat futrovat frontu z jedné stage do druhé tempem 1/24 s.
Ne, nemůže. Ty totiž nemáš neomezené prostředky. I kdybys měl dekabuffer, tak v určitém konečném čase se ti tento buffer vyprázdní, bude-li zpracování jednoho snímku trvat déle, než trvá jeho zobrazení ve filmu. Tohle není gameska, kde můžeš snížit framerate. Tohle je muzika, kde ti bubeník tluče rytmus a ty se do něj musíš se svou muzikou vlézt. A i když si na keyboardu dopředu nacvakáš nějaké kombo, tak ho stejně musíš odehrát v čase tomu určeném, a pokud je delší, tak už to nebude rytmická muzika.
A poslední větou ses naprosto zesměšnil, protože stále nechápeš problém bottlenecku. Ten opravdu nepřetlačíš tím, že před něj nahrneš haldu nezpracovaných dat.
Proboha, motáme se furt na začátku.
To, že z výrobní linky škodovky padá jedno auto za minutu s kadencí jedno auto za minutu neznamená, že výroba auta může trvat maximálně minutu, protože vyrábějí souběžně frontu aut za sebou a na každém dělají jinou operaci. Klidně můžou auto hodit na půl hodiny do lakovny, a stejně poleze jedno za druhým v minutových intervalech.
A při rozpočítání to opravdu vychází, že se vyrábí jedno auto za minutu. Ale neznamená to, že se musí za minutu vyrobit celé auto.
Stačí jen, když se současně vyrábí šedesát aut, která se postupně posouvají po jednotlivých operacích. a buď se nesmí na žádné operaci zdržet déle než minutu, nebo se při operacích, co trvají déle, musí vyrábět souběžně více aut.
A neznamená to, že když chci, aby mi z té linky padalo šedesát aut za hodinu, tak si musím dopředu do bufferu nachystat šedesát kompletních aut.
Ne nemotáme. Ty to stále nechápeš.
Tvé pojetí je zcela mimo, protože ve tvém modelu čekáš na první auto celý měsíc a celá lakovna činí 80% plochy celého závodu, protože je v ní velký pool rozpracovaných kastlí. V případě grafik ten dostupný pool (výkonu) ovšem není tak velký, aby udržel konstantní framerate.Ty neustále operuješ jakousi paralelizací, ale ta je už spotřebována na zpracování JEDNOHO obrázku v dostatečně krátkém čase. U nvidie přece nejsou takoví hlupáci aby nebyli schopni efektivně využít paralelizace.
V tom čipu jsou různé výpočetní bloky. Každý dělá něco jiného. A jsou schopné pracovat paralelně. Dekodér videa je oddělený od GPU. Pixel shadery (stream procesory) jsou oddělené od dekodéru, flow akcelerátoru (pro výpočet pohybových vektorů) i tensor cores. Tensor cores jsou oddělené od dekodéru, pixel shaderů, flow akcelerátoru.
I když bude jen jeden dekodér dekódovat jediný snímek, i když budou nakrásně všechny pixelshadery filtrovat jediný snímek, i když bude nakrásně optical flow accelerator pracovat jen s jedním snímkem, i když bude neuronka tensor cores zpracovávat jeden snímek, pořád může každý z nich souběžně pracovat na jiném snímku. A když práci dokončí, posune ho ve frontě dál.
Celkový čas na zpracování snímku bude daný řetězcem dekodér + pixel shadery + optical flow + upsampling na tensor cores. Neznamená to, že to celou pajplajnou musí prolézt během 1/24 s.
Neznamená to, že když dekodér videa dokončí dekódování snímku na začátku, tak ho nemůže strčit pixel shaderům na filtrování a začít dělat na dalším, ale musí čekat, dokud další snímek nevyleze z neuronky na konci.
Klasické upsamplery včetně těch využívajících neuronky (přinejmenším povětšinou) tohle s výjimkou toho dekódování a enkódování počítají jen na těch stream procesorech. A protože mají čas a vyšší rychlosti se dá dosáhnout pořízením výkonnějšího železa, tak se s optimalizacemi taky nikdo zase tak moc nemaže.
Akorát se začínám pomalu bát, že je to taky jen upscaler na jednom snímku.
Dobře Adame. Mějme hypoteticky případ, kdy se použijí všechny bloky na GPU a největší zátěž bude třeba na pixel shaderech (PS), kde čas zpracování jedné úlohy (obrázku) na _všech_ dostupných jednotkách tohoto typu bude delší, než je čas 1/24fps. Jak a kde zpracuješ následující snímek na PS, když ještě nedokončil předchozí úlohu?
Protože to je jen přesun o level níže, na větší detail procesu, ale principiálně se na celé věci nic nezmění.
Principálně to změní právě to, že se na zpracování jednoho snímku může věnovat i několikanásobně víc času než jen 1/24 s, což je to, co tady celou dobu řeším.
Neznamená to, že to může jeden na frame při operaci na pixel shaderech vytvrdnout na sekundu, znamená to jen, že se dá celý proces rozhodit na více operací a každou bude počítat jedna část čipu, zatímco v těch upscalerech to zatím povětšinou jede jen na těch pixel shaderech všechno komplet. A i tak některé zvládají upscalovat i tempem několika snímků za sekundu.
Ano, celou operaci můžeš rozhodit na více podoperací, ale jakmile součet jejich časů překročí frametime, je konec. Pak ti už může pomoci pouze paralelizace nestíhající podoperace, ale tuto munici u GPU už použít nemůžeš, tam je paralelizace inherentní, tudíž maximální možná. A druhou grafiku si asi pořídí kvůli tomuto nástroji jen málokdo.
Ach jo. Součet času všech operací může být libovolně dlouhý. Jen to na žádné operaci nesmí vytvrdnout déle než po dobu trvání jednoho snímku, a to ještě za předpokladu, že nelze při dané operaci paralelně zpracovávat dva snímky (což třeba v případě dvou fyzických dekodérů videa pracujících na dvou různých snímcích jde).
Jenom je nutné každou operaci zpracovat v kratším čase, než trvá jeden snímek a poslat ho na další operaci. Pak se celá fronta nikde nezasekne, ale hrne se kontinuálně dál se zpožděním úměrným počtu operací.
Zajisté máte nějaké logické vysvětlení, jak je možné, že od začátku do konce fronty to jednomu snímku trvá pět sekund, a přesto z toho padá jeden snímek za sekundu, když zpracování jednoho snímku prostě nemůže trvat déle než sekundu, jinak se tam udělá bottleneck a začnou se v tom hromadit snímky.
https://imgur.com/a/gu3ZqyG
Ano, to je věc, které se říká "dopravní zpoždění" (viz ekvivalent pásového dopravníku), to jsem se ti snažil vysvětlit už několikrát. A všimni si, že každá operace posunu "o políčko dál" trvá vždy stejný čas. O souvislosti s rozdělením na další podoperace jsem ti už také psal, ani na tom se nic nemění, z hlediska systému je úplně jedno jakou si zvolíš velikost operačního kroku a samotný takt. Pokud by např. posun z pole 3. na 2. trval ne 1s ale dvě, muselo by pole č. 3 být zdvojené (opět jsem se ti to už snažil vysvětlit, viz ta lakovna).
Tvůj příklad je navíc proces plně serializovaný, bez odboček, prostojů apod. a samozřejmě běžící plně v taktu - tedy věc v praxi zcela nenormální. :-)
Super. Akorát ti z toho vypadlo nějak to tvoje tvrzení, že "součet všech operací nesmí trvat déle než jeden frame", které tu do toho furt motáš, a u kterého jsem se marně pokoušel vysvětlovat, že jediné, co je potřeba, je, aby žádná z operací netrvala déle než jeden frame.
U grafik je naopak klíčové to, že žádná z operací netrvá déle než jeden frame, a tak nějak se s tím počítá třeba ve chvílích, kdy je celá pajplajna a výpočetní jednotky optimalizované na DLSS 2 nebo DLSS 3 a všechny ty výpočetní bloky a software k nim je navržený na to, aby své operace stíhaly během jednoho frame. Dokonce mají výrazně vyšší výkon než to, co je potřeba na přehrávání videa rychlostí 30 nebo 60 fps.
Ale to přece stále platí, že součet operací nesmí trvat déle. Je to jen o granularitě. Pokud budeš brát jako systém vlastní GPU, tak to platí bezezbytku. Pokud proces rozložíš do menších/dílčích úkonů, tak ani ty nemohou trvat déle než trvání jednoho frame, za předpokladu, že tam je 100% využitost času a zároveň nedochází k dalšímu zpoždění.
DLSS pracuje ale s obrazem který částečně "chápe" - má informace o předchozím i následujícím framu, využívá informace o scéně jako takové, scéna není zatížena rozmazáním pohybem (jak je běžné u latentních obrázků). Takže to rozhodně není srovnatelné a jako argument to prostě neuspěje.
Ty v podstatě tvrdíš, že v nvidii jsou všichni blbí.. :-D
Proboha, když to protáhnu tou pajplajnou, ve které jsou čtyři kroky, každý trvá 0,7 frame, tak se zpracováním obrazu stráví 2,8 frame čistého času, 4 frame celkového času včetně prostojů, tou pajplajnou to projede jak po másle až nakonec a zobrazí se to.
Tak jaktože se zpracováním obrazu nemůže strávit víc než 1 frame?
Ne, celkový čas zpracování v takovém (zcela hypotetickém) případě bude 0,7 fps. V praxi to tak ale nebývá čistě proto, že tě vypeče paměť/buffer.
Šmarjá, dělám chleba.
dvacet minut míchám těsto, dvacet minut to kyne, dvacet minut to peču.
Než se udělá, trvá to hodinu.
Ale když ty chleby začnu dělat tři najednou, tak ten chleba vyrobím za dvacet minut?
Hm, tak tady už asi s debatou končím.
"Klidně můžou auto hodit na půl hodiny do lakovny, a stejně poleze jedno za druhým v minutových intervalech."
Aby ti na výstupe išlo každú minútu auto, musel by si mať tých lakovní 30. Trošku nereálne.
Tak tohle muzes resit castecne bufferem, kde (pred)zpracujes a cachnes nejdriv nejakou uvodni sekvenci, nez ji posles dal. Pak by jsi teoreticky mohl (v ramci nejakeho casoveho limitu) zpracovavat, rekneme nektere framy i dele nez "1/24", v zavislosti na tom, kolik tech zpracovanych snimku pred tim v tom bufferu mas jako 'buffer' 've predu'.
Jestli to tak funguje je samozrejme druha vec :)
Samozřejmě to tak nefunguje, pokud se buffer nedá funkčně "roztáhnout" na celou délku (to neznamená že by musel být stejně velký, ale musel by předem pokrýt onu nedostatečnost, tedy zjednodušeně: pokud výpočet nad streamem trvá o 10% déle, musí být velký alespoň jako 10% celkového streamu a zároveň předem naplněn.) Pak by se dalo uvažovat že při rovnoměrném časovém rozdělení náročnosti by to mohlo doběhnout...
Ono to je tak: kdo kdy pálil CD "na mouše" na starých mechanikách bez možnosti navázat přerušené pálení, tak prostě "ví". :-D
Nepozastavoval bych se nad tím. Je jasný, že gpu musí stíhat upravovat snímky podle snímkové frekvence videa. Jestli to trvá 33 ms nebo 300 ms je fuk. Gpu by jich mohlo zpracovávat třeba 10 paralelně a emitovat postupně včas tak, aby to nebrzdilo video. Tu informaci ale nemáme. Jsou to spekulace.
No já bych neřekl, že GPU to bere striktně sekvenčně a celý čip pracuje vždy právě jen a pouze na jediném snímku. Spíš bych řekl, že to postupně prochází pipeline a jednotlivé operace probíhají souběžně na různých typech výpočetních jednotek. Funguje tak DLSS, proč by tak nefungovalo tohle.
Na televizi taky post processing snímku při filtrování a upsamplingu aspoň soudě dle zpoždění obrazu zabírá výrazně déle, než je doba překreslení jednoho snímku.
U něčeho, co má obraz zpracovávat v reálném čase, bych to čekal. Naopak u těch aplikací, které to v reálném čase dělat nemusejí, to naopak není vysloveně nutné.
Přestaň vymýšlet teoretické konstrukty.
Skoukni ten trailer co jsem nalinkoval a možná ti dojde o čem to tady všichni mluví.
Stačí prvních 23 sekund (včetně loga, které trvá 12s).
Proč prostě nepřiznat (Adams Adams), že něčemu nerozumím?
Nic se Vám nestane.
Je to fakt tak nepředstavitelné, že by se na GPU s deseti miliardami tranzistorů a desítkami a tisíci výpočetních jednotek různých typů a několikero enkodéry a dekodéry videa dalo třeba najednou paralelně zpracovávat více než jeden snímek?
Asi těch 16384 pixlí šejdrem není dost.
To je zase jedna další připitomělá zbytečná inovace, se kterou opět přišla nvidia. Počkám si radši pár měsíců až to AMD okopíruje a vyšle na úplně jiný level. To tu budou opěvné články s výživnou diskuzí jako vždy ;)
Budou, budou.
Nebudou, nebudou.
Koho to trápí?
Možná tak ve verzi 4.2.5
Nemusíš čekat, diskuze je kvalitní už teď....Adam proti všem :-D
Jj, neschopnost pripustit svůj omyl je základem každé vtipné diskuse.
Vylepšování přehrávaného videa tady už máme delší dobu já to mám třeba laptopu s Intel procesorem a grafikou
To má vlastně skoro každý, ale to tvoje je každopádně úplně mimo mísu jelikož to není AI based řešení co teď hrozně frčí :-D
zatial nie je o co stat, zerie to ako tank.
https://forum.pctuning.cz/viewtopic.php?p=9860786#p9860786
to je ta prvotriedna nvidia driver-kvalita, o ktorej vsade pcmr rozprava.
Přesně, je to vostuda, že nejsou schopní vyvinout technologii, co by fungovala třeba padesátkrát rychleji než běžné AI upsamplery, a přitom žrala třeba tři watty, co? Zjevně to maj zabugovaný!
Dival jsi se vubec na to srovnani tech snimku?
U toho realneho videa je to uplne o nicem. Trosku zvysena ostrost mozna v kombinaci s nejakym filtrem, ktery malinko vic saturuje barvicky.
Nestli ma byt tohle finalni vystup, tak to stoji teda za pekny hovno. Tohle udelas v kazdem druhem 'programku' s minimalnima narokama na vykon.
ved tam v cipe maju tensor cores, jednoznacne najlepsiu inovaciu od cias ziarovky, ako to ze to zerie o 120W viac?...ci preto?
Zjevně je to immature solution, což logicky odpovídá náročnosti úlohy a nízkému výkonu soudobých grafik.
Za mě by udělali líp, kdyby to byla offline konverzní utilita, než se pinožit za takto hodně optimisticky nastaveným cílem.
Off-line by neprošlo skrz DRM (digital restriction management).
Pravdu máš... já to myslel spíše jako řešení přehrávání starých digitalizovaných (S-)VHS domácích nahrávek.
Mám dotaz z jiného soudku: K ČEMU JE TO DOBRÝ?
Jestli bude chtít Netflix nebo Disney vylepšit svá videa, tak ať to klidně udělá a nemusí to vůbec vylepšovat v reálném čase. No a až to vylepší, tak mi to nasdílí a já se na to kouknu. Nerozumím, proč bych měl zbytečně energii spotřebovávat já a milión dalších lidí a vylepšovat si to na svých počítačích, když to může vylepšit už Netflix.
Technologie NVidie mi přijde (pardón) zcela k hovnu.
U DLSS ve hrách je to přeci o něčem jiném. Nemáme grafiky, které by 4K her zvládly bez vylepšování, proto se jako "nouzovka" používá DLSS, dokud ty grafiky nebudou ten výkon mít nativně.
Socializace nákladů.
Vyrobí se to v nějaké kvalitě.
Pak se to skomprimuje, aby to na diskovém poli nezabíralo tolik místa.
Pak se to skomrimuje ještě jednou, aby to protlačili linkama.
Pak se řeší stížnosti platících zákazníků na nekvalitu.
A pak přijde někdo s nápadem, že se to "opraví" na straně zákazníka.
Jasně, o tom mluvim, dneska při cenách za TB to úplně v pohodě můžou ukládat i v lepší kvalitě a co se týká linek, tak kde kdo už je na optice, taky už to není pro spoustu lidí problém. Oprava na straně zákazníka je jen o blbosti toho zákazníka, že si to nechá líbit.
zase blbé rozmýšľanie. Toho kto vysiela prd zaujíma tvoje mega giga ultra spojenie....On vysiela dáta ktoré potrebuje dopraviť k tebe a platí providerovi za tie dáta...Takže čím menej dát, tým viacej zarobí. Keď som robil v súkromnej regio tv tak sme vysielali cez net providera a výsledné videa som rendroval v cca dvd kvalite, teda bitrate okolo 8 Mb/s. Potom šéf prišiel s nápadom že budeme vysielať aj cez satelit a provider mal jasnú požiadavku na stream - 2,5 Mb/s. Vypadával z toho stream horší ako vHS. Takže tak mistre moudrosti.
K čemu je to dobrý. Slušný 3D upsampling na přehrávání videa na PC prakticky neexistuje. Všechny přehrávače to honí maximálně nějakou podělanou bikubickou interpolací, co tak akorát rozmazává obraz.
Přitom televize s řádově nižším výkonem zvládnou upsampling obrazu na 4K podstatně líp.
Kdyz uz nic Adame, tak dneska aspon bavis...150W upsampling, kde vidis prd rozdil. To proste chces :D
V ramci takoveho vyvoje jsou Inteli primotopy jeste vrcholem technicke geniality..
No musím se hlavně nejdřív kouknout, jak to vypadá v reálu. A k tomu se dostanu bůh ví kdy.
Z toho, co je zatím na youtube, jsem od toho čekal víc. Ale furt je to jenom youtube s prasáckou kompresí.
Hlavne si nezabudni pustit play, aby si nedopadol ako 4W copy/paste cenzor z roota, co tu tak rad vyplakava o upadajucej kvalite clankov.
To je jiný Ježek. A ten to taky jenom opsal z THG, kde je to v tabuli výslovně uvedené.
A taky se mi to nezdá.
Dik za opravu, moja chyba, ospravedlnujem sa Davidovi za '4W copy/paste'. Inu, cervene platno mi zakalilo usudok.
A k veci, podla tvojich komentov predpokladam, ze sa ti doma povaluje kopa ripov z VHS, skus to prosim pridat do testu.
Ani ne, spíš mám hromadu nahrávek z kabelovky v MPEGu 2 na 576p, a ještě víc v 1080p v MPEGu 4/H.264, ale u monitorů už jedu na 4K s úhlopříčkou jak kráva (43" a 55"), na kterých to vypadá z krátké vzdálenosti jako fakt celkem hnusně.
u televizí to byla nutnost, protože přechod z fullhd na 4k byl hodně rychlí, už roky dobrou fullhd tv nekoupíš a 4k obsahu bylo pramálo v té době a dnes ještě ani tv vysílání není pořádně ve fullhd
u PC je situace jiná, na hry 4k monitory používají jenom masochisti nebo "snobové" videa na youtube ti stačí fullhd na mém 1440p monitoru skoro nepoznám rozdíl mezi 1080p a 4k verzí, takže potřeba nějak slušně upscalovat video na pc prostě není
a hlavně díky netflixu máme 4k obsahu habakuk nehledě na to, že na výsledné kvalitě obrazu záleží víc na tom čím to natočili než v jakém rozlišení video běží
Naopak.
Pokud televize nepoužívá pitomý upscaling, tak 4K obraz je přesně čtverec 4 pixelů fullHD obrazu. Teda jeden pixel fullHD budou ve skutečnosti 4 sousedící pixely na 4K televizi a potom je to jen a jen o vzdálenosti, ve které budeš sedět tak, abys neviděl jednotlivé pixely, ale splývaly ti a potom žádný upscaling u televize řešit nemusíš a máš to zadarmo. :-)
takže kúpim si 65 " 4K telku ale budem sedieť na chodbe aby som nevidel blivajz? Super rada, díky nechcem. 65 telku som kúpil aby som pozeral z cca 2 m a aby som si čo najviac priblížil zážitok z kina.
Úplně to samé platí pro obě možnosti, které píšeš a platí to i pro Adama, který tu píše podobné argumenty:
Nikdo vás nenutí odebírat blbou kvalitu videa. Pořád máš možnost jít do BR nebo k takovému poskytovateli, který ti bude po netu ochoten poslat super 4K kvalitu, technicky to možné dnes je.
Technicky dnes opravdu není možné jít na netflix s tím, že chceš od nich ve 4K to, co tam má HBO jen v 1080p.
Technicky se dnes děje naopak to, že z jedné služby věci mizí jen kvůli tomu, že je chce mít jiná služba exkluzivně a jsou mraky obsahu, který jinde ve vyšší kvalitě prostě neexistuje.
Nefunguje to tak, že když někdo něco v lepší kvalitě nemá, tak vždycky najdu někoho, kdo to v lepší kvalitě bude mít.
No, tak já třeba na youtube poznám i rozdíl mezi videem v 1080p a 4K přehrávaném na monitoru s 1080p. :D
O 1080p upsamplovaném na 4K nemluvě.
Drtivá většina obsahu přehrávaného na PC ve 4K je pořád ještě v 1080p. Včetně těch různých xflixů, HBO, voyo ivysilani a podobnejch nesmyslů nebo nahrávek videa z flešky.
Při přehrávání přímo přes televizi to vypadá o parník líp, než když to člověk pustí v prohlížeči na PC nebo v nějakém přehrávači přes windows. A kvalitnější 3D upsamplery i při akceleraci přes GPU jsou schopné drhnout.
ak je vo full HD a nie len 720.
"Při přehrávání přímo přes televizi to vypadá o parník líp,"
.. akorat to je casto dano i tim treba, ze panely do monitoru maji napr antireflexni upravy, u televize casto nemaji nebo ne tak silne, coz subjektivne zvysuje napr kvalitu obrazu - podani barev. Rovnez 10b (8+2) byl/je u televizi vic rozsireny nez u monitoru, coz zvysuje zivost barev. Rovnez nastaveni televizi, s vysokm kontrastem, atd byva jine, nez u treba stolniho monitoru, kde se napriklad snazis upravit obraz tak, aby jsi nemel unavene oci, atd.
Tim chci jen rict, ze ruzna srovanni jsou velmi subjektivni zalezitost a casto jsou o nastaveni obrazu daneho vystupnho zarizeni, oproti jinemu.
"No, tak já třeba na youtube poznám i rozdíl mezi videem v 1080p a 4K přehrávaném na monitoru s 1080p. :D"
.. to ale bude paltit nejspis pro stejny 1080p a 4k, kde 1080p nebude prilis kvalitni, potazmo bude mit nejake artefakty v obraze nebo spatne provedeny encoding, ktery to rozmazne.
Jinak souhlasim s tim, ze 4k obsah ma svoje vyhody i na nizsich rozliseni. Tim ze mam relativne cerstvou zkusenost s UWQHD (3440x1440 IPS) na 34'', tak musim rct, ze pri vzdalenosti, ze ktere na obraz cumim, je rodil 4k vs 1080p obrazu vetsi nez u moji 55'' 4k OLED telky, kde sedim cca 2,5m od toho. Uz jsem v principu nad 4k lamal hul, ale tenhle novy ultra sirokouhly format, to paradoxne zachranil v nizsim rozliseni, nez nativni 4k.
Já mám u dvou počítačů televize místo monitorů. Takže tím míním přímé srovnání.
ok, rozumim. Tak asi ty obvody v ty telce (pokud mas vylepsovani obrazu zapnuty) si na sebe aspon trochu vydelaji ;)
Proč by to dělali takovéhle firmy, bude to dělat BFU, máš starší nahrávky v nižších rozlišení máš konverze z VHS kazet, někde si omylem natočil něco v nižším rozlišení, využití jsou mraky, můžeme se bavit o reálném výsledku a jeho kvalitě, ale ne o využitelnosti. Ta tady je a využívá se.
tady je vidět že firma má zbytečně moc peněz a vymejšlí projekty tohoto typu, úplně k ničemu, nikdo to nepoužije, výsledky jsou meh a stálo to určitě balík, kdyby se radši soustředili udělat čipletový design udělali by líp
Hlavně musíme fandit nejen AMD, ale i Intelu kvůli konkurenci. Tohle je jen důsledek toho, že je dneska NVidie monopol. Takže nám v klidu napálí cenu grafik a za ty peníze navíc pak vymýšlí pitomosti, které nikdo nechtěl a nikdo ani používat nebude. (vyjma Adama samozřejmě.) :-)
Nikdo nechtěl. Já na něco, co bude slušně a v rozumném čase upsamplovat stará videa, která jsou nahráváná třeba jenom v PALu, čekám už dvacet let.
Výkon grafik za tu dobu vyrostl bambilionkrát, a přehrávače ve widlích se povětšinou nezmůžou na nic jiného než na stejnou rozmatlanou bikubickou interpolaci, kterou dělaly před dvaceti lety.
Nenajdu to teď, ale kámoš o něčem před časem mluvil, prý skvělé, ale bylo to za peníze. Každopádně ten realtime upscaling pro PC existuje v dobré kvalitě už několik let, akorát není zadarmo.
Pokud se týká filmů, tak téměř všechny jsou na filmovém pásu, který má okolo 4K rozlišení po digitalizaci, stačí to udělat. Netřeba to přenášet na zákazníka.
Jo, domácí videa může být, ale zase většinou to uděláš tak, že si to převedeš v kvalitním upscaleru bez realtime a teprve potom na to budeš koukat.
Přidanou hodnotu v tom, co NVidia vymyslela, nevidím.
Ono si stačí pustit i cokoliv z iVysilani, z toho, co je tam v archivu jako televizní inscenace nebo seriály, je tam v podstatě všechno v 576p s výjimkou věcí, co někdo točil na filmové pásy a remasteroval. A to, co je remasterované, tam mají pro změnu v 1080p a na 4K se zmůžou možná za deset let. Blbej MASH, Hvězdná brána, jakékoliv staré televizní seriály, co se točily v době, kdy neexistovalo ani to 1080p.
A že bych to stahoval a pět hodin offline upsamploval, abych na to koukl a pak to smazal... hm.
Na margo starych serialov, je velky rozdiel v kvalite robit remaster z filmu (35/65mm) a videopasky, ktore sa bezne pouzivali v 80-90tych rokoch ako master (najma u serialov) az do nastupu digitalnych formatov (a aj tam to dlho bola bieda*). Pre detailistov, surova stopa bola/je stale natocena na film, ale master (postprodukcia, ako strih, specialne efekty, mix, atd) je dostupny uz len na paske (nizsie naklady, lahsia manipulacia, na ukor kvality rozlisenia a farieb, ktore stale postacovali pre vtedy dostupne zobrazovadla). Jedina vynimka o ktorej viem, kedy sa znova robila postprodukcia za ucelom digitalizacie, je Star Trek: The Next Generation, ale zjavne sa to studiu nevyplatilo, kedze dalsie serie su digitalizovane opat z videopasok.
* v porovnani s filmom, z ktoreho sa da po digitalizacii dostat kvalita niekde medzi 4-8k
A pak jsou tady věci, které byly točeny
- na digitální kameru (např. https://www.csfd.cz/film/12103-fantom-parize/prehled/)
- na iPhone
Potřebuje to předraženou RTX grafiku, přes 100W elektřiny a výsledek stejný jako když ve VLC nastavíte upscale Algo lanczos a trošku přidáte zaostření.
Potlesk nVidia za nejvíce nesmyslnou fičuru roku 2023.
Potřebuje to předraženou RTX grafiku, přes 100W elektřiny a výsledek stejný jako když ve VLC nastavíte upscale Algo lanczos a trošku přidáte zaostření.
.. neco podobneho mne napadalo, alespon podle tech samplu orazku v originalnim clanku. Je to malinko priostrene, mozna je tam vytazena trochu barevna sytost. To je cely.
Mozna to chce nejaky jiny typ zdroje videa, kde to bude podovat zajimavejsi vysledky, ale tady to bylo vylozene meeh.
No jo, Lanczos jede jenom na jednom snímku, nedá se z toho skládáním posunutých vytáhnout víc detailů.
akorat je otazka, jestli a kde ty 'poskladane' detaily uvidis.
Vychazim z tech srovnavacich samplu..prinos krome priostreni vicemene nula.
Proto pisu, ze je mozne, ze na nejakem jinem zdroji, treba horsi kvalite, atd, ten vysledek bude lepsi. Ale z toho jak a na cem to testovali je to featura na dve veci zatim
Já se vážně při pohledu na screeny a videa s kvalitou výsledků začínám bát, že to funguje spíš jako tupý upscaler a filtr na jednom snímku.
A to může AMD taky nakrásně smáznout nějakým vylepšeným filtrem pro pixel shadery.
A furt to bude lepší jak nic.
Tim padem to za tu spotrebu fakt nestoji ;)
Pro psaní komentářů se, prosím, přihlaste nebo registrujte.