Google’s open WebRTC media stack ported to QNX / Blackberry 10
The WebRTC media stack has been ported to QNX / Blackberry 10 as reported hy Hookflash in this Press Release below.
This does not mean that WebRTC browsers will now begin communicating with Blackberry apps written using the Open Peer SDK, well… not today anyhow. What it does mean is Blackberry 10 developers can write apps using this new SDK to enable P2P voice, video and messaging, across Blackberry and iOS platforms using their own user identity model or mashed up with social identities.
In the sample app (pictured above) running on a production Z10 and a Alpha Z10 device, Facebook was used to map IDs.
Here is the Press Release…
BlackBerry Live 2013, Orlando Florida – May 13, 2013 – Hookflash announces beta availability of Open Peer Software Development Kit (SDK) for BlackBerry® 10, providing developers with an effective way to integrate high quality, secure, real-time, voice, video and messaging into their own BlackBerry 10 applications.
“The Open Peer SDK for BlackBerry 10 enables a completely new generation of communications integration on the BlackBerry 10 platform,” explains Hookflash co-founder Erik Lagerway. “The Hookflash team has worked tirelessly to build this toolkit and port the WebRTC libraries to BlackBerry 10. BlackBerry developers and enterprise customers can now integrate high quality, real-time, peer-to-peer (P2P), voice, video and messaging into their own BlackBerry 10 applications. People just want good quality voice, video and text communications embedded in whatever they’re doing. Open Peer enables progressive developers in medical, finance, gaming, travel and many other verticals with this next evolution of integrated P2P communications on BlackBerry 10 smartphones.”
“BlackBerry is committed to our app partners through an open ecosystem, strong platform and commitment to supporting innovation and invention,” said Martyn Mallick, VP of Global Alliances and Business Development at BlackBerry. “We are pleased to have Hookflash bring Open Peer to BlackBerry 10, enabling developers to add rich peer-to-peer communications in their apps, and enhance the customer experience.”
The Open Peer SDK for BlackBerry 10 is the most recent addition to the Open Peer, open source family of real-time P2P communications toolkits. The BlackBerry 10 SDK joins the existing C++ and iOS SDKs already available. Mobile developers creating applications across multiple platforms can now leverage the suite of Open Peer toolkits to deliver real-time P2P communications for all of their applications. The Open Peer SDKs are available in open source and can be found on Github (http://github.com/openpeer/).
Hookflash is a globally distributed software development team building “Open Peer”, new “open” video, voice and messaging specification and software for mobile platforms and web browsers. Open Peer enables important new evolution of communications; Open, for developers and customers to create with. “Over-the-top” via the Internet, where users control their economics and quality of service. “Federated Identity” so users can find and connect without limitations of service provider’s walled gardens and operating systems and “Integrated”, communications as a native function in software and applications. Hookflash founders, lead developers and Advisors previous accomplishments include; creators of the world’s most popular softphones, built audio technology acquired and used in Skype, created technology acquired and open sourced by Google to create WebRTC, and engaged inWebRTC standards development in the IETF and W3C.
Developers can register at (http://hookflash.com/signup) to start using the Open Peer SDK today.
For more information and an Open Peer/WebRTC white paper on please visit Hookflash http://hookflash.com
Press Contact:
Trent Johnsen
Hookflash
Press@hookflash.com
855-HOOKFLASH (466-5352) ext 1Hookflash enables real-time social, mobile, and WebRTC communications with “Open Peer” for integration of voice, video, messaging and federated identity into world leading software, enterprise, applications, networks, mobile and computing devices. Hookflash and Open Peer are trademarks of Hookflash Inc. BlackBerry and related trademarks, names and logos are the property of Research In Motion Limited. BlackBerry is not responsible for any third-party products or services. Skype is a trademark of Microsoft. Google is a trademark of Google. Other company and product names may be trademarks of their respective owners.
(full disclosure, I work for Hookflash)
WebRTC MTI Video Codec: VP8 Patent Holders & License Terms Defined
The plot thickens…
—
VP8 Patent Cross-license Agreement
Google is in the process of preparing an agreement that will assist companies and developers with the adoption of VP8 technology by making available a royalty-free license to certain patents that are necessary for the implementation of VP8 and which are owned by Google and a number of other major technology companies.
Google is considering licensing these patents pursuant to the terms of the attached draft patent license agreement. This draft is under review by Google and is therefore currently non-binding and does not constitute an offer to license any patents. A formal, binding agreement will be posted to this site in the coming weeks. Thus, the below draft is for informational purposes only.
The Primary Licensors are each of the following entities and, subject to any noted exclusions, all of their respective Affiliates (as defined in the VP8 Patent Cross-License Agreement).
CIF Licensing LLC
France Telecom
Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e.V.
Fujitsu Limited
Koninklijke Philips Electronics N.V.
LG Electronics Inc.
Mitsubishi Electric Corporation
MPEG LA, LLC
Panasonic Corporation
Samsung Electronics Co., Ltd.
Siemens Corporation
Video: WebRTC Introduction (revisited)
For those who missed this video the first time around, here is a great introduction to WebRTC (Real-time Communication on the web via HTML5 & JavaScript) from Cullen Jennings, Cisco Fellow & Co-chair of WebRTC & RTCWEB Working Groups in the IETF / W3C & advisor at Hookflash.
Cullen covers plenty of ground, focusing on the standards work surrounding this newly proposed standard that is WebRTC. A must watch for those interested in WebRTC. Sadly, there has been zero progress regarding MTI video codecs since this video was shot/uploaded 8 months ago. This MTI video codec issue really needs to be put to bed at the next IETF meeting in July.
H.264 for WebRTC MTI Codec
I have been supporting VP8 as the MTI codec in the WebRTC / RTCWEB WG, for various reasons including…
- Royalty Free (drives innovation)
- Open Source (Source code is optimized for RTC and readily available)
- Supported by a rather large company (Google)
It seems some of us may be changing our minds (myself included), for various reasons, eg…
- H.264 is prolific in RTC today. If we are to have interoperability with other endpoints out there we need 264.
- Open Source. H.264 optimized source for ARM and X86 its coming, Cullen said so
- Supported by many rather large companies (MPEG-LA for starters)
- VP8 IPR is coming under heavy fire. Nokia being one firm that has boldly stated that they hold patents on VP8 and will enforce them, and apparently there is at least one more VP8 patent holder out there that is keeping rather quiet, which is rather disconcerting.
- Since H.264 utilizes hardware acceleration, battery consumption on mobile devices should be lower as well.
- Quality is arguably better in some cases, this can be somewhat subjective.
So where does this leave the innovators that need free software to create free software? Great question, and here are some potential answers…
- If there is Open Source H.264 software out there that has been optimized for Real-time Communication (encoding and decoding in real-time) there are no “software” fees (excluding MPEG-LA), that is one less, rather large, obstacle.
- MPEG-LA (last I looked) has stated that there are no patent fees associated with deployments under 100k endpoints. This is great for smaller deployments but larger deployments could still have a problem here?
Some are saying that the bulk of all mobile devices that could support video have a t least one license for H.264 already, so why then would there be another royalty for H.264 on that very same device? This is an interesting argument and one that may in fact provide the innovative developers with a leg up when it comes time to debate the issue with the MPEG-LA. That being said, most innovative developers I know want nothing to do with legal debates.
There is also another factor to consider, many of the MPEG-LA patent holders are behind WebRTC, so why then would they shoot themselves in the foot and hamper adoption of WebRTC by litigating those who adopt it? There has also been talk of creating a new H.264 license in the MPEG-LA related directly to WebRTC / RTCWEB, which would be free of royalties. Talk is cheap.
Those vendors who only run one codec today will have likely already chosen H.264 for their existing deployments and will likely vote 264 as the MTI codec. At the end of the day, the prudent vendors looking for the most coverage in WebRTC interoperability will support both H.264 and VP8, regardless of which codec is selected as MTI.
After weighing all the options it seems (to me at least) that H.264 is the better choice today, now we just need an open source (with a BSD or MTI license or the like) H.264 implementation that has been optimized for WebRTC.
I am interested in hearing what the developers out there think about this. What do you think? Should H.264 be the MTI (Mandatory to Implement) video codec for WebRTC?
Google forks Webkit in Blink, more WebRTC fragmentation?
As the go-to browser toolkit, WebKIT has been around for a long time and for the most part this open source project is owned by Apple with large contributions coming from Google ala Chrome.
In reference to WebRTC, Apple is really not saying or doing much around WebRTC (at least not publicly), so it should come as no surprise that Google might feel the need to drive innovation into their new Blink project. Obviously WebRTC is not the only motivating factor here but it seems likely that it played a part.
This is probably a good thing, Blink now provides an alternate solution to WebKIT and will seemingly move quicker with Google driving. It could also create fragmentation, which could (for some) be a bad thing. It also means there there is now another critical component of WebRTC under Google’s control, not saying that is bad, just sayin..
At any rate, it begs the question “Where the heck is Apple?” It would be nice to see this mobile market leader taking more of a leadership role in the development of WebRTC. They have been somewhat more vocal recently around the MTI video codec debate in the IETF but aside from that they have remained relatively silent. One thing seems certain, it will be up to Apple to maintain WebKIT now that Google is focusing on Blink.
Changes afoot in WebRTC DataChannel API
We all know that WebRTC and related APIs are a moving target, no surprise there. There is another proposed change in the dataChannel that could break some things for existing developers, if only temporarily.
I am including a recent message from the W3C WebRTC mail list so the developers not following the W3C discussions around WebRTC APIs, dataChannel et al, will be informed.
From: Randell Jesup (Mozzila)
We’re getting ready to do a major update to the Mozilla DataChannel implementation to reflect the results of the Interim and recent IETF meeting. I need a quick answer on the direction to take in the update, as we have some compatibility breaks we must do (wireline protocol changes) and want to minimize the pain for developers.
In this change, per the presentation at the Interim that I hope you all paid attention to (but I think everyone was busy worrying about the wireline issues), createDataChannel() would change from:
channel = peerconnection.createDataChannel(label, dictionary_object)
to
channel = peerconnection.createDataChannel(label, protocol, dictionary_object)Note that this breaks backwards compatibility. Now that there are existing (if experimental) applications using this API in both Chrome and Firefox, this will impact those developers (though it’s an easy update – but knowing which one to use isn’t, since we don’t version the API, and I don’t want people to have to sniff UAs).
I propose instead moving the protocol field into the dictionary (and so people who don’t care about it can easily ignore it).
In related news, to support external negotiation I propose adding these fields to the dictionary (and I’ll note that the dictionary is woefully out of date, supporting in the spec only “reliable”)
/* If either maxRetransmitTime or maxRetransmitNum are set, it’s
unreliable, else it’s a reliable channel. If both are set it’s an
error. outOfOrderAllowed can be used with any type of channel. The
equivalent of UDP is { outOfOrderAllowed: true, maxRetransmitNum: 0 }.
The TCP equivalent is {}.
preset is true if the channel is being externally negotiated, and no
wireline OpenRequest message should be sent. If preset is true, stream
can be optionally used to set a specific SCTP stream to use. If it’s
false but preset is true, then the application should read the ‘stream’
attribute from the returned DataChannel and convey it to the other end
to pass in via the DataChannelInit dictionary.
*/
dictionary DataChannelInit {
boolean outOfOrderAllowed;
unsigned short maxRetransmitTime;
unsigned short maxRetransmitNum;
DOMString protocol;
boolean preset;
unsigned short stream;
};Should we include ‘reliable’ in the dictionary for back-compatibility?
Firefox has not implemented ‘reliable’ up until now, we’ve had the above
(minus protocol and the new negotiation support). If included, it would be
shorthand for {} or { outOfOrderAllowed:true, maxRetransmitNum:0 }
(depending on value). We’d need verbiage about mixing it with the detailed
members however.And I added to the DataChannel webidl:
readonly attribute DOMString protocol;
readonly attribute unsigned short stream;and had previously added:
readonly attribute boolean ordered;
And the question of the existing ‘reliable’ attribute would come up here, though we
can synthesize a value for it from the dictionary values easily per above. We could expose the detailed parameters from the dictionary; I’m not sure that buys us a lot either way
If you have any interest in WebRTC you should follow the W3C list yourself: http://lists.w3.org/Archives/Public/public-webrtc/
IETF 86 | RTCWEB Meetings – Recordings
Meetecho was kind enough to offer their services for remote participation at the last IETF meeting, and most others I have attended remotely.
Here is the email to the IETF mail list…
Dear all,
the full recording (synchronized video, audio, slides and jabber room) of the
RTCWEB WG session at IETF 86 is available at the following URL:
http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#RTCWEBIn case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com.
For the chair(s): please feel free to put the link to the recording in the minutes,
if you think this might be useful.Cheers,
the Meetecho TeamThis email has been automatically generated by The Meetecho Conferencing System
Robin Raymond
Erik
