Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Looking to use base64 encoded video in

Goal: Beeing able to cache video for offline access using locastorage.


Approach:

To test my implementation I am downloading file from my server, encoding it with base64 and adding "data:video/mp4;base64,"+base64 as source to html5 video component.


This works great across desktop browsers and on android, but ios (target platform) fails without a proper error message.


Looking for any imputs that might help be move past this brick wall.. I've spent hours searching the web, but found no success stories..




My code:



<HTML>

<body>

<video id="videodiv" width="320" height="240" controls>

</video>



<script>

var viddiv = document.getElementById("videodiv");

var source = document.createElement('source');


var xhr = new XMLHttpRequest();

xhr.open('GET', 'movie.mp4', true);


xhr.responseType = 'arraybuffer';


xhr.onload = function(e) {

if (this.status == 200) {

var uInt8Array = new Uint8Array(this.response);

var i = uInt8Array.length;

var binaryString = new Array(i);

while (i--)

{

binaryString[i] = String.fromCharCode(uInt8Array[i]);

}

var data = binaryString.join('');


var base64 = window.btoa(data);


source.setAttribute('src',"data:video/mp4;base64,"+base64);

viddiv.appendChild(source);

viddiv.play();

}

};


xhr.send();

</script>

</body>

</HTML>

iPad, iOS 7.0.3

Posted on Jan 29, 2014 4:01 AM

Reply
10 replies

Jan 29, 2014 6:56 AM in response to etresoft

I am not - data is served binary from the server then encoded in javascript om the device (for storage in localstorage)


The storage and retrival from localstorage is left out of the code for visibility / elimintaing error sources.


