December 30, 2019

2019 summary

As the the year of 2019 is over, we want to recap the most significant products and features which we introduced during past 12 months.

We'd like to remind you that you can track all of our latest Softvelum changes via our TwitterFacebookLinkedIn posts and even YouTube channel news podcasts.

Qosifire web service


This year we released a new product called Qosifire. It's a streaming quality monitoring web service which allows tracking live HLS, RTMP and Icecast streams. Qosifire checks for stream correctness from protocol integrity and general content consistency viewpoints. Qosifire agent software checks streams 24/7 using your own server, then our web service console collects data to analyse and sends alerts via email and mobile push notifications.

Read more about why you may need Qosifire for your streaming infrastructure and how you can get started with Qosifire. In addition, read a Qosifire review article by Jan Ozer and find more information in Qosifire knowledge base.

You can also run a free 30-seconds checkup for your live stream without a sign-up.

Nimble Streamer bundle updates


As we explained in January, Flash has been continuously removed in all browsers which caused the decline of RTMP playback. This affects primarily live low latency streaming, this is why we've been working on low latency improvements in our products.

SLDP. First of all, SLDP ABR capabilities ignited a wide adoption among our customers. They use Nimble Streamer for their delivery edges and play their content via HTML, Android and iOS players to have nearly a latency of just about a second long.

Apple introduced Low Latency HLS earlier and released it for developers community.
Now Apple Low Latency HLS is supported in Nimble Streamer with MPEGTS, audio-only and fMP4 containers. Read this introduction article which describes Nimble Streamer setup and LL-HLS usage. As of iOS 13.3, Apple hasn't released LL-HLS from beta stage yet, so we don't have player app available. But our iOS SLDP Player SDK is able to provide this for our subscribers.
BTW, LL-HLS is working on top of HTTP/2 implementation available in Nimble Streamer. You can use it for HLS and MPEG-DASH live streaming delivery.

SRT. Another outstanding technology which we improved over this year was SRT reliable delivery over UDP. Being a member of SRT Alliance we contributed to the community and kept improving user experience allowing to tune latency and maxbw to improve reliability. Our products always have the latest stable versions of SRT library to make sure they have all the latest improvements.

Icecast. Speaking of other improvements, we added more features related to Icecast metadata as described on our Icecast feature page.

SSL. For those of our customers who use Certbot with Let's Encrypt, we made a detailed description for using this duo with Nimble Streamer.


Live Transcoder has been improved in several ways as well. First, take a look at Transcoder overview screencast and Transcoder documentation reference page to see what we got.

We've added SVT-HEVC software library for H.265/HEVC encoding in Live Transcoder for Nimble Streamer.
This feature utilizes the latest improvement, the ability to run encoder out-of-process which allows securing the main Nimble Streamer process in case if some encoder library causes crashes.

The HEVC in general has been on the rise this year. To meet customers' demands we've released an experimental support of H.265/HEVC over RTMP in Nimble Streamer and Larix Broadcaster apps.

As for encoder libraries, QuickSync hardware acceleration is now available on Ubuntu which makes it easier to install.

Nimble Advertizer was improved through this year to handle SCTE-35 markers:
Read Advertizer spec to full details.

Reference pages. Last but not least, we added a couple of useful digest pages:


Mobile solutions


Our mobile solutions were improved over this year.

One of the most significant improvements is adding SRT playback into SLDP Player for Android and iOS. You can also take a look at our SRT digest page to find out more about product support for this technology.

As was mentioned earlier, our iOS SLDP Player SDK is able to provide Low Latency HLS playback capabilities for those who would like to try this new technology. Feel free to subscribe to iOS SLDP Player in order to obtain the latest version and build your own app with LL-HLS.

We also released Larix Screencaster for iOS - a highly anticipated great addition to our mobile apps bundle.

Larix Broadcaster is now able to produce RTMPS and RTSPS, which means RTMP and RTSP can be delivered via SSL. It's a great advantage for those who would like to secure their live streams in un-secure environments like mobile networks or public WiFi.
Larix also has ABR support for outgoing streams which means it can lower bitrate and framerate according to network conditions.

Softvelum website now has Larix documentation reference which has links to all articles and pages related to mobile streaming with our products.

You can read SDKs release notes to find out more about our updates and releases.




Softvelum team wishes you a Happy New Year and looks forward to bringing you more features and improvements!



Follow us via TwitterFacebookLinkedIn and YouTube to get updates on time.

December 29, 2019

The State of Streaming Protocols - 2019 Q4

Softvelum team keeps tracking the state of streaming protocols. It's based on stats from WMSPanel reporting service which handles data from Wowza Streaming Engine and Nimble Streamer servers. This quarter WMSPanel collected data about more than 17.8 billion views. Total view time for our server products is 2.25 billion hours this quarter, or 24+ million view hours per day.

The State of Streaming Protocols - Q4 2019

You can compare these numbers with metrics from Q3 2019:

The State of Streaming Protocols - Q3 2019

Most protocols state kept the same share with HLS controlling the most of delivery landscape.


We'll keep analyzing protocols to see the dynamics. Check our updates at FacebookTwitter and LinkedIn.

If you'd like to use these stats, please refer to this article by original name and URL.

December 24, 2019

Introducing Apple Low Latency HLS in Softvelum products

The HLS of RFC8216 is currently a de-facto standard for live and VOD delivery. Playlists and chunks delivered over HTTP/1.1 provide the simplicity of implementation, wide platforms availability, adaptive bitrate support and scalability. These advantages allowed it to get the biggest share of customer base. However it has some disadvantages for live streaming, primarily because chunks delivery means many seconds of delay at the start of a live stream. The industry has been making some improvements on top of HLS, and then Apple released its spec update to address existing issues.

Low Latency HLS


