Showing posts with label Javascript. Show all posts
Showing posts with label Javascript. Show all posts

Sunday 5 August 2018

Loading video from WCF into HTML5 Video

Live demo here!

WCF demo - Loading video using Stream or byte array into HTML5 Video control
This article will look at loading up a video into a HTML5 Video. First off, you can clone the repository I have prepared here:
git clone https://toreaurstad@bitbucket.org/toreaurstad/wcfaudiostreamdemo.git
git fetch && git checkout VideoDemo_04082018


The image below shows our user interface, a simple web page displaying two HTML5 Video controls. This article builds upon code from previous articles. Defining a WCF Service Contract IVideoServiceContract is as following:

using System.IO;
using System.ServiceModel;
using System.ServiceModel.Web;

namespace WcfStreamAudioDemo.Common
{
    
    [ServiceContract]
    public interface IVideoServiceContract
    {

        [OperationContract]
        [ContentType("video/mp4")]
        [WebGet(UriTemplate = "media/{videofile}")]
        Stream GetVideo(string videofile);

        [OperationContract]
        [WebGet(UriTemplate = "mediabytes/{videofile}", ResponseFormat = WebMessageFormat.Json)]
        byte[] GetVideoBytes(string videofile);


    }
}

This servicecontract consists of two operations (methods) and they are exposed to the WCF Rest programming model through the WebGet attribute and an uri template. The method GetVideo returns a Stream of the video file requested. This will allow the user to play off the video file as a stream and has many benefits. First off, the load time is quick - as soon as enough data is collected (and the video file format supports it), the video can play back. We will be using a video/mp4 format in this demo and it supports Streaming playback. An additional benefit of streaming is that it is lightweight. It has low latency, efficient bandwidth usage and allows the client to spend little memory to fetch data. The downside is that our Stream does not support any other type of playback than uni-directional, starting from the beginning. You cannot fast forward, rewind or go to a location in the video with just a Stream like this.

I have not looked into if we could provide some offset to the Stream and skip to for example a specified time in the video. Instead I have made another method called GetVideoBytes that returns a byte array. A client can then retrieve the entire video as a byte array and then dynamically build up a Blob object and create a Blob url and dynamically set the src of the video. The WCF service implementation looks like this:
 using System.IO;
using System.Web;
using WcfStreamAudioDemo.Common;

namespace WcfStreamAudioDemo.Host
{
    public class VideoService : IVideoServiceContract
    {

        public Stream GetVideo(string videofile)
        {
            return GetVideoStream(videofile, ".mp4");
        }

        public byte[] GetVideoBytes(string videofile)
        {
            Stream videoStream = GetVideoStream(videofile, ".mp4");

            byte[] buffer = new byte[32*1024];
            int count;
            var memoryStream = new MemoryStream();

            while ((count = videoStream.Read(buffer, 0, buffer.Length)) > 0)
            {
                memoryStream.Write(buffer, 0, count);
            }

            return memoryStream.ToArray();
        }

        private Stream GetVideoStream(string videofile, string extension)
        {
            string mediaFolder = HttpContext.Current.Server.MapPath("~/media");
            string videoFileFullPath = Path.Combine(mediaFolder, videofile) + extension;
            return File.OpenRead(videoFileFullPath);
        }

    }
}

