YouTube en Vimeo experimenteren met nieuwe video-tag

YouTube en Vimeo zijn beide aan het experimenteren met de video-tag, die waarschijnlijk wordt opgenomen in de html 5-specificatie. Met deze tag moet video kunnen worden bekeken zonder dat een plugin hoeft te worden geïnstalleerd.

Momenteel worden nog vaak commerciële plugins zoals Flash of Silverlight gebruikt voor het afspelen van video's. De video-tag in de html 5-specificatie moet die plugins overbodig maken. Hoewel html 5 nog geen officiële standaard is, hebben de videosites YouTube en Vimeo al een experimentele speler gelanceerd die de video-tag gebruikt.

De player van YouTube werkt alleen met Google Chrome en versie 4 van Apples Safari. Dat komt waarschijnlijk doordat YouTube voor het afspelen van content met de video-tag de h.264-codec gebruikt, terwijl bijvoorbeeld Firefox en Opera daarvoor Ogg Theora gebruiken. Chrome en Safari ondersteunen wel h.264; Internet Explorer biedt helemaal nog geen ondersteuning voor de tag.

Voor de Vimeo-player geldt hetzelfde: gebruikers van Firefox, Opera of Internet Explorer kunnen de experimentele speler niet gebruiken. Ook werkt de speler bij Vimeo niet in fullscreen en worden embedded video's nog altijd afgespeeld met de Flash-codec. Ook werkt één op de tien video's niet met de nieuwe speler. Zowel bij YouTube als bij Vimeo moeten bezoekers expliciet aangeven de html5-speler te willen gebruiken.

Reacties (115)

[tweeny]

Het enige probleem is dat er alleen H.264 op dit moment word ondersteund door maar 2 browsers, want de 3 van de 5 grootste browsers hebben de implementatie nog niet in hun nieuwste alpha/beta van hun browser, waarvan 2 hebben aangegeven H.264 niet te willen ondersteunen, en de 3e er nog niks over heeft losgelaten.

Bij mozilla is het probleem dat de H.264 closed source is, net als flash, veel patenten van H.264 zullen in de komende tijd aflopen, maar de laatste lopen af in 2017, tegen die tijd is er weer de opvolger van H.264, en dan loop je weer tegen hetzelfde probleem op.
Bron

Ook Opera is op het moment niet van plan om H.264 te gaan ondersteunen, gewoon om de simpele reden dat het te veel geld kost (rond de 10 cent per gebruiker bij 1 miljoen gebruikers, dus $100.000 <KLIK>)
Bron

En Microsoft heeft er nog niks over gezegd welke kant ze op gaan met hun HTML5 support.

[Reactie gewijzigd door tweeny op 22 juli 2024 17:30]

[ls470]

Waarom moet een webbrowser eingenlijk de gebruikte codecs ondersteunen? Is het niet voldoende dat de webbrowser de OS interface (bijvoorbeeld directshow) ondersteunt, zodat de gebruiker zelf nog kan kiezen welke (al dan niet commerciele) codecs hij installeert?

[latka]

Mozilla is cross-platform: niet alle OS'en komen met in het OS geintregeerde video (noem het een nadeel, ik zie het als een voordeel). Dus moet de browser het zelf ondersteunen.

[ppl]

Firefox bevat anders zat features die OS specifiek zijn. Zo zijn er specifieke OS X en specifieke Windows 7 features die ze ondersteunen. Daarbij komt dat ze dit ook nog eens willen uitbreiden om zo de integratie van de browser in het OS sterk te verbeteren. Die dingen staan op het menu voor 3.7 en 4.0. M.a.w. het is geen enkel excuus om het niet op die manier te doen.

[latka]

Ongetwijfeld dat er Windows specifieke zaken inzitten: niet ieder OS heeft een taskbar. Als het gaat om HTML rendering is cross-platform echter wel een must. Wordt een beetje moeilijk uitleggen aan je gebruikers als de install wel lukt, maar de site het alsnog niet doet omdat ze codec abc niet hebben. Plugins lossen dit deels op maar dan ben je afhankelijk van veelal brakke code van derden (flash anyone).

[elmuerte]

Uit bovenstaande reacties is het duidelijk dat veel mensen het nog niet snappen:

Open Source (Software)
Software waarvan de source code beschikbaar is, en je deze vrijelijk mag gebruiken her-distribueren vaak onder bepaalde voorwaarden. Dit betekend natuurlijk niet dat de software gratis is, maar omdat iedereen de code mag gebruiken en verspreiden zonder kosten is de software in principe gratis.

Open Standaard
Een standaard die iedereen kan inzien en mag gebruiken zonder daarvoor licentie geld te moeten betalen.

Free Software
Bijna synoniem aan Open Source Software, er zijn alleen wat kleine philosofische verschillen.

H.264 is geen open standaard. x264 is een open source implementatie van de H.264 standaard.
Theora is een open standaard, en er zijn ook open source implementaties van deze standaard.
MP3, WMA, AAC zijn ook geen open standaarden. Vorbis is weer wel een open stanaard.

MP4 is geen codec, maar een container formaat, en ook geen open standaard. MKV, OGG en OGV zijn wel open standaard container formaten.

[Verwijderd]

Open Standaard
Een standaard die iedereen kan inzien en mag gebruiken zonder daarvoor licentie geld te moeten betalen

een open standard is een standard die door derden geimplementeerd mag worden, de standaard is ondergebracht en wordt beheerd door een onafhankelijke organisatie. bijvoorbeeld W3C of IEEE of OSI.

dat er geen licenties betaald hoeven worden voor een open standaard is mooi meegenomen maar is mijns inziens niet een vereiste.

het belangrijkste is dat alle partijen evenveel inzicht hebben in de open standaard (documentatie) zodat er een level playing field is voor partijen. geen enkele partij wordt voorgetrokken zodat er een gezonde concurrentie in de implementatie van de standaard onstaat.

[NESFreak]

Windows heeft directshow, linux heeft gstreamer en osx heeft quicktime.
Zeker aangezien er voor gekozen is om geen standaardcodec in te sluiten in de standaard, lijkt het mij persoonlijk een beetje loos dat een browser dus elke potentieel gebruikte codec gaat bijsluiten.

