Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[sarkonovich]

What are the possible parameters for:

Conversion
Resolution

when sending an  /MCWS/v1/File/GetFile request?


I'm hoping that the new HTTPS access for the media server will allow HouseBand to stream to Alexa devices....maybe?

Thanks,
Steve

[Hendrik]

Resolution is largely unused, its only a hint and not used much.

Conversion is how you select a conversion preset.
There is two ways to do that, either using a numbered index of the preset, or using a descriptive name.

For Audio:

This works (its what JRemote and Panel use, nevermind the "Android" in there, it just controls the preset selection, just keep it)
Conversion=Android&Quality=Medium (with Low = 128k mp3, Medium = 256k, High = 320k)

And this works:
Conversion=2

with
0 - WAV 16-bit
1 - PCM 16-bit no header (raw pcm data)
2 - MP3 Low
3 - MP3 Medium
4 - MP3 High
25 - WAV 24-bit
27 - PCM 24-bit no header (raw pcm data)

If Alexa might require a different format we don't offer right now, we could think about adding that.

[sarkonovich]

Well, shoot. It seems like it should work, but it doesn't. To stream audio the only requirement is that it is accessed via an HTTPS call without authentication. Self-signed certificates are fine.


If I take the audio file and put it up on AWS S3 and call it from Alexa, it works:

https://s3-us-west-2.amazonaws.com/alexa-bucket/my_audio_file.mp3

If I feed Alexa the MCWS URI, it seems like it's going to play, but I only get a some silence before it quits:

https://my_ip.net:52200/MCWS/v1/File/GetFile?File=444&Conversion=Android&Quality=Low&FileType=Key

Am I just misunderstanding what's going on in these two calls? Are they really entirely different kettles of fish?

[Hendrik]

Should be pretty much the same, unless Alexa doesn't like custom ports?
You could try running MC SSL on port 443 temporarily and see if that helps. And of course a network sniffer like Wireshark could help determine if it tries to read at all.

PS:
I just did a quick search and that suggests that self-signed is not actually OK. Are you certain about that?
Unfortunately setting up trusted certificates is quite a chore - you need a FQDN first that you can actually get a cert for, then obtain it and let MC know.

[sarkonovich]

Yes, I'm sure (er...not so much, it turns out)

For audio delivered in an ssml tag, the hosting site has to have a kosher certificate. But for longform streaming audio, it just needs to be HTTPS.  I'll look into port issues.

[sarkonovich]

One more question. What are the values for the HLS parameter?

Alexa supports a wide variety of codecs and HLS streaming.

https://developer.amazon.com/docs/alexa-voice-service/recommended-media-support.html

[Hendrik]

HLS is only supported for video in MC, and mostly only because some devices couldn't stream anything else.
Audio should just be fine streaming MP3 directly (ie. Progressive MP3 Streaming).

[sarkonovich]

Aw, dammit.  You're right. It needs to be on an endpoint with trusted SSL certificate.

Shoot. I swear it didn't used to be that way. On the upside, it saved me a lot of time!

[sarkonovich]

Just for fun, since I got excited about this, I routed the HouseBand commands through an ngrok tunnel (which provides a valid wild card certificate), and can stream from the media server to my Amazon Echo.

Getting this working was literally a matter of running a single command from the terminal: `ngrok.exe http 52199` (so, it's orders of magnitude easier than getting a valid certificate for your computer.) Still, it seems like a bit of a hurdle to actually make this a workable solution for people.

Hey! Maybe you guys can create your own domain, get a wildcard cert, and route traffic through there? No? 

Steve

[Hendrik]

Using an external server to stream through kind of defeats the entire purpose, doesn't it?

I would love to be able to offer instant trusted certificates, unfortunately that is not easy. I know how some other software with local hosting does it, but they went all overboard and partnered with a Certificate Authority to issue certificates directly through their servers. Its a nice concept but so extremely complex.

[sarkonovich]

Using an external server to stream through kind of defeats the entire purpose, doesn't it?

It does for me, but then the whole world being taken over by people streaming low res music through tiny plastic speakers drives me to drink. (Okay, I'd drink anyway, I guess.)

But a lot of people seem to care enough about music to want to be able to play their own music, but are also happy to hear it  through an Echo.

[cncb]

And this works:
Conversion=2

with
0 - WAV 16-bit
1 - PCM 16-bit no header (raw pcm data)
2 - MP3 Low
3 - MP3 Medium
4 - MP3 High
25 - WAV 24-bit
27 - PCM 24-bit no header (raw pcm data)

I may be doing something wrong, but this doesn't seem to currently be working.

That is, Conversion=2&Quality=0 and Conversion=2&Quality=4 both seem to yield an identically-sized MP3 file.

[Hendrik]

The number you pass to Conversion is the one referenced above, not an additional Quality parameter. Quality is only used for some "named" formats like "Android".

[cncb]

I see.  Thanks for the explanation.

[cncb]

I thought I read before that for video conversion the only option is MPEG-TS (low,medium,high).  It seems like this might not be the case, since Gizmo can cast converted video that plays back on Chromecast which in my experience cannot play ts video.  Are there additional video conversion options available?  Thanks.

[Hendrik]

We have a long list of video conversion profiles. For Chromecast, we use HLS to wrap TS streams.

Profiles relevant for streaming (ie. the same ones you get through Android Low/Medium/High/VeryHigh, plus AutoFPS variants)

Quality=Low
35 - H264-TS 240p, AAC, 30 FPS, 0.5mbit
40 - H264-TS 240p, AAC, Auto FPS, 0.5mbit

Quality=Medium
36 - H264-TS 480p, AAC, 30 FPS, 1.5mbit
41 - H264-TS 480p, AAC, Auto FPS, 1.5mbit

Quality=High
37 - H264-TS 720p, AAC, 30 FPS, 5mbit
42 - H264-TS 720p, AAC, Auto FPS, 5mbit

Quality=Very High
38 - H264-TS 1080p, AAC, 30 FPS, 10mbit
43 - H264-TS 1080p, AAC, Auto FPS, 10mbit

If you want to use HLS for Chromecast, the only way to currently access that is through a command like this:
Conversion=Android&Quality=Medium&HLS=1

Otherwise you can also access things through Conversion=43, but not in HLS.

There is also MKV streaming profiles, 60-63 for Low to Very High, but that mode is not tested well since I'm not sure which devices use it. It can be selected in DLNA though.

I'm working on some better interfaces to the streaming profiles, so you can get a list of defined profiles for a certain use-case, better opt into certain features like HLS, and also offer multi-channel audio. But how exactly thats going to work we'll see in the future.

[cncb]

Thanks again for all the info and your willingness to help!

[cncb]

Is the "Context" argument necessary for HLS?  If so, what are the possible values?

[Hendrik]

It should use that internally to identify the individual segments. You should not have to really care about it, just let the HLS client manage it.