Nothing special going on here, we grab hold of a FileStream of the video file using HttpContext.Current.Server.MapPath and Path.Combine to locate it in a media folder (there is no error handling in this simple sample) and then use System.IO.File.OpenRead. The method returning a byte array loops through the Stream using a MemoryStream and then returns a byte array from this stream again. Let's look at the client side code. Sadly, using a responsetype of 'arraybuffer' in a XMLHttpRequest has given bloated data. Instead, I must pass the byte array as raw data to the client and manually mold and bake the data into a working ArrayBuffer that then is used in an Uint8Array as a view for this Buffer and instatiating a Blob in Javascript with a Blob url with URL.createBlobUrl and then setting finally the src attribute of a video control in the page. It is not very elegant and there is a performance penalty, especially for larger video files, it would be problematic. Our sample video is just 4.32 MB and can be handled. Of course, this article is just for educational purposes and shows you what CAN be achieved, optimizing this for production purposes would of course need to get this ArrayBuffer to work more elegant. So here is my manual code to fix up the dynamic loading of a byte array into data that HTML5 Video can use:

    <script type="text/javascript">

        window.onload = init;

       
        var source; //Video buffer 

        function init() {
            loadByteArray('http://wcfaudiodemohost.azurewebsites.net/VideoService.svc/mediabytes/sintel_trailer-480p');
        }

        function loadByteArray(url) {
            
            var request = new XMLHttpRequest();

            request.overrideMimeType('text\/plain; charset=x-user-defined');
            //request.responseType = 'arraybuffer';
            request.open('GET', url, true);
            //request.setRequestHeader("Content-Type", "video/mp4");


            request.onload = function() {
                //console.log(request.response);
                debugger;

                var responseData = request.response;
                if (responseData === undefined || responseData === null)
                    return;

                if (responseData.charAt(0) === '[') {
                    responseData = responseData.substring(1);
                }
                if (responseData !== null &&
                    responseData !== undefined &&
                    responseData.charAt(responseData.length - 1) === ']') {
                    responseData = responseData.slice(0, -1);
                }

                if (responseData === undefined || responseData === null)
                    return;

                var videoByteArray = responseData.split(',');
                source = new ArrayBuffer(videoByteArray.length);

                var videoByteArrayView = new Uint8Array(source);


                for (var i = 0; i < videoByteArray.length; i++) {
                    videoByteArrayView[i] = videoByteArray[i];
                }

                var blob = new Blob([videoByteArrayView], { type: "text/plain;charset=utf-8" });

                var blobUrl = URL.createObjectURL(blob);

                var videoCtrlFedByByteArray = document.getElementById("videoCtrlFedByByteArray");

                videoCtrlFedByByteArray.setAttribute("src", blobUrl);

                saveAs(blob, "SintelTrailer_VideoReceived.mp4");

            } //request.onload 

            request.send();

        }

    </script>

Take note what I am doing here:
  request.overrideMimeType('text\/plain; charset=x-user-defined');
This enforces the byte array to be sent as a raw string. Our video with about 4.37 MB actually is 15.54 MB in Fiddler. Not very efficient. I will look into if this can be fixed up in a future article. Our GUI markup looks like this:
 <div>
        
        <h3>WCF Sample Video streaming example (<strong>System.IO.Stream</strong>)</h3>
        
        <p>Playing an wideo file (.mp4) using a custom WCF IDispatchMessageFormatter with REST (webHttpBinding).</p>
        
        <video controls width="320" height="240">
            <source src="http://wcfaudiodemohost.azurewebsites.net/VideoService.svc/media/sintel_trailer-480p" type="video/mp4" />
            <p>Your browser doesn't support HTML5 video. Here is a <a href="http://wcfaudiodemohost.azurewebsites.net/VideoService.svc/media/sintel_trailer-480p">link to the video</a> instead.</p> 
        </video>
        
        <h3>WCF Sample Video streaming example (<strong>byte[] array</strong>)</h3>
        
        <p>Playing an video file (.mp4) using a custom WCF IDispatchMessageFormatter with REST (webHttpBinding).</p>
        
        <video id="videoCtrlFedByByteArray" controls width="320" height="240">         
            <p>Your browser doesn't support HTML5 video. Here is a <a href="http://wcfaudiodemohost.azurewebsites.net/VideoService.svc/mediabytes/sintel_trailer-480p">link to the video</a> instead.</p> 
        </video>
        
    </div>

As you can see, the Stream method allowed us to set the src directly. The byte[] array instead needed us to do a lot of manual molding of the data. I hope you found this article interesting and helpful.

Saturday 19 May 2018

Call a Javascript function from Blazor page