Low Latency HLS (LL-HLS) is the next generation of Apple's HTTP Live Streaming protocol introduced in early 2019.
Several key features improve it over regular HLS for live delivery:
  • Partial segments (parts) can be accessed before full chunks of content are available.
  • Server side can use HTTP/2 Push for sending parts.
  • Holding playlist requests for obtaining latest parts as soon as they appear.
Softvelum team added LL-HLS into the bundle. We provide customers with playback capabilities using SLDP Player for iOS, and Nimble Streamer allows generating LL-HLS for all supported containers such as fMP4, audio-only and MPEGTS.

1. SLDP Player to play LL-HLS


Apple still has LL-HLS in beta stage as of iOS 13.3 at the end of December of 2019, so there are a number of shortcomings in its implementation. The main concern is the fact that iOS native player implementation cannot be published into AppStore yet. Lack of browsers' and other platforms' availability is also a big blocker so far. So the only way to try the playback for development purposes is to build your own app for that.

SLDP Player SDK for iOS allows having full-featured Low Latency HLS playback on iOS devices. It covers live streams from any source capable of LL-HLS like Wowza Streaming Engine and Nimble Streamer, and it also supports regular HLS from any available source.

If you'd like to build your own low latency playback app, you can get player SDK from our team for further test and integration. Once the LL-HLS technology goes from Apple beta to production (in early 2020 as per Apple), you'll be able to have full-featured app and publish it under your brand.

2. Nimble Streamer for LL-HLS transmuxing


Nimble Streamer software media server allows taking any supported live input streams and re-packaging them into Low Latency HLS. Here are the steps you need to follow in order to make it work.

2.1 HTTP/2 and config setup


2.1.1. LL-HLS uses HTTP/2 via SSL as a transport protocol. So you need to enable it before performing any further setup.
Please follow this HTTP/2 setup article to make this protocol working for Nimble Streamer.

2.1.2. In addition to that, you need to add this parameter into nimble.conf and restart Nimble Streamer, read this page for config setup details:
hls_add_program_date_time = true
If a client tries to access LL-HLS stream via HTTP/1.1, or if HTTP/2 is not properly set up, then player will fall back to regular-legacy HLS and will not use any advantages of LL-HLS.

You can check if Nimble Streamer delivers HTTP/2 by checking access log. To enable access logs, add this parameter into nimble.conf the same way you've done it for other parameters:
log_access = file
Once you re-start Nimble, you'll be able to view the log. In Ubuntu it's located in /var/log/nimble/access.log by default. Now when you try to get your regular HLS live stream via https:// via curl or HTTP/2-capable player, you'll get this kind of record in access log:
Dec 24 17:43:09 nimble[5500]: [nimble-access.log] 192.18.1.2 - - "GET /livell/stream/playlist.m3u8 HTTP/2" 200 84 1114 372 "-" "AppleCoreMedia/1.0.0.17C54 (iPhone; U; CPU OS 13_3 like Mac OS X; en_us)"
You can see HTTP/2 there which means it's working. In other cases it will have HTTP/1.1 and this will mean you need to check what's wrong. Contact us in case of issues.

2.2 Live streaming setup


Now you need to set up transmuxing settings via WMSPanel web service. If you are not familiar with live streaming setup of Nimble Streamer, please refer to live streaming digest page, or respective input protocol pages, such as RTMP streaming. Please make sure you have a correctly set up live stream (like regular-latency HLS or SLDP) before trying to use LL-HLS.

Once you have a live stream set up in WMSPanel, go to Nimble Streamer top menu and select Live streams settings. You will see Global setting tab for selected server (and you may create application-specific setting as well).


Currently, Nimble Streamer supports all 3 containers available for HLS, you can see their respective checkboxes on the screenshot above:
  • HLS - HLS with audio-only container. Audio-only is optimized for audio delivery having a reduced size. The ID3 tags are also inserted in each audio part.
  • HLS (MPEGTS) - MPEG-TS: the only container with video and audio support for LL-HLS
  • fMP4 - fragmented MP4. Notice that fMP4 container playback has a couple of issues related to current Apple implementation of their player as of iOS 13.3, please refer to section "3. Known issues" below for more information.
Once you select either of those containers, WMSPanel will show Enable Apple's Low Latency HLS checkbox and you need to select it. It will also show HLS part duration edit box to define parts' duration in milliseconds, we recommend using default value of 1000ms, see section "3. Known issues" for details.

Once LL-HLS is enabled, you need to re-start the input stream so Nimble Streamer could start producing LL-HLS output stream.

2.3 Workflow and playlists


Now as the set up has been made, you can use the player to consume the stream using the usual playback URL. The main playlist will have proper chunklists which will have a content according to LL-HLS spec, as shown in the example below.
#EXTM3U
#EXT-X-VERSION:7
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-MAP:URI="audio.fmp4?nimblesessionid=1"
#EXT-X-TARGETDURATION:7
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=1.536
#EXT-X-PART-INF:PART-TARGET=0.512
#EXT-X-PROGRAM-DATE-TIME:2019-12-23T02:29:02.609Z
#EXTINF:5.995,
a_6_6016_1.fmp4?nimblesessionid=1
#EXT-X-PART:DURATION=0.512,URI="a_6_12011_2_0.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_12011_2_1.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_12011_2_2.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_12011_2_3.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_12011_2_4.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_12011_2_5.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_12011_2_6.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_12011_2_7.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_12011_2_8.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_12011_2_9.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_12011_2_10.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.363,URI="a_6_12011_2_11.fmp4?nimblesessionid=1"
#EXT-X-PROGRAM-DATE-TIME:2019-12-23T02:29:08.604Z
#EXTINF:5.995,
a_6_12011_2.fmp4?nimblesessionid=1
#EXT-X-PART:DURATION=0.512,URI="a_6_18006_3_0.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_18006_3_1.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_18006_3_2.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_18006_3_3.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_18006_3_4.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_18006_3_5.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_18006_3_6.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_18006_3_7.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_18006_3_8.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_18006_3_9.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_18006_3_10.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.362,URI="a_6_18006_3_11.fmp4?nimblesessionid=1"
#EXT-X-PROGRAM-DATE-TIME:2019-12-23T02:29:14.599Z
#EXTINF:5.994,
a_6_18006_3.fmp4?nimblesessionid=1
#EXT-X-PART:DURATION=0.512,URI="a_6_24000_4_0.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_24000_4_1.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_24000_4_2.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_24000_4_3.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_24000_4_4.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_24000_4_5.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_24000_4_6.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_24000_4_7.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_24000_4_8.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_24000_4_9.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_24000_4_10.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.384,URI="a_6_24000_4_11.fmp4?nimblesessionid=1"
#EXT-X-PROGRAM-DATE-TIME:2019-12-23T02:29:20.593Z
#EXTINF:6.016,
a_6_24000_4.fmp4?nimblesessionid=1


