Vyznam dual core

[Caleb]

nepravda. mp3 skodujem bez straty kvality 2x efektivnejsie na DC - staci skladbu rozdelit na 2 casti. Je ale pravda ze na DC bude vysledny subor asi o promile vacsi.
DivX/Xvid skodujem bez straty kvality 2x efektivnejsie na DC - staci video rozdelit na 2 casti.

OMG, kolikrat se to tu resilo - jak psal Pit, doporucuji ti si opravdu precist tento thread (pripadne nam ukazat jak rozdelujes a pak spojujes MP3)

[THX]

OMG, kolikrat se to tu resilo - jak psal Pit, doporucuji ti si opravdu precist tento thread (pripadne nam ukazat jak rozdelujes a pak spojujes MP3)

ha, to bolo popisane v jednom linku ktory tu tusim dal eagle ako priklad ze sa to neda

Ako to teda rozdelim? Nezkodovany subor bez problemov rozdelim na dve casti. Ako spojim mp3ku? Jednoducho spojim dva skodovane mp3 zasebou a upravim hlavicku. A ak by som bol drsnak, tak ani neupravim tu hlavicku a pojde to prehrat, akurat nebude to asi ukazovat spravnu dlzku a niektore playere s tym mozu mat rozne mensie problemy.

[Caleb]

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?

[THX]

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

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.

[Caleb]

Praveze lupanec tam nebude, pretoze sa vytvori novy frame a to je tiez dovod, preco bude vysledny subor trocha vacsi.

Muzes nejak dokazat, ze to lze? Pomoci kterych nastroju by si to vytvoril (tj. nastaveni enkoderu Lame aby nevytvarel na zacatku a konci MP3ky mezery) a pomoci ceho by si to spojoval? To ze je neco teoreticky mozne (coz ale imho neni tento pripad) neznamena ze to je prakticky realizovatelne (se softwarovymi nastroji ktere jsou k dispozici). Mam neustale pocit, ze varis z vody - nebo si snad myslis ze vyvojari Multi-threading LAME sou tak hloupi, ze by neprisli na to, ze (podle tebe) staci vstupni soubor rozsekat na kousicky, paralelne enkodovat a pak pospojovat a misto toho resi nejakou DC optimalizovanou verzi co enkoduje stejne sekvencne. Chci dukaz misto slibu

[THX]

Muzes nejak dokazat, ze to lze? Pomoci kterych nastroju by si to vytvoril (tj. nastaveni enkoderu Lame aby nevytvarel na zacatku a konci MP3ky mezery) a pomoci ceho by si to spojoval? To ze je neco teoreticky mozne (coz ale imho neni tento pripad) neznamena ze to je prakticky realizovatelne (se softwarovymi nastroji ktere jsou k dispozici). Mam neustale pocit, ze varis z vody - nebo si snad myslis ze vyvojari Multi-threading LAME sou tak hloupi, ze by neprisli na to, ze (podle tebe) staci vstupni soubor rozsekat na kousicky, paralelne enkodovat a pak pospojovat a misto toho resi nejakou DC optimalizovanou verzi co enkoduje stejne sekvencne. Chci dukaz misto slibu

novy frame tam vznikne, pretoze na zaciatku kazdej jednotlivej casti samozrejme bude novy frame. Ake nastavenia lame pouzit neviem - nepouzivam lame. V podstate si uz ani nepamatam kedy som naposledy enkodoval. Ale predpokladam ze existuje nejake nastavenie lame, ktore do enkodovanej skladby nepridava na zaciatku ani na konci ziadne medzery, fadeouty atd. a ze len enkoduje presne to co dostane nekomprimovane na vstupe.
Mam dojem, ze vyvojari multithreaded lame sa vybrali inou cestou ako delenie suborov a teda tam robia ten multihreading uplne inac (tak, aby mohli spracovat subor sekvencne).
Program ktory by delil skladby a potom ich spajal potrebuje od enkodera v podstate iba vytvorenie frameov. Ak ma lame nejaky option, nech nepridava na zaciatok (ani koniec) id3 tagy, tak by malo stacit appendnut tie dva subory. Potom by to chcelo este k vyslednemu suboru pridat tie id3 tagy...

[Caleb]

Ale predpokladam ze existuje nejake nastavenie lame, ktore do enkodovanej skladby nepridava na zaciatku ani na konci ziadne medzery

A myslim ze u pocitu to zustane - je to problem samotneho navrhu formatu MP3.

bud lupanec v strede alebo v strede znizena/zvysena kvalita => vysledny subor iny

Presne tak, jeden spojovaci frame by kvalitu asi moc neovlivnil, ale pri prechodu na multicore by techto framu bylo v souboru cim dal tim vice a kvalita by byla o necem jinem.
2THX - nejde o to, ze by idea rozdeleni souboru a enkodovani byla spatna, pouze je konkretne u MP3 formatu nerealizovatelna - imho by se s timto muselo pocitat uz pri navrhu samotneho formatu (jak zde psal Pit) a je dost dobre mozne, ze diky teto vlastnosti by mel ve vysledku horsi pomer velikost/kvalita.