Natuurlijk zou je mijn voorstel natuurlijk ook kunnen opvatten als het afschuiven van het probleem op het besturingssysteem. Zeker op windows zou dit een probleem kunnen worden, aangezien zelfs bij windows 7 het toch nog weer nodig was om een überepiccodecpack te installeren. Ook weet ik niet of osx bijvoorbeeld standaard met theora support komt. Wel komen de meeste linux distro's niet standaard met x264, echter bijvoorbeeld ubuntu bied meteen de mogelijkheid om alsnog ontbrekende codecs te installeren zodra je er eentje tegenkomt.
meteen na installatie sudo apt-get install ubuntu-restricted-extras doen is natuurlijk ook een optie

Daarnaast betekend het afhandelen van de video door het os ook meteen dat je hardwareversnelde videodecodering hebt. Dit zonder dat de browserbouwers daar ook maar iets voor hoeven te doen.

Hiernaast vind ik het een beetje jammer dat, omdat één land toevallig softwarepatenten heeft de rest van de wereld ook meteen hier de dupe van word. Je zou er bijna een europese build (met x264) van firefox voor gaan maken. Bedankt Amerika.

[anandus]

Heeft dit zin zolang er geen codec-standaard voor is?

Dit is toch net zoiets als van die sites die IE-specifieke tags hebben? Alleen zijn het nu Safari- en Chrome-specifieke 'tags'.

Hoe dan ook lijkt mij dit een ongewenst iets, laat ze eerst maar een uitgewerkte standaard voor HTML5 maken (of kunnen codecs niet in een HTML-standaard opgenomen worden?)

[Little Penguin]

Helaas zal er in de HTML5 specificatie geen codec-standaard voorgeschreven worden, simpelweg omdat de fabrikanten die dit element daadwerkelijk zijn gaan implementeren niet eens konden worden over de codec die gebruikt zal gaan worden.

Apple is van mening dat H.264 de beste optie heeft, mede omdat het decoderen van de content geheel of gedeeltelijk uitbesteed kan worden aan de hardware (buiten de CPU om dus). Mozilla aan de andere kant wil deze nu net weer niet implementeren omdat H.264 niet compatible is met de MPL/GPL/LGPL licentie vanwege de patenten die op de H.264 codec rusten.

Opera heeft 't probleem met open source broncode niet, maar is van mening dat de licentiekosten van H.264 simpelweg te hoog zijn.

Gevolg is dat Mozilla Firefox (en andere Gecko-based browsers), Opera en ik meen ook Chromium geen H.264 ondersteuning hebben, maar alleen Ogg Theora ondersteunt. Google Chrome ondersteund zowel Ogg Theora als H.264 en Apple's Safari ondersteund alleen H.264.

Dit is toch net zoiets als van die sites die IE-specifieke tags hebben? Alleen zijn het nu Safari- en Chrome-specifieke 'tags'

Ja, gedeeltelijk wel. Maar in de specificatie van het video-element is weer wel opgegeven dat je alternatieve content op kunt geven op het moment dat je het video-element niet goed weer kunt geven.

Men heeft dus wel geleerd van de Netscape en IE-only tags, en probeert nu in de HTML5-specificatie zo veel mogelijk de issues die je in het verleden had te voorkomen.

[mzziol]

De grote vraag is wat Google aan het uitspoken is met On2. Vorige jaar maakten ze beiden bekend dat Google het bedrijf voor $106 miljoen overnam. On2 claimt een codec te hebben ontwikkeld die beter is dan h264. Bovendien heeft het bedrijf een paar interessante patenten in handen.

Google zegt daarover:

“Although we’re not in a position to discuss specific product plans until after the deal closes, we are committed to innovation in video quality on the web, and we believe that On2 Technologies’ team and technology will help us further that goal.

We’ll update everybody when we’re able to share more information. In the meantime, nothing will change for On2 Technologies’ current and prospective customers.”

De roddel is dat Google van VP8 een open-standaard / open-source codec maakt.

Opera's bezwaar valt dan weg, omdat het gratis is; Mozilla heeft een codec met een open licentie en Apple heeft een codec superieur aan h264. Wat er zal gebeuren is nog afwachten, maar het is zeker een mooie gedachte!

[kidde]

Alleen in de tussentijd wordt het een rotzooi.

Bowsers die de ene standaard ondersteunen (FF/Opera), de andere (Safari), beiden (Chrome), of geen (IE), dan weer plugins die eraan te pas moeten komen om de gaten op te vullen (IE Chrome-tab, FF h.264 plugin), en dan weer een website / webserver die moet gaan uitvinden wat de browser wel of niet ondersteund.

En in de overgangsfase nog volop de aanwezigheid van verschillende versies van Flash die volzitten met veiligheidsgaten. Een specificatie van HTML5 die nog niet 'final' is, en Theora dat nog volop in ontwikkeling is omdat sommigen zeggen dat het nog niet goed genoeg is. Dan nog Adobe dat wel weer met iets nieuws en beters zal komen omdat ze bang zijn dat straks Flash niet meer het internet regeert zoals nu, IE dat waarschijnlijk 'halve' HTML5-support gaat leveren en de onzekerheid over de licenties van h.264 na 2011.

Geweldig, marktwerking (zie ook BluRay vs. HD-DVD) , alleen het geeft zo'n troep en als de stofwolken zijn opgetrokken zitten mensen met allemaal software / plugins die nutteloos zijn geworden.

[CyBeR]

Google Chrome ondersteund zowel Ogg Theora als H.264 en Apple's Safari ondersteund alleen H.264.

Hoe 't met Chrome zit weet ik niet, maar op OSX ondersteunt Safari in ieder geval alles wat de lokale Quicktime kan spelen (dus inclusief Ogg spul als je Perian hebt, bijvoorbeeld.)

[Toolskyn]

Het probleem is er eentje van 'de kip of het ei'. Ik hoop dat dit soort acties van deze sites de andere browsermakers aanmoedigen om allemaal hetzelfde te ondersteunen. Het mooiste zou wat mij betreft zijn dat zowel h.264 als ogg in alle browsers worden ondersteund. Dan kan iedereen lekker zijn eigen formaat kiezen.