This article will show how a Js function can be called from a Blazor page. First off, create a button like this:
 <button class="btn btn-warning" onclick="@SayHelloToBlazor">Click me!</button>
Then define the .Net method to handle the onclick event.
@using Microsoft.AspNetCore.Blazor.Browser.Interop

 private async void ShowAlert()
 {
    if (RegisteredFunction.Invoke("showAlert", "Hello World!"))
        Console.WriteLine("The Js function showAlert was called!");
 }
The code invokes a registered function with the invoke method and passing in the method name and an argument. Note that you must add the Interop namespace to Blazor in AspNetCore. We then add the Js function, but Blazor will give you a compiler error if you put the Js function in the same file as the Blazor page. Instead, add it in the index.html file under wwwroot folder of your Blazor project (check the wwwroot folder). You can define the Js function in a .js file or right into the index.html file.

    Blazor.registerFunction('showAlert', (msg) => {
        console.log(msg);
        alert(msg);
        return true;

    });

Note that if you refactor the Js method, your reference in the .DotNet code of Blazor will of course go stale, and you must update it. Since we return true (as Blazor wants you to do), we can act upon that in the Blazor code as a callback (check the async modifier of the DotNet method). That is what you need to do to get started with calling Javascript from Blazor page running in DotNetCore 2.1 and later.

Sunday 17 July 2011

Slides about Ecmascript 5 arrays

I am publishing some slides about Ecmascript 5 arrays written in Norwegian in this article.

Sunday 7 February 2010

Godbiten Javascript

Javascript er et fantastisk herlig programmeringsspråk.

Her er grunnene til at jeg liker javascript:
- Ingen klasser! Alt er objekter.
- Dynamisk tolket språk som ikke er strengt typet, full fleksibilitet mht utvidelse.
- Intet behov for generics eller innviklede mønstre for å oppnå det javascript
greier på en elegant måte.
- Det programmeringsspråket i verden flest mennesker har tilgang til, nemlig som
en tolker i en nettleser.
- Innebygd støtte for lambda-uttrykk og avansert funksjonalitet som Javascript har
arvet fra Scheme.
- Det herligste, mest elegante språket i verden!

Jeg håper Ecmascript 5 ikke lager en stor bloatware ut av Javascript, men at språket
sin nette eleganse og enkelhet bevares som i dag. Det er nettopp enkelheten og
fleksibiliteten som gjør Javascript så kraftig.

Jeg anbefaler å se videoene av Douglas Crockford på Yahoo! sin video side.

Spesielt følgende video anbefales!

JavaScript: The Good Parts.

Javascript har selvsagt sine "flaws" også og Douglas Crockford går gjennom disse på en hysterisk morsom måte. (Man må være innvidd i denne bransjen for å sette pris på slike ting da..).

Mvh Tore A

Raskere Javascript med document-fragments?

Jeg har undersøkt litt om man får kjøre raskere Javascript vha. document-fragments. Sentralt i denne teknikken er å benytte document.createDocumentFragment(). Dette er en "construct" eller byggekloss som tillater en å klargjøre store modifikasjoner i HTML DOM treet i en operasjon. Dermed slipper man "reflow", dvs. at nettleseren forsøker å tegne opp html dom treet, hver gang man setter inn et nytt element.

Jeg har testet teknikken ved å lage en Javascript kode som regner ut tiden det tar i antall millisekunder å sette inn 1000 elementer i et HTML nedtrekksliste, etter først å ha slettet 1000 elementer, hvis nødvendig, i samme nedtrekksliste. Enten ved å bruke document-fragments, eller ved å direkte manipulere HTML dom treet for hver iterasjon. Resultatene viser seg at effekten er mindre enn mange andre tester har vist, men det er størst effekt i Internet Explorer. IE er helt klart også den nettleseren med dårligst Javascript-ytelse for akkurat dette.

Resultatene ble som følger (målt i antall millisekunder, mindre er bedre=raskere!):
With Fragment Without Fragment
IE 8.0 608 1070
Firefox 3.6 77 100
Safari 4.0 69 74
Opera 10.5 77 76
Chrome 4.0 87 92

