Html5 krijgt toch geen video en audio

testbeeld

Gepubliceerd: Vrijdag 3 juli 2009
Auteur: Jasper Bakker

De veelgeroemde video- en audio-mogelijkheden van html5 komen toch niet in de officiële specificatie. Bij gebrek aan een standaard blijven meerdere plugins dus de norm.

Toon volledig artikel

debert op Vrijdag 3 Juli 2009 12:42

image

Dat leek me nu net het enige zinvolle van html5. Laten we dan maar stoppen bij 4.

Sheynberg op Vrijdag 3 Juli 2009 20:17

image

Em, wat dacht je van HTML5 Canvas? Kijk bijvoorbeeld eens naar deze 3D shooter, die is helemaal gemaakt in Canvas. Of deze stock grapher. Is geen Flash of Silverlight aan te pas gekomen.

NULL op Vrijdag 3 Juli 2009 23:38

image

Je gaat me niet vertellen dat je van die dingen onder de indruk bent? HTML5 is sowieso een farce. Eindelijk hadden ze de mogelijkheid om alle legacy-drek van HTML4 eens op te ruimen en er meteen een XML-standaard van maken. En tevens Javascript 1.x eens naar zijn graf kunnen dragen, in overgaan op (ten minste) Javascript 2, maar nog liever een fatsoenlijke taal (Java ligt voor de hand)

Daarnaast is Canvas toch ook maar een amateuristische gimmick. PC's hedentendagen kunnen 3D-dingen doen waar je "wow" van zegt. Maar de WHATWG beperkt zich tot armtierige 2D-graphics. En dan nog niet eens SVG.

De WHATWG moet zich schamen.

Endure op Zaterdag 4 Juli 2009 15:48

image

Je vind java fatsoenlijk?
grappig

NULL op Zondag 5 Juli 2009 01:42

image

Het minst slechte alternatief ja.

Endure op Zondag 5 Juli 2009 01:59

image

Tja tis maar wat je vind.

Maar zover ik het weet is java op elk OS gewoon niet bepaald iets wat je wil gaan promoten.

Peter ... op Zondag 5 Juli 2009 10:32

image

Heb je daar rationele onderbouwde redenen voor? Of was het toevallig voor jouw een keer traag en heb je het sindsdien nooit meer een kans gegeven?

Bolleke op Zondag 5 Juli 2009 21:31

image

Ik denk niet dat Endure de enige is die iets tegen java heeft. Het is relatief traag en de user-interface zuigt. IMHO.

Peter ... op Zondag 5 Juli 2009 22:57

image

Als ik kijk naar een product als Eclipse, kan ik het niet met je eens zijn dat de UI zuigt. Dat het traag is, is volgens mij een logisch gevolg van een geïnterpreteerde taal. Inderdaad wel een nadeel.

Java is misschien niet perfect, maar het is naar mijn idee wel de meest complete multi-platform taal op dit moment.

Sheynberg op Zondag 5 Juli 2009 23:24

image

Als ik kijk naar een product als Eclipse, kan ik het niet met je eens zijn dat de UI zuigt.
Eclipse gebruikt een GUI-toolkit die niet standaard in Java zit. Het is ontwikkeld door hen zelf, toen het project nog van OTI en IBM was. Die toolkit, de 'Standard Widget Toolkit' is inderdaad een stuk gelikter dan het gros van de Java applicaties -- die gebruiken veelal de standaard widget toolkits, 'Abstract Window Toolkit' en 'Swing'. Ook hebben de mensen van Eclipse er nog een laag tussen moeten bouwen, 'JFace'. Het kost dus nogal wat extra code om een Java-applicatie er goed uit te laten zien. Je kunt je afvragen hoe 'typisch Java' zo'n applicatie als Eclipse is.

Meer info (JavaWorld.com)

Peter ... op Maandag 6 Juli 2009 09:51

image

Ik ben met je eens dat AWT en Swing zuigen. Maar SWT ziet er gewoon goed uit. Of je het standaard Java wil noemen? Nee, misschien niet. Maar Visual Studio gebruik ik ook met de nodige uitbreidingen, dus waarom moet Java ineens afgerekend worden op het feit dat het niet standaard is?

Maar goed, ik laat het hier maar bij. Ik heb eigenlijk geen idee waarom ik Java aan het verdedigen ben, want ik doe er niks mee op het moment. :)

