I work on a big Flash project as the web backend guy that delivers all the files and assets to the main application SWF. Our last, really big packet of data are all the assets and sounds contained in swf files that are imported during the preloader.
Are there any ways to optimize this process in any way?
I'm really looking for ideas in any direction, no matter if its in the swf, the process of loading and so on. Also I look for solutions for the first time load (empty cache) and for consequent loads (prefilled cache).
A few tips for file optimization:
Choose the correct type of image extension, sometimes gif or png delivers better results then jpg's. Ask your designer to deliver tileable, scalable graphics whereever possible. Take advantage of vector graphics.
Use the sound optimization in Flash, so import wave files and try mp3 compression with lower bit rates.
Load sound effects/bg loops related with user interaction prior. Videos can wait. People are used to wait for videos.
For preloader optimization, obviously each HTTP request is extra load on the server. So reduce the number of swf's to be loaded, maybe by logically grouping them. Preloading the crucial stuff first, then background preloading lower priority swf's is always good for convenient user experience.
Related
I am trying to build a web application which will need to have audio streaming functionality implemented in some way. Just to give you guys some context: It is designed to be a purely auditive experience/game/idkhowtocallit with lots of different sound assets varying in length and thus file size. The sound assets to be provided will consist of ambient sounds, spoken bits of conversation, but also long music sets (up to a couple of hours). Why I think I won't be able to just host these audio files on some server or CDN and serve them from there is, because the sound assets will need to be fetched and played dynamically (depending on user interaction) and as instantly as possible.
Most importantly, consuming larger files (like the music sets and long ambient loops) as a whole doesn't seem to be client-friendly at all to me (used data consumption on mobile networks and client-side memory usage).
Also, without any buffering or streaming mechanism, the client won't be able to start playing these files before they are downloaded completely, right? Which would add the issue of high latencies.
I've tried to do some online research on how to properly implement a good infrastructure to stream bigger audio files to clients on the server side and found HLS and MPEG-DASH. I have some experience with consuming HLS players with web players and if I understand it correctly, I would use some sort of one-time transformation process (on or after file upload) to split up the files into chunks and create the playlist and then just serve these files via HTTP. From what I understand the process should be more or less the same for MPEG-DASH. My issue with these two techniques is that I couldn't really find any documentation on how to implement JavaScript/TypeScript clients (particularly using the Web Audio API) without reinventing the wheel. My best guess would be to use something like hls.js and bind the HLS streams to freshly created audio elements and use these elements to create AudioSources in my Web Audio Graph. How far off am I? I'm trying to get at least an idea of a best practice.
To sum up what I would really appreciate to get some clarity about:
Would HLS or MPEG-DASH really be the way to go or am I missing a more basic chunked file streaming mechanism with good libraries?
How - theoretically - would I go about limiting the amount of chunks downloaded in advance on the client side to save client-side resources, which is one of my biggest concerns?
I was looking into hosting services as well, but figured that most of them are specialized in hosting podcasts (fewer but very large files). Has anyone an opinion about whether I could use these services to host and stream possibly 1000s of files with sizes ranging from very small to rather large?
Thank you so much in advance to everyone who will be bothered with helping me out. Really appreciate it.
Why I think I won't be able to just host these audio files on some server or CDN and serve them from there is, because the sound assets will need to be fetched and played dynamically (depending on user interaction) and as instantly as possible.
Your long running ambient sounds can stream, using a normal HTMLAudioElement. When you play them, there may be a little lag time before they start since they have to begin streaming, but note that the browser will generally prefetch the metadata and maybe even the beginning of the media data.
For short sounds where latency is critical (like one-shot user interaction sound effects), load those into buffers with the Web Audio API for playback. You won't be able to stream them, but they'll play as instantly as you can get.
Most importantly, consuming larger files (like the music sets and long ambient loops) as a whole doesn't seem to be client-friendly at all to me (used data consumption on mobile networks and client-side memory usage).
If you want to play the audio, you naturally have to download that audio. You can't play something you haven't loaded in some way. If you use an audio element, you won't be downloading much more than what is being played. And, that downloading is mostly going to occur on-demand.
Also, without any buffering or streaming mechanism, the client won't be able to start playing these files before they are downloaded completely, right? Which would add the issue of high latencies.
If you use an audio element, the browser takes care of all the buffering and what not for you. You don't have to worry about it.
I've tried to do some online research on how to properly implement a good infrastructure to stream bigger audio files to clients on the server side and found HLS and MPEG-DASH.
If you're only streaming a single bitrate (which for audio is usually fine) and you're not streaming live content, then there's no point to HLS or DASH here.
Would HLS or MPEG-DASH really be the way to go or am I missing a more basic chunked file streaming mechanism with good libraries?
The browser will make ranged HTTP requests to get the data it needs out of the regular static media file. You don't need to do anything special to stream it. Just make sure your server is configured to handle ranged requests... most any should be able to do this right out of the box.
How - theoretically - would I go about limiting the amount of chunks downloaded in advance on the client side to save client-side resources, which is one of my biggest concerns?
The browser does this for you if you use an audio element. Additionally, data saving settings and the detected connectivity speed may impact whether or not the browser pre-fetches. The point is, you don't have to worry about this. You'll only be using what you need.
Just make sure you're compressing your media as efficiently as you can for the required audio quality. Use a good codec like Opus or AAC.
I was looking into hosting services as well, but figured that most of them are specialized in hosting podcasts (fewer but very large files). Has anyone an opinion about whether I could use these services to host and stream possibly 1000s of files with sizes ranging from very small to rather large?
Most any regular HTTP CDN will work just fine.
One final note for you... beware of iOS and Safari. Thanks to Apple's restrictive policies, all browsers under iOS are effectively Safari. Safari is incapable of playing more than one audio element at a time. If you use the Web Audio API you have more flexibility, but the Web Audio API has no real provision for streaming. You can use a media element source node, but this breaks lock screen metadata and outright doesn't work on some older versions of iOS. TL;DR; Safari is all but useless for audio on the web, and Apple's business practices have broken any alternatives.
I have a loop that will be loading a new sound every minute. My questions is... I am wondering if it is better to load all 50 at once and play them when needed every minitue or is it better to load the sounds right before I play them?
What is the best way to save resources?
This is for a cell phone app so I need to use all resources very carefully.
It's a good practice to use resources on demand (load sounds when user needs them), especially in resource restricted environments like mobile devices. Every sound object will consume memory. So answer will be: load sound on demand, after playback, unload it by setting reference on sound object to null, load and play another one. If you loading them, from the network, You should load several sounds, for example current and next one, because for mobile devices, network process will turn on radio, and switching radio is battery consuming process.
Network sound loading: load several on demand (for example current and next one)
Filesystem loading: load only current on demand.
I'd like to know if I have downloaded (loaded to my computer) any big flash game like Evony or so where does it do the counting? I mean in the flash files which I have dowloaded to my computer, will there be the counting functions where it counts everything like attacking, defensing, etc.
The above is just an example, it could be any big flash game. The question remains the same. Where does these games do the counting part. It is in those flash files or it is somewhere else on their server which I can't see?
That depends of the game and the developers that make them. As rule of thumb for network games is that everything that needs to be stored or process in any way, like counting - is to do it on the server. The Flash player is considered insecure, because it can be easily hacked, so every action in the game that is significant needs to be executed on server, because they are harder to hack.
Again, this really depends on the choices of the developers, how they will structure the game. So you can't really know unless they tell you or you hack the flash code and see it for yourself.
I'm streaming a video from an Amazon CloudFront RTMP source with
video.attachNetStream(myNetStream);
myNetStream.play(myVideoFileName,0,-1);
and it's working quite well. Now, what I want to do is something like this:
video1.attachNetStream(myNetStream);
video2.attachNetStream(myNetStream);
myNetStream.play(myVideoFileName,0,-1);
This doesn't work as written because only one of the two videos will play at a time for some unknown reason. I want video1 and video2 to play the same video from a single NetStream (to save bandwidth) and remain completely in-sync with each other. How can I accomplish this?
If you are playing an FLV file directly (not streaming it from FMS), you should be able to :
Load the file with URLStream
Wait for sufficient data to start copying the data to a ByteArray object
Create as many NetStream objects as you need and use the appendBytes(bytes) method
I haven't actually tested it, and the logic of appendBytes() needs to be looked at, but theoretically it should work.
Also, it deserves a benchmark. But it's probably better than re-drawing a bitmap copy at the same rate as the video, and keep the two videos in sync.
bitmapData can't be accessed at all because of security restrictions. I'm going with plan B which is playing 2 netstreams, but reducing the file size of the one the videos by removing its audio. I'll have to wait until Amazon allow security policy access to use the bitmapData solution.
How to restrict the game locally?. I know the browser sitelock. But i do not know how much it is effective.
I played the games in http://www.gameark.com/. If you download the games from this website, you cannot play it locally. How to do this?
Thanks.
I'm using http://www.swfshield.com to do this without pain.
What they do is actually converting your swf into binary or some sort, and wrap it inside a loader (I'm not sure.. It's just my guess...). I use this swfshield to protect my swfs from being decompiled and being stolen.
It will not load locally if you do single domain lock. So, basically, it won't literally load in any domain other than the specified domain.
Additionally: I've tried at least five different decompilers to decompile the protected swf from swfshield.com, but none of them were able to get a single hint about the swf. :)