Co nejmenší video s co největší kvalitou? Kdo poradí?

Myslím, že požaduješ nemožné. 3 minutové video bude mít 0,56 Mb/s dátový tok, což je nedostatečné. U tohoto rozlišení by to mělo mít dátový tok minimálně 40 Mb/s, aby to mělo aspoň prúměrnou kvalitu. Tady nepomúže ani komprimace. Snížit dátový tok se dá snížením rozlišení, snížením počtu obrázkú za sekundu a komprimací typu VBR, která však není všemocná.

40Mbps je celkem dost. Já komprimuju 4K videa do 10Mbps 10bit h.265 a kvalita je dobrá, ale chce to komprimovat co nejpomaleji aby ta kvalita byla dobrá. A pozor! Nepoužívat HW akceleraci, ale jen pouze CPU. Handbrake používám rychlost slow, ale na tak krátké video bych použil klidně i very slow nebo placebo. Jinak bych nepočítal u 3min videa kolem 250MB i se zvukem.

"..komprimovat co nejpomaleji .." Jako že když to budu komprimovat na 486, tak bude kvalita lepší, než když to zkomprimuju na i9..?

Je to myšleno, že například Handbrake má možnost kvality renderingu, čož přímo odpovídá rychlosti resp. času jak dlouho to bude trvat. Asi to bylo trochu nepřesné vyjádření z mé strany.

nedělej ze sebe debila, každej ví jak to myslel.

Ja teda komprimuju tak dvakrat do roka, ale zajimalo by me proc nepouzivat HW akceleraci? To jako, ze grafika pocita rychlejc, ale spatne?

Zhruba ano ... proto se to používá hlavně při střihu pro rychlý náhled. Je to něco na způsob, jako když budeš dělat výpočty v 16b nebo ve 32b.

Taky jsem byl překvapen, když při stejném nastavení kvality mělo stejné video kódované přes GPU daleko větší velikost, než při kodování přes CPU. Ale bylo to rychlejší. Použil jsem Handbrake a H264.

Komprimovat co nepomaleji? Už dlouho jsem se takto nepobavil Ty toho asi o komprimaci moc nevíš, co?

a ty ? Mě je naprosto jasný jak to myslel.. tobě ne ?

"Je to myšleno, že například Handbrake má možnost kvality renderingu, čož přímo odpovídá rychlosti resp. času jak dlouho to bude trvat. Asi to bylo trochu nepřesné vyjádření z mé strany."Není tak složité si přečíst tu diskusi celou.

pokial nemáš k dispozícii hw kodeky ale robíš to čiste softwarovou cestou,vždy zhoršíš kvalitu vo výsledku oproti originálu....pokial chceš kvalitnú kompresiu,skús použiť napr. D3 kodek a program,ktorý umožní použiť externé kodeky,oplatí sa zakúpiť elgato turbo HD software edition( má aj trial verziu),alebo digiarty VideoProc(trial je obmedzený na 5 minútové výsledné video)......pokial Ťa neuspokojujú jednoduché programy,môžeš si stiahnuť free DaVinci Resolve od Blackmagic

Jakože HW kodeky nesnižují kvalitu a SW ano? Jak jste na to přišel?

dva příspěvky výše jsem označil přesně naopak, než jsem chtěl, vinou chyby stránky. Označil jsem podle svého názoru, stránka v daném místě napsala "+0" a "-0". Po refreši ale souhlas/nesouhlas naskočil přesně naopak.K odpovědi dryqj: vyzkoušej a odpovíš si sám.

Je to tak, ale přesně obráceně. GPU HW akcelerace renderu videa právě tu kvalitu sníží. Ano HW render je řádově rychlejší, ale kvalita třeba o několik desítek procent horší.

Vy dvaja si nemýlite HW podporu s HW kodekmi? A čo je vlastne HW kodek? Máš síce mínusy, ale je pravda, že enkódovanie videa pomocou grafickej karty znamená rýchlejší render, ale na úkor kvality výsledného videa.

