Vyznam dual core

[PiT]

Pri komprimaci MP3 se pouzivaji Long, Short a Mixed Blocks - tj. dopredu nevim jak velky frame pouziju, proto by nejake deleni zdrojoveho souboru nebo enkodovani na preskacku bylo imho nerealizovatelne (minimalne ne bez dopadu na kvalitu)

A kto povedal, ze to musim robit na preskacku, ked mam dopredu dany obsah toho, co idem kodovat

[Caleb]

A kto povedal, ze to musim robit na preskacku, ked mam dopredu dany obsah toho, co idem kodovat

Povidal to THX
Kdyz se komprimuje Wav do MP3, tak o tom, jak dlouhy frame se pouzije se rozhoduje v prubehu komprimace - pokud by si nejdrive komprimoval prvni polovinu souboru a pote druhou (nebo po nejakych blokach, to v principu nic nemeni) tak nezarucis, ze ti ty casti do sebe budou zapadat - frame jako takovy je nedelitelny a jak sem rekl, dopredu nevis kde jake framy pouzijes.

[PiT]

A v com je problem posledny frame prvej polovice useknut resp. prisposobit na presnu dlzku?

Kodovat na preskacku je hlupost. Bavme sa cisto o rozdeleni kodovanych udajov na 2 polovice (pripadne v nejakom pomere na zaklade statistickych udajov ziskanych z prveho passu) s nejakym prekryvom alebo uplne bez prekryvu.

[Caleb]

A v com je problem posledny frame prvej polovice useknut resp. prisposobit na presnu dlzku?

frame jako takovy je nedelitelny

- navic i kdyby to slo - presne tohle by melo vliv na kvalitu - vysledek z multithread. aplikace by byl jiny nez ze singlethread.
Ale to uz jsme hodne OT. Myslim ze podobne problemy mohou postihnout podobne z principu sekvencni ztratove komprese.
EDIT: 2 pass enkodovani MP3 sem jeste nevidel, to nejaky encoder umi?

[PiT]

Ako je potom rieseny koniec MP3ojky? Viem, ze s tym byval problem ale ten je, pokial viem, uz nejaku dobu vyrieseny.

EDIT: Na akom principe funguje VBR enkoder? Cisto na nejakom dopredu urcenom zasobniku a jeho prekracovaniu/nedosahovaniu?
V principe ale na pravy 2 pass u MP3 kaslu, lebo by vysledok nebol o tolko lepsi ako pri VBR/ABR, ktory je zauzivany...

EDIT2: OK, nastudoval som si to, vdaka tomu zasobniku (bit reservoir) je v podobe ako funguje LAME nemozne z neho spravit Multithread aplikaciu pre VBR/ABR...
Video ale imho paralelizovatelne je - 1 pass 100%ne - staci rozdelit subor hrubo v polovici - najst najblizsiu zmenu sceny - a zacat kodovat naraz obe "polovice".
2hy pass na zaklade udajov z prveho priamo ovplyvnujem, takze mozem tiez rozdelit ulohy "na polovicu", nie?

[Caleb]

Ako je potom rieseny koniec MP3ojky? Viem, ze s tym byval problem ale ten je, pokial viem, uz nejaku dobu vyrieseny.

Lame umi posledni frame useknout, ale nikdo nerekl, ze se na nej da navazovat - a myslim ze tohle se resi pomoci "mp3_accurate_length = yes" tagu. MP3 uz hodne dlouho nepouzivam, takze v tomhle si jistej nejsem, kazdopadne vim, ze frame jako takovej je nedelitelnej.
Tohle se ale tyka pouze kodeku MP3 jako takoveho (prilis stastne navrzen nebyl), tj. v tomhle pripade si nedokazu predstavit realizaci tebou navrhovaneho systemu. Navic to sou proste problemy navic, myslim ze vyvojari se budou spise snazit zdokonalovat kodek samotnej.
Multi-threaded aplikace je proste narocnejsi vyvijet a ladit, spousta problemu nelze multithreadove algoritmizovat vubec. Ja sem velkym zastancem dualcore (hlavne kvuli multitaskingu), ale rozhodne nejsem optimista co se tyce narustu mutli-threaded optimalizovanych aplikaci.

[PiT]

Multi-threaded aplikace je proste narocnejsi vyvijet a ladit, spousta problemu nelze multithreadove algoritmizovat vubec. Ja sem velkym zastancem dualcore (hlavne kvuli multitaskingu), ale rozhodne nejsem optimista co se tyce narustu mutli-threaded optimalizovanych aplikaci.

Presne tak... Hlavny problem je v tom, ze treba poriadne rozmyslat pri samotnom navrhu a programovani na vyssej urovni... Neda sa spolahnut na prekladac a kompilator...