Webcasting

[dastrix]

hi All

I am trying to display MJPEGS of all my cameras in a java applet thats part of my home automation system.

Right now, we are using the substream url and proxying it because the cameras (Dahua 5231) use digest authentication and we cant pass those credentials using the url (shame theres no basic that works!)

It works, but its very slow. The server that runs nginx is a Xeon Quad core 1ghz Cisco UCS blade with RAID1 and 8GB ram.

Im wondering would Webcast be a solution to this? The BlueIris box has plenty of grunt, also a Cisco UCS machine with 6 x 2 Ghz Cores and 16GB Ram.

Does webcasting support the digest auth and present a URL for either Each camera, or all cameras? Ive got 10 of them.
Thanks

 

[bp2008]

Look in Blue Iris's help file under "The Web Server" topic. At the bottom is a list of URLs you can pull video from. Among them you will find jpeg snapshot and mjpeg video URLs.

Blue Iris's web server doesn't ever use digest authentication as far as I know. Go to Blue Iris Options > Web Server > Advanced. If you disable the checkbox "Use secure session keys and login page" then it will accept HTTP basic auth and also accept authentication embedded in the URL like this: ?user=user&pw=password

Alternatively you can type ^192.168.0.1 in the Limit IP addresses box to cause all connections from 192.168.0.1 to automatically have administrator privilege without the need to log in at all. Very handy if you want a simple device with a static IP address to pull video out of Blue Iris.

 

[dastrix]

Thanks bp2008, you're a huge help. Ill get onto this today and give it a whirl

 

[bp2008]

Browsers do not support mjpeg streams very well. If I recall, those which support mjpeg at all only support it as the src of an img element. When you just enter the URL into the address bar, the browser looks at the Content-Type of the web response and decides how to handle it. Your browser can either choose to play the stream or download it as a file. You don't really get a say in which way the browser vendor implemented it.

 

[dastrix]

Thanks! yep, works fine with Chrome. Thats OK, ill see if this works in OpenHab! If its not too heavy on the CPU using a low encoder profle , it will be a great solution!

 

[dastrix]

Any reason why changing the resolution in advanced of the webserver defaults back to 1270 x , i dont need such high resolutions

 

[bp2008]

Nope

 

[dastrix]

Hmmmm very odd.

 

[yeahman]

Browsers do not support mjpeg streams very well. If I recall, those which support mjpeg at all only support it as the src of an img element. When you just enter the URL into the address bar, the browser looks at the Content-Type of the web response and decides how to handle it. Your browser can either choose to play the stream or download it as a file. You don't really get a say in which way the browser vendor implemented it.

what do you use in ui3 ?

 

[bp2008]

what do you use in ui3 ?

Fetch API to download an H.264 video stream (optionally with a "ulaw" audio stream), in a proprietary streaming format which Blue Iris uses to send video to the mobile apps. The audio gets fed into the web audio API, and the video gets decoded and rendered using Media Source Extensions.

The jpeg streaming modes just continually refresh the jpeg snapshot URL that is defined in Blue Iris's help file.

 

[yeahman]

Fetch API to download an H.264 video stream (optionally with a "ulaw" audio stream), in a proprietary streaming format which Blue Iris uses to send video to the mobile apps. The audio gets fed into the web audio API, and the video gets decoded and rendered using Media Source Extensions.

The jpeg streaming modes just continually refresh the jpeg snapshot URL that is defined in Blue Iris's help file.

So basically it just continously fetching and display camera jpeg?

 

[bp2008]

Yes, that is how UI3 does the streaming quality options that start with "Jpeg".

 

[yeahman]

Yes, that is how UI3 does the streaming quality options that start with "Jpeg".

I was investigating about how to reduce the num of requests on ui3 to reduce battery drain on mobile but seems difficult as it seems the session needs to be renewed quite frequently

 

[bp2008]

The data usage of the background requests (updating server status, camera list, clip list, etc) is really low. You'll save a lot more just by choosing one of the lower resolution H.264 stream options. Or add a new streaming option kind of like this one, and use it. The lower the resolution and frame rate and quality / bit rate limit you can stand to use, the less battery usage will be required.

 

[yeahman]

I see this kind of url
http://{ip_adress}/video/Index/2.0?session={session}&audio=0&stream=0&h=640&kbps=1024&extend=2
in UI3 ... this is not documented anywhere in the blue iris help file.. what kind of stream is this?

 

[bp2008]

That is the "proprietary streaming format which Blue Iris uses to send video to the mobile apps ". I had to ask Blue Iris support for an explanation of how to process it. Now, of course, UI3's source code kind of serves as the only public documentation of the format ... that I am aware of.

 

[yeahman]

oic... thx for the info. Do you know what is the lifetime of the sessions? when should they be "refreshed"?