that NPAPI thing..

[Ouch]

Does anyone know how various camera manufacturers are progressing with updated their firmware to enable full functionality via web-browser that isn't dependent on NPAPI?

I'm considering a Hikvision camera or two (probably DS-2CD2432F) for home use, and have gone as far as emailing their support to find out if their firmware has been updated for non-IE browser support, there were discussions earlier this year which implied that it hasn't.

I've been sent a reference to some firmware (vers 5.3.3 I think) released in October, but as I've yet to install one of their cameras, I'm not in a position to confirm if it works or not.

has anyone had any similar experiences?

G

 

[nayr]

NPAPI Plugins are going to be required for a good long time, dont hold your breath.

FYI, Hikvisions work fine on MacOSX.. and I dont have IE at my disposal.. Chrome killed the NPAPI, but firefox and safari work with it just fine...

so basically your statement: non-IE browser means = no chrome support, because there are non-ie browsers that work fine.

 

[klasipca]

Yeah, it's a bummer. One of the reasons I went with Hikvision cams before was because they worked in Chrome and I can't stand using any other browser. Although, now I've accustomed to use IE tab extension. It does the job without leaving Chrome you can view any cam:

https://chrome.google.com/webstore/detail/ie-tab/hehijbfgiekmjfkfjpbkbammjbdenadd?hl=en-US

 

[nayr]

the only way that this point for a camera to work in Chrome is to support html5 video directly from the camera.. thats not going to happen any time soon because:

1. HTML5 Video for Realtime Live Video is not quite there
2. The camera does not encode your h264 streams into an html5 compatible encoding.. changing it so it does could break more than it fixes as IPCams have more going on like WaterMarking, Index Timelines, that are not part of standard MP4 Video.

Chrome is awesome, but they killed all plugins for everything.. not just IPCameras.. so why are the camera manufacturers going to jump through a bunch of hoops only to have Google pull the rug out from under them again.. at this point, I dont think any of them give 2 shits about Chrome being broken and have zero intention of supporting it again.

 

[klasipca]

so why are the camera manufacturers going to jump through a bunch of hoops only to have Google pull the rug out from under them again..

Because they are slowly taking over the world

Browser	Total Market Share
Microsoft Internet Explorer	43.40%
Chrome	39.09%
Firefox	10.54%
Safari	4.87%

 

[nayr]

and so with IE having a mere 40% of the market, then explain to me why your Huisun and Lorex's require ActiveX?

oh wait, they dont give 2 shits what's the most popular browser...

If IE, Firefox and Safari dropped NPAPI Support then maybe the'd add it.. but then maybe the'd say download China's state sanctioned browser instead, as there developers face prison time for installing chrome.

The industry is not moving off RTSP simply because google thinks its too antiquated to allow its browser to display video from it..

 

[klasipca]

and so with IE having a mere 40% of the market, then explain to me why your Huisun and Lorex's require ActiveX?

China didn't give a shit about Chrome up until recently a few years ago, Chrome is overtaking now there as well, but it will take a while before IP camera market will benefit from that

http://www.chinainternetwatch.com/12582/top-6-desktop-browsers-in-china-in-2014/

 

[nayr]

yeah and everyone is using 1/3rd image sensors still and people still think 720p is HD.. the way this industry moves, chrome might work again in the 2020's.. if your lucky.

The industry required IE for eons, then finally started supporting other browsers just recently... then google pulled the rug out from under them and removed all external plugin support.. they cant plugin there way out of this, they have to change firmware/hardware to appease chrome.. good f'n luck.

 

[bp2008]

They could fall back to jpeg video and require no plugins ... I would love that myself but people who can't live without smooth video would hate it. Also I suppose their encoding hardware would need to be able to produce jpeg frames efficiently without pegging the little CPU. I'm not sure if camera logic boards have maintained that ability over the years.

 

[nayr]

cant even get VLC to proxy h264 video directly to a web browser in html5, ive tried it.. i think fenderman or you did too, has to be transcoded to Theora and then whats the point.

Got to get all the vendors to ditch there proprietary video containers to have any hope for plugin-less h264 html5 video... that'd be really awesome if they did, but I am not holding my breath.

the cameras stream h264 via http, at least Hik and Dahua do.. but its nothing any browser can understand natively.

 

[bp2008]

Yup, Theora isn't nearly as good of a codec, and VLC's transcoding performance leaves a lot to be desired. I've briefly looked at some of the methods for streaming live h264 to browsers without plugins (like MPEG-DASH) but it is all way over my head and overly complicated. I would think a camera manufacturer would rather use a web socket to stream whatever video container format they want and use Broadway (an h264 decoder in Javascript) to decode and display the video. It wouldn't solve audio streaming though.

 