Het probleem dat mozilla heeft met h.264 is dat er in de VS patenten op dat formaat zitten. Aan de ene kant zouden ze dan verplicht zijn om royalties te betalen, aan de andere kant zou dat waarschijnlijk (dat is niet helemaal zeker) niet kunnen in combinatie met de licentie die aan mozilla-software vast zit.

Aan de andere kant weigert Apple om ogg te gebruiken, omdat het niet genoeg ondersteund zou worden. Het zou de gebruikerservaring op Apple systemen 'in gevaar brengen' wanneer ze een software-codec zouden moeten gebruiken volgens de redenatie van Apple. En er gaan echt geen hardwarematige ogg-chips komen zolang het vrijwel niet gebruikt wordt.

Ik weet niet precies wat het standpunt van Microsoft is, en of ze uberhaupt wel een standpunt hebben. Waarschijnlijk hebben ze het liefste een web gebaseerd op Silverlight en de Windows Media codecs.

Vanwege al dat gezeur van alle bekende browsersontwikkelaars is besloten om de decoder voor het video-element maar helemaal uit de specificatie te laten. De huidige specificatie zegt nu min of meer: er is een video element, dat gebruikt kan worden om een video in af te spelen.

Ik denk dat Google hoopt dat ze op de een of andere manier Mozilla mee kan trekken op de h.264 weg. Microsoft zal vast ook wel een keer volgen.

[Verwijderd]

Als browsermakers nou slim zijn, maken ze decoders die de browser aan kan op basis van addons, ofzoiets (ik heb niet veel verstand van addons, dus ik weet niet precies of dit technisch gezien zou werken). Dan kunnen sites gewoon een codec gebruiken en als je die nog niet kunt decoden kan je een addon installeren die dat wel kan.

[ZpAz]

Ofterwijl, dan zit je op het punt waar je nu ook zit. Namelijk wil je iets afspelen, ga addon-flash of silverlight maar installeren.

[kidde]

Niet helemaal, Flash is een plugin die buiten be browser om op het OS geinstalleerd moet worden, een add-on blijft 'binnen' de browser.

[depeje]

Maar flash is meer dan alleen een codec.

[ZpAz]

Inderdaad, maar dan zit je alsnog met het feit dat je 'iets' extras moet installeren. En de gemiddelde computergebruiker zal het weinig uitmaken of het nou een codec of flash is, want ze weten toch niet wat het is.

Daarnaast vind ik het zeker wel een vooruitgang, want Flash (HD) filmpjes op Youtube werken gewoon niet fijn (haperdehaper) onder OSX (720p).

En onder Linux is Flash volgens mij ook al een probleemkindje.

[Reactie gewijzigd door ZpAz op 22 juli 2024 17:30]

[Xthemes.us]

En onder Linux is Flash volgens mij ook al een probleemkindje.

Dat heb je helemaal juist, ik zou zelfs zeggen dat is een understatement.

[thegve]

Het is misschien wel nuttig om de voordelen te laten zien. Bekijken hoeveel load dit nu scheelt of extra kost om te serveren ten opzichte van flash. Kijken welke problemen er naar voren komen. Dan kan de feedback die hieruit terug komt gebruikt worden bij het verder verbeteren van de standaard. Google is een van de bedrijven die helpt bij het ontwikkelen van de standaard.
Je moet dus eerst zelf expliciet aangeven dat je van de html5 optie gebruik wil maken, en vervolgens krijg je dezelfde functionaliteit als met de flashplayer. Het is dus niet als met de IE-only sites dat gebruikers van andere browsers minder functionaliteit krijgen.

[Reactie gewijzigd door thegve op 22 juli 2024 17:30]

[CH4OS]

Dan ben ik eigenlijk benieuwd, hoe ze gaan checken of de browser ondersteuning heeft voor de video-tag en de gebruikte codec? Bij (Java)script is dat heel simpel, dat is de script en noscript tag, komt er dan ook een novideo? Het is imo het mooiste om zoiets native te hebben, zoals script en noscript, dan dat je er eerst javascript tegenaan moet gooien.

[Reactie gewijzigd door CH4OS op 22 juli 2024 17:30]

[Zaffo]

Zowel bij YouTube als bij Vimeo moeten bezoekers expliciet aangeven de html5-speler te willen gebruiken.

Je moet dus aangeven dat je gebruik wilt maken van de video-tag, anders krijg je de standaard flash content voorgeschoteld. Als je browser dan geen h.264-codec ondersteuning heeft werkt het niet. Daarnaast kan er natuurlijk gegeken worden of je Chrome of Safari gebruikt.

Toch jammer dat Google eigenwijs is en voor h.264 kiest. Theora video in een OGG (OGM) container en Vorbis audio vereisent geen licentie, is open en geeft met lage bitrates betere kwaliteit. Edit: Bron

[Reactie gewijzigd door Zaffo op 22 juli 2024 17:30]

[dj_tjerk]

Tot 2011 is voor h264 ook geen licentie vereist voor internet streaming/leeching, wat er daarna gaat gebeuren is niet helemaal duidelijk. bron

Wat bedoel je met "open"? Een herhaling van je licentie argument of dat de specificaties van h264 streams niet bekend zijn? (Dat zijn ze wel namelijk) Als je open-source bedoelt, dan zou ik suggereren eens te kijken naar x264 en ffmpeg. Naar mijn mening zijn die toch behoorlijk open-source (tenzij je niet van GPLv2 houdt natuurlijk).

Dat argument dat Theora beter is dan h264 is ook niet helemaal juist. Alleen al met de specificaties van h264 kan je betere kwaliteit behalen, en het gros van de encoders geeft ook betere kwaliteit (maar youtube HQ encoder zuigt hard). Ook is het natuurlijk heel erg fijn als ze een vergelijking doen van encoders zonder de settings te geven.

Om maar even een developer van x264 te quoten uit een reddit thread:

Youtube's "HQ" H.264 encoder is a crap-quality Baseline Profile encoder hacked together by Pascal, one of the old Xvid developers who was hired by Google.

It is terrible. It is likely worse than Xvid in most cases. In some cases I've found that ffmpeg's FLV1 encoding at 350kbps (Youtube standard-quality) outperforms Pascal's encoder at 500kbps (Youtube HQ). That's how bad it is. On the other hand, Youtube HD is encoded with x264. Note the difference.