Parts in chunklist. Comparing to regular HLS, you see a lot of lines representing parts like this:
#EXT-X-PART:DURATION=0.512,URI="a_6_24000_4_0.fmp4?nimblesessionid=1"
The full chunk which contain these parts will be described after all parts' lines:
a_6_24000_4.fmp4?nimblesessionid=1
All parts within chunks are numerated starting from zero. So "a_6_18006_3_0.fmp4" mean its the first part of chunk number 3.

Part length. This attribute declares a designated size of upcoming parts:
#EXT-X-PART-INF:PART-TARGET=0.512
In this example it's 512 milliseconds.

Can block reload
. Check this line:
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=1.536
The "CAN-BLOCK-RELOAD" declares that media server allows holding playlist request.

Hold playlist request. LL-HLS allows requesting the server to hold sending out the playlist until a specific chunk and/or part is available for the stream.
So a player may request some part which is going to be available within a few seconds from now, then Nimble Streamer will check if that part is available. Once the requested part is ready, Nimble will return a playlist.

Check this request example:
curl -k "https://localhost:8443/livell/stream/chunks.m3u8?nimblesessionid=1&_HLS_msn=59&_HLS_part=5"
The highlighted _HLS_msn=59 and _HLS_part=5 parameters indicate that the server must hold the request until Nimble Streamer has part number 5 of chunk number 59 or later and then it could return a playlist. You can use only _HLS_msn=59 parameter, in this case the playlist will be sent out only once full chunk is available.

The resulting chunklist will look like this:
#EXTM3U
#EXT-X-VERSION:7
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-MAP:URI="audio.fmp4?nimblesessionid=1"
#EXT-X-TARGETDURATION:7
#EXT-X-MEDIA-SEQUENCE:55
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=1.536
#EXT-X-PART-INF:PART-TARGET=0.512
#EXT-X-PROGRAM-DATE-TIME:2019-12-23T02:34:26.599Z
#EXTINF:5.994,
a_6_330006_55.fmp4?nimblesessionid=1
#EXT-X-PROGRAM-DATE-TIME:2019-12-23T02:34:32.593Z
#EXTINF:6.016,
a_6_336000_56.fmp4?nimblesessionid=1
#EXT-X-PART:DURATION=0.512,URI="a_6_342016_57_0.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_342016_57_1.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_342016_57_2.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_342016_57_3.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_342016_57_4.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_342016_57_5.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_342016_57_6.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_342016_57_7.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_342016_57_8.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_342016_57_9.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_342016_57_10.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.363,URI="a_6_342016_57_11.fmp4?nimblesessionid=1"
#EXT-X-PROGRAM-DATE-TIME:2019-12-23T02:34:38.609Z
#EXTINF:5.995,
a_6_342016_57.fmp4?nimblesessionid=1
#EXT-X-PART:DURATION=0.512,URI="a_6_348011_58_0.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_348011_58_1.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_348011_58_2.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_348011_58_3.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_348011_58_4.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_348011_58_5.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_348011_58_6.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_348011_58_7.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_348011_58_8.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_348011_58_9.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_348011_58_10.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.363,URI="a_6_348011_58_11.fmp4?nimblesessionid=1"
#EXT-X-PROGRAM-DATE-TIME:2019-12-23T02:34:44.604Z
#EXTINF:5.995,
a_6_348011_58.fmp4?nimblesessionid=1
#EXT-X-PART:DURATION=0.512,URI="a_6_354006_59_0.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_354006_59_1.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_354006_59_2.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_354006_59_3.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_354006_59_4.fmp4?nimblesessionid=1"
#EXT-X-PART:DURATION=0.512,URI="a_6_354006_59_5.fmp4?nimblesessionid=1"
You can see it ends with part a_6_354006_59_5.fmp4 - it's part number 5 of the upcoming chunk 59. That chunk will be available only a few seconds later, but the player can already perform the playback, this helps a lot with reducing the latency.

Push the requested part. In addition to requesting specific part upon its arrival, a player may request Nimble Streamer to make HTTP/2 Push of that part to reduce the playback latency even further. This will be made by adding "_HLS_push=1" parameter in URL. If we look at Nimble Streamer access logs, we'll see the following actions:

Dec 24 18:43:04 nimble[5500]: [nimble-access.log] 192.18.1.2 - - "GET /livell/stream/chunks.m3u8?nimblesessionid=18&_HLS_msn=9&_HLS_part=0&_HLS_push=1 HTTP/2" 200 84 1114 372 "-" "AppleCoreMedia/1.0.0.17C54 (iPhone; U; CPU OS 13_3 like Mac OS X; en_us)"
Dec 24 18:43:04 nimble[5500]: [nimble-access.log] 192.18.1.2 - - "PUSH /livell/stream/l_4_27008_9_0.aac?nimblesessionid=18 HTTP/2" 200 0 49896 662 "-" "AppleCoreMedia/1.0.0.17C54 (iPhone; U; CPU OS 13_3 like Mac OS X; en_us)"