Bolleke op Maandag 6 Juli 2009 18:49

image

:) Ik ook niet, en zit er ook zeker niet diep genoeg in dat ik al die toolkits ken... maar om te vergelijken, GTK vind ik ook ruk, QT daarentegen niet. Dit onder het motto 'het kan dus wel' ;)

Sheynberg op Maandag 6 Juli 2009 20:39

image

Helemaal mee eens. Een Java app met een SWT GUI laad je niet zomaar vanaf een webpagina. Als je het dan toch moet downloaden, dan gaat mijn voorkeur uit naar C++ icm Qt of GTK.

Sheynberg op Zondag 5 Juli 2009 21:42

image

Heb je daar rationele onderbouwde redenen voor?
Haha, kijk even aan wie je dat vraagt.

Enfin, ik hou ook niet van Java. Het is langzaam als stroop, je hebt vaak geen enkel idee waar het mee bezig is, en de user interface is lelijk en niet uniform.

Ik zeg echter niet dat het op elk platform langzaam is. Op Solaris is het best OK.

Endure op Zondag 5 Juli 2009 23:54

image

traag, instabiel, geen correcte fout afhandeling methodes.
en het ziet er gewoon totaal niet uit, het is niet meer van deze tijd.

Peter ... op Maandag 6 Juli 2009 09:40

image

geen correcte fout afhandelingJij vind try catch blokken geen correcte foutafhandeling? Ja ja.

debert op Maandag 6 Juli 2009 10:39

image

HTML5 canvas is inderdaad een mooie feature.

TheReactor op Vrijdag 3 Juli 2009 12:43

image

Waar is de rest van het artikel gebleven?

Jasper Bakker [red. Ww] op Vrijdag 3 Juli 2009 14:01

image

Ai, ik merkte bij het invoeren dat img met < > eromheen in de Webwereld-editor gelijk handig een image-optie opleverde, maar zag dat dit niet gold voor video en audio.
Kennelijk gaat dit bij sommige nieuwe browsers, zoals Safari 4 (nu hier gecheckt) niet goed. Firefox (3.0) negeert de voor hem onbekende tags video en audio, net als IE8 en Chrome. Vandaar dat ik/we eerst niet begrepen wat de klacht was.
Excuses!
En weer wat geleerd, over html, standaarden en browsers.

Peter ... op Vrijdag 3 Juli 2009 14:51

image

Ga je het nog oplossen dan?

Jasper Bakker [red. Ww] op Vrijdag 3 Juli 2009 15:16

image

Eh, heb ik juist eerst opgelost, en toen die reactie hier in het forum gegeven.
:)
Of is het bij sommigen nu nog niet goed qua weergave? Welke browsers en versies dan?

piekhaar op Vrijdag 3 Juli 2009 15:22

image

Ff 3.5 heel stuk verdwenen.

Anonymous Coward op Vrijdag 3 Juli 2009 15:42

image

Dat krijg je met een browser die niet standaards compatibel is.
;-)

piekhaar op Vrijdag 3 Juli 2009 16:18

image

En dat is een reactie van iemand die niet helemaal compatibel is. ;-)

kernel op Vrijdag 3 Juli 2009 16:40

image

Dat krijg je als een pagina niet aan de standaarden voldoet, zegt dat het XHTML strict is, maar toch maar liefst 164 Errors en 43 warning(s) genereert.

Anonymous Coward op Vrijdag 3 Juli 2009 21:45

image

Vreemd dat deze gemind wordt. WebWereld zou er goed aan doen om in dit geval XHTML 1.0 Transitional te kiezen. Dat scheelt wat in de formele fouten. Browsers die nogal fundamentalistisch omgaan met XHTML (wat een nogal strenge standaard is), gaan minder gek gedrag vertonen met een transitional doctype.

Maar uiteindelijk is het gewoon best wel dom om pagina's met zoveel fouten te genereren. Dat gekke issue laatst met die grijze vlakken, da's praktisch niet te debuggen op een pagina vol markupfouten.

Bolleke op Vrijdag 3 Juli 2009 17:03

image

"Grappig" bedoeld, maar je moet entities escapen, anders weet je dat je het risico loopt dat een browser er iets raars mee doet. <bla> is een tag, en je mag er niet vanuit gaan dat een browser hem "dus" sec weergeeft omdat het "toevallig" een onbekende tag is.

