Het grote HTML5 topic

[Bosmonster]

Peter schreef op donderdag 13 januari 2011 @ 23:34:
[...]

http://www.whatwg.org/spe...dom-navigator-canplaytype

Je mist het punt. Het kunnen detecteren is het probleem niet.

[NMe]

LauPro schreef op vrijdag 14 januari 2011 @ 02:45:
[...]

[...]
Niet waar dus, men verwacht Q1 2011 al de eerste chips op de markt, dan is het een kwestie van prototypes maken en goed testen, daar zal Google vast wel vol op inzetten. Als ze de multimediamarkt hebben dan is de weg open.

Verder is die hardware niet zo spannend, er komt geloof ik o.a. ogg e.d. in. Daar zijn al jaren chips van op de markt, wat dingen bij elkaar gooien en software maken en klaar. Hebben ze nog geen 6 maanden voor nodig bij Google schat ik.

Je zegt tot twee keer toe "bij Google". Google is al over naar WebM. Apple nog niet, en dat zie ik ook nog even niet gebeuren. Microsoft is nog maar de vraag. En als Google om wil maar bijvoorbeeld een HTC geen WebM-chip inbouwt zijn we er nog niet.

Bosmonster schreef op vrijdag 14 januari 2011 @ 08:37:
[...]

Je mist het punt. Het kunnen detecteren is het probleem niet.

Klopt, het is de oplossing voor het niet kunnen renderen van video die je browser zelf niet kent. De designkeuze waarin je al dan niet voor lief neemt dat je gebruikers iets niet zomaar kunnen afspelen hoort niet bij de browsermaker te liggen maar bij de webdeveloper (en diens leidinggevende).

[ Voor 22% gewijzigd door NMe op 14-01-2011 09:57 ]

[Bosmonster]

NMe schreef op vrijdag 14 januari 2011 @ 09:54:
[...]

Klopt, het is de oplossing voor het niet kunnen renderen van video die je browser zelf niet kent. De designkeuze waarin je al dan niet voor lief neemt dat je gebruikers iets niet zomaar kunnen afspelen hoort niet bij de browsermaker te liggen maar bij de webdeveloper (en diens leidinggevende).

Nee, die keuze ligt bij de opdrachtgever, want uiteindelijk beïnvloedt het de gebruikservaring van het resultaat en kosten van het project.

Externe codecs klinkt leuk vanuit individualistisch perspectief, maar het verandert niets aan het landschap van ondersteunde mogelijkheden. Je moet er namelijk als ontwikkelaar altijd vanuit gaan dat het merendeel van de gebruikers die externe codecs niet heeft geïnstalleerd. (vandaar dat detecteren ook een non-issue is)

Dit is de Devschuur, niet de HK. We kunnen toch wel verder denken dan onze neus lang is?

[ Voor 26% gewijzigd door Bosmonster op 14-01-2011 10:20 ]

[Spinal]

Wellicht interessant: Why the Web needs WebM door Anne van Kesteren (Opera)

[Bosmonster]

ZanderZ schreef op vrijdag 14 januari 2011 @ 10:59:
Wellicht interessant: Why the Web needs WebM door Anne van Kesteren (Opera)

Mjah, het is nog maar de vraag hoe royalty-free WebM is. Dat is de hele reden waarom MS en Apple er vooralsnog huiverig over zijn. Het formaat is compleet nieuw en het verleden heeft al vaak genoeg uitgewezen dat er genoeg bedrijven in de rij staan om patent-rechtzaken te beginnen zodra een dergelijke techniek door een aantal grote bedrijven wordt geadopteerd.

MS en Apple hebben wat dat betreft wel een punt. Ja h.264 kost ze misschien 6 miljoen per jaar (waarschijnlijk niet als het gaat om Apple), maar dat is peanuts in vergelijking tot een enkele mogelijke rechtzaak mbt WebM. Daarnaast is de h.264 standaard uitontwikkeld, zijn er geen geheimen meer over en is er uitgebreide hardware-ondersteuning beschikbaar.

Het is dus lang niet zo zwart-wit als Anne wil doen voorkomen. Beide mogelijkheden hebben zo hun voor- en nadelen.

[ Voor 4% gewijzigd door Bosmonster op 14-01-2011 11:28 ]

[RuddyMysterious]

Royalty free, als in: dat er eventueel verborgen gebruikte patenten in zitten die niet royalty free zijn?

Ook is hier een reactie op het artikel van Peter Bright op Ars Technica, door Haavard van Opera.

Daar staat ook een reactie op het artikel die in sé samenvat wat voor mij het belangrijkste punt is dat google hier probeert te maken:

Great move from Google. h264 should not be online. Also, mp3 and gif must go away. Because ogg and apng is open, free, and have better quality. We must not allow again, from the start, another mistake of using shareware codec.

[Bosmonster]

Die reactie is van iemand die echt geen benul heeft hoe de wereld in elkaar zit als je mp3 en gif wilt "afschaffen". En dan noemen ze mij idealistisch

En "shareware codec"? Beetje klop/klepel.

[ Voor 12% gewijzigd door Bosmonster op 14-01-2011 13:27 ]

[NMe]

Sowieso is dat onzin want gif en mp3 kunnen wel degelijk bepaalde voordelen over andere formaten hebben.

[RuddyMysterious]

Bosmonster schreef op vrijdag 14 januari 2011 @ 11:22:
Mjah, het is nog maar de vraag hoe royalty-free WebM is. Dat is de hele reden waarom MS en Apple er vooralsnog huiverig over zijn. Het formaat is compleet nieuw en het verleden heeft al vaak genoeg uitgewezen dat er genoeg bedrijven in de rij staan om patent-rechtzaken te beginnen zodra een dergelijke techniek door een aantal grote bedrijven wordt geadopteerd.

MS en Apple hebben wat dat betreft wel een punt. Ja h.264 kost ze misschien 6 miljoen per jaar (waarschijnlijk niet als het gaat om Apple), maar dat is peanuts in vergelijking tot een enkele mogelijke rechtzaak mbt WebM. Daarnaast is de h.264 standaard uitontwikkeld, zijn er geen geheimen meer over en is er uitgebreide hardware-ondersteuning beschikbaar.

Het is dus lang niet zo zwart-wit als Anne wil doen voorkomen. Beide mogelijkheden hebben zo hun voor- en nadelen.

http://www.osnews.com/sto...reat_than_H264_Wait_What_

Met als conclusie:

"Although the Ogg codecs don't have known patents that aren't RF licensed, it's not completely clear that none of the patents out there on video/audio encoding apply," he argued, "Often, parties holding a submarine patent wait for a company with very deep pockets (like Apple, or Microsoft, or Google) to infringe on the patent before they sue."

Emphasis added.

Even though I don't like to use this term (too convenient a discussion killer), all this looks and smells like "FUD", propagated by those with a vested interest in shackling the web to H264.

Is het argument dat het gebruik van WebM gevaarlijk kan zijn wegens mogelijke rechtzaken dan toch gewoon FUD om ervoor te zorgen dat WebM moeilijk geadopteerd geraakt als de standaard codec voor html5 video?

edit: dit artikel heb ik gevonden bij het vermelden ervan in het volgende artikel, met hier het betreffende deel tekst:

Are you aware of the fact that after a decade of threats by the MPEG-LA, they have never been able to show a single patent infringed upon by On2/Theora/VPx, despite offers by the Xiph Foundation to work together with the MPEG-LA to ensure no patents were infringed upon?

Bron: http://www.osnews.com/sto...uber_Regarding_H_264_WebM

[ Voor 11% gewijzigd door RuddyMysterious op 14-01-2011 13:37 ]

[TGEN]

NMe schreef op donderdag 13 januari 2011 @ 17:06:
[...]

Die standaard zou in principe browserspecifiek kunnen zijn. Zolang er fallback is in de vorm van een codec voor andere standaarden maakt dat namelijk niet zo uit.

Regel even dat tweakers.net Ogg Theora dan wel WebM aanbiedt voor mijn Opera, in plaats van alleen AVC .

[Verwijderd]

NMe schreef op vrijdag 14 januari 2011 @ 13:32:
Sowieso is dat onzin want gif en mp3 kunnen wel degelijk bepaalde voordelen over andere formaten hebben.

Ik zie geen voordelen op het gebruik van gif en mp3 over png en ogg.