Comparing Theora against something so bad demonstrates how desperately they are trying to grasp at straws here. Of course, this is done all the time by commercial encoder companies, who compare against the worst of the worst (e.g. Quicktime's H.264 encoding) in order to make their own encoder not look like a piece of junk. But open source developers should be above such scumbaggery.

How about they actually improve the Theora specification to make it suck less instead of spending all their time misleading the public about its capabilities?

Of course, no, instead, they're going to come to this Reddit thread and downvote everything that disagrees with them. And of course I'm right--nearly every single post of mine in this thread other than this one has been downvoted equally completely regardless of what it actually said. Isn't blanket-downvoting people who disagree with you fun?

[Reactie gewijzigd door dj_tjerk op 22 juli 2024 17:30]

[djhartman]

Het grote verschil tussen theora en h264, is dat voor zover bekend, op theora geen geclaimde patenten liggen, en dat patenten die er zijn, expliciet zijn vrij gegeven.

Bij h264 moet je licentie kosten betalen voor gebruik, en die zijn zeer ondoorzichtig. Belangrijk is echter dat Theora niet gegarandeerd patent vrij is. Kan dus zijn dat er alsnog iemand om de hoek komt die licentiegeld van je wil.

In Europa is het twijfelachtig of zoiets als een software patent wel bestaat bij wet. Er zijn er voldoende van geclaimed, maar dit is volgens mij nog nooit Europees getest bij de rechtbank.

[Maurits van Baerle]

Ten eerste zijn h.264 licenties het tegenovergestelde van ondoorzichtig, als er iets makkelijk is... Het is een hele simpele één-loket oplossing, je kunt alles wat je denkt te weten over patenten en dergelijke gerust vergeten, daar heb je namelijk allemaal helemaal niets mee te maken als je het netjes doet en gewoon een licentie afneemt van de MPEG-LA. Tarieven zijn gewoon openbaar en je kunt kiezen uit een prijs-menu voor een hele reeks verschillende opties, van gratis tot duur maar wel met een 'cap', meer dan een bepaald bedrag per organisatie zul je nooit hoeven te betalen. Of Apple nou 5 miljoen of 50 miljoen iPods per jaar verkoopt, boven een bepaalde 'cap' is de licentie per verkocht apparaat gratis.

Ten tweede is de software patent discussie volkomen irrelevant aangezien dit niets met software patenten te maken heeft. Dit gaat niet om abstracte begrippen zoals in software, dit gaat om hele concrete bit-operaties die uiterst nauwkeurig in zo'n codec patent omschreven zijn en gewoon in Europa geldig. Weet je nog dat een Italiaans bedrijf uit naam van Nederlandse en Franse codec-patent houders op CeBIT in Duitsland beslag liet leggen op hardware van fabrikanten die hun licenties hadden ontdoken? Europeser dan dat kan niet...

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 17:30]

[depeje]

Wat bedoel je met "open"? Een herhaling van je licentie argument of dat de specificaties van h264 streams niet bekend zijn? (Dat zijn ze wel namelijk) Als je open-source bedoelt, dan zou ik suggereren eens te kijken naar x264 en ffmpeg. Naar mijn mening zijn die toch behoorlijk open-source

Bedoel je dat het mogelijk is om h264 content af te spelen met een x264 codec? En als dat mogelijk is dat je dat tot in de eeuwigheid mag doen zonder licentiekosten te betalen?

[dj_tjerk]

H264 content kan je afspelen met ffdshow/libavcodec, wat bij mijn weten gewoon open-source is. x264 is geen codec, het is een encoder (net als Ateme, MainConcept/DivX en Elecard). Libavcodec/CoreAVC/DivX/.. zijn decoders.

In dit stukje tekst gaat het dan voornamelijk over vendors van encoding/decoding software (onder a), en daar vallen x264 en ffdshow niet onder. Je kan ook zeggen dat het bij x264/ffdshow gaat om een open-source implementatie en ze eigenlijk alleen verantwoordelijk zijn voor de source, wat op zich geen werkende decoder/encoder is.

Verder zegt het laatste kopje (b)(2) alleen wat over Internet Broadcast, wat daar precies onder valt is mij ook niet precies duidelijk (alleen streaming of ook downloaden). In ieder geval zou ik zeggen dat je een video die je nu al hebt, tot in de eeuwigheid mag blijven afspelen. Wat er gebeurt met videos die ja 2010 download, weet ik niet.

Verder maakt het (hopelijk) voor europa weinig uit, want ik zou h264 nou niet beschouwen als een "non-obvious technical solution". Het borduurt imo vooral voort op andere technieken.

[djhartman]

x264 erkent de patenten niet. Woon jij in een land waar die patenten wel bestaan, dan moet je als gebruiker zorgen dat de licentiekosten betaald worden. (Wat natuurlijk niemand doet).

[Verwijderd]

PS: Zoals hieronder al wordt gezegd is de licentie vaak al betaald...

In Europa zouden er geen patenten voor software mogelijk zijn. Dus die bestaan dan voor ons (in Nederland) eigenlijk niet.

Of dat in de toekomst ook zal zijn is een ander verhaal (jarenlange discussie - dus zelf weten ze het ook niet meer - gaande wat wel en niet eronder kan vallen, combinaties met zowel software hardware etc....)

MAAR dan nog, zou het zo zijn dat je er als gebruiker er in princiepe NIKS van merkt:

-Vaak is de licentie gewoon al betaald of gebeurt dat later alsof.

-Het blijft de verantwoordelijkheid is tussen de makers ervan en degene van wie het patent is. Dus als er iets is gaan ze naar de makers van de software en niet naar de gebruiker.
Je kunt van een gebruiker ook niet verwachten dat hij/zij alles weet van wat er allemaal gaande is met iets dat sowieso al niet zo duidelijk is.

-Er is volgens mij ook geen echt goede reden om de gebruikers zelf aan te klagen.

-Verder trouwens niet bekend wie precies de gebruikers zijn. Software wordt duizenden of soms miljoenen keren gedownload van diverse sites over de hele wereld... En nou niet bepaald opgeslagen wie wat download.