Vincentlaborant op Vrijdag 3 Juli 2009 19:36

image

Zeker weer een MS fanboy

Bolleke op Vrijdag 3 Juli 2009 17:16

image

@jasperB: "intentie om de &lt;video&gt;-tag" ... de vishaakjes moet je entities van maken.

vinylat45 op Vrijdag 3 Juli 2009 12:52

image

Voordeel van HTML5 is de canvas tag!

Tekenen met vectoren in de browser :)

Husky op Vrijdag 3 Juli 2009 12:53

image

Dit artikel klopt van geen kant. De <video> en <audio> tags blijven gewoon in HTML5, maar er wordt geen standaard codec gespecificeerd aanbevolen in de standaard, omdat de browsermakers het daar niet over eens konden worden. Apple wil H264, terwijl de rest OGG Theora willen. Microsoft houdt zich zoals gebruikelijk afzijdig en heeft geen commentaar op dit onderwerp.

Nogmaals: de multimediamogelijkheden blijven gewoon in HTML5 aanwezig.

TheReactor op Vrijdag 3 Juli 2009 13:30

image

Moet er eigelijk wel een standaard codec gespecificeerd worden? <IMG> ondersteunt toch ook verschillende formaten? Natuurlijk is het wel handig als alle browsers in elk geval een aantal formaten zal ondersteunen. Dat lukt vast wel. h.264 begint behoorlijk dominant te worden dus ik denk dat je daar straks een eind mee komt - zeker als op de achtergrond toch Media Player of Quicktime of MPlayer/VLC of wat de open bron browsers ook willen - feitelijk de video afspeelt.

Anonymous Coward op Vrijdag 3 Juli 2009 14:11

image

Bij <img> heeft ons dat de halfbakken ondersteuning voor PNG-transparantie in Internet Explorer opgeleverd. Zou wel zonde zijn als het nu weer zes jaar of langer moet duren voordat het allemaal goed werkt.

Rijk op Vrijdag 3 Juli 2009 14:07

image

Inderdaad, gevalletje 'verkeerd begrepen'. Het bericht klopt gewoon niet. De elementen (niet tags...) 'video' en 'audio' blijven gewoon in de HTML5 spec, en verplichte codecs stonden er al in niet in. Nu staat er ook niet meer dat er gestreefd wordt een verplichte codec te vinden. Dus net als met het IMG element is er geen verplichte ondersteuning voor bepaalde video-formaten. Dus als je het Video-element wilt gebruiken en alle browsers wilt bereiken, moet je vooralsnog zowel een H.264 als een Ogg bestand aanleveren. Dat kan best, zie 'Video for Everybody'.

Husky op Vrijdag 3 Juli 2009 14:27

image

En waarschijnlijk ook nog wel een tijdje een FLV voor mensen die alleen (een oudere versie van) Flash hebben. Gelukkig zijn er al een aantal oplossingen die het wat makkelijker maken, zoals Video for everbody:

http://camendesign.com/code/video_for_everybody

Puist ☺ op Vrijdag 3 Juli 2009 15:59

image

Ergo, er is niks aan de hand. De programmeur kan gewoon de tags gebruiken.

Husky op Vrijdag 3 Juli 2009 18:41

image

Nee, zo simpel is het ook weer niet. De programmeur kan die tags wel gebruiken, maar kan niet één enkel filmpje aanbieden in een formaat, maar zal op z'n minst twee formaten aanbieden (H264 en OGG) zodat het zowel werkt vor Safari als Firefox. En waarschijnlijk voorlopig ook nog een Flash FLV bestand, zodat IE ook nog blijft werken (met een workaround omdat IE vooralsnog geen <video> gaat ondersteunen).

SED. op Vrijdag 3 Juli 2009 13:04

image

Kortom, Apple frustreert weer eens vooruitgang ;)
Microsoft houdt zich terecht afzijdig bij dit bitchfight
En de rest loopt op standaarden vooruit die het niet halen.
Het W3C remt elke innovatie weer en durft weer geen standpunt in te nemen.
Poolse landdagen daar...


xehrbagiz op Vrijdag 3 Juli 2009 13:15

image

