slowmoVideo

Byl uveřejněn nový open-source editor videa slowmoVideo, jehož hlavní devizou je změna rychlosti videa, a to včetně přehrávání pozpátku. Oproti pouhé změně snímkové rychlosti slowmoVideo produkuje video, které je plynulé. K dispozici jsou i ukázky. slowmoVideo využívá grafickou kartu k dopočítání snímků.

27.8.2011 16:32 | stativ | Zajímavý software

Komentáře

[BeryCZ]

Sakra to vypadá velice dobře

[Dreit]

Neškodilo by dodat, že:

GPU-KLT+FLOW requires an nVidia card.

[kralyk z abclinuxu]

FFFFUUUUU :-/

[stepulka]

Jo, proto jsem si radeji poridil gts450ku :P

[Dreit]

Mám svoji první grafiku co netopí a už je to špatně :D Ale jestli to běží přes "ssh -X ..." tak jsem za vodou :P

[AsciiWolf]

Mohu vědět, co máš za grafiku, že netopí?

Jako jediná možná varianta mne napadá Intel, nicméně u těchto karet je logické, že netopí, jelikož mají výkon jako Nvidia z roku 2002 (mám v laptopu Intel i950 a seká se mi občas i Quake 3).

[Dreit]

Radeon 4200 na desce, frekvence z 500 zvednutá na snad 650.

Netopí = pasiv kde při sledování filmu udržím packu Na grafice co jsem měl dřív (nVidia) jsem jednou nechtěně (opravdu!) odpojil větrák, po třech minutách byla na 72°C a lezla rychle nahoru..

[stativ]

No, třeba moje nVidia 9600GT má pasiv, podle sensorů má 40°C a podle ruky je jen vlažná.

[pic]

kdysi to umělo i kdenlive

[bhy]

a proč už to neumí?

[marek_hb]

to nevím - myslím, že to má něco společného s MLT - někde kolem verze 5 fungoval efekt revese video dobře. pak nefungoval a ted ani není v nabídce

[stativ]

Aha, ale umělo kdenlive takovéhle plynulé změny rychlosti?

[Mandarinka]

Kdo nemá nvidii nebo si třeba chce víc pohrát, nechť zkusí avisynth (pod wine, samozřejmě, a pro jistotu berte stabilní v2.5) s pluginem mvtools2. Analýza pohybu, interpolace snímků a změna framerate je jedna z věcí, co to dokáže (viz readme).

[Mandarinka]

P.S. Ale imho tohle interpolování snímků je poměrně humus, vypadá to hnusně a jediné, k čemu je to dobré, je když chcete přidat kompenzaci pohybu do nějakého temporálního filtru (přičemž tyto nové snímky jsou toliko pomocné a po filtrování jsou zahozeny, naštěstí). Čertví, jaká je ta kvalita řešení ze zprávičky, když to ještě musí běžet na CUDA...

[cezz]

Mas na stranke projektu ukazkove videa, IMHO je ta kvalita uzasna.

[dustin]

Právě kvůli CUDA bych čekal, že kvalita bude výborná.

[Mandarinka]

Právě kvůli CUDA bych čekal, že kvalita bude výborná.

Protože pro CUDA se dobře programuje a ti nejlepší experti na video se to zároveň naučili? Haha.

[dustin]

Ne, protože je na takové výpočty GPU primárně konstruované a vývojář si může dovolit algoritmy, které by CPU nestíhalo.

[cezz]

Ak som spravne cital na strankach projektu, ono to video nerobi realtime, tak mi nejak nie je jasne, co by CPU "nestihalo".

[Mandarinka]

Je však třeba připustit, že v tomhle případě by GPGPU mělo být uplatnitelné, na rozdíl od třeba kódování videa. Rozdíl je v tom, že v tomto případě děláte jenom motion search a nezajímá vás už efekt na kompresi (což je důvod, proč enkódování na shaderech moc nejde udělat - nemůžete se při hodnocení vektorů podívat na to, kolik bitů bude stát jejich použití).

[stativ]

Třeba protože by to na CPU trvalo strašně dlouho. Ze stejného důvodu má Octane renderer takový úspěch. Není to realtime, ale jako první opravdu kvalitní renderer poskytl možnost běhu na CPU, díky tomu je rychlý a stal se rychle velmi oblíbeným. Naštěstí LuxRender už má podporu OpenCL, takže i v OSS jsou alternativy…

[stativ]

Čertví, jaká je ta kvalita řešení ze zprávičky, když to ještě musí běžet na CUDA...

