Převod MP4 na JPG sekvence (nebo datové pole) co nejrychleji

[YourDog]

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++.

[Reklama]

[_Jenda]

Kód: [Vybrat]

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.

[PanVP]

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

PS: Dobře ty! Tohle se mi totiž shodou okolností dost hodí.

[_Jenda]

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)).

[YourDog]

Kód: [Vybrat]

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 takže python to přes stdout pochytá a udělá pole, to jsem vůbec neznal tohle. Jdu zkusit. Dík

[Reklama]

[_Jenda]

koukám že to plive rovnou do konzole jako byty v ASCI 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í.

[YourDog]

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

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.

[PanVP]

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.)

[YourDog]

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/

[YourDog]

smazano duplicitní příspěvek

[YourDog]

koukám že to plive rovnou do konzole jako byty v ASCI 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

[RDa]

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.

[_Jenda]

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.

[PanVP]

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

[PanVP]

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.