Microsoft houdt zich terecht afzijdig bij dit bitchfight
... totdat er een standaard is die ze vervolgens saboteren door 'm niet te implementeren, of zo te implementeren dat ie problemen voor de anderen oproept...

Peter ... op Vrijdag 3 Juli 2009 14:01

image

Microsoft wacht ongetwijfeld tot iedereen er uit is voordat ze dwars gaan liggen. Net als ze doen bij embedded fonts.

Husky op Vrijdag 3 Juli 2009 14:30

image

Apple heeft zich duidelijk uitgesproken over waarom ze Theora niet willen implementeren: ze zijn bang gesued te worden vanwege de patenten die er potentieel op Theora van toepassing zijn.

Microsoft daarentegen doet helemaal niks. Ze geven nergens commentaar op, denken niet mee over de specificatie en frustreren zo het proces omdat 75% van de gebruikers nog steeds IE gebruikt als browser. MS hoopt natuurlijk dat die strategie vruchten afwerpt zodat Silverlight de standaard wordt voor nieuwe webapplicaties, en niet HTML5.

Gustaaf op Vrijdag 3 Juli 2009 19:35

image

Als je het bericht leest vind Google dat Ogg/Theora nog niet de vereiste kwaliteit levert, dus je hebt slechts half gelijk. Met ogg/Theora zou de kwaliteit van video niet vooruit gaan, het zou alleen iets makkelijker worden om het te implementeren.

Vincentlaborant op Vrijdag 3 Juli 2009 19:37

image

[cynisch]het is deze bitchfight en niet dit bitchfight[/cynisch].

Anonymous Coward op Vrijdag 3 Juli 2009 13:07

image

Beetje opgeklopt dit. Microsoft gaat <video> en <audio> waarschijnlijk gewoon via een ActiveX-control implementeren (Windows Media Player aanroepen). Zolang er een directshow-filter voor OGG is, speelt dat dus gewoon af. Idem voor het Apple-platform. OGG hoeft helemaal geen default te worden in Quicktime.

Verder kan Theora 1.1 behoorlijk concurreren met h264 dus het argument van YouTube om het niet te ondersteunen hangt nu vooral op het feit dat ze een hoop h264 legacy hebben. Dat ga je niet even voor je lol transcoden.

Ik ben wel benieuwd wat er gebeurt wanneer Wikipedia straks vol staat met OGG-content die door iedereen behalve Firefox halsstarrig wordt geweigerd vanwege het klassieke Not Invented Here-syndroom. Of hoe YouTube gaat reageren op de aankondiging van de h264-patenthouders om vanaf 2010 (of was het 2011) licentievergoedingen te gaan vragen voor elke uitgezonden h264-stream.

Voorlopig vlak ik Theora nog niet uit als serieuze kanshebber om straks de webvideostandaard bij uitstek te worden. Misschien niet formeel vastgelegd, maar wel de facto.

Gregorius op Vrijdag 3 Juli 2009 13:16

image

Ik ben wel benieuwd wat er gebeurt wanneer Wikipedia straks vol staat met OGG-content die door iedereen behalve Firefox halsstarrig wordt geweigerd
Persoonlijk denk ik dat de (enige) reden zal zijn waardoor Ogg Theora/Vorbis uiteindelijk zal doorbreken.
Nu maar hopen dat Wikipedia niet zal toehappen op mogelijke aanbiedingen voor gratis/"gesponsorde" licenties voor vendorafhankelijke/gepatenteerde codecs...

Husky op Vrijdag 3 Juli 2009 14:33

image

Dat zal niet zo snel gebeuren. Alle technologie die gebruikt wordt om Wikipedia te draaien *moet* vrij en open zijn, dus een H264 of Silverlight-achtige technologie zie ik zo snel nog niet verschijnen op Wikipedia.

Rijk op Vrijdag 3 Juli 2009 14:10

image

Niet alleen Firefox 3.5 ondersteunt Ogg. Ook Chrome 3 en de volgende Opera (na Opera 10.0) zullen Ogg-ondersteuning ingebouwd hebben. En Mac-bezitters kunnen inderdaad zelf Ogg-ondersteuning toevoegen aan Quicktime, en daarmee ook aan Safari 4.

CAPSLOCK2000 op Vrijdag 3 Juli 2009 14:15

image