-De software zelf zeker door blijft bestaan, omdat er voor Open-Source tig andere sites zijn die het ook aanbieden (mirror, torrent, etc.)


PS: Of theora helemaal vrij is van patenten weten we niet... Tot nu toe zijn er nog geen claims geweest. Maar er kunnen altijd zelfs ná járen toch weer claims b.v. van grote bedrijven onstaan
Verder is de toekomst ervan onzeker, omdat de verschillende browsermakers er niet eens over kunnen worden. (Theora of H.264)
PPS: Iemand nog opmerkingen of aanvullingen?

[Reactie gewijzigd door Verwijderd op 22 juli 2024 17:30]

[kidde]

Ja, opmerkingen en aanvullingen:

-In het geval van MP3 besloten de rechthebbenden geen geld te eisen voor 'vrije' implementaties en van eindgebruikers. Alleen van grote bedrijven, zoals o.a. Microsoft. Hopelijk gebeurd dit ook voor h.264.

-In Europa is software 'as such' niet patenteerbaar, doorgaans vertaald als 'software op zich'. Als het patent niet 'software op zich' is, dus over hoe een stukje code samenwerkt met 30 onderdelen van een MRI scanner, of hoe het gebruik maakt van een gedistribueerd netwerk, zijn softwarepatenten mogelijk wel afdwingbaar.

-VZIW verdient Apple aan Quicktime, Microsfot verdient ook aan mediaformaten, dus ze hebben liever niet dat er 'gratis' formaten zoals Theora gemeengoed op het internet worden, want dan verdienen ze er niets meer aan. De mensen van Xiph hebben geprobeerd om Theora ondersteuning op de officiele Quicktime-plugin site van Apple te krijgen, maar Apple wil daar niet aan meewerken. Naar alle waarschijnlijkheid verdient Microsoft redelijk wat aan VC1, dus die zitten ook niet op Theora te wachten.

-Omdat zoals boven gezegd Mozilla, Apple en Google het niet eens konden worden over een standaard voor de video tag, is laatstgenoemde dus niet gestandaardiseerd in HTML5.

-IE gebruikers kunnen IE-tab extensie met Chrome gebruiken om toch HTML5 te kunnen 'browsen'.

[depeje]

MAAR dan nog, zou het zo zijn dat je er als gebruiker er in princiepe NIKS van merkt:

Wat ik denk ik wel nog kan merken als gebruiker is dat door de licentiekost mijn favoriete browser h264 nooit gaat ondersteunen. Ik denk dan zeker aan Firefox en Konqueror, maar ook de openste van de openste zoals Dillo en Midori.

[Verwijderd]