Dec 24 18:43:05 nimble[5500]: [nimble-access.log] 192.18.1.2 - - "GET /livell/stream/chunks.m3u8?nimblesessionid=18&_HLS_msn=9&_HLS_part=1&_HLS_push=1 HTTP/2" 200 84 1180 341 "-" "AppleCoreMedia/1.0.0.17C54 (iPhone; U; CPU OS 13_3 like Mac OS X; en_us)"
Dec 24 18:43:05 nimble[5500]: [nimble-access.log] 192.18.1.2 - - "PUSH /livell/stream/l_4_27008_9_1.aac?nimblesessionid=18 HTTP/2" 200 0 49828 568 "-" "AppleCoreMedia/1.0.0.17C54 (iPhone; U; CPU OS 13_3 like Mac OS X; en_us)"

As you can see the player is sending hold-playlist request (described earlier) with specific part number and _HLS_push=1 parameter. Nimble Streamer returns that playlist in response, as well as making HTTP/2 Push for the requested part.

Performance. With all these specific actions Nimble Streamer generates and serves parts within HLS stream with high efficiency. From resource consumption perspective, LL-HLS processing costs the same as handling regular-latency playlists and chunks.

3. Known issues and troubleshooting


At the moment Apple native player on iOS 13.3 has the following problems with LL-HLS implementation which may affect end-user experience.

1. fMP4 video+audio. If you use fMP4 container then you will be able to get either video or audio component working. Video+audio fMP4 streaming is not working properly yet. You can try using MPEGTS container for video+audio instead.

2. Part duration. If you set part duration to less than 1000 ms then video will not work at all. So we recommend setting part duration as "1000".

We are sure those issues will be fixed in Apple's upcoming releases. Meanwhile on iOS 13.3 you'll have to test it with aforementioned limitations.

3. Interleaving compensation. If you have video+audio stream you may have issues with playback due to interleaving as described in this article. This kind of issues becomes even more severe in case of low latency playback. In order to fix this you can try enabling interleaving compensation with Min. delay set to zero, see the image below.





Feel free to try Nimble Streamer with Low Latency HLS and buy SLDP Player SDK to get your hands on the iOS playback.

Let us know if you have any questions.

December 17, 2019

Running encoders in out-of-process mode

Live Transcoder for Nimble Streamer allows using a number of encoder libraries for producing output stream content. All encoding activities are performed in the same process with the other transcoding pipes.

However, there are cases when encoder libraries may cause issues. Some experimental encoders may be unstable during extensive usage and even legacy encoders in some cases may act unpredictably - that is because the encoding process is very complicated. These issues may cause the main Nimble Streamer process to go down and stop processing streams. This affects overall robustness and stability of streaming infrastructure.

To address that, we've made Live Transcoder to support running encoders in out-of-process mode. It makes Nimble Streamer to start a new separate process for each encoder in transcoder scenario. If the encoder fails, the process is stopped and automatically re-started without affecting overall transcoding. The output is also not interrupted so your end-users will notice just a short image freeze.

By default, out-of-process encoding is enabled only if you choose SVT-HEVC encoding library for specific encoder. For all other encoders, this capability is disabled by default.

To enable this feature, you need to open encoder details dialog, enter new nimble-execution-mode parameter on the left and then enter its out-of-process value to the right as shown on the image below.


Once you save the transcoding scenario and it's synced to Nimble Streamer instance (which happens 30 seconds), this will take immediate effect.

Out-of-process encoding is available in Nimble Streamer starting from version 3.6.3-2 and Live Transcoder starting from version 1.1.1-2.

This improvement brings ability to have more robust and reliable transcoding. Let us know if you have any questions regarding this feature usage.


Related documentation


Live Transcoder, Transcoder documentation reference

December 12, 2019

SVT-HEVC H.265 encoding setup in Nimble Streamer Transcoder

Nimble Streamer Live Transcoder has support for various codecs using a number of encoding libraries. H.265 (HEVC) encoding has been supported only via NVENC and QuickSync hardware acceleration so we were looking for the best ways to provide software alternative to that.

Now Live Transcoder can use SVT-HEVC for software encoding. The Scalable Video Technology for HEVC Encoder by Intel® is an HEVC-compliant encoder library core highly optimized for Intel Xeon™ Scalable Processor and Xeon™ D processors. However it can also be used on other hardware supported by Live Transcoder.


The output can be delivered by Nimble Streamer via any protocol which supports HEVC delivery.

The library is delivered with Nimble Live Transcoder and can be used like any other software encoder. The setup process is described below.

Install Live Transcoder


Live Transcoder is a premium add-on for Nimble Streamer freeware media server. You'll need to subscribe for its license in order to start using it.

You need to follow these installation instructions in order to set it up for further usage.

Create transcoding scenario


Live streams transcoding is set up using transcoding scenarios. Each scenario is a graphical representation of content transformation for video and audio ingredients. It has decoding elements to specify how the stream is decoded, filter elements to define the content transformation and encoder elements to put the content into the right codec.

You can refer to Documentation reference for setup details, including video tutorials.

The next section explains how to use encoder element to setup HEVC encoding with SVT-HEVC.

SVT-HEVC encoder settings


Once you've set up the designated transcoding scenario, add encoder element for your output and choose libsvthevc from the list of Encoder field values.


You'll be able to specify Key frame alignment from the list of supported values similar to those used in libx264 setup. The profile values can vary between "main" and "main10". In addition to that you can define other parameters specific to SVT-HEVC.

Live Transcoder supports a subset of SVT-HEVC encoder parameters, you can read their respective description on project page:

  • asm
  • base-layer-switch-mode
  • brr
  • constrd-intra
  • deblock
  • encMode
  • fps-denom
  • fps-num
  • hierarchical-levels
  • hme
  • hrd
  • interlaced-video
  • intra-period
  • irefresh-type
  • lad
  • level
  • lp
  • max-qp
  • min-qp
  • pred-struct
  • profile
  • q
  • rc
  • rt
  • sao
  • scd
  • search-h
  • search-w
  • sharp
  • speed-ctrl
  • ss
  • tbr
  • threads
  • tier
  • tile_col_cnt
  • tile_row_cnt
  • tile_slice_mode
  • umv
  • use-default-me-hme
  • vbv-bufsize
  • vbv-init
  • vbv-maxrate