Wikipedia + Firefox + VideoBay lijkt mij een ijzersterke combo die bergen kan verzetten.

Microsoft bemoeit zich niet met de discussie omdat ze de video tag helemaal niet zien zitten, ze willen liever dat er Silverlight gebruikt wordt.

Apple wil perse H264 tot standaard verheffen omdat ze daar al support voor hebben in al hun recente hardware. Daar hebben ze flink voor betaald, dus ze gaan het er door proberen te rammen.

Google zou hier een hoofrol kunnen spelen. Als Google (en dus YouTube) een keuze maakt, dan wordt dat de facto de standaard. Helaas zit Google met een vervelende keuze. Ogg Theora is met het oog op de toekomst aantrekkelijker, maar momenteel is H264 iets beter. Gezien de gigantische hoeveelheid video op YouTube is dat kleine verschil voor Google een verschil van vele miljoenen.

Anonymous Coward op Vrijdag 3 Juli 2009 14:24

image

Verder kan Theora 1.1 behoorlijk concurreren met h264
Heb je daarvoor aantoonbare onderbouwing ?
Bijvoorbeeld een vwergelijkingstest ?

Als Theora van gelijke kwaliteit bijvoorbeeld 10% groter is dan h.264 video dan kost het Youtube al miljoenen.

Peter ... op Vrijdag 3 Juli 2009 14:31

image

people.xiph.org...comparison.html

Anonymous Coward op Vrijdag 3 Juli 2009 15:04

image

Ok, maar die ene vergelijking van 1 video gaat over een animatie film en dat geeft echt extreem andere uitkomsten dan realistische videobeelden.
Dat is zoiets als GIF en JPEG vergelijken.

Peter ... op Vrijdag 3 Juli 2009 15:12

image

Je vroeg of Theora kon concurreren met h.264. Dat heb ik beantwoord. Theora doet het steeds beter. Of het al beter is dan h.264 weet ik niet, maar dat was ook niet de vraag.

Verder kan Theora 1.1 behoorlijk concurreren met h264De link lijkt aan te tonen dat Theora behoorlijk kan concurreren met h.264.

Anonymous Coward op Vrijdag 3 Juli 2009 15:28

image

Probleem is dat dat zo lijkt.

De vergelijking bijvoorbeeld laat niet zien dat de Youtube bitstrems 128kB AAC geluid meekrijgt en de Theora stream 64kb OGG vorbis. Dat is al 10%-20% verschil op de overige videostream.

Verder is er potentieel een groot verschil in key framerates tussen de voorbeeld video van Xiph en die van Youtube. Meer key frames maken bijvoorbeel buffering eenvoudiger maar key frames zijn veel minder compressable dan de tussenliggende p-frames.

De maker stelt een keyframerate tegebruiken van 250. Dat is maar 1 keyframe per 10 seconden waar bijvoorbeeld Youtube zovel ik kan vinden werkt met keyframe rates van 30-60.

Vreemd dat in deze test gekozen is om een opvallend slechtere verschillende keyframerate te gebruiken op het element dat in videocompressie het minst te verkleinen is.

Peter ... op Vrijdag 3 Juli 2009 19:41

image

Als je het allemaal toch al zo verschrikkelijk goed weet, waarom dan:
Heb je daarvoor aantoonbare onderbouwing ?

Anonymous Coward op Vrijdag 3 Juli 2009 20:51

image

Omdat ik geen objectieve vergelijkingen ken en die zoek ik.
Als iemand een vergelijking van de Theora developer zelf opgeeft zoals jij dan voel ik meteen een kriebel en kost het maar een paar minuutjes om uit te vinden wat daar mis mee is.

Ik weet er wat van maar de info over de audio bitrate en keyframe rates heb ik even snel gebinged.

Peter ... op Vrijdag 3 Juli 2009 21:46

image

Helder. Bedankt voor de toelichting.

Anonymous Coward op Vrijdag 3 Juli 2009 15:21

image

Beide codecs hebben toch hetzelfde bronmateriaal voor hun neus? Dan lijkt de vergelijking me eerlijk. Sowieso ga ik dit verhaal zelf nog testen met afleveringen van mijn favoriete televisieserie. Ik verwacht echter niet dat er iets gaat afwijken omdat dit soort 3D-animatie grotendeels dezelfde compressiekarakteristieken heeft als kwalitatief hoogwaardige live action.

