[OpenVIP-devel] potencialni odpoved na FAQ re. adresovani streamu

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

Ahoj,

vymyslel jste nekdo nahodou reseni toho pondelniho problemu s=20
jednotnym adresovanim pozic v audio a video proudech? Pripominam=20
zatim vymyslene varianty:

  - adresovat A/V zvlast (V: snimky, A: bloky dat)
  - adresovat casovym intervalem
  - mit u kazdeho modulu parametr FPS a adresovat audio cislem snimku
    s tim, ze neni jasne, jak velky objem dat jeden "snimek"
    predstavuje

Priznavam, ze jsem nemel moc cas nad tim premyslet, takze treba lze=20
vymyslet funkcni & jednoduche unifikovane schema... Ja na zadne=20
neprisel :), takze navrhuju tohle:

1) Adresovat ruzne typy dat ruzne, jejich "prirozenym" adresovanim.=20
Tj. dotazy na video modul pomoci snimku, dotazy na audio pomoci=20
dvojice (pocatecni sample, # samplu). Dusledek: moduly pro zpracovani=20
A a V maji jiny interface, pracuje se s nimi jinak. Rovnez je potreba=20
specializace na urovni (vstupnich) portu modulu.

2) Zavest "vystupni modul" jako specialni pripad modulu, ktery nema=20
vystupni porty a tudiz *po nem nikdy nikdo nebude zadat zadna data*.=20
Vypocet nebude probihat tak, ze se vystupni moduly zadaji o snimky=20
0,1,...,N (interface IOutputModule vubec zadost o snimky=20
nepripousti!), ale bude se adresovat "cislem iterace", coz obecne=20
nemusi mit zadny vztah k poctu snimku nebo delce videa. Planovac se=20
kazdeho vystupniho modulu zepta na pocet iteraci potrebnych k zapsani=20
celeho vystupu a pote vola jeho metody "zjisti pozadovana data pro=20
provedeni iterace i" a "proved iteraci i". V pripade video vystupu je=20
vhodna volba 1 iterace =3D 1 snimek, v pripade audio-only vystupu napr.=20
1 iterace =3D 4 kilosamply.

3) krome A a V zavest jeste treti typ streamu (a tedy i portu a=20
zpracovavajiciho modulu...): obecna data. Ucelem je poskytnout=20
takovou berlicku k protlaceni non(A or V) dat systemem. Prikladem=20
jsou treba titulky z textoveho souboru nebo DVD titulky nebo nejaka=20
metadata. Struktura techto proudu musi byt hodne obecna, takze mi=20
prijde jako rozumne adresovat je pomoci *casoveho* intervalu -- dotaz=20
na interval (a,b) vrati data v podobe seznamu paketu relevantnich pro=20
dany casovy interval. Paket je struktura { string packet_id; float=20
time; ... }, kde "..." zavisi na tom, co je packet_id. Moduly=20
ignoruji pakety, jejichz ID neznaji.

Zjevne tenhle pristup odstranuje problem s potrebou jednotneho=20
adresovani vystupnich A+V modulu, ale bojim se, jestli s timhle=20
modelem nebudou jine, horsi problemy -- proto to posilam sem, at mate=20
dost casu prijit na to, proc to nebude fungovat ;)

Vasek