Also notice the SVT-HEVC is running in out-of-process mode by default, you can read about it in this article.


If you have any questions related to transcoding, feel free to contact us.

Related documentation

Live Transcoder, Transcoder documentation reference,
.

November 20, 2019

HTTP/2 in Nimble Streamer

The Internet as we know it was created on top of HTTP versions 1.0 and 1.1, with HTTP/1.1 being dominant for the last 20 years. The growing demand for new features and capabilities showed several cavities in it and they were addressed in HTTP/2, which has been developed and adopted as a successor for 1.1. You can read the Introduction to HTTP/2 by Google team to see what exactly HTTP/2 has to offer.

At the moment HTTP/2 is supported in all modern browsers and every time users are trying to reach some resource on the Internet, their browser tries to connect through this new protocol version. If it succeeds then all further collaboration is performed via this new channel. If HTTP/2 in unavailable then the browser switches to HTTP/1.1.

Softvelum team has implemented HTTP/2 for some of Nimble Streamer output HTTP-based protocols to provide our customers with one more advantage for their end-users and establish the ground for further development.

HTTP/2 in Nimble Streamer


Nimble Streamer now has support for HTTP/2 protocol in most popular streaming scenarios. No change to input streams is required, you only need to enable the feature as described in "Enabling HTTP/2" section below.

HLS


HTTP Live Streaming (HLS) by Apple is a de-facto standard for end-user media consumption so we implemented extended support for HTTP/2:

  • Live HLS streams with fMP4/CMAF, MPEG-TS and audio-only containers are fully supported.
  • Ads insertion in live HLS via Nimble Advertizer is working fine as usual.
  • HLS DVR output works fine with all of its features.
  • VOD HLS is working in case of transmuxing from local files.

MPEG-DASH


MPEG-DASH live streams and VOD can be played via HTTP/2. VOD DASH is working in case of transmuxing from local files at the moment.

Progressive download


Nimble Steamer can serve local files via progressive download over HTTP/2.

Other protocols


At the moment only aforementioned protocols can be delivered via HTTP/2.
Everything else - HTTP re-streaming, Icecast and HTTP MPEG-TS - will be processed only via HTTP/1.1. We'll add them later on.

Enabling HTTP/2


HTTP/2 can be used only when Nimble Streamer streams over HTTPS, so in order to make it process HTTP/2 requests, you need to do the following.


After that you'll be able to use HTTP/2 to reach live streams with HLS and MPEG-DASH protocols enabled.

LiteSpeed HPACK library


Nimble Streamer uses LS-HPACK library for encoding and decoding HTTP headers using HPACK compression mechanism.

Softvelum team would like to say thank you to LiteSpeed team, we appreciate their effort and technical expertise. We've made several contributions to LS-HPACK code base and we plan to continue that support as long as we move forward in our HTTP/2 development.



Let us know if you have any thoughts or feedback regarding HTTP/2-based streaming.

Related documentation


Nimble StreamerNimble AdvertizerHLS in Nimble StreamerMPEG-DASH in Nimble Streamer

November 6, 2019

Wowza Streaming Engine and WMSPanel agent upgrade

Wowza Media Systems has just released Wowza Streaming Engine version 4.7.8 which has a big set of major updates. Softvelum has a wide feature set for this media server so we keep our software up-to-date with all new changes.

After this release, if you install WMSPanel agent using common procedure then it will work fine on any Wowza Streaming Engine version.

If you have WMSPanel agent installed on your server already then it will stop working after this Wowza update.

So if you plan upgrading to the latest Wowza engine release, please follow these steps:
  1. Upgrade Wowza Streaming Engine per Wowza instructions.
  2. Upgrade WMSPanel agent for Wowza using this procedure: https://wmspanel.com/docs/wowza_upgrade
The new WMSPanel agent version number will be no less than 4.0.0.10308 after that.

This will make a smooth transition from WMSPanel reporting viewpoint.

Please contact us if you have any issues or questions.

WMSPanel API to control push API

Nimble Streamer provides various push APIs which allow controlling the streaming process such as Publish controlPay-per-view or playback authorization.

Typically you set those APIs settings via web UI by opening "Control" -> "API setup" menu.

And now we have API for API setup! You can use "Push API settings" API methods to perform control by making API calls. Please open the respective section of API reference.
It has the following methods:

  • Get global push API settings gives parameters of "Global push API" tab.
  • Set global push API settings sets parameters for "Global push API" tab.
  • Get list of servers push API settings gets list of servers from "Servers push API" tab.
  • Get server push API settings gets parameters of selected server.
  • Set server push API settings sets parameters for a server.
  • Remove server push API settings removes parameters.

So having those you can dynamically control your push API based frameworks.

You can check our Nimble Streamer configuration reference page for more API descriptions.

Related documentation

November 5, 2019

SRT playback support in SLDP Player

SRT became a popular transport protocol for live streams secure delivery over unreliable network. Softvelum team has been an active contributor to SRT open source community being part of SRT Alliance.

Softvelum products lead products have full support for SRT:


Now we introduce SRT playback support in SLDP Player for Android and SLDP Player for iOS.
SLDP Player for HTML5 does not support SRT yet unfortunately.

Mobile SLDP Players provide low latency consumption of SLDP, RTMP, Icecast, HLS and MPEG-DASH and adding SRT gives more flexibility, robustness and reliability for end-user last-mile playback.

You can get SLDP Player free app in Google Play and AppStore.

SRT can be obtained via SRT Pull mode, so you need to make sure your source media server or streaming service has SRT Listen mode enabled for the output stream. Read SRT setup description for Nimble Streamer to see how it can be set up there.