Anonymous Coward op Vrijdag 3 Juli 2009 15:39

image

Beide codecs hebben toch hetzelfde bronmateriaal voor hun neus? Dan lijkt de vergelijking me eerlijk

Nee want
* Animatievideo is veel simpeler dan realistische standaard beelden en dat is weer veel simpeler dan realistisch beelden met veel beweging/actie. Hoe lastiger de beelden hoe meer stress voor een videocodec om een goede bitrate te handhaven.
* De audio codec gebruikt verschillen en ook de bitrates daarvan. Hoewel de video's even groot zijn bevat de Youtube h.264 video een veel grotere geluidsstream en daarom dus ook kleinere videostream en alleen de video stream wordt vergeleken
* De keyframerate van de voorbeeld video is belachelijk slecht. 1 keyframe per ruim 10 seconden. Dat is misschien voor compleet binnegehaald video not wel net acceptabel maar voor progressive downloadende video (zoals youtube) heel slecht.

Een eerlijke vergelijking verwacht ik ook niet op de Xiph pagina's.
Die ontwikkelen Theora en hebben duidelijke belangen.

Sowieso ga ik dit verhaal zelf nog testen met afleveringen van mijn favoriete televisieserie

Dat zou te waarderen zijn maar neem dan een hoog kwaliteits brommateriaal (bijvoorbeeld een echte DVD9) en liefst een realistische niet al te donkere scene met behoorlijk bewegende beelden.
Gebruik een gelijke bitrate audio.
Gebruik een gelijke keyframerate bij zowel h.264 als Theora onder de 60

Anonymous Coward op Vrijdag 3 Juli 2009 15:59

image

Ik heb Star Trek Enterprise op DVD. Die is in tegenstelling tot veel andere trekkies niet interlaced en zo'n aflevering is qua omvang nog wel te behappen. Volledigheidshalve zal ik ook een stukje Wall-E en een aflevering van The Simpsons vergelijken (allemaal van originele DVD's natuurlijk). Het resultaat is waarschijnlijk pas bekend als dit topic al lang gezakt is, dus ik kom er binnenkort op terug onder een volgend on-topic artikel hier.

Husky op Vrijdag 3 Juli 2009 18:43

image

Zou erg interessant zijn, ware het niet dat DVD's natuurlijk ook al een keer geëncodeerd zijn, namelijk in MPEG2. Het mooie van de vergelijking met Big Buck Bunny is juist dat ze daar het originele 'raw' formaat konden gebruiken, omdat van de hele film alle (lossless) pngtjes beschikbaar zijn. Maar hoge kwaliteits lossless filmmateriaal is moeilijk te vinden.

piekhaar op Vrijdag 3 Juli 2009 17:37

image


Nee want


Ze hebben wel beiden hetzelfde filmpje, het is alleen een anim, maar voor beiden hetzelfde.

Anonymous Coward op Vrijdag 3 Juli 2009 19:34

image

Je leest blijkbaar alleen de eerste twee woorden van een reactie ???

Peter ... op Vrijdag 3 Juli 2009 19:43

image

Wat Piekhaar waarschijnlijk bedoelt is dat h.264 verschrikkelijk slecht is in het comprimeren van Animatie.

Anonymous Coward op Vrijdag 3 Juli 2009 14:38

image

Zie hier.

Peter ... op Vrijdag 3 Juli 2009 14:49

image

Sorry, ik was je net voor. ;)

Anonymous Coward op Vrijdag 3 Juli 2009 14:53

image

Maar ik heb lekker wel een plusje meer.. voor dezelfde link. ;-))

Peter ... op Vrijdag 3 Juli 2009 14:56

image

Show off. ;)

Puist ☺ op Vrijdag 3 Juli 2009 16:00

image

opgeteld nu niet meer. ;-)

Bolleke op Vrijdag 3 Juli 2009 14:15

image

Ik snap eigenlijk ueberhaupt niet zo goed wat het probleem is. Het hele punt van die <video> tag leek mij juist dat je als bouwer niet meer hoeft te meuken met allerlei plugins/fixes/workarounds/browserchecks, maar gewoon <video src="film.mpeg"> of <video src="film.wmv"> of wat voor formaat ook opgeeft. Het is dan aan de browser om te zorgen voor een werkende plugin voor dat mimetype, en als die er niet is een linkje van het eoa aan te bieden. Inderdaad, precies zoals bij <img> ook het geval is.

