I am trying to use Azure Media service to do the 7x24 live streaming and also try to persist the streamed video. In the document it said the Live Output can set the archiveWindowLength upto 25 hours for VOD. But not really able to persist the whole streamed videos.
Any idea about how to achieve it. I am quite new in this area. Any help is appreciated.
The DVR window length for a single Liveoutput is 25 hours. The reason for the 25 hours is to provide a 1 hour overlap for you to switch to a second Liveoutput with a new Asset underneath.
Typically how i set this up is to have an Azure Function and Logic App running with a timer to ping-poing between two LiveOutputs. You have to create a new LiveOutput with a new Asset.
Think of LiveOutputs as "tape recorders" and the Asset is the "tape". You have to swap between tape recorders and switch tapes ever xx-hours.
You do not necessarily have to wait a full 25 hours though. I actually recommend not doing that because of the size of the manifest gets really huge. Sometimes loading such a large HLS or DASH manifest on a client can really mess with memory and cause some bad things to happen. So, you could consider doing the ping-pong between your "tape recorders" every 1 hour.
If you wish to "publish" the live event to your audience with a smaller DVR window (say 10 minutes or 30 minutes) you could additionally create a 3rd LiveOutput and Asset and leave that one set to a DVR window of 30 minutes and leave it running forever.
Related
I've used Fabric for quite a few applications, however I was curious about the performance when a single application submits potentially hundreds of events per minute.
For this example I'm going to be using a Pedometer application, in which I would want to keep track of the amount of steps users are taking in my application. Considering the average user walks 100 steps per minute, I wouldn't want the application to be sending several dozen updates to the server.
How would Fabric handle this, would it just tell the server "Hey, there were 273 step events in the last 5 minutes with this meta deta" or would it sent 273 step events.
Pedometer applications typically run in the background so how would we get data to Fabric without the user opening the application
Great question! Todd from Fabric. These get batched and sent at time intervals and also certain events (like installs) trigger an upload of the queued events data. You can watch our traffic in Xcode debugger if you are curious about the specifics for your app.
The following code fragment
for($i=0;$i<60;$i++){
$u[$i]=$_REQUEST["u".$i];
$pic[$i] =imagecreatefromjpeg("http://graph.facebook.com/".$u[$i]."/picture");
}
is taking more than 90 seconds to execute on my new server. It was taking less than 15 seconds on my shared hosting server. However, on dedicated server it is taking more than 90 seconds.
The data center of my new server is Asia Pacific.
Please advice on how I can reduce this time of fetching images on the graph.
thanks and regards
Why not just request all the pictures' URLs in a single call?
https://graph.facebook.com/?fields=picture&ids=[CSV LIST OF IDS]&access_token=ACCESS_TOKEN
You'll then have a list of all the images and can fetch them all however you so wish
is taking more than 90 seconds to execute on my new server.
Well, for 60 HTTP requests that’s not too bad, I’d say.
It was taking less than 15 seconds on my shared hosting server. However, on dedicated server it is taking more than 90 seconds.
Maybe the connection of your old server was just faster …?
The data center of my new server is Asia Pacific.
Do you know by any chance, which one it was before?
Please advice on how I can reduce this time of fetching images on the graph.
Do you have to request all these images in one go?
Maybe your app’s workflow (which we don’t know anything about yet) would allow for other approaches, like getting user images at a previous time (f.e. when a user starts using your app) and cache them locally, so that you don’t have to do 60+ HTTP requests in one go.
I'm streaming videos via rtmp from Amazon Cloudfront. Videos are taking a loooong time to start playing, and I don't have any way of figuring out why. Normally I'd use the "Net" panel in Firebug or Web Inspector to get a good first impression of when an asset starts to load and how long it takes to be sent (which can indicate whether the problem is on the server end or network versus the browser rendering). But since the video is played within a Flash player (Flowplayer in this case), it's not possible to glean any info about the status of the stream. Also since it's served from Amazon Cloudfront, I can't put any kind of debugging or measuring tools on the server (if such a tool even exists).
So... my question is: what are some ways I can go about investigating this problem? I'm hoping there would be some settings I can tweak on either the front-end (flowplayer) or back-end (Cloudfront), but without being able to measure anything or even understand where the problem is, I'm at a loss as to what those could be.
Any ideas for how to troubleshoot streaming video performance?
You can use WireShark (can diessect RTMP) or Fiddler to check what is going on... another point (besides the client and the server) to keep in mind is your ISP.
To dig deeper you can use this http://rtmpdump.mplayerhq.hu/ OR http://www.fluorinefx.com/ OR http://www.broccoliproducts.com/softnotebook/rtmpclient/rtmpclient.php.
You need to keep in mind that RTMP isn't ideal since it usually bypasses proxies and tries to make direct connection... if this doesn't work it can fallback, but that means that some time has already passed (it wait for a connection timeout etc.)... if you have an option to set CloudFront/Flowplayer to RTMPT then I would recommend doing so since that uses Port 80 for the connection.
Presumably - if you go and attempt to view a video - then come back 20min later and hit it again - it loads quickly?
SAN -> Edge Servers ---> Client
This is all well and good in a specific use case (i.e. small filesize of the origin content, large long running cache) - but, it becomes an issue when it's scaled out, with lots of media hosts running content through the system i.e. CloudFront.
The media cache they keep on their edge servers gets dumped fairly often - after the cache is filled - start dumping from the oldest file in cache - so if you have large video files that are not viewed often - they won't be sitting in the edge server cache, and take a long time to transfer to the edges - thus, giving an utterly horrific end user experience.
The same is true of youtube, for example - go and watch some randomly obscure, high duration video - and try it through a couple of proxies, so you hit different edge servers, you'll see exactly the same thing occur.
I noticed a very noticable lag when streaming RMTP from cloudfront. I found that switching to straight http progressive from the amazon S3 bucket made the lag time go away.
We have an application on iPhone. This application displays 25 products per page/screen. The text items such as product name, price, discount, URL of the product image, etc of all the 25 products is downloaded from the server first.
After that we make 25 synchronous requests to download the 25 product images, one after the another. Each image is about 25KB in size and these are of size 300 by 400 pixels approximately and we only need 72 by 72 pixels size images for display on iPhone. We notice that it takes about 40 seconds to display one screen/page and this sort of performance is not good. So we are investigating how to increase the performance.
Will the performance improve if we scale down the size of the images on the server to 72 by 72 pxiels.
Also is it possible to download all 25 images from server to the iPhone? If so can you please share your approaches as to how to do that? We want to do this only if it can improve the performance.
I suggest you ask this on Stackoverflow as already mentioned.
From a programmer's perspective, if you only need 72x72 images, you should definitely bring that. You'll be saving bandwidth, battery and processing power.
Then 25 sync requests seems like a bad idea, why not bring an entire page (or two pages) at the same time?
A URL request is "slow" by nature, so the less you make, the faster it will work.
I'd modify the server to allow batch fetching as in "give me the first 25" and then you process them locally. Then you can fetch the next 25 asynchronously (and preemptively) for when the user presses next you already have it (and always have 1 or 2 in advance).
Use Cache, save them locally if you can and always check if that page is available locally, so you don't have to re-fetch the records if the user presses back and then next again. What's downloaded stays downloaded :) Product pages should't change that often.
For more specific implementations, I suggest you jump over to StackOverflow.
I'm having issues with audio files on the iPhone web-app. Seems as each time an audio file is played, it's loaded first then played, even if repeating the same audio on a page that hasn't refreshed (done via javascript). From what I've research manifest files would be great but they are for offline application. I'm now researching HTML5 databases.
Does anyone know if HTML5 databases can store audio files such as mp3? The end result it then to pull the mp3 from the database. It might still have to load the file each time from the database but I'm hoping it's quicker than retrieving it from a server.
Thank you.
I think what you are after is possible, however you have a significant hurdle in that the implementation of HTML5 databases on most browsers is limited to 5mb as per w3c recommendations:
A mostly arbitrary limit of five
megabytes per origin is recommended.
Having said that the way its implemented in iPhone Safari is that databases can grow until they reach 5MB in size at which point the browser will ask the user if they wish to allow for the extra size, asking again at 10, 50, 100 and 500MB (see section "Estimated Database Size" in this post by html5doctor).
There is no limit on the number of databases you can build per domain in safari, however according to this post by Cantina Consulting you can have a total of 50MB across all databases in a single domain.
Given these parameters, a possible work-around for this implementation is to split your mp3 blobs across multiple databases, creating a new database each time your reach 4.9MB, however even if you follow this design it may not be ideal as you will still experience the following:
50MB is not a lot of audio files, a typical 5/6min song is about 5MB at 128Khz, so that only gives you space for about 1CD (60 min) of mp3 songs, after this you will need user cooperation to use additional database space.
You will still have significant security issues trying to play the mp3 blobs from the javascript runtime, it may be possible to bypass these tricking flash into thinking they are mp3 stream but I'm not sure how you'd go about it.
Feel free to have a play around with this iPhone HTML5 SQL Client I put together, you may want to use something similar for experimenting with your local mp3 Database.