Does ABS's m3u8 audio stream meet Amazon's criteria?

[amwmedia]

I've started work to explore the feasibility of making an Alexa skill that interfaces with ABS. I've run into a roadblock that I'm trying to figure out. The skill plays the stream fine on my phone (through the Alexa app) but when I try to play it on a device I get nothing. Alexa support says to make sure the stream meets their url requirements. I believe it does, but was hoping someone on here might be able to point out something I missed?

Their criteria are:

• You must host the audio file at an Internet-accessible HTTPS endpoint on port 443.
• The web server must present a valid and trusted SSL certificate. Self-signed certificates aren't allowed. Content hosting services, such as Amazon S3, provide valid and trusted SSL certificates.
• If the stream is a playlist container that references additional streams, you must host each stream within the playlist at an Internet-accessible HTTPS endpoint on port 443 with a valid and trusted SSL certificate.
• Your audio file must be in one of the following formats: AAC/MP4, MP3, PLS, M3U/M3U8, HLS.
• Your audio stream must support bit rates of 16 – 384 KB per second.

My test instance is hosted on a NAS and exposed to the public via Cloudflare tunnels so the SSL certificate shouldn't be an issue. The only criteria I am not sure about are the audio format used within the transport stream files.

[advplyr]

It should meet that criteria but the m3u8 stream is only returned when opening a session if it is requested. Depending on how you setup the skill would depend on what Abs sends back when opening the session.

[amwmedia]

Yeah, I have logic in the skill to make the POST request to start a new session and I pass the m3u8 contentUrl back to the echo device. It just doesn't want to play. I'm trying to get amazon to look at the stream url (I'm generating one and sending it with the token and all), but so far they have been less than helpful.

[advplyr]

I would suggest passing in forceDirectPlay when opening the session so you get back a url to the audio file. Unless you have audio formats in your library that aren't AAC/MP4 and MP3 you shouldn't need to transcode.

[amwmedia]

I've been primarily focused on audioTracks[0].contentUrl but I did try sending libraryItem.media.tracks[0].contentUrl as well with no luck. The latter seems to be a link to the (in my case anyway) raw m4b file. Is this what you're referring to? I have tried playing around with passing in things like forceDirectPlay or forceTranscode but I can't tell what changes about the payload that gets returned.

[advplyr]

The audioTracks[0].contentUrl is what changes when you forceDirectPlay or forceTranscode. Transcoding is the HLS m3u8 file.
When forcing direct play you may get many audioTracks depending on if you have a multi-file audiobook or not. It is up to the client to handle switching audio tracks.

[amwmedia]

Thanks for the clarification. We'll see if Amazon ever actually takes a look at this thing 🙄

[P-Hoep]

Oh man, yeah, running into this myself. It's pretty wild how poorly the audio player works, like, sometimes it will play through my dev test area, and not on devices, or on my phone and not on an actual echo device, etc. Kind of maddening.

[amwmedia]

Would there be a way to map listening position back to a specific user? Sounds like there's no user-connected session to track progress?

[advplyr]

You would need to use the local session API endpoint and manage the session object yourself. It's probably not the route you want to go if you want to keep user progress synced.

[amwmedia]

It doesn't sound easy, but if the stream works in the audio player... It might be technically possible

[sevenlayercookie]

_One issue that I had making my skill (and the reason I went with RSS shares) is that Alexa devices do not handle cookies or auth headers. The echo device makes the request of the ABS API for the media file, but you cannot force the Echo device to include any headers or cookies with that request (which ABS requires). So you must be able to pass the echo device a plain, public media url, with no cookies or headers.

There are two APIs for publicly accessible calls in ABS: media share, and RSS. Neither of these require auth header (so they're publicly accessible).

However, last I checked, media share item GET call does require including share_session_id cookie with the request, so this is fundamentally incompatible with Alexa. (However I'm not certain that share_session_id should be fundamentally required for the call, and I'm not certain what significant purpose the cookie serves anyways).

RSS shares do not require cookies or headers. I experimented with a man in the middle injection of headers and/or cookie using proxy, but RSS ended up being easier for me.

I also initially experimented with HLS and had issues (likely due to the same header and cookie issue however) and switched to direct play and have had perfect playback on all my varied Alexa devices with my skill, once I switched to RSS shares. It's possible HLS works if able to be done without headers or cookies, but I hadn't experimented further.

@advplyr if share_session_id cookie were optional when using the GET: /api/share/:slug/track/:index call, it would make Alexa playback a lot easier using media item share API. Perhaps if the API allowed the session_id to be passed as a URL parameter instead of a cookie. Or even better would be a new API for a dynamically generated temporary public URL that requires no authentication header or cookie.

In the meantime, I believe that RSS feed is the only option for Alexa (unless someone does MITM header or cookie injection, but I didn't love the security implications of that approach)_

EDIT: turns out, all of the RSS stuff is unnecessary. Alexa and ABS support streaming direct play so long as the API key is included in the URL parameters. I have updated my skill to use this, which greatly simplifies things….

[sevenlayercookie]

It doesn't sound easy, but if the stream works in the audio player... It might be technically possible

It's possible; POC in my Alexa skill if you're interested (https://github.com/sevenlayercookie/abs-alexa/).

Since I used RSS feed approach, which has its own non-user-affiliated listening session, the workaround was creating a simultaneous user listening session in addition to the RSS listening session. Then the skill just manually syncs the two using the POST http://abs.example.com/api/session/<ID>/sync call. The API key you provide links the user session to the user that the API key is associated with, and updates that users current listening position and session duration stats etc.

[sevenlayercookie]

I have experimented more with Alexa skills and .m3u8 (unfortunately, very large audiobooks tend to crash the device using my ABS-Alexa skills, so I thought breaking it up using HLS might work better). However, I have not been able to get HLS to work on the echo devices, regardless of source. I’ve tried probably 20 different public HLS audio streams of various encodings on the internet (in addition to ABS HLS streams), and none of them play on the Alexa device. They do play on Alexa app and in the web browser.

so to answer your question, ABS is likely generating perfectly compatible streams; the problem is Alexa doesn’t actually support HLS, despite their website claiming otherwise.

[amwmedia]

Yeah, I have found that the main issue is the m3u8 file size. Most of the size comes from the token needing to be included with each transport stream. I've found that rewriting the m3u8 so that it doesn't need the token in the file generally brings the file size down to a level that the devices can handle.