dinsdag 22 mei 2012

Test case #3

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

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:
AddType video/ogg .ogv
AddType video/mp4 .mp4
AddType video/webm .webm
Voor 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

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.