Ik ben van scratch begonnen aan een nieuwe testcase waarin net voor de initialisatie van de speler de playlist wordt ingeladen en de video-tag met bronnen dynamisch wordt gegenereerd en in het document geplaatst, gevolgd door een aanroep van de load()-functie op de video-tag om de speler te initialiseren. Voor het inlezen van de playlist heb ik zelf een parser geschreven in javascript om het cache-probleem van de google feed (test case #1 - bug#5) te elimineren.
Naderhand werden buttons voorzien op dezelfde methode als in test case #1. Bij klik op de buttons wordt de respectievelijke playlist-data opgevraagd en meegegeven aan de functie "src", voorzien door het VideoJS-API om de nieuwe bron aan de speler te koppelen en de speler te herladen (zonder refresh).
Report:
bug#1 Ajax-request naar rss-playlist faalt: data.responseXML geeft geen resultaat.
Oorzaak: Ajax-request kunnen enkel gemaakt worden naar de eigen server, geen andere server. Vermits de rss-playlist zich op een andere server kan bevinden moet we hiervoor een oplossing zoeken.
Oplossing: Omwille van snelheids-overwegingen en ontlasting van de server heb ik de rss-parser geschreven in javascript (client-side execution), maar om deze fout op te lossen kunnen we niet anders dan een call doen naar een script op de eigen server, die vervolgens de playlist op de remote server opvraagt en terugstuurt naar de client. Hiervoor heb ik een php-script geschreven dat d.m.v. een curl-commando de playlist die de client als parameter in de ajax-call meegeeft controleert op bestaan, opvraagt en xml-bestandsindeling en syntaxfouten controleert, en ten slotte de inhoudt van het bestand met xml-header terugstuurt naar de client. De cliënt ontvangt op deze manier wel playlist. We hebben nu ook volledige controle over caching, dat geforceerd vermeden kan worden door bij elke aanroep een unieke dummy-parameter mee te geven aan de URL-zodat deze nooit hetzelfde is. (Deze methodiek is momenteel nog niet toegevoegd omdat het zo al werkt).
SOLVED
bug#2 De speler blijft de lader weergeven en begint niet met spelen in Chrome
Oorzaak: Error treedt op bij initialisatie. Het TECH-playback engine van VideoJS plaatst het eerste videobestand dat ondersteund wordt door de gebruikte browser als src-attribuut bij de video-tag en verwijderd niet alle source-tags tussen de videotag. (Het engine doet dit omdat het gebruik van source-tags tussen de video-tag leidt tot fouten of onnodige video-objecten in het DOM bij een dynamische reload (de videobronnen aanpassen zonder de pagina te vernieuwen), het engine uitschakelen is dus geen oplossing). Hierdoor treedt een bronnenconflict op: zowel het src-attribuut als een source-tag zijn gedefinieerd en bevatten beide een verschillend bestand (resp. mp4 en ogg), waarmee Chrome problemen heeft.
Bij het statische reload van dezelfde videobron zijn wel alle source-tags verdwenen. Dit lijkt een bug in de VideoJS-library.
Oplossing: Na aanpassing van enkele regels code in de library worden de source-tags wel correct verwijderd en werkt de speler in Chrome.
SOLVED
bug#3 Speler verschijnt niet in IE
Oorzaak: Speler initialiseert niet. Error treedt op in de parser. De DOM-functies getElementsByNameNS om nodelist te verkrijgen (als een namespace gebruikt wordt) en hasAttribute zijn niet in alle browsers ondersteund, waaronder IE.
Oplossing: In de browsers waarin getElementsByNameNS niet is ondersteund kan een node met namespace ook opgevraagd worden met de standaard getElementsByName. Wanneer deze functie dus niets teruggeeft, moet de NS-specifieke functie gebruikt worden. De hasAttribute-functie kan vervangen worden door een test met getAttribute op null.
SOLVED
bug#4 Speler blijft lader weegeven en begint niet te spelen in IE
Oorzaak: Na research op het internet blijkt dat een videobron die zich bevindt op de eigen webserver relative gedefinieerd moeten zijn, op een externe server absoluut moet gedefinieerd zijn.
Oplossing: Videobronnen plaatsen op andere webserver, .htaccess file voorzien op de server (in de map met videobestanden) en URL's van de bronnen absoluut maken in de rss-playlist.
SOLVED
bug#5 Flash-probleem treedt nog steeds op: videospeler bevriest enkele seconden tot minuten alvorens de video begint te spelen.
Oorzaak: Vermoedelijk downloadt het videobestand eerst volledig in het cache voordat de speler pas begint te spelen; dit omdat korte video's (zoals ook de demo op videojs.com) nagenoeg onmiddellijk beginnen te spelen en de vertraging bij grotere video's langer is. Na research op het internet blijkt dit inderdaad het geval én dat MP4-bestanden kunnen geoptimaliseerd worden voor het web (waarbij een bestand met metadata over het laden van het bestand niet achteraan de videofile, maar vooraan de videofile wordt geplaatst in de container), waardoor de Flash-speler onmiddellijk toegang heeft tot de laad-informatie zodat het deze direct kan toepassen en reeds met afspelen kan worden begonnen alvorens de video volledig gedownload is.
Oplossing: Video's opnieuw converteren met behulp het programma "Handbrake" dat een optie "optimaliseren voor het web" bevat. Het resultaat blijkt zeer positief!
SOLVED
De speler lijkt nu in alle browsers te werken, zowel in HTML5- als Flash-modus. Een demo kan hier bekeken worden: http://mvcpeer.be/uhbpmedia/demo3/video.html
dinsdag 22 mei 2012
Test case #2
In een nieuwe versie kon bug#2 opgelost worden worden.
Report:
bug#2: Firefox speelt geen webm
Is te wijten aan fout in de configuratie van de webserver waarop de videobron zich bevindt. De webserver moet de MIME-types van het webm- en ogg-videoformaat ondersteunen en dit kan gemakkelijk ingesteld worden d.m.v. een .htaccess serverconfiguratie-bestand:
Report:
bug#2: Firefox speelt geen webm
Is te wijten aan fout in de configuratie van de webserver waarop de videobron zich bevindt. De webserver moet de MIME-types van het webm- en ogg-videoformaat ondersteunen en dit kan gemakkelijk ingesteld worden d.m.v. een .htaccess serverconfiguratie-bestand:
AddType video/ogg .ogv AddType video/mp4 .mp4 AddType video/webm .webmVoor de overgie bug#3 en bug#5 werd geen onmiddellijke oplossing gevonden.
vrijdag 11 mei 2012
Bugreport
bug#1: Firefox errorcode4: source not supported
Firefox: video wordt niet herkend als de source zich lokaal bevindt en de URL absolute is, URL moet relative zijn. Als de source zich niet lokaal bevindt moet de URL absolute zijn.
Opera & Chrome: URL mag in beide gevallen absolute zijn.
SOLVED
bug#2: Firefox speelt geen webm
Wanneer webm het tweede formaat in de rij is, geeft de speler een error (source not supported). Oorzaak onbekend.
UNSOLVED
Mogelijke oplossing: Zet steeds ogg als tweede formaat (na mp4)
bug#3: Playlist in Flashmode duurt te lang.
Wanneer er op volgende video wordt geklikt duurt het een heel tijdje alvorens de volgende video begint te spelen. Oorzaak onbekend.
UNSOLVED
bug#4: Javascript-functie JSON.parse() wordt niet ondersteund door elke browser.
Vervangen door andere Javascript-code die gebruikt maakt van een array van objecten, ipv. string die ingeladen wordt door de JSON-functie.
SOLVED
bug#5: Google feed API lijkt het cache nooit te updaten.
Oorzaak onbekend.
UNSOLVED
Firefox: video wordt niet herkend als de source zich lokaal bevindt en de URL absolute is, URL moet relative zijn. Als de source zich niet lokaal bevindt moet de URL absolute zijn.
Opera & Chrome: URL mag in beide gevallen absolute zijn.
SOLVED
bug#2: Firefox speelt geen webm
Wanneer webm het tweede formaat in de rij is, geeft de speler een error (source not supported). Oorzaak onbekend.
UNSOLVED
Mogelijke oplossing: Zet steeds ogg als tweede formaat (na mp4)
bug#3: Playlist in Flashmode duurt te lang.
Wanneer er op volgende video wordt geklikt duurt het een heel tijdje alvorens de volgende video begint te spelen. Oorzaak onbekend.
UNSOLVED
bug#4: Javascript-functie JSON.parse() wordt niet ondersteund door elke browser.
Vervangen door andere Javascript-code die gebruikt maakt van een array van objecten, ipv. string die ingeladen wordt door de JSON-functie.
SOLVED
bug#5: Google feed API lijkt het cache nooit te updaten.
Oorzaak onbekend.
UNSOLVED
donderdag 10 mei 2012
Video voor iedereen - test case #1
Na een stuk schrijven aan de thesis ben ik begonnen met het implementeren van een videospeler die zowel in HTML5 werkt, alsook kan terugvallen op Flash als HTML5 niet ondersteund is. De speler ziet er in beide gevallen identiek uit, dus de eindgebruiker merkt geen verschil. De videospeler moet ook RSS-playlist ondersteuning hebben.
Om dit geheel te implementeren heb ik gebruik gemaakt van de VideoJS-library. Dit is een API met een standaard skin die gebruikt kan worden om een video af te spelen in HTML5 en Flash. De library ondersteunde echter geen playlist, dus ik heb ik geprobeerd de library uit te breiden met playlist-ondersteuning, bestuurd door twee knoppen (vorige en volgende) in de skin. De RSS-playlist wordt geparsed met behulp van Google's Feed API. Beide methodes (HTML5 en Flash) gebruiken het API met de nieuwe, toegevoegde functionaliteiten.
De uitbreiding was minder eenvoudig als gedacht en het heeft veel tijd gekost om de library te begrijpen omdat deze niet gedocumenteerd is, enkel het bestaande API. Het is me vandaag gelukt om playlist-functionaliteit werkende te krijgen in Google Chrome. In de andere browsers lijkt het updaten van de source momenteel nog een error te veroorzaken.
Een eerste testcase staat online: http://mvcpeer.be/uhbpmedia/demo2/video.html
De videospeler start (in elke browser) met het spelen van de standaardvideo, die in de bron wordt aangegeven. Tevens wordt een (voorlopig standaard) playlist ingelezen. Bij het klikken op de knop volgende/vorige wordt de respectievelijke video uit de playlist ingeladen.
Ik ga nu proberen de bug te verhelpen en enkele andere stukken code aan te passen zodat errorhandling effectiever wordt. Mogelijk is het ook handig dat de videospeler direct de eerste video in de playlist begint te spelen.
Om dit geheel te implementeren heb ik gebruik gemaakt van de VideoJS-library. Dit is een API met een standaard skin die gebruikt kan worden om een video af te spelen in HTML5 en Flash. De library ondersteunde echter geen playlist, dus ik heb ik geprobeerd de library uit te breiden met playlist-ondersteuning, bestuurd door twee knoppen (vorige en volgende) in de skin. De RSS-playlist wordt geparsed met behulp van Google's Feed API. Beide methodes (HTML5 en Flash) gebruiken het API met de nieuwe, toegevoegde functionaliteiten.
De uitbreiding was minder eenvoudig als gedacht en het heeft veel tijd gekost om de library te begrijpen omdat deze niet gedocumenteerd is, enkel het bestaande API. Het is me vandaag gelukt om playlist-functionaliteit werkende te krijgen in Google Chrome. In de andere browsers lijkt het updaten van de source momenteel nog een error te veroorzaken.
Een eerste testcase staat online: http://mvcpeer.be/uhbpmedia/demo2/video.html
De videospeler start (in elke browser) met het spelen van de standaardvideo, die in de bron wordt aangegeven. Tevens wordt een (voorlopig standaard) playlist ingelezen. Bij het klikken op de knop volgende/vorige wordt de respectievelijke video uit de playlist ingeladen.
Ik ga nu proberen de bug te verhelpen en enkele andere stukken code aan te passen zodat errorhandling effectiever wordt. Mogelijk is het ook handig dat de videospeler direct de eerste video in de playlist begint te spelen.
dinsdag 7 februari 2012
Video op het web
Tot op vandaag was er geen algemene standaard om video weer te geven op het web en werd voornamelijk een plug-in gebruikt, zoals Adobe Flash. Met HTML 5 is <video> het standaard element om video te embedden op een website.
Een overzicht van de attributen van de tag: W3Schools.
Binnen de <video> tag kunnen meerdere <source> tags worden opgenomen die linken naar verschillende video-bestanden. De browser zal het eerste video-bestand kiezen dat het herkent. Er is ook het <track> element dat kan linken naar een tekst-bestand, onder meer gebruikt voor ondertitels of captions.
Er zijn momenteel 3 video-codecs ondersteunt in HTML 5:
Een overzicht van de attributen van de tag: W3Schools.
Binnen de <video> tag kunnen meerdere <source> tags worden opgenomen die linken naar verschillende video-bestanden. De browser zal het eerste video-bestand kiezen dat het herkent. Er is ook het <track> element dat kan linken naar een tekst-bestand, onder meer gebruikt voor ondertitels of captions.
Er zijn momenteel 3 video-codecs ondersteunt in HTML 5:
- MP4: MPEG4-bestanden met H.264 videocompressie
- WEBM: WebM-bestanden met VP8 videocompressie en Vorbis audio-codec (open standaard)
- OGG: Ogg-bestanden met Theora videocompressie en Vorbis audio-codec (open standaard)
Controle over de playback kan in eigen handen worden genomen met diverse DOM-methods voor o.a. afspelen, pauzeren en laden, DOM-properties zoals duur, volume, seeking en DOM-events die kunnen opgevangen worden met een functie, bijvoorbeeld wanneer de video begint te spelen, gepauzeerd wordt, enz. Een overzicht is gedefinieerd door W3Schools.
Browsercompatibiliteit
Een overzicht door Longtailvideo:
Het Ogg-formaat wordt niet breed ondersteund daar het van mindere kwaliteit is dan MP4 of WebM. Alle browsers ondersteunen MP4 en/of WebM, met uitzondering van Firefox v.3.5 (die in december 2011 overigens nog minder dan 5% van het marktaandeel bezat).
In The Chromium Blog heeft Google bekend gemaakt dat het in de toekomst mogelijk de H.264 videocompressietechnologie uit zijn browser haalt en voor de open standaard WebM zal kiezen, wat mogelijk een doorbraak zou kunnen betekenen voor deze laatste, maar hierover is nog niets met zekerheid te zeggen. Microsoft en Apple zien toekomst in de H.264 techniek, hoewel Microsoft in samenwerking met Google ook een WebM-plugin heeft voorzien in Internet Explorer 9.
Volgens Longtailvideo speelt elke browser het eerste videoformaat dat het ondersteunt wanneer een lijst van sources wordt meegegeven, maar moeten bij Chrome en Safari het Mimetype gedefinieerd worden. Android 2.2 daarentegen kan enkel meerdere sources aan wanneer geen Mimetypes gedefinieerd zijn.
Tot slot wordt het <track> element momenteel in nog geen enkele browser ondersteunt.
Een overzicht door Longtailvideo:
| Browser | Video formaten | Audio formaten | |
|---|---|---|---|
| Internet Explorer | MP4 | MP3 | |
| Chrome | MP4, WebM | AAC, MP3, Vorbis | |
| Firefox | WebM | Vorbis | |
| Safari | MP4 | AAC, MP3 | |
| iPad/iPhone | MP4 | AAC, MP3 | |
| Opera | WebM | Vorbis | |
| Android | MP4 | AAC |
Het Ogg-formaat wordt niet breed ondersteund daar het van mindere kwaliteit is dan MP4 of WebM. Alle browsers ondersteunen MP4 en/of WebM, met uitzondering van Firefox v.3.5 (die in december 2011 overigens nog minder dan 5% van het marktaandeel bezat).
In The Chromium Blog heeft Google bekend gemaakt dat het in de toekomst mogelijk de H.264 videocompressietechnologie uit zijn browser haalt en voor de open standaard WebM zal kiezen, wat mogelijk een doorbraak zou kunnen betekenen voor deze laatste, maar hierover is nog niets met zekerheid te zeggen. Microsoft en Apple zien toekomst in de H.264 techniek, hoewel Microsoft in samenwerking met Google ook een WebM-plugin heeft voorzien in Internet Explorer 9.
Volgens Longtailvideo speelt elke browser het eerste videoformaat dat het ondersteunt wanneer een lijst van sources wordt meegegeven, maar moeten bij Chrome en Safari het Mimetype gedefinieerd worden. Android 2.2 daarentegen kan enkel meerdere sources aan wanneer geen Mimetypes gedefinieerd zijn.
Tot slot wordt het <track> element momenteel in nog geen enkele browser ondersteunt.
zondag 5 februari 2012
HTML 5
HTML 5 wordt de nieuwe standaard voor HTML, XHTML en het HTML Document Object Model (DOM). We concentreren ons voornamelijk op de nieuwe video- en audio-elementen voor media playback.
HTML 5 is momenteel nog in ontwikkeling, maar langzamerhand beginnen de moderne browsers nieuwe onderdelen te ondersteunen. De snel evoluerende specificatie en browserimplementaties maken het belangrijk voldoende tijd te investeren in het onderzoek naar de beperkingen van de nieuwe technologie, o.a. 'cross-browser/device support' zal een belangrijk kernpunt worden doorheen het onderzoek.
We bekijken de evolutie van de browsermarkt (StatCounter Global Stats - Browser Market Share):
We vergelijken dit met de HTML 5 ondersteuning (Longtailvideo, meting november 2011):
We kunnen concluderen dat het merendeel HTML 5 ondersteunt, maar een Flash-backup eveneens noodzakelijk zal zijn (oudere versies van Internet Explorer - zonder HTML 5 ondersteuning - maken nog steeds het grootste marktaandeel uit). Mobiele toestellen en tablets vormen een nieuwe sterk toenemende groep op de markt en ondersteunen meestal geen plugins meer (Adobe Flash).
We gaan verder dieper in op de video specificaties in HTML 5.
HTML 5 is momenteel nog in ontwikkeling, maar langzamerhand beginnen de moderne browsers nieuwe onderdelen te ondersteunen. De snel evoluerende specificatie en browserimplementaties maken het belangrijk voldoende tijd te investeren in het onderzoek naar de beperkingen van de nieuwe technologie, o.a. 'cross-browser/device support' zal een belangrijk kernpunt worden doorheen het onderzoek.
We bekijken de evolutie van de browsermarkt (StatCounter Global Stats - Browser Market Share):
We vergelijken dit met de HTML 5 ondersteuning (Longtailvideo, meting november 2011):
| Browser/Device | Marktaandeel | HTML5 | Flash | |
|---|---|---|---|---|
| Internet Explorer 6/7/8 | 28% | NEE | JA | |
| Chrome | 24% | JA | JA | |
| Firefox | 23% | JA | JA | |
| Internet Explorer 9 | 9% | JA | JA | |
| Safari | 4% | JA | JA | |
| iPad/iPhone | 4% | JA | NEE | |
| Opera | 2% | JA | JA | |
| Android | 2% | JA | JA | |
| Andere (meestal mobiele toestellen) | 4% | NEE | NEE |
We kunnen concluderen dat het merendeel HTML 5 ondersteunt, maar een Flash-backup eveneens noodzakelijk zal zijn (oudere versies van Internet Explorer - zonder HTML 5 ondersteuning - maken nog steeds het grootste marktaandeel uit). Mobiele toestellen en tablets vormen een nieuwe sterk toenemende groep op de markt en ondersteunen meestal geen plugins meer (Adobe Flash).
We gaan verder dieper in op de video specificaties in HTML 5.
donderdag 2 februari 2012
Welkom
Als opgave voor de bachelorproef 2012 binnen mijn opleiding aan de Universiteit Hasselt koos ik voor "Media presentatie in HTML 5". Het eindwerk kadert binnen het "synchronous MediaSharing" (sMS) onderzoek van het wetenschapscentrum EDM.
Het sMS-framework laat gedistribueerde gebruikers toe multimedia te delen met elkaar en op een gesynchroniseerde wijze te consumeren. Voor de media presentatie steunt de dienst op Adobe's Flash technologie, wat op een aantal platformen zoals mobiele toestellen echter niet is ondersteund. HTML 5, de meest recente, maar nog niet volledig gestandaardiseerde versie van HTML, voorziet een aantal nieuwe features om interactieve content te integreren zonder dat hiervoor beroep gedaan moet worden op proprietary plug-ins zoals de Adobe Flash Player. Dit maakt HTML 5 een geschikte kandidaat om het sMS-framework te verlossen van zijn Flash afhankelijkheid zodat de toepassing ook beschikbaar wordt voor o.a. mobiele gebruikers.
Concreet ga ik starten met een onderzoek naar de nieuwe mogelijkheden die HTML 5 biedt om multimedia te integreren in websites. Na deze studie wordt de verworven kennis toegepast in het sMS-framework, met als doelstelling de web-gerelateerde codebase van het platform om te zetten van HTML 4 naar HTML 5.
Het eindwerk verwacht zijn voltooiing omstreeks juni (specifieke datum volgt later). Het resultaat zal een proefschrift omvatten met een uiteenzetting van de literatuurstudie en de concrete werkwijze om tot de voltooiing van de doelstellingen te komen.
Hieronder volgt een beknopt schema van het verloop van het eindwerk, behoudens kleine wijzigingen naarmate het studieprogramma van het tweede semester bekend raakt. Naarmate het eindwerk vordert zal overigens een meer concrete planning van periodes duidelijk worden.
Het sMS-framework laat gedistribueerde gebruikers toe multimedia te delen met elkaar en op een gesynchroniseerde wijze te consumeren. Voor de media presentatie steunt de dienst op Adobe's Flash technologie, wat op een aantal platformen zoals mobiele toestellen echter niet is ondersteund. HTML 5, de meest recente, maar nog niet volledig gestandaardiseerde versie van HTML, voorziet een aantal nieuwe features om interactieve content te integreren zonder dat hiervoor beroep gedaan moet worden op proprietary plug-ins zoals de Adobe Flash Player. Dit maakt HTML 5 een geschikte kandidaat om het sMS-framework te verlossen van zijn Flash afhankelijkheid zodat de toepassing ook beschikbaar wordt voor o.a. mobiele gebruikers.
Concreet ga ik starten met een onderzoek naar de nieuwe mogelijkheden die HTML 5 biedt om multimedia te integreren in websites. Na deze studie wordt de verworven kennis toegepast in het sMS-framework, met als doelstelling de web-gerelateerde codebase van het platform om te zetten van HTML 4 naar HTML 5.
Het eindwerk verwacht zijn voltooiing omstreeks juni (specifieke datum volgt later). Het resultaat zal een proefschrift omvatten met een uiteenzetting van de literatuurstudie en de concrete werkwijze om tot de voltooiing van de doelstellingen te komen.
Hieronder volgt een beknopt schema van het verloop van het eindwerk, behoudens kleine wijzigingen naarmate het studieprogramma van het tweede semester bekend raakt. Naarmate het eindwerk vordert zal overigens een meer concrete planning van periodes duidelijk worden.
- 12 februari: Verzameling literatuur en basis van de studie
- 24 maart: Afronding principieel literatuuronderzoek. Starten met studie naar concrete implementatiemethoden en test cases.
- 15 april: Een concreet idee voor implementatie zou hier ongeveer moeten verworven zijn.
- Vanaf 15 april: Implementatie sMS-framework en afwerking proefschrift.
Deze webblog is opgesteld om de projectbegeleiders evenals u, geïnteresseerde lezer, te informeren over het verloop van het onderzoek. Met regelmaat zal ik hier updates publiceren over vorderingen en bevindingen. Reacties, opmerkingen of informatie zijn altijd welkom.
Student: Steven Thijs
Bachelorproef: Media Presentatie in HTML 5
Promotor: Prof. dr. Wim Lamotte
Begeleider: dr. Maarten Wijnants
Abonneren op:
Posts (Atom)