Zkoušel jsem to a je to fakt jako na ukázkových videích. Tj. skoro neuvěřitelné.

[-]

Chtěl jsem to taky vyzkoušet ale mám problém:

* ffmpeg libraries could not be found. * libswscale could not be found. * slowmoVideo will be built: NO

přitom ffmpeg-devel v repozitářích nemůžu najít

[Jendа]

Nejde spíš o libavcodec-dev a libavformat-dev?

[kralyk z abclinuxu]

A kdes vlastně vyčet, že to běží na CUDA? Já tam akorát našel, že potřebují nVidia kvůli jakési kompresi při přenosu na GPU, třeba to řeší nějak přes shadery...

[kralyk z abclinuxu]

Jo, tak jsem kouknul do zdrojáků, a maj to napsaný v shaderech v Cg. Imho podpora ATi by nebyl problém, kdyby se jim chtělo

[Dreit]

Už aby to bylo

[helb]

Ona to je práce jednoho člověka a ten má evidentně nVidii. Ale třeba se do toho časem někdo pustí…

[marvm]

potrebuje to nvidia-cg-toolkit a nejspis to vyuziva CUDA jadra v grafikach...

[kralyk z abclinuxu]

potrebuje to nvidia-cg-toolkit

Jo, ten ale kompiluje do DirectX nebo OpenGL shaderů, takže to by neměl být problém...

nejspis to vyuziva CUDA jadra v grafikach...

Nic takového neexistuje CUDA je tooltik, nic víc, na GPU jsou jádrem GPGPU stream processory. Ty ale oni nepoužívaj, oni to opravdu počítají přes ty shadery, který jsou unifikovaný.

[sabraq]

No, takže jste to domotal ještě více. Někde/někdy se lze dočíst označení stream procesorů jako "CUDA cores" (např. v gui utilitě nvidia-settings), zkratka GPGPU je potom využití GPU na počítání něčeho jiného, než je grafika, nebo fyzika ve hrách. Takže marvn má pravdu.

potrebuje to nvidia-cg-toolkit

..na GPU jsou jádrem GPGPU stream processory. Ty ale oni nepoužívaj, oni to opravdu počítají přes ty shadery, který jsou unifikovaný.

Jasně, takže "oni" vlastně nepoužívají tu spoustu procesorů v jádře, počítají to přes shadery, který jsou unifikovaný a ty se stream procesory/CUDA jádry nemají ale vůbec nic společnýho, že?

[kralyk z abclinuxu]

Někde/někdy se lze dočíst označení stream procesorů jako "CUDA cores" (např. v gui utilitě nvidia-settings)

To je pouze marketingové označení - snaží se propagovat svoji technologii. Care-o-Meter: Lo [-|--------] Hi.

zkratka GPGPU je potom využití GPU na počítání něčeho jiného, než je grafika, nebo fyzika ve hrách

Ne. GPGPU je general purpose, což značí vyšší úroveň programovatelnosti (pouze nejnovější shadery). "Fyzika", ať už ve hrách, nebo kdekoli jinde, do toho patří samozřejmě taky.

Jasně, takže "oni" vlastně nepoužívají tu spoustu procesorů v jádře, počítají to přes shadery, který jsou unifikovaný a ty se stream procesory/CUDA jádry nemají ale vůbec nic společnýho, že?

Oni = programátoři gpu-klt+flow, tak jsem to myslel.

Co se týče těch jader: jestli jsou nebo nejsou fyzicky na konkrétních grafikách tvořeny stejným HW a jestli si to ovladače přeloží tak, nebo onak je v této debatě naprosto irelevantní, protože podstatný na tom je způsob přístupu k nim. Přístup přes OpenGL shadery není to samý jako přístup přes GPGPU API jako třeba CUDA nebo OpenCL.

To je totiž taky důvod, proč GPU-KLT+FLOW podporuje i starší grafiky, už od GeForce 6 - tato grafárna rozhodně žádný "CUDA cores" nemá, protože tehdy ještě ani CUDA neexistovala!

A o to mi právě šlo v týhle debatě, protože od způsobu, jakým ke GPU oni přistupují se totiž pak odvíjí otázka portování na jiný grafický karty než nVidia.

[sabraq]

Jistě, pojem CUDA je mezi námi od GeForce 8xxx, takže by se s geforce 6xxx nedalo o CUDA hovořit. Sice píše, že knihovny zahrnují i CUDA, ale v případě starší karty bude tato technologie nejspíš mimo hru...

[SAM:]

Moc pěkné.

[sabraq]

Fakt pěkný...