#Wrong approch

##Data URL's are for transport only.

A data URL converts a binary stream to a format that can be transported over networks that handle text files as UTF-8. It does this by EXPANDING the data to fit a safe range of characters (64 of them) storing 6 bits in every byte (UTF-8). That means for every 3 bytes in the source the data URL needs 4 bytes to store.

This is compounded in javascript by the fact that JavaScript strings are 16bit UCS-2 characters. That means that for every 3 bytes in the source the JavaScript dataURL needs 8 bytes to store.

##Video

Videos are highly compressed streams, not only is each frame compressed, but that compression is related to previous frames. This allows very high compression rates. For example I picked a random low res video 420 by 270 at 20Fps, running time of 1h 25m, and a file size of 380MB.

A random frame saved as png was 238kb in size.

The data throughput to display is about 10mb a second (and this is low res LOW quality video, full frame HD is about 0.5Gig a second)

That means that running your function on that video the memory needed to complete the function is about 380 * 1024 * 1024 + (1 * 60 * 60 * 20fps + 25 * 60 * 20fps) * 200kb * 1024 * ((8 / 3)dataUrl Storage overhead) which is around 56 gigabytes of RAM (Something only the very top range devices can handle).

If you compare the Video size to the image dataURLs used to store the frames you have expanded the video memory needs to almost 400 times the original size.

Even if you consider better options, store frames as Jpeg Blobs (near one to one of bin size) set at very low compression (eg jpeg quality 0.4) each frame requires ~12kb. The final RAM need to store the frames is (1 * 60 * 60 * 20fps + 25 * 60 * 20fps) * 12kb * 1024 = 1.2Gig (do-able on PC's and laptops if you don't count the IMG element overhead)

Though it will fit memory the processing will no less require a lot of time to render, compress, and store.

##The Sad truth

Until browsers come with a way to use a disk based cache for large data needs, video editing like applications will not be able to provide fast random access frame editing like traditional native video editing apps.

##What to do?

I did notice that there was a image element id named gif which hints that the application may be a video to gif like thing.

Again this will be slow, but it is do-able if you compress the video frames to gif as you go. Get video frame, quantize color, compress to GIF, delete frame. Use webWorkers to pipeline the quantize, and compress steps. Ensure that unsaved gif data size does not crash the page.

You should also consider options for resolution and frame rate reduction. Also add warnings for long (large) videos. It will be slow, there is nothing you can do, that is the nature of videos,

Wrong approch

Data URL's are for transport only.

A data URL converts a binary stream to a format that can be transported over networks that handle text files as UTF-8. It does this by EXPANDING the data to fit a safe range of characters (64 of them) storing 6 bits in every byte (UTF-8). That means for every 3 bytes in the source the data URL needs 4 bytes to store.

This is compounded in javascript by the fact that JavaScript strings are 16bit UCS-2 characters. That means that for every 3 bytes in the source the JavaScript dataURL needs 8 bytes to store.

Video

Videos are highly compressed streams, not only is each frame compressed, but that compression is related to previous frames. This allows very high compression rates. For example I picked a random low res video 420 by 270 at 20Fps, running time of 1h 25m, and a file size of 380MB.

A random frame saved as png was 238kb in size.

The data throughput to display is about 10mb a second (and this is low res LOW quality video, full frame HD is about 0.5Gig a second)

That means that running your function on that video the memory needed to complete the function is about 380 * 1024 * 1024 + (1 * 60 * 60 * 20fps + 25 * 60 * 20fps) * 200kb * 1024 * ((8 / 3)dataUrl Storage overhead) which is around 56 gigabytes of RAM (Something only the very top range devices can handle).

If you compare the Video size to the image dataURLs used to store the frames you have expanded the video memory needs to almost 400 times the original size.

Even if you consider better options, store frames as Jpeg Blobs (near one to one of bin size) set at very low compression (eg jpeg quality 0.4) each frame requires ~12kb. The final RAM need to store the frames is (1 * 60 * 60 * 20fps + 25 * 60 * 20fps) * 12kb * 1024 = 1.2Gig (do-able on PC's and laptops if you don't count the IMG element overhead)

Though it will fit memory the processing will no less require a lot of time to render, compress, and store.

The Sad truth

Until browsers come with a way to use a disk based cache for large data needs, video editing like applications will not be able to provide fast random access frame editing like traditional native video editing apps.

What to do?

I did notice that there was a image element id named gif which hints that the application may be a video to gif like thing.

Again this will be slow, but it is do-able if you compress the video frames to gif as you go. Get video frame, quantize color, compress to GIF, delete frame. Use webWorkers to pipeline the quantize, and compress steps. Ensure that unsaved gif data size does not crash the page.

You should also consider options for resolution and frame rate reduction. Also add warnings for long (large) videos. It will be slow, there is nothing you can do, that is the nature of videos,