Resultatene er etter kjøring av Javascript som setter inn 1000 elementer og sletter hvis nødvendig de 1000 elementene først og hvert case er kjørt 10 ganger og tatt gjennomsnitt av. IE 8.0 er nesten dobbelt så rask med document-fragment teknikken som uten. Likevel er IE 8.0 i sin egen liga i å være tregere enn de andre nettleserne. Som man ser av tallene over er Safari 4.0 9x-10x raskere med fragment teknikken. Safari 4.0 er mer enn 12x raskere enn IE 8.0 uten fragment teknikken. Safari er forøvrig den raskeste browseren, både med og uten document-fragment. Opera, Safari og Chrome viser små hastighetendringer med document-fragment. Opera 10.5 er faktisk litt raskere uten.. Chrome og Safari har små bedringer, ca. 5-10% raskere. Etter Safari er Opera raskest, Chrome og Firefox er ganske jevne. Chrome er tregere enn Firefox med document-fragment, men kjøringen uten document-fragment viser at Chrome er raskere enn Firefox 3.6. Firefox har ca. 30% raskere utførelse med document-fragment.

Konklusjonen må derfor være at document-fragment må absolutt brukes. IE 8.0 er meget treg i sin Javascript-ytelse og doblingen i hastighet (100% raskere) er nødvendig å utføre. Er du opptatt av hastigheten til webapplikasjonene dine i IE 8.0 er document-fragment meget viktig å bemerke seg med andre ord. For de andre nettleserne er det Firefox 3.6som er mest følsom for document-fragment, med 30% raskere utførelse. De andre browserne har 10-5% økning i raskere utførelse, men for dette caset hadde Opera 10.5 Alpha -1 til -5% økning i hastighet.. Safari er forøvrig den aller raskeste nettleseren. Det at Safari 4.0 skal med en slik enkel test med HTML DOM manipulasjon i javascript være mellom 9x-12x raskere enn IE 8.0: Dette er for dårlig Microsoft! Hvis IE 9 skal bli tatt seriøst som en nettleser og tatt i betraktning Microsoft sine enorme finansielle muskler, må de seriøst fikse Javascript hastigheten sin. Er du på utkikk etter den aller raskeste browseren gir denne testen en klar indikasjon på at JS-ytelsen i Safari er best. Opera og Chrome er hakk i hæl, Firefox sist av disse fire, men langt foran IE 8.0. Det skal nevnes at Opera 10.5 Alpha er en Alpha-versjon og kanskje kan nå opp til Safari 4.0.4 sine høyder i nær framtid..

Jeg har i Google Docs Spreadsheet laget et diagram på ytelsen:



Legg merke til den dramatisk raskere utførelsen i IE 8.0 med document-fragment. Ikke alle nettlesere har spesiell stor ytelsesforbedring, ca. 5-30%, med Firefox som den nettleseren som nyter best av å benytte document-fragment.

Her er testen vist under kjøring i Google Chrome 4.0:



Jeg vil nå oppsummere resultatene fra denne testen:
- Kjører man IE 8.0 må nesten document.createDocumentFragment() benyttes når store
HTML DOM manipulasjoner kjører i nettleseren, pga IE 8.0 sin dårlige hastighet.
- IE 8.0 er 9x-12x tregere enn Safari 4.0.4 i JS-ytelse. Dette er ikke bra Microsoft..
- For de andre nettleserne er det også bra å bruke document.createDocumentFragment(), forbedringen er 5-30%, men Opera hadde ikke noen ytelsesforbedring..
- Generelt sett, benytt document-fragment likevel, evt. unngå det for Opera med
oppdaging av klientens nettleser..
- Testen viser at Safari 4.0.4. er aller raskest, Opera 10.5 og Chrome 4.0 er hakk i hæl. Firefox 3.6 er nest tregest, men milevis foran IE 8.0 i JS-ytelse.