Even een 'kleine' correctie: H.264 zat al in de Flash versie van 2007 ( http://blogs.zdnet.com/Stewart/?p=501 ) en (de flash plugin) is praktisch op elke computer ook geïnstalleerd.

De discussie hier ging dan vooral om het gebruik van de 'H.264 codec' als webstandaard geïntegreerd in de browser zelf, wat dus eigenlijk wel 'een beetje' het wiel opnieuw uitvinden is...

En idd, HTML5 (waar dus die video tag inzit) opzich zal ook nog wel even of zich wachten voordat (zo goed als) iedereen het kan gebruiken.

Zie bijv. de ontzettend langzame ontwikkelingen bij Internet Explorer (nieuwste versie nog steeds geen ingebouwde ondersteuning video tag) en het langzame overstappen van mensen en bedrijven op een andere browser.
En de discussie tussen de browsermakers zelf over o.a. welke codec er nou gebruikt moet worden.

Mensen moeten het voordeel hier het praktisch nut nog ervan inzien (welliswaar open-source en promoot paar mogelijkheden van video, maar nog lang niet overal beschikbaar bij mensen, weinig gebruikt, toekomst is nog onzeker, speelt HD videos minder goed af, doet praktisch wat flash ook kan)

En zoals Xthemes.us al een beetje zegt: Tegen de tijd dat ze hier uit zijn, zijn de patenten wie weet al verlopen.

Gelukkig dat het nou niet écht zo'n groot probleem is - Want anders....

[Xthemes.us]

Dillo ondersteunt sinds 2009 amper ' basic css'?
Met een beetje geluk zijn de patenten verlopen tegen de tijd dat ze uberhaupt het ondersteunen van <video> eens gaan overwegen

[depeje]

Maar ik heb wel betaald voor mijn grafische kaart die zelf ook h.264 kan decoderen. Ik neem aan dat ik dus ook het recht heb (ook als ik in de VS zou wonen waar die patenten wel bestaan) om deze content af te spelen.

[Munters]

Helaas, zo werkt het niet. Ik heb betaald voor mijn auto die 180 km/uur kan. Maar dat betekent nog niet dat ik het recht heb zo hard te rijden.

[Zaffo]

Ja x265 is een decoder en kan dus decoderen, daarnaast is deze vrij (free-software) te gebruiken (wat ik ook met open bedoel) en beschikbaar onder GPLv2 (hou ik van hoor).

Maar ik vraag me meer af wat de regels zijn om content in .265 aan te bieden, of is met x.265 decoded meteriaal ook vrij?

[lembregtse]

Je moet ook begrijpen, Google heeft met een enorme bandbreedte te maken voor al deze filmpjes. Wat ze dus doen is opzoek gaan naar een manier die zoveel mogelijk bandbreedte bespaard en zo weinig mogelijk kwaliteit moet inleveren. Blijkbaar heeft na veel testen uitgewezen dat ze tot het beste resultaat komen met de h264 codec, en niet met OGG Theora.

Trouwens in de bron die je aanhaalt wint Theora het tegenover h.263 niet h.264, die wordt er ook bijgenomen en daar zegt men uiteindelijk het volgende over:

In the case of the 499kbit/sec H.264 I believe that under careful comparison many people would prefer the H.264 video. However, the difference is not especially great.

Laat ze nu maar gewoon eens tot een eensgezinde oplossing komen, wie weet samen met h.264 of met een andere betere.

Nog een interessant stuk uit http://www.osnews.com/thread?405356:

Regardless of any quality discussion, h.264 is for
YouTube definitley the better codec.

The big problem is the transmission of the content configuration of the data stream. Where h.264 defines a clear data stream where the configuration ( width, height, decompression tables) are transported with a defined network abstraction layer that is defined in the spec, Theora has a different aproach. You need to configure your decoder before you can feed it the datastream.

Just in the moment I am in the middle of implementing a video chat system and want to have Theora support next to h.264 as well. The h.264 implementation was pretty straightforward. You just feed the decoder with the datastream and eventually you get decoded pictures. With Theora you need to make sure that the receiver has all necessary configure parameters of the codec, so that he can start decoding the datastream. So
I decided to send the data setup seperatley through a TCP connection where I could be sure that receiver got it correctly. That was really a pain, since the system wasn't designed to communicate like that.

You can read about that here: http://tools.ietf.org/html/draft-barbato-avt-rtp-theora-01

En google heeft er natuurlijk nog veel meer.

[Reactie gewijzigd door lembregtse op 22 juli 2024 17:30]

[Maurits van Baerle]

Voor Google zal er nog iets anders meespelen, al hun films zijn nu al h.264 dus er hoeft niet geconverteerd te worden.

Op dit moment wordt de h.264 in flash ingepakt voor de meeste browsers en voor bijvoorbeeld de iPhone rechtstreeks doorgestuurd. In alle gevallen, Flash, andere platformen en HTML5 is en blijft de codec h.264. Als ze naar Theora zouden overstappen moeten ze vele terabytes aan video ineens gaan converteren naar een ander formaat.

[Verwijderd]

betekend dat als er support voor komt dat je strax wel films zou kunnen afspelen op je iphone.

De eenige reden dat ik het vervelend vind is dat ik geen films op internet sites kan bekijken. Zoals anime etc.

Zou dit de oplossing voor mij kunnen zijn ?

[AndrewF]

Je kan met een iPhone wel degelijk films afspelen. Daar heeft Apple namelijk het HTTP Live Streaming "protocol" voor ontwikkeld. surf gerust een naar iphone.akamai.com voor filmpjes.

De Flash Player implementatie op Mac is heel inefficient en zou de batterij van een iPhone heel snel opsouperen. Daarom heeft Apple gekozen om Flash te verbannen en willen ze met hun streaming protocol (ism HTML5 video tag) een efficiëntere oplossing voorleggen.

Ik schrijf er momenteel een paper over, en de client implementatie van Flash heeft een 4x hogere cpu load dan HTTP Live Streaming en 3.5x hoger dan RTP/RTSP (op MacOS).

[TheBorg]

Dan zou ik er in je paper rekening mee houden dat de laatste versie van de Flash player op een heleboel devices hardwarematige video acceleratie heeft. Je stelling klopt dan ook waarschijnlijk niet meer.

Zie hier voor meer info: http://labs.adobe.com/technologies/flashplayer10/

[AndrewF]

Ik hoop dat de nieuwe Flash player dan ook op het Mac platform daar gebruik van zal maken.

Mocht je de paper willen lezen/bekijken: http://andrewsblog.org/a_review_of_http_live_streaming.pdf
(vanaf pagina 20 vergelijk ik de performance)

Toch vind ik het een bewijs van ondermaatse implementatie als het afspelen van dezelfde video met HTTP Live Streaming 16% cpu load kost, 21% met RTP/RTSP en 78% met Flash Video Player.

[Reactie gewijzigd door AndrewF op 22 juli 2024 17:30]

[Maurits van Baerle]

Ik heb zelf geen iPhone dus kan het niet testen maar inderdaad zou de iPhone HTML5 met h.264 filmpjes moeten ondersteunen. Of het nu al zover is weet ik niet maar aangezien Safari de HTML5 video tag ondersteunt en de iPhone hardware decoding voor h.264 heeft lijkt dat me geen probleem.

Probeer het zelf anders eens door met je iPhone naar Vimeo.com te gaan (YouTube heeft geen zin want die hebben aangepaste pagina's voor iPhone bezoekers). Probeer bijvoorbeeld deze film en kies dan rechts onderin 'Switch to HTML5 player'.

[ppl]

Toch jammer dat Google eigenwijs is en voor h.264 kiest.

Google kiest daar niet expliciet voor, Google gebruikt de webkit engine en laat die nou alleen h.264 met die video tag ondersteunen.

Je bron is overigens onbetrouwbaar omdat het de makers zelf zijn die zeggen dat het beter is. Dat is vrij normaal want toegeven dat je codec bagger is betekent de doodsteek (hiermee wil ik niet zeggen dat ogg theora bagger is). Het is dan ook het bekende "wij van wc-eend adviseren wc-eend" verhaaltje. Een onafhankelijke bron die stelt dat ogg theora beter is dan h.264 is een stuk sterker. Zelfde geldt natuurlijk ook voor h.264. Aan de overige reacties te zien wordt je bron ook al aardig ontkracht.

[user109731]

HTML tussen <video> en </video> wordt alleen weergegeven door browsers zonder video support. Dat kun je dus gebruiken om een flash-player weer te geven. Verder kun je met JS via canPlayType kijken of een bepaalde codec beschikbaar is.

[Hero of Time]

HTML tussen <video> en </video> wordt alleen weergegeven door browsers zonder video support.

Waar zet je dan je video neer als je de HTML5 methode wilt gebruiken? Juist, tussen <video> en </video>. Je zegt het dus verkeerd, video tussen de tags wordt afgespeeld door browsers die het WEL ondersteunen .
Mocht ik het fout hebben, leg het dan beter uit, niet iedereen is een webontwikkelaar en heeft zich in de nieuwe specs verdiept.

[stefanos1990]

versimpeld voorbeeldje:

<video src="html5video.avi">
<flashobject src="flashvideo.swf"></flashobject>
</video>

de browsers die de video tag niet herkennen negeren die en lezen dus alleen:
<flashobject src="flashvideo.swf"></flashobject>

de browsers die de video tag wel kennen zullen weten dat wat er tussen de tags staat code is voor incompatible browsers. en lezen alleen:
<video src="html5video.avi">
</video>

[Reactie gewijzigd door stefanos1990 op 22 juli 2024 17:30]

[ytsmabeer]

Maar nu het volgende, Opera 10.5 en Fx3.6 ondersteunen de video tag wel maar hebben niet de juiste codec. wordt dan de video gewoon niet afgespeelt?

[stefanos1990]

Je kan in de video tag als web developer ook twee video files noemen, de browser kiest dan automatisch de file die geschikt is om af te spelen.

Maar bij websites zoals youtube die maar één codec ondersteunen is dat dus inderdaad nog geen oplossing.

[ppl]

Het is sowieso geen oplossing omdat je dan de content 2x moet opslaan. Diskspace is niet bij iedereen toereikend. Als je dat gaat betrekken op Vimeo en YouTube dan gaat dat niet om een paar honderd Megabytes of Gigabytes maar heel wat meer en juist dan is het een gigantisch probleem geworden. Een veel betere oplossing is dat de strijdbijl begraven wordt en men beide standaarden in de diverse webbrowsers implementeert. Kan de content aanbieder zelf kiezen wat ze willen. Met de huidige situatie is die html5 video tag nogal useless. Als ik kijk naar wat SilverLight kan dan zou ik als content aanbieder toch eerder voor SilverLight gaan, dat werkt tenminste in vrijwel iedere browser in Windows en OS X. Linux is het enige zorgenkindje omdat zij met een achtergestelde SilverLight player zitten die overigens nog altijd een stukje verder is dan Flash.

[Verwijderd]

Maar wat dacht je van apparaten die geen Windows, OSX of Linux hebben? Daarvoor is de videotag veel makkelijker te implementeren dan Flash of Silverlight. Denk aan gameconsoles, telefoons, etc.

[kidde]

Daar zijn voor Firefox dan weer plugins voor. Hier een POC:

http://old.nabble.com/h26...r-firefox-td26981431.html

[ppl]

Volgens mij moet Gecko daar ook mee om kunnen gaan. De renderengine moet dus wel weten dat als hij bij het zien van een video tag h.264 content voorgeschoteld krijgt dit dan kan afspelen via die h.264 plugin. Volgens mij is het hard coded in Firefox dat ze alleen maar ogg theora gebruiken. Dat zou betekenen dat je met die plugin nog niets kan omdat Mozilla een aanpassing in hun code moet maken.

[Maurits van Baerle]

Zo te zien wordt die dan inderdaad gewoon niet afgespeeld. Dat is waarschijnlijk op twee manieren op te lossen: User-agent sniffing of nog een extra fallback option naast Flash, het zal waarschijnlijk niet lang duren tot iemand daar een mooie standaard oplossing voor vindt.

[Hero of Time]

Kijk, dat is nog eens nuttige informatie . Iedereen hierboven (en spuit 11 hieronder) zeggen het wel leuk, maar je hebt er alsnog geen zak aan als je maar een half jaar HTML hebt gehad. Dit soort misverstanden zijn het beste op te lossen via daadwerkelijke voorbeelden, en niet blaten wat het doet en hoe en weet ik veel wat nog meer.
Een plaatje zegt meer dan 1000 woorden, in dit geval een stukje code zegt meer dan een heel verhaal.

[Herko_ter_Horst]

Het is altijd al zo geweest dat browsers tags die ze niet kennen overslaan en gewoon verder gaan met wat er tussen de tags staat. Dat is bijvoorbeeld reden dan je script tags vaak gevolgd worden door commentaar.

Wat JanDM zegt, klopt dus: een browser die de video-tag NIET support, zal de tag zelf negeren en de inhoud renderen (en daar zou dus een flash object kunnen staan). Een browser die de video-tag WEL support, zal de video-tag zelf gebruiken om video af te spelen (de inhoud van de video-tag wordt dan genegeerd).

[ppl]

Dat is denk ik niet de denkwijze van Hero of Time. Als de pagina geladen is kun je in menig webbrowser rightclicken op de pagina en kiezen om de broncode te zien. Doordat browsers die geen html5 support hebben en browsers die de codec die voor de video tag gebruikt wordt niet support die stukjes overslaan zul je die ook niet terug vinden als je de broncode bekijkt. Ik moest bij het lezen van de reactie van JanDM aan exact hetzelfde denken en vroeg me ook al af of hij wel eens de broncode in de webbrowser had bekeken. Ik heb het trouwens zelf getest met het Magic Mouse filmpje op de Apple site. Dat werkt in Safari met de video tag en in Firefox met Flash. Als je in beide browsers dan de broncode bekijkt zie je dat ook terugkomen.

[Denni]

Niemand zegt ook dat het de enige manier is om flash of video te gebruiken.. Het is inderdaad mogelijk door een flash filmpje in de videotag te zetten maar het kan ook met JavaScript of zelfs server-side aangezien browsers altijd in de header informatie meesturen wie ze zijn.
Waarschijnlijk doet apple dit serverside. Dit zou als voordeel hebben dat er minder data verstuurd hoeft te worden.

[pat42]

Dat is bijvoorbeeld reden dan je script tags vaak gevolgd worden door commentaar.

Dat zijn totaal achterhaalde technieken die al sinds IE5 niet meer nodig zijn. Om een of andere reden blijven ze echter in tutorials opduiken, maar het is echt totaal overbodig.

[Reactie gewijzigd door pat42 op 22 juli 2024 17:30]

[crisp]

volgens mij was Netscape 3 de laatste browser waarvoor dat nog nodig was

[PV85]

Die video voor HTML5 video zet je in de attributen van de video tag.

Wanneer een browser HTML5 video ondersteund zal het deze methode gebruiken en wat tussen die video tags staat met rust laten.

Wanneer een browser HTML5 video niet ondersteund zal de browser het HTML gedeelte uitvoeren wat er tussen staat. Dit dient dan als fallback methode.

Volgens mij werkt het zo?

[Reactie gewijzigd door PV85 op 22 juli 2024 17:30]

[Verwijderd]

Nee hoor, hoewel heel vaag uitgelegd, heeft ie het wel goed.
Als een browser support heeft voor de <video> tag, dan zie je een geëmbed filmpje, zo niet, dan staat er <video>youtube.com/banenpuree</video>, aangezien de tag niet herkend wordt, wordt het op de pagina gezet als standaard text.

[varkenspester]

Hij zegt toch duidelijk 'HTML tussen de video tag wordt niet weergegeven'. De video (die geen HTML is) wordt uiteraard wel weergegeven.

[SvMp]

Zeer welkome ontwikkeling! In FreeBSD werkt Flash video voor geen meter, in Linux is het niet prettig om een closed-source programma te installeren. Het zou prachtig zijn als Flash overbodig wordt en zonder plugins kunnen Youtuben.

[bzerk]

gnash heeft een heel redelijke plugin die bij mij onder FreeBSD youtube "ontsluit". Maar inderdaad, het wordt de hoogste tijd dat die afhankelijkheid van flash voor videosites ophoud.

[SvMp]

GNash doet het redelijk, maar bij mij geen geluid, filmpjes niet op juiste snelheid. Daarnaast vreet Gnash veel CPU-tijd vooral op websites met meerdere flash-elementen. Niet optimaal dus.

[Little Penguin]

Alleen is het dan nu net weer wel jammer dat men gebruik maakt van een coded (H.264) die volgens de meeste open source mensen niet compatible is met de populaire open source licenties (GPL e.d.).

Als men dan toch een gebaar wilt maken naar de open source gemeenschap, dan zou men gelijk verder moeten gaan met Ogg Theora of in elk geval Ogg Theora ook moeten ondersteunen....

[RoBBS]

Leuk bedacht natuurlijk, maar is het niet beter eerst de basis eens goed te krijgen, het gaat de goede kant op maar af en toe zijn er nog steeds zulke rare verschillen tussen de manier waarop browsers een site renderen. Imho is een goede fundering belangrijker dan native video kunnen afspelen.

[Little Penguin]

maar af en toe zijn er nog steeds zulke rare verschillen tussen de manier waarop browsers een site renderen

Is dat echter een probleem van die site of van de browser? Vaak heb je render-problemen als de site gebruik maakt van browser-specifieke constructies, die niet ondersteund worden door de browser die jij nu net gebruikt.

Dat soort sites moeten zelf de code aanpassen en niet de browser aan de site...

Als je verder moet wachten op een 100% (pixelpreciese) rendering door alle grote browsers kan je pas over 15+ jaar aan nieuwe features gaan werken - ook niet echt wenselijk dus.

[SvMp]

De huidige versies van gangbare niet-IE browsers voldoen grotendeels aan de standaard. Dus ik zie het probleem niet. Wat ik met Firefox ontwikkel, ziet er ook goed uit in andere browsers. Alleen IE heeft nog rariteiten, en dingen die niet ondersteund worden (zoals ronde hoeken opgemaakt in CSS).

[i7x]

Ook bij YouTube is fullscreen niet meer mogelijk wanneer je HTML5 aan zet hoor.

Wel jammer dat filmpjes met advertenties nog wel gewoon in Flash worden getoond. Ik ben erg blij met deze nieuwe speler. Lijkt mij ook vooral handig voor Mac users omdat Flash daarop meestal dramatisch slecht draait.

[torp]

Lijkt mij ook vooral handig voor Mac users omdat Flash daarop meestal dramatisch slecht draait.

Dat valt best mee hoor. Van slecht draaien merk ik niks. Wel dat bijv. m'n browser soms vastloopt door Flash (vooral bij de Volkskrant heb ik daar weleens last van) maar dat is misschien gewoon slecht geïmplementeerd.

[Jarige]

"Wel jammer dat filmpjes met advertenties nog wel gewoon in Flash worden getoond."
Je kijkt graag advertenties op internet?

Lijkt me zelf juist heerlijk om Flash er af te gooien, mede door die advertenties. Ik denk dat advertentiemakers de video-tag wel gaan gebruiken, jammer genoeg... Maar dan hebben we altijd nog Addblock plus die dat kan blocken, en hebben we geen NoScript meer nodig (iig niet voor dat doeleinde)

[prinsrichard]

Die filmpjes die vimeo gebruikt voor de speler zijn echt veel beter, bij youtube krijg je volgens mij gewoon de iphone versie van de filmpjes, echt lelijk op een groot scherm.

[ZpAz]

Hier krijg ik juist wel nette beelden, zal wel verschillen per filmpje denk ik nog.

[AndrewF]

Ik denk dat de bron van de video belangrijker is. Het zijn namelijk vaak gewone consumenten die de video moeten uploaden.

@Tweakers: Wanneer gaan jullie de video tag ondersteunen voor jullie videos? Als ik de video van Heavy Rain probeer af te spelen op mijn 1.8Ghz dual core MacBook haal ik 3 frames per seconde

[Verwijderd]

2.8Ghz dual core mac book pro is niet veel beter, misschien een probleem aan de server kant?

[woekele]

Flash gaat tenminste wel hardware-decoding ondersteunen, dat betekent dus dat je op youtube soepel hd-filmpjes kunt kijken met een atom-processor. Met de video-tag in de browser gaat dat (nog) niet lukken, helemaal niet als er voor theora gekozen wordt lijkt me, aangezien videokaarten alleen vc1/h264/mpeg2 ondersteunen meestal.

[ZpAz]

Volgens mij kan je juist dmv de door Youtube gekozen codec wel met HTML5 video gebruik maken van de hardware-decoding in je pc/mac.

[woekele]

Nou, de door youtube gekozen codec is h264, dus die wordt wel ondersteund door de videokaart. Echter, de browser zal dan dus wel zodanig met je videokaart moeten kunnen communiceren dat hij ook gebruik maakt van hardware-decoding. Dat is voor zover ik weet nog niet het geval.

Aangezien firefox, opera en IE geen ondersteuning bieden voor h264, zal het voor veel mensen helemaal niet werken, ook niet zonder hardware-decoding.

Oplossing: alle browsers h264 ondersteunen, en allemaal ondersteuning inbouwen voor dxva

[ZpAz]

Sinds safari 4 zijn er meerdere dingen die met de GPU worden gedaan in de browser (renderen, CSS3 transistions, webgl ook heeft Firefox hier volgens mij ondersteuning voor (webgl althans). )

Lijkt me dus dat de mogelijkheid dat h264 via de GPU gedaan (kan) worden in de browser niet uit te sluiten is.