Disregard "public": false assets when selecting for playback

[mrdavidjcole]

Wistia videos have a bunch of assets. One of those assets is a low FPS mp4 file, like https://embed-ssl.wistia.com/deliveries/3ba323d378f11abaa8a75244bbad0a92fbae3824.bin, for the media with hashed id mo7xzk0d6m.

That asset should never get played. It exists only for the engagement graph overlay interface on Wistia media stats pages.

That asset is not returned in the response from the API's medias#show response, and yet somehow WistiaKit knows about it, and chooses it as the asset to play.

This only happens when check for the presence of HLS assets fails (see #44), so fixing that should make this much less likely to occur. But it still should never occur.

[mrdavidjcole]

Similarly to #44 (comment), the medias#show response (which doesn't include the low FPS mp4 asset) isn't relevant here. WistiaKit gets its list of assets from the public media data endpoint. In that media's case, http://fast.wistia.com/embed/medias/mo7xzk0d6m.json. The low FPS mp4 asset is in there, and it's listed as "public": false. WistiaKit should only consider assets with "public": true to be playable assets.

[spinosa]

@mrdavidjcole Want to change this issue to "disregard public: false assets when selecting for playback"? I'll handle that fix separately from the HLS stuff we're working on in the PR

[spinosa]

Noted for WistiaKit2

[ArrHarper]

@spinosa 👋 this issue is rearing its ugly head for a customer looking to use wistiaKit on a pretty massive scale. Is there any hope that we can make a change to this behavior in the near future, or suggestions of a workaround? Without going into specific details in this public thread, I have access to a dev build on a customer's app in case seeing the problem in action would help, which I can share internally if necessary.

I'm wondering if there's a means to employ the qualityMin option here to prevent the dip to that low FPS asset?