For de som ønsker å teste ut selv, kan de laste ned en zippet versjon av løsningen som jeg laget i Visual Web Developer Express 2008 her:
Document Fragment Demo Test Solution.

For å teste gjør følgende:
1. Pakk ut .zip filen
2. Åpne .sln filen
3. Når Visual Studio er startet, trykk F5 for å starte.

Klikk på de to knappene for å kjøre tester med document-fragment i ulike nettlesere.

Da skulle vel Microsoft-utviklere der ute ha noen pekepinner om hvor skoen trykker i
JS-ytelse for neste versjon av IE 9.x! De øvrige nettleserne er mindre følsomme for document.createFragment() men man bør unngå reflow inne i iterasjoner i javascript, eller spesifisere det enklere på en måte som er optimert for hastighet. Problemet ligger her i at nettleseren ønsker å holde GUI-visuelt oppdatert hele tiden. I en iterasjon er ikke det nødvendigvis en god teknikk for en nettleser. Klienten vil jo helst ha innholdet sitt og starte å jobbe videre, nettlesere er jo som kjent single-threaded miljø når det kommer til GUI. Da bør nettlesere unngå reflow inne i iterasjonen og først starte med en reflow rett etter en slik for-loop slik at man slipper å gjøre rene hacks for å få nettleseren til å være rask og responsiv.

Jeg limer inn javascript-koden her til slutt:


///Runs a desired function, returns amount of millisecond the function took to perform before completing.
function timedFunction(func) {
if (typeof func == 'function') {
var startTime = (new Date()).getTime();
func();
var endTime = (new Date()).getTime();
return (endTime - startTime);
} //if
return 0;
}

function generate_thousand_option_elements_in_dropdown_with_document_fragment() {
var optionsFragment = document.createDocumentFragment();
var ddltest = document.getElementById("ddlTest");
var len = 0;
while (len = ddltest.options.length) {
ddltest.options[len-1] = null;
}
for (var i = 1; i <= 1000; i++) { var optiontoadd = document.createElement("option"); optiontoadd.value = i; optiontoadd.appendChild(document.createTextNode("Option " + i)); optionsFragment.appendChild(optiontoadd); } ddltest.appendChild(optionsFragment); } var withoutFragmentTest = 0; function generate_thousand_option_elements_in_dropdown_without_document_fragment() { withoutFragmentTest++; var ddltest = document.getElementById("ddlTest"); var len = 0; while (len = ddltest.options.length) { ddltest.options[len-1] = null; }
for (var i = 1; i <= 1000; i++) { var optiontoadd = document.createElement("option"); optiontoadd.value = i; optiontoadd.appendChild(document.createTextNode("Option " + i)); ddltest.appendChild(optiontoadd); } }generate_thousand_option_elements_in_dropdown_without_document_fragment var withFragmentTest = 0; function testDocumentFragment() { withFragmentTest++; var resultRun = timedFunction(generate_thousand_option_elements_in_dropdown_with_document_fragment); if (resultRun != 'undefined') { var resultParagraphNode = document.createElement("p"); var resultParagraphTextNode = document.createTextNode("Ran test #"+ withFragmentTest + " with document fragment. Test took: " + resultRun + " milliseconds."); resultParagraphNode.appendChild(resultParagraphTextNode); document.getElementById("resultList").appendChild(resultParagraphNode); } //if }
testDocumentFragment () function testWithoutDocumentFragment() { var resultRun = timedFunction(generate_thousand_option_elements_in_dropdown_without_document_fragment); if (resultRun != 'undefined') { var resultParagraphNode = document.createElement("p"); var resultParagraphTextNode = document.createTextNode("Ran test #" + withoutFragmentTest + " without document fragment. Test took: " + resultRun + " milliseconds."); resultParagraphNode.appendChild(resultParagraphTextNode); document.getElementById("resultList").appendChild(resultParagraphNode); } } testWithoutDocumentFragment




Mvh Tore Aurstad