We are working on a mobile video app and need to decide on the video protocol between HLS or MPEG-DASH.
Our key consideration is which of the 2 has a better support and compatibility for browsers and mobile platforms (iOS, Android)?
The video content is recorded/uploaded/watched on a mobile app, but also needs to be shared for viewing on browsers.
It seems initially that HLS has a wider range of platforms support, but would love to hear from anyone's experience.
Thanks!
You will most likely find you have to support both at this time if you want to reach as many users as possible, especially if the content is encrypted.
iOS and Safari typically use HLS and FairPlay, Android, Firefox and Chrome use DASH and Widevine and Windows and Edge use DASH and PlayReady.
At this time, Apple iOS devices must use HLS for content greater than 10 mins over a mobile network:
2.5.7 Video streaming content over a cellular network longer than 10 minutes must use HTTP Live Streaming and include a baseline 192 kbps HTTP Live stream.
(https://developer.apple.com/app-store/review/guidelines/)
For this reason streams served to Apple devices are usually HLS, while DASH is used for other devices.
If you streams are not encrypted you can use CMAF a single source file. If they are encrypted then it will be some time before devices support a single CMAF encrypted source - See more detail here: https://stackoverflow.com/a/62020034/334402
CMFA info here: https://developer.apple.com/documentation/http_live_streaming/about_the_common_media_application_format_with_http_live_streaming
Related
I have a requirement to develop a Android and iOS mobile apps that allow subscribers to view movies like the way Netflix and Iflix does it.
I would like to know if this can be achieved by inbuilt Video playing classes or widgets on the Android and iOS platforms, or if we will need a library or SDK for this.
I came across this URL on how to stream video in Android apps. Would this approach suffice for this requirement?
https://code.tutsplus.com/tutorials/streaming-video-in-android-apps--cms-19888
Netflix and similar systems use ABR to deliver video to mobile devices - ABR allows the client device or player download the video in chunks, e.g 10 second chunks, and select the next chunk from the bit rate most appropriate to the current network conditions. See here for an example:
https://stackoverflow.com/a/42365034/334402
There are several ABR protocols but the two most common at this time are HLS and DASH. HLS must be used to deliver video streams to iOS devices due to the apple guidelines (at this time and for video over 10 mins which may be accessed on a mobile network - the guidelines can change over time) and DASH is probably more common on Android devices, although HLS can be supported on Android also.
Most Android players now can handle ABR - the Android Exoplayer is a good example, is very well used and supports this natively:
https://github.com/google/ExoPlayer
Take a look at the Developers Guide (included in the link above at the time of writing) which shows how to include ExoPlayer in your app.
On iOS the native player supports ABR using HLS.
I am testing out Azure Media services and I am looking for a preset or a custom config which takes an mp3 file and encodes it for playback on iOS, Android (4.0+) and HTML5 for streaming (one manifest hopefully). Currently I am seeing presets for HTML5 and HLS (none for Android) however they are separate and not in one config/workflow. How can I set this up to done. Note I am using the UI and not programming at this time.
Are you planning to deliver in both HLS and MPEG-DASH across multiple HTML5 browsers? You will need to use both of those protocols to reach all of the devices that you have in mind. Android has a really poor implementation of HLS. Most of the Android devices only support HLS v3, so make sure to test your devices with the v3 (muxed ts) protocol.
I would encourage you to use the Azure Media Explorer tool for everything.
http://aka.ms/amse
It gives you easier access to all of the protocol URLs that you will need.
Try encoding everything to Standard Definition Multiple bitrate MP4 files to begin with. Most Android devices only like Baseline profile encoding.
Once you have Multiple bitrate Mp4 files encoded, you will need to enable at least 1 streaming Reserved Unit to allow you to get "dynamic packaging" to work. You need that feature to re-package your MP4 files on-the-fly to HLS and DASH.
Also, if you are looking for an awesome player framework for HTML5 delivery -check out our new Azure Media Player http://azure.microsoft.com/blog/2015/04/15/announcing-azure-media-player/
I'm making an app that needs to send a video feed from a single source to a server where it can be accessed by desktop browsers and mobile apps.
So far, I've been using Adobe Media Server 5 with a live RTMP stream. This gives me about a 2.5 second delay on desktop browsers, which gives me no native support for iOS, but leaves me with the option to use Air to export the app for iOS, which produces a minimum 5-6 second delay.
The iOS docs strongly recommend the use of HTTP Live Streaming which segments the stream into chunks and serves it using a dynamic playlist in a .m3u8 file. Doing this produces a 15+ second delay in desktop browsers and mobile devices. A Google search seemed to reveal that this is to be expected from HLS.
I need a maximum of 2-4 second delays across all devices, if possible. I've gotten poor results with Wowza, but am open to revisiting it. FFMpeg seems inefficient, but I'm open to that as well, if someone has had good results with it. Anybody have any suggestions?? Thanks in advance.
I haven't even begun to find the most efficient way to stream to Android, so any help in that department would be much appreciated.
EDIT: Just to be clear, my plan is to make an iOS app, whether it's written natively or in Air. Same goes for Android, but I've yet to start on that.
In the ios browser HLS is the only way to serve live video. The absolute lowest latency would be to use 2 second segments with a 2 segment windows in the manifest. This will give you 4 seconds latency on the client, plus another 2 to 4 on the server. There is no way to do better without writing an app.
15 Second delay for HLS streams is pretty good, to provide lower latency you need to use a different streaming protocol.
RTP/RTSP will give you the lowest latency and is typically used for VoIP and video conferencing, but you will find it very difficult to use over multiple mobile and WiFi networks (some of them unintentionally block RTP).
If you can write an iOS app that supports RTMP then that is the easiest way to go and should work on Android too (only old Androids support Flash/RTMP natively). Decoding in software will result in poor battery life. There are other iOS apps that don't use HLS for streaming, but I think you need to limit it to your service (not a generic video player).
Also please remember that higher latency equals higher video quality, less buffering, better user experience etc. so don't unnecessarily reduce latency.
I want to embed video's on our website that should work with these restrictions:
The video needs to start as soon as the user clicks on play. As far as I can tell this means that the video must be either streamed or it must use progressive downloads.
The video must not be downloadable by sending the link to other people.
The video must be protected against being viewed without being allowed to do so.
The video must work on all devices, also the ones that do not support flash such
as iOS and android
As a backend I use amazon cloudfront. So far we have used RTMP, but that obviously does not work for iOS or android devices.
What we’re planning to do is this:
For flash platforms we use RTMP with the amazon signed URL’s to prevent anyone to view the content.
For iOS we want to use HLS with a generated m3u8 file that contains signed URL’s to the TS files
For Andoid devices I'm not yet sure what to use.
My questions are these:
Is this a viable setup, or are is there a superior setup that ticks all the boxes?
What should we use for the android case?
I would suggest, use pre-signed hls/m3u8 for both ios and flash.(https://github.com/mangui/HLSprovider). For Android you can use normale html5 video streams with quality selection (signed URLs of course).
For Android you have to use RTSP protocol.
Wowza media server is the perfect solution for you.
I am new to video streaming and am working on a project to broadcast video to android phone over internet, and users to view the video at the same time may reach 100.
After looking around for a while I think using rtsp streaming for the phone client may be convenient(Am I right?) and so I have to choose a server, My current choice will be using
VLC
Darwin Streaming Server
Are they suitable? Or any other better choice?
How about the performance of these two servers while 100 users accessing at the same time.
Thanks in advance
Regards
Bolton
RTSP streaming in H.264/AAC would be the most convenient way to reach Android devices. End-users will not need to install an app or open the stream in one - the native media player will seamlessly open the stream.
If you intend on using VLC for the encoding portion - you may want to reconsider, as I'm not sure it supports H.264/AAC compression, which is required to reach Android devices. You may want to consider using commercial software like Wirecast or the free Flash Media Encoder with the AAC plugin.
Darwin Streaming Server is stable enough to handle that load (100 concurrent viewers), however the amount of throughput you have available and the bit-rate you will be broadcasting at are more important factors to consider when delivering video. In other words - your upload speed has to be able to be sufficient. If it's not intended strictly as a DIY project, I would suggest tapping into a commercial CDN's network (I would recommend NetroMedia).