[nayr]

I tried to get WebChimera to work, but it also is a beast to setup.. https://github.com/jaruba/node-vlc-multiscreen

its basically transmitting the vlc framebuffer as html5, if I understand how its working.. so if VLC can play it you can stream it.

 

[bp2008]

Hmm, the last time i paid attention to WebChimera it was just a fancier version of the VLC web plugin (NPAPI!)

 

[Ouch]

So does anyone know if firmware I mentioned in the first post actually works?

 

[moleiro]

It seems that for now the only solution is to transcode rtsp into mp4 or other.
Does anyone know any solution with the transcode being done in the client browser ? It's nasty... but doing it on the server if you have a lot of users it's crazy.
I have came across a lot of transcode solutions like this one: https://github.com/SpecForge/html5_rtsp_player/wiki/HTML5-RTSP-Player
Did anyone try this solution or other?

Many thanks,
Pedro, O Moleiro

 

[bp2008]

It seems that for now the only solution is to transcode rtsp into mp4 or other.
Does anyone know any solution with the transcode being done in the client browser ? It's nasty... but doing it on the server if you have a lot of users it's crazy.
I have came across a lot of transcode solutions like this one: https://github.com/SpecForge/html5_rtsp_player/wiki/HTML5-RTSP-Player
Did anyone try this solution or other?

Many thanks,
Pedro, O Moleiro

Interesting, but as I suspected they needed to run server-side code to stream the video with a web socket. That step is probably efficient enough to run on a camera, but good luck getting a camera manufacturer to implement such a thing this decade. Also, good luck getting them to host the web socket on the same port as http (which would be most convenient for firewall access rules).

 

[SpecForge]

It seems that for now the only solution is to transcode rtsp into mp4 or other.
Does anyone know any solution with the transcode being done in the client browser ? It's nasty... but doing it on the server if you have a lot of users it's crazy.
I have came across a lot of transcode solutions like this one: https://github.com/SpecForge/html5_rtsp_player/wiki/HTML5-RTSP-Player
Did anyone try this solution or other?

Many thanks,
Pedro, O Moleiro

Hello, moleiro.

The live test of our html5 player, which transcodes rtsp to mp4 can be viewed http://srv.tom.ru/ (not supported in iOS Safari and Internet Explorer)

Transcoding from client's side becoming mainstream because JavaScript webworkers + asm.js technologies already allow us to do it.
Performance on the profile measurements for transcoding shows 1% of the execution time of the whole process of streaming while playing from the browser side.
And this is without code optimization.
Soon, more and more of processing will be moved to the client side. Technologies, such as webassembly, will allow us to get productive code.

Best Regards,
SpecForge team.

 

[SpecForge]

Interesting, but as I suspected they needed to run server-side code to stream the video with a web socket. That step is probably efficient enough to run on a camera, but good luck getting a camera manufacturer to implement such a thing this decade. Also, good luck getting them to host the web socket on the same port as http (which would be most convenient for firewall access rules).

Hello, bp2008.

Even our current implementation of server-side rtsp proxy mades cross-platform and can be easily build to work in video cameras,
if they have UNIX-like Operating Systems (in our case).


Our html5 player, formally, does not depend on our server-side rtsp proxy,
and it can be completed and streams from rtsp over html and any other plagins.


About port 80: Work on port 80 is nothing more than setting up a server,
currently our test html5 player http://srv.tom.ru/ runs on port 80 for normal http requests and for websocket.


Sincerely,
SpecForge team

 

[dclaar]

Opera just stopped working with NPAPI. Firefox will by the end of the year. Leaving internet explorer? :-(

Hello, bp2008.

Even our current implementation of server-side rtsp proxy mades cross-platform and can be easily build to work in video cameras,
if they have UNIX-like Operating Systems (in our case).


Our html5 player, formally, does not depend on our server-side rtsp proxy,
and it can be completed and streams from rtsp over html and any other plagins.


About port 80: Work on port 80 is nothing more than setting up a server,
currently our test html5 player http://srv.tom.ru/ runs on port 80 for normal http requests and for websocket.


Sincerely,
SpecForge team

 

[bp2008]

Opera just stopped working with NPAPI. Firefox will by the end of the year. Leaving internet explorer? :-(

I would be shocked if IE lost compatibility with NPAPI because IE has never followed the same automatic updating scheme as other browsers.