Blue Iris UI3

[erkme73]

UI3 can't load separate audio streams of any kind. Only whatever comes with H.264 video.

How did you add the group video stream to blue iris as a new camera? It should definitely be capable of doing audio, but you might have to use a different URL to stream from than you are currently using. 5.3.1 - July 16, 2020 Your Blue Iris web server now is also an RTSP server.

I was using the neighbor's server as RTSP and it worked - but frequently dropped out and no audio. I recently moved to using Raw h264 with the IP of the server, and /h264/[groupname] under the stream. Much more reliable, but still no audio...



For grins, I added /h265/[camera_shortname] to the audio field, but it's just whitenoise/static.

 

[bp2008]

You could try the .ts or HLS streams that Blue Iris provides (see help file for URLs), to see if they are any better.

I believe for either of those it would be appropriate to select the Model: "HTTP Live Streaming (HLS, M3U8), MP2TS."

Ironically it seems Blue Iris probably does not support consuming the proprietary protocol it uses to send H.264 to mobile apps and UI3, which is a shame because we know that does audio just fine.

 

[bp2008]

Also, I think Blue Iris does support streaming "WAV" audio via some other URL. UI2 used to be able to use that way back in the day. That is a path you might try entering into the Audio path field. Otherwise you want to leave the Audio path empty.

Here we are.

/h264/{cam-short-name}/temp.ts. Pull an MPEG-2 transport stream (MIME type video/MP2T).

/h264/{cam-short-name}/temp.m or .m3u8. Pull a virtual M3U8 file (MIME type application/
vnd.apple.mpegurl). This will play in QuickTime, iPad and the iPhone using the Apple HLS
(HTTP Live Streaming) format.

/audio/{cam-short-name}/temp.wav. Pull a raw audio stream (MIME type audio/x-wav).

 

[erkme73]

I just tried both and no beans. I suppose I could just create another camera going to just one of the remote cameras and point to that with the audio channel - but I'm up against the 64-camera hard limit (which is why I'm going with the group/index-to-camera option in the first place). Thanks for the suggestions. I may just reach out to Ken to see if he has any other ideas.

 

[Buxton]

Hello,

I have tried many of the functions/parameters for the MQTT toast feature and so far, all work as described. Thank you so much for writing the extension as this new feature is really helpful.

One revision did occur to me, but it is a minor suggestion. For the "ui3/{instance_id}/toast/{toast_id}" where one puts a hardcoded unique toast_id in the message (for multiple toast popups), would it be possible to instead just write "ui3/{instance_id}/toast/multi" or something similar, and then internally UI3 would use an algorithm to insert a unique ID in place of multi within the MQTT message. I don't believe one needs to know the toast ID on either end of the communication so any value generated by UI3 should work.

Thx again for this addition.

 

[bp2008]

ui3/{instance_id}/toast/multi

That is a good idea. It will be in the next ui3 release.

 

[wtf911]

@bp2008 sharing this here because it shows how nice web push notifications can be. Suppose if this was natively integrated into Blue Iris/UI3 then there would be no need for any app installed, you'd have cross-platform compatibility, fast notification alerts, and battery efficient. Great work on UI3 by the way!

 

[bp2008]

@wtf911 I agree native web push support would be nice. I've thought a lot about it before and brought it up to the BI dev before, but if I recall he didn't respond to my email (this is pretty typical for such requests from me).

I see 3 challenges with natively supporting web push:

1. I personally do not use or care about alert notifications, and I've never even set them up before in the existing native apps. This means I am not very familiar with how notifications are done already, and I am not motivated to spend a lot of time working on it, which is required because:

2. I would consider it a failure if web push notifications were not at least as easy to set up as for Android/iOS. Dealing with the HTTPS requirement seems like the biggest part of this. Self-hosting HTTPS for every Blue Iris user is a pipe dream -- most would be stuck with self-signed certificates and warning pages which I consider an absolutely unacceptable user experience. Therefore this would require a cloud-hosted website to proxy the notifications through. Like ntfy.sh is doing for you, but in this case I'd have to custom-build it for tight integration with UI3 and Blue Iris, and maintain the service indefinitely. All of this is completely within my skill set, but it is a lot more than I want to do for free.

3. This would require lots of collaboration with the BI dev since he's the only one who can make additions and changes in the BI local console. That is time-consuming for both of us.

 

[wtf911]

@wtf911 I agree native web push support would be nice. I've thought a lot about it before and brought it up to the BI dev before, but if I recall he didn't respond to my email (this is pretty typical for such requests from me).

I see 3 challenges with natively supporting web push:

1. I personally do not use or care about alert notifications, and I've never even set them up before in the existing native apps. This means I am not very familiar with how notifications are done already, and I am not motivated to spend a lot of time working on it, which is required because:

2. I would consider it a failure if web push notifications were not at least as easy to set up as for Android/iOS. Dealing with the HTTPS requirement seems like the biggest part of this. Self-hosting HTTPS for every Blue Iris user is a pipe dream -- most would be stuck with self-signed certificates and warning pages which I consider an absolutely unacceptable user experience. Therefore this would require a cloud-hosted website to proxy the notifications through. Like ntfy.sh is doing for you, but in this case I'd have to custom-build it for tight integration with UI3 and Blue Iris, and maintain the service indefinitely. All of this is completely within my skill set, but it is a lot more than I want to do for free.

3. This would require lots of collaboration with the BI dev since he's the only one who can make additions and changes in the BI local console. That is time-consuming for both of us.

Thanks for the reply. I'll just mention regarding the HTTPS certs, I had never used Caddy before but after running it, it's really amazing how it simply just works. Runs on Windows, can run as a service, supports a simple few line config file to get a reverse proxy going, and no matter what website you throw at it as long as your router has ports 80 and 443 forwarded it will get you Let's Encrypt certs automatically no work needed for every new domain you route to it.

 

[bp2008]

Thanks for the reply. I'll just mention regarding the HTTPS certs, I had never used Caddy before but after running it, it's really amazing how it simply just works. Runs on Windows, can run as a service, supports a simple few line config file to get a reverse proxy going, and no matter what website you throw at it as long as your router has ports 80 and 443 forwarded it will get you Let's Encrypt certs automatically no work needed for every new domain you route to it.

Yup, in fact it is even possible with just port 443 forwarded, via the TLS-ALPN-01 validation method supported by LetsEncrypt and Caddy. I even implemented that validation method in my own reverse proxy server I wrote.

Unfortunately, just getting that far is difficult for a lot of users (thanks largely to CGNAT), and then some don't want to expose their Blue Iris web server online, which makes it a lot trickier for them to get trusted certificates.