Fórum Root.cz
Hlavní témata => Software => Téma založeno: YourDog 27. 08. 2021, 21:40:29
-
Potřebuju procházet terabajty videí a převádět na obrázky kvůli zpracování obrazu. Ty pozdější operace jsou vcelku rychlé, ale bottleneck je ten samotný převod z MP4 na obrázek, který ted provádím přes ffmpeg. Ten zvládá i enkodování a dekodování přes GPU, ale myslím že to že z toho dělám obrázky asi na GPU běžet nemůže.
Zkoušel jsem i OpenCV ale to je 4x pomalejší a možná kdyby se to podařilo multithreadovat tak to pobeží maximálně stejně rychle.
Tak jsem se chtěl zeptat, zda někdo neznáte nějaký rychlejší zpusob než ffmpeg, nebo jestli je ten software tak efektivní že už je limit jen muj HW? Ale ffmpeg touto operací vytežuje jen CPU, tak třeba existuje něco pro GPU. Prakticky to ani nemusím ukládat na disk, to zpracování může probíhat současně pokud z toho nějak udělám pole. Pracuju v Pythonu a nebo můžu C# a v nouzi C++.
-
ffmpeg -i test.mp4 -pix_fmt rgb24 -f rawvideo -y -Plive to rovnou RGB framy.
Na mém i5-8265U @ 1.60GHz to spustí 4 thready a dekóduje fullhd H.264 video rychlostí 250 FPS, takže na lepším stroji (tohle je low-power notebook) by ses měl dostat na 1000 FPS minimálně. Stačí to nebo je potřeba řešit bottlenecky? To je hlavně:
- dekodér. ffmpeg má podporu HW dekodérů
- konverze z yuv420 na RGB. To trvá podle zvolené interpolace. Buď můžeš zkusit nějakou rychlejší méně kvalitní, nebo to taky půjde offloadovat.
Navíc je to stock ffmpeg z Debianu, nevím, jestli používá AVX2 i pro dekódování. Skoro bych řekl že ne.
Mezikrok přes JPG je nesmysl, jeho enkódování a dekódování sežere nejspíš víc než dekódování videa.
-
Mezikrok přes JPG je nesmysl, jeho enkódování a dekódování sežere nejspíš víc než dekódování videa.
...a asi to i vnáší cca 10-20% šumu... ne?
Výstup sypat někam na ramdisk, tenhle provoz by asi spolehlivě vydojil i enterprasové SSD :o
PS: Dobře ty! Tohle se mi totiž shodou okolností dost hodí.
-
Je to zkopírované z https://www.abclinuxu.cz/blog/jenda/2021/4/jednoduche-formaty-souboru-netpbm-dot-pcap (čtete
biblimůj blog, tam to všechno je)
Tazatel chtěl pole, já bych to četl rovnou ze stdout toho procesu (v pythonu:
p = subprocess.Popen("ffmpeg ...", shell=True, stdout=subprocess.PIPE); while True: frame = p.stdout.read(1920*1080*3)).
-
ffmpeg -i test.mp4 -pix_fmt rgb24 -f rawvideo -y -Plive to rovnou RGB framy.
koukám že to plive rovnou do konzole jako byty v ASCI :D takže python to přes stdout pochytá a udělá pole, to jsem vůbec neznal tohle. Jdu zkusit. Dík
-
koukám že to plive rovnou do konzole jako byty v ASCI :D takže python to přes stdout pochytá a udělá pole, to jsem vůbec neznal tohle.
Ano, takhle UNIX funguje. Bohužel to poslední dobou lidé zapomínají/nevědí a tahle krása se pak vytrácí.
-
Mezikrok přes JPG je nesmysl, jeho enkódování a dekódování sežere nejspíš víc než dekódování videa.
...a asi to i vnáší cca 10-20% šumu... ne?
Výstup sypat někam na ramdisk, tenhle provoz by asi spolehlivě vydojil i enterprasové SSD :o
PS: Dobře ty! Tohle se mi totiž shodou okolností dost hodí.
ty JPG by nevadily že budou lehce horší, klidně bych mohl zmenšit i rozlišení. V tyhle fazi to má vyházet stejný nebo velmi podobný obrázky a nechat jen ty co se liší. Aby se pak to náročnejší zpracování dělalo jen tam kde je to potřeba.
-
Náhodou, kluci, umí nějaké (laciné) kamery posílat surový (nekomprimovaný) stream z kamery? USB3.0 už by nemuselo být úzké hrdlo ne? Jsou UHD 4K kamery, ale mně by stačilo i míň než FHD. ::) Mám aplikaci hrozně citlivou na artefakty spojené s kompresí a nevím, co s tím. Zatím to mám v šuplíku.
(Drahé, průmyslové, kamery umí zpracovávat obraz přímo v sobě, ano.)
-
Náhodou, kluci, umí nějaké (laciné) kamery posílat surový (nekomprimovaný) stream z kamery? USB3.0 už by nemuselo být úzké hrdlo ne? Jsou UHD 4K kamery, ale mně by stačilo i míň než FHD. ::) Mám aplikaci hrozně citlivou na artefakty spojené s kompresí a nevím, co s tím. Zatím to mám v šuplíku.
(Drahé, průmyslové, kamery umí zpracovávat obraz přímo v sobě, ano.)
Tak spousta kamer posílá ven live nekomprimovaný obraz bez artefaktů, Panaosnic GH5 a nebo Blackmagic kamery z těch "levnějších" ale to je vždy po HDMI, případne SDI, na USB se to nepřevádí, ale existujou různý převodníky, ale tam to bude trpět tim ukládáním na konci... to se pak používá Prores kterej je pomalej. Jinak nejsem si jisty ale Raspberry Pi kamera umí RAW ale možná jen fotky u videa nevím... a tam jsou Sony IMX senzory, ty mají kvalitní obraz. A Canon fotaky se dají hacknout že točí RAW do Cinema DNG ale to je offline po snímcích, to se jmenuje magic lantern.
https://www.strollswithmydog.com/open-raspberry-pi-high-quality-camera-raw/
-
smazano duplicitní příspěvek
-
koukám že to plive rovnou do konzole jako byty v ASCI :D takže python to přes stdout pochytá a udělá pole, to jsem vůbec neznal tohle.
Ano, takhle UNIX funguje. Bohužel to poslední dobou lidé zapomínají/nevědí a tahle krása se pak vytrácí.
Tak otestováno i7-5930k (cca 2x rychlejší než ten notebook)
ukládání do JPG na disk jede SD 20x (480 FPS) a HD 5-8x (120-190 FPS), což jen ten základ, co jsem chtěl zrychlit..
ten příkaz s RAW a -pix_fmt rgb24 jede víceméně přesně 1,5x rychleji
bez toho pix_fmt to jede 4x rychleji tj SD skoro 2000 FPS a HD 500FPS ale ještě nevím co je to za data
a pak když to dám do pythonu tak s tím rgb24 to jede stejně jak kdybych ukladal JPG na disk a bez toho to jede jen 2,5x rychleji
Ráno se na to podívám... alespon jsem se posunul dál že vím že to dekoduje i 4x rychleji a ted z toho ty data nějak bez zpomalení pochytat. Diky
-
Náhodou, kluci, umí nějaké (laciné) kamery posílat surový (nekomprimovaný) stream z kamery? USB3.0 už by nemuselo být úzké hrdlo ne? Jsou UHD 4K kamery, ale mně by stačilo i míň než FHD. ::) Mám aplikaci hrozně citlivou na artefakty spojené s kompresí a nevím, co s tím. Zatím to mám v šuplíku.
(Drahé, průmyslové, kamery umí zpracovávat obraz přímo v sobě, ano.)
Tak existuji i levne cinske prumyslove kamery na USB3, ale vysledek je.. trocha marnej :)
Pokud az moc tlacis na cenu, tak si porid nejake SBC ktery ma dedikovany kamerovy port a nejaky kamerovy modulek - a zachytavat RAW budes moct. Tohle ale nebude mit mozna vykon na tvuj processing.
-
bez toho pix_fmt to jede 4x rychleji tj SD skoro 2000 FPS a HD 500FPS ale ještě nevím co je to za data
Data jsou ve formátu, který ti to vypíše. Téměř určitě to bude yuv420p. yuv znamená, že to jsou tři obrázky - jas a dvě rozdílové barevné složky. 420 znamená, že barevné složky mají čtvrtinové rozlišení (ve smyslu 0.5*0.5) oproti jasové. A p znamená, že je to tahle po sobě (planar), pak je ještě packed, to by byly proložené v tom stejně jako když máš standardní RGB obrázek.
-
Kdyby to někoho zajímalo:
Sony IMX377 - 4032 x 3024, 12.19 MPx
https://www.aliexpress.com/item/1005002899255017.html
Sony IMX335 - 259 2x 1944, 5 MPx
https://www.aliexpress.com/item/4000689715911.html
Sony IMX290 - FHD, 2 MPx (low light a vysoké FPS - až 120)
https://www.aliexpress.com/item/1005003187704063.html
https://www.aliexpress.com/item/4001241985121.html
SONY IMX179 - 3288 x 2512, 8 MPx (používaná i pro RPi)
https://www.aliexpress.com/item/4000510421682.html
YUV2 (YUYV) umí při 1024X768@ 30fps
Bohužel, dostat nekomprimovaný stream přes USB do pecka...třeba ve FHD...za rozumné peníze (řekněme do 1500 Kč) ...to je výzva.
Tohle jsem nezkoušel, je to už dražší, než potřebuji:
https://www.aliexpress.com/item/1005003163104150.html
Ale ty FPS jsou zajímavé: 640x480@180fps/180fps
-
Dělal jsem testy a YUV2 (YUYV) mi fungovalo, resp. pokud jsem snímal podklad (řekněme objekt), bylo možné vrstvit snímky na sebe a "pasovaly". U Mpegu ne...občas ano a občas ne.
Jestli to chápu správně, tak formát YUV2 (YUYV) může i nemusí být komprimovaný. Co jsem měl na pokusy dávalo nekomprimovaný výstup.
Co dávají tyto kamery nevím.
Abych to mohl vyndat ze šuplíku, potřeboval bych 1280×960 nebo klidně 1280×720 a 30 FPS při nekomprimovaném výstupu (na vrstvení)...
Ad co to melu o vrstvení: Pokud mi části obrazu pasují na sebe, tak je nezpracovávám. Pokud tam mám šum, tak to neutáhne CPU.
-
Bohužel, dostat nekomprimovaný stream přes USB do pecka...třeba ve FHD...za rozumné peníze (řekněme do 1500 Kč) ...to je výzva.
Porid si HDMI-USB3 prevodnik, ty na FHD nejsou drahe. A FHD kameru s HDMI ti zastoupi jakykoliv suplikovej/bazarovej handycam nebo fotacek. Pokud jde o nizkou cenu, tak to bude nejaky bastl, ale pocitej, ze na tom prodelas pokud by sis mel zapocist svuj promarneny cas.
Pokud vyzadujes nezasumeny obraz, tak to chce svitit, svitit, svitit. Nebo pouzit velikej a drahej snimac, v jeste drazsi kamere.
-
Ty laciné redukce...přemýšlím, jestli to bude mít rozumné API...
Co použít něco jako tohle? (Pokud bych se dostal za fázi hrubého prototypu...)
https://www.avermedia.com/professional/product/ce314_hn/spec
Avermedia často mají solidní API......ve srovnání s nejčínovatější Čínou...
-
Porid si HDMI-USB3 prevodnik, ty na FHD nejsou drahe.
Taky jsem mu to chtěl navrhnout, ale myslel jsem, že ty levné posílají MJPEG a možná snižujou framerate.
-
Porid si HDMI-USB3 prevodnik, ty na FHD nejsou drahe.
Taky jsem mu to chtěl navrhnout, ale myslel jsem, že ty levné posílají MJPEG a možná snižujou framerate.
Ano - ty ultra lacine jsou takove, ale muze za to USB2, protoze 10080p30 @ 422/8bit je 124 MB/s a to se musi nejak redukovat. Pro USB3 model by tohle melo projit bez komprese. Take neni treba hledat "4K podporu", spis aby to bylo hlavne USB3.
-
Ty laciné redukce...přemýšlím, jestli to bude mít rozumné API...
Co použít něco jako tohle? (Pokud bych se dostal za fázi hrubého prototypu...)
https://www.avermedia.com/professional/product/ce314_hn/spec
Avermedia často mají solidní API......ve srovnání s nejčínovatější Čínou...
PCIe karty budou mit bud nejake custom SDK (blackmagic, deltacast) a pripadne adaptacni vrstvu na klasicke WDM video pro Win.
Ty levne karty budou mit jenom WDM. S V4L2 to je relativne marny v komercnich consumer produktech.
U USB budes mit na 90% nativni UVC video, tj. bezdriverove reseni, nektere slozitejsi vyrobky pak maji vlastni drivery a api (blackmagic ultrastudio usb3 / intensity shuttle).
-
U USB budes mit na 90% nativni UVC video, tj. bezdriverove reseni
Díky! Otestuji!
-
ffmpeg se neustále vyvíjí, jednu dobu quicksync nefungoval dobře, jednou mu byl potřeba dáva nějaké zvláštní identifikátory kodeku, a nefungovaly ani quicksync filtry (na akcelerované zmenšování rozlišení a klasický -vf scale softwarový celý proces pětkrát zpomalil)
Já jsme tedy řešil trochu jiný problém (bottleneck byl encoding, decoding mě netrápil)
zde přikládám recept
ffmpeg -hwaccel qsv -vcodec h264_qsv -i in -c:v h264_qsv -global_quality:v 28 -v verbose . Možná tam by mohl být ještě nějaký pix_fmt, protože to funguje jen pro 420p.
Ale můj use case je jiný, já to neposílám do jiné aplikace, ale zapisuju jako finálni video na disk