Videó a Flickr-en

Internet, Közösségi média

Már régebb óta pusmogtak arról, hogy a Flickr hamarosan a képek mellett videó feltöltési és megosztási szolgáltatást fog indítani. A nap eljött, a szolgáltatás elérhető.

Az első HUP videó a Flickr-en

Ugyanez a Youtube-on

(A YouTube videó még a Hi-Def bejelentés előtt lett feltöltve, lehet, hogy ha most tölteném fel, jobb lenne a minősége.)

A Flickr ellentétben a többi videómegosztó oldallal nem mindenféle videó, hanem a saját kezűleg készített videók megosztását szorgalmazza. A megosztható videók maximális hossza jelenleg 90 másodperc. A "Pro" (előfizetéssel rendelkező) Flickr tagok már használhatják a szolgáltatást.

A részletek itt olvashatók.

( thuglife | 2008. 04. 09., sze – 11:23 )

ez miota ideillo hir? amiota eladtad a lelked? :)

Internet kategóriába belefér. A HUP cikkek képei a Flickr-ről jönnek. Ezentúl lehet, hogy a videók is. A YouTube hasonló cikknél nem tetted fel ezt a kérdést. A lelkemnek meg nem tudom mi köze lenne a Flickr-hez. Ők vették volna meg, vagy mi? :) Egyszerűen érdekel engem a téma.

--
trey @ gépház

( kikke | 2008. 04. 09., sze – 11:44 )

Kíváncsi vagyok mikor támad fel a stage6... Mert ez még mindig nagyon idejétmúlt, ahhoz képest. Mondhatni, szánalmas utánlövés.
--
the tide is turning

A divx videomegosztója volt, azon is többnyire saját felvételek voltak, és mivel divx volt a formátum, igen jó minőségű videók voltak fent. Volt persze videoklip is rengeteg.
De sebaj, most az archive.org-ot használom kulturális értéket hordozó videók megosztásához.
--
the tide is turning

Azt állították magukról, hogy a vége felé havi 1M dollár volt a havi internetszámlájuk (a divx cég nyomta) és ezért érthetően vége a mókának. Mondjuk némi fenntartásokkal vagyok a számokat illetően, de az biztos, hogy a nem P2P megoldásban elég húzós dolog videót szolgáltatni.

Én csak azt nem értem, miért éri meg jobban a többi, még élő videomegosztónak a blokkokra széteső flv-re pazarolni ugyanannyi tárhelyet mint a kristálytiszta divxre?
Egy 720x576-os film divx-en mondjuk 700MB körül van, 320x240-es aránylag még nézhető flv-ben kb. feleakkora helyet foglal. Akkor már érdemesebb - lenne - úgy hagyni ahogy van, kétszer annyi helyet foglal de sokkal, sokkal jobb minőség. Vagy legyen vége ennek az flv-s mókának, nem filmre van kitalálva..
--
the tide is turning

Többek között azért, mert az FLV-t le lehet játszani böngészőből (flash), a divx-et meg nem. (a média lejátszó plugineket hagyjuk, nem lehet velük számolni, ha ilyen site-ot tervezel.

Az FLV egyébként csak egy konténer, több féle video codec-et támogat, ezek egy része nagyságrendileg jobb, mint a divx, igaz, hogy nem mindet lehet ingyenes szoftverekkel megfelelően előállítani, ezért az ilyen 1 php kóder + 1 debian rendszergazda + sok PC + befektetők felállású videomegosztó cégek nem kedvelik.

Pl. ez is "FLV": http://www.flashvideofactory.com/test/demofullscreen345.html

meg ez is,
http://www.sensation-white.hu/siteLC.html?width=1012&height=709

felbontásban nincs a másik közelében, de már normál minőségű video, és flv. ha vmi médiaplugin kellene hozzá, amit innen meg onnan kellene letölteni, a többség hagyná a francba az egészet. az internetes video ma = flashplugin. ha jól emlékszem a Ms és az EU sokat civakodott anno, az XPbe került win mediaplayer miatt, még wmp nélküli xp változatot is ki kellett adnia a msnak. az internetes videózás monopolitálása volt akkor vád. és hol van ma a wmp a flashez képest? a divx webplugin pedig még a wmphez képest sincs sehol, nemhogy flash.

( evone | 2008. 04. 09., sze – 11:47 )

miert adta volna el? a flickr a legjobb foto megoszto oldal internet szerte...

( leeroy | 2008. 04. 09., sze – 11:56 )

Tudom, hogy OFF: Youtube mostanaban nalatok is lassu? Probaltam letolteni flv fajlt a www.keepvid.com-al es neha (egyre surubben) 10-15Kb a letoltes sebessege, van ugy hogy 180Kb(ritkan). Online nezni lehetetlen, 3 masodpercenkent "karikazik". Most akkor az Invitel kedves hozzam, vagy a Youtube kezd tulterhelodni?

ha uzemeltettel mar hasonlo kaliberu siteot, lathattad mennyi problema van...

ha nem, par tavpont:
- a tartalmat el kell osztani a content gepeid kozott
- normalis (szoftveres) LB modszer kell (hint egy urlen ered el a tartalmat, de sok gep fizikailag)
- sok kis gep, de skalazni azert kell ahogy nosz => karban kell tartani oket
- kulfoldon nagyon draga a savszelesseg (stage6nal teljesen realis az az 1M$ csak a savra)

es meg rengeteg problema. :)