Ses zbláznil, ne? Aby UHD video vypadalo dobře, tak musí mít minimálně nějakých 80Mb/s = 10MB/s a to x 180s = 1,8GB. Takže 100MB z toho fakt neuděláš Možná, když se smíříš s mizernou kvalitou, tak se dostaneš na 1GB, ale míň určitě ne a už to bude vypadat dost blbě.

80Mb/s je zbytečně moc..nebo jako hodně záleží od scény. Točím takový ty běžný videa z dovolené/děcka na písku atd a foťák sice točí 100Mb/s, ale když to sestříhám, tak dávám bitrate 15Mb/s a vypadá to naprosto bezvadně. Originální videa a projekty zálohuju, takže není problém to vyexportovat ve vyšším rozlišení, ale jak říkám, těch 15Mb/s je úplně v pohodě. Export mám VBR, 2pass, takže to ví kdy na bitrate ušetřit (hodně statických scén) a pak kdy ho zvýšit na nějaký pohyb

Prosím všechny, kteří mi klikají na "nesouhlasím", aby nebyli srabi a napsali konkrétně s čím.

Normálně používám 80Mbps, ale loni z dovolené jsem měl dlouhé video, tak jsem chtěl trochu ušetřit a stáhl jsem to na 60Mbps. Dívat se na to dá, v běžných scénách problém není, ale jak tam byl třeba západ slunce a obecně velké plochy s plynulými přechody odstínů, tak už bylo poznat, že to málo. Samozřejmě YouTube to zmršilo ještě mnohem víc Ale na doma pod 60 určitě chodit nebudu a to jen u dlouhých videí. Kratší raději nechávám v 80Mbps. Nebo jedině přejít na h.265, to by asi šlo stáhnout na polovinu, ale bude to záhul pro počítač to enkódovat

H.265 bude záhul? A to jsi vzal kde? Dyť to dnes akceleruje snad cokoli, nejlépe Intel grafiky od 11. generace, umí 8, 10 i 12 bit, I 4:4:4, To nedávají ani NVIDIA grafiky potažmo AMDčka....Ale SDR nebo 4:2:2 10 bit by mělo zvládnout akcelerovat snad vše.Jinak víš jistě že ten záznam už není v H.265? Já třeba vůbec H264 netočím, vše je H265 a kdybych měl, tak bych se nebál ProResu s nějakými 150Mb/s

Bude to záhul, protože čím kvalitněji to renderuješ tím je to výpočetně náročnější a pokud nechceš ztratit kvalitu (nebo jen velmi málo) a chceš snížit datový tok, tak se tím právě zvyšuje výpočetní náročnost potažmo čas.Dneska ti sice kdejaká kamera a zařízení vyhodí h.265, ale buď nekvalitní a nebo ve vysokém datové toku právě proto, že je to pak mnohem méně náročné.

Je mi jasné že se bude zvedat náročnost, ale proč by měl bý H265 záhul a H264 ne?H265 dnes běžně akcelerují i levné mobily a v podstatě kdejaký počítač.Když nechám exportovat video na svém iPadu nebo Macbooku tak nepozoruji že by to byl velký záhul. U iPadu je akorát blbé že LumaFusion musí být na popředí. U Macbooku to nechám běžet na pozadí. Loni jsem převáděl nějaký archiv videí z H254 na H265 v Handbrake, konverze běžela více jak den nonstop. že to něco dělá člověk zjistil jen podle teploty na omak, kdy nad klávesnicí a zespod v tom místě to bylo cítitelně hřejivé (normálně je to chladivé).Na to že to kódoval čip, který dnes najdeš v střední třídě tabletů tak jsem neregostroval nic co by se dalo označit za záhul. Prostě si to počítalo víc jak den na pozadí a já při tom normálně laptop používal, a to jak připojený k napájení tak bez - na výkon to v mém případě nemá žádný vliv.Ten čip z tabletu tu konverzi dokonce dělal rychleji než stolní počítač s NVIDIA grafikou při cca 10x nižší spotřebě