The player setup is easy, just open the application, add new connection and enter your stream with srt:// protocol prefix.



The Player supports the following SRT parameters and provides respective fields:
  • passphrase and pbkeylen;
  • latency and maxbw - read this article for more details about their usage;
  • streamid in case your media source supports it.


Once you save it and tap on it, it will connect to your server and will start playing the stream.



Let us know if you have any questions or suggestions regarding SLDP Player.

October 7, 2019

Enable hardware acceleration for Intel Quick Sync on Ubuntu

Nimble Streamer Transcoder supports Intel® Quick Sync technology for encoding acceleration using Intel® processors feature set. Nimble Streamer allows using Quick Sync as AVC/H.264 video encoder in transcoding scenarios.

Once you have Quick Sync installed, the encoding becomes available in our Transcoder.

The instructions below describes how to enable hardware acceleration on Ubuntu 19.04 and later releases.

Install required packages


Run the following command to install required packages on Ubuntu:
sudo apt-get install intel-media-va-driver-non-free libmfx1

Notice hat they are available on 19.04 and later releases.

Set up Nimble Streamer Transcoder


Follow Transcoder Ubuntu installation procedure to install it on your server.
Use Ubuntu 18.04 instruction there as it works fine on 19.04.

This articles describes how to use this encoder: H.264/AVC QuickSync encoder parameters.
After that you'll be all set to use Intel acceleration on Ubuntu with our live Transcoder.


If you face any questions, feel free to contact us for any questions.

Related documentation


Live Transcoder for Nimble Streamer, Live Streaming features, Transcoder support for Intel® Quick Sync,  Enabling hardware acceleration on CentOSEnabling hardware acceleration on Windows,

Intel is a trademark of Intel Corporation in the U.S. and/or other countries.

October 1, 2019

Stream availability push API notification

Nimble Streamer provides a variety of APIs and frameworks, including Publish control, Pay-per-view and playback authorization framework, along with other solutions.

Now this tool set has event notifications for incoming live streams' availability, like RTMP and RTSP publish/unpublish events, MPEG-TS streams, Icecast pulled streams and also Live Transcoder output. Nimble Streamer can inform you about the start of stream ingestion and stop of incoming stream.

Why we implemented this as a push API which notifies your handler about all live streams; behavior.

If you want to use the notifications API, the major steps for usage are as follows:
  1. Create a processing script on your web site.
  2. Specify a processing script URL via WMSPanel UI.
  3. Test the solution.
After that, your script will be automatically called each time your Nimble Streamer instances gets proper events.

Let's go step by step to see what you need to do.

1. Create a processing script


Nimble Streamer uses POST request to call your URL. Your script MUST get request body first.

Request body will look differently for different types of calls. Here are examples, with additional formatting, the fields are described below.

RTMP is published into Nimble:
{"ID":"c581b1c2-686a-8140-8deb-f44031fa393f",
  "Signature": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTg",
  "Puzzle": "42342-33434-343434-34343",
  "publish":[{
      "stream":"live\/4k",
      "protocol":"RTMP",
      "time":1569999976249,
      "type":"push",
      "remote_ip":"127.0.0.1"
    }]}

Nimble started receiving output from Live Transcoder:
{"ID":"c581b1c2-686a-8140-8deb-f44031fa393f",
  "publish":[{
      "stream":"live\/4k_ao_aac",
      "protocol":"ENCODER",
      "time":1569999976374,
      "type":"pull"
    }]}

Icecast stream is not pulled anymore:
{"ID":"c581b1c2-686a-8140-8deb-f44031fa393f",
  "unpublish":[{
      "stream":"live\/4k",
      "protocol":"ICECAST",
      "time":1570000823258
    }]}

Two major types of calls are available:

  • "publish" means that the incoming live stream has appeared in Nimble Streamer input.
  • "unpublish" means the stream is not in the input of Nimble Streamer anymore.

The following fields are used:

  • "stream" shows application and stream name in the call.
  • "protocol" is one of the following values: RTMP, RTSP, ICECAST, MPEG-TS (which covers MPEGTS and also pulled HLS) and ENCODER (output stream of Nimble Live Transcoder)
  • "time" is publish/unpublish event epoch time in milliseconds.
  • "remote_ip" is provided in case the stream is a published, it shows the IP of the publisher.


"Signature" and "Token" is what your script MAY check to make sure that it was Nimble Streamer who sent it.
Signature = BASE64(MD5(ID + Puzzle + Token))

You can find a small PHP sample of processing the incoming request in out github samples repo.

2. Set up API in WMSPanel


2.a Global setting

Go to Control / API Settings and choose Global push API tab.



Here you need to use two fields:
  1. Enter handler URL into Streams (un)publish handler URL field;
  2. Click on Enable publish/unpublish notifications checkbox.
After you click Save, the first sync-up will be sent to your handler within several seconds.

API parameters also include Token field as well as Enable mutual authorization check box. Those should be used if you'd like to use signature as described in section 1 above.

2.b Server instance setting

You may also make per-server setup. Just click on Servers push API tab to be able to define same settings for each individual server.

3. Test the complete solution


Now you can set up a testing stream or use existing one to try this feature. Just publish that stream to and get notified by the panel via the script. In the github example above you'll get a new log entry.

WMSPanel provides a test handler you can use for trying your calls. You'll be able to debug your scrip real-time.

Once you test it, you can use it in production together with other API features and frameworks.

Related documentation


Nimble Streamer, RTMP streaming in NimbleWMSPanel API reference, github API code samples

September 30, 2019

2019 Q3 summary

This quarter our team kept improving our existing products and rolling out new ones.

Before moving to certain updates, take a look at these useful articles which give broad view on our products' capabilities:


Let's go to specific pieces, there's a lot to take a look at.

Qosifire updates and free check-up

We keep improving Qosifire live streaming quality monitoring service.