amugy nekem teljesen jo a youtube (berelt vonal), bar attol is fugg, hogy egy videot mennyire neznek (ha tobben nezik,
tobb helyen van meg, jobban eloszthato a terheles), es hogy epp melyik content gepet fogod ki

Na nem kötöszködés, de:

normalis (szoftveres) LB modszer kell

Egy normális load balancer nem szoftveres, hanem hardveres. Ahogy egy cluster oktatáson mondták, a scalable apache cluster a szegény ember load balancer -je (vagy valami nagyon hasonló volt).

- a tartalmat el kell osztani a content gepeid kozott

SAN, NAS?

--
http://laszlo.co.hu/

kotozkodjunk, szeretek :-)

a hw loadbalancer ott esett ki, mikor kontinensek kozotti dolgokrol beszelunk. nem fogom vpnbe osszehuzni az egeszet,
es nem akarok nagyon trukkozni se. masreszt, tudsz olyan LBt, ami mondjuk a forrascim alapjan az adott ponthoz
legkozelebb levo content gepre iranyitana a kerest? lehet, hogy van ilyen, meg nem talalkoztam vele.

SAN, NAS? megint: kontinensek kozott? ISPk kozott? meresz dolog lenne. Te bevallalnad? en biztos nem.

Igazad lehet, nagyon mélyen nem gondolkodtam el a dolgokon. Szerintem az akamai -t kellene megkérdezni, hogy csinálják :)
Az adattárolásnál maradjunk a SAN -nál szerintem. Miért ne lehetne ISPk között egy-egy SAN dobozom, pl. Hitachi9990 (ez elég nagy), ami replikálni tudja az adatait másik storage -el. Így kontinensekre már szét lehet dobni a dolgot. Túl sok féle hardveres LB-hez nem volt szerencsém még, nem tudom hog tud -e olyat, amire te gondoltál. De ugye legyen egy masinánk(na jó ez is lehet redundáns), ami csak azzal foglalkozik, hogy a beérkező kéréseket a forrás IP figyelembe vételével (megállapítja, hogy melyik kontinensről jött) átirányítja azon a kontinensen lévő hardveres LB címére, ami mögött van egy pár masina meg egy storage/több. Minden kontinensen van nekünk egy ilyen. A kontinensek közötti adatreplikációt, ami a storage -eken vannak, azt meg oldják meg a storage -ek hardveresen.

--
http://laszlo.co.hu/

És azt végiggondoltad, hogy egy ilyen storage szintű tükrözés mit jelentene egy aktív-aktív clusterben, mondjuk köztük 10 ezer km távolsággal?
Teljesen használhatatlan sebességű lenne egy ilyen rendszer (főleg youtube-féle videomegosztásra :), már persze ha a használt protokollok egyáltalán képesek lennének működni rajta.

Plusz gondold bele még a "kiesik az egyik, megy a másik", "megy mindkettő, de közöttük elszakad a drót", stb. felállásokat és gyorsan rájössz, hogy ez leginkább failover clusternél lehet alkalmazható.

Cisco-nál DRP-nek hívják, amivel gyorsan le lehet kérdezni, hogy melyik border router-től mennyire van egy cím, ezt szokták használni az LB rendszerek. A gyakorlatban 98% -ban multihome-olt datacenterekben használják, de működik több datacenter között.

Storage ISP-k között: teljesen elfogadott az internetes replikáció, az összes geo cluster így működik, ahol nem volt $ kiépíteni a dedikált FC instratruktúrát. Én még csak failover clustert láttam így, de ha az alkalmazás lehetővé teszi, miért ne lehetne akár bármilyen.

had reagaljak egy helyen a fenti dolgokra is: koszonom :) mindig tanulok valamit.

mostanaban szoftveres oldalon mozgok, szerencsere van mas, aki turja a vasakat helyettem.

ket dolgot viszont azthiszem, elfelejtetek: ezek nagyon draga megoldasok. tudom, cegfuggo, hogy mi a draga, de nem hiszem, hogy
ne lehetne hasonlo rendszert osszehozni szoftveresen.

amit Laci irt fent, hogy szoftveres gep, ami az LBt csinalja, es a fizikai "pontok" mogott van a storages megoldas, az mar tok jo.