Dej sem tříminutové zdrojové video 4K.Dej sem 4K video enkodované tebou popsaným způsobem přes gpu na bitrate 4.44 mbps.Já ti sem pak dám video enkodované pomocí cpu taky na bitrate 4.44 mbps a pak se teprve můžeme o něčem bavit

Čo je „záhul”? Ja zníženie výkonu PC počas enkódovania videa v Handbrake nepociťujem ani na C2Q. Je to totiž otázka priority. Nastav si prioritu na time critical a nepohneš ani s myšou ani na Tvojom ospevovanom ájPede. Otázka dekódovania h265 je otázkou buď výkonu CPU, alebo grafiky s HW podporou, ale to určite vieš. A nie každý má takú GK/iGPU. 1 deň myslíš 4K jedno video, alebo x videi? nVidiu porovnávaš s ájPedom za rovnakých okolností?

Otázka také je jaký používáš kodek, jestli je to s HW akcelerací a také rychlost/kvalita renderu. vysoce kvalitní render 4k h.265 s 2pass 1h videa by trval snad více jak týden

Prečo používaš konštatntný bitrate a nie konš. kvalitu? Nech o dát. toku rozhodne SW podľa toho či ide o pohľad pol minuty (napr.) na moderátora (týden živě), alebo niečo ako „rýchlo a zbesilo”. CQ=22 až 25 je znesiteľné. Ako určuješ aký dát. tok pre konkr. video je optimálne?

Podle mě je lepší používat CRF než CQ. Co si pamatuju, tak CQ je konstantní kvalita ve smyslu absolutní kvality, kdežto CRF je konstantní kvalita z pohledu lidského vnímání. Když to zjednoduším, tak CRF trošku ubere na absolutní kvalitě v akčnějších scénách (např. 1/2 videa z 10 mbps na 9 mbps), protože tam je jednak velký bitrate a jednak v nich lidské vnímání tolik nevnímá detaily a kvalitu a ušetřené bitrate převede na statické scény (např. 2/2 videa z 1 mbps na 2 mbps), kde lidské vnímání je citlivější na kvalitu videa.Když bys pak ukázal dva ripy CQ a CRF o stejné velikosti člověku, tak by měl jako to kvalitnější uvést to enkodované jako CRF .-)

To není tak uplně pravda. Lze udělat kvalitní render u s relativně nízkým datovým tokem, ale nesmí se použít GPU akcelerace a je třeba ten render provádět pomalejí = kvalitněji, ale to někdy znamená že třeba 2 hodiny videa se renderují několik dní.

Asi máš pravdu, ale do toho se pouštět nebudu Ale zajímalo by mě, o kolik se to dá zlepšit. Možná si to zkusím u nějakého krátkého videa. Stačí myslíš, když při exportu zakážu využití GPU?

Popravdě GPU akceleraci nepoužívám nejen kvůli kvalitě (řekl bych že to je viditelné), ale hlavně kvůli tomu, že jsem vyrenderoval hromady videí a pak zjistil, že přes GPU to dělá v obraze artefakty. Já používám Handbrake a tam to je v Tools > Preferences > VideoPřípadně v jiném SW by mělo stačit buď zakázat GPU akceleraci pro export/render/encode nebo to zakázat v tom SW globálně.