Bij gif vs png:
- beide ondersteunen transparantie, maar png is beter (heeft RGBA ipv RGB-)
- beide ondersteunen animaties (png wordt alleen niet ondersteund door programma's, maar kan wel!!!)
- png is kleiner is formaat bij complexe afbeeldingen, terwijl gif alleen kleiner is bij enkele kleur(en) en horizontale lijnen.

De verschillen tussen mp3 en ogg ken ik niet uit mijn hoofd, maar ik dacht dat ogg iets groter in formaat is (???).

[TGEN]

Verwijderd schreef op vrijdag 14 januari 2011 @ 15:13:
[...]
De verschillen tussen mp3 en ogg ken ik niet uit mijn hoofd, maar ik dacht dat ogg iets groter in formaat is (???).

MP3, Ogg Vorbis en AAC ontlopen elkaar niet zoveel, maar MP3 comprimeert over het algemeen beter, AAC levert betere kwaliteit bij lagere bitrates, en Ogg Vorbis levert over het algemeen betere kwaliteit dan MP3. Ogg Vorbis vs. AAC qua geluidskwaliteit kan ik niet onderscheiden. Dit alles bij gelijke bitrates, natuurlijk.

[NMe]

Verwijderd schreef op vrijdag 14 januari 2011 @ 15:13:
[...]

Ik zie geen voordelen op het gebruik van gif en mp3 over png en ogg.

Bij gif vs png:
- beide ondersteunen transparantie, maar png is beter (heeft RGBA ipv RGB-)

Transparantie is niet hetzelfde als opacity, en bovendien heb je het niet altijd nodig. Dit spreekt mijn post dus niet tegen.

- beide ondersteunen animaties (png wordt alleen niet ondersteund door programma's, maar kan wel!!!)

Heb je dus niks aan op het web. Daarnaast zijn GIF-animaties kleiner omdat die lossy zijn. Als kwaliteit niet boeit of als er weinig kleuren gebruikt worden kan dat best wel eens beter uitpakken.

- png is kleiner is formaat bij complexe afbeeldingen, terwijl gif alleen kleiner is bij enkele kleur(en) en horizontale lijnen.

PNG is juist groter bij complexe afbeeldingen omdat het lossless is.

De verschillen tussen mp3 en ogg ken ik niet uit mijn hoofd, maar ik dacht dat ogg iets groter in formaat is (???).

MP3 is juist groter (of liever: ogg heeft een lagere bitrate nodig voor dezelfde kwaliteit) maar wordt tevens ook veel breder ondersteund door hardware.

[ Voor 3% gewijzigd door NMe op 14-01-2011 15:19 ]

[RuddyMysterious]

Eigenlijk jammer dat de nutteloze en oude discussie over mp3 vs ogg en gif vs png heb opgestart, maar ik wil het eigenlijk vooral hebben over waarom iemand H264 zou verkiezen boven WebM. Ik probeer het argument dat WebM juridisch gezien niet veilig zou zijn te counteren met een artikel.

Ik zie dat de meeste mensen die H264 verdedigen, dat doen vanuit hun eigen standpunt: "voor mij (als webgebruiker) voegt het wegnemen van native H264 ondersteuning voor Google Chrome momenteel niks toe, dus ga ik niet akkoord met de keuze van Google." Dat is een jammerlijke mening, want de gevolgen op grotere termijn zijn des te beter voor de vrijheid en gratisheid van het internet.

Om even verder te gaan in de subtak van de discussie: MP3 wordt inderdaad beter ondersteund, en dat is net wat Google probeert tegen te gaan: codecs waar royalties voor moeten betaald worden weren, en zodoende moet niemand die er iets mee wilt doen er geld voor betalen, wat niet zo (geweest) is bij MP3. Hoe vroeger, hoe beter dus.

[ Voor 19% gewijzigd door RuddyMysterious op 14-01-2011 15:33 ]

[NMe]

DevilsProphet schreef op vrijdag 14 januari 2011 @ 15:32:
Ik zie dat de meeste mensen die H264 verdedigen, dat doen vanuit hun eigen standpunt: "voor mij (als webgebruiker) voegt het wegnemen van native H264 ondersteuning voor Google Chrome momenteel niks toe, dus ga ik niet akkoord met de keuze van Google." Dat is een jammerlijke mening, want de gevolgen op grotere termijn zijn des te beter voor de vrijheid en gratisheid van het internet.

H.264 is de facto al de standaard. Het zit ingebouwd in een breed scala aan hardware en wordt al jaren gebruikt in onder andere Flash maar ook in offline video sinds het HD-tijdperk. Door te kiezen voor WebM schop je de hele branche weer 3 jaar terug in de tijd.

[Bosmonster]

DevilsProphet schreef op vrijdag 14 januari 2011 @ 15:32:
Ik zie dat de meeste mensen die H264 verdedigen, dat doen vanuit hun eigen standpunt: "voor mij (als webgebruiker) voegt het wegnemen van native H264 ondersteuning voor Google Chrome momenteel niks toe, dus ga ik niet akkoord met de keuze van Google." Dat is een jammerlijke mening, want de gevolgen op grotere termijn zijn des te beter voor de vrijheid en gratisheid van het internet.

Ik heb nog niemand hier h.264 zien verdedigen. Er worden alleen argumenten gegeven om de keerzijde van de nogal eenzijdige berichten die gepost worden mbt WebM te tonen. De discussie gaat wat verder dan "WebM is open en kostenloos dus beter".

Belangrijkste is dat ze tot een standaard komen. Of dat h.264 of WebM is, die beiden hun voor- en nadelen hebben, maakt voor ons (gebruikers én developers) niet uit.

Ik heb wel een persoonlijke voorkeur, en die sluit aan bij NMe.

[ Voor 15% gewijzigd door Bosmonster op 14-01-2011 15:59 ]

[RuddyMysterious]

NMe schreef op vrijdag 14 januari 2011 @ 15:42:
H.264 is de facto al de standaard. Het zit ingebouwd in een breed scala aan hardware en wordt al jaren gebruikt in onder andere Flash maar ook in offline video sinds het HD-tijdperk. Door te kiezen voor WebM schop je de hele branche weer 3 jaar terug in de tijd.

Wel neen, de facto is het nog niet dé standaard, anders had Google de keuze om die niet meer te ondersteunen niet kunnen maken wegens teveel verlies van gebruikers van hun browser.

WebM gaat trouwens ook worden ondersteund door flash, heb ik gelezen.

Ik weet dat er al een hele collectie videobestanden bestaat gecodeerd met H.264, maar dat is net het jammerlijke. De illegale scene heeft de codec geadopteerd omdat zij toch geen kosten hebben aan het gebruik van die codec, en op die manier wordt die ook populair. Zodoende zitten de mensen die wél voordeel halen van het gebruik van FOSS-codecs dik in de puree, want zij worden door overmacht gedwongen om te dokken voor het gebruiken van die royalty-onvrije codecs, omdat niemand anders wilt.

Persoonlijk ben ik van mening dat als het aankomt op zulke dingen, het gemak van de gebruiker achter komt op het feit of een technologie bezwaard wordt met het betalen van licenties of niet. Het zou volledig open en gratis moeten zijn, en dat is H.264 niet. En nu probeer ik niet goed te praten dat Google even 6,5 miljoen dollar minder uitgeeft op die manier, maar ik denk aan de kleinere bedrijven die de kost beter kwijt dan rijk zijn. (hoe ironisch, het gebruik van deze uitdrukking in de huidige context)

Dus het komt neer dat WebM voor iedereen een goede keus is, behalve voor de financiëel-belanghebbenden van de H.264 codec en voor de gebruiker die zijn collectie H.264 videomateriaal niet rechtstreeks zal kunnen streamen via de video-tag.

Het is waar dat H.264 momenteel technisch gezien de beste codec is, maar bij mij wegen de royalties daar harder tegenop, waardoor de schaal negatief uitkomt. Idealistisch, dat is inderdaad zo, maar liever dat dan opportunistisch.

edit: bosmonster, in welke zin is de berichtgeving omtrent WebM eenzijdig? Ik heb het gevoel dat Google vooral wordt afgeschoten voor hun beslissing.

Vanuit welk standpunt zijn jullie trouwens de diepgaande afweging aan het maken tussen beide codecs? Als gebruiker, als webdesigner of als aanbieder van video?

edit2: Ik merk dat ik bezig ben een discussie te voeren die er niet was, want jullie waren aan het brainstormen over de best mogelijke manier van codec-ondersteuning en integratie, niet over welke van beide codecs die momenteel in het oog van de storm staan zou moeten winnen en waarom dan wel.

[ Voor 11% gewijzigd door RuddyMysterious op 14-01-2011 16:19 ]

[Bosmonster]

Het zou volledig open en gratis moeten zijn, en dat is H.264 niet.

Waarom zou dat moeten? Waarom is dat beter?

Dus het komt neer dat WebM voor iedereen een goede keus is, behalve voor de financiëel-belanghebbenden van de H.264 codec en voor de gebruiker die zijn collectie H.264 videomateriaal niet rechtstreeks zal kunnen streamen via de video-tag.

Nee, WebM is voor de gebruiker en developer geen beste keuze. Er is nauwelijks ondersteuning en geen hardware decoding. Daarnaast is de standaard inferieur aan h.264, zoals je zelf al aangeeft. Daarnaast is het helemaal niet zeker of WebM wel zo royalty-free is. Dat moet nog maar blijken.


Samengevat en zoals al eerder gezegd: Het enige argument dat elke keer weer om de hoek komt kijken is "WebM is gratis dus beter" en dat wordt gebracht als waarheid. Feit is dat het zodra WebM geadopteerd wordt, je de komende jaren alle devices mag gaan aanpassen die nu h.264 ondersteunen (alle huidige Android en iOS-apparatuur kan er niet mee omgaan). Leg mij eens uit waarom DAT nu zo'n goede keuze is.

edit: bosmonster, in welke zin is de berichtgeving omtrent WebM eenzijdig? Ik heb het gevoel dat Google vooral wordt afgeschoten voor hun beslissing.

Omdat het alleen maar wederom ingaat op het punt van royalties, maar alle overige argumenten (die dus niet in het voordeel van WebM spreken) negeert.

Google wordt inderdaad afgeschoten om hun beslissing, maar dat ligt meer aan het feit dat ze al een licentie op h.264 hebben, maar desondanks het wel schrappen uit Chrome. Ze gaan dus opzettelijk en onnodig dwarsliggen en daar helpen ze zowel gebruikers als developers niet mee.

[ Voor 20% gewijzigd door Bosmonster op 14-01-2011 16:30 ]

[NMe]

DevilsProphet schreef op vrijdag 14 januari 2011 @ 16:08:
[...]

Wel neen, de facto is het nog niet dé standaard, anders had Google de keuze om die niet meer te ondersteunen niet kunnen maken wegens teveel verlies van gebruikers van hun browser.

de facto
de ` fac - to (Latijn) bijwoord feitelijk, metterdaad (maar niet de jure , niet op rechtsgronden) '

Het is geen geschreven standaard maar veruit de meeste video die nu geproduceerd wordt, wordt encoded in H.264. Dat is de facto dus de standaard, en dat wordt nu dus overhoop getrokken omdat bepaalde bedrijven niet blij zijn met het risico...dat vervolgens bij WebM net zo groot danwel groter is.

[RuddyMysterious]

Er wordt gesteld dat Google dit gedaan heeft omdat het later, wanneer H.264 teveel ingeburgerd zou zijn, het te laat zou zijn. Ik durf te zeggen dat dit eigenlijk al het geval is.

Hardware-ondersteuning, daar wordt aan gewerkt hoor. Zoals hier, in puntje 3:

Are you aware of the fact that every major chip manufacturer except for Intel have openly pledged support for WebM? Are you aware of the fact that hardware support for WebM is scheduled to arrive in Q1 2011?, followed by even more later this year?

Dat het nog moet blijken dat WebM echt gratis is, daar heb ik toch ook al een reactie op gemaakt? Hier is een artikel over dat onderwerp, en ondanks dat de schrijver van het artikel geen uitmuntende kennis over recht heeft, heeft deze persoon dat blijkbaar wel. Het komt er inderdaad op neer dat Google tot nu toe nog niet heeft vrijgegeven of de gebruikte technologie van WebM patenten gebruiken waar royalties voor betaald moeten worden, maar er wordt ook gezegd dat het er naar uitziet dat het eerder niet zo zal zijn. Daartegenover staat dat het bij H.264 sowieso wél het geval is, dus liever een misschien dan een zeker.

Soit, ik kan mij het meest vinden in deze mening:

Theora is based on a pretty old codec. I'm pretty certain (by now) that there is no relevant, earlier, patented technology out there. Apple have been looking for it for nearly ten years now, and haven't come up with any.

---

Apple's not "looking for patents" they paid up "protection" to MPEG-LA and at this point they are the 800lb gorilla in the room. I'd venture Apple is getting the royalties for much less than anybody else... because they control enough media market, where Apple goes, the market goes. h.264 helps with lock-in to their stack... Apple wants to help "creatives" but only with "paid for", "locked down" tools.... Most OSS codex are locked out of Apple by default... they don't even toss in an EXT2/3 driver or other pieces that would play nicer with Linux and gain allies. Apple's biggest weakness right now is trying to "walk their own road" and not being willing to bring in other folks "enemy of my enemy" type deals.

Als het gaat om het zoveel mogelijk weren van grootmachten die hun eigen wil doordrijven, vind ik dat Apple momenteel zich arroganter gedraagt dan Google, en helemaal geen scrupules toont als het aankomt van geld vragen voor zaken en zich profileren als dictator, terwijl Google eerder bezig is met "gratis" dingen aan te bieden. (in hoeverre dat echt gratis is, daar valt natuurlijk over te twisten, maar dat valt buiten deze discussie)

NMe schreef op vrijdag 14 januari 2011 @ 16:25:
Het is geen geschreven standaard maar veruit de meeste video die nu geproduceerd wordt, wordt encoded in H.264. Dat is de facto dus de standaard, en dat wordt nu dus overhoop getrokken omdat bepaalde bedrijven niet blij zijn met het risico...dat vervolgens bij WebM net zo groot danwel groter is.

Ik weet best wel wat de facto wil zeggen, maar ik wil maar even zeggen dat het niet is omdat de meeste video's worden aangeboden in H.264-vorm, dat meteen maar de "de facto standaard" genoemd kan worden. Reden 1) Niet alle browsers ondersteunen H.264. Reden 2) Niet alle platformen ondersteunen H.264 officiëel. (alle FOSS OS'n) Het is niet dermate onmurwbaar als MP3 dat vroeger was, en ik denk niet dat WebM dezelfde tragische dood zal sterven zoals Ogg Vorbis dat deed, met amper hardwareondersteuning en weinig verspreiding. Ik denk, net nu HTML5 video nog niet zo ingeburgerd is, dat het daarom nog doenbaar is om de positie H.264 te verzwakken en met een alternatief te komen dat wél door iedereen ondersteund _kan_ worden.

Op technisch vlak is H.264 momenteel superieur, edoch zijn Theora en VP8 intussen al dichterbij gekomen, en ik geloof er wel in dat ze hun schade uiteindelijk wel kunnen inhalen. Hetzelfde met verspreiding, mede dankzij de boude zet van Google. Althans, dat hoop ik toch, want ik heb een lichte hekel aan machtsmisbruik en vendor lock-in's.

[TGEN]

NMe schreef op vrijdag 14 januari 2011 @ 16:25:
[...]


[...]

Het is geen geschreven standaard maar veruit de meeste video die nu geproduceerd wordt, wordt encoded in H.264. Dat is de facto dus de standaard, en dat wordt nu dus overhoop getrokken omdat bepaalde bedrijven niet blij zijn met het risico...dat vervolgens bij WebM net zo groot danwel groter is.

In termen van totale bandbreedte wereldwijd is MPEG2 nog steeds stukken groter dan MPEG4 AVC. Het zal nog een paar jaar duren voordat AVC MPEG2 overvleugelt qua aandeel in broadcasts. Voor internetvideo geldt dat niet, want dat is immers een nog jonge industrie die dus sneller kan wisselen, en die ook nog met meer bandbreedtebeperkingen zit dan zaken als satelliet-TV, en de compressievoordelen dus zwaarder wegen.

Voor internetvideo geldt wel wat jij zegt, dat AVC een voordeel heeft wegens de al bestaande adoptie in de markt, waar WebM/VPX dat niet heeft. Daar tegenover staat dan weer dat WebM/VPX royalty-vrij is, en dus breder toegepast kan worden, en ook sneller in lage-marge producten terecht kan komen.

[Bosmonster]

Daartegenover staat dat het bij H.264 sowieso wél het geval is, dus liever een misschien dan een zeker.

En daar maak je een kleine denkfout. Liever zeker dan misschien. De "zeker" is namelijk een fractie van een eventuele "misschien".

[Freeaqingme]

DevilsProphet schreef op vrijdag 14 januari 2011 @ 16:50:
[...] ondanks dat de schrijver van het artikel geen uitmuntende kennis over recht heeft, heeft deze persoon dat blijkbaar wel. Het komt er inderdaad op neer dat Google tot nu toe nog niet heeft vrijgegeven of de gebruikte technologie van WebM patenten gebruiken waar royalties voor betaald moeten worden, maar er wordt ook gezegd dat het er naar uitziet dat het eerder niet zo zal zijn.

Dat was zo. Google heeft daar best wel een boel kritiek op gehad vanuit de OSS community, en daarom diens beleid aangepast. Tegenwoordig kan je 't patent vrijelijk gebruiken, mits je niemand aanklaagt voor patent-litigation in zijn/haar/google's vp8 implementatie.

[NMe]

Bosmonster schreef op vrijdag 14 januari 2011 @ 16:54:
[...]

En daar maak je een kleine denkfout. Liever zeker dan misschien. De "zeker" is namelijk een fractie van een eventuele "misschien".

Plus dat je een "zeker" kan inramen in je budget en een "misschien" niet.

DevilsProphet schreef op vrijdag 14 januari 2011 @ 16:50:
Ik weet best wel wat de facto wil zeggen, maar ik wil maar even zeggen dat het niet is omdat de meeste video's worden aangeboden in H.264-vorm, dat meteen maar de "de facto standaard" genoemd kan worden. Reden 1) Niet alle browsers ondersteunen H.264. Reden 2) Niet alle platformen ondersteunen H.264 officiëel. (alle FOSS OS'n) Het is niet dermate onmurwbaar als MP3 dat vroeger was, en ik denk niet dat WebM dezelfde tragische dood zal sterven zoals Ogg Vorbis dat deed, met amper hardwareondersteuning en weinig verspreiding. Ik denk, net nu HTML5 video nog niet zo ingeburgerd is, dat het daarom nog doenbaar is om de positie H.264 te verzwakken en met een alternatief te komen dat wél door iedereen ondersteund _kan_ worden.

Op technisch vlak is H.264 momenteel superieur, edoch zijn Theora en VP8 intussen al dichterbij gekomen, en ik geloof er wel in dat ze hun schade uiteindelijk wel kunnen inhalen. Hetzelfde met verspreiding, mede dankzij de boude zet van Google. Althans, dat hoop ik toch, want ik heb een lichte hekel aan machtsmisbruik en vendor lock-in's.

Waarom zou je überhaupt willen dat WebM H.264 verslaat terwijl je zelf al aangeeft dat het momenteel nog inferieur is én minder ondersteund wordt? Potentiële kosten als enige argument? Terwijl die juist bij WebM hoger zouden kunnen uitvallen? En alle kosten voor de hardwarematige overgang naar WebM dan?

[RuddyMysterious]

Waarom zou ik dus willen dat WebM H.264 verslaat? Uit principes, zoals bij velen. En omdat het niet strookt met de W3C HTML5 specificaties. En omdat ik niet wil dat we allemaal onderworpen zijn aan de macht- en geldlust van de grote bedrijven in het MPEG-LA.

Voor de rest: hardwareondersteuning komt er sowieso al, flash ondersteuning idem.

De technische kwaliteit hoeft niet zo slecht te blijven als de huidige situatie, maar dat is mogelijks wishful thinking. We zullen wel zien, zeker?

[NMe]

DevilsProphet schreef op vrijdag 14 januari 2011 @ 18:04:
Waarom zou ik dus willen dat WebM H.264 verslaat? Uit principes, zoals bij velen. [...] De technische kwaliteit hoeft niet zo slecht te blijven als de huidige situatie, maar dat is mogelijks wishful thinking. We zullen wel zien, zeker?

Dus je wil uit principe dat een inferieure techniek een aantoonbaar betere techniek vervangt? Goede instelling.

[Bosmonster]

DevilsProphet schreef op vrijdag 14 januari 2011 @ 18:04:
Waarom zou ik dus willen dat WebM H.264 verslaat? Uit principes, zoals bij velen. En omdat het niet strookt met de W3C HTML5 specificaties. En omdat ik niet wil dat we allemaal onderworpen zijn aan de macht- en geldlust van de grote bedrijven in het MPEG-LA.

De html5 specificaties zeggen 0,0 over een te gebruiken codec. Die laat de keuze 100% over aan de ontwikkelaars.

Voor de rest: hardwareondersteuning komt er sowieso al, flash ondersteuning idem.

Het komt er toch al is in jouw ogen gelijk aan gratis? WebM gaan gebruiken ipv h.264 kost(te) de industrie tientallen, zo niet honderden miljoenen aan ontwikkelkosten. De honderden miljoenen die al in h.264 zijn gestoken kunnen de vuilnisbak in. Gratis? En dat allemaal voor een inferieure techniek. Kapitaalvernietiging als je het mij vraagt.

open source =/= gratis!

[ Voor 10% gewijzigd door Bosmonster op 14-01-2011 18:24 ]

[RuddyMysterious]

Bosmonster schreef op vrijdag 14 januari 2011 @ 18:20:
De html5 specificaties zeggen 0,0 over een te gebruiken codec. Die laat de keuze 100% over aan de ontwikkelaars.

Het W3C spreekt nochtans van de eis voor een royalty-vrije codec die de standaard moet worden voor HTML5 video.

Bosmonster schreef op vrijdag 14 januari 2011 @ 18:20:
Het komt er toch al is in jouw ogen gelijk aan gratis? WebM gaan gebruiken ipv h.264 kost(te) de industrie tientallen, zo niet honderden miljoenen aan ontwikkelkosten. De honderden miljoenen die al in h.264 zijn gestoken kunnen de vuilnisbak in. Gratis? En dat allemaal voor een inferieure techniek. Kapitaalvernietiging als je het mij vraagt.

open source =/= gratis!

Het zal in het niets vallen vergeleken met het kapitaal dat naar het MPEG-LA zal vloeien in de vorm van royalties, en ik ben van mening dat dat vermeden moet worden.

Dat Open Source niet gratis is, daar ben ik best van op de hoogte, aangezien H.264 Open Source is (x264 is een legale encoder die verstrekt wordt onder de GPL) maar niet gratis.

Blijkbaar is het hier nogal not done om FOSS boven eventuele extra kosten te plaatsen. Een beetje jammer, vind ik. Al is dat waarschijnlijk geen lokaal fenomeen; daarvan getuigt deze post.

[NMe]

DevilsProphet schreef op vrijdag 14 januari 2011 @ 18:32:
[...]

Blijkbaar is het hier nogal not done om FOSS boven eventuele extra kosten te plaatsen. Een beetje jammer, vind ik. Al is dat waarschijnlijk geen lokaal fenomeen; daarvan getuigt deze post.

Het is not done om te kiezen voor een techniek die aantoonbaar slechter is dan een andere alleen omdat deze (for the moment!) gratis en open source is en de andere niet. Een beetje developer heeft "user the right tool for the right job" met de paplepel ingegoten gekregen en op dit moment kiezen voor WebM staat daar gewoon lijnrecht tegenover. De underdogpositie die veel OSS-aanhangers zich vaak graag aanmeten is hier totaal irrelevant.

[ Voor 5% gewijzigd door NMe op 14-01-2011 18:42 ]

[RuddyMysterious]

De codec is helemaal niet gratis, hij is enkel gratis in non-commercieël gebruik, iets waar een site niet onder valt, iets waar de H.264 compatibele hardware niet onder valt, iets waar blu-ray's niet onder vallen ...

VP8 is trouwens heus zoveel slechter niet dan H.264, toch niet in de mate waarin je het doet uitschijnen.

Het gaat hier trouwens nog altijd om een webstandaard, geen videostandaard in het algemeen. Het feit dat het web zo belangrijk is geworden, maakt het des te crucialer dat we niet wéér gaan vast-zitten aan een codec die niet gratis is.

[NMe]

DevilsProphet schreef op vrijdag 14 januari 2011 @ 18:45:
Het gaat hier trouwens nog altijd om een webstandaard, geen videostandaard in het algemeen. Het feit dat het web zo belangrijk is geworden, maakt het des te crucialer dat we niet wéér gaan vast-zitten aan een codec die niet gratis is.

Kun je garanderen dat VP8 gratis blijft?

[Freeaqingme]

NMe schreef op vrijdag 14 januari 2011 @ 18:54:
[...]

Kun je garanderen dat VP8 gratis blijft?

Ja. Zie ook mijn vorige post. Ze hebben de codec onder de BSD license gereleased, en een lifetime patentgrant hierbij meegegeven. *

Freeaqingme schreef op vrijdag 14 januari 2011 @ 17:20:
[...]


Dat was zo. Google heeft daar best wel een boel kritiek op gehad vanuit de OSS community, en daarom diens beleid aangepast. Tegenwoordig kan je 't patent vrijelijk gebruiken, mits je niemand aanklaagt voor patent-litigation in zijn/haar/google's vp8 implementatie.

offtopic:
* Uiteraard kan google nog wel de licentie veranderen, maar doordat het nu al als BSD verspreid is, kan je dan 'gewoon' de boel forken.

[RuddyMysterious]

NMe schreef op vrijdag 14 januari 2011 @ 18:54:
[...]

Kun je garanderen dat VP8 gratis blijft?

Ja, want Google heeft het vrijgegeven onder BSD licentie. De code die ze onder die licentie hebben vrijgegeven is voor altijd en voor eeuwig volledig vrij, beschikbaar en bruikbaar voor iedereen zonder enige beperking.

Het kan zijn dat Google zijn verdere ontwikkelingen voor zich houdt, maar dat weerhoudt niemand om van de open versie een fork te maken. Hetzelfde zie je terug bij bijvoorbeeld LibreOffice.

edit: damn, ninja'd

edit2: een artikel daarover gevonden op Ars Technica: http://arstechnica.com/op...lict-with-bsd-license.ars

[ Voor 29% gewijzigd door RuddyMysterious op 14-01-2011 19:04 ]

[NMe]

Meer leesvoer.

http://antimatter15.com/w...of-open-and-vp8-vs-h-264/

[Webgnome]

DevilsProphet schreef op vrijdag 14 januari 2011 @ 19:01:
[...]


Ja, want Google heeft het vrijgegeven onder BSD licentie. De code die ze onder die licentie hebben vrijgegeven is voor altijd en voor eeuwig volledig vrij, beschikbaar en bruikbaar voor iedereen zonder enige beperking.

Het kan zijn dat Google zijn verdere ontwikkelingen voor zich houdt, maar dat weerhoudt niemand om van de open versie een fork te maken. Hetzelfde zie je terug bij bijvoorbeeld LibreOffice.

edit: damn, ninja'd

edit2: een artikel daarover gevonden op Ars Technica: http://arstechnica.com/op...lict-with-bsd-license.ars

En google kan niet ineens zomaar uit het niets van licentie veranderen?

[Freeaqingme]

Webgnome schreef op zondag 16 januari 2011 @ 18:20:
[...]


En google kan niet ineens zomaar uit het niets van licentie veranderen?

Jawel.

Maar, dit kunnen zij niet met terugwerkende kracht doen (en in de patentgrant staat dat dit voor altijd is, dus die kunnen ze niet veranderen). Dus als google ooit eens de licentie verandert kan je 'gewoon' de boel forken.

[RuddyMysterious]

NMe schreef op zondag 16 januari 2011 @ 16:58:
Meer leesvoer.

http://antimatter15.com/w...of-open-and-vp8-vs-h-264/

Enorm interessant imo, de meest nuchtere analyse die ik tot nu toe heb gelezen.

In de commentaren amper moddergegooi, eerder testamenten van verbijsterde gebruikers die het internet-wereldbeeld zien veranderen.

edit: Om even de discussie over het gebruiken van de codecs van het betreffende OS waarop de browser draait verder te zetten: (een reactie op het artikel uit de link die NMe gepost had)

BlackAura says

Tim F. – Using system codecs only makes sense if you only care about one operating system, and you have control over that operating system.

On Windows, an H.264 codec is only available with Windows 7. Last I heard, that was still less than 20% of Windows users. The other 80% get nothing. If they wanted an H.264 codec (legally, without violating any patent licenses), they would have to buy one.

Microsoft only cares about Windows 7, and they do control the operating system. They’ll probably just ship an H.264 codec for Vista when they release IE 9, but nobody else can do that.

Same deal with Safari. Apple can get away with using QuickTime, because they control it. If they want to ship QuickTime on Windows bundled with Safari, they can do that. Nobody else could.

On Linux, there’s only one legal H.264 codec. You would have to buy that if you wanted to use it. On other operating systems, there aren’t any codecs at all. You can rely on Theora and WebM being present though.

And what about embedded systems, like phones, tablets, games consoles… They usually don’t have any codecs at all. And yes, Opera, Mozilla, and Google care about these. Opera makes it’s living from selling web browsers for embedded systems, Mozilla wants Firefox to be available on everything with a CPU, and Google uses Chrome on Android and ChromeOS, neither of which have native video codecs.

So, you end up with inconsistent support across different platforms. Apple’s H.264 decoder supports a different subset of H.264 than Microsoft’s decoder does, and changes depending on which version of Mac OS X you’re using. Microsoft’s H.264 decoder is only available on Windows 7. Theora and WebM are normally only available on Linux. WMV is always available on Windows, sometimes on MacOS X, and rarely on Linux.

It’s also a maintainence headache. Since neither MIcrosoft nor Apple care about supporting lots of operating systems, they each have only one codec interface. Opera, Chrome, and Safari would need at least three, and then a fallback in case your platform doesn’t have any codecs at all. That’s just way too much work to maintain, and way too many chances for it to all blow up in your face.

Even worse – it’s a security problem. The native codecs are often very old, and were never designed to be accessible from the ‘net. By exposing them to the web, you expose any security vulnerabilities they have. That’s not just codecs installed by default either – that includes some random set of codecs that might have been installed by the user. You can’t just only allow a predetermined set of codecs either, because that defeats the whole point of using system codecs in the first place.

January 15, 2011, 9:22 pm

Waaruit blijkt dat het niet zo simpel is om dat te verwezenlijken als in het achterhoofd uniformiteit als hoofddoel wordt gesteld.

[ Voor 98% gewijzigd door RuddyMysterious op 16-01-2011 22:28 ]

[Bosmonster]

Freeaqingme schreef op zondag 16 januari 2011 @ 18:35:
[...]


Jawel.

Maar, dit kunnen zij niet met terugwerkende kracht doen (en in de patentgrant staat dat dit voor altijd is, dus die kunnen ze niet veranderen). Dus als google ooit eens de licentie verandert kan je 'gewoon' de boel forken.

Het gaat ook niet zozeer om de garanties of patenten van Google, maar om sleepers. Patenten van andere bedrijven die geschaad zijn, maar die wachten tot het gemeengoed is geworden. En daar zijn die garanties compleet nutteloos voor.

Google's garanties veranderen dus helemaal niks aan de argumentatie van MS en Apple.

DevilsProphet schreef op zondag 16 januari 2011 @ 21:51:
[...]

edit: Om even de discussie over het gebruiken van de codecs van het betreffende OS waarop de browser draait verder te zetten: (een reactie op het artikel uit de link die NMe gepost had)

[...]
Waaruit blijkt dat het niet zo simpel is om dat te verwezenlijken als in het achterhoofd uniformiteit als hoofddoel wordt gesteld.

Dat is wat ik al een paar pagina's duidelijk probeer te maken

[ Voor 32% gewijzigd door Bosmonster op 16-01-2011 23:13 ]

[RuddyMysterious]

Bosmonster schreef op zondag 16 januari 2011 @ 23:09:
[...]


Het gaat ook niet zozeer om de garanties of patenten van Google, maar om sleepers. Patenten van andere bedrijven die geschaad zijn, maar die wachten tot het gemeengoed is geworden. En daar zijn die garanties compleet nutteloos voor.

Google's garanties veranderen dus helemaal niks aan de argumentatie van MS en Apple.

Dat argument is loos omdat de MPEG-LA evenmin garandeert dat hun codec geen inbreuk maakt op patenten, dus in dat opzicht zijn ze geen haar beter.

Ook wordt er geargumenteerd dat de MPEG-LA al lang zoekt naar patentinbreuken, maar dat ze er nog geen hebben gevonden. Dat bewijst natuurlijk niks, maar het duidt wel wat aan.

[NMe]

DevilsProphet schreef op zondag 16 januari 2011 @ 23:41:
[...]

Dat argument is loos omdat de MPEG-LA evenmin garandeert dat hun codec geen inbreuk maakt op patenten, dus in dat opzicht zijn ze geen haar beter.

Juist wel. H.264 wordt al door heel wat grote bedrijven heel breed ondersteund. MS en Apple zijn de meest noemenswaardige voorbeelden. Als een patentjager daar geld aan had willen verdienen, dan hadden ze dat al gedaan. Het feit dat dat nog niet gebeurd is maakt het dus redelijk onwaarschijnlijk dat daar nog verborgen patenten aan vast hangen waar niemand nu iets van weet. Bij VP8/WebM/Theora/etc. moet dat nog blijken.

[RobIII]

NMe schreef op maandag 17 januari 2011 @ 00:06:
Als een patentjager daar geld aan had willen verdienen, dan hadden ze dat al gedaan. Het feit dat dat nog niet gebeurd is maakt het dus redelijk onwaarschijnlijk dat daar nog verborgen patenten aan vast hangen waar niemand nu iets van weet.

Los van de hele discussie (waar ik te moe voor ben ): vergis je daar niet in. Het zal niet voor 't eerst zijn dat men pas na 10 (of meer) jaren met patentzaken komt aankakken om zodoende te trachten nog meer "gedorven winst" proberen op te strijken of te wachten tot H.264 bijvoorbeeld door nog meer bedrijven wordt opgepakt om ze zodoende "mee te pakken". En zelfs al zou men wel meteen actie ondernemen kan het voorbereiden van een dergelijke zaak behoorlijk complex zijn en an sich al (bij wijze van) 5 jaar voorbereiding vereisen voor er überhaupt iemand een dagvaarding krijgt.

[ Voor 16% gewijzigd door RobIII op 17-01-2011 02:06 ]

[Bosmonster]

Dat neemt niet weg dat het met h.264 onaannemelijk is, aangezien dit al vele jaren door de industrie wordt gebruikt, terwijl het met WebM totaal onzeker is.

Normaliter zou dit voor ons als gebruikers en developers niet zo boeiend zijn, maar het laatste waar ik persoonlijk zin in heb is een herhaling van zoiets als Eolas. En dan viel dat nog relatief mee in verhouding tot wat een patentzaak met WebM zou doen als dat de industry standard zou worden.

[ Voor 47% gewijzigd door Bosmonster op 17-01-2011 08:55 ]

[RuddyMysterious]

Bosmonster schreef op maandag 17 januari 2011 @ 08:50:
Dat neemt niet weg dat het met h.264 onaannemelijk is, aangezien dit al vele jaren door de industrie wordt gebruikt, terwijl het met WebM totaal onzeker is.

Normaliter zou dit voor ons als gebruikers en developers niet zo boeiend zijn, maar het laatste waar ik persoonlijk zin in heb is een herhaling van zoiets als Eolas. En dan viel dat nog relatief mee in verhouding tot wat een patentzaak met WebM zou doen als dat de industry standard zou worden.

Dat is niet persé zo, want Google heeft nog niet zo lang geleden On2 (de makers van VP8) overgenomen, en ze hebben daarbij een resem patenten aan hun patent pool kunnen toevoegen, waardoor ze bij een eventuele rechtzaak leverage hebben. De waarschijnlijkheid voor beide partijen mag dan misschien verschillen, zeker zijn we niet.

edit: een beetje geschiedenis van de hele zaak:

(quote)If google really believes that supporting Theora is minimal threat, why don't they Use it on YOUTUBE? why did they invested in buying a new Codecs? Google is like a whore if you pay them (with supporting Theora, they get the OSS- Supporters heart), they gonna do what ever you want! They do any thing to get more users and Ads market.
Only the future will tell, I don't believe that Mozilla will keep their Position, Google is taking their Market-space. Buy supporting both Codecs they are getting Firefox-users, but they will not use Theora in any Productive Space.

my two cents(/quote)

---

As long as MPEG LA do not control the market completely, MPEG LA need YouTube to be h.264. MPEG LA might even SPONSOR YouTube to use h.264 ... that is a possibility.

Eraly last year, MPEG LA were starting to get very confident of their position. There was no other competitive codec. Mozilla announced a donation to improve Theora, but pfffft ... that wasn't a threat (or so thought MPEG LA).

http://techcrunch.com/200...video-format-for-the-web/

Early last year, MPEG LA began talking about increases in the license fees for h.264 for use on the web. Google saw the writing on the wall, and bought On2 (about mid-year), hoping to gain an alternative codec from that.

Unfortunately, On2 are licensees of MPEG LA.

http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx
(number 465).

Late last year (well after Google had bought On2), Mozilla's funding of Xiph.org for development of Theora bore fruit. Xiph.org released the Thusnelda branch of Theora, which finally was competitive with h.264.

As a side-note, development of Theora continues, and the next branch (called ptalarbvorm, which is now still experimental) is an appreciable improvement over Thusnelda (and hence, an improvement over h.264).

http://people.xiph.org/~greg/video/ptalarbvorm/

Thusnelda and Ptalarbvorm both make perfect sense for Google to use "in production space". The earlier Theora 1.0, which was out when Google bought On2, was not suitable.

bron: http://www.osnews.com/thread?415217

En hier een post over de geschiedenis van het ontstaan van VP3 waarop zowel Theora en H.264 zijn voortontwikkeld:

The "elephant in the room" is that VP3 is patented, and Theora is based on VP3.

On2 gave Xiph.org an irrevocable right to develop Theora based on VP3 patents.

OK, you may ask ... why exactly is this an "elephant in the room"? Well, the point is that if there is patentable technology that is included in both Theora as well as in H.264 ... then VP3 is older. Theora is likely to be the one covered by patent, and H.264 is likely to be the infringer!!!

However ... this shouldn't happen at all (so MPEG LA can breathe a bit of a sigh of relief here). It shouldn't happen because if there was a patentable technology in VP3, then On2 should have patented it, and the USPTO should not have granted a second patent later on to H.264 for the same technology. If VP3 uses technology that wasn't patentable (and so isn't covered by On2's patents for VP3), then that same technology shouldn't be patentable later on if one of the MPEG LA group of companies tried to patent it.

If the USPTO did its job properly, there should be no technology covered by an H.264 patent within the earlier VP3 technologies.

bron: http://www.osnews.com/thread?415208

Hier nog een post waaruit zou moeten blijken dat Apple (een van de grote namen in MPEG-LA) al jaren op zoek is naar patentschending in zowel Theora als VPx, maar die nog altijd niet gevonden heeft:

Apple is indirectly asking ... no, pleading ... for anyone to come forward who has a magic patent (that shouldn't exist, BTW, if the USPTO was doing its job) that is older than VP3 and covers the same technology as VP3.

Please, please, please Apple are signalling, all you noble patent trolls, attack Theora. You are certain to find silent backers if you do.

Apple have apparently been asking (no, pleading) for this for nearly ten years now.

So far, no takers. Bad luck, Apple.

bron: http://www.osnews.com/thread?415211

En dan is er nog deze thread in de commentaar: (vergeef mij voor al het gecopy-paste)

by bhtooefr on Thu 25th Mar 2010 13:41 UTC:

Just because MPEG-LA (or someone else) hasn't sued someone for using Theora doesn't mean that they can't in the future.

And, just because they're trying to intimidate people doesn't mean that there's not actually patents.

One common technique is to wait until the patent has almost expired, or there's a lot of money in Theora. Right now, there's not that much money to go after for Theora. If/when it gets more deeply rooted, there's a lot of money.

---

by lemur2 on Thu 25th Mar 2010 13:51 UTC:

This ignores the fact that the Theora technology is older than h.264.

If Theora and H.264 do have some common technology, and there is a patent squabble, then Theora prevails, not h.264.

No-one else (other than MPEG LA members) are making any grumble about Theora. This has been the case for almost ten years now.

Finally, all that the MPEG LA members ever do is make ominous-sounding-but-vague hints of potential patent difficulties for Theora. All hat and no cattle.

---

by bhtooefr on Thu 25th Mar 2010 13:54 UTC:

Theoretically, there could be something that VP3 didn't do, but Theora did. In that case, it COULD infringe on H.264.

Also, "H.264" isn't A patent, it's a patent pool. I haven't looked, but there could be patents in the pool that predate VP3.

---

by lemur2 on Thu 25th Mar 2010 14:13 UTC:

Theoretically, I suppose. However, I have a player that is Theora 1.0, and it can still play these videos encoded by later versions of the encoder:

http://people.xiph.org/~greg/video/ptalarbvorm/

Xiph.org aren't playing about with the format or mucking about with new technologies, they are simply optimising the encoder.

PS: In threads like these, I am forever astounded by how many people seem to be desperate to try to find a problem for Theora. Theora is a collaboratively-developed freedom codec which anyone may use anywhare anytime in any context without restriction, a gift to humanity if you will.

Meanwhile, the competing codec H.264 is heavily patented, licensors of the codec make endless "all hat and no cattle" threats to sue left right & centre, both against competing codecs and their own users, and they have been doing so for almost ten years, but there is never any actual substance.

Why does ANYONE support those trolls?

---

by bhtooefr on Thu 25th Mar 2010 14:23 UTC:

I don't SUPPORT them.

It's just that I lean towards pragmatist. H.264 has quite a lot of momentum behind it.

My prediction is that, if <video> takes hold, Firefox is dead, unless the plugin approach (the very thing that <video> is trying to avoid,) preferably using the host's native media framework and any codecs available to it, is used. (This will also provide increased performance, as generally the native media frameworks are optimized to use the host's graphics system in the most efficient manner.) Opera may end up having to shell out for an H.264 license.

If Mozilla doesn't provide a way for H.264 content to be played back in Firefox, then Chrome will completely replace Firefox.

(I'll note, BTW, that I'm an Opera user.)

More likely, though, video sites will consider the Firefox userbase as too large to lose, and <video> won't take hold. Flash will remain as the dominant web video format, and every browser will suffer from its goatse-sized security holes.

bron: http://www.osnews.com/thread?415220

Ik geef toe dat de bron niet direct de meest objectieve is, gaande over dit onderwerp, maar ik wil toch maar zeggen dat er blijkbaar veel FUD en onzekerheid circuleert over het internet.

[ Voor 103% gewijzigd door RuddyMysterious op 17-01-2011 11:36 ]

[.oisyn]

nieuws: Microsoft brengt h264-plug-in voor Chrome uit

[crisp]

.oisyn schreef op donderdag 03 februari 2011 @ 14:03:
nieuws: Microsoft brengt h264-plug-in voor Chrome uit

En de code van de plugin: https://gist.github.com/808455
Hij vervangt <video> door <object> - hoezo vooruitgang door HTML5?

[.oisyn]

Ik snap niet wat de relevantie is van hoe het gebeurt. De content wordt op een standaard manier aangeboden, en Chrome gebruikers onder Windows kunnen het nu ook afspelen. Het is niet alsof die translatie op de server al gebeurt en iedereen er dus mee te maken krijgt. Het is gewoon een transformatie naar iets wat de browser wél support. Browserspecifiek, dus standaard schmandaart. Als ik een browser plugin schrijf hou ik ook rekening mee wat die specifieke browser doet, en niet wat de HTML standaard voorschrijft.

[ Voor 52% gewijzigd door .oisyn op 03-02-2011 14:31 ]

[Bosmonster]

Ach ja... de oplossing is niet de mooiste, maar can't blame 'em for trying.

Nadeel is natuurlijk wel dat je serieus rekening moet houden met het feit dat de tag kan veranderen in zowel CSS als Javascript. De plugin kan potentieel je site breken.

Ook ben ik benieuwd wat er gebeurt als je een video-tag met daarin een object-tag hebt als Flash-fallback. Breekt dat ook?

[ Voor 66% gewijzigd door Bosmonster op 03-02-2011 14:33 ]

[.oisyn]

Bosmonster schreef op donderdag 03 februari 2011 @ 14:31:
Nadeel is natuurlijk wel dat je serieus rekening moet houden met het feit dat de tag kan veranderen in zowel CSS als Javascript. De plugin kan potentieel je site breken.

Het klinkt alsof je nu redeneert van de site developer, maar ik zou daar persoonlijk dan weer geen rekening mee gaan houden. Tenzij je de plugin actief promoot om je H264 content aan de man te brengen, is het voornamelijk de plugin zelf die er verantwoordelijk voor is.

[ Voor 5% gewijzigd door .oisyn op 03-02-2011 14:37 ]

[crisp]

.oisyn schreef op donderdag 03 februari 2011 @ 14:29:
Ik snap niet wat de relevantie is van hoe het gebeurt. De content wordt op een standaard manier aangeboden, en Chrome gebruikers onder Windows kunnen het nu ook afspelen. Het is niet alsof die translatie op de server al gebeurt en iedereen er dus mee te maken krijgt. Het is gewoon een transformatie naar iets wat de browser wél support.

Het idee van het <video>-element is juist om af te zijn van allerhande plugins om iets als video af te kunnen spelen. Nu komen er alleen maar meer plugins bij. Ja, ik snap waarom MS H264 pushed, en waarom Google juist WebM pushed, maar ik vraag me af of dit nu wel de juiste weg is. Het zou hilarisch zijn als het niet zo serieus was... Ik zie liever dat alle partijen constructief meewerken om te komen tot een standaard baseline codec die breed gesteund wordt (wat ook de oorspronkelijke intentie was van de HTML5 WG); gelukkig houdt Microsoft wat dat betreft de deur nog wel open.

[mcDavid]

crisp schreef op donderdag 03 februari 2011 @ 14:40:
[...]

Het idee van het <video>-element is juist om af te zijn van allerhande plugins om iets als video af te kunnen spelen. Nu komen er alleen maar meer plugins bij. Ja, ik snap waarom MS H264 pushed, en waarom Google juist WebM pushed, maar ik vraag me af of dit nu wel de juiste weg is. Het zou hilarisch zijn als het niet zo serieus was... Ik zie liever dat alle partijen constructief meewerken om te komen tot een standaard baseline codec die breed gesteund wordt (wat ook de oorspronkelijke intentie was van de HTML5 WG); gelukkig houdt Microsoft wat dat betreft de deur nog wel open.

Helemaal mee eens dit is absoluut niet waar de <video> tag voor bedoeld is. Heikel punt is namelijk dat deze plugins duidelijk platform-afhankelijk zijn. En dat was nou juist één van de dingen waar we vanaf wouden.

[.oisyn]

@crisp: ik snap je bezwaar in z'n algemeenheid wel, maar je reageerde specfiek op de code, en in die context plaatste ik daar weer een reactie op. Je verhaal gaat ook op als ze via een plugin daadwerkelijk h264 aan de <video> hadden toegevoegd, ipv de omweg die ze nu gebruiken.

[ Voor 31% gewijzigd door .oisyn op 03-02-2011 14:54 ]

[crisp]

.oisyn schreef op donderdag 03 februari 2011 @ 14:53:
@crisp: ik snap je bezwaar in z'n algemeenheid wel, maar je reageerde specfiek op de code, en in die context plaatste ik daar weer een reactie op. Je verhaal gaat ook op als ze via een plugin daadwerkelijk h264 aan de <video> hadden toegevoegd, ipv de omweg die ze nu gebruiken.

true, maar de hilariteit zit 'm in het feit dat deze manier letterlijk 'backwards' is

Dat verder buiten de potentiele problemen die Bosmonster al noemde en die Microsoft zelf ook al deels aanstipt:

quote: http://www.interoperabili.../wmp-extension-for-chrome

The current version of the Extension still uses the Windows Media Player Plug-in APIs to control video playback, so there are some differences between the methods/properties defined in the emerging HTML5 standard and those available in the Windows Media Player plug-in. We are working to fix this limitation in the next release.

[NMe]

mcDavid schreef op donderdag 03 februari 2011 @ 14:45:
[...]

Helemaal mee eens dit is absoluut niet waar de <video> tag voor bedoeld is. Heikel punt is namelijk dat deze plugins duidelijk platform-afhankelijk zijn. En dat was nou juist één van de dingen waar we vanaf wouden.

De browservendors zitten gewoon gezamenlijk alle voordelen van HTML5 video te vermoorden en vervolgens de andere vendors de schuld te geven van het feit dat het gebeurt. En daar maken ze zich allemaal even schuldig aan als je het mij vraagt.

[Verwijderd]

Ik ben bezig met een html5/css3/jQuery site, niet echt rocket science en lukt verder prima.

Wat me nou niet lukt is het gebruik maken van de font-face mogelijkheid.
Heb via Font Squirrel wat fonts aangemaakt.
Lokaal werkt alles prima (duh) alleen wil die het online niet tonen.

Heb in IIS al de nodige MIME types aangemaakt maar dit mag niet baten. Maak gebruik van .woff.

Vergeet ik een header tag ofzo? Of toch niet de goede MIME?

Gebruikte;

.svg / image/svg+xml
.svgz / image/svg+xml
.woff / (weet even niet, zit niet op werk)

Vermoed overigens het laatste…

Als je het wenst kan ik wel even de url pm-en (vanwege werk)

[.oisyn]

Hoe zit het eigenlijk met input mogelijkheden? Biedt html 5 nog dingen als relative mouse motion? Ik zat een beetje de webgl demo's te bekijken, maar ze hebben allemaal hetzelfde probleem: mouse interaction laat veel te wensen over

[RuddyMysterious]

Verwijderd schreef op vrijdag 04 maart 2011 @ 18:33:


Ik ben bezig met een html5/css3/jQuery site, niet echt rocket science en lukt verder prima.

Wat me nou niet lukt is het gebruik maken van de font-face mogelijkheid.
Heb via Font Squirrel wat fonts aangemaakt.
Lokaal werkt alles prima (duh) alleen wil die het online niet tonen.

Heb in IIS al de nodige MIME types aangemaakt maar dit mag niet baten. Maak gebruik van .woff.

Vergeet ik een header tag ofzo? Of toch niet de goede MIME?

Gebruikte;

.svg / image/svg+xml
.svgz / image/svg+xml
.woff / (weet even niet, zit niet op werk)

Vermoed overigens het laatste…

Als je het wenst kan ik wel even de url pm-en (vanwege werk)

Wat werkt er niet? En in welke browser werkt het niet?

[crisp]

.oisyn schreef op vrijdag 04 maart 2011 @ 18:46:
Hoe zit het eigenlijk met input mogelijkheden? Biedt html 5 nog dingen als relative mouse motion? Ik zat een beetje de webgl demo's te bekijken, maar ze hebben allemaal hetzelfde probleem: mouse interaction laat veel te wensen over

WebGL is helemaal geen HTML5, WebGL is een 3D-API voor het canvas-element ontwikkeld door Khronos (en dus buiten het W3C om). Net als bij de 2D-API (wat feitelijk ook een aparte specificatie is en dus geen onderdeel van HTML5 in de nauwe zin) gaat interactie via de DOM interface. Nu is de 2D-API behoorlijk simpel van opzet (en eigenlijk ook nooit bedoelt om dingen als animatie mee te doen); hoe dat met WebGL zit weet ik niet precies, maar volgens mij ben je qua events nog steeds afhankelijk van de DOM en zal je zaken als relative mouse motion zelf moeten oplossen...

[Freeaqingme]

Waarbij 'zelf' natuurlijk ook relatief is. Er zullen ongetwijfeld weer frameworks komen die al dat voor je implementeren.

[.oisyn]

crisp schreef op vrijdag 04 maart 2011 @ 23:42:
[...]

WebGL is helemaal geen HTML5

Dat beweer ik toch ook nergens Ik vroeg me alleen af of het uitgebreidere inputmogelijkheden bood.

Relative motion is helemaal niet te implementeren met DOM, want je kunt buiten de window komen, en daarnaast heb je last van de randen van het scherm.

[ Voor 24% gewijzigd door .oisyn op 05-03-2011 18:54 ]

[crisp]

.oisyn schreef op zaterdag 05 maart 2011 @ 18:52:
[...]

Dat beweer ik toch ook nergens Ik vroeg me alleen af of het uitgebreidere inputmogelijkheden bood.

Het valt m.i. helemaal niet binnen de scope van de HTML WG, het lijkt me meer iets voor de Web Applications WG.

Relative motion is helemaal niet te implementeren met DOM, want je kunt buiten de window komen, en daarnaast heb je last van de randen van het scherm.

Ik beweer ook niet dat ik alle aspecten van 'relative motion' ken Maar inderdaad; dat is met de huidige DOM interface niet mogelijk.

[Verwijderd]

Ik weet niet als dit het juiste topic is om dit te bespreken, maar HTML5Boilerplate heeft gisteren de status 1.0 gekregen!

[Verwijderd]

Ik heb al veel gelezen op internet over het verschil tussen <section> en <article>. Nu weet ik onderhand dat <article> specifieker gezien wordt dan een <section>. Zover ik het nu doorheb bevat <article> altijd het artikel (logisch.. ) en is een <section> een deel in het artikel. De content uit een <article> kan zo op zichzelf staan als je het uit het geheel haalt, dat is bij een <section> niet het geval. Beide zijn niet bedoelt voor opmaak, daar is de <div> dan weer zo. Klopt dit zo?

Nu zit ik het met het volgende. Ik heb een homepage met, laten we zeggen, 8 content blokken. Daarboven een <header>, eronder een <footer>. Nu de vraag. Is de hompage nu een <article> met 8 maal een <section> erin, of zijn het 8 losse <article>'s? De blokken bevatten samenvattende informatie over aan te bieden diensten, social media, contact, vacatures, etcetera. De informatie hoort dus wel bij elkaar (gaat over het bedrijf), maar aan de andere kant kunnen de content blokken ook op zichzelf staan.

Zie ik iets over het hoofd?

[Verwijderd]

Op mijn blog werkt het omgekeerd:

Ik heb 1 <section> waar mijn nieuws inkomt en elke nieuwspost is een nieuw <article>.

[Verwijderd]

Waar gebruik je de <section> dan precies voor? Container?

[Verwijderd]

Dat klopt. Ik heb in totaal 3 sections:

• container
• content (articles)
• balk aan de zijkant met tweets en overzicht van categoriën

[Verwijderd]

Nu las ik her en der dat het niet de bedoeling is om een <section> en <article> te gebruiken als container functie. Toch heb je dat gedaan. Reden voor?

[Verwijderd]

Ik las dit artikel en als ik alles goed begrijp mag dit wel gewoon.

The potentially confusing part of this is that <section> can be used for parts of a page (eg the main content column, the news section on a homepage) and contain <article>s, and also for sections of a long <article> (ie inside an <article>).

Dat is een beetje hoe ik het gedaan heb.

Voor de sectie rechts heb ik ook <aside> gebruikt. Uiteraard maak ik voor mijn header gebruik van <header> en voor mijn footer gebruik van <footer>. De navigatie verzorg ik logischerwijs met <nav>

[Bosmonster]

Een section is gewoon een deel van je site dat je als los blok content kan zien. Het is dus een div met iets meer semantische waarde mbt content. Dit kan, zoals de quote hierboven al aangeeft, een losstaand deel van je pagina zien, maar binnen een article kun je ook sections hebben. Sections kunnen ook prima genest zijn.

Header en footer zijn eigenlijk ook gewoon sections, maar omdat ze zoveel gebruikt worden en zo'n specifieke waarde hebben, hebben die een eigen tag gekregen.

Het grote verschil met div is dat die gewoon 0,0 waarde heeft en je puur voor layout kunt gebruiken.

Wel een kanttekening: Het blijft allemaal nog wat nieuw en de meningen en best practices moeten eigenlijk nog grotendeels gevormd worden. 100% goed kun je het dus gewoon nog niet echt doen, fout daarentegen wel (een section zonder content is gewoon geen section, om maar iets te noemen).

[ Voor 22% gewijzigd door Bosmonster op 22-06-2011 21:44 ]

[Verwijderd]

Dat stukje verklaard wel het één en ander. Je kan dus een <section> hebben voor het indelen van content, maar ook voor het indelen van een <article>. Thanks!

[Verwijderd]

Zo zit dat ja! Heb je goed gesnapt!

[ Voor 49% gewijzigd door Verwijderd op 22-06-2011 21:45 ]

[Verwijderd]

Thanks, maakt het allemaal weer wat helderder!

[Verwijderd]

HTML5 = vooral betere semantiek

[OkkE]

En daarnaast natuurlijk nog veel meer; nieuwe form elementen, nieuwe attributen en een aantal nieuwe APIs.

[ Voor 3% gewijzigd door OkkE op 23-06-2011 12:53 ]

[Verwijderd]

Ik gebruik overigens de volgende code om de html5 tags zichtbaar te maken in oudere browsers/IE (getest tot 7.x)

JavaScript:

(function(){if(!/*@cc_on!@*/0)return;var e = "abbr,article,aside,audio,bb,canvas,datagrid,datalist,details,dialog,eventsource,figure,footer,header,hgroup,mark,menu,meter,nav,output,progress,section,time,video".split(',');for(var i=0;i<e.length;i++){document.createElement(e[i])}})()

[NMe]

Ik geef toch de voorkeur aan deze.

[Verwijderd]

NMe schreef op maandag 20 februari 2012 @ 21:03:
Ik geef toch de voorkeur aan deze.

Wat is het voordeel van deze? Uitgebreider, dat sowieso

[NMe]

Die is waarschijnlijk wat duidelijker voor je als je de uitgeschreven versie leest.

[Bosmonster]

Feit blijft dat je site instort in 20-30% van de browsers zonder javascript... terwijl het qua functionaliteit niks toevoegt vooralsnog.

Sterker nog, html5 outlining wordt nog praktisch niet ondersteund door bijvoorbeeld (Google) spiders, screenreaders e.d.

[ Voor 53% gewijzigd door Bosmonster op 21-02-2012 08:02 ]

[_Erikje_]

Bosmonster schreef op dinsdag 21 februari 2012 @ 08:00:
Feit blijft dat je site instort in 20-30% van de browsers zonder javascript... terwijl het qua functionaliteit niks toevoegt vooralsnog.

Ik vraag me toch sterk af wie zijn javascript standaard uit heeft staan, de 'security nut' en de eenzame Lynx2 gebruiker Het klootjesvolk heeft gewoon IE met javascript

[Verwijderd]

Dat vraag ik me dus ook af. Zijn er überhaupt nog gevallen waarbij je expliciet rekening wilt houden met javascript-less cases? Anno 2012 hebben toch zelfs bijna alle mobile devices beschikking over (beperkte, performancewise) javascript?

Desalniettemin is het natuurlijk wel lekker als je weet dat je website het ook gewoon volledig blijft doen zonder JS, dus het dwingt je wel enigszins om semantisch correct te werk te gaan. Dus: niet van een DIV element later een select-widget maken, maar in plaats daarvan een SELECT element (met onderliggende OPTION elementen) decoreren met attributen waar een parser overheen kan gaan.

[Voutloos]

Bosmonster schreef op dinsdag 21 februari 2012 @ 08:00:
Feit blijft dat je site instort in 20-30% van de browsers zonder javascript... terwijl het qua functionaliteit niks toevoegt vooralsnog.

Wat is dat percentage? Aantal oude browsers? Leuke statistiek, nu alleen nog vermenigvuldigen met het percentage mensen dat javascript uit heeft.

Sterker nog, html5 outlining wordt nog praktisch niet ondersteund door bijvoorbeeld (Google) spidersx

Even minder belangrijke spiders negerende: Is er bewezen dat Googlebot HTML5 niet ondersteund?

...screenreaders e.d.

Hmz, wordt er door producenten van screenreaders dan zo erg gefaald? Je zou juist denken (althans ik ) dat screenreaders juist enorm gebaat zijn met betere semantiek.

[Cubic X]

After crunching the numbers, we found a consistent rate of JavaScript-disabled requests hovering around 1% of the actual visitor traffic, with the highest rate being roughly 2 percent in the United States and the lowest being roughly 0.25 percent in Brazil. All of the other countries tested showed numbers very close to 1.3 percent.

bron

Daarom maken wij op het werk (en stage ook trouwens) ons niet druk over mensen die JavaScript uit hebben staan, dan maar een minder goed werkende of mooie website voor die kleine groep mensen. De meeste huis-tuin-en-keuken gebruikers hebben JavaScript wel aan .

[Bosmonster]

Voutloos schreef op dinsdag 21 februari 2012 @ 21:08:
[...]
Wat is dat percentage? Aantal oude browsers? Leuke statistiek, nu alleen nog vermenigvuldigen met het percentage mensen dat javascript uit heeft.

Wij werken vrij veel voor overheid bijvoorbeeld en dienen dus ook vrij veel rekening te houden met de webrichtlijnen voor toegankelijkheid. Daarnaast zijn deze richtlijnen over het algemeen kwaliteitsrichtlijnen, die we ook zoveel mogelijk in alle andere projecten proberen te hanteren.

Ten tweede is het voor SEO bijvoorbeeld ook geen slecht plan om je site te laten werken zonder javascript en in ieder geval content toegankelijk te houden.

Het is niet zo dat je dat per definitie altijd moet doen, maar zolang die html5-shiv in de praktijk niks toevoegt, is het ook redelijk zinloos je een dergelijke beperking aan te meten.

Even minder belangrijke spiders negerende: Is er bewezen dat Googlebot HTML5 niet ondersteund?

Als het gaat om html5 outlining: ja. Google gaat nog steeds uit van 1 H1 bijvoorbeeld als hoofdheader van een pagina e.d.

Hmz, wordt er door producenten van screenreaders dan zo erg gefaald? Je zou juist denken (althans ik ) dat screenreaders juist enorm gebaat zijn met betere semantiek.

Zolang html5 nog niet echt een standaard is en screenreaders vaak gebaseerd op de standaard semantiek en outlining zoals die al jaar en dag gebruikt wordt, is dat niet even een aanpassing die je snel doet. Het vereist niet alleen een technische aanpassing, maar ook een flinke wijziging voor je gebruikers in hoe ze ermee omgaan.

Een normale bezoeker ziet geen verschil in html4, xhtml of html5, die ziet gewoon een site. Een screenreader-gebruiker krijgt een hele andere structuur voorgeschoteld.

Daarnaast kun je van html5 een grotere puinhoop maken als developer (wat ik ook te vaak zie gebeuren...) dan van de oudere standaarden. Er zijn veel semantische tags bijgekomen en als je die niet goed gebruikt is het niet veel anders dan dat je tables gebruikt voor je opmaak.

--
Al met al vind ik het een mooie technologie en is het natuurlijk de toekomst, maar vind ik het nog niet volledig productierijp zolang er een javascript-shiv nodig voor het merendeel van de gebruikers en het nut nog te beperkt is om een dergelijke beperking te verantwoorden. Dat is een puur praktische afweging.

Als het gaat om html5-doctype, data-attributen, input-types, etc: die zijn gewoon prima bruikbaar en dus ook gewoon doen! Hetzelfde geldt voor kleinere of persoonlijke projecten natuurlijk. Niet alles is productie

[ Voor 3% gewijzigd door Bosmonster op 22-02-2012 08:23 ]