Ik kan nu ook een .tiff ofzo opnemen als plaatje, en dan weet ik van tevoren dat het gros van de bezoekers het niet kan zien. Moet ik toch zelf weten? Ik ben eigenlijk als ik erover nadenk mordicus tegen het opleggen van een formaat omdat er altijd mensen gaan zijn die liever iets anders gebruiken. Dus alles overziend is het eigenlijk een mooie dag voor HTML5 :)

Husky op Vrijdag 3 Juli 2009 14:34

image

Spreek je jezelf niet een beetje tegen? Je zult toch een formaat moeten opleggen als je wilt dat iedereen een videootje kan bekijken dmv de <video> tag?

Bolleke op Vrijdag 3 Juli 2009 15:48

image

Nee, want dat is de bedoeling niet. De bedoeling is dat de bouwer van de pagina op 1 manier kan zeggen "dit is mijn video", en het aan de browser overlaat hoe en waarmee-ie dat weergeeft. Ik wil ook helemaal niet dat iedereen de video kan bekijken; er zijn vast mensen die bewust helemaal geen plugins installeren omdat ze het irritant vinden als er opeens video's gaan afspelen op een pagina. Moet je die mensen dan dwingen toch te kijken? Dat lijkt me niet. Die krijgen dan vanzelf wel de melding "hier had een video kunnen staan, klik hier om 'm te downloaden", wat precies is wat ze willen.

Cloverfield op Vrijdag 3 Juli 2009 17:22

image

Dat gaat nergens over. Zomaar wat doen en dan afwachten wie het wel en niet ziet... daarvoor heeft men standaarden in het leven geroepen.
Wij spreken af dat er op het web gecommuniceerd wordt via html4, dan zou iedereen op wat voor browser ook, het zelfde moeten zien.
Dat gebeurt ook met de video tag. Iedereen kan het zien, ongeacht welke plugins men heeft.

En tuurlijk ligt Apple weer dwars. En microsoft (met hun silverlight). Eigenlijk hadden ze die open standaarden er gewoon doorheen moeten drukken.

Het is te hopen dat met FF3.5 iedereen aan de ogg video gaat, dan komen de andere ook wel.

Bolleke op Vrijdag 3 Juli 2009 17:32

image

Zomaar wat doen en dan afwachten wie het wel en niet ziet... daarvoor heeft men standaarden in het leven geroepen.
Nee, het is niet "zomaar". De video- en audio-tags ondersteunen nou juist het opgeven van meerdere alternatieven. De standaard hier is dat je specifiek aangeeft dat het om video (of audio) gaat, zodat de user-agent daar op een toepasselijke manier op kan reageren. En dat kan de melding zijn dat de plugin er niet is. Da's net zoiets als zeggen dat alle browsers alleen nog maar GIF voor plaatjes moeten ondersteunen, dat slaat toch ook nergens op?

Dat gebeurt ook met de video tag. Iedereen kan het zien, ongeacht welke plugins men heeft.
...en daarom ondersteunt het alternatieven? Nee, dat lijkt me een onjuiste voorstelling van zaken. <video> is net als <img> - de gebruiker moet bepalen of-ie een browser gebruikt die het ondersteunt. Of wou je ook afdwingen dat text-only browsers toch videofilmpjes moeten afspelen om standaards-conform te zijn? Ik ben het hier echt principieel mee oneens :)

Als je user-agent een plaatje niet kan of wil tonen is er de alt-text. Door het gebruik van video- en audio-elementen (ipv allerlei wazige javascripts die generieke objecten uitschrijven waar god-weet-wat in kan zitten) kan een browser die dat type niet kan/wil afspelen daar iets nets mee doen. Bijvoorbeeld een downloadlink of een andere melding.

What's next? Een <pdf>-tag voor PDFjes? Een <office>-tag voor een office-document? En dan ruzie maken over of dat ODF of OOXML moet zijn?

Sheynberg op Vrijdag 3 Juli 2009 19:51

image

