...
The technical change will in practise bee to replace your current parameter for "type" according to this mapping and also change bitrate to 64. The following table shows a mapping from the current values to new ones. It is important to use the correct type for each scenario, both for performance and statistics so if you are unsure on which parameter to use kontakt ketil@bokbasen.no.
| Current value | Is file for download (Can customer access the actual file, or is it closed in an app) | New value |
|---|---|---|
| audio/mpeg | Yes | audio/vnd.bokbasen.complete-public |
| audio/mpeg | Only for use in closed ecosystem where user cannot access file (e.g in app). If you are using complete file for streaming (progressive download) see audio/mpeg3 at the bottom. | audio/vnd.bokbasen.complete-private |
| application/zip | Yes | audio/vnd.bokbasen.zipped-public |
| application/zip | Only for use in closed ecosystem where user cannot access file (e.g in app). | audio/vnd.bokbasen.zipped-private |
| vnd.apple.mpegURL | HLS is only for use in closed ecosystems (e.g in app). | audio/vnd.bokbasen.hls-private |
| audio/mpeg3 | Complete progressive download is only for use in closed ecosystems (e.g in app). If you are simulating streaming in your app using progressive downloads, this option gives you better performance than the complete download as caching is adjusted to fit a streaming scenario. | audio/vnd.bokbasen.progressive-private |
The new values might change a little bit but will be confirmed when system is available for testing. Values are now confirmed and will be as documented above (small adjustment from original documentation).
Changes to HLS
HLS will also be migrated to 64 kps, and will no longer be backed by Wowza streaming engine. Instead HLS will be available through a global Content Delivery Network (CloudFront). Testing so far shows that this is giving us considerable lower latency than the current solution. HLS links for testing can be made available now, just contact us to receive links.