Feel free to sign up and try Qosifire in action.

Larix Screencaster for iOS

We're glad to announce our new application - Larix Screencaster for iOS. It allows capturing the screen and audio of iOS device for further encoding and transmission, and has all streaming capabilities of Larix Broadcaster. Read this article to learn more about setting up iOS screencasting.
The source of iOS Larix Screencaster will be available in the nearest release of iOS Larix SDK. So if you're a subscribed SDK customer, you'll have it as soon as it's out.

We've also updated SLDP Player for Android to add HLS and MPEG-DASH playback via ExoPlayer for convenience of usage and media testing.

Also check latest information about our mobile solutions here.

Upgrades

We always recommend our customers to keep up with our software updates and upgrade Nimble Streamer accordingly.

With recent update of Live Transcoder, we require to make upgrading both Live Transcoder and Nimble Streamer at the same time. We use FFmpeg for decoding and filtering operations and we moved from FFmpeg 3 to FFmpeg 4, hence the correlated upgrade.
So if you have Live Transcoder and you plan upgrading your Nimble Streamer, please follow this upgrade instruction.

NVENC users has had some issues with upgrading NVidia drivers. So we made this detailed instruction which we recommend using during your upgrades.


SCTE-35, DVB and Icecast processing and pass-through

We've released a number of features for Nimble Streamer and Live Transcoder to cover cases when we get some data on top of media stream.


Other Nimble Streamer updates

There were a bunch of features and updates that will be important for many customers.


Last but not least, take a look at The State of Streaming Protocols report for 2019 Q3 showing (no surprise) the domination of HLS.

We'll keep updating you with our new features and products, stay tuned.

The State of Streaming Protocols - 2019 Q3

Softvelum team continues analyzing the state of streaming protocols. It's based on stats from WMSPanel reporting service which handles data from Wowza Streaming Engine and Nimble Streamer servers - there were 4000+ servers on average this quarter. WMSPanel collected data about more than 14.5 billion views. Total view time for our server products is 2 billion hours this quarter, or 21+ million view hours per day.

Let's take a look at the chart and numbers of this quarter.

The State of Streaming Protocols - Q3 2019

You can see HLS and RTMP shares are still bouncing around 77% and 8% while other protocols shares haven't been changed much.

You may compare that to the picture of Q2 streaming protocols landscape:

The State of Streaming Protocols - Q2 2019

We'll keep analyzing protocols to see the dynamics. Check our updates at Facebook and Twitter.

If you'd like to use these stats, please refer to this article by original name and URL.

Manual ingest of Icecast metadata into RTMP via API

Nimble Streamer can re-package incoming RTMP stream into outgoing Icecast stream, it's part of our extensive audio streaming feature set. Besides just processing an Icecast stream, Nimble Streamer can handle Icecast metadata in various scenarios, from pass-through to setup via UI and passing Icecast metadata via RTMP.

Now you can also ingest Icecast metadata into any incoming live stream any time via Nimble Streamer native API call, which makes it a real-time metadata injection. Currently only "streamtitle" and "streamurl" metadata parameters are supported. Once the metadata is ingested into the live stream, that data can be used for all RTMP- and Icecast-related scenarios as shown later in this article.

1. Enable RTMP Icecast metadata


To use this real-time injection you need to enable RTMP Icecast metadata feature first.

Follow "Generating Icecast metadata from RTMP" article to set up the processing of Icecast metadata in RTMP for further usage. Basically it's a matter of one checkbox in WMSPanel UI for given server instance or for some specific application.

Once this feature is enabled, any incoming stream will 

2. Enable Nimble API


Nimble Streamer native API allows working directly with server instance in order to get its status and control its behavior in some cases.

To start using it, you need to enable it on server side via configuration file. Please follow Pre-setup section in Nimble Streamer API reference to proceed. Once you have properly set up server, you can run the ingestion.

So whatever app or server you will enable this feature for, the incoming stream will get the metadata which you later will be able to transfer and process via RTMP.

3. Perform the injection


At this point we assume that you have a live stream to ingest metadata into, let it be "live" application and "radio" stream.
Then assuming your management interface is 127.0.0.1 and port is 9999 you can make this POST call:
curl -vvv http://127.0.0.1:9999/manage/icecast_metadata/live/radio -d "{\"streamtitle\":\"News\", \"streamurl\":\"URL2\"}"
This includes /manage/icecast_metadata method with for live/radio stream and set streamtitle and streamurl metadata parameters.

If you don't need to set streamurl you can run it this way:
curl -vvv http://127.0.0.1:9999/manage/icecast_metadata/live/radio -d "{\"streamtitle\":\"News\"}"
to apply streamtitle only.

You can find more about this and other native API methods on API reference page.

Further usage


As we've mentioned before, this metadata injection API call allows adding that data into the live stream, as if it's been ingested by some encoder before that stream entered into Nimble Streamer instance. This means that you may use ingested metadata in any output RTMP or output Icecast processing use case like those:
RTMP will still carry the data outbound as you need.


Contact us if you have any questions regarding any of our features.

Related documentation


Nimble Streamer APIAudio streaming feature setRTMP support

September 5, 2019

Larix Screencaster for iOS - live streaming from any app

Softvelum provides a number of solutions for mobile streaming and playback.

Today we introduce Larix Screencaster for iOS.

Larix Screencaster application allows capturing the content of user device and streaming it to the target media server or service. The list of supported protocols includes RTMP/RTMPS, RTSP/RTSPS and SRT, you can stream AVC/H.264 and HEVC/H.265.

Install Larix Screencaster here.

The setup of streaming is similar to Larix Broadcaster, you can read documentation reference for connectivity details.

As for the screen recording part, Apple requires additional setup:

Please study these sources to perform the setup.

Let us know if you have any questions regarding Larix Screencaster or other mobile solutions.

September 4, 2019

Generating Icecast metadata from RTMP

