Trying to determine what's "most" responsible for latency - the round trip my video makes from my encoder, to my server, and back down to the player in my browser.
I'm at about 12 seconds right now with a player I like. Is it buffering in my player? Buffering on the way out by FMLE?
The reason I ask is I feel I've eliminated other culprits with my little test scenario outlined below. And also, all else equal, swapping other players in produces the greatest variance in the latency. One takes it down to 4 seconds. Can't get any lower than that though.
Eliminating other culprits:
-Bad network? Nope, running it all locally.
-The codec?, Nope, setting FMLE to VP6 or H.264 produces same latency.
-Pushing too much data out of FMLE? Nope, 50kbs or 1000kbs produces 12 seconds
-Framerate settings to intense? Nope, 5-29.97 fps changes effects motion quality but delay stays around 12 seconds.
I'm developing a small FMS based web presentation package so the latency will have to be down to a second at most. I've seen a similar package with almost no latency. Here's my test set up:
-Camera connected to Windows XP machine
-Flash Media Live Encoder 3.0.1
-FLash Media Server 3.51
-Video Player - Sample dynamic streaming player in Adobe Flash Media Server productivity tools (kind of like a reference implementation for Adobe's ActionScript 3.0 Dynamic Streaming Class)
If I bounce my video off a server about 30 miles from me the result is nearly identical.
I ran a test with a CDN and a player they provided and the best I could do was 4 seconds.
Does anybody have a really fast player I can test?
To make low latency web stream, do the following:
Setup your encoder normally and point it to the media server
Check media server edge configuration for low latency configuration, Wowza has low latency app built-in
In your player, make sure your buffer is 2 second or larger.
ps. With player having buffer less than 2 second it will not work properly for most people, especially over wifi or long range links.
ps2. If your encoder is on the same LAN as Encoder, you can use low latency app for origin application as well.
ps3. You will never go below 4 seconds and reliable stream at the same time, but if you will do extreme tuning on your LAN part (no buffering for encoder at all - you can do it), by just using buffering on edge you can archive 2 seconds - I have such player but it's not public :(
I would like to share my experience since recently I have been researching into this world of CDN and live video streaming.
My best result has been 2 seconds latency.
I have tried a few providers and I would like to know if anyone knows of any other provider that gets to that low latency.
I achieved those 2 seconds with The Original Livestream, do not confuse with The New Livestream (16 seconds latency).
Both, The Original Livestream and The New Livestream, are part of the same group, Livestream, but it seems they target a different market segment.
They also told me that although they area still supporting The Original Livestrean, they are not longer developing it.
It is not very reassuring when they tell you that they not longer develop the platform, this is the only reason for which we have decided not to get on board with them. You will also have a hard time when you try to get support from them if you want to get access to their RESTfull endpoint for the Guide API.
Still, 2 seconds latency.
I am based in London by the way.
Please let me know if you have some other ultra low latency CDN.
Ah, the url for the original livestream is not easy to find, here it is... https://secure.livestream.com/
Take a look at NetStream.setBufferTime() and ns.bufferTime in the FMS documentation. Also like Robert mentioned the player has its buffer too.
Related
What is the best and most efficient way to benchmark an iOS application? We are mainly looking to get response times for the application to communicate with our API and complete the processing of the returned data.
If you're looking for API response times, you can simply add the two lines of code that measure the times within your app (log at request start, log at request end.)
You can also look into using Apple's Instruments toolset to measure device CPU performance and leaks.
For the quickset-and-dirtiest method of measuring your performance, just NSLog at the start of the request, end of the request/start of processing, and end of processing. That will give you an idea of whether your device or the server are causing a hold-up (something I assume you're looking for). Xcode will timestamp the outputs and you can analyze them after a few trials.
Also, if you run your app in the simulator, it will not give a good representation of phone speed, as it just runs at your computer's speed, but it will give you the option of using the new Network Link Conditioner in Lion to simulate slow and sketchy network connections, so you can see how the network performance would feel out in the field - just make sure to bear in mind you won't have the comfort of the extra processing power.
Flurry provides decent, free analytics and support timed events. Take a look: http://www.flurry.com/product/analytics/index.html
This is good if you want to collect data from other folks running your app.
My app was rejected because one of the features is streaming Podcast audio from a website. Apparently, it may stream over 5MB/5 minutes which is against section 9.3 of the App Store Review Guidelines (https://developer.apple.com/appstore/resources/approval/guidelines.html).
Their suggestion would be to use Reachability to restrict that feature to WiFi. My question is, is there any other way to get around this? Perhaps to only let the user stream 5Mb worth of audio before displaying an alert to switch to WiFi? I don't see anything in Reachability about data usage... is there any other Framework that could keep track of data usage?
ASIHTTPRequest has inbuilt code to throttle bandwidth when the user is on 3G. This uses a modified version of the Reachability sample. The source is available, so take a peek if you want to try doing this yourself. It dodges the 5mb/5min limit by slowing down the download speed to a rate at which that limit won't be hit.
I think Apple's guideline is a reasonable one. It's not only to prevent users running up big data bills, but also to help reduce congestion on data networks.
As for your idea of letting user stream over cellular for 5 minutes, then prompting them to switch to wifi -- I think this would make a for a poor/annoying user experience, as opposed to just prompting them from the start to use wifi. If they use wifi from the start, they will:
1) have less probability of having choppy audio
2) waste less of their cellular data allowance/cost
3) not have a break in service after 5 minutes which might interrupt their flow, at which point they have to fiddle with their phone
I don't think any framework tracks the data usage for you (you get to do that yourself), Reachability is used to find out if you are on WiFi or 3G.
i've searched and read many articles and looked at the GKTank apple sample (can't see any specifics about my problem, seems to process events as they occur) but i can't see a sample or tutorial that seems to answer the following
in a multiplayer game over bluetooth/internet (maybe) how do you synchronise player interactions so that the correct game outcome occurs taking into account latency etc ...
for example:
A button is displayed to each player A & B on two separate devices connected via bluetooth
Player A presses the button (Player A is hosting the game and so latency is not an issue)
Player B presses the button just before Player A but his connection to Player A's device has at least a 200ms network latency
problem: the game needs to know Player B pressed first even though Player A's touch request would reach the game code first - i.e. no advantage to the hosting player.
i know the touch event has the timestamp and so i could ensure that the actual time of the press was sent from Player B to the game code... but not sure if thats the right approach and if it is where to go from there..
i expect the answer lies in some game time cycle where touches aren't processed immediately but within a game cycle...
any help on this or pointers to tutorial or specific source code that handles this would be appreciated.
adam
You might want to ask this question on https://gamedev.stackexchange.com/ , as it's a general question about multiplayer lag or latency, and not particularly specific to the iPhone.
You might be able to use timestamps to order the action messages. I think iPhones are synchronized to a date time server maintained by AT&T.
Well I have no actual experience with creating multiplayer games. But as is the case with most game developement questions, I suppose there is no wrong or right, so some logic thinking should do the trick.
Here are some thoughts you might want to consider:
Even if no latency is occuring on Player A's device, you'll have to introduce some to compensate for player B (and vice versa, since from Player B's point of view Player A is late too)
Thus, you'll need to introduce some kind of a "command stack" to buffer input from both players and execute the commands once both Players had the opportunity to contribute their inputs for a given point in gametime
You may want to introduce ping commands to measure the actual latency from time to time
Only one Device (the host) should be measuring the latency and announce it to the client
Based on the measured latency, calculate a time offset (relative to the hosts time) or delay for the commands in the stack (use the latency to convert Player B's timestamps to "local" time)
Keep the delay dynamic if possible, to compensate for varying latency (keep measuring latency throughout the session
If the actual latency peaks beyond the calculated one, commands from Player B may be put onto the stack late - make sure they will be executed anyway (lag may be experienced at this point)
You'll actually need two "layers" - the input layer, which exchanges, buffers and synchronizes the actual input, and a game layer, which receives the delayed commands from the input layer
So far, my 2 cents ;-)
used this website for the long time to find answers, now need to ask on myself! :)
I have implemented multi player for my game using GKSession and client/server approach, not using peer picker (up to 4 player allowed).
I have one big problem which I can't find solution for.
If you disconnect/reconnect server peer quickly enough, client peer will "remember" that host and will show it in the list of all available peers permanently, only turning wifi/bluetooth off resets this.
So if I do this 5 times in a row, my client will show 5 available hosts with the same name!
Anyone had experience with this? Any idea of workarounds?
I should note that requirements for my game is iPhone SDK 3.0 for Bluetooth and 3.1 for Wifi as GKSession supports both now.
I have a similar problem. In fact I event get peers listed who are not even currently playing the game. Even more so, peers who are not acting as server are listed. I am wondering if there is some behind the scenes caching going on.
I'm thinking about implementing some kind of timer with visual feedback to show the disconnect progress, ideally to prevent this situation. It seems like in general there is a bit of time delay involved with connecting/available and disconnecting/unavailable. It might be better to code the interface to take these time delays into consideration, though I'm not sure exactly how.
Our lovely app that downloads mp3s from our server into a local file on the phone then plays from that file was rejected for using too much bandwidth.
I understand the rejection (we are downloading rather than streaming) and don't quibble with their decision... our first priority was quality of user experience.
I am just wondering... what do I do now?
There are no hard and fast rules... Apple just says, "Must not in Apple's reasonable judgment excessively use or unduly burden network capacity or bandwidth".
Anyone have data on what Apple considers reasonable data transfer rates?
Should I fill up the buffer file in short spurts? Should stream the file at a constant rate (and how would I limit the transfer rate from within the app?)
Any and all suggestions are welcome.
Thanks
I have talked with Apple Developer support, and just FYI. You are only allowed to stream 1 MB per minute over the Cellular network. Support suggest that you test your app in the following way:
"The basic measurement methodology is to turn off all background updating (particularly Mail's automatic mail downloads and Calendar updates), reset the transfer statistics in "Settings:General:Usage:", and then launch your application. Let it run for a fixed amount of time (five minutes is reasonable), and then exit your application. Once you've finished the test, the numbers listed under "Cellular Network Data" in "Settings:General:Usage:" are what you should focus on reducing.
Using what I just described, I'd suggest 4.8 MB every 5 minutes as the guideline you use to ensure your application stays within our bandwidth requirements."
Hope that helps at least a little.
Have you considered HTTP Live Streaming? It's built into OS 3.0.
Basically, you split your media into small (say, 10 second) snippets and put it on a standard web-server. Then you create little text 'meta-descriptor' files in EXTM3U format that point out where the bits are. The interesting thing is that you can create multiple versions of each snippet at different bit-rates. So if your bandwidth is good, the iPhone player dynamically chooses the higher bit-rates but when it's low it automatically switches to the lower bit-rate version of the snippet. It does this on-the-fly to adapt to changing conditions.
So if you split your MP3 into multiple 10-second bits at say, 3 different bit-rates then when the user is connected through WiFi they get the high-quality stuff but if they're on 3G or EDGE they get progressively lower-quality (and smaller sized) content.
If this violates your downloadable media concept, then perhaps you can use the same trick and keep multiple size files for each connection type. Then if you're on WiFi (or get a fast turnaround on a heartbeat ping to the server) download the big file vs. medium or small size ones.
Here's a decent step-by-step on segmenting content. They focus on video but it should work with audio content as well.
I would suggest throttling the bandwidth on the network/http request when connected to cellular, and having no throttle on wifi.
A combo of using Reachability to detect the network status, and implementing your http request using CFNetwork with a sleep until the next second whenever you have already downloaded as much as allowed per second should get you there.
You should check out this project, either to use, or just to see an example of how to code this well:
http://allseeing-i.com/ASIHTTPRequest
The ASIHTTPRequest class implements this, using either the old or 2.0 version of Reachability, and also provides a class level throttle, so even if you have multiple concurrent downloads and uploads, so long as all of them go through ASIHTTPRequest, they will be properly taken together and throttled properly.
A bit more on how to use this here:
http://allseeing-i.com/ASIHTTPRequest/How-to-use#bandwidth_throttling
Lots of good stuff in this (and no, I am not the author of any of it).
On a more serious note, what is it trying to do? There are many markets for iPhone outside of the US which don't have good download rates for phones, nor are the download cap sizes good, so having an app do lots of downloading isn't a good thing.
Could you possibly drop the data rate on your mp3 or some such? Make it optional to do the downloading with a warning that it will use your download?
YOu could not download the mp3 unless you are on wireless, and inform them of that. If you the mp3 are too important, then just tell them it only works on wireless, or include a few mp3 on the device. But 30min of mp3 is ridiculous, that is about what, 30meg.... think about it, 30 meg is just too much.