[openstandaarden] Een antwoord van de VTM

[Jan Claeys]

At 2003-05-09 11:09, you wrote:
> Ik vraag me af hoe Quick Time past in dit rijtje waar jullie steeds over
> gediscuteerd hebben.
> In ieder geval werkt dat op Windows en Mac 8/9/X maar ze hebben geen Linux
> versie.... De streaming is volgens mij wel MPEG 2/4 compatibel en zou door
> elke MPEG4 ondersteunende viewer moeten kunnen bekeken worden.

Het probleem is natuurlijk niet alleen het formaat, maar ook het streaming 
protocol.  (Het streaming protocol zorgt ervoor dat de inhoud vanaf de 
server tot bij de client geraakt.)

Microsoft gebruikt hiervoor meestal het eigen gesloten "mms:" protocol, maar 
er bestaat ook een goed _open_ streaming protocol: RTP/RTSP.
Client side wordt dat o.a. ondersteund door mplayer, QuickTime en RealPlayer, 
en er is ook een Winamp plugin.  Van andere players heb ik 't nog niet echt 
onderzocht.
Server-side heb je o.a. QuickTime, RealNetworks (+ de open source versie 
Helix DNA) en Live.com voor RTP/RTSP streaming.

De open source Darwin Streaming Server, waarop de QuickTime server gebaseerd 
is, is overigens beschikbaar voor MacOS X, Linux, Solaris & Windows NT.
QuickTime players maakt Apple zelf enkel voor MacOS & Windows, maar op Linux 
etc. zou je het moeten kunnen afspelen met mplayer, dacht ik?  Hoe dan ook, 
een MPEG4-over-RTSP stream _zou_ je ook met een andere player moeten kunnen 
bekijken...

Soms wordt ook HTTP gebruikt voor simpele streaming, maar dat is minder 
betrouwbaar (voor streaming dan).  Voor audio (vb. Ogg Vorbis, MP3) is het 
echter wel bruikbaar, en dan is er bijvoorbeeld IceCast om te streamen.

> Volgens mij is dit ook een goed alternatief en misschien minder
> vreemd voor heel wat webmasters. Tenslotte heeft iedereen er al eens van
> gehoord.

Net zoals ze van RealNetworks gehoord hebben, hoop ik.
Dat zijn dus minstens 2 commercieel bekende streaming servers waarmee je 
MPEG4 (of een ander meer open formaat?) zou moeten kunnen streamen over een 
open streaming protocol.

Theora (het video-broertje van Vorbis) zal ook als QuickTime en Windows Media 
codec beschikbaar zijn, maar daar zijn nu alleen nog maar beta versies van.

>Dat de servers die deze streams ondersteunen beperkt zijn tot een paar
>platformen vind ik een minder grote drempel.

Dat is inderdaad de privé-zaak van de server-beheerder, net zoals het een 
privé-zaak van de gebruiker is welk OS/software hij gebruikt.  Zolang de 
stream zelf maar in een open formaat over een open protocol beschikbaar is.

>Het probleem met Ogg op dit moment is dat ondermeer dat een webmaster die
>gevraagd wordt om streaming aan te bieden voor een site steeds met een
>dilemma zit:
>	- de streams volledig zelf verzorgen
>	- de mainstream aanleveren en ze door een provider laten streamen
>	- de mainstream en de streaming volledig uitbesteden
>
>Hoe meer hij zelf doet hoe meer er eventueel ook marge overblijft om er
>zelf ook beter van te kunnen worden (in geval van externe webmaster) of
>het zelfde geld voor iets anders uit te kunnen geven (in geval van
>interne webmaster).

De VRT doet dit momenteel ook niet volledig zelf vziw?

>Als je dan voor zo'n webmaster met van die "afschrikwekkende
>hersenbrekers" aankomt of van programma's waarvan voor hem de support veel
>te vaag is dan durft hij dit niet uit te proberen.....

Apple, RealNetworks en Live.com bieden commerciële support voor streaming.
En er zullen er nog wel andere zijn (misschien zelfs in België?).

>Ik herrinner me nog eens een uitspraak..... "Er is nog niemand ontslagen
>omdat hij voor IBM heeft gekozen".... Dit is op zijn minst de laatste
>jaren ook meer en meer de houding die een ICT-aankoper heeft tov
>Windows... "Er is nog niemand ontslagen omdat hij voor MicroSoft heeft
>gekozen"....
>
>Stel je maar eens in de plaats van een (niet verder dan Windows kennende)
>webmaster die dit voor zijn baas/opdrachtgever moet uitwerken.....
>Welke beslissing zou jij dan nemen ?

Ik denk dat vooral ook onder tijdsdruk zo'n beslissingen genomen worden, 
als je geen tijd hebt om alle opties te onderzoeken...

-- 
Jan Claeys

"Be strict when sending and tolerant when receiving."
RFC 1958 - Architectural Principles of the Internet - section 3.9