Citace Původně odeslal Caleb Zobrazit příspěvek
A ze budes mit uprostred lupanec (v dusledku nedelitelnosti frame) to ti moc nevadi, ze? A to ze ti samotne rozdelovani a spojovani zabere vice casu nez kdyby si to enkodoval na SC (neni mi znam zadny nastroj ktery by tuto cinnost automatizoval) ti take nevadi?
Jiste existuje DC-optimalizovany Lame (s horsi kvalitou nez SC), muzes enkodovat vice WAVu najednou, ale tebou popsany postup je imho nesmyslny. Nebo si to snad zkousel?
Praveze lupanec tam nebude, pretoze sa vytvori novy frame a to je tiez dovod, preco bude vysledny subor trocha vacsi. Rozdelovanie a spajanie ak mi ma zabrat vela castu v porovnani s enkodingom znamena, ze enkodujem kratke skladby - ak su to napr. pesnicky albumu, mozem ich enkodovat paralelne, ak je to jedna dlha hodinova skladba, tak potom mi delenie a spajanie prinesie usporu.

(tento link sem dal eagle) http://forum.doom9.org/showthread.php?t=115822
Citace Původně odeslal omion

Quote:
Originally Posted by emmel
Yes. But why not simply split the file in N-parts, and trivially distribute them over N-cores? And finally join the results. That would scale exactly linearly, or does it? Of course, if N is big, exact load balancing may be problematic (one thread could run much longer than the others). But anyways.

I actually made a program that could do that with x264, but it's not quite linear. I got something like 1.95x with 2 processors (although it's been a while since I've used it, so that number may be way off).

The main problem with many processors is with the splitting. There's no easy way to determine where x264 will put an I frames without analyzing each frame, so chances are the split point will be in the middle of a scene. For consistant quality, you need to re-render that scene. Obviously, this will not scale well if your number of processors is greater than the number of scenes in your movie.

I minimized the load-balancing problem by splitting to more parts than cores, then having each core "check out" the next split part. This, of course, increased the number of split frames and therefore the number of re-encoded scenes.

I think the reason that my setup didn't scale perfectly had to do with disk accesses. Two programs were reading and writing in two separate places on the same hard disk.

But as I said, it's been a while since I used that program to encode anything, and it was in the super-pre-alpha stage, so it may be a problem with my optimizations.
Teda, nie neviem o programe ktory by to robil automatizovane, ani som ho nerobil, ale vravim ze to nebude zlozite a ze tento program bude robit:
1. rozdeli neenkodovany subor na dva casti
2. pusti paralelne enkodovanie oboch casti
3. pospaja vysledne subory (a to sice tak, ze z nich povyhadzuje hlavicky a vezme iba data)
4. vytvori novu hlavicku kde nastavi spravne informacie o dlzke atd.
Tuto novu hlavicku moze vytvorit modifikovanim hlavicky 1. vysledneho mp3 suboru kde zmeni informacie na skutocne po pospajani odpovedajuce.

V bode 2 predpokladam enkodovanie s rovnakymi nastaveniami enkodera.