I am making an app for a book, and part of it involves audio. The book is broken up into chapters and each chapter has about 10 sections. The sound engineer who made the audiobook broke the files up into chapters, but the book itself is broken up into readable sections. Therefore I need to way to play only a specific part of the chapter.
I know you can use URLs to specify timestamps using ...mp3#t=00:03:26. But I'm not exactly sure of the behaviour the download will play after.
The starting of the file works fine, but I'm worried about what happens when it gets to the end of a section. I suppose I could put an event listener on the audio element to check to see if the time has reached the next section's timestamp. The issue I'm facing is that involves trying to conserve bandwidth because that's our main cost.
If the browser decides to download the rest of the audio file, then let's say you're at section 3 and your browser downloads section 4,5, and 6. Then when you go to section 4 it re-downloads a part of what it already downloaded.
There are a number of 'other' solutions but what I mainly want to is understand how the browser determines the timestamp at which it 'stops' downloading. I assume that when it is playing live, it only downloads x amount of seconds in advance. If this is a low number, it's not a big deal. But if the browser skips ahead it could incur a lot of costs, in which case I would need to 'cap' it somehow.
The audio engineer doesn't want to break the files up into sections because then there are quality losses for re-compression.
Related
I'm making a webcomic reader that loads 5 to 10 images whenever the user navigates to an episode. Each image is 2 to 3 megabytes. The project is in angular.
The problem is that each episode takes a while to load because all the images of an episode are loading at the same time. You can't even begin reading the episode until the entire episode is done loading.
I tried using the (load) function to stop an image from loading until the previous image is done loading. That way, the user can begin reading the episode while the rest of the episode loads. And while this did load the first image much quicker, it took an eternity to load the entire episode. My guess is because javascript can load a certain number of images at the same time through separate channels, and bottlenecking it to one image at a time takes much longer.
So is there an ideal number of images that javascript can load at the same time without sacrificing speed? Or do I just have a flawed understanding of the system.
One of the rule I know from optimizing frontend app is the less the better.
You see, the page with text only will load faster than with full of images, and page with 1 image loads faster than page with 10 images.
Assuming we have a reliable connection, good backend. Let's focus on what we can do on frontend.
So first thing first: we want users to see the first image immediately, so we load it immediately, similar to what you did, it's just that we don't touch other images, we only explicitly load the first image. For others, we lazy load them (more on that on point 2)
What I wanted to add more is there're also other resources such as JS/CSS/Fonts... We want our images to load first, so we need to hint to browsers that this is a high priority resource. You can find more about this by searching for "preload" keyword
Next, while users scroll down the page as they're reading/viewing the first image/episode, we will start loading the rest, one by one.
This is what called "lay-loading", with this keyword you can find pretty much any kind of examples. You can take advantages of modern browsers's lazy attribute, or use IntersectionObserver to have more control over when to load
Small note: This is more of a performance question than any framework. So you could find some books about performance, they provide the background such as what is blocking and non-blocking resources, what is TTFB, LCP.
Angular recently updated with NgOptimizedImage, it looks promising, we don't have to do those manual works anymore (at least for the images)
I'm working on a project where several videos are added to the HTML dynamically by JavaScript when they're needed to play, sort of like a remotely-controlled presentation. The order the videos will need to play is unknown at the time of page load and each video is under four seconds. However, the videos are large and naturally need to appear seamless when moving from when to the next, but since the videos are so big and, in some cases, loaded through the Internet, loading usually isn't seamless.
The way I'm adding videos right now is something like this:
$("body").append("<video class='onscreen' autoplay><source src='"+c.video+"'></source></video>");
Where c.video is a relative path to the video source.
Is there any way to preload videos directly from JavaScript beforehand without adding to the HTML? If not, what would be the best way to add to the HTML without having the video visibly playing and allowing for it to be dynamically added later?
I've seen several similar questions on StackOverflow (like this one) but they're all concerned with adding the video and only playing it later, once loaded. I'm sure it's possible to adapt the code presented in those, but I'm not quite sure how to go about doing it, especially as I don't understand some of the concept (please feel free to expand on your answer a bit; I don't just want code snippets!).
If it effects things at all, this will, in the foreseeable future, only have to run on Firefox and the videos will likely all be OGV (though there may be exceptions).
Before you say it can't be done please take a look at my train of thought and entertain me.
I have read on stackoverflow that it can't be done and how to implement this using ffmpeg and other stuff on the server side which is great and simpleish enough to comprehend .. ive even used an extensiion to Video.js i found on github that makes this one step easier. But none the less what if I dont have a copy of the <video src=... > and I really dont care to get one?
I Do not want to use a server to do this Okay with that out of the way, I understand thanks to a post from Paul Irish that video playback is not a shared aspect of web-kit ports (the code which powers basically every browser ... minus chrome canary now using blink a webkit fork) This kinda makes sense why certain browsers only support certain video containers.
So for the sake of simplicity: I want to make this functionality only available on Chrome and only MPEG-4 AVC video containers, why can't this be done if some how I can actually view each frame of the video while its playedback?
additional note
So the generating of video thumbnails is possible using by drawing frames to a canvas, this will only be part of a final solution to my problem, I'm looking to do this each and everytime a video is viewed not store images on my server after a first playback is completed by a user. What I would like to eventually work up to is generating a thumbnail as the video is downloaded that can be viewed while a user uses a dragging scrollbar to ff/rw to a point in the video. So this will need to be done as frames of video come available, not once they have been rendered by the browser for user to view
One can actually feed in a video to the canvas, as seen here in HTML5Doctor. Basically, the line that does the magic is:
canvasContext.drawImage(videoElement,0,0,width,height);
Then you can run a timer that periodically retrieves the frames from the canvas. There are 2 options on this one
get raw pixel data
get the base64 encoded data
As for saving, send the data to the server to reconstruct an image using that data, and save to disk. I also suggest you size your canvas and video to the size you want your screenshots to be since the video-canvas transfer automatically manages scaling.
Of course, this is limited by the video formats that are supported by the browser. As well as support for canvas and video.
Generating thumbnails during first render? You'd run into problems with that since:
You can't generate all frames unless it's rendered on the video element.
Suppose you have generated thumbnails during first run and want to use them for further runs. Base64 data is very long, usually 3 times the file size if the image. Raw pixel data array is width x height x 4 in length. The most viable storage candidate is localStorage, which is just 5-10MB depending on the browser.
No way to cache the images generated into the browser cache (there could be a cache hack that I don't know using data-urls).
I suggest you do it on the server instead. It's too much burden and hassle to do in the client side.
I'm developing a website that allows the user to see and configure a product.
I wanted to start this project using jquery, css3 and html5 with a graceful degradation for older browsers.
I've combined all the smallest images in several sprites to reduce the number of http requests (the images will be served from a cookieless subdomain).
By the way the product must be viewable in 360° for each combination of configurations.
This produces 2252 images (15mb total).
This is not a big issue for the bandwitdh since we have 2 dedicated servers, but I'm just thinking about the best way to improve the user experience.
Actually I only preload images for the default product view, then when the user changes settings I load the needed images (jQuery helps here). When the images are loading the user will se a "loading" gif. Should I preload images also when it does not request them?
Images will be cached by the browser so each image will be a 304 Not Modified response.
Do you have any advice or suggestion to improve the user experience?
Thank you.
if you have 2252 images per product and you preload one, it seems a bit futile to start preloading others. Presumably the viewer changes his selection and you need another one of the 2252 images. That's a very low chance that you'd have that image preloaded.
If there are various "attributes" that are more common than others, you might want to preload a select few? For example, (I don't know what your product is), if you have a red shirt and a pink plaid XXXL shirt, you might want to preload the red one first ;)
One thing I do in situations like this is to play with the animation effects in jQuery (fade, slide, etc). You can fadeOut on attribute change. That animation will take perhaps 600 milliseconds which would be a good chunk of the time required to go and fetch that image from the server. The result is a perceived lower waiting time for the new view/attribute.
Serving the images from a CDN like amazon s3 might improve the load times a little. As for preloading in steps - that might depend on the product. Somethings are more likely to be rotated - for example a car over what landon said. I personally wouldn't bother rotating a t shirt, but a car probably. So the decision might be based on the expected use of your site.
I'm working on a HTML 5 game, it is already online, but it's currently small and everything is okay.
Thing is, as it grows, it's going to be loading many, many images, music, sound effects and more. After 15 minutes of playing the game, at least 100 different resources might have been loaded already. Since it's an HTML5 App, it never refreshes the page during the game, so they all stack in the background.
I've noticed that every resource I load - on WebKit at least, using the Web Inspector - remains there once I remove the <img>, the <link> to the CSS and else. I'm guessing it's still in memory, just not being used, right?
This would end up consuming a lot of RAM eventually, and lead to a downgrade in performance specially on iOS and Android mobiles (which I slightly notice already on the current version), whose resources are more limited than desktop computers.
My question is: Is it possible to fully unload a Resource, freeing space in the RAM, through JavaScript? Without having to refresh the whole page to "clean it".
Worst scenario: Would using frames help, by deleting a frame, to free those frames' resources?.
Thank you!
Your description implies you have fully removed all references to the resources. The behavior you are seeing, then, is simply the garbage collector not having been invoked to clean the space, which is common in javascript implementations until "necessary". Setting to null or calling delete will usually do no better.
As a common case, you can typically call CollectGarbage() during scene loads/unloads to force the collection process. This is typically the best solution when the data will be loaded for game "stages", as that is a time that is not time critical. You usually do not want the collector to invoke during gameplay unless it is not a very real-time game.
Frames are usually a difficult solution if you want to keep certain resources around for common game controls. You need to consider whether you are refreshing entire resources or just certain resources.
All you can do is rely on JavaScript's built in garbage collection mechanism.
This kicks in whenever there is no reference to your image.
So assuming you have a reference pointer for each image, if you use:
img.destroy()
or
img.parentNode.removeChild(img)
Worth checking out: http://www.ibm.com/developerworks/web/library/wa-memleak/
Also: Need help using this function to destroy an item on canvas using javascript
EDIT
Here is some code that allows you to load an image into a var.
<script language = "JavaScript">
var heavyImage = new Image();
heavyImage.src = "heavyimagefile.jpg";
......
heavyImage = null; // removes reference and frees up memory
</script>
This is better that using JQuery .load() becuase it gives you more control over image references, and they will be removed from memory if the reference is gone (null)
Taken from: http://www.techrepublic.com/article/preloading-and-the-javascript-image-object/5214317
Hope it helps!
There are 2 better ways to load images besides a normal <img> tag, which Google brilliantly discusses here:
http://www.youtube.com/watch?v=7pCh62wr6m0&list=UU_x5XG1OV2P6uZZ5FSM9Ttw&index=74
Loading the images in through an HTML5 <canvas> which is way way faster. I would really watch that video and implement these methods for more speed. I would imagine garbage collection with canvas would function better because it's breaking away from the DOM.
Embedded data urls, where the src attribute of an image tag is the actual binary data of the image (yeah it's a giant string). It starts like this: src="data:image/jpeg;base64,/9j/MASSIVE-STRING ... " After using this, you would of course want to use a method to remove this node as discussed in the other answers. (I don't know how to generate this base64 string, try Google or the video)
You said Worst scenario: Would using frames help, by deleting a frame, to free those frames' resources
It is good to use frame. Yes, it can free up resource by deleting the frames.
All right, so I've made my tests by loading 3 different HTML into an < article > tag. Each HTML had many, huge images. Somewhat about 15 huge images per "page".
So I used jQuery.load() function to insert each in the tag. Also had an extra HTML that only had an < h1 >, to see what happened when a page with no images was replacing the previous page.
Well, turns out the RAM goes bigger while you start scrolling, and shoots up when going through a particularly big image (big as in dimensions and size, not just size). But once you leave that behind and lighter images come to screen, the RAM consumption actually goes down. And whenever I replaced using JS the content of the page, the RAM consumption went really down when it was occupying to much. Virtual Memory remained always high and rarely went down.
So I guess the browser is quite smart about handling Resources. It does not seem to unload them if you leave it there for a long while, but as soon you start loading other pages or scrolling, it starts loading / freeing up.
I guess I don't have anything to worry about after all...
Thanks everyone! =)