Ty vidis svuj problem v potrebe nakupu CPU, ja vidim ze CPU ani nepotrebujes, jestli je ukol JENOM dekodovani. Proto se ptam - co s tim chces jako delat pak ?
Tak předně dodávám že tohle je můj side projekt abych se naučil víc kolem všeho co k tomu využiju.
Prakticky potřebuju ze vstupního videa udělat framy kde je porovnám mezi sebou, na což by mi stačilo je mít v rozlišení 8x8 nebo 16x16 grayscale, což i samotné převedení dost urychluje a nejspíš potvrzuje co píšeš. Pak promažu ty kde se nic nehýbe porovnáním těch zmenšenin, aby z každé takové situace zůstal jen jeden frame. To mi třeba počet 150k framů zmenší na 10-30k, což bude pokaždé jinak. Jenže pak ty zbylé chci zase ve větším rozlišení kde na ně budu aplikovat nějake operace, které už by měly bežet na GPU. Takže je vlastně otázka jestli to tím prohnat 2x, protože někdy to zmenšování na 8x8 jelo i 1500-3000 FPS, ale HD jede tak 500 max at z nich dělám 8x8 nebo 640x360... pak si udělat list jen toho co nechávám a vyzobat to zvlášt ve větším rozlišení. A nebo to vše převést najednou a promazat.
třeba by to šlo nějak chytřeji porovnat abych se vyvaroval zbytečnému zmenšování a převádění všeho když ve finale potřebuju 10-15% originalu.
Konecne se nekam dostavame:
1/
pokud jde o detekci rozdilu z komprimovane streamu (h264/h265) tak bych na to sel analyzou enkodovaneho streamu - protoze tyhle kodeky koduji keyframe + rozdilove snimky, a kdyz zadnej rozdil nebude, bitrate poklesne.
Jako neni to vsespasne - protoze kodek samozrejme povazuje za mezisnimkovy rozdil i sum v obraze. A s nim si tvuj algoritmus bude muset taky poradit, necekal bych ze na statickem obraze bude rozdil pixelu nula
V tomto smeru se nabizi jeste vyuziti hw enkoderu v roli "detektoru pohybu", protoze kodeky delaj presne tohle.
2/
Kdyby to video bylo i-frame only (napr. mjpeg stream), tak lze dekodovat jen DC slozku, tim se dostane 8x mensi obrazek (12.5% v kazde ose), tj. z FHD zbude jen 240x135 px - ale bude to >100x rychlejsi. Pokud je treba vetsi rozliseni, slo by rozbalit i AC a spocitat jen prvni nizkofrekvenci koeficienty. Pro bezne kodeky ale tohle moc nebude fungovat, tam se ocekava kodovani rozdilu vuci obrazu v plnem rozliseni.
3/
v pripade ze to musis dekodovat cely a pocitat rozdily svym zpusobem, abys treba sledoval tendenci, tak je idealni si sestavit tento tok: gpu decode (nvdec) + on-gpu scale + "svuj algoritmus (CUDA)". Zde opravdu nevyuzijes cpu ani trocha, neprijde mi to jako tak slozita uloha, aby to muselo bezet na cpu.
Pokud jede cpu na 100% behem hw/gpu akcelerace, tak je neco spatne (nejspis to dela to skalovani/konverzi formatu, ktere ale maji nekdy svoji GPU variantu, takze bych se zameril timto smerem).