In a production environment, there will be a check to see if the file exists in localstorage - if it does decode and use that. If not - download, encode and place in localstorage. Then decode and use that. (Plus this works accross all other platforms and browsers (including dekstop safari). I don't think encoding/decoding is the one to blame here)


The exact same code works fine with images - which leads me to believe that this is a limitation mobile safari and its implementation of the <video> element.

Jan 29, 2014 9:06 AM in response to dupuis2387

I'm writing this off as data uri not supported in <video> and <audio> tags in mobile safari.


I found http://www.iandevlin.com/blog/2012/09/html5/html5-media-and-data-uri and the comments indicate others are having no luck as well..


I guess Apple still has some bugs to iron out in the html5 space

http://www.infoworld.com/t/html5/bad-news-ios-7s-html5-full-of-bugs-227685?page= 0,0

Jan 29, 2014 9:29 AM in response to HelgeFl

HelgeFl wrote:


I am not - data is served binary from the server then encoded in javascript om the device (for storage in localstorage)

Ah! I get it. I give you (or the originator of the idea) points for cleverness but then take away demerits for crudeness.


The exact same code works fine with images - which leads me to believe that this is a limitation mobile safari and its implementation of the <video> element.

Does it work for a video the same size as an image? It appears to rely on the maximum length of both a Javascript string and a DOM attribute value being unlimited. I think both values are actually "implmentation defined", which translates into "anything reasonable, i.e. not base64 encoded video streams" (cue laughter from people in design meeting).


It really isn't reasonable to talk of "bugs" in a context like HTML5 where everything is perpetually under revision. There are way too many variables to count on something like this working. Why not just make an app? Then you don't have to deal with such hacks and you get practically unlimited storage.

Jan 29, 2014 10:56 AM in response to etresoft

etresoft wrote:

Ah! I get it. I give you (or the originator of the idea) points for cleverness but then take away demerits for crudeness.

Thanks for the credit, but it is definately not mine to take. This is not an uncommon approach when it comes to images, for both performance and offline access. I first picked it up over at blog.ft.com - who made one of the finest offline web applications out there.


Does it work for a video the same size as an image? It appears to rely on the maximum length of both a Javascript string and a DOM attribute value being unlimited. I think both values are actually "implmentation defined", which translates into "anything reasonable, i.e. not base64 encoded video streams" (cue laughter from people in design meeting).


Well, I havent tried with a video in the < 1MB range, but the example from my previous post: http://iandevlin.com/html5/data-uri/audio.php clocks in at 44.5KB, definately not unreasonable for a image. Again, this works accross every platform, browser and OS i've tried except iOS.


I guess people in your design meeting will have to fight it out with theese guys: http://en.wikipedia.org/wiki/Data_URI_scheme.


It really isn't reasonable to talk of "bugs" in a context like HTML5 where everything is perpetually under revision. There are way too many variables to count on something like this working. Why not just make an app? Then you don't have to deal with such hacks and you get practically unlimited storage.


Customer wants this to be a web application because this is a business internal application, not ment for public and the B2B program is not yet rolled out in my country. Besides cross platform is a plus for them as they now can use their existing CMS and check the result right on the desktop.


They have not yet purchased the devices for this project, so I guess I'll just have to make them consider another tablet manuacturer, or live without the offline video for now.


A lot of the HTML5 bugs (yes, bugs) was fixed in the latest revisions of iOS, so I guess there is still a chance a future update might change this.

Jan 29, 2014 12:29 PM in response to HelgeFl

HelgeFl wrote:


Thanks for the credit, but it is definately not mine to take. This is not an uncommon approach when it comes to images, for both performance and offline access. I first picked it up over at blog.ft.com - who made one of the finest offline web applications out there.

Just because it is not uncommon does not mean it isn't crude.


Well, I havent tried with a video in the < 1MB range, but the example from my previous post: http://iandevlin.com/html5/data-uri/audio.php clocks in at 44.5KB, definately not unreasonable for a image. Again, this works accross every platform, browser and OS i've tried except iOS.

It doesn't matter where it works. Obviously the problem is where it doesn't work. That can be caused by a bug in that particular platform, but it can also be caused by relying on behaviour that is not standard.


If you are trying to identify exactly what the problem is, to submit an actual bug report for example, it would be helpful to identify exactly where it fails. See if you can take the video tag out of the equation with a small video or a large image. Then see if you can get an equivalently large Javascript string to fail in another situation.


I guess people in your design meeting will have to fight it out with theese guys: http://en.wikipedia.org/wiki/Data_URI_scheme.

I think the people in my design meeting are laughing because they read that RFC and made a note of the sentence on the first page that reads: "The "data:" URL scheme is only useful for short values".


Customer wants this to be a web application because this is a business internal application, not ment for public and the B2B program is not yet rolled out in my country. Besides cross platform is a plus for them as they now can use their existing CMS and check the result right on the desktop.


They have not yet purchased the devices for this project, so I guess I'll just have to make them consider another tablet manuacturer, or live without the offline video for now.

There is nothing that pleases enterprise IT more than a reason not to buy an Apple product. Perhaps you can get a promotion out of this. (I wish I were only joking at this point).


A lot of the HTML5 bugs (yes, bugs) was fixed in the latest revisions of iOS, so I guess there is still a chance a future update might change this.

I doubt it. When those Android tablets come in, I suggest abandoning the hack approach for something that is explicitly supported. If you follow Apple's advice on how to write such offline pages, you will find that the solution will work great across platforms. Google has similar advice. You include a manifest that specifies the resources you need. The browser will keep those things around. Then use localstorage and Javascript for what they were designed for.

Jan 29, 2014 1:02 PM in response to etresoft

etresoft wrote:


If you are trying to identify exactly what the problem is, to submit an actual bug report for example, it would be helpful to identify exactly where it fails. See if you can take the video tag out of the equation with a small video or a large image. Then see if you can get an equivalently large Javascript string to fail in another situation.


With 44.5KB audio file (previous post) i think size is already taken out of the equation.. I'll go ahead and file a bug report, and will report back should I ever hear anything back


I think the people in my design meeting are laughing because they read that RFC and made a note of the sentence on the first page that reads: "The "data:" URL scheme is only useful for short values".


Good catch.. However, in this case it is very useful also for larger values.. 🙂


I doubt it. When those Android tablets come in, I suggest abandoning the hack approach for something that is explicitly supported. If you follow Apple's advice on how to write such offline pages, you will find that the solution will work great across platforms. Google has similar advice. You include a manifest that specifies the resources you need. The browser will keep those things around. Then use localstorage and Javascript for what they were designed for.


Actually the webapp already uses Application cache extensively (if thats what you're referring to)for HTML, JS and CSS files. Currently we also cache images in the application cache, but that will probably be moved out to localstorage. (Or webdb). The reason beeing theese take a lot of space, and the way application cache works is that as soon as the manifest file is touched, all data becomes obsolete and the application starts redownloading all data.. For HTML and JS thats not really an issue, but we have also some 30 MB of images and would like a few hundred megs of video.. Definately dont want that to be deemed obsolete (and redownloaded) because customer changed punctuation on one of the HTML files 🙂


..And most (all?) browsers simply ignore video files in the cache manifest (probably for good reason)


Thanks for our effort and time though - appericiate it.

Jan 29, 2014 1:10 PM in response to HelgeFl

I really think a native app is a better choice, even if it is an Android app. It can be little more than a wrapper around WebKit using your existing code but then you have full control of everything.


But if this is an internal application, a few hundred megabytes shouldn't be noticed. It just seems like a fragile solution. Such things work fine one day and fail the next.

Looking to use base64 encoded video in

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.