HLS implementation differs from Wistia support suggestion

[maltebaumann]

Hi,
we're trying to integrate native playback of Wistia assets into our iOS app. We use parts of the WistiaKit (WistiaAsset, WistiaMedia and WistiaService) to parse the API responses and select the best asset. As Apple requires the use of HLS for our app, we asked the support to enable it for our account. Jay responded that appending .m3u8?segment_duration=3 to the URL + hash is the way to go and enabled HLS support for our account and all already uploaded media files.

The implementation within WistiaKit has special handling of m3u8 assets as well and tries to use those assets instead of basic mp4 files. Using this technique and passing the found asset.url, wrapped into an AVURLAsset which is wrapped into an AVPlayerItem, to an AVPlayer starts the playback just fine. The API returns assets with m3u8 containers and the corresponding URL has a .bin ending.

However forcing a url in the style suggested by the Wistia Support doesn't seem to work. Furthermore playback on 2G doesn't seem to reduce the video quality. If I run Apples mediastreamvalidator tool on a https://fast.wistia.net/embed/medias/<thehashedid>.m3u8?segment_duration=3 url the tool loops and doesn't return a correct report. A corresponding StackOverflow answer mentions appending m3u8 as well.

Could you explain the right way for integrating Wistias HLS capabilities into an iOS app and why your implementation differs from the Wistia support explanation? Apple seems to be quite strict about allowing media streaming on cellular networks and we don't want to risk a rejection because of it.

Thanks
Malte Baumann

[maltebaumann]

Quick correction: Forcing the baseURL/<hashedID<.m3u8?segment_duration=3 url does actually work, but only for certain videos in our account. But the playback still doesn't adapt to the available network speeds (tested using iOS Network link conditioner).

[spinosa]

Hi @maltebaumann ,

Once HLS is enabled for an account and medias are processed, the WistiaAssets for that WistiaMedia will include the HLS asset (which provides the URL to the m3u8 playlist). Appending the .m3u8 extension will also work at this point. There are a few ways to skin this cat.

WistiaKit inspects the assets as those are definitive. As you've seen, the url extension technique failed for some medias in your account. They may have still been processing new HLS assets.

---

The README for this repo outlines our recommend approach for integrating video in your iOS app.

Have you tried use the WistiaPlayerViewController or the WistiaPlayer? Using either of these should be the best way to integrate. If you prefer not to use them, I'd like to understand why (as we're trying to make WistiaKit as useful as possible; it's for you!).

HTH!
dan

/cc @jayholman

[maltebaumann]

Hi Dan and thanks for the quick reply,
your explanation on the asset handling is great and we'll continue to use the WistiaKit implementation.

We haven't used the other parts of WistiaKit yet, as they were simply not available when we created our video player. I just took a new look at the WistiaPlayer and discovered the support for events. We'll migrate from our AVPlayer to the WistiaPlayer to make sure we use the correct approach on playing Wistia media, but I don't think this will fix the playback issues, as they seem to originate from the HLS stream provided by Wistia. I already contacted the Wistia support about these issues, but do you have any idea why a slow connection doesn't reduce the quality?

Thanks
Malte

[spinosa]

If for some reason the HLS asset created (or the one chosen by WistiaKit) doesn't have all of the necessary streams, that would explain this. The support team will help debug and get to the bottom of the HLS stuff in your case.

But generally speaking, the algorithm that dynamically chooses the stream is implemented by apple in the AV frameworks, and it's a black box. We've implemented HLS on our backend to Apple's spec and submitted an app (unreleased to app store) to get their review team to vet our implementation; it was approved. That being said, there could be always be bugs especially in these early days.

[maltebaumann]

Thanks for the explanation, we'll see where the problem comes from. We just noticed that the pod won't work for iOS 8.0 so sadly we can't use WistiaKit as easy as we thought. We'll try to extract the WistiaPlayer or at least the features we use. Thanks for your help!

[spinosa]

Hey @maltebaumann - a quick heads up: Current versions of WistiaKit (0.3.0 and older) have an incomplete / broken HLS implementation.

The code to grab the manifest of manifests (which @jayholman correctly told you was available from https://fast.wistia.net/embed/medias/<hashed_id>.m3u8) was not included. And this is currently the only way to grab a manifest of manifests.

Broken versions of WistiaKit (v 0.3.0 and older) are using just a single HLS stream.

I was mistaken and misspoke and apologize for generating some confusion here!

Planning to push a fixed version 0.4.0 this week.

[maltebaumann]

Hey Dan, thanks for the heads up and the quick fix. Could you explain the following comment in more detail?

- Note: Not all WistiaMedia has HLS derivatives available yet. (Commit f0fb1e3)

Are there any limitations? And how can we avoid playing back HLS media, if they don't have the corresponding derivatives available?

[spinosa]

Comment is there because not all accounts have HLS enabled, yet. But yours already does. So you're all set!