Nimble Streamer can re-package incoming RTMP stream into outgoing Icecast stream, it's part of our extensive audio streaming feature set.
RTMP protocol has the ability to carry Icecast metadata and encoders like Omnia Z/IPStream X/2StreamS Live Legacy Encoder and some others may produce this kind of streams.
So Nimble Streamer can pass that metadata from RTMP input to Icecast output.

If you need to process the input RTMP Icecast metadata for further use in Icecast, you need to enable this capability on server or per-application level. If you want to pass the RTMP Icecast metadata through Live Transcoder, you also need to enable it.

To enable the feature globally for entire server, go to Nimble Streamer / Live streams settings menu to open the setup page and choose the required server from the drop-down list. By default, the Global tab will be opened. Here you need to select Icecast protocol to have it in the output. This will show Generate Icecast metadata checkbox which you also need to select as shown below.


If you'd like to define this separately for specific application then choose Applications tab. Click on existing application's settings or click on Add application settings button to create a new one. Its settings will be similar to those described above so you need to select Icecast among protocols and click Generate Icecast metadata checkbox.


Once you save settings and re-start your input RTMP stream, the streams in the affected applications will have the Icecast metadata. You can use it as part of Icecast streaming or for passing through Transcoder scenarios.

Notice that RTMP output streams will have the Icecast metadata regardless or the described setting. This means that if you re-publish such RTMP stream or make it available for further pulled, it will have the Icecast metadata. However if you decide to transcode the stream and keep the Icecast metadata, you'll have to follow this setup process.

Also notice the Icecast metadata ingest via Nimble API which allows using RTMP is further processing and transfer.


Contact us if you have any questions regarding any of our features.


Related documentation


Live Transcoder for Nimble StreamerAudio streaming feature setRTMP support

Forwarding RTMP Icecast metadata through Live Transcoder

RTMP protocol has the ability to carry Icecast metadata. Nimble Streamer can forward that metadata into output stream when transmuxing from RTMP to Icecast. However some scenarios may require Live Transcoder to be involved in order to transform audio. In this case the metadata from RTMP stream need to be carried through the transcoder pipeline by setting parameters in a transcoding scenario. Let's see how this can be done.

Notice that Nimble Live Transcoder is able to passthrough the Icecast metadata. Please make appropriate setup for respective protocol use case. 
If you have incoming Icecast with Icecast metadata, please follow this instruction and skip this article.
If you have incoming RTMP with Icecast metadata, you need to follow the instruction below.

Enable RTMP Icecast metadata


First, the incoming stream must have the RTMP Icecast metadata delivered. So you need to enable RTMP Icecast metadata processing as described in this article. If you don't set up the designated application or entire server processing the RTMP Icecast metadata, it will not be available for transcoder scenarios.

Set up Transcoder


In this sample scenario we use transcoder for re-sampling audio from the existing RTMP stream. You may see a decoder, then a filter to perform sampling and then an encoder.



The forwarding needs to be specified on both decoder and encoder sides. In the audio decoder element you need to check the Forward RTMP metadata checkbox to set the transcoder to take metadata into the pipeline.


Now go to video encoder element and click on Expert setup.


Here you need to check the Forward RTMP metadata checkbox to make the transcoder grab the metadata from the pipeline and make it part of output stream.

Once you save the scenario and re-start the input stream, the output stream will have the metadata which then can be used for transmuxing into Icecast or re-publishing.


Contact us if you have any questions regarding any of our features.


Related documentation


Live Transcoder for Nimble StreamerAudio streaming feature setRTMP support

September 3, 2019

Processing DVB subtitles in Nimble Streamer and Transcoder

DVB (Digital Video Broadcasting) subtitles are used for media streaming from various sources via MPEG2TS and HLS. Nimble Streamer allows transferring DVB subtitles from incoming streams to its output.

Enable the DVB subtitles processing for MPEG2TS and HLS streams


If your incoming MPEG2TS or HLS stream has DVB subtitles and you need to have those subtitles to be passed through to output MPEG-TS and HLS, you need to add the following parameter into your Nimble config:
dvb_subtitles_processing_enabled = true
Once you add it and re-start Nimble Streamer, your output HLS and MPEG-TS will have DVB subtitles if your source streams have them.

Passing DVB subtitles through Live Transcoder


If you need to transcode your streams (e.g. make multiple resolutions or put graphics on top) and keep DVB subtitles from the source stream, you'll need to make some additional changes to your transcoding scenarios. Also notice that you must have dvb_subtitles_processing_enabled parameter to be enabled as described above.

Let's take a look at a simple scenario which allows keeping original stream as well as make lower resolutions.


Here you see /live/source stream being processed to get /live/output_480p output stream down-scaled to 480p (via Scale filter box) and keep the original rendition as /live/output_original stream.

There are 2 ways of passing the DVB - via video and via audio pipeline. We'll demonstrate both ways.

The /live/output_original stream has video being passed through - you can see long line with blue-to-orange gradient. This way, if you have full HD stream as input, you won't waste resources decoding and encoding the content to the same rendition. But the audio is split to decoder and encoder. Let's see their settings.

 

In the source stream decoder you see the enabled Forward DVB subtitles checkbox. It enables the transcoder to grab the subtitles for processing. In audio encoder setting, you click on Expert setup section to see the Forward DVB subtitles checkbox again. Check it to make the encoder take the subtitles which were previously grabbed into the pipeline by the decoder. After saving the transcoder scenario and re-starting the incoming stream, the output will have the DVB subtitles in the result stream.

The /live/output_480p stream has audio being passed through while video is transformed to lower rendition. So here we use video pipeline to pass DVB subtitles. It's set up the same way - both in decoder and encoder elements.


You need to check Forward DVB subtitles checkbox in video decoder and in video encoder settings under Expert setup section. As in case of audio, once you save the scenario and re-start input stream, the output will have the initial DVB subtitles.

Related documentation


Live TranscoderMPEG2TS streamingHLS streaming