Cisco To Open Source H.264, Surveillance Impact?
Typically, devices using H.264 need to pay a royalty to MPEG-LA. Now Cisco has announced that they "plan to open-source [their] H.264 codec, and to provide it as a binary module that can be downloaded for free from the Internet."
The immediate benefit is for HTML5, specifically the WebRTC enhancements to better support media / video on web pages.
It might help to enable H.264 streaming for surveillance web clients (e.g., Milestone's HTML5 client uses MJPEG, not H.264). However, I do not think this will have any impact on camera manufacturers who will likely still continue to pay the relatively small royalty for H.264.
This will be HUGE for the VMS industry. HUGE.
Today if you want to use a web browser to view video you either have to install ActiveX, Silverlight or some other application or transcode the video to JPEG. This made it less than desirable. This will make it so you can play H.264 IP cameras in a web browser natively.
I am not sure how huge web VMS clients are :)
That said, I agree about the benefits of streaming H.264 direct to a web client.
I believe they havent been huge in the past because you had to install something. If you were going to install something, why not just install the thick client?
Open source solutions have existed for a while (namely FFmpeg/Libav). The bigger deal is that Cisco is paying the MPEG LA licensing costs for the Internet at large.
That is a pretty big deal.
There are far better solutions available. We (Network Optix) have used VP8/WebM for well over a year now.
VP8/WebM have limited browser support and non-existent camera/VMS support.
James,
WebM has support for all major browsers except for Safari and iOS because Apple is lame and doesn't like supporting Open Source solutions. IE9 and above works just fine when using the extension for it here: WebM for IE. Frankly we don't really care about Apple or iOS in this case because they're both notorious for being walled gardens who don't like to work well with modern open source tech.
As far as cameras and VMS support, that seems kind of a silly statement since when I said "we" above I meant my company which is the developer of HD Witness and DW Spectrum, a VMS solution that has been regularly tested by IPVM.
As far as support for cameras, we support well over a thousand camera models via direct integration and Onvif Profile S and each and every one of them streams from our server to all the above mentioned browsers. That even includes Arecont Vision's multi-sensor cameras which stream as a single stream of all sensors joined together. So all that being the case, I'm not really sure what you're talking about.
The meta point is that 99% of VMS manufacturers do not support VP8. Your company is an exception but is the extreme minority.
Nathan, wouldn't it be easier even for you to use straight H.264 and eliminate the need to transcode streams to VP8?
John,
Streaming H.264 to the web requires paying royalties and obtaining licenses from MPEG. Hence why Cisco is doing this. It's the reason the WebM project was started in 2010. As a solution around such restrictive stupidity for something as open as the web. The point of my comment was to illustrate that there are already good solutions available even without Cisco doing what they're doing.
As an aside, I'm not the only one who believes WebM is a good choice. In a discussion on your own multi-streaming comparison thread, Murat Altuev, founder and Director of Axxonsoft even acknowledged that it was a good choice.
The web should be open and those who use it to provide solutions to web users shouldn't be restricted by stupid licensing schemes. Addtionally, H.264 has serious issues in standard web streaming (that's a whole other discussion). With WebM the decoder lives within the construct of the stream therefore it doesn't require silly extensions or add-ons for proper decoding. The only other alternative around MPEG's monopoly on H.264 is to stick with MJPG as many other VMS do. We believe WebM and open-licensed open source is the way to go.
"Streaming H.264 to the web requires paying royalties and obtaining licenses from MPEG. Hence why Cisco is doing this."
But since Cisco is doing this, doesn't this mean that the royalties requirement for streaming H.264 to the web is now covered?
It certainly adds another solution and method around the MPEG H.264 monopoly. However it still comes with a plethora of issues. A native decoder with full support for Cisco's codec will have to reside inside every browser and app that supports it. With WebM, the decoder lives within the construct of the stream based on the Matroska container. That means you don't need a native decoder. It only requires a window within the browser or app to be open and the stream can decode itself for display within it.
Additionaly, Cisco's method doesn't address dynamic (on-the-fly) transcoding. The native decoder will have to support all resolutions and will have to allow real-time communications between the browser and the source server to request changes in stream resolutions. With WebM, it starts at the source/server streamed resolution and supports dynamic shifting to any sub-resolution. So switching between a 720p stream to a lower resolution 320p or 240p stream is a single click and the client side resolution switches instantly.
There are other issues with H.264 related to p-frames and such but that's worthy of a whole seperate technical discussion.
BTW John,
There's a good discussion in the comment threads of that Cisco blog post discussing H.264/5 vs. VP8/9 codecs.
As an aside, it's worth taking a look at who the supporters of the WebM project are: The WebM Project | WebM Supporters
WebM has support for all major browsers except for Safari and iOS because Apple is lame and doesn't like supporting Open Source solutions. IE9 and above works just fine when using the extension for it here: WebM for IE
If you have to install a plug-in, it doesn't count as supported. From a usability standpoint that's no better than the proprietary Activex crap you have to deal with on so many DVR's nowadays.
Frankly we don't really care about Apple or iOS in this case because they're both notorious for being walled gardens who don't like to work well with modern open source tech.
I have enough Apple using customers that I am forced to care.
As far as support for cameras, we support well over a thousand camera models via direct integration and Onvif Profile S and each and every one of them streams from our server to all the above mentioned browsers. ... So all that being the case, I'm not really sure what you're talking about.
So you are transcoding. That is all fine and good. Currently you are pretty much forced to transcode at the server or require a client side browser extension. If browser support for H.264 becomes ubiquitous (which is what Cisco is trying to achieve), it could conceivably eliminate transcoding.
We're talking in circles James so I'll just leave it with all my comments below. Even in the comments of the Cisco thread listed above the discussion of their solution vs. WebM - VP8/9 codec is lively.
WebM for IE is not an extension. I shouldn't have used that word. WebM for IE. It is simply an additional capability that allows IE to "open the window" and allow VP8/9 to pass through. It is not a decoding engine.
Regarding Apple, Cisco's blog openly discusses that right now it is only for the open source Firefox browswer so it will do you no more good than WebM would for Safari. And for the record, Firefox threw their support behind WebM two years ago and has been a major part of its open source evolution which is why Firefox has full support for it for over two years.
We are transcoding for the reasons I describe in my comments below. It allows dynamic resolution scaling which has huge benefit in optimizing for varying bandwidth connections.
And lastly, as I discuss below, Cisco's own PR person has acknowledged that commercial applications of their technology are still bound by the MPEG-LA royalty licensing once the distribution reaches greater than 100,000 installs with the limitless cap still requiring the $6,500,000 royalty license.
To me this whole thing sounds like Cisco's attempt to stay relevant in a web space that is rapidly trending towards open source, open standards, open licensing. I'd recommend reading all of the comments on that blog post as well. They are highly enlightening regarding the limitations of what they are doing.
Nate, what counts as an 'install'? For purposes of surveillance application, 100,000 installs seems like a lot but I am not sure what counts.
Whether or not you call it an extension, users still have to download and install something. While I am sure it's fairly painless to install the WebM extension, users may not have Admin priveleges or may just be averse to installing additional plugins.
As for your "open the window" argument, I don't get it. Any browser that supports video decoding is going to do so via some 3rd party library. Chrome uses FFmpeg for H.264 support, IE uses Windows Media Player libraries, Safari defers to Quicktime, etc, etc, etc.
That WebM / VP8 offers some technical advantages over H.264, I have no doubt. Indeed I think I started a discussion praising it's potential benefits for security on the old Disqus forums years ago (can't find the link). But the winner of this race is going to be the one who becomes ubiquitous, not necessarily the superior technology.
The browser issue aside, you still haven't addressed the transcoding point; Transcoding adds server load thereby reducing the maximum number of cameras per server.
Whether or not you call it an extension, users still have to download and install something.
Fair point.
As for your "open the window" argument, I don't get it. Any browser that supports video decoding is going to do so via some 3rd party library. Chrome uses FFmpeg for H.264 support, IE uses Windows Media Player libraries, Safari defers to Quicktime, etc, etc, etc.
As you can see from WebM's supporters, FFMPG is a major part of it. It is their primary decoding engine and also the engine we use even in our thick clients as several of my team are major contributors to the FFMPG open source project. However in this case, the ffmpg-based decoder lives within the stream so it doesn't need to be hosted natively within the browser.
But the winner of this race is going to be the one who becomes ubiquitous, not necessarily the superior technology.
I'd have to agree although I would add that it will also be driven by how "open" it is in terms of source code as well as licensing structure. Between the long, long list of powerful companies and technologies supporting WebM as well as their completely free and very open licensing structure makes me think it has an early and commanding lead in this respect.
Reading through the comments it looks like Cisco's PR person is acknowledging that people will still have to pay the MPEG-LA royalties once they've surpassed 100,000 distributions.
If you distribute it, you are subject to the MPEG-LA license rules, and Cisco has nothing to do with it. The MPEG-LA licensing rules allow you to distribute 100k copies royalty free, and after that there is a per-unit charge. Alternatively, you may elect to pay them the cap of $6.5M if you believe your distribution is that large. The cap is really meant for BIG distributions. Hope that clarifies.
Newest Discussions
| Discussion | Posts | Latest |
|---|---|---|
|
Started by
Brandon Simms
|
3
|
1 minute by Brian Rhodes |
|
Started by
Undisclosed End User #1
|
10
|
less than a minute by Undisclosed #3 |
|
Started by
Rashid Khan
|
14
|
less than a minute by Martin Naylor |
|
Started by
Undisclosed #1
|
6
|
about 4 hours by Undisclosed #1 |
|
Started by
John Poole
|
3
|
about 1 hour by Undisclosed Manufacturer #1 |
Nadee Gunasena October 31, 2013 at 9:36 am