Uit het artikel:
Hij meldt dat Apple weigert de open source video-codec Ogg Theora te implementeren als default in zijn Quicktime-software. Apple's webbrowser Safari gebruikt, net als iTunes, Quicktime voor het afspelen van multimedia-content. De Mac-maker beroept zich erop dat er geen hardware-ondersteuning is voor Theora, en dat er een onzekere toekomst voor is vanwege patentenclaims.

Google heeft H.264 en Ogg Theora wel geïmplementeerd in zijn browser Chrome, maar kan de codelicentie voor eerstgenoemde niet bieden aan distributeurs van de open source-variant Chromium. Verder meent de internetreus volgens Hickson dat de kwaliteit per bit van Theora nog niet geschikt is voor het massaverkeer dat YouTube nu afhandelt. Die videosite die Google in 2006 heeft gekocht, gebruikt Flash van Adobe (die daarvoor in 2005 Macromedia overnam).

De oorspronkelijke QuickTime-codec vormde de basis voor MPEG-4. H.264 is ook een MPEG-4 formaat en wordt al jaren ondersteund in QuickTime. QuickTime-bestanden (.mov, .qt, .mp4) zijn nu enkel nog containerbestanden, de standaard codecs zijn MPEG-4. (bron)

Door middel van een plug-in kun je in QuickTime ook Ogg Theora gebruiken als codec. (link)

H.264 is een open licensed standaard, dat wil zeggen dat iedere ontwikkelaar de encoders en decoders voor het formaat mag inbouwen in software en hardware. Wel moeten daarvoor, in bepaalde landen, licentiekosten betaald worden aan MPEG-LA. (bron)

YouTube gebruikt geen Flash-video, het presenteert de video alleen in een Flash-wrapper. De video zelf is ge-encodeert met h.264.

Anonymous Coward op Vrijdag 3 Juli 2009 20:16

image

Wel moeten daarvoor, in bepaalde landen, licentiekosten betaald worden aan MPEG-LA

Ik heb geruchten gehoord dat die licentievergoeding gaat veranderen binnenkort, en dat daarna voor elke stream betaald moet gaan worden. Wat er echt van waar is weet ik niet, maar het gonst wel zo links en rechts.

Sheynberg op Vrijdag 3 Juli 2009 20:37

image

Broodje aap. De standaard wordt gebruikt voor BluRay en HD-DVD's, voor televisie-kastjes voor kabel en digitale etherontvangst, in HD-camcorders, online video in de iTunes Store (en YouTube en Hulu), in software als Adobe Flash Player, in spelcomputers en telefoons, etc etc.

De industrie zou zo'n verandering in de licentievergoeding nooit toelaten. Daarnaast zou MPEG-LA zich daarmee alleen maar in de vingers snijden, ze willen immers dat het de standaard voor alles wordt.

Bolleke op Vrijdag 3 Juli 2009 21:27

image

Tja, een altijd aanwezig risico met dit soort standaarden. Zal ws. wel loslopen, maar de angst is begrijpelijk.

Anonymous Coward op Vrijdag 3 Juli 2009 21:50

image

Ik heb werkelijk geen idee. Het is ook maar een gerucht, dat ik hier heb opgepikt. Ik schat MPEG-LA wel zo in dat het waar zou kunnen zijn..

johnnymast op Zaterdag 4 Juli 2009 02:34

image

Ik vind dit de grootste onkul ooit op dit gebied. Dat niet om deze ruzie maar omdat bijna elke browser behalve natuurlijk ... IE ... All audio en video voor zogenoemd html5 ondersteund dus het is het een hoop veloren tijd als er niet een overeenkomst komt. Misschien ruimte voor een nieuwe opensource codac dat voor alle browers toegankelijk is ?. Mischien komt er dan ook wel wereld vrede

Anonymous Coward op Zaterdag 4 Juli 2009 16:39

image

Theora is een open source codec die voor iedereen toegankelijk is. Slechts het vermoeden dat er misschien ooit wel eens iemand iets over een patent zou kunnen gaan roepen weerhoudt Apple er blijkbaar van om het te implementeren. Softwarepatenten == evil!

Mimamo op Zaterdag 4 Juli 2009 11:03

image

En hier zien we nu hoe een mooi innovatief idee om zeep is geholpen door...

softwarepatenten!

Om te kunnen reageren, dient u ingelogd te zijn.

Loading Poll

Peiling

Loading Poll

Video: Sony toont compacte camera (video)

Verleden nieuws