openvip-devel — OpenVIP development is discussed here

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

[OpenVIP-devel] Poznamky k uplynulemu tydnu

[Ludek M. <mar...@ss...>]

0) Omlouvam se, ze jsem neprisel na schuzku. Mel jsem praci a nedostal jsem se
vcas k mailu.
Poznamenal jsem si, ze pristi schuzka je 23.4.2002 16:00

1) Jirka a Jozo jeste nejsou v registrovani v OpenVIP - neco s tim udelejte
  (jsem tam ja, Milan, Tonda a Vasek)

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.

Soubor UML2 bez pripominek, Soubor UML3 jsem si jeste neprohledl (nemohl jsem
se zalogovat na SF, ted uz jsem to dal doporadku).

3) Pochvala slovniku

4) Slovnik doplnit o pojmy:
   Time-line model
   videoflow model

5) Processing overview
   "Na kazdem vstupnim portu smi byt pripojena prave jedna pipa"
   Misto SMI by asi melo byt MUSI

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.

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?

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".

9) dobry preklep - takova automagie :-)
Vyrenderovani probiha "automagicky"

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).

11) Architektura
  -- pozdeji --

12) Dekuju Vaskovi za velmi slusne dokumenty. Doufam, ze si to vsichni
prectete, zkritizujete mu to abychom odhalili slabiny. Zda se mi, ze bychom se
meli venovat te casti se zpracovanim zvuku. Obraz Vasek vymyslel dost slusne,
ale zvuk jsem jeste nedocenil.

Ahoj

                                      Ludek Marek

                                        mar...@ss...

[OpenVIP-devel] dalsi schuzka

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

Pro pripomenuti: pristi projektova schuzka byla domluvena na utery=20
23.4. na 16:00.

(Popis tech algoritmu/pristupu udelam do konce tydne... pevne verim :)

VS

[OpenVIP-devel] poznamky k architekture na webu

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

Ahoj,

uploadnul jsem dalsi dil Slavikovych poznamek k OpenVIP...  Na=20
http://openvip.sf.net/internal/notes/architecture.html je par veci,=20
na ktere bychom nemeli zapomenout pri navrhu architektury - jsem si=20
jisty, ze tam toho spousta chybi, ale lepsi neuplna poznamka nez pak=20
na neco zapomenout :)

Vasek

Re: [OpenVIP-devel] pristi (pracovni) schuzka

[Michal D. <lu...@ce...>]

VS> Cau,

VS> co rikate tomu udelat pristi schuzku v utery vzapeti po te pravidelne 
VS> schuzce s L.M. (ta IIRC zacina 15:45, do ~16:45 budeme hotovi, tak 
VS> potom). Krome Tondovych (a Jirkovych?) dotazu bych rad zacal aspon s 
VS> hrubym navrhem architektury jadra... Delat to uz tenhle tyden nema 
VS> smysl, je potreba nejdriv zjistit co a jak s audiem a tak.

VS> Pokud se utery nehodi, tak muzu tenhle vikend kdykoliv, pristi tyden 
VS> v patek (asi) nebo nedeli.


Proti schuzce v utery nic nemam.

    Michal Dvorak <lu...@ce...>


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
A jury consists of 12 persons chosen to decide
who has the better lawyer.

-- Robert Frost
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

[OpenVIP-devel] pracovni schuzka

[<xj...@em...>]

Souhlasim s prac. sch. v utery po te oficialni.

Jozef Smizansky

_________________________________________________________________________=
_____
---------> Created by Email.cz
http://www.email.cz <--- Get Your Free Email
    =20

[OpenVIP-devel] UML a dalsi

[Ludek M. <mar...@ss...>]

Kluci, sorry, ale ja ted fakt nejak nemam cas prochazet ty URL, ktery tu Vasek
aktivne postuje. Opravuju studentum domaci ukoly, vyrizuju nejaky veci kolem
SW projektu a nemam uz cas sedet u prohlizece. Na vikend jedu domu a prijedu
az v pondeli.

Pokud budete prochazet ty dokumenty, pamatujte, ze dulezite je pochopit k cemu
jsou nasl. typy diagramu:
Use-case diagram
Class diagram
Sequence diagram (popr. collaboration diagram)
State Chart

Ostatni druhy diagramu jsou zajimave, ale nepovazuju je za dulezite.

O Class diagramech pise kde kdo, tam neni nic noveho. Nove jsou ty Use-case,
to je dulezity (pro analyzu toho, CO ma system delat). Sequence + State chart
jsou dulezite pro navrh - popisuji JAK ma system uvnitr fungovat.

Snad Vam tohle trochu pomuze.

                                      Ludek Marek

                                        mar...@ss...

[OpenVIP-devel] pristi (pracovni) schuzka

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

Cau,

