Re: [OpenVIP-devel] Poznamky k uplynulemu tydnu

[Vaclav S. <vac...@ma...>]

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