HLS share is on the same level of 77% share while RTMP share (17%) went down insignificantly. Other protocols are at the same position.
All these metrics calculations are based on nearly 2.9 billion views. The stats are collected from 1700+ media servers, including Wowza, Nimble Streamer, Red5, nginx-rtmp-module and Flussonic. Check the charts below.
Our team keeps tracking news about media streaming, online video and audio from around the world. This gives a lot to think about the industry goes and about what we can do.
As usually, we made a small digest of what we thought might be interesting for our customers and followers.
The main event of this month was the NAB Show 2015 in Las Vegas.
Our CEO Yury Udovichenko visited the trade show and met a lot of our customers and partners. You will see some of the results of these meetings in the near future. Take a look at a few pictures from the show in Facebook account (and subscribe to its updates if you haven't done it yet).
One of the visited events was the DASH IF networking reception. Take a look at the inteviews of the participants. Also, check the best products of the show as seen by Streaming Media magazine.
“Amazon Web Services is a $5 billion business and still growing fast — in fact it’s accelerating,” says Jeff Bezos. Amazon's first quarter sales proove that.
One of the first supported scenarios for Nimble Streamer was HTTP media re-streaming. Today this includes now HLS, SmoothStreaming, HDS and progressive download re-streaming. In this scenario Nimble is used as an efficient caching server which is able to handle media content properly. This means that re-streaming of live content will use its own set of caching techniques and VOD re-steaming will utilize cache in other way.
As people discover more use cases for DASH usage, we wanted to provide full features coverage for this protocol. Like, companies consider using DASH for DRM so they need a way to efficiently deliver streams after the content is encrypted. So basically it's a good case for delivery of pre-packetized content to end users.
This is why we introduce the MPEG-DASH re-streaming capabilities in Nimble Streamer.
Re-streaming cache works the same way as for other protocols. Live stream cache is stored for limited time while VOD media cache may be stored for large periods of time.
It's set up the same way as for other protocols like HLS. An administrator defines a route where he specifies:
Streaming infrastructure maintenance requires some operations with hardware. The hardware may fail some time, it may be upgraded to improve the performance, or your system may need to be moved to other physical location. Being part of streaming infrastructure, Nimble Streamer server instance may need to down and then re-installed again. As it's a high-performance software, it may have a lot of streams' setting so losing the configuration in case of hardware changes is a bad option.
To cover cases like hardware change we added a recovery mode for Nimble Streamer installer. It will re-register the instance in recovery mode and WMSPanel will push existing configs to it.
So in addition to existing routes control API and Icecast control API, we introduce API for controlling RTMP streaming behavior. It can be found when you follow Nimble Streamer -> Live streams set up menu and then click on RTMP settings button for any of Nimble Streamer instances. Another functional area is ABR control for live streaming which is found on a separate ABR page for any Nimble instance.
So in addition to existing routes control API we introduce API for controlling Icecast streaming behavior. It can be found when you follow Nimble Streamer -> Live streams set up menu and then click on Icecast settings button for any of Nimble Streamer instances.
Stream aliasing is a well-known technique in media streaming. It allows mapping multiple names to single media stream in order to add some flexibility into streaming process.
Nimble Streamer now supports it as well, with WMSPanel being an easy-to-use UI to set it up. It allows defining applications which will be covered by mapped applications' aliases.
Basically, aliases are good for case when you have some media stream and you need to provide it under different names. As example, you are a content provider and want to give your stream to multiple partner websites and services.
Here are the major use cases where aliases may work perfectly:
You need different levels of security for each alias. E.g. one of your partners need this stream to be locked to specific country and you need to use geo-location lock. And another partner needs to apply hotlinking protection. Adding separate aliases will allow creating separate security rules via WMSAuth paywall settings.
You need to collect viewers' statistics per each of your partners. In this case after the aliases are set up, you create separate data slice for each partners' alias and give them their own logins in a branded panel. Each slice will have full set of stats for tracking audience performance.
So physically having 1 actual stream, you will give several "virtual" streams, without overhead of resources, but with all benefits of multiple streams.
Get Geo stats - get geo-location statistics for selected dates range.
Get ISP stats - get Internet service providers statistics for selected dates range.
Each method is illustrated sample request URL which you may use via any technique or programming language. If you run it from command line, check this FAQ question as well.
Follow us to learn about new features and contact us in case of any questions.
From the time of its wide adoption, RTMP played an important role in media streaming. Along with Flash player, it opened online video capabilities for huge audience of developers and consumers. This protocol is still the best option when it comes to real-time streaming as it has the least latency among other technologies. It is also used as a fallback for HLS, HDS, SmoothStreaming or DASH when it comes to platforms which do not support these protocols. Thus people keep using this protocol and we need to provide best user experience in streaming.
Notice that RTMP playback scenarios will be declined by the industry during 2019 and 2020 due to Flash technology support discontinuity. So if you need real-time latency for live streams, take a look at Get ready for Flash farewell and RTMP decline article explaining to handle this shift.
Nimble Streamer team has added RTMP streaming support for playback and pull for scenarios when Nimble has RTMP stream as an input. Both published and pulled RTMP sources are supported.
Follow the steps described below to get RTMP output.
First you may take a look at video tutorial about RTMP setup.
To take RTMP streams for transmuxing, you need to specify available sources. After that Nimble will pick them up and start producing streams for immediate use.
Go to Nimble Streamer -> Live Streams Settings menu. Here you have 2 possible scenarios:
get published RTMP streams;
pull RTMP streams.
2. RTMP setup
You may combine both scenarios and process both types of incoming streams to get outgoing streams.
Published streams setup
Go to Global tab. These are global server settings. These are as follows.
Default chunk duration used for outgoing streams.
Default chunks count for the playlist or manifest - this is used for HLS and DASH.
Protocols which will be produced - you can generate all 6 supported types or just one of them, it does not affect the performance much.
Push login and password for published streams - they will be used by default for published streams but can be overridden by individual apps settings.
Global RTMP setting for Nimble server instance.
You may also define individual applications' settings. Go to Applications tab to add new apps. Each app has the same set of fields as Global server settings.
Individual applications' settings.
New application settings.
You may apply new application settings to several Nimble servers instances. Just click on the checkboxes with their names in the dialog - the setting will be applied to each server within a few seconds.
To make Nimble Streamer capable of getting published RTMP streams, it needs to listen to a specific interface - address and port. Go to Interfaces tab and click on Add RTMP interface.
You'll see a dialog for specifying an address and a port to listen to. You may leave IP address blank, in this case Nimble will listen to all IP addresses available.
You may also apply new settings to multiple servers to convenience of administration.
If you have only published streams, then you can move to "RTMP Flash playback setup" section.
Pulled streams setup
If your streaming content is available via public URL RTMP streams, you may pull them into Nimble instances for further transmuxing. To make proper settings, go to Live pull settings tab.
There you click on Add RTMP URL button to see new dialog for adding new stream to transmux. There you enter:
URL - the address of RTMP stream.
Fallback URLs - if you have multiple sources of the same stream, you may specify them to make robust streaming, so if main stream goes down, secondary streams could be used.
Application and stream are the the names which will be used for DASH stream URL.
As already mentioned in other settings, you may apply this setting to multiple servers - just click on the checkboxes with their names. Also you can use advanced RTMP pull settings to specify incoming RTMP streams. Please read the Processing RTMP and RTSP pull streams per request article for details.
Once it's saved, you'll see it in settings list.
The output streams will be served via protocols which are set up in server global or application settings.
E.g. if you've set up "live" app individual settings in "Applications" tab and set it to produce RTMP and HLS, then pulled streams will be processed to produce RTMP and HLS.
Now the RTMP outgoing streams will be produced as soon as the incoming stream arrives. Those streams might be played as well as pulled by other media servers (e.g. Nimble, Wowza, Red5 etc).
Using outgoing streams
Having incoming streams defined and processed, you may now use the results of Nimble Streamer work for streaming your content via the protocol which you selected in global or application settings.
Click on Outgoing stream area on a chart or Outgoing link on top of the setup area. You will see all streams that are currently processed and ready for usage. Each stream has
status,
names of servers which have this stream running,
stream name for playback URL,
video and audio parameters and options,
link for getting playback URL - it's a question mark icon.
Available outgoing streams list.
To use the outgoing stream for playback, click on question mark icon to see Sample URL for player dialog. Here you see selectors for playback links for protocols which you defined for this server in global settings. You will also be able to watch it in one of pre-defined players and get respective player code. Players list depends on the protocol selected.
Providing RTMP streams allows settings up various scenarios from playback to live media delivery between origins and edges. The delivery case is a good addition to RTMP re-publishing feature set which uses stream publishing rather then stream pulling.
Related features
If you need to secure your RTMP streams during transmission over public networks, you can also use SSL for RTMP transmission.
If you need to change content parameters, like change the bitrate for creating ABR playback, use our Live Transcoderfor Nimble Streamer to transform. It has high performance and low resource usage.
When producing RTMP output streams, you can use Nimble Advertizerfor server-side ads insertion. It provides a framework for inserting pre-roll and mid-roll ads into live streams for further output via RTMP, SLDP and Icecast with custom business logic and per-user ads.
Visit Advertizer web page to find out more.
