Is there any possibility in Adobe AIR to control bandwidth usage with AIR when downloading a file using URLStream?
Short answer, you can't. It is not Air's purpose to 'limit' any kind of downloads (and I don't get why you would in the first place...) since if you're going over HTTP it actually uses the OS' default browser.
The only way you could limit it is by create a Socket and try to implement an HTTP protocol within that or implement your own protocol. Frankly, I wouldn't even try. I don't see much use for limiting bandwidth for download...
you can try and check if NetLimiter can handle this. Here is the link
http://www.netlimiter.com/
Hope this helps.
"eats all available traffic" is a good thing on the client side.
If a stream download speeds becomes slower then the time played the user will have to wait for buffering and this would be bad.
Your best bet is detect the speed of DL and if it lesser then XXX have it download a lower rez video. To do this you will need to have a few versions of the file on the server. This allows the client to get optimized speeds. You can also allow the user to override it To get HD quality if they really want to see high def
Related
I'm developing a service where people can stream multiple audio files at the same time.
Unfortunately, when streaming about 4 streams simultaneously, Chrome's HTTP connection limit seems to kick in: new stream requests only arive at the server when a previous connection was closed.
Interestingly enough, I can play 10+ videos at the same time on YouTube.
What kind of technique could YouTube have used here to circumvent the browser's simultaneous http connection limit?
The crucial point here I suppose is that YouTube streams are not directly controlled by the browser, they are embedded Flash players which use streams that are handled by Flash. If you want to hand off the streaming process to an external app/library (Flash, Java etc) you can circumvent these limitations quite easily.
The other point is that YouTube has a huge CDN, so there is no guarantee you're getting any two videos from the same server, which would also help to circumvent concurrency limitations (to a point, at least).
I'm not surprised that Chrome stops you after a while because Google did a load of research and experiments regarding browser concurrency and relative efficiency a while ago, and I remember reading somewhere that they concluded that 3-4 concurrent connections to the same server represented the the most efficient data transfer architecture over straight HTTP. Annoyingly, I can't find a reputable source to reference with that (although I got it from one in the first place), however this is related and probably part of the same research program.
This is also the sort of research Facebook get quite heavily involved in, and you might find some useful information in over at http://developers.facebook.com/ if you can be bothered sifting through the rubbish to find it...
I have an Adobe AIR application that makes multiple connections to a server. When I open more than two connections I get an error:
2032: Stream Error.
Is there a configuration option or a property somewhere to raise the limit?
Not familiar with a configuration for this, but I have a theory you might test. Flash is single threaded, but handles requests asynchronously. It still has to handle the input of streams through its one thread. If you are open connections that stream/stay open for a long time, there is probably some blocking going on that could be longer than the allowed stream buffer blocking tolerance. Perhaps flash can handle 2 connections, but introducing the third starts to cause a stream to block too long. This is not exactly a solution, but may get you going in the right direction.
There are no limitation you may check this forum https://forums.adobe.com/thread/1281685
Also you should provide some details like sdk version,os etc
Our app need instant notification, so obvious I should use some some WCF duplex, or socket communication. Problem is the the app is partial trust XBAP, and thus I'm not allowd to use anything but BasicHttpBinding. Therefore I need to poll for changes.
No comes the question: My PM says the update interval should be araound 2 sec, and run on a intranet with 500 users on a single web server.
Does any of you have experience how polling woould influence the web server.
The service is farly simple, it takes a guid as an arg, and returns a list of guids. All data access are cached, so I guess the load on the server is minimal for one single call, but for 500...
Except from the polling, the webserver has little work.
So, based on this little info (assume a standard server HW, whatever that is), is it possible to make a qualified guess?
Is it possible or not to implement this, will it work?
Yes, I know estimating this is difficult, but I'd be really glad if some of you could share some thoughts on this
Regards
Larsi
Don't estimate, benchmark.
Polling.. bad, but if you have no other choice, then it's ideal :)
Bear in mind the fact that you will no doubt have keep-alives on, so you will have 500 permanently-connected users. The memory usage of that will probably be more significant than the processor usage. I can't imagine network access (even in a relatively bloaty web service) would use much network capacity, but your network latency might become an issue - especially as we've all seen web applications 'pause' for a little while.
In the end though, you'll probably be ok, but you'll have to check it yourself. There are plenty of web service stress testers, you can use Microsoft's WAS tool for one, here's a few links to others.
Try using soapui, a web service testing tool, to check the performance of your web service. There is a paid version and an open source version that is free.
cheers
I don't think it will be a particular problem. I'd imagine the response time for each request would be pretty low, unless you're pulling back a hell of a lot of data, so 500 connections spread over 2 seconds shouldn't hit it too hard.
You can use a stress testing tool to verify your webserver can handle the load though, before you commit to this design.
250 qps probably is doable with quite modest hardware and network bandwidth provided you do minimize the data sent back & forth. I assume you're caching these GUID lists on the client so you can just send a small "no updates" response in the normal case.
Should be pretty easy to measure with a simple prototype though to be more confident.
Assuming that I have to copy each image on the stream (I cannnot simply access that data with any mutex protection, it must be copied anyway), which method is better, pros/cons?
I would like to know also how much performance loss this implied compared to using the images in the same process.
Thanks
For images, IPC through shared memory would be the best option.
At least Windows' firewalls can interfere even with local TCP/IP connections. Therefore I would prefer shared memory.
In term of performance, IPC through shared memory is the best option but IMHO,
even if sockets consume a little more processing, they will give you a better result in term of evolutivity of your software.
Google "Memory Mapped Files"
I would take the VCAM example of a DirectShow capture device (available at:
http://tmhare.mvps.org/downloads/vcam.zip)
This driver appears to the O/S as a video capture device and would run in the destination process. The source would use shared memory buffers to feed it frames to inject.
While more complicated than a minimal shared-memory IPC scheme, it gives an incredible advantage in that your video pipes can connect to most media player programs, capture and editing tools, etc.
I have done this several times, including features like sinks, mixers, Freeframe effect plugins, and so on. It should take a day or two to hack together.
I'm no expert in audio, so if any of you folks are, I'd appreciate your insights on this.
My client has a handful of MP3 podcasts stored at a relatively high bit rate, and I'd like to be able to serve those files to her users at "different" bit rates depending on that user's credentials. (For example, if you're an authenticated user, you might get the full, unaltered stream, but if you're not, you'd get a lower-bit-rate version -- or at least a purposely tweaked lower-quality version than the original.)
Seems like there are two options: downsampling at the source and downsampling at the client. In this case, knowing of course that the source stream would arrive at the client at a high bit rate (and that there are considerations to be made about that, which I realize), I'd prefer to alter the stream at the client somehow, rather than on the server, for several reasons.
Is doing so possible with the Flash Player and ActionScript alone, at runtime (even with a third-party library), or does a scenario like this one require a server-based solution? If the latter, can Flash Media Server handle this requirement specifically? Again, I'd like to avoid using FMS if I can, since she doesn't really have the budget for it, but if that's the only option and it's really an option, I'm open to considering it.
Thanks in advance...
Note: Please don't question the sanity of the request -- I realize it might sound a bit strange, but the requirements are what they are. In that light, for purposes of answering the question, you can ignore the source and delivery path of the bits; all I'm really looking for is an explanation of whether (and ideally how) a Flash client can downsample an MP3 audio stream at runtime, irrespective of whether the audio's arriving over a network connection or being read directly from disk. Thanks much!
I'd prefer to alter the stream at the client somehow, rather than on the server, for several reasons.
Please elucidate the reasons, because resampling on the client end would normally be considered crazy: wasting bandwidth sending the higher-quality version to a user who cannot hear it, and risking a canny user ripping the higher-quality stream at it comes in through the network.
In any case the Flash Player doesn't give you the tools to process audio, only play it.
You shouldn't need FMS to process audio at the server end. You could have a server-side script that loaded the newly-uploaded podcasts and saved them back out as lower-bitrate files which could be served to lowly users via a normal web server. For Python see eg. PyMedia, py-lame; or even a shell script using lame or ffmpeg or something from the command line should be pretty easy to pull off.
If storage is at a premium, have you looked into AAC audio? I believe Flash 9 and 10 on desktop browsers will play it. AAC in my experience takes only half of the size of the comparable MP3 (i.e. a 80kbps AAC will sound the same as a 160kbps MP3).
As for playback quality, if I recall correctly there's audio playback settings in the Publish Settings section in the Flash editor. Wether or not the playback bitrate can be changed at runtime is something I'm not sure of.