|
From: Vaclav S. <vac...@ma...> - 2002-04-19 11:22:20
|
Ahoj, > 2) Ad UML od Viria > soubor UML1: > Typicky diagram Use-Case obsahuje desitky ci stovky entit - NE. > Typicky diagram by nemel obsahovat vic nez 10 entit, jinak je > neprehledny. Ovsem na vsech diagramech dohromady popisujicich > system muze byt radove 100 - 1000 entit. Tohle asi myslel... > Soubor UML2 bez pripominek, Soubor UML3 jsem si jeste neprohledl > (nemohl jsem se zalogovat na SF, ted uz jsem to dal doporadku). Huh?! K pristupu k webu zadne zalogovani neni potreba, proste si v=20 browseru otevres http://openvip.sf.net. Do SF se musis zalogovat=20 jenom pokud chces delat s bug trackerem nebo admin interfacem... > 4) Slovnik doplnit o pojmy: > Time-line model > videoflow model Pridano do moji TODO FIFO. > 5) Processing overview > "Na kazdem vstupnim portu smi byt pripojena prave jedna pipa" > Misto SMI by asi melo byt MUSI Pravda. > 6) Video pipa ma hlavni funkci GetFrame(n) ..., plus bude muset > zajistovat konverze formatu > Nebo by mohly existovat specielni procesory, ktere maji za ukol > pouze prevod datovych formatu. Tahle myslenka se samozrejme nabizi. Zavrhl jsem ji, protoze je a)=20 navrhove osklivejsi a b) trochu slozitejsi na implementaci.=20 Vysvetlim: Sit procesoru je high-level popis ulohy (stejne jako=20 timeline, to je jeste vyssi popis) a spada do *uzivatelske* casti=20 systemu -- uzivatel popisuje ulohu v terminech site. Protoze moduly=20 nemaji a priori znalost o formatu na vstupu (nemohou mit; zavisi=20 totiz na tom, co je pred nimi pripojeno v siti!) a seznam formatu=20 podporovanych modulem je implementacni detail, do ktereho uzivateli=20 nic neni (uzivatel rozhodne nechce pri vymysleni site na zpracovani=20 obrazu premyslet nad impl. omezenimi "motion blur" filtru...),=20 znamenalo by to, ze je potreba sit trosku modifikovat pred tim, nez=20 se s ni zacne pocitat (pridat nove uzly). To se mi zda jako spatny=20 design (ja vim, subjektivni), ale hlavne je to komplikace navic. Proto IMHO bude nejlepsi mit objekt s jednim snimkem videa, ktery se=20 tvari, ze ma data ve vsech formatech a konverzi provadi on-the-fly.=20 (Nebo ekvivalentne, ze je to fce pipe, ale ukazuje se (viz utery), ze=20 by to byla jedina smysluplna funkce pipe a ze cela analogie s rourami=20 pokulhava...) BTW, pote co jsem se v utery pristihl, ze misto "procesor" rikam=20 casteji "modul" nebo "plugin", tak navrhuju plosnou upravu=20 terminologie: procesor -> modul. Procesor je pro modul blby nazev,=20 protoze OpenVIP =3D Open Video Processor a tedy stejny termin pro dve=20 ruzne veci (modul a cely system). > 7) Typy procesoru > Source a Output jsou v jistem smyslu inverzni, nemel by to > vyjadrovat i nazev typu? Treba Source a Destination nebo Input a > Output? Pravda. Input/Output je neprijemne v tom, ze I/O jsou z hlediska=20 modulu jejich porty a "Input" by pak podle kontextu bud znamenalo=20 hranu grafu vedouci do modulu nebo vstupni modul site. Navrhuju=20 Read/Write (uzel, modul). > 8) SWITCH > "V casovych intervalech nepokrytych zadnym vstupnim portem se > pousti ven /dev/null" > Vim co jsi chtel rici, ale spravnejsi by asi bylo, ze se chova > jako /dev/null, cili jako SOURCE "dev/null". To je neformalni vyjadreni, v praxi tam samozrejme zadny READ modul=20 /dev/null nebude, ale pouze VideoFrame instance s priznakem, ze=20 neobsahuji validni data...=20 > 9) dobry preklep - takova automagie :-) > Vyrenderovani probiha "automagicky" To neni preklep, to je odborny termin. Asi jsem moc cetl The Jargon=20 File ;-) > 10) Binarni kompatibilita > Nerozumim uplne presne vsem detailnim problemum, ale ja bych si to > predstavoval tak, ze v jadru by byly nejake proxy-objekty, ktere > zaridi komunikaci se skutecnymi objekty v DLL. KOmunikaci muze > zajistit Corba, COM, nebo jiny existujici protokol, nebo si muzeme > protokol napsat vlastni (treba neco pres XML). Ano, jedna se o principalne stejny problem, jaky musi resit=20 kterykoliv RPC a/nebo distribuovanu objektovy system, tedy napr.=20 CORBA. Je jenom treba si uvedomit, ze tento problem existuje i v=20 ramci jednoho procesu diky omezeni kompilatoru. Nejlepsi zpusob jak=20 vysvetlit, jak to bude fungovat, opravdu je "viz CORBA nebo COM" ;-) Duvod, proc nemuzeme pouzit existujici systemy, je jednoduchy:=20 brutalni overkill. CORBA je meziprocesova a sitove transparentni,=20 dela tedy marchallovani dat, komunikuje po siti. To by uz byl=20 postrehnutelny overhead -- nezapominej, ze zde bude alespon jedno RPC=20 volani na snimek a modul! O potrebe existence brokera ani nemluve...=20 Jak presne na tom je COM nevim (IIRC COM2/ActiveX je z tohoto pohledu=20 totez), kazdopadne to ale neni cross platform reseni. XPCOM sice je,=20 ale ma spoustu zavislosti na Mozille a je velka. Existuji dalsi=20 "lightweight" COM-like knihovny (XCOM [resi ABI, ale C++ only a=20 intenzivne pouziva sablony, takze port pro C bude slozitejsi], XPLC=20 [neresi ABI]), z tech taky vykrademe, co se da :)=20 Pouzit pro komunikaci vlastni protokol: ano, ale spis "protokol".=20 Pouzit protokol typu XML zapisu vyzaduje spoustu zbytecnych kroku pri=20 kazdem RPC volani -- pro nase ucely (in-process komunikace, na rozdil=20 od inter-process COMu) staci zajistit, ze se proxy a "vzdaleny"=20 objekt mezi sebou dohodnou na presnem layoutu datovych struktur a na=20 volaci konvenci pro funkce (bohate staci ANSI C: volaci konvence=20 cdecl, struktury se zarovnanim na 1 byte). Protoze vsechny komponenty=20 budou ve stejnem adresovem prostoru, staci predat pointery na funkce=20 a celkovy overhead komponentoveho systemu bude 1 call ptr instrukce=20 navic plus pripadne konverze dat (jenom u specialnich pripadu, ktere=20 nastavaji ridce a ne behem vypoctu snimku, napr. konverze std::string=20 a std::list<T>). Proste zadna veda :) Na prizpusobeni XCOM nasim potrebam (otevrenost pro dalsi jazyky, aby=20 slo pak k siti pristupovat z Pythonu, odstraneni potreby UUID,=20 enumerace vsech trid poskytujicich dany inteface (abych napr. nasel=20 vsechny filtry), cislovani verzi intefacu, aby nedochazelo ke kolizim=20 novych pluginu se starou verzi OpenVIP) uz delam, bohuzel mi to=20 zabralo mnohem vic casu, nez jsem cekal :( Momentalne C (a tedy ABI=20 vrstva) funguje, C++ klient taky, "server" napsany v C++ jsem jeste=20 nezkousel. Jeste je potreba doplnit IDL parser o korektni zpracovani=20 typu string a sequence<> a bude to stacit. > se mi, ze bychom se meli venovat te casti se zpracovanim zvuku. > Obraz Vasek vymyslel dost slusne, ale zvuk jsem jeste nedocenil. V utery jsme se (prinejmensim s Tondou ;) shodli, ze nevymyslime nic=20 lepsiho nez totez jako u video casti. Principalne proste nic jineho=20 neni mozne: my _musime_ zvuk nacist sekvencne a potom ho sekvencne=20 zapsat. Co se stane mezitim se v naproste vetsine pripadu da=20 implementovat pomoci N pruchodu (Jirka porad neprisel s operaci nad=20 zvukovou stopou, ktera to nesplnuje) -- a co nejde, to se udela dvema=20 pruchody: v prvnim se audio stopa vysype do (obrovske) cache na=20 disku, na konci 1. pruchodu se provede kdovico ten modul dela a v=20 druhem pruchodu provede kopirovani z cache na vystup.=20 Jedina otazka asi je, jestli ma smysl dovolit modulem rizenou=20 granularitu pozadavku na zvukovy kanal: bud je velikost audio framu=20 fixni (napr. 4096 samplu) a pozadavky jsou GetFrame(1), GetFrame(2)=20 atd. nebo si modul rika, kolik dat chce (GetData(pozice,=20 pocet_samplu)). IMHO prvni varianta staci, ale druha je zase=20 obecnejsi, takze tam neni takove nebezpeci unahleneho predpokladu. Vasek |