Erik here! As mentioned in the opening blog post, I will mostly post about innovations. Today I kick off with some work in progress on a feature that we call stream splicing.
What is stream splicing?
Stream splicing works by manipulating media data just before it leaves the media server. For example, this allows you to switch media sources or insert generated content while maintaining bitstream and container compliance, thus allowing advanced features without requiring player awareness or being limited to specific protocols.
What can I do with stream splicing?
The real power of this technology is that it allows you to adapt basically any stream on a per-viewer basis. While this gives us many feasible use cases, I will handle three of these in today's post.
- Adaptive bitrate switching
I will start out with a re-imagining of a widely used technology which allows for quality selection in your streams by your viewers. The established solution works by generating a Manifest, which is generally a playlist of various qualities of a single stream. This playlist is requested by a video player, and allows the player to select the best quality based on factors like display resolution and available bandwidth. Using a separate playlist for each quality, the player will request the actual video data. If the actual data segments are keyframe-aligned between the various qualities, the player is able to switch to a lower or higher quality on segment boundaries.
While being a proven solution which allows you to reach a wider audience, an individual user may still opt to select a higher quality than his available bandwidth allows him to view. The technology is also restricted to segmented protocols, reducing the usability for applications with requirements on low latency. On top of this, players will probably request a segment of a higher quality to see whether it is received fast enough in order to switch to it, effectively wasting bandwidth as a single segment is requested twice but only played once.
Using stream splicing to achieve the same effect on the server side allows you a more fine-grained control over what your viewer gets to watch. Looking at the actual state of the server machine, which blocks on the data connection if the viewer is not reading data fast enough, a connection can be forced to a lower quality regardless of what the player requests. By not relying on client-awareness of quality switching, a more low-level sync can be achieved while providing compatibility with both progressive download and low-latency streaming protocols. Where bandwidth is limited or costly viewers can also be forced to a lower quality stream as demand increases. Doing this allows for more clients to connect while you’re working on scaling up.
- Stream personalisation
In applications everywhere, individualisation is gaining terrain over a one-fits-all mindset. On large scale platforms it is becoming a requirement and your customers expect to see this option. However, using existing technologies for streaming often makes it really cumbersome to give your viewers a default language in either audio or subtitles.
Our flexible triggers API already allows you to take specific actions based on events within the media server. Combining this with server side manipulation of your stream data, you can automatically select and influence the default language a single user will receive based on, for example, their user profile on your platform. The addition of extra triggers in our API will not only make it easier to implement these kind of options on your platform, it will allow for full integration of the stream splicing feature into your existing system.
- Advertisement injection
Probably one of the most important elements of any streaming platform is monetization. While there are multiple solutions readily available to serve advertisements to your viewers, innovations like ad blockers on the client side prevent you from reaching every viewer, cutting into your profits. While fully encoding the desired advertisement into your stream ensures your viewers will see the advertisement, it does not allow the same flexibility given by client-side advertisements. In this scenario every viewer gets the same final stream.
The latest Video Ad Serving Template (VAST) specification adds support for server side advertisement stitching and tracking, allowing the dynamic insertion of advertisements into a video stream. Combining this with splicing allows for individualized advertisements to be inserted without needing a custom player and effectively combats ad-blockers.
While not covering the entire range of possibilities, the examples above should give some insight into what you will be able to do with this technology. If you have a specific use case that's not covered here and you want to know whether we can help you achieve it, feel free to contact us to discuss in more detail.
When will it be ready?
As already mentioned this is currently a work in progress. We are about to start with testing it in the field, and are open to applications of interested parties. Assuming the field tests are successful, a release containing stream splicing will follow shortly after.
Feel free to contact us with any questions regarding the progress or field tests of this new feature at firstname.lastname@example.org.
Our next blog post will be by Carina, explaining more about our recently released meta-player.
Why use a media server, anyway?
As mentioned before by Jaron, I will kick off the first post. I will be giving a short and simple overview on why you would want a media server instead of other solutions like a regular web server. I’ll feature what I think are the four biggest reasons to use a media server in favor of the alternatives.
1. Superior handling of media files means guaranteed delivery
As a media server specializes in media, it should come as no surprise that it will have superior handling of media files when compared to other solutions. A true media server can take your source file and make sure it gets to your viewer regardless of the chosen delivery method. The most important feature of any solution is to make sure your media works in any situation on any device.
Alternatives often cannot handle this transmuxing and must stick to the type of media prepared in advance, forcing your users to use a certain player, plugin or delivery method. Even worse is that when that method isn't supported by their device/system, they will not be able to watch at all! Especially hosting a live stream can become a chore if you don't have a media server, as most consumer-grade live streaming is based on RTMP, which is disappearing in favor of HTML5-capable methods.
A media server alleviates this problem by transmuxing the stream, making sure it can be viewed by anyone at any time, whether it is a live or on demand stream.
2. Deeper analysis is possible through media servers
Because media servers can handle media so much better they also allow deeper insight in how your media is consumed. You'll be able to see just what part of your media files or live streams is most popular, how many viewers you've had and through what protocol or device they've connected.
If you are not using a media server you will most likely be stuck with just a viewer count and are not sure if they watched the entire thing or just a part of it. Furthermore, the viewer count may well be off by a significant amount when using segmented delivery methods, as it becomes hard to track single views when these delivery methods are used.
Using the deeper knowledge you gain about your users allows you to decide where your focus for media should be and how to keep your viewers interested, or what area you could try to grow next.
3. Keep on growing
Probably the most forgotten feature of media servers is that you will be able to keep growing, taking advantage of the newest developments and innovations in streaming media at practically no extra cost. Media servers specialize in developing and implementing features that improve your media delivery, making sure you will always be caught up with the latest innovations.
Implementing these new features, protocols or outputs yourself is a full-time job. Streaming media developments happen so quickly that settling for a system that isn’t keeping up with developments will most likely render your entire media chain outdated or unusable within just a few years.
As an example: using flash players was considered a good, stable and proven solution just a few years ago. These days, the Flash plugin is blocked automatically by the majority of consumer browsers.
4. User-oriented, content-aware connection handling
Using a media server allows you to customize every user's experience individually. This means that you are able to change the experience of a single viewer without affecting the experience of others.
Web servers usually send the entire file at the speed they have available, meaning that even if your viewers do not watch the entire video they will still have received the largest part of it. This means bandwidth is wasted, and bandwidth costs are often the highest costs you have when running a media service.
Media servers are able to send media in a real-time sense, which means viewers will have downloaded just a bit more than they have watched. This can easily save you hundreds of GBs of bandwidth. This also means that when your platform grows, the savings of using a media server grow proportionally.
Besides saving bandwidth this user oriented connection handling also allows for several other tricks, which Erik will highlight in the next blog post.
Introducing our new bi-monthly blog posts
Hello streaming enthusiasts around the world,
Happy 2017! A new year is a time for new beginnings, and here at DDVTech we have decided to start the new year off with a bi-monthly blog.
From now on, twice per month you will be able to read posts from the MistServer team right here, covering subjects that we didn't cover before.
We plan to switch authors every post, with each author covering a different type of subject matter. The coming posts you can expect these authors:
- Balder: Streaming how-to's and ideas
- Erik: Innovation and various other subjects
- Carina: Streaming on the web
- Jaron (myself): Technical deep-dives and behind the scenes details on our team's progress
Later this month you can expect a post from Balder, and from then on we'll randomly pick an author for each post.
We hope you're looking forward to reading our rambles!
Stable release 2.9.0 now available!
Added VideoJS player to our smart meta-player. Adding VideoJS allows HLS playback to work in most non-Apple browsers in addition to Apple browsers.
The MistController can now restart without closing connections and restart faster
Pro Feature: Added RECORDING_END trigger. This trigger alerts you when a file finishes writing to disk. Allowing you to do your own post-processing for example.
Pro Feature: MP4 live improvements. MP4 live is now compatible with FireFox, no longer randomly disconnects mid-stream and the end-to-end latency has been reduced to 5-8 seconds for most streams.
Various other bugfixes and small improvements.
Stable release 2.8.2 out now
Pro only feature: RTMP output track selection has been added. MistServer can now select the tracks to output by ending the rtmp urls with "?track=track_number" or "?video=track_number" "?audio=track_number".
Pro only feature: HTTPS support has been added, you can activate it through the Protocol panel.
Feature: DTSC pull now allows selection of all buffer parameters.
Improvement: Changed flash protocols priority to RTMP > FLV > HDS. While flash protocols are becoming less common, we have changed the priority to check for the protocols we see used the most.
Improvement: HLS protocol. HLS has become faster and more reliable.
Improvement: Updated Windows (Cygwin-based) builds with IPv6 support
Improvement: Live streaming Live streaming has received various changes for incoming and outgoing live streams, streaming should be more reliable and faster.