MKV Support on Xbox One

This blog post captures information regarding MKV support on Xbox One that should be published soon on support.xbox.com.  Please refer to the Xbox support site for the latest updates.

Edit: The official post is now located at:
 http://support.xbox.com/en-US/xbox-one/xbox-video/mkv-support

Note that I will try to answer those questions I can here:

http://redd.it/2ghejo

 

Posted in MKV | Comments Off

Xbox announces upcoming MKV support

Xbox announced MKV support at gamescom this week.  This was picked up and blogged by MajorNelson and is seeing rave reviews on Reddit.

I’m glad to see the excitement for MKV, as it’s what I’ve been working on these days!  I’m interested in feature requests and to make sure we have support for the most common scenarios.

Posted in MKV | Comments Off

HLS v3 – The new old thing

Azure Media Services now supports a down-level version of HLS, HLS v3.  
Use: format=m3u8-aapl-v3

A little history:

As of version 4, September 2011, Apple/HLS added support for multiple-languages: Alternative Audio Renditions these were called. Multi-language support was the motivation behind choosing HLS v4 two years ago for our service. At that time, Android was seeing a lot of active development and with its largely international customer base, it was assumed that Android would adopt HLS v4 for these multi-lingual markets. Not so, as history would prove. Here we are two and a half years later and HLS v4 support is only available on the very latest Android drops. So, instead, we are reaching back and dusting off the HLS v3 draft spec from November 2010, and building backward compatibility. We are also motivated by the connected TV space, which has a lower adoption rate for device updates.

To use HLS v3, simply use:

*.ism/manifest(format=m3u8-aapl-v3)

This will mux the default audio language into the video.

But what about multi-language scenarios, since HLS v3 doesn’t support those?

HLS v4 allows video and audio to be delivered in a decoupled fashion (like Smooth, DASH and HDS), whereas HLS v3 must have the audio muxed into the video data, and both are delivered as a single stream. Since HLS v3 does not have native multi-language support, but our server does, we were able to allow content-owners to set the audio track that they want muxed in the URL using the ‘audioTrack’ attribute. If you don’t set anything, we just mux in the default audio.

You can force the language that you want muxed into the video by using the audioTrack attribute.

It looks like this:

*.ism/manifest(format=m3u8-aapl-v3,audioTrack=audio_eng)

*.ism/manifest(format=m3u8-aapl-v3,audioTrack=audio_spa)

Or

*.ism/manifest(format=m3u8-aapl-v3,audioTrack=audio)

*.ism/manifest(format=m3u8-aapl-v3,audioTrack=audio_1)

Depending on if your audio languages were detected/defined in the source media.

You can get the audioTrack name from the Smooth manifest Language, or HLS v4 manifest.

You can set your own track names by using the title=”audio_spa” attribute in the .ism file used for your multi-bitrate MP4 assets.  Similarly, you can use systemLanguage=”spa” to set the Language attribute in the manifests. Add the attributes to the line in the .ism which has the src=”yourAudio.mp4”. You can also do some renaming in the .ism/.ismc of Smooth assets if you’re feeling brave. Sorry there’s no support for this type of manipulation in the platform, perhaps some of you would like to contribute to the Azure Media Services .NET SDK Extensions project on GitHub?  For doing these types of touch-ups, there is a manifest parser/generator from Mariano, one of our friends at SouthWorks.

So now HLS works on all Android devices, right?

Nope, not a chance.

Android is highly fractured and has varying levels of implementation for streaming media. The media stacks are different from device to device, and even within a single device the media stack can be duplicated/different. If you’ve been trying to make this work for a while, you’ve seen that the same Android version may work differently on different handsets; that’s because each manufacturer has the option of tweaking the OS. All to say, it’s not an easy problem to solve, and as a stream provider, the best I can do is make sure my streams are conformant – device support/upgrades is up to Android.

We also did some deeper testing of 4.1.2 debug builds which demonstrated that the quality of the underlying native implementation was low for that release. Some manufacturers had forked the code and done some fixes, but generally, I would not expect devices 4.1.2 and below to work. This is consistent with the findings of other streaming server and player framework providers.

For the Android devices with version 4.2.2, it would seem that there are varying degrees of implementation. Some adaptive bitrate logic implementation is particularly poor (dropped frames are not triggering bitrate switching, latching to a particular bitrate or bitrate switching causes a re-start). Other devices with 4.2.2 do reasonable well, and the latest Android drops are much better.

The MSDN doc will have a table on the device testing we were able to accomplish as part of building this feature, it is in no way extensive, but does cover a good number of popular devices that can be purchased today. Just to be clear, the goal of HLS v3 is to provide spec-compliant HLS streams which pass Apple validator and other Transport Stream compliance suites; not to ‘work on all Android devices’, so your millage may vary, take it up with the the other guys.

On the connected TV side, we’ve gotten good feedback from our partners thus far.  We also got a thumbs up from the popular JW player folks (note, set type:”HLS” in the embed code for JW Player).

Posted in Uncategorized | Tagged , , , | Comments Off