Vegas Pro 13 - využití potenciálu grafické karty
Zdravím a prosím o několik vašich názorů.
Ve svém starším, ale stále provozuschopném PC (MB s chipsetem P55, CPU i7-860, 16GB RAM, SSD se systémem Win7 Pro) jsem vyměnil grafickou kartu z původní (XFX) HD6870 1GB RAM na (Asus) HD7950 3GB RAM. Touto záměnou jsem sledoval pořízení toho možná co nejlepšího, co se dá v použitých (tedy ne moc drahých, video stříhám jen několikrát ročně a nevýdělečně) grafických kartách nalézt pro VP13. Očekával jsem, že (trochu) navýším výkon v náhledu při střihu a (trochu) zkrátím rendering do formátů, ve kterých je ve VP13 podporována GPU akcelerace.
Ovšem, žádné výrazné zlepšení se nekonalo. Na výkonu v náhledu se subjektivně nezměnilo nic a testovací rendering 10 minut dlouhého videa do Sony AVC dopadl téměř na vteřinu stejně v mírný prospěch HD7950 (ale opravdu jen asi o cca 10 vteřin na pěti minutách). Tak nějak laicky jsem čekal, že při renderingu se zátěž ať už CPU nebo GPU dostane na hodnoty blízké 100% a tím bude jasné, že daný komponent pracuje na maximum. Ovšem při renderingu i přehrávání timeline se to nestalo (zátěž GPU se například vůbec nezměnila). V projektu, na kterém jsem to testoval, bylo jen několik AVCHD videosouborů a na stopách jen pár základních procesů (Levels, Color Corrector a Color Curves, na výstupu potom pro jistotu ještě Broadcast Levels).
Je tedy možné, že je v PC úzké hrdlo někde jinde, nebo jsem prostě narazil na strop v některé jiné části PC sestavy, než je grafická karta?
Myslíte, že má cenu pozapínat v BIOS všelijaké ty Intel vychytávky (Intel Turbo Boost aj.)?
Nebo jsem omezen i softwarovou podporou daných exportních procesů VP13, kdy nejsou podporovány grafické čipy od nějaké generace dál? (ale v době vydání VP13 už byly grafické karty s HD7950 na světe, aspoň myslím).
Má podle vás smysl místo herních grafických karet nechat pracovat Vegas spíš s kartami typu AMD FirePro Wxxxx? (V čem se vlastně liší?)
Omlouvám se, že nekladu žádný konkrétní, přesně mířený dotaz, ale třeba se v některých z vašich názorů najde vodítko, co má a nemá cenu zkoušet, popřípadě pořizovat. Každopádně, předem díky za každý názor!
Ve svém starším, ale stále provozuschopném PC (MB s chipsetem P55, CPU i7-860, 16GB RAM, SSD se systémem Win7 Pro) jsem vyměnil grafickou kartu z původní (XFX) HD6870 1GB RAM na (Asus) HD7950 3GB RAM. Touto záměnou jsem sledoval pořízení toho možná co nejlepšího, co se dá v použitých (tedy ne moc drahých, video stříhám jen několikrát ročně a nevýdělečně) grafických kartách nalézt pro VP13. Očekával jsem, že (trochu) navýším výkon v náhledu při střihu a (trochu) zkrátím rendering do formátů, ve kterých je ve VP13 podporována GPU akcelerace.
Ovšem, žádné výrazné zlepšení se nekonalo. Na výkonu v náhledu se subjektivně nezměnilo nic a testovací rendering 10 minut dlouhého videa do Sony AVC dopadl téměř na vteřinu stejně v mírný prospěch HD7950 (ale opravdu jen asi o cca 10 vteřin na pěti minutách). Tak nějak laicky jsem čekal, že při renderingu se zátěž ať už CPU nebo GPU dostane na hodnoty blízké 100% a tím bude jasné, že daný komponent pracuje na maximum. Ovšem při renderingu i přehrávání timeline se to nestalo (zátěž GPU se například vůbec nezměnila). V projektu, na kterém jsem to testoval, bylo jen několik AVCHD videosouborů a na stopách jen pár základních procesů (Levels, Color Corrector a Color Curves, na výstupu potom pro jistotu ještě Broadcast Levels).
Je tedy možné, že je v PC úzké hrdlo někde jinde, nebo jsem prostě narazil na strop v některé jiné části PC sestavy, než je grafická karta?
Myslíte, že má cenu pozapínat v BIOS všelijaké ty Intel vychytávky (Intel Turbo Boost aj.)?
Nebo jsem omezen i softwarovou podporou daných exportních procesů VP13, kdy nejsou podporovány grafické čipy od nějaké generace dál? (ale v době vydání VP13 už byly grafické karty s HD7950 na světe, aspoň myslím).
Má podle vás smysl místo herních grafických karet nechat pracovat Vegas spíš s kartami typu AMD FirePro Wxxxx? (V čem se vlastně liší?)
Omlouvám se, že nekladu žádný konkrétní, přesně mířený dotaz, ale třeba se v některých z vašich názorů najde vodítko, co má a nemá cenu zkoušet, popřípadě pořizovat. Každopádně, předem díky za každý názor!
Po HW stránce: i7-860 je na úrovni nynějších slabších modelů i5 procesorů. Dále úzké hrdlo může být v chipsetu a sběrnici.
Po SW stránce: Jsi si jistý, že VP13 je směrován na rendering GPU a není směrován na výkon CPU? Máš správné ovladače grafické karty?
Problém vidím v tom, že VP13 neumí tuto kartu a uvedené grafické efekty akcelerovat právě přes GPU nebo požadovaný výstup není pro akceleraci GPU podporován. Ne všechny formáty umí VP přes GPU akcelerovat.
Zkus mrknout sem https://goo.gl/jZc2sD . Sice je to k VP12, ale třeba ve VFP13 je nastavení podobné.
Po SW stránce: Jsi si jistý, že VP13 je směrován na rendering GPU a není směrován na výkon CPU? Máš správné ovladače grafické karty?
Problém vidím v tom, že VP13 neumí tuto kartu a uvedené grafické efekty akcelerovat právě přes GPU nebo požadovaný výstup není pro akceleraci GPU podporován. Ne všechny formáty umí VP přes GPU akcelerovat.
Zkus mrknout sem https://goo.gl/jZc2sD . Sice je to k VP12, ale třeba ve VFP13 je nastavení podobné.
Nieco podobne som riesil aj ja. Mam cpu i7-4770K, gpu Geforce 1060 6GB a na strihanie pouzivam Corel Videostudio. Pri renderingu a vypnutej hardverovej akceleracii som mal CPU vyuzitie len okolo 40%, pri zapnuti hardverovej akceleracii kleslo CPU vyuzitie na 10% ale GPU isla len na cca 7%. Vysledny renderovaci cas bol vsak v obidvoch pripadoch rovnaky. Skusal som menit HDD aj inu graficku kartu ale vysledok bol ten isty.
Na prevod videa do mp4 pouzivam este softver Xmedia Recode. Ten dokaze vytazit CPU na maximum (vsetky jadra na 100%). Ak zapnem akceleraciu, CPU klesne na 20% a GPU mam na 35%. Lenze vysledny cas pri pouziti GPU je 3krat rychlejsi.
Takze podla mojho nazoru, strihaci program nedokaze vyuzit potencial CPU (vsetky jeho instrukcie).
Pri mojich pokusoch som este zistil, ze na komunikaciu CPU -> GPU ma vplyv aj frekvencia CPU (aj ked celkove zatazenie CPU sa nezmenilo). Ak mas moznost skus svoju i7-860 pretaktovat.
Na prevod videa do mp4 pouzivam este softver Xmedia Recode. Ten dokaze vytazit CPU na maximum (vsetky jadra na 100%). Ak zapnem akceleraciu, CPU klesne na 20% a GPU mam na 35%. Lenze vysledny cas pri pouziti GPU je 3krat rychlejsi.
Takze podla mojho nazoru, strihaci program nedokaze vyuzit potencial CPU (vsetky jeho instrukcie).
Pri mojich pokusoch som este zistil, ze na komunikaciu CPU -> GPU ma vplyv aj frekvencia CPU (aj ked celkove zatazenie CPU sa nezmenilo). Ak mas moznost skus svoju i7-860 pretaktovat.
Díky, nastavení Vegasu jsem samozřejmě zkontroloval, ovladače mám nejnovější (ne tedy od výrobce karty, ten má nejnovější někdy z roku 2014, ale stažené z webu AMD pro daný GPU HD7950). Já rozumím tomu, že ne všechny efekty umí VP akcelerovat, ale v tom případě bych pochopil poměr vytížení CPU 100% a GPU někde "u dna". Jenže oni se loudají oba dva. I když jsem povypínal všechny efekty a nechal tedy projekt renderovat bez úprav do Sony AVC, nic se na výsledném čase (ani zatížení) nezměnilo.
[QUOTE=warchief;527015]Nieco podobne som riesil aj ja. Mam cpu i7-4770K, gpu Geforce 1060 6GB a na strihanie pouzivam Corel Videostudio. Pri renderingu a vypnutej hardverovej akceleracii som mal CPU vyuzitie len okolo 40%, pri zapnuti hardverovej akceleracii kleslo CPU vyuzitie na 10% ale GPU isla len na cca 7%. Vysledny renderovaci cas bol vsak v obidvoch pripadoch rovnaky. Skusal som menit HDD aj inu graficku kartu ale vysledok bol ten isty.
Na prevod videa do mp4 pouzivam este softver Xmedia Recode. Ten dokaze vytazit CPU na maximum (vsetky jadra na 100%). Ak zapnem akceleraciu, CPU klesne na 20% a GPU mam na 35%. Lenze vysledny cas pri pouziti GPU je 3krat rychlejsi.
Takze podla mojho nazoru, strihaci program nedokaze vyuzit potencial CPU (vsetky jeho instrukcie).
Pri mojich pokusoch som este zistil, ze na komunikaciu CPU -> GPU ma vplyv aj frekvencia CPU (aj ked celkove zatazenie CPU sa nezmenilo). Ak mas moznost skus svoju i7-860 pretaktovat.[/QUOTE]
No tak že podobná situace bude i u (výrazně) výkonnějšího CPU i7-4770K, to bych nečekal a vypadá to, jakoby to byl skutečně problém VP, že nevyužívá potenciál GPU. Požádal jsem Magix, jestli by mi nevygeneroval nějaký krátkodobý kód pro trial verzi VP14 (třicetidenní trial jsem vyčerpal už na podzim, když byl VP14 novinkou), poslali mi čtyřdenní, ale první pokusy ukazují, že je to to samé, stejné renderovací časy i stejné ne-vytížení GPU (i CPU). Je tedy samozřejmě možné, že je problém někde v komunikaci CPU-GPU, ale netuším, kde může být.
Doplnění:
...anebo je proces kódování do Sony AVCHD prostě naprogramován tak, že nevyužije možností GPU.
Ještě jsem spouštěl ve VP13/14 testovací projekt, který vytvořil John Rofrano, celý se skládá jen z Vegasem renderovaných textur a na ně aplikovaných efektů. A tady se projevilo, že VP14 "udrží" fps náhledu do většího rozlišení náhledu (rozměru náhledového okna), než je tomu u VP13. Ověřil jsem si, že VP14 dokáže o trochu lépe (pozorovatelně) komunikovat s GPU při aplikaci akcelerovatelných efektů. Stejně jsem se ale při zvětšování okna náhledu (a poklesu fps náhledu) nedostal na více než 60% zatížení (využití) GPU. Aspoň jsem viděl, že VP14 dokáže GPU vybudit k větší aktivitě...
Na prevod videa do mp4 pouzivam este softver Xmedia Recode. Ten dokaze vytazit CPU na maximum (vsetky jadra na 100%). Ak zapnem akceleraciu, CPU klesne na 20% a GPU mam na 35%. Lenze vysledny cas pri pouziti GPU je 3krat rychlejsi.
Takze podla mojho nazoru, strihaci program nedokaze vyuzit potencial CPU (vsetky jeho instrukcie).
Pri mojich pokusoch som este zistil, ze na komunikaciu CPU -> GPU ma vplyv aj frekvencia CPU (aj ked celkove zatazenie CPU sa nezmenilo). Ak mas moznost skus svoju i7-860 pretaktovat.[/QUOTE]
No tak že podobná situace bude i u (výrazně) výkonnějšího CPU i7-4770K, to bych nečekal a vypadá to, jakoby to byl skutečně problém VP, že nevyužívá potenciál GPU. Požádal jsem Magix, jestli by mi nevygeneroval nějaký krátkodobý kód pro trial verzi VP14 (třicetidenní trial jsem vyčerpal už na podzim, když byl VP14 novinkou), poslali mi čtyřdenní, ale první pokusy ukazují, že je to to samé, stejné renderovací časy i stejné ne-vytížení GPU (i CPU). Je tedy samozřejmě možné, že je problém někde v komunikaci CPU-GPU, ale netuším, kde může být.
Doplnění:
...anebo je proces kódování do Sony AVCHD prostě naprogramován tak, že nevyužije možností GPU.
Ještě jsem spouštěl ve VP13/14 testovací projekt, který vytvořil John Rofrano, celý se skládá jen z Vegasem renderovaných textur a na ně aplikovaných efektů. A tady se projevilo, že VP14 "udrží" fps náhledu do většího rozlišení náhledu (rozměru náhledového okna), než je tomu u VP13. Ověřil jsem si, že VP14 dokáže o trochu lépe (pozorovatelně) komunikovat s GPU při aplikaci akcelerovatelných efektů. Stejně jsem se ale při zvětšování okna náhledu (a poklesu fps náhledu) nedostal na více než 60% zatížení (využití) GPU. Aspoň jsem viděl, že VP14 dokáže GPU vybudit k větší aktivitě...
boumis: Pokud jde o samotny encode do H264, zkus treba HW enkodovani VCE (Video Coding Engine) ktery by tva nova karta mela umet.
Treba ja mam GTX 750Ti a z Vegasu pres frameserver krmim NVEnc encoder (H264 VBR2 3000 kbps). FullHD video z timeline (bez jakychkoliv korekci a uprav) enkoduju rychlosti cca 180% realtime. CPU (i7 6700) je vytizen na cca 20-25%, GPU na cca 30-40%. Urcita rezie pada na prenos mezi Vegasem a NVEnc encoderem. Render toho sameho videa Sony AVC s podobnym nastavenim byl cca o 60% pomalejsi, CPU cca 68%.
Treba ja mam GTX 750Ti a z Vegasu pres frameserver krmim NVEnc encoder (H264 VBR2 3000 kbps). FullHD video z timeline (bez jakychkoliv korekci a uprav) enkoduju rychlosti cca 180% realtime. CPU (i7 6700) je vytizen na cca 20-25%, GPU na cca 30-40%. Urcita rezie pada na prenos mezi Vegasem a NVEnc encoderem. Render toho sameho videa Sony AVC s podobnym nastavenim byl cca o 60% pomalejsi, CPU cca 68%.
[QUOTE=aleycon;527592]boumis: Pokud jde o samotny encode do H264, zkus treba HW enkodovani VCE (Video Coding Engine) ktery by tva nova karta mela umet.
Treba ja mam GTX 750Ti a z Vegasu pres frameserver krmim NVEnc encoder (H264 VBR2 3000 kbps). FullHD video z timeline (bez jakychkoliv korekci a uprav) enkoduju rychlosti cca 180% realtime. CPU (i7 6700) je vytizen na cca 20-25%, GPU na cca 30-40%. Urcita rezie pada na prenos mezi Vegasem a NVEnc encoderem. Render toho sameho videa Sony AVC s podobnym nastavenim byl cca o 60% pomalejsi, CPU cca 68%.[/QUOTE]
Díky za reakci, teď se zeptám asi hodně neznale. Ono HW enkódování s označením "VCE" je označení schopnosti hardwaru nebo je VCE nějaká aplikace, kam frameserver posílá data z Vegasu? O NVEncoderu jsem se zatím dočetl/dogooglil, že je to sw pro karty Nvidia. Kdysi jsem z frame-serverováním něco zkoušel, ale už si to moc nepamatuju, tak se ptám radši asi jako někdo, kdo to viděl jen z rychlíku.
Díky za (radši) ještě jeden ťukanec...
Treba ja mam GTX 750Ti a z Vegasu pres frameserver krmim NVEnc encoder (H264 VBR2 3000 kbps). FullHD video z timeline (bez jakychkoliv korekci a uprav) enkoduju rychlosti cca 180% realtime. CPU (i7 6700) je vytizen na cca 20-25%, GPU na cca 30-40%. Urcita rezie pada na prenos mezi Vegasem a NVEnc encoderem. Render toho sameho videa Sony AVC s podobnym nastavenim byl cca o 60% pomalejsi, CPU cca 68%.[/QUOTE]
Díky za reakci, teď se zeptám asi hodně neznale. Ono HW enkódování s označením "VCE" je označení schopnosti hardwaru nebo je VCE nějaká aplikace, kam frameserver posílá data z Vegasu? O NVEncoderu jsem se zatím dočetl/dogooglil, že je to sw pro karty Nvidia. Kdysi jsem z frame-serverováním něco zkoušel, ale už si to moc nepamatuju, tak se ptám radši asi jako někdo, kdo to viděl jen z rychlíku.
Díky za (radši) ještě jeden ťukanec...
Podle mého názoru jde při střihu videa hlavně o výkon PC při vlastní editaci, při té člověk tráví nejvíc času. Rychlost renderingu není až tak důležitá a jde mi při něm zejména o výstupní kvalitu. Aby byla editace co nejpohodlnější, je základem co nejvýkonnější procesor a rychlý přístup k souborům. Výkon grafické karty se projeví jenom u efektů s podporou GPU. Nevím jak u jiných střihových softů, ale u Vegasu se vyšší výkonnost grafické karty v náhledu příliš neprojevuje. Porovnával jsem (subjektivně) rychlost Preview při použití integrované grafiky v procesoru 6700K, grafiky NVidia GTX 560 a grafiky NVidia GTX 950 a bohužel žádné zásadní rozdíly jsem nepozoroval. Měl jsem v úmyslu pořídit si novou výkonnou grafickou kartu, ale mám obavy že budu zklamaný. Tak co s tím?
[QUOTE=Saxel;527597]Podle mého názoru jde při střihu videa hlavně o výkon PC při vlastní editaci, při té člověk tráví nejvíc času. Rychlost renderingu není až tak důležitá a jde mi při něm zejména o výstupní kvalitu. Aby byla editace co nejpohodlnější, je základem co nejvýkonnější procesor a rychlý přístup k souborům. Výkon grafické karty se projeví jenom u efektů s podporou GPU. Nevím jak u jiných střihových softů, ale u Vegasu se vyšší výkonnost grafické karty v náhledu příliš neprojevuje. Porovnával jsem (subjektivně) rychlost Preview při použití integrované grafiky v procesoru 6700K, grafiky NVidia GTX 560 a grafiky NVidia GTX 950 a bohužel žádné zásadní rozdíly jsem nepozoroval. Měl jsem v úmyslu pořídit si novou výkonnou grafickou kartu, ale mám obavy že budu zklamaný. Tak co s tím?[/QUOTE]
Pokud vím, tak Vegas mnohem efektivněji využívá podporu GPU od AMD (ATI), než procesory NVidia. Z diskusí na CreativeCow jsem vyčetl i zkušenosti, že se slabším a starším CPU ale s grafikou od AMD bylo dosaženo lepších výsledků při preview a renderu než se silnějším procesorem a silnou grafikou NVidia.
Jinak souhlas, při střihu jde uživateli hlavně o komfort plynulého preview. Koneckonců, pokud někdo spouští render takříkajíc přes noc, je asi jedno, jestli doběhne o půl hodin dřív nebo později. Někdy je ale i minuta rozdílu užitečná, když je hodně velký fofr...
Můžu kdyžtak nabídnout na vyzkoušení půjčit grafiku s HD6870, oproti NVidii by měl Vegas být schopen vytěžit její potenciál lépe. Já jsem nedávno pořídil HD7950, ale rozdíl je jen v řádu jednotek procent (na preview je to ale znát už víc, naštěstí). Už to ale nechám být a HD6870 nabídnu o dům dál.
Pokud vím, tak Vegas mnohem efektivněji využívá podporu GPU od AMD (ATI), než procesory NVidia. Z diskusí na CreativeCow jsem vyčetl i zkušenosti, že se slabším a starším CPU ale s grafikou od AMD bylo dosaženo lepších výsledků při preview a renderu než se silnějším procesorem a silnou grafikou NVidia.
Jinak souhlas, při střihu jde uživateli hlavně o komfort plynulého preview. Koneckonců, pokud někdo spouští render takříkajíc přes noc, je asi jedno, jestli doběhne o půl hodin dřív nebo později. Někdy je ale i minuta rozdílu užitečná, když je hodně velký fofr...
Můžu kdyžtak nabídnout na vyzkoušení půjčit grafiku s HD6870, oproti NVidii by měl Vegas být schopen vytěžit její potenciál lépe. Já jsem nedávno pořídil HD7950, ale rozdíl je jen v řádu jednotek procent (na preview je to ale znát už víc, naštěstí). Už to ale nechám být a HD6870 nabídnu o dům dál.
Saxel, boumis: Mate pravdu ze nejvice casu se stravi s editaci, takze hbite nahledy jsou treba.
boumis: Myslel jsem to tak ze pokud jsi investoval do nove karty a ted jsi zjistil, ze Ti moc nepomohla, muzes ji vyuzit pro finalni render kdyz to pujde a budes chtit usetrit cas. NVEnc je jen pro NVdidie, pro tvuj Radeon bude neco jineho. Prekvapilo me ale jak kvalitni vystup NVEnc dava i pri pomerme nizkem bitrate. Pro prenos z Vegasu do NVEnc pouzivam docela kostrbatou cestu: Vegas -> DebugMode frameserver -> Avisynth (prevod z RGB na YUV12) -> avs2yuv -> NVEnc.
boumis: Myslel jsem to tak ze pokud jsi investoval do nove karty a ted jsi zjistil, ze Ti moc nepomohla, muzes ji vyuzit pro finalni render kdyz to pujde a budes chtit usetrit cas. NVEnc je jen pro NVdidie, pro tvuj Radeon bude neco jineho. Prekvapilo me ale jak kvalitni vystup NVEnc dava i pri pomerme nizkem bitrate. Pro prenos z Vegasu do NVEnc pouzivam docela kostrbatou cestu: Vegas -> DebugMode frameserver -> Avisynth (prevod z RGB na YUV12) -> avs2yuv -> NVEnc.
O tom, že Vegasu lépe sedí GPU od AMD jsem také četl, ale stejně mám pořád obavy jestli nemalá investice do nové grafiky přinese adekvátní zlepšení.
[QUOTE=Saxel;527611]O tom, že Vegasu lépe sedí GPU od AMD jsem také četl, ale stejně mám pořád obavy jestli nemalá investice do nové grafiky přinese adekvátní zlepšení.[/QUOTE]
Jak jsem zjistil, právě rozdíl mezi HD 6870 a HD 7950, kterou jsem pořídil, až zase tak závratný není a pochybuji, že kdyby to člověk v segmentu AMD "hnal vejš", že se dočká rozdílu v řádu třeba desítek procent. Spíš na to má vliv rychlost CPU. Když jsem na radu jednoho z diskutérů výše zkusil svůj stařičký prvogenerační i7-850 přetaktovat, hned se to projevilo na renderovacím čase asi o 15% rychlejším. Ale je zajímavé, že před přetaktováním nebyl CPU vytížen na 100%, takže se zdálo, že není přetížen a možná má i nějakou tu rezervu. Díky tomu mě nenapadlo CPU zkoušet taktovat. Ovšem je to jinak. Netuším, čím to může být, brzda je možná i jinde (mám desku s čipsetem P55 z roku 2009, také asi nic moc).
Nevím, jak "nemalou" investici do GK máš na mysli, ale jak jsem už psal, můžu poskytnout mou HD6870 ve výslužbě na vyzkoušení. Myslím, že při slušném zacházení to nebude ani pro ni ani pro mne riziko.
Jak jsem zjistil, právě rozdíl mezi HD 6870 a HD 7950, kterou jsem pořídil, až zase tak závratný není a pochybuji, že kdyby to člověk v segmentu AMD "hnal vejš", že se dočká rozdílu v řádu třeba desítek procent. Spíš na to má vliv rychlost CPU. Když jsem na radu jednoho z diskutérů výše zkusil svůj stařičký prvogenerační i7-850 přetaktovat, hned se to projevilo na renderovacím čase asi o 15% rychlejším. Ale je zajímavé, že před přetaktováním nebyl CPU vytížen na 100%, takže se zdálo, že není přetížen a možná má i nějakou tu rezervu. Díky tomu mě nenapadlo CPU zkoušet taktovat. Ovšem je to jinak. Netuším, čím to může být, brzda je možná i jinde (mám desku s čipsetem P55 z roku 2009, také asi nic moc).
Nevím, jak "nemalou" investici do GK máš na mysli, ale jak jsem už psal, můžu poskytnout mou HD6870 ve výslužbě na vyzkoušení. Myslím, že při slušném zacházení to nebude ani pro ni ani pro mne riziko.
myslim, ze by ti stacilo rozjet frame server jen kvuli tomu exportu(instalace Debugmode fRame serveru a Avisynthu), pokud pak budes enkodovat s nejakym x264 enkoderem tak ti pojede CPU na 100% (pokud nejaky efekt nezabrani tomuto ve Vegasu),
take mam nazor, ze samotna editace zabere tolik casu, ze export neni vpodstate dulezity, pokud to je jen na domaci videa urcite ...
frame server export:
vyhody -
-100% cpu (pokud pouzijes x264 enkoder i jine),
-lepsi enkodovani nez z GPU (pokud je prumerny bitrate shodny),
-dalsi vyhoda je moznost pouziti Zones (z Vegasu prectes cislo snimku pro zacatek a konec) - jine parametry na enkodovani podle casti videa, protoze pokud mas treba grafickou znelku ve videu ty potrbuji trochu vice datoveh toku atd.
-muzes pouzit CRF enkodovani ne VBR, pouziti VBRje pro tebe jako home usera naprosto nelogicke i chybne (bud mrhas datovym tokem, nebo tomu nedas dost, jedno nebo druhe, do optimalnih datoveho toku se nikdy netrefis, CRF je vzdy 1pass, VBR 2pass, takze uz tim, ze pouzijes jen 1pass mas usetreno a navic video enkodujes vedecky a ne podle nejake vestecke koule (hadanim prumerneho bitrate)
,
ale CRF muzes pouzit i po pouziti intermediate videa jako SonyUYV (silene velikosti) nebo lossless videa a pak to enkodovat, ale to je jen take ztrata casu a potrebujes na to extra hardisk, kdezto frame server ma velikost skoro nula, vzdy jen velikost nekolika snimku, ktere zrovna necemu predava (pokud tam do toho virtualniho avi jeste neprida cele PCM audio, kdyz to zaskrtnes pri exportu)
-muzes pouzivat i prehistorickou verzi Vegasu a mit nejnovejsi enkodovaci program na enkodovani (protoze enkodujes mimo starsi Vegas) napr. ja pokud striham stare HDV nahravky pouziju stary dobry 32bit Vegas 8.0c, protoze to byla posledni naprosto skoro bezchybna verze (navic to nema zadne frame server bugs)
nevyhoda - pokud mas na timeline vice typu videa, neni to moc vhodne, protoze Frame server exportuje jen jeden typ, to co mas v properties projektu, takze ty dalsi typy videa se zbytecne 2x prepocitavaji, tedy frame server je vhodny pouzivat jen pokud mas na timeline jen jeden typ videa, stejnych parametru
-dalsi nevyhoda je, to, ze to samozrejme chvili trva nez to poprve rozjedes nasetupujes atd., potrebujes zjistit co Avisynth je, jak to funguje ..
-frame server muze produkovat tzv. audio bug, da se tomu vyhnout, ale to muze byt dalsi ztrata casu pro tebe, nektere verze Vegasu vykazuji ten bug
take mam nazor, ze samotna editace zabere tolik casu, ze export neni vpodstate dulezity, pokud to je jen na domaci videa urcite ...
frame server export:
vyhody -
-100% cpu (pokud pouzijes x264 enkoder i jine),
-lepsi enkodovani nez z GPU (pokud je prumerny bitrate shodny),
-dalsi vyhoda je moznost pouziti Zones (z Vegasu prectes cislo snimku pro zacatek a konec) - jine parametry na enkodovani podle casti videa, protoze pokud mas treba grafickou znelku ve videu ty potrbuji trochu vice datoveh toku atd.
-muzes pouzit CRF enkodovani ne VBR, pouziti VBRje pro tebe jako home usera naprosto nelogicke i chybne (bud mrhas datovym tokem, nebo tomu nedas dost, jedno nebo druhe, do optimalnih datoveho toku se nikdy netrefis, CRF je vzdy 1pass, VBR 2pass, takze uz tim, ze pouzijes jen 1pass mas usetreno a navic video enkodujes vedecky a ne podle nejake vestecke koule (hadanim prumerneho bitrate)
,
ale CRF muzes pouzit i po pouziti intermediate videa jako SonyUYV (silene velikosti) nebo lossless videa a pak to enkodovat, ale to je jen take ztrata casu a potrebujes na to extra hardisk, kdezto frame server ma velikost skoro nula, vzdy jen velikost nekolika snimku, ktere zrovna necemu predava (pokud tam do toho virtualniho avi jeste neprida cele PCM audio, kdyz to zaskrtnes pri exportu)
-muzes pouzivat i prehistorickou verzi Vegasu a mit nejnovejsi enkodovaci program na enkodovani (protoze enkodujes mimo starsi Vegas) napr. ja pokud striham stare HDV nahravky pouziju stary dobry 32bit Vegas 8.0c, protoze to byla posledni naprosto skoro bezchybna verze (navic to nema zadne frame server bugs)
nevyhoda - pokud mas na timeline vice typu videa, neni to moc vhodne, protoze Frame server exportuje jen jeden typ, to co mas v properties projektu, takze ty dalsi typy videa se zbytecne 2x prepocitavaji, tedy frame server je vhodny pouzivat jen pokud mas na timeline jen jeden typ videa, stejnych parametru
-dalsi nevyhoda je, to, ze to samozrejme chvili trva nez to poprve rozjedes nasetupujes atd., potrebujes zjistit co Avisynth je, jak to funguje ..
-frame server muze produkovat tzv. audio bug, da se tomu vyhnout, ale to muze byt dalsi ztrata casu pro tebe, nektere verze Vegasu vykazuji ten bug
ai: děkuju za nastartování, rád zkusím něco pro mne zatím nového, nevyzkoušeného. Budu se tedy snažit proniknout do (zatím) tajů frameservingu. Pokud můžu poprosit o nějaké odkazy na přínosné články na toto téma, budu rád. Předem dík!
nainstaluj oba programy, Debugmode frame server a Avisynth ,v pripade frame serveru se ti objevi v nabidce exportu, pokud ne je nekde chyba
nainstaluj Avisyhtn a nic se neobjevi, neexistuje ani zadna ikona pro PC, program proste ani neexistuje, nainstalit Avisynth znamena, ze PC po tomto momente vi, ze textovy soubor s priponou *.avs je proste video, je to v registrech a nejake dll je pak jeste ve Widows system slozce
Jak tohle prekousnes, tu podivnost, ze proste nejaky tvuj textovy soubor neco.avs , s priponou avs, ne txt, muze ted znamenat po instalaci Avisynthu i video, kde ho muzes nacist do nejakeho x264 enkoderu nebo videoplayeru, ktere to proste nactou jako video, tak jedes dal ... :-)
Export z Vegasu s pouzitim frame serveru:
[SPOILER]-tvoje project properties ve Vegasu musi byt shodne jako properties klipu, protoze Vegas frame server exportuje properties projektu , ne klipu
-exportujes virtualni avi z Vegasu pomoci frame serveru, RGB32, nazves ho treba moje.avi ,minimize Vegas do spodni listy, aby neprekazel, nic se jeste nespusti, frame server zacne predavat snimky az spustis nekde pozdeji skript
-otevres notepad a napises tam:
[CODE]AviSource("C:\server\moje.avi")
ConvertToYV12(matrix="PC.709") #pokud exportujes RGB32 z Vegasu a pokud bys mel barvy zasedle bez tohoto radku[/CODE]
kde tam napises samozrejme zpravnouy cestu kde to mas v PC, ten virtualni moje.avi, tento soubor pak ulozis a das mu jmeno moje.avs, pozor, ne moje.txt
v tomto momente muzes zkusit i prehrat tve video, poloz ten moje.avs na MPC-HC treba , nebo do VirtualDubu, nebo i Windows Media Playeru (VLC nenacte ten avs napr.)
-pak ten moje.avs nactes do enkodovaciho programu , ktery muze nacist VFW avi, (ne Handbrake, tam to jde jen oklikou pres virtualni avi, to je mela pak, do toho Handbraku se to dostane "live" pres asi odhadem 5 aplikaci :-) ), vpodstate jakykoliv x264 enkoder nebo ffmpeg enkoder
-po skonceni enkodovani zastavis ve Vegasu frame server (STOP frame server), p.s. ja ho mam spusteny nekdy i tydny, pokud to zapomenu, ale naprosto to nicemu nevadi[/SPOILER]
nainstaluj Avisyhtn a nic se neobjevi, neexistuje ani zadna ikona pro PC, program proste ani neexistuje, nainstalit Avisynth znamena, ze PC po tomto momente vi, ze textovy soubor s priponou *.avs je proste video, je to v registrech a nejake dll je pak jeste ve Widows system slozce
Jak tohle prekousnes, tu podivnost, ze proste nejaky tvuj textovy soubor neco.avs , s priponou avs, ne txt, muze ted znamenat po instalaci Avisynthu i video, kde ho muzes nacist do nejakeho x264 enkoderu nebo videoplayeru, ktere to proste nactou jako video, tak jedes dal ... :-)
Export z Vegasu s pouzitim frame serveru:
[SPOILER]-tvoje project properties ve Vegasu musi byt shodne jako properties klipu, protoze Vegas frame server exportuje properties projektu , ne klipu
-exportujes virtualni avi z Vegasu pomoci frame serveru, RGB32, nazves ho treba moje.avi ,minimize Vegas do spodni listy, aby neprekazel, nic se jeste nespusti, frame server zacne predavat snimky az spustis nekde pozdeji skript
-otevres notepad a napises tam:
[CODE]AviSource("C:\server\moje.avi")
ConvertToYV12(matrix="PC.709") #pokud exportujes RGB32 z Vegasu a pokud bys mel barvy zasedle bez tohoto radku[/CODE]
kde tam napises samozrejme zpravnouy cestu kde to mas v PC, ten virtualni moje.avi, tento soubor pak ulozis a das mu jmeno moje.avs, pozor, ne moje.txt
v tomto momente muzes zkusit i prehrat tve video, poloz ten moje.avs na MPC-HC treba , nebo do VirtualDubu, nebo i Windows Media Playeru (VLC nenacte ten avs napr.)
-pak ten moje.avs nactes do enkodovaciho programu , ktery muze nacist VFW avi, (ne Handbrake, tam to jde jen oklikou pres virtualni avi, to je mela pak, do toho Handbraku se to dostane "live" pres asi odhadem 5 aplikaci :-) ), vpodstate jakykoliv x264 enkoder nebo ffmpeg enkoder
-po skonceni enkodovani zastavis ve Vegasu frame server (STOP frame server), p.s. ja ho mam spusteny nekdy i tydny, pokud to zapomenu, ale naprosto to nicemu nevadi[/SPOILER]
Instalací a používáním Avisynthu a Frameserveru posuneš tvé workflow na vyšší úroveň. Vedle zmíněného kvalitního enkódování videa pomocí X264 můžeš v budoucnu využít i spoustu bezplatných a mnohdy velmi kvalitních filtrů napsaných pro avisynth, jako např. deinterlacing, zpomalení scény vytvořením mezisnímků, resize, úprava starých záznamů z VHS apod.
PS. už se odchylujeme od tématu tohoto vlákna...
PS. už se odchylujeme od tématu tohoto vlákna...
[QUOTE=ai;527618]-muzes pouzit CRF enkodovani ne VBR, pouziti VBRje pro tebe jako home usera naprosto nelogicke i chybne (bud mrhas datovym tokem, nebo tomu nedas dost, jedno nebo druhe, do optimalnih datoveho toku se nikdy netrefis, CRF je vzdy 1pass, VBR 2pass, takze uz tim, ze pouzijes jen 1pass mas usetreno a navic video enkodujes vedecky a ne podle nejake vestecke koule (hadanim prumerneho bitrate)
,[/QUOTE]
Dovolim si uvest na pravou miru nekolik nepresnosti.
1) VBR je 2pass. To neni obecne pravda, muzes mit i 1 pass VBR.
2) VBR je nelogicke a chybne. To preci obecne zavisi na kvalite daneho enkodovaciho algoritmu, nikoliv pausalne na metode samotne.
3) Pri pouziti CRF enkodujes vedecky a ne podle nejake vestecke koule (hadanim prumerneho bitrate). Opet nelze pausalizovat a je to odvisle od kvality algoritmu daneho enkoderu. Pro finalni render kde chci nejlepsi moznou kvalitu je 2 pass metoda prave vhodna (pokud ji dany enkoder opravdu dobre zvlada a prinese oproti 1 pass vyrazne zlepseni). To ze to zabere vice casu neni preci dulezite, zvlast pokud nejvice casu spolkla vlastni editace.
,[/QUOTE]
Dovolim si uvest na pravou miru nekolik nepresnosti.
1) VBR je 2pass. To neni obecne pravda, muzes mit i 1 pass VBR.
2) VBR je nelogicke a chybne. To preci obecne zavisi na kvalite daneho enkodovaciho algoritmu, nikoliv pausalne na metode samotne.
3) Pri pouziti CRF enkodujes vedecky a ne podle nejake vestecke koule (hadanim prumerneho bitrate). Opet nelze pausalizovat a je to odvisle od kvality algoritmu daneho enkoderu. Pro finalni render kde chci nejlepsi moznou kvalitu je 2 pass metoda prave vhodna (pokud ji dany enkoder opravdu dobre zvlada a prinese oproti 1 pass vyrazne zlepseni). To ze to zabere vice casu neni preci dulezite, zvlast pokud nejvice casu spolkla vlastni editace.
ad 2): Máš pravdu že jsou situace, kdy použití 2-pass VBR dává smysl. Je to tehdy, když potřebuju hlídat velikost výstupu aby mi efektivně zaplnil datové médium, např. při rendrování videa pro DVD disk.
ad 3): Pro ruční nastavení vhodné průměrné bitrate u 2-pass VBR je potřeba odhadnout komprimační náročnost zdrojového videa. Když nastavím víc než je potřeba, kvalita bude OK, ale soubor zbytečně velký. Když nastavím míň, odnese to výsledná kvalita. Metoda CRF má jasně navrch - já jen nastavím faktor požadované kvality výstupu a enkodér si řídí bitrate podle náročnosti zdroje a nastaveného faktoru kvality.
ad 3): Pro ruční nastavení vhodné průměrné bitrate u 2-pass VBR je potřeba odhadnout komprimační náročnost zdrojového videa. Když nastavím víc než je potřeba, kvalita bude OK, ale soubor zbytečně velký. Když nastavím míň, odnese to výsledná kvalita. Metoda CRF má jasně navrch - já jen nastavím faktor požadované kvality výstupu a enkodér si řídí bitrate podle náročnosti zdroje a nastaveného faktoru kvality.
1) 1passVBR (ne CRF) je nepouzitelne, nema zadny prakticky vyznam, i jako internet stream je nutne pouzit 1pass CRF s omezenymi buffers (limitujicim bitrate), kde zvolenim CRF se zvysi ci snizi kvalita , ale maximalni spicky jsou porad v mezich buffers, napr. --vbv-maxrate 2000 --vbv-bufsize 2000, bude to litat max do 2500Mbt/s
2) pokud enkodujes CRF 1pass , nejaky film, pak vypoctes prumerny bitrate, enkodujes znovu 2pass na ten prumerny bitrate , absolutne stejne nastaveni jako CRF (a nedojde k urezani spicek, cut off) tak video je skoro naprosto totozne u x264 (pod lupou najdes treba nejake drobne rozdily samozrejme). CRF a VBR pouziva naprosto stejne algoritmy, defacto VBR je vpodstate CRF, a ne naopak. Je to na prvni pohled nelogicke, ale je to tak, i 2pass VBR puziva quantizer. Bavime se o x264. Jine enkodery nas nezajimaji. Limitovany MainConcept v NLE ani CRF nema. Alghoritmy ux264 jsou napsany jak CRF predevsim. Proto ja nechapu proc NLE jej nepouzivaji nebo to je slendrian, nebo proste politika, protoze ty NLE nepouzivaji plne enkodovaci verze tech jejich enkoderu (MainConcept)
3)skutecne si to promysli, ty ten prumerny bitrate nikdy neznas, nemuzes se nikdy trefit do nejake kvality, lisi se to video od videa, (ne CRF) jedine co 2pass VBR dela, je to, ze ty si pripravis kbelik a on ti uspesne vse akorat do nej vse nacpe, co nejefektivneji, ale ty nikdy nevis jak velky kbelik potrebujes, netusis to, to je ta nevedeckost. Je to to same jako kdyz nas na prumce ucitel matemamtiky buzeroval za to, ze jsme mu dali vysledek na 4 desetinna cisla, kde predtim nekde ve vypoctu doslo k zaokrouhleni na dve desetinna mista, nema to pak smysl, ty 4 desetinna cisla ve vysledku. Tedy co na tom, ze to tam nacpes uspesne, kdyz velikost kbeliku (prumerny bitrate) je spatny. To CRF ti ten kbelik vybere podle sebe.
Lidi se snazi enkodovat filmy videa a reknou si, film musi mit 2BG a pak se mi cleze atd., ale neuvedomi si, ze to co potrebuje je prumerna velikost filmu nebo videa, udelas 20 videi, filmu a zjistis ze CRF18 ti dava PRUMER 2GB na video/film jeden ma 1.2, druhy 3.8 ctvrty 2.4, ale prumer treba 2GB. To je ta vedeckost. Kvalitu mas konzistentni a 2GB. 2pass VBR ti napraska kbeliky , kazdy 2BG, kvalita nekonzistentni a oba mate ve vysledky disk stejne plny.
Neco jineho je DVD a BD, tam samozrejme, zvolis 2pass VBR a jedes do maxima objemu a pak se modlis, jestli kvalita bude ok.
U CRF se nemodlis, tam vis, pro to a to video, low light musim mit CRF 17, velmi dobre osvetlene veci mi daji vzdy dobry vysleke, kdyz natocim strom s temi miliony listku tak mi bitrate naskoci az na 50000, proto nastavim CRF 17 nebo 18 ale nastavim buffers, limitujici bitrate na 40000, pouziju --vbv-maxrate 35000 --vbv-bufsize 35000, pokud mam video nizke kvality a vim, ze tam bude hodne "banding" tak pritlacim na pilu a dam CRF 16 nebo 17 a omezim buffers jeste vice, aby mi to nedavalo prilis velky bitrate, protoze vim, ze sceny, ktere si vezmou 30000 vypadaji vzdy slusne, tedy pouziju i --vbv-maxrate 30000 --vbv-bufsize 30000 a mene
u VBR ztravis cely den a hledas optimalni prumerny bitrate a u noveho videa filmu muzes zacit znova, vsechno je zase jinak, to je ta nevedeckost take, u CRF a zvolenem CRF quantizeru je ti jasneji a ucis se ... pokud je nekde zrno bude to davat az 2x vetsi bitrate, ale zase u animace a filmech bez filmoveho zrna, budes dostavat velmi prekvapive nizke datove toky, tedy znova u toho 2pass VBR netusis co mas ...
proste vedecky ridim kvalitu a netipuju
2) pokud enkodujes CRF 1pass , nejaky film, pak vypoctes prumerny bitrate, enkodujes znovu 2pass na ten prumerny bitrate , absolutne stejne nastaveni jako CRF (a nedojde k urezani spicek, cut off) tak video je skoro naprosto totozne u x264 (pod lupou najdes treba nejake drobne rozdily samozrejme). CRF a VBR pouziva naprosto stejne algoritmy, defacto VBR je vpodstate CRF, a ne naopak. Je to na prvni pohled nelogicke, ale je to tak, i 2pass VBR puziva quantizer. Bavime se o x264. Jine enkodery nas nezajimaji. Limitovany MainConcept v NLE ani CRF nema. Alghoritmy ux264 jsou napsany jak CRF predevsim. Proto ja nechapu proc NLE jej nepouzivaji nebo to je slendrian, nebo proste politika, protoze ty NLE nepouzivaji plne enkodovaci verze tech jejich enkoderu (MainConcept)
3)skutecne si to promysli, ty ten prumerny bitrate nikdy neznas, nemuzes se nikdy trefit do nejake kvality, lisi se to video od videa, (ne CRF) jedine co 2pass VBR dela, je to, ze ty si pripravis kbelik a on ti uspesne vse akorat do nej vse nacpe, co nejefektivneji, ale ty nikdy nevis jak velky kbelik potrebujes, netusis to, to je ta nevedeckost. Je to to same jako kdyz nas na prumce ucitel matemamtiky buzeroval za to, ze jsme mu dali vysledek na 4 desetinna cisla, kde predtim nekde ve vypoctu doslo k zaokrouhleni na dve desetinna mista, nema to pak smysl, ty 4 desetinna cisla ve vysledku. Tedy co na tom, ze to tam nacpes uspesne, kdyz velikost kbeliku (prumerny bitrate) je spatny. To CRF ti ten kbelik vybere podle sebe.
Lidi se snazi enkodovat filmy videa a reknou si, film musi mit 2BG a pak se mi cleze atd., ale neuvedomi si, ze to co potrebuje je prumerna velikost filmu nebo videa, udelas 20 videi, filmu a zjistis ze CRF18 ti dava PRUMER 2GB na video/film jeden ma 1.2, druhy 3.8 ctvrty 2.4, ale prumer treba 2GB. To je ta vedeckost. Kvalitu mas konzistentni a 2GB. 2pass VBR ti napraska kbeliky , kazdy 2BG, kvalita nekonzistentni a oba mate ve vysledky disk stejne plny.
Neco jineho je DVD a BD, tam samozrejme, zvolis 2pass VBR a jedes do maxima objemu a pak se modlis, jestli kvalita bude ok.
U CRF se nemodlis, tam vis, pro to a to video, low light musim mit CRF 17, velmi dobre osvetlene veci mi daji vzdy dobry vysleke, kdyz natocim strom s temi miliony listku tak mi bitrate naskoci az na 50000, proto nastavim CRF 17 nebo 18 ale nastavim buffers, limitujici bitrate na 40000, pouziju --vbv-maxrate 35000 --vbv-bufsize 35000, pokud mam video nizke kvality a vim, ze tam bude hodne "banding" tak pritlacim na pilu a dam CRF 16 nebo 17 a omezim buffers jeste vice, aby mi to nedavalo prilis velky bitrate, protoze vim, ze sceny, ktere si vezmou 30000 vypadaji vzdy slusne, tedy pouziju i --vbv-maxrate 30000 --vbv-bufsize 30000 a mene
u VBR ztravis cely den a hledas optimalni prumerny bitrate a u noveho videa filmu muzes zacit znova, vsechno je zase jinak, to je ta nevedeckost take, u CRF a zvolenem CRF quantizeru je ti jasneji a ucis se ... pokud je nekde zrno bude to davat az 2x vetsi bitrate, ale zase u animace a filmech bez filmoveho zrna, budes dostavat velmi prekvapive nizke datove toky, tedy znova u toho 2pass VBR netusis co mas ...
proste vedecky ridim kvalitu a netipuju
Saxel, ai: Dal jsem si tu praci a otestoval H264 encoding nekolika HD videi (reklamy z TV) s hodne detaily (napr. vanocni stromek, louka plna lucni travy, ...) nebo vetsim pohybem v obrazu. Musim priznat ze volba s CRF dava opravdu skvele vysledky. Testoval jsem ffMPEG a HandBrake. Zde musim rict ze ffMPEG v posl. verzi (20161227-0ff8c6b) dava o trochu lepsi vysledky nez HandBrake 1.0, alespon co se tyce zachovani urovni ve stinech. Buffers jsem nikdy nijak neomezoval, at si bitrate vyleti az kam chce (ve spickach treba i pres 100 Mbps pro jednotl. framy (pro crf 18) - viz Bitrate Viewer).
Velmi dobre vysledky daval i NVEnc pro NVidii na me GFX 750Ti, tam neni sice crf, ale mechanismus konst. kvality ma take. Na nove desitkove rade GFX by to mozna bylo jeste lepsi.
Nicmene 2pass VBR je podle me dobrou volbou pro pripad kdy potrebuju determinovat velikost vyst. souboru a mensi ci vetsi ztrata kvality neni tak podstatna.
Velmi dobre vysledky daval i NVEnc pro NVidii na me GFX 750Ti, tam neni sice crf, ale mechanismus konst. kvality ma take. Na nove desitkove rade GFX by to mozna bylo jeste lepsi.
Nicmene 2pass VBR je podle me dobrou volbou pro pripad kdy potrebuju determinovat velikost vyst. souboru a mensi ci vetsi ztrata kvality neni tak podstatna.
Handbrake, ffmpeg (pokud nastavis -vcodec libx264 doporucuju), vsechny enkodery na bazi x264 enkoderu, vsechny pokud snad pouzivaji vzdy nejakou posledni aktualizovanou x264 library, nevim jak casto treba Handbrake aktualizuje, tam muze byt spozdeni, tak bys mel vzdy se stejnym nastavenim dostat stejny vysledek. Vsechny enkodery pouzivaji x264.
To je prave problem GUI enkoderu, ony ti "v pozadi", v tichosti, nastavi parametry vzdy jinak, a pak se to hodnoti, ten a ten enkoder je lepsi. Ale pokud das parametry stejne, tak se dostane i stejny vysledek. Prave proto mam rad command line, tam nastavis par hodnot a vis , ze zbytek bude default, a ty hodnoty znas.
To je prave problem GUI enkoderu, ony ti "v pozadi", v tichosti, nastavi parametry vzdy jinak, a pak se to hodnoti, ten a ten enkoder je lepsi. Ale pokud das parametry stejne, tak se dostane i stejny vysledek. Prave proto mam rad command line, tam nastavis par hodnot a vis , ze zbytek bude default, a ty hodnoty znas.
Ahoj po "nějaké" době, slíbil jsem, že vyzkouším avisynth workflow a dám sem vědět. Dnes jsem konečně nainstaloval, vyzkoušel a nestačím se divit. Hned při prvním pokusu o kódování do MP4/H.264 byla velikost minutového vzorku 1080/50p po exportu téměř třikrát menší a rendering trval o třetinu méně než přímo z Vegas Pro 13 (Použil jsem XMedia Recode). Ale hlavně, ten soubor renderovaný přes avisynth byl nejenom menší a rychleji zpracovaný, ale hlavně viditelně kvalitnější (jednalo se o záznam tanečního divadelního vystoupení, sice s klidným černým pozadím, ale také s rychle se pohybujícími mnoha tanečníky). Po prvním, relativně rychlém a nijak příliš hlubokém zkoumání jsem fakt nadšen z nových možností renderování.
Díky všem za rady, i když se toto vlákno stočilo poněkud jiným směrem, než jakým jsem jej původně "vykopával".
Díky všem za rady, i když se toto vlákno stočilo poněkud jiným směrem, než jakým jsem jej původně "vykopával".
http://videobird.cz/index.php/stahnout/item/prevod-hdv-do-sd-rozliseni
Tady je když tak návod, jak z Vegasu přes FrameServer ven, např pro HD do SD rozlišení
Tady je když tak návod, jak z Vegasu přes FrameServer ven, např pro HD do SD rozlišení
jej, to je navod asi 10 let stary od Fantase. :-)
Tenkrat to letelo Vegas -Frame Server -VirtualDub - Carbon Coder, on to tam vysvetluje, tak jsme kdysi zacinali delat DVD.
Podrobneji Fantas to zacal delat pres VirtualDub, protoze tam byl velice dobry prevod rozliseni na SD. Prokladany HD na prokladany SD.
Dalsi alternativy dneska:
VirtualDub pouziva algoritmus na zmenu rozliseni, prokladany HD na prokladany SD, ktery je v tomto ohledu celkem solidni.
Existuje filter napsany pro Avisynth primo, od Donald Graf, ktery zohlednil ten VD filter, jmenoval se VD smart resize myslim.
Dneska lze pouzit IResize pro Avisynth. Takze zajizdka pres VirtualDub a take pouziti VirtualDubu serveru neni treba. Takze je mozno VirtualDub vynechat. Napise se skript pro Avisynth ten se primo nacte do enkoderu.
Na enkodovani je v tom pdf ukazany Carbon Coder, ale zase, dneska se free HcEncoder take vypracoval je mozno jej s klidem pouzit a ma i 1pass quality kodovani (pro DVD kratsi nez hodinu a deset minut priblizne jej s klidem mozno pouzit). I kdyz ten Coder je snad nejlepsi co na mpeg2 tu je nebo bylo.
Toto se tyka enkodovani na DVD a kdyz original je prokladany. Pokud neni HD prokladane ale treba 50p, je mozno pouzit take IResize. 50p HD na 25i SD se dost spatne prevadi take, protoze to vetsinou silene blika. A prave ta kombinace IResize a pak jeste low pass filter (obycejny vertikalni blur) zapricini odstraneni blikani horizontalnich hran. Ten low pass filter je klasicky trade-off. Vice , znamena mene blikani, ale video je mene ostre. Skoro zadny, zaznam je ostrejsi a muze to blikat. Nebo experimentovat co doporucuje treba uzivatel Skiller. I kdyz ten IResize prave to blikani potlacuje. Je to chroma aware resize. To blikani je prave stvoreno v momente kdyz se znova vyrabi prokladani.
IResize muze primo udelat prokladane HD na prokladane SD. Tak jako to del ten VD treba, jak to Fantas vysvetluje v tom VD.
Tenkrat to letelo Vegas -Frame Server -VirtualDub - Carbon Coder, on to tam vysvetluje, tak jsme kdysi zacinali delat DVD.
Podrobneji Fantas to zacal delat pres VirtualDub, protoze tam byl velice dobry prevod rozliseni na SD. Prokladany HD na prokladany SD.
Dalsi alternativy dneska:
VirtualDub pouziva algoritmus na zmenu rozliseni, prokladany HD na prokladany SD, ktery je v tomto ohledu celkem solidni.
Existuje filter napsany pro Avisynth primo, od Donald Graf, ktery zohlednil ten VD filter, jmenoval se VD smart resize myslim.
Dneska lze pouzit IResize pro Avisynth. Takze zajizdka pres VirtualDub a take pouziti VirtualDubu serveru neni treba. Takze je mozno VirtualDub vynechat. Napise se skript pro Avisynth ten se primo nacte do enkoderu.
Na enkodovani je v tom pdf ukazany Carbon Coder, ale zase, dneska se free HcEncoder take vypracoval je mozno jej s klidem pouzit a ma i 1pass quality kodovani (pro DVD kratsi nez hodinu a deset minut priblizne jej s klidem mozno pouzit). I kdyz ten Coder je snad nejlepsi co na mpeg2 tu je nebo bylo.
Toto se tyka enkodovani na DVD a kdyz original je prokladany. Pokud neni HD prokladane ale treba 50p, je mozno pouzit take IResize. 50p HD na 25i SD se dost spatne prevadi take, protoze to vetsinou silene blika. A prave ta kombinace IResize a pak jeste low pass filter (obycejny vertikalni blur) zapricini odstraneni blikani horizontalnich hran. Ten low pass filter je klasicky trade-off. Vice , znamena mene blikani, ale video je mene ostre. Skoro zadny, zaznam je ostrejsi a muze to blikat. Nebo experimentovat co doporucuje treba uzivatel Skiller. I kdyz ten IResize prave to blikani potlacuje. Je to chroma aware resize. To blikani je prave stvoreno v momente kdyz se znova vyrabi prokladani.
IResize muze primo udelat prokladane HD na prokladane SD. Tak jako to del ten VD treba, jak to Fantas vysvetluje v tom VD.
Díky, mně se hodí do začátků i třeba deset let starý návod od Fantase...
Vím, že sice dál podporuji ne úplně správný odklon od původního tématu, ale v čem je někým zmiňovaný problém při frameservingu z projektu, kde je smícháno víc typů materiálu? Já měl v projektu 1080/50p dva druhy klipů - 1080/50p a 720/50p a nepozoroval jsem žádný problém. Díky.
Vím, že sice dál podporuji ne úplně správný odklon od původního tématu, ale v čem je někým zmiňovaný problém při frameservingu z projektu, kde je smícháno víc typů materiálu? Já měl v projektu 1080/50p dva druhy klipů - 1080/50p a 720/50p a nepozoroval jsem žádný problém. Díky.
Nemusi to tak vadit jako v tvem pripade. Frame server exportuje tak jak jsou nastaveny vlastnosti projektu. Takze jedno rozliseni meni Vegas jeste pred exportem.
Napr. Pokud exportujes na DVD podle toho navodu od Fantase a mas treba projekt nastaveny na 1080/50p , tak Vegas prepocitava ten 720/50p klip na 1080/50p a pak zase podle toho navodu se to meni na SD. Takze to asi neni zadouci. Video je zpracovano 2x a ne jen jednou. Ale vtip je v tom, ze v tvem pripade je ta zmena - neprokladane video na zase neprokladane (progresivni), a to Vegas vylozene neskazi, no a pak to znova zase zmensi pozdeji na SD, takze videt nic moc neni.
Vice to vadi pokud v projektu jsou kombince prokladeneho a neprokladaneho videa. Tam Vegas je nucen v jednom pripade odstranit prokladani, nebo v druhem pripade vyrobit prokladani. A to je v primem rozporu kvuli cemuz vlastne frameserver pouzivame (no jeden z duvodu), aby Vegas nedelal nic z prokladanim a delalo se to mimo Vegas.
Napr. Pokud exportujes na DVD podle toho navodu od Fantase a mas treba projekt nastaveny na 1080/50p , tak Vegas prepocitava ten 720/50p klip na 1080/50p a pak zase podle toho navodu se to meni na SD. Takze to asi neni zadouci. Video je zpracovano 2x a ne jen jednou. Ale vtip je v tom, ze v tvem pripade je ta zmena - neprokladane video na zase neprokladane (progresivni), a to Vegas vylozene neskazi, no a pak to znova zase zmensi pozdeji na SD, takze videt nic moc neni.
Vice to vadi pokud v projektu jsou kombince prokladeneho a neprokladaneho videa. Tam Vegas je nucen v jednom pripade odstranit prokladani, nebo v druhem pripade vyrobit prokladani. A to je v primem rozporu kvuli cemuz vlastne frameserver pouzivame (no jeden z duvodu), aby Vegas nedelal nic z prokladanim a delalo se to mimo Vegas.
Začal jsem používat Sony Vegas 14, a chtěl jsem vyzkoušet render přes Avisynth, jak píše boumis pátý příspěvek nade mnou.
Nainstaloval jsem Avisynth, a Virtualddub, ale nějak nevím jak na to. Přečetl jsem ti tuto stránku http://jech.webz.cz/avisynth.php, ale tam se také konkrétní návod nepíše. Dá se někde sehnat návod krok za krokem?
Do Sony Vegas 14 PRO 64bit jsem odtud stáhnul a nainstaloval Debugmode frameserver verzi 2.15: http://www.debugmode.com/frameserver/.
Dal jsem renderovat jen 10s video přes Frameserver a stojí to pořád na 0%. Přitom uplynulý čas pořád běží už 1,5 hodiny, a předpokladaný celkový čas je už 14 hodin (a pořád narůstá). A 4jádrový procesor je vytížený jen na 3%. Nastavení frameserveru jsem nechal defaultní (a při jiném to je také stejné).
Může někdo poradit kde je chyba?
Nainstaloval jsem Avisynth, a Virtualddub, ale nějak nevím jak na to. Přečetl jsem ti tuto stránku http://jech.webz.cz/avisynth.php, ale tam se také konkrétní návod nepíše. Dá se někde sehnat návod krok za krokem?
Do Sony Vegas 14 PRO 64bit jsem odtud stáhnul a nainstaloval Debugmode frameserver verzi 2.15: http://www.debugmode.com/frameserver/.
Dal jsem renderovat jen 10s video přes Frameserver a stojí to pořád na 0%. Přitom uplynulý čas pořád běží už 1,5 hodiny, a předpokladaný celkový čas je už 14 hodin (a pořád narůstá). A 4jádrový procesor je vytížený jen na 3%. Nastavení frameserveru jsem nechal defaultní (a při jiném to je také stejné).
Může někdo poradit kde je chyba?
Frameserver musíš mít funkční. Potíž je, že jeho autor vydal poslední verzi v době, kdy byl aktuální Vegas Pro 13. Pro to aby byl frameserver funkční i v novějších Vegasech od Magixu, je potřeba do složky s Vegasem Pro (defaultně "c:\Program Files\VEGAS\VEGAS Pro 14.0") nakopírovat malý soubor s informací o instalaci Frameserveru. Název souboru je "Frameserver.x64.fio2007-config". Pokud máš nainstalovanou i starší verzi Vegas Pro 13, najdeš soubor v jeho složce, pokud ne, stáhni si ho z tohoto odkazu (je v zip archivu)
https://drive.google.com/file/d/1K3PGK5tv2Pbn3D21neSOI2PlFkJW-m1F/view?usp=sharing
https://drive.google.com/file/d/1K3PGK5tv2Pbn3D21neSOI2PlFkJW-m1F/view?usp=sharing
Nebudu začínat nové téma tak to připlácnu sem.
Koupil jsem novej počítač a zjistil jsem, že můj Pinnacle 14 nějak nechce využívat možnosti mého Della.
Proto jsem po 15 letech přešel jinam, konkrétně Vegas PRO 14.
Je to mnohem svižnější ale nevím jak donutit program aby lépe využil moje železo.
Dal jsem na zkoušku vyrenderovat projekt do AVCHD aby se trochu zapotil a procesor jde na 50-55%, tak nevím jak ho přinutit makat navíc.
SSD disk kde je program nainstalován ten jede na 0-1% a RAM do 20%.
díky, možná debilní dotaz, nevím, dělám s tím tři dny.
EDIT: když mám na oe dvě videa a každý v jiným formátu tak už jede procesor při přehrávání na 100%
Koupil jsem novej počítač a zjistil jsem, že můj Pinnacle 14 nějak nechce využívat možnosti mého Della.
Proto jsem po 15 letech přešel jinam, konkrétně Vegas PRO 14.
Je to mnohem svižnější ale nevím jak donutit program aby lépe využil moje železo.
Dal jsem na zkoušku vyrenderovat projekt do AVCHD aby se trochu zapotil a procesor jde na 50-55%, tak nevím jak ho přinutit makat navíc.
SSD disk kde je program nainstalován ten jede na 0-1% a RAM do 20%.
díky, možná debilní dotaz, nevím, dělám s tím tři dny.
EDIT: když mám na oe dvě videa a každý v jiným formátu tak už jede procesor při přehrávání na 100%
Atari11:
Asi uz jsi na to prisel, je to takove nelogicke , pokud se to dela poprve, melo by se to zduraznovat vice,
ten debugmode frame server se rozjede a nic se nedeje. Akorat se vytvori virtualni AVI a nic vic. Pak jen zalezi na uzivateli kam ten AVI nacte a co s tim. Vetsinou se to nacita do Avisynthu a az ten skript pak do nejakeho enkoderu, vetsinou tedy neceho co pouziva x264 enkoder.
Virtualdub je privetivy, je udelany na VFW AVI, tak to nacte, ma tam spoustu filtru. Ale pozor na barevny prostor. VirtualDub myslim pracuje jen s Rec 601 i kdyz mas HD video. Ne Rec 709.
A pak druha vec, z Vegasu to jede ven (velmi ravdepodobne, zavisi to na typu videa, videa z camcorderu ano) vzdy jako 16-235. Pokud to neosetris, mas to video ve vysledku takove zasedle, mdle. Tedy musis aplikovat nejaky filter, ktery to hned napravi. Nevim co tam VD na to ma (nebo nema). Dneska uz existuje VirtualDub FilterMod, ktery exportuje H.264, tedy MP4 nebo MKV. Jinak je snad stejny jako VirtualDub, tak se na to podivej. V Avisynthu musis vetsinou tedy prevest RGB zpet na YUV a upravit ty barvy na full range:
ConvertToYV12(interlaced=true, matrix="PC.709") #frame server exportuje prokladane RGB32 z Vegasu
ConvertToYV12(matrix="PC.709") #frame server exportuje progresivni, neprokladane video, RGB32 z Vegasu
Tedy pred exportem z Vegasu bys mel radeji aplikovat na vsechna videa (na cely track nebo bus track)Sony levels "Studio RGB to Computer RGB" efekt , a pak nedavat ten "matrix" parametr v avisynthu (full range korekci), a tim to vyresit primo uz ve Vegasu. To je prave to, ze Vegas provadi sve pikle na timeline , kde si to prevede na to StudioRGB sam ve vetsine pripadu u videi , ktere pochazeji z nasich kamer. Ale zase tam nactes nejaky lossless a pristupuje k tomu jinak. To si musi kazdy hlidat.
frame server exportuje vlastnosti projektu, pozor na to, ne klipu, tedy ty vlastnosti projektu a klipu by mely byt totozne
Asi uz jsi na to prisel, je to takove nelogicke , pokud se to dela poprve, melo by se to zduraznovat vice,
ten debugmode frame server se rozjede a nic se nedeje. Akorat se vytvori virtualni AVI a nic vic. Pak jen zalezi na uzivateli kam ten AVI nacte a co s tim. Vetsinou se to nacita do Avisynthu a az ten skript pak do nejakeho enkoderu, vetsinou tedy neceho co pouziva x264 enkoder.
Virtualdub je privetivy, je udelany na VFW AVI, tak to nacte, ma tam spoustu filtru. Ale pozor na barevny prostor. VirtualDub myslim pracuje jen s Rec 601 i kdyz mas HD video. Ne Rec 709.
A pak druha vec, z Vegasu to jede ven (velmi ravdepodobne, zavisi to na typu videa, videa z camcorderu ano) vzdy jako 16-235. Pokud to neosetris, mas to video ve vysledku takove zasedle, mdle. Tedy musis aplikovat nejaky filter, ktery to hned napravi. Nevim co tam VD na to ma (nebo nema). Dneska uz existuje VirtualDub FilterMod, ktery exportuje H.264, tedy MP4 nebo MKV. Jinak je snad stejny jako VirtualDub, tak se na to podivej. V Avisynthu musis vetsinou tedy prevest RGB zpet na YUV a upravit ty barvy na full range:
ConvertToYV12(interlaced=true, matrix="PC.709") #frame server exportuje prokladane RGB32 z Vegasu
ConvertToYV12(matrix="PC.709") #frame server exportuje progresivni, neprokladane video, RGB32 z Vegasu
Tedy pred exportem z Vegasu bys mel radeji aplikovat na vsechna videa (na cely track nebo bus track)Sony levels "Studio RGB to Computer RGB" efekt , a pak nedavat ten "matrix" parametr v avisynthu (full range korekci), a tim to vyresit primo uz ve Vegasu. To je prave to, ze Vegas provadi sve pikle na timeline , kde si to prevede na to StudioRGB sam ve vetsine pripadu u videi , ktere pochazeji z nasich kamer. Ale zase tam nactes nejaky lossless a pristupuje k tomu jinak. To si musi kazdy hlidat.
frame server exportuje vlastnosti projektu, pozor na to, ne klipu, tedy ty vlastnosti projektu a klipu by mely byt totozne
AI díky moc za reakci.
Na ten frame server jak funguje už jsem přišel.
Jsem začátečník a se Sony Vegas začínám.
Co znamená že z Vegasu to jede 16-235?
Tak jestli jsem Tě správně pochopil, tak ve Vegas v „Preferences“ na kartě „Preview Device“ zaškrtnu „Adjust levels from studio RGB to computer RGB“ a tím Vegas celý projekt upraví na RGB, a po exportu přes frame server to skriptem Avisynthu převedu zpět na YUV. Je to tak?
A kameru mám Panasonic a soubory z toho jsou mts.
Na ten frame server jak funguje už jsem přišel.
Jsem začátečník a se Sony Vegas začínám.
Co znamená že z Vegasu to jede 16-235?
Tak jestli jsem Tě správně pochopil, tak ve Vegas v „Preferences“ na kartě „Preview Device“ zaškrtnu „Adjust levels from studio RGB to computer RGB“ a tím Vegas celý projekt upraví na RGB, a po exportu přes frame server to skriptem Avisynthu převedu zpět na YUV. Je to tak?
A kameru mám Panasonic a soubory z toho jsou mts.
Tak to není, nastavení v "Preview Device" slouží pro korekce na monitoru pro Preview, ale na rendering to nemá vliv. Pokud bys chtěl, aby celý projekt byl ve Vegasu zpracováván v rgb 0-255, dá se v Properties nastavit Pixel format na 32-bit floating point (full range), ale osobně si nemyslím, že je to nejlepší řešení. On je v tom barevném prostoru obecně mezi uživateli trochu zmatek. Jak už psal ai, Vegas v 8-bitovém režimu převádí videa běžných formátů s barevným prostorem YUV do RGB rozsahu 16-235 a při renderingu do stejných formátů je převádí zase naopak. Debugmode Frameserver má výstup v RGB stejný jak je v to projektu, proto je potřeba při konverzi do modelu YV12 převést jas a barvy do standardu PC.709.
Já nastavuji v Properties Pixel Format na 32-bit fl.point (video levels), což je barevně a jasově stejné jako 8-bitový formát, jen se efekty zpracovávají v 32-bitové aritmetice. Pokud použiju materiál, který Vegas nepřevádí do 16-235, jako například fotky, nastavím jim filtr Levels - Computer RGB to Studio RGB, abych dosáhl stejných úrovní jako má celý projekt. Při renderu přes Frameserver přidávám do Avisynth skriptu příkaz ConvertToYV12(matrix="PC.709").
Já nastavuji v Properties Pixel Format na 32-bit fl.point (video levels), což je barevně a jasově stejné jako 8-bitový formát, jen se efekty zpracovávají v 32-bitové aritmetice. Pokud použiju materiál, který Vegas nepřevádí do 16-235, jako například fotky, nastavím jim filtr Levels - Computer RGB to Studio RGB, abych dosáhl stejných úrovní jako má celý projekt. Při renderu přes Frameserver přidávám do Avisynth skriptu příkaz ConvertToYV12(matrix="PC.709").