Proto si ty grafiky a další čipy s HW akcelerátory encode a decode videa kupuje jak rohlíky, když chce pracovat s videem.Hlavně ono encode není pro většinu lidí důležité. Když si video editor a děláš nějaké třeba víc trikové video, strávíš s 20-30 minutový, klipem klidně měsíc, kde děláš efekty snímek po snímku. Jestli ti pak výsledný export běží 10 minut nebo 10 hodin už je jedno. Po měsíci si stejně dáš oraz. Tak jak tak při editaci videa je klíčový výkon na time lině, k tomu potřebuješ co nejširší podporu HW decode (vedou Intel grafiky ve Windows světě). Pak můžeš mít i3-12100 s 12 bit 4:4:4 4k H265 videem a stříháš bez lagů oproti člověku třeba s R9 5950X, s nějakou NV/AMD grafikou, které ten formát nepodporuji a to 1ž jádro dostane pořádně zabratNavíc je různými testy prokázáno že dnešní enkódéry, třeba NVENC jsou kvalitou velice blézké HEVC. Navíc když tvůj encodér žere 1W je to něco jiné než když na to musíš pustit CPU které má 200W spotřeby a je +- stejně pomalé.Navíc ten encodér nemusí počítat vše. Grafická karta má pak ještě výpočetní jádra a pro encoding lze využít nejen NVENC ale i CUDA. Případně klidně použít i další grafickou kartu pokud jich je v systmu víc, a že to docela bývá. Nemálo tvůrců dnes kupuje 12. gen Intely na práci s videem, integrované grafiky podporují decode a encode nejvíce H265 formátů videa o kterých si NVIDIA a hlavně AMD mohou nechat zdát.

V tomto vlákně se ale řeší velmi nízké bitrate. Ne rychlost nebo spotřeba.HEVC není kodek, kodek pro cpu se jmenuje x265.gpu enkodéry se kvalitou dejme tomu blíží cpu enkodérům, ale jen při vyšších a dejme tomu běžných bitrate, kdy ten rozdíl člověk stejně asi moc nepozná nebo není tak znatelný. Při nízkých bitrate ale podle mě ten rozdíl bude znatelný. A bavíme se tu o nízkých bitrate.

A proč se nemůže použít GPU render? To ta grafika má stát? Proč nepoužít třeba NVENC + CUDA? Proč nepoižít QuickSync? A proč nepoužít třeba vlastní akcelerátory, však H265 ti v reálném čase včetně image procesingu natoči i low endový mobil právě proto že má vše potřebné a efektivní v sobě.Proč bych to neudělal na mobilu, nebo třeba na tabletu který používá fakticky to samé co mobil. Proč bych nepoužíval video encodéry a dekodéry, když je mám v procesoru? Někdo dá 4+ tisíce dolarů za M1 Ultra právě proto aby měl 4 HW encodéry a dekodéry H264, 265 a ProRes. To co highendové PC počítá klidně 15 minut ta ultra zvládne za 2-3

Někdo to tu v diskusi psal (asi je to skryté a nechce se mi to hledat). Jde o to, že GPU a CPU používá pro encode jiný algoritmus a ten pro GPU je upravený na rychlost, ale s tím také klesá výsledná kvalita videa. Jinak ano dneska ti natočí h.265 i nějaká low kamera, ale s vysokým tokem nebo nic moc kvalitou.Když to video pak re-encoduješ přeš CPU s vysokou kvalitou tak to bude sice trvat dlouhou dobu, ale můžeš bez ztráty kvality dosáhnout výrazné úspory velikosti souboru.

No někdo tu to psal a já pořád čtu tohle od spousty lidí ale nikdo neukázal prstem na nějaké srovnání a testy.Moje informace už jsou starší - příchod NVENC v Turingu, a v případě Intel grafik - nový QuickSync od 11. generace.Oboje se výrazně zlepšilo v kvalitě a z testů - prohání se to nějakým SW vycházelo že při nízkých datových tocích jsou tyhle HW akcelerátory velice kvalitní a fakticky srovnatelné s běžně používaným SW encode. Ano ve vyšších datových tocích.To jsem v tom testu ale neviděl vůbec srovnávání různých SoC pro mobily a tablety, kde ty akcelerátory jsou také.Navíc neznám kreativní profesionály kteří by videa encodovali pomocí SW, všichni na to využívají HW akceleraci a třeba takové Mac Studio s M1 Ultra si koupí video editor právě kvůli tomu že proti Macbooku Pro s M1 Max znásobuje HW akcelerátory a ty krásně škálují. Není nad to exportovat 8k H265 10bit 4:4:4 timelinu dvakrát rychleji a dokonce několikrát rychleji než podobně drahé PC :)