co rikate tomu udelat pristi schuzku v utery vzapeti po te pravidelne=20
schuzce s L.M. (ta IIRC zacina 15:45, do ~16:45 budeme hotovi, tak=20
potom). Krome Tondovych (a Jirkovych?) dotazu bych rad zacal aspon s=20
hrubym navrhem architektury jadra... Delat to uz tenhle tyden nema=20
smysl, je potreba nejdriv zjistit co a jak s audiem a tak.

Pokud se utery nehodi, tak muzu tenhle vikend kdykoliv, pristi tyden=20
v patek (asi) nebo nedeli.

Vasek

[OpenVIP-devel] dalsi UML dokumentace

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

Cau,

na strance=20
http://gutleber.home.cern.ch/gutleber/umlpage/uml_resources.htm jsou=20
nejake kratke tutorialy a UML Notation Guide (148 stranek, vypada=20
slusne).

http://home.wanadoo.nl/techlinq/uml.html je UML rozcestnik a vypada=20
to, ze ukazuje na slusne zdroje (i.e. clanky obsahujici neco vic nez=20
jen obecne povidani).

Vasek

[OpenVIP-devel] treti pokracovani UML

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

Cau,

nahral jsem treti dil, je to v ponekud obskurnim formatu DjVu (jenze=20
jinak by to bylo obrovske...), prohlizec pro Wokna jsem tam nahral=20
taky (plugin do browseru), pro Unix je k nalezeni na=20
http://djvu.sf.net ...

Vasek

Re: [OpenVIP-devel] Zdroje o zpracovani hudby

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

Ludek Marek wrote:
> Zkusil jsem na SourceForge dat vyhledavani slova video v
> Software/group. Myslim ze to vyhodilo i par veci, ktere nejak
> operuji se zvukem. Zkuste se podivat.

Dalsi veci se daji najit na freshmeat.net (katalog Unixovych hlavne=20
open source nebo free aplikaci, obsah je pravdepodobne nadmnozinou=20
sf.net).

Mozna(!) budou zajimave zdrojaky Audacity, viz=20
http://freshmeat.net/search/?q=3Daudacity (prime URL si nepamatuji, ale=20
skoro urcite to bude audacity.sourceforge.net...)

Vasek

[OpenVIP-devel] registrace na sf.net

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

Cau,

je treba vyplnit tenhle formular:
    http://sourceforge.net/account/register.php
a poslat mi login name.

Vasek

[OpenVIP-devel] Zdroje o zpracovani hudby

[Ludek M. <mar...@ss...>]

Zkusil jsem na SourceForge dat vyhledavani slova video v Software/group.
Myslim ze to vyhodilo i par veci, ktere nejak operuji se zvukem. Zkuste se
podivat.

                                      Ludek Marek

                                        mar...@ss...

[OpenVIP-devel] intro do UML

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

Cau,

