En osaa h264:n algoritmin osalta varmaksi sanoa, mutta rinnakkaislaskennassa ei ole kyse siitä, onko algoritmi tarpeeksi fiksu jakamaan pienempiin osiin, vaan jos tehtävä on tarpeeksi pieni, sitä ei kannata enää rinnakkaistaa, koska tehtävän koordinointi maksaa enemmän kuin lisäteho, mitä saadaan ytimistä. 1920x64 kuulostaa aika vähäiseltä työmäärältä suhteessa säikeen hallintaan (huom. CPU-puolella, ei FPGA/DSP/CUDA). Toinen on se, että jos halutaan maksimoida throughput, silloin aikataulutuksen latenssi voi kasvaa ja tehtävien pitää olla entistä isompia. Jos h264-videota pitää saada enkoodattua nopeammin niin etsisin ratkaisua custom-raudasta. Jos taas on iso pino videoita renderöitäväksi, niin niitä voi yhä ajaa useampia rinnan. Esim. jos yhden videon koodaus ei hyödy yli 16 coresta, 32 coren koneella pystytään vielä käyttämään tehoja hyvin kahta videota samaan aikaan prosessoitaessa.
Mielellään kuulisi videoita harrastavilta, mitkä ovat ne todelliset vaatimukset, joita videon enkoodausnopeudella on. Siis liiketaloudelliset tiukat deadlinet työn valmistumiselle. Ja toisaalta kotikäyttäjillä, paljonko 3960x:n tai 3970:n tapauksessa jää puuttumaan tehoja, että tekee mieli jo taitella köydestä hirttosilmukkaa tai potkia nauloja kynsien alle. Varmasti silläkin on jokin kvantitatiivisesti määritettävä raja, koska CPU toimii riittävän nopeasti ettei tarvi harkita harakiria.