heh … 80Mbs? tolik nemaji ani nektery fajnovy UHD blureje :D

se zas malinko uklidnime :)

Tak 80Mbps je minimum, při kterém nepoznám po renderu rozdíl od původního 100Mbps originálu 60Mbps už znamená viditelnou ztrátu v určitých typech záběrů. Pravda, mluvím o h.264. h.265 snese samozřejmě větší snížení.

jasne :D nemas nahodou doma
i pozlaceny HDMI konektory, protoze “poznas” rozdil mezi audiem, co projde pres pozlaceny a nepozlaceny?

Ne, to opravdu nemám, protože taková pitomost by mě nenapadla Ale rozdíl 60/80Mbps u 4K videa v h.264 vidím na první pohled (na 140cm TV), jsem si jistý, že bys to viděl taky Jak jsem psal, na běžných scénách to vidět není, ale třeba na západu slunce, kde jsou na velké ploše plynulé přechody odstínů, se to už projeví.

Tak 80Mbps nie je zas extra moc, kedze 4K je 4x1080p, takze na to 1080p vychadza 20Mbps, co nie je nic extra, hlavne nie v H264.Tie prechody medzi jednotlivymi odtienmi, je podla mna sposobene podzvorkovanim farieb na 4:2:0, a este tym, ze asi to video nie je HDR. Skus HDR, prave HDR bolo robene na tieto typy nedostatkov, ked iba 8 bitovy rozsah nedokazal pokryt jemne prechody medzi odtienmi. Este by pomohlo pozriet ako mas nastaveny dithering.Ked tak, daj nejaku ukazku.

HDR bohužel nemá zdrojové video. Kamera ani dron HDR neumí. Ale obojí produkuje 100Mb/s tok v h.264 a když to z editoru exportuju 80Mb/s, tak žádné viditelné zhoršení nepozoruju. Ale při 60Mb/s už ano.

Tak je mozne, ze software pre 60Mb/s uz podstatne meni parametre, co je logicke, kedze na niecom sa usetrit musi.Co pouzivas za encoder? Nie som sice expert, ale neskusal si sa pohrabat v nastaveniach, alebo profiloch, zamerane na taketo sceny?

Používám export v Davinci Resolve, zkoušel jsem render přes CPU i GPU. Ale ne, nijak detailně jsem se v nastavení nerýpal. Ani bych to nemohl nastavovat speciálně pro konkrétní typ scény, protože to zabíralo jen malou část videa.

Jednak to může být kodekem, používá x265/x264?A jednak tím, že banding je úplně normální věc. Eliminovat se dá nastavením enkodování nebo použitím 10bit videa (při stejném bitrate je méně bandingu - odzkoušeno) nebo prostě debandingem při přehrávání.

Budeš muset snížit rozlišení na FullHD a použít HEVC (H.265) kodek, pak by to při 100MB mohlo být snad trochu koukatelné.

I pro FHD je to hódně na hraně a bez zvuku

Datový tok mi vychází na 4.44Mb/s, což je plusmínus stejně jako např. FHD vysílání ČT1. A když to navíc prožene nějakým kvalitnějším víceprůchodovým encodingem, tak to taková hrůza být nemusí.

100 mb je 0.55 mbps, což u 4K by bylo možné jen u statického obrazu.Pokud myslíš 100 MB, to je 4.44 mbps a v tom videu by už mohl být i pohyb, ale opět bude záležet na tom, jestli je to video statické nebo dynamické a jestli je tam hodně detailů nebo málo. Ale teoreticky (koukatelné) video na tý velikosti vytvořit jde.

Mimo jiné záleží na tom co to je zač. Pokud je to statický obrázek tak by nemělo být problém ten bitrate hodně snížit.Jinak koukatelných 4k@30FPS je tak 300-400MB/minuta v H.265, tzn nějaké 1GB ale už to bude na hraně..Šlo by použít AV1, ale otázkou je nakolik to pomůže a jak dlouho to bude trvat.