I am starting to get familiar with Azure Media Services and I wanted to see if anyone had some thoughts on live events and start times.
We offer a paid live event, so via our web application, users can join the "presentation" up to 30 minutes before it starts.
In azure, we typically start the channel 1hr beforehand to get everything set up, and start the "Live Event" at the exact start time. What is the best practice for showing a "this presentation will begin shortly" message and auto-starting the feed when the event starts?
Is it best to start the "Live event" 30 min early, and use a slate, or can the Azure Media player basically sit and wait for the event to start? Does this happen automatically, or would I need javascript to keep trying when OnError happens? Basically, I don't want users to have to refresh the page or anything when the even starts. It should just start playing right at the start time.
I'll take a stab at this one Chris.
For most live events that are produced by our customers (including Microsoft Studios here on campus), we typically start the channel about 20-30 minutes prior to the event time with a slate and music. Usually that slate is coming from the encoder rather than from a slate on the live channel in Azure Media Services. Reason for that is there is a lot more control locally in the production pipeline for animated slates, music, fading and switching, etc. You can achieve this with low cost options like Telestream Wirecast, or a NewTek Tricaster setup.
n azure, we typically start the channel 1hr beforehand to get everything set up, and start the "Live Event" at the exact start time. What is the best practice for showing a "this presentation will begin shortly" message and auto-starting the feed when the event starts?
We then monitor the Preview feed URL from the Live Channel in Azure just to make sure everything is operational and running correctly. When it is close to showtime (5-10 minutes or so ahead), we will start the recording (Start a new Program). This is not automatic, but you could certainly use multiple methods to automate the calling of the API to create, start, and stop the Program via our REST API or client SDKs.
To your point, the new Program creation will generate a new Program URL for playback. Your users or web page code would need to refresh. If you have a requirement that the users are going to arrive really early, you could either start the Program recording a lot early and publish that URL - but you would then want to use our Dynamic Filters or Subclipping feature after the event to remove the long slate at the head of the event.
Another trick could be that if you automate the start of the live Program recording, you could also use SignalR or some other out-of-band notification to signal the player in the page to reload the src URL and begin playback. I've seen that trick used before as well.
Hope that helps. Bottom line, there are a lot of creative options, but nothing "built-in" and automatic at this time.
Related
I am implementing an app in Flutter, for which I need to schedule (audio) events in advance. Only after one event is completed I can schedule the next, since the duration of the event might not be known before. Each audio event is a notification sound for the user, thus scheduling and audio playback should both work while the app has no focus or the phone is locked.
I currently fail to implement these specifications and I guess I'm just not thinking the right way about it for the moment. Since I started to learn Flutter recently, there could also be just some simple misunderstandings from my part. Let me summarize what I know about background execution & native code in Flutter, please correct anything wrong with these statements:
When the App looses focus (or the phone gets locked) code execution stops.
However, inside the "primary" Dart-code, I can spawn an isolate which will run even with the phone locked or without focus on the app.
Different isolates share no memory whatsoever; they communicate via ports.
There a spawned isolate does not know anything about the flutter ecosystem, therefore it is not possible to use flutter plugins.
For the same reasons I cannot use MethodChannels as well to communicate with platform code from an isolate.
From this I conclude:
The event should be scheduled from a seperate Dart-isolate, so that locking the phone won't halt scheduling.
This isolate won't be able to play any audio file by itself, and won't be able to communicate with platform code.
Thus, it needs to communicate with the primary isolate, which can play audio. However, without the app open, the code won't respond.
Consequently, this approach cannot work?
Right now, I am stuck at this point and don't know how to continue. I guess one option could be to directly call java/swift code for the respective native platforms and handle scheduling and audio there. Yet, I hope that I just don't see a simpler option right now.
I am using SailsJS for a web application which basically lets the user download and process any video from the internet(say youtube). The user enters a link to the video and my sails app downloads the video if available and then starts processing the downloaded video using a shell script(Come OpenCV processing to find different frames).
This process takes a very long time to complete, and the user can navigate away from the page and do whatever he wants. Now, to check on the progress by visiting this page later I need to be able to connect with the child process that was created earlier for this video file.
I have come up with two possible solutions:
1) Using gearman to implement a job server and connect to it every time the user navigates to the page and start getting the callback events and show the progress based on them. This is the first time I'll be using gearman.
2) Somehow storing the processID of the child process in the session/db and then using it to find the process using ps-node.
Which of these is the better approach(if you think they'll work fine)? Or is there any other solution I don't know about? Any pointers in the right direction will be appreciated.
Let's start with the second option. Don't use it. Simply because this way your site users will have sort of more control over the number of processes running on your server then you will.
Number one is way better, but using a separate job server seems like a bit of overkill to me (I have to admit though that I'm not fully informed the scale of your plans).
Bottom line, I would use a message/job queue (kue seems like a perfect fit to me) and store the progress in DB or (preferably) Redis (or whatever cache you are using).
I am new to mobile website development, and facing this issue where I want to refresh data on the website in every 30 sec which is invoked from the client side and server provides the data in response. Problem is when I close the browser or when the browser goes in background it stops working. Is there any thing we can do to make this thing possible?
Have a look at the Android Developers - Processes and Threads guide. You'll get a deeper introduction to how process life-cycles work and what the difference is between the states for background- and foreground processes.
You could embed your web app in a WebView. This way you could deal with the closing browser case: you could provide a means to "exit" the app that involves closing only your container activity. That way the timers you have registered in javascript will still be running in the 'WebViewCoreThread'. This is an undesirable behavior and a source of problems, but you can take advantage of it if you want (just make sure you don't run UI-related code there). I've never tested this in Kit Kat (which uses a different WebView based on Chrome) but works for previous versions, as I described here.
Now the user can always close any app. Even without user interaction, the OS can kill your app on low memory. So just give up on long-running apps that never end, because the OS is designed in such a way this is simply not possible.
You could go native and schedule Alarms using the AlarmManager.
Just checked this out on the Android KitKat WebView and as per Mister Smith's comments the javascript will continue executing in the background until the Activity is killed off:
Just tested with this running in a WebView:
http://jsbin.com/EwEjIyaY/3/edit
My gut instinct is that if the user has moved your application into the background, there seems little value in performing updates every 30 seconds, it makes more sense to just start updating again once the user opens the device up and cache what information you currently have available to you.
As far as Chrome for Android goes the same is happening, as Chrome falls into the background the javascript is still running.
If you are experiencing different behaviour then what exactly are you seeing and can you give us an example?
Team,
i'm developing an iOS application.
My requirement is to query for specific news service(REST API) in regular time interval.I wanted query the service twice for a day and update my sqllite db, even the applciation is in background state. My UI will be updated with data fetched from sqllite db, while the application is in foreground.
My question are,
Is it possible to run NSTimer in background continuously? if yes, is
there any maximum time limit for timer to run in background (say 10
mins or 60 mins)?
Is it possible to send request to download a file using
NSUrlConnection and save the file to documents directory, when the
application is in background ?
Your suggestions will be much helpful for my project design.
Thanks in advance.
What you are aiming for cannot be achieved on iOS:
Arbitrary apps cannot run in the background for an arbitrary amount of time.
You can try to mitigate some of this by using local notifications instead of NSTimer to schedule your updating. This will, however, only buy you a very limited amount of time to do your networking.
The question you should ask yourself at this point probably is:
If you are only updating twice a day, how bad can it be to initiate the download when your app becomes active?
Answering my own question, so that it will be helpful for others.
Ques 1: Is it possible to run NSTimer in background continuously?
Ans: Nstimer will not run while the application in background state. So there is no point of maximum allowed timer value in background. If the application enters into background while there is an ongoing process, [UIApplication beginBackgroundTaskWithExpirationHandler:] can be used to complete the ongoing process. The maximum time allowed by the OS with this handler is 10mins.
Ques 2: Is it possible to send request to download a file using NSUrlConnection and save the file to documents directory, when the application is in background ?
Ans:
Below given information is from Apple documentation. Detail info is found here
In iOS, only specific app types are allowed to run in the background:
Apps that play audible content to the user while in the background,such as a music player app
Apps that keep users informed of their location at all times, such as a navigation app
Apps that supportVoice over Internet Protocol (VoIP)
Newsstand apps that need to download and process new content
Apps that receive regular updates from external accessories
Info about running background process using VOiP type application can be found here
I am using the 'location' UIBackgroundMode to receive GPS background updates when the user presses the Home button. As a result, if the app is left in background mode overnight, the battery is consistently dead the next morning. I have told the locationManager to stopUpdatingLocation, but to no effect.
I understand Apple doesn't want developers to use exit - in fact it seems to have little effect on the app other than to take it to the background - but I can't afford to have the battery die if the user doesn't end the app.
Any suggestions?
Maybe you could register for a local notification that informs the user they should open the app to stop location tracking? It's not very elegant of course, it seems Apple should allow the developer to register for location updates for a specified length of time, maybe you could submit a feature request for that. I think Loopt monitors for 24 hours and then quits, maybe you could research into how they made it stop after 24 hours. I wish I could help more but I haven't messed with the location framework at all.
You could use a timer and/or background task, which would run after a set amount of idle time, and try to turn off the GPS then. So you can still have location tracking in the background of your app, but after 10-20 minutes, it turns off.