SoundCloud recently enabled their 15k-a-day rate limit.
My app will serve quite a few visitors a day. The rate limit is expected to be hit very easily.
Can the stream URL be cached? Is there any way to stream and stay in the rate limit when going over because you have too much traffic?
The devs haven't made an application form yet to ask for higher limits..
Related
Can we access the heart rate directly from the apple watch? I know this is a duplicate question, but no one has asked this in like 5 years. I know you can access it from the Health App but I'm not sure how "real-time" that will be.
If you don't expect 100% real-time.
You can use this one: HKAnchoredObjectQuery. I think it has a 300-500ms delay.
A query that returns changes to the HealthKit store, including a snapshot of new changes and continuous monitoring as a long-running query.
I am trying to create a low-power watchOS app that will only periodically (every 5 minutes or so) need an updated but precise location. The key word there is need. The app certainly could provide better information if it were getting location updates consistently but the goal is for this app to be low power. That being said (and I am not sure if this is possible) if another app is constantly streaming location in the background it would be nice to get those updates too if that does not have extra battery cost.
Is there a way to only request location periodically? Is this actually better for the energy impact of the 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.
From Apple:
9.4
We found that your app does not use the HTTP Live Streaming protocol,
with a baseline stream of 64 kbps, to broadcast streaming video, as
required by the App Store Review Guidelines.
This is not the first time we had this error. The first time we had this they mentioned the url that was giving the error and pointed us towards their mediastreamvalidator tool.
We fixed our .m3u8's, added a low bitrate stream, have run through all our url's with that tool, and they have all passed.
Upon resubmitting they gave us the error above, with no details. We've replied in the resolution center with the validation output attached and are currently waiting for a reply. Does anyone have any ideas of things we've missed that would not be caught by their validation tool?
Thanks.
You must include 64kbps or lower bitrate stream (usually audio-only or audio with still images) in your streaming contents.
Check the guide: HTTP Live Streaming Overview
Requirements for Apps
Warning: iOS apps submitted for distribution in the App Store must
conform to these requirements.
If your app delivers video over
cellular networks, and the video exceeds either 10 minutes duration or
5 MB of data in a five minute period, you are required to use HTTP
Live Streaming. (Progressive download may be used for smaller clips.)
If your app uses HTTP Live Streaming over cellular networks, you are
required to provide at least one stream at 64 Kbps or lower bandwidth
(the low-bandwidth stream may be audio-only or audio with a still
image).
These requirements apply to iOS apps submitted for distribution in the
App Store for use on Apple products. Non-compliant apps may be
rejected or removed, at the discretion of Apple.
Well, after finally getting through to someone at apple on the phone we got a case number and our app flagged for a fast tracked review. It was approved and is now available, despite there being no change whatsoever in the binary between the last rejection and this approval.
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.