docela nahodou jsem v CHIPu nasel tridilny uvod do UML (by M. Virius,=20
takze to nejsou uplne zvasty jako dost veci z=20
http://www.cetus-links.org ;-). Je v cislech 2/2002 az 4/2002. Nahral=20
jsem prvni dva dily do

    http://openvip.sf.net/internal/tmp/

treti snad bude nasledovat zitra vecer. Prvni dil tam je jako hodne=20
souboru nejruznejsich formatu a velikosti, tak se nedeste - je to=20
totez jenom pokazde jinak zabalene (od 400kB .ps.bz2 az po 2.4MB=20
PDF). Je to IMHO docela hezky udelany uvod do UML nebo tutorial.

Vasek

[OpenVIP-devel] admin stuff

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

Cau,

nastavil jsem projekt na sf.net do pouzitelneho stavu. Tady je popis=20
toho, co a jak funguje (reknete mi, jestli jsem na neco zapomnel):

(1)
Mailing list ope...@li... urceny k diskuzi technickych=20
zalezitosti, idealne by mel castecne nahradit osobni schuzky.=20
Prihlaseni jsou uz vsichni. List ma nastavene reply-to mungling, tj.=20
pokud v maileru kliknete na "Reply", odpoved se neposila autorovi=20
prispevku, ale do konference. Je to mozne zmenit, pokud nevyhovuje=20
(pak je treba pouzit "Reply to all" a rucne odstranit puvodniho=20
odesilatele nebo si poridit chytry MUA). Velikost prispevku je=20
omezena 40kB, mohu libovolne zmenit.

(2)
CVS repozitar cvs.openvip.sf.net obsahuje dva moduly, "website"=20
(http://openvip.sf.net se z nej generuje) a "openvip" (zdrojaky,=20
zatim prazdny). Pristup k repozitari je mozny jenom pomoci SSH (viz=20
dokumentace SF a linky na http://openvip.sf.net/internal/) a=20
prerekvizitou je registrace na SF, tj. momentalne mam pristup jenom=20
ja a Tonda. Pouziti CVS viz "info cvs" nebo The CVS Book.

Prvni checkout repozitare lze udelat napriklad takto (loginname je=20
pochopitelne vas login, \ znamena pokracovani radku, tj. cely postup=20
ma 5 a ne 9 radek):

    export CVS_RSH=3Dssh
    cd ~
    cvs -z3 \
      -d:ext:log...@cv...:/cvsroot/openvip \
      checkout openvip
    cd openvip
    cvs -z3 \
      -d:ext:log...@cv...:/cvsroot/openvip \
      checkout website

Pote lze oba adresare prejmenovat. Nasledny update se uz dela jenom=20
pomoci
    cd ~/openvip ; cvs update -d -P ; cd website ; cvs update -d -P

(3)
Web se updatuje automaticky 1x denne z CVS modulu "website". Udelat=20
update po kazdem commitu do repository se mi nepovedlo, protoze WWW a=20
CVS servery jsou na SF fyzicky na jinych strojich a jsem prilis liny=20
na vymysleni nejakeho sloziteho notifikacniho mechanismu, kdyz cron=20
slouzi docela dobre. Pokud je nutne udelat _okamzity_ update webu,=20
jde to docela snadno:

    ssh -l loginname openvip.sf.net
    cd /home/groups/o/op/openvip/htdocs
    cvs update -P -d
    logout

Struktura webu http://openvip.sf.net/ je tato:

/index.html=20
    - uvodni stranka pro non-developery
/internal/=20
    - prostor pro vyvojare
/internal/index.html
    - ...a jeho uvodni stranka, obsahuje i ruzne linky
/internal/spec.html
    - specifikace pro komisi
/internal/reports/=20
    - Markovy reporty (text/plain soubory se jmeny jako=20
      2002-04-02.txt)
/internal/notes/
    - ruzne dokumenty a poznamky pro nasi potrebu. Momentalne
      obsahuje ten muj navrh site (still awaiting _any_ feedback!) a=20
      Markuv slovnik pojmu (prazdny, nevim co tam psat...)
/internal/tmp/
    - prostor na nahravani docasnych souboru. Neni v CVS!

Modifikovat stranky muze kazdy s CVS pristupem.

(4)
Do mailing listu ope...@li... se posilaji logy o=20
veskerych zapisech do CVS repozitare v podobe unified diffu mezi=20
puvodni a novou verzi souboru. Ucelem tohoto listu je jednak umoznit=20
peer review kodu (vice oci, mene chyb), jednak informovat o tom, ze=20
se neco zmenilo. Posilaji se sem i logy z websitu. V soucasnosti se=20
posilaji plne texty nove pridanych souboru a diffy do velikosti 500=20
radku. Velikost prispevku je neomezena (40kB nestacilo ani na logy o=20
prvni verzi webu ;).

Vasek

[OpenVIP-devel] Fwd: Projekt - ut schuzka

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

Cau,

preposilam Jirkuv zapis ze schuzky. [Jirko, muzes rovnou posilat na=20
adresu ope...@li......]

Ad nase schuzka (viz attachment): muzu od patku kdykoliv, otazka je,=20
co a jestli potrebujeme ted vyresit a jestli se neco z toho neda=20
udelat formou diskuze na tomhle m-listu. Ja osobne budu mit furu=20
prace se setupem openvip.sf.net, takze o moc vic udelat nestihnu...=20
Co IMHO urcite potrebujeme je probrat ten muj (nebo nejaky=20
alternativni) navrh pristupu k jadru a prip. udelat jeho dalsi=20
iteraci...

Ad davani zapisu na web: co takhle abychom je posilali jako maily do=20
openvip-devel? Ten je archivovany...

Vasek

----------  FWD  ----------

Subject: Projekt - ut schuzka
Date: Tue, 02 Apr 2002 23:09:02 +0200
From: <jir...@ce...>
To: <vac...@ma...>

ahoj
posilam ti zapis z uterni schuzky, zkus ji prosim dat na
projektovou stranku, prip. preposlat ostatnim

dik
jirka

[OpenVIP-devel] co se stalo na schuzce

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

Cau,

zjevne jsem na schuzku nestihl dorazit :) Co se tam delo? A kdy bude=20
dalsi, zase v utery?

Dik,
Vasek

[Openvip-devel] Omluva

[<xj...@em...>]

Dobry den,
omlouvam se, ale bohuzel dnes opet nemohu prijit na schuzku clenu projekt=
u Video(OpenVIP). Priste uz urcite prijdu.

Jozef Smizansky


_________________________________________________________________________=
_____
Nakupujte na internetu levn=ECji - http://www.pconline.cz
PC d=EDly, PDA, software, digital foto, GSM