felteszem itt, hatha tudtok ebben is okosat: olcso ember storage kategoriaban mit gondoltok arrol, hogy egy normalis gepet osszerakni (nem desktop
alkatreszekbol), es iSCSI -n kiajanlani egy szoftveres tombot? mennyire jo ennek a tamogatasa (linuxon/bsdn), illetve milyen a performanciaja
es hws NAShoz kepest?

Természetesen meg lehet csinálni szoftveresen, a céleszközökön is szoftver fut, és ezt nem ironikusan mondom, hanem mert a gyártók kínálatában tipikusan ezek az eszközök szoktak legtávolabb állni a spéci switching architektúrás, akármis durva dolgoktól. Amit én láttam, abban x86 processzor volt..

Ha egy-egy pár milliós eszközt drágának tartasz, akkor nem tudom, miből finanszírozod a datacentereket egymástól földrésznyi távolságra. Ezek egyike sem az, hogy beraksz 1 gépet colocationbe itt, colocationbe ott, aztán kész a geo cluster.

De pl. egy internetes videomegosztó rendszernél sokkal célszerűbb SAN helyett adatszervereket használni, és a replikációt tartalom alapján (~ fájlszinten megoldani).

iSCSI -t kifejezetten sz*rnak tartom linux/unix rendszerek alatt és nagyon jónak windows alatt, de nem sokat foglalkozunk vele. Ami van az Solaris/ZFS, ezzel nagyon jó szervert lehet csinálni, vagy "hardveres" NAS, de azon is Solaris fut... az újabb, olcsóbb iSCSI storage-eket még csak tesztelgetjük.

Performancia teljesen rendben van, csak nem szabad elfelejteni hogy normális L2 architektúra kell alá, ha már nem kell FC fabric akkor az emberek abból az erőből ki szokták hagyni a normális switchet is + lazán ráteszik osztott hálózatra. Initiator oldalon nagyon lényeges hogy fájlokat ajánlsz ki vagy partíciókat, mindez hogyan cache-elődik, ezt a ZFS szerencsére 1:1 megoldja

A globális tartalomelosztás, -routing ahogy nézem szinte mindenhol DNS alapú irányítással kezdődik. Ezek után kerülnek load balancerekre a userek, amelyek franc se tudja milyenek.
A hardveres drága, sok esetben nehézkes, megköti az ember kezét, kevésbé lehet dinamikus, mint egy "szoftveres" megoldás pár PC-n. Utóbbinál sokkal gyorsabban tudsz valószínűleg reagálni, bonyolultabb elosztási algoritmusokat használhatsz.

SAN: nagyon csodálkoznék, ha ezek a cégek SAN-t használnának (mármint fibre channelt, vagy hasonló technológiát) a tartalom elérésére, elosztására.
Nem igazán kifizetődő, nem képes megfelelő teljesítményt adni, irdatlan drága, könnyen hibázik, nehéz bővíteni. Eszembe sem jutna...

minden komolytalansag nelkul mondtam. ha minden tartalmadrol tudod, hogy milyen surun szedik, hanyan,
foleg milyen kontinensen divik, etc, etc (szoval vezetsz ertelmes, jo statisztikat a klippjeidrol),
en eltudok kepzelni egy olyan szoftverrendszert, aminek a kliens oldalat feltelepited a content gepekre,
es azok megoldjak a felmerulo problemakat (content-replikacio, ha torolnod kell valamit, etc, etc), raadasul
emberi beavatkozas nelkul.

Én egy nagy DHT-t építenék, ahol a kulcs a tartalom valamilyen hash algoritmussal képzett lenyomata (pld. SHA), az érték meg értelemszerűen maga a tartalom.
Az, hogy a DHT-ben maguk a key:value párok hogyan, milyen szabályok szerint terjednek, replikálódnak, illetve mi alapján jutnak el hozzájuk a kliensek (pld. valamilyen decentralizált P2P megoldással, ahol a data node-ok csak a szomszédjaik tartalmáról tudnak és a rendszerben legfeljebb x. hoppal találhatók meg az adatok, vagy egy központi adatbázissal, akár osztottan is, az a felhasználás módjától, az adatmennyiségtől és még sok minden mástól függ. Rengeteg matek van emögött, ki is választhatok egy már publikált algoritmust, vagy ha okos vagyok, ki is találhatok egy újat, van mozgástér bőven.) szabadon választott.

Hardverből (ilyen persze nincs, abban is szoftver van :) ilyet megoldani meglehetősen költséges és emellett egy rém rugalmatlan rendszert kapsz.
Egyszerűbb és valószínűleg olcsóbb is általános célú megoldásokból felépíteni.

Én is olvastam korábban a google tanulmányát, hogy miért használnak PCket. Szerinted nem használnak hardveres LB -t, csak mindent szoftveresen oldalanak meg? Ezzel a példámmal kimondottan a webes alkalmazásokra gondoltam, hogy oda jobb egy hardveres LB a scalable service -ként akarjuk üzemneltetni, mint a szoftveres megoldás. Ez állításom teljesen független a Flickr -től.

--
http://laszlo.co.hu/