Kijött a tizes Flash fejlesztői doksijának előzetese, innen tölthető. Csak most volt időm átnézni és rögtön nekiestem az engem érdeklő újdonságok nyomainak, úgymint P2P, lokális fájlok elérése és persze videó (javaslom olvasd el a korábbi bejegyzésemet ha még nem). Előre szólok, hogy nincs kolbászból a kerítés és sok a mézesmadzag.
Eddig ezzel az osztállyal lehetett többek között egy vagy több lokális fájlt megjelölni és feltölteni a szerverre, mostantól viszont a betöltött fájl minden egyes bájtja is elérhető a data:ByteArray (csak olvasható!) objektumon keresztül. Két fontos tulajdonság:
Ezzel lehet bármilyen bináris adatot kezelni, olvasni és írni, boolean szinttől a bájtokon át egészen komplett AMF objektum szintig, nagyon sokféleképpen, ez igen kényelmes. UTF-8 karakterenként is képes olvasni, nem kell ezzel vacakolni. Már 9-es Flash-től elérhető, de:
Extra, hogy az egész adathalmazt képes zlib-bel tömöríteni és kicsomagolni (mihez tartás végett: a gzip-ben ez van) és ennek a kiterjesztett változatát, a deflate-et is tudja, tehát gyakorlatilag egy komplett gzip van benne.
A Sound objektum extract metódusával ByteArray-ben érhetők el a nyers audió adatok. Mármint úgy nyers, hogy mondjuk egy mp3 azért kikódolásra kerül és megkapod a belső, mindig 44100hz 32bit float formátumú adatot.
Nagyon vártam, hogy esetleg hozzá lehet majd férni a videó bájtjaihoz, hát sajnos nem (az audiót a Sound-on keresztül talán ki lehet bújtatni). Ellenben végre van rendes NetStream információ a NetStreamInfo ojjektummal, pl. a dropped frames és playback kbps szinte egyből megvan.
Jópofa a maxPauseBufferTime tulajdonság, ami azt szabályozza, hogy egy megállított videó maximum hány másodpercet töltsön még be. Tehát pl. egy YouTube videó (ha felkészítik a YouTube playert) a pause gomb lenyomása után nem fogja feleslegesen enni a sávszéledet, a play-ig megáll a letöltés.
Felkészítés nélkül pedig max. 60 további másodpercet zúz csak, ez a default érték, így a régi playerek is kapnak a jóból. Amekkora arányt elvesz a teljes internets sávszéléből a videó (kb. 40%) és amekkora ebből a Flash aránya (kb. 95%), csak ez a pici intézkedés képes lesz akár 1-2%-ot is megtakarítani világszinten, aaaaz rengeteg bájt.
A NetConnection-nél kell állítani a maxPeerConnections értékét, az alapértelmezett 8. Kiváncsi leszek, hogy mondjuk a uStream programozói (Felhőbácsi) hogyan fogják ezt kihasználni, hiszen az egy szem szerver-felé stream-en kívül érdemes lesz kapásból néhány közeli, lokális usert is kiszolgálni (ami felveti, hogy hogyan mérjük ki a közeli és hogyan mérjük a teljes rendelkezésre álló kifelé sávszélt, hogy legalább a szerver tutira megkapja, ami kell).
A NetStream objektumnál is van egy-két peer tulajdonság. Arról viszont nincs még hajszálpontos infóm, hogy a francba kell p2p alapon csatlakozni valakihez, bőven hiányos ez a doksi még. Van a NetConnection-nél egy nearID, ez a player saját azonosítója, ezt a többiek farID-nak látják, illetve a NetConnection protokolljának "rtmfp"-nek kell lennie.
Szóval az RTMFP lesz a P2P Flash fegyver. UDP alapú, azaz nem garantált minden adat megérkezése, de audio/videónál ez inkább jó. Sajnos azt csiripelik a verebek, hogy a méregdrága Flash Media Server kell a kapcsolat létesítéséhez, az FMS intézi a nearID-farID azonosítók kezelését és az összekapcsolást, aztán a kliensek már a szerver érintése nélkül mennek tovább. Csak remélni tudom, hogy gyorsan lesz rá open megoldás.
A hülye nearID-farID helyett egy helyes kis IP cím - port számnak mindenki jobban örült volna.
iMect means internet, media and other cool things. iMect is a small company near lake Velence, Hungary. We’ve a big footer on every page where you can discover what we do and what happens with us.
Az iMect jelentése: internet, média és egyéb király dolgok. Egy kis cég vagyunk közel a Velencei-tóhoz. Minden oldalon van egy nagy lábléc, ahol felfedezheted, hogy mivel foglalkozunk.