Petar Bojkov

Exploiting WebRTC Data Channel Potential: Interview with Viblast

Petar BojkovFollowing my previous post about companies using the WebRTC data channel I started doing some in-depth interviews with a few of them. This is the first interview done with Petar Bojkov, COO of Viblast.

Can you tell us what your company is all about and what makes it stick out of the crowd of WebRTC start-ups?

Petar Bojkov:

Viblast is providing scalable video streaming solutions. Our software platform addresses the unique challenges of broadcasters and over-the-top (OTT) video content providers to reliably deliver high quality video to an ever-growing number of broadband viewers worldwide. Viblast’s groundbreaking functionality relies on the principle of a peer-assisted Content Delivery Network (CDN), where content is delivered to end-viewers using a traditional CDN model improved by the addition of a peer-to-peer (P2P) layer between users.

Our solution uses WebRTC’s data channel to exchange video/audio data chunks between users. While the prevalent uses of WebRTC we’ve seen so far have been centered around making video calls, Viblast tackles a larger scale problem which is poised to grow in parallel with the exponential demand for video streaming.

Viblast-Solutionn-Diagram

The data channel is one of the more interesting capabilities of WebRTC with boundless innovation opportunities. How are you innovating with it?

Petar Bojkov:

Theoretically, the data channel has unlimited potential. However, current implementations usually assume that the data channel will be used for small amounts of data. As Viblast is one of the few companies using the data channel to transfer more than simple text messages between users, we were one of the first developers that tried to pass big chunks of data between peers.

Of course, being off the beaten track is very interesting and challenging. We had to solve some unique challenges, the answers to which cannot be found with a simple web search. We also had to implement various workarounds such as limiting the amount of data we are sending in one message.

While there are many start-ups dealing with WebRTC not many of them are looking at the data channel. Do you think there is any special reason for that?

Petar Bojkov:

The core idea behind WebRTC is to provide a real time communications stack for the web and as such, most startups tend to focus on this space, building one video calling app after another. Since video calling does not require a data channel to work, it gets largely ignored. Such a pity, since there are many interesting use cases of the data channel that would solve real world problems.

An example would be Viblast as a peer augmented CDN using the data channel for peers to communicate, another interesting use is direct file sharing between browsers and yet another one would be a distributed web without servers. The list goes on and I expect that once the initial hype with video calling starts to fade, we will see more and more of these use cases taking advantage of WebRTC’s data channel.

Lately there has been a lot of buzz around net neutrality and the FCC actions in this regards. In addition to that there are announcements about Netflix relationship with Comcast and Verizon, while on the other hand there are rumors about Netflix looking at P2P technology to save on bandwidth and cost. Can your company provide remedy to this issue and does Net Neutrality impact your solution?

Petar Bojkov:

The recent Netflix – Comcast deal and the surrounding net neutrality debate is an interesting issue when considered in the context of Viblast as Viblast’s technology has a potential impact on both. As it currently stands, Netflix streams directly to their subscribers, each subscriber consuming gigabytes upon gigabytes of data, which are delivered by Netflix’s own infrastructure and Amazon Web Services. With the planned move to Ultra HD (4K), these numbers are set to grow in the coming years. Streaming to millions of users is an expensive proposition and the recent Netflix – Comcast peering agreement only compounds the total cost for Netflix.

Are there any customers already using it? Can you name a few?

Petar Bojkov:

Although a young company offering an innovative and yet market unproven solution, interest for our product has been strong and the company is making strides. Viblast is running pilots for a few TV stations, including a national TV channel and a couple of OTT video providers.

What’s next for your company?

Petar Bojkov:

Obtaining a patent for our technology, opening an office in North America and aggressively expanding our customer base once Viblast’s technology becomes more mainstream.

Read more
Keeping things simple requires complicated effort

WebRTC MTI Video Codec: More is Less

Webinar Poll Results Different From My Opinion

Last week I held the second Webinar in the series of WebRTC Webinars for Upperside Conferences. This time it was with Victor Pascual Avila who gave an update about standards. We had 2 live sessions, one in the morning EMEA time and second in the morning US time.

In case you missed it, slides are available as well as the recording.

Keeping things simple requires complicated effortPrior to the Webinar I wrote about the areas WebRTC standards cover and more importantly, why it is good WebRTC defines only the minimal must requirements, As an opening to the Webinar, I presented that diagram and spoke about the “Less is More” advantage in WebRTC standards.

In a nutshell, we want any WebRTC application to run in any WebRTC enabled browser, thus, W3C standardization work is important.

Additionally, we want one WebRTC implementation to work with any other WebRTC implementation and therefore definition of transport, security and media codecs are important, AKA, work done in IETF.

Since WebRTC is built with Web in mind and for the Web, similar to other Web technologies, the way the browser communicates with the server, structures data exchanged and acts upon that data is in the hands of the application.

This is how innovation thrusts.

Poll Question: What should be the mandatory video codec in WebRTC?

After Victor spoke about the different point of views of vendors and segments on the mandatory to implement (MTI) video codec in WebRTC we presented this poll question. Options to choose from were:

  • H.264/H.265
  • VP8/VP9
  • Both should be mandatory
  • There should be no mandatory video codec
  • Don’t care, just make up your mind…PLEASE

To my great surprise, in both sessions, the majority (around 40%) selected option 3.

The need for a mandatory video codec

The preferred option for connecting a session is with media flowing directly between the 2 browsers. In some cases, due to FW/NAT complexities, there is a need for media to go through a TURN server. In both of these options media flows securely between the browsers and even when there is a need for a forwarding server in-between, it doesn’t (and can’t) touch the media, decrypt it or transcode it.

Achieving this requires both browsers to support the same codec.

If they don’t, a transcoding server will need to be placed in the middle, be part of the communication breaking privacy and overloading servers with CPU intensive transcoding and media decrypt/encrypt tasks.

Considerations for selecting the mandatory video codec

There are a few parameters to take into consideration when selecting the MTI codec:

  • Quality
  • HW support
  • License
  • Royalties
  • Porting
  • Future codecs

 

Quality

All in the eyes of the beholder there are different comparisons and opinions depending to a large extent on what camp/company one is part of.

In my eyes, both options are of good enough quality. I don’t see a significant enough difference that would make the decision lean towards one option over the other as long as comparison is apples to apples (VP8 to H.264 and VP9 to H.265, network conditions and additional resiliency tools).

At the end of the day, the WebRTC MTI video codec decision is more of a business decision rather than a technical one.

HW support

H.264 is the standard codec used today for real-time communication. As a result of that, it is supported in many chipsets and mobile devices. This in turn allows for HW acceleration of the CPU intensive encoding and decoding tasks but that is right only for some of the devices and surely not for Apple devices.

On top of that, if an application wants to connect between a WebRTC client and a traditional video conferencing/UC client H.264 will probably be the codec found on the latter.

Having said that, chipset vendors are adding VP8 support as it is already supported by Imagination Technologies, the vendor providing this IPR to most of those vendors.

VP9 is also making its way to HW devices so this gap is about to be closed.

On the traditional video communications front, vendors are adding VP9 as an additional codec but that may take time.

License

Both H.264 and VP8 come with a permissive BSD license.

Google took care of that for VP8 and Cisco took on the challenge to open source H.264.

For the next generation codec, VP9 and H.265 it is a different story.

Google continues the same path of BSD open source for VP9. H.265 on the other hand comes as GNU GPL 2.0 or via a commercial license.

Royalties

Patents and royalty payments are one of the key questions to ask. As WebRTC lives in the world of the Web it is required to allow any developer to build his application without the need to worry about patent infringement. This includes not only applications that run in the browser but also mobile and other devices as they all need to interwork.

VP8 – Google made VP8 royalty free and handled all the patent issues. New issues may come-up once in a while but Google is committed and big enough to solve them. The royalty free “feature” comes with no strings attached, you can port the codec to any platform and still enjoy the Google umbrella.

H.264 – Cisco has also committed to free developers from the H.264 patent burden but the story here is different as in order to seek shelter under the Cisco umbrella you must use their binary package. This works well for browsers but what if I’m developing a mobile application and want the codec to be part of it? What if I want to port the codec to an embedded device and make changes to the codec? In these cases the developer will need to bear the royalties of H.264.

The work Cisco has done for freeing H.264 is well explained by Cullen Jennings in this video.

VP9 – Google has gone the same path.

H.265 – No indication for a similar arrangement by Cisco or others.

Porting

Since all 4 codecs come in some sort of open source license it is technically possible to take the code and port it yet licensing and royalty considerations apply as detailed above.

Future codecs

The decision between VP8 and H.264 will have a good chance to impact the decision of the future codec (VP9 or H.265) and therefore the considerations and differences detailed above (mainly in the licensing and royalty front) must be taken into consideration.

Mandating both is a bad option

So we agree there needs to be a decision.

We reviewed the different parameters to consider.

Why not go for both as the majority of the audience on the Webinar recommended?

There will be no need for a server in the middle to transcode and break privacy.

The 2 browsers will always be able to negotiate which codec to use and life will be great.

Not exactly!

Forcing the implementation of both H.264 and VP8, and in the future H.265 and VP9 increases complexity. WebRTC is open source and it will find its way into different types of devices, including proprietary embedded devices (think of a WebRTC enabled sensor, camera or medical device).

Moreover, licensing and royalty/patent issues will arise in some cases for H.264, and based on current status, in all cases for H.265.

Conclusion

Having H.264 added to the browsers can be a good thing. It will still be royalty free and will avoid transcoding and privacy breach needs in cases where connecting to traditional video communication systems. Additionally, it will eliminate the need to download it as some sort of plug-in in cases the application vendor decides to use it.

Having said that, adding H.264 voluntarily to the browser doesn’t mean H.264 needs to become mandatory.

My choice for MTI would be VP8/9 accompanied with a strong recommendation to add H.264/265 when possible and this is due to 2 simple reasons:

  • Licensing and royalty considerations are extremely important for allowing proliferation of WebRTC applications and services. This alone is a good enough reason
  • VP8/9 is becoming the video codec of the web and that is the natural environment of WebRTC
Read more
WebRTC 2014 Conference Location

WebRTC 2014 Conference Coming to Life

We are shifting gears in preparation for WebRTC 2014. Now that the agenda is public, it’s time to tell you a little bit about the plans for the conference and a few new things that we believe will make the 2014 conference event better than the one of 2013.

WebRTC 2014 Conference LocationThe conference agenda itself was built a bit differently this year as will be described below. Additionally, we added some supporting tools to the conference so people can benefit from content and present their ideas along the year and not only during conference days. There is now a series of Webinars taking place and a blog that was just launched (well, that is where you are reading this post). There will also be a networking tool available for conference attendees so it will be easier to find the people you want to meet.

To wrap all of that nicely, the conference location has changed and it will be in central Paris.

Starting the planning phase

Soon after the end of the WebRTC 2013 conference I was invited by the organizers to lead the committee of 2014 and help in building the conference content and supporting tools. We started forming the conference committee and collected ideas for topics to put on the agenda.

Decision was to have a mix of sessions we would define as mandatory topics to have in the conference agenda while leaving enough room for topics coming mainly from service providers and small startups, things we didn’t think of ourselves and we found interesting.

As a result of this, we managed to get some interesting topics and speakers into the agenda.

The agenda

The training itself will comprise 3 topics:

  • WebRTC state of the market by Tsahi Levent-Levi
  • WebRTC standards update by Dan Burnet and Victor Pascual Avila
  • Data channel workshop by Lubomir Chorbadjiev, CTO of Viblast

The training will be in a technical level right to cater product managers, technology leaders such as architects and CTOs and business people. It is not only for hard-core developers.

At the beginning of the conference we will have a nice lineup of independent industry analysts and consultants I will be bugging through the opening panel to get a wide perspective on what startups, vendors and service providers are doing with WebRTC.

This will come after the traditional opening of Dean Bubbly who will share with us his results of his study about WebRTC statistics and numbers.

On the service provider front there is also a nice lineup of speakers who will present and participate in a panel moderated by Alan Quayle.

We will have series of presentations dedicated to the service provider and enterprise segments as well as more general sessions including:

  • WebRTC SaaS and server side components
  • WebRTC use cases with a few innovative startups
  • A bit more technical sessions on WebRTC 2.0 and ORTC, identity management and the data channel
  • W3C representative’s perspective on the impact of WebRTC on the Web

On the demos front some changes were made this year as well. We will have a dedicated demo session with a few demos of data channel startups. In addition to that there will be demos of communications services but don’t expect to see only the traditional talking heads demos.

There are a few surprises up our sleeves currently in planning so all in all; we believe this will be an interesting conference. You are invited to take a closer look at the agenda and contact us for any question about the conference.

Read more
WebRTC Architecture

WebRTC Standards: Why are They Important?

A year a go I wrote a post talking about Where Standards Matter for WebRTC. As Victor Pascual Avila and I are getting ready for the WebRTC Standards Update Webinar I thought it is a good time to get back to this topic and look at it from a different angle.

Where are the standards when it comes to the Web

There are many misconceptions about what exactly is in the scope of WebRTC and what isn’t. As a result of that, there are different opinions about the parts in WebRTC that should be standardized. This arises mainly when speaking with VoIP and telecom people as we (yes, I’m one of them) are used to the case where everything is standardized, from top to bottom.

Looking at this in perspective of the Web. When a Web developer builds an application there is only one area where standards apply to him, the things that need to run in the browser (i.e. HTML, CSS and JavaScript). Browsers must be compatible in this area, implement the same APIs and yield the same user experience. How information that is exchanged between the browser and the server is structured is completely up to the developer building the application.

This reality of a closed client-server world with standards for client side implementation that allows users to use whatever browser they choose is one of the things that enabled the speed of change and innovation we are all used to in the Web. This stands in contrast to the slow rate of advancement in the telecom world where all needs to be standard.

WebRTC is all about the Web

Taking the Web application example above and implementing it for WebRTC makes it seem very clear that communication between the client and the server doesn’t need to be standardized. How SDP, session context information, user specific data… are sent from the browser to the server is rightfully left for the application, as every application will have different requirements.

Having said that, things related to making sure WebRTC will run on all browsers must be handled through standards. This part will be the main focus of our coming Webinar.

WebRTC Architecture

The diagram above shows this quite clearly. The areas in WebRTC that are and should be standardized are only those related to the interfaces and capabilities of WebRTC itself. This in essence means:

  • The JavaScript APIs (northbound) – this makes sure a WebRTC application will run in any browser that supports WebRTC
  • On the wire protocols – in essence, this is how voice, video and data streams are exchanged peer-to-peer between browsers. Examples of such are transport protocols, security mechanisms chosen and mandatory voice and video codecs. If this wasn’t standardized, communication between browser of brand A would need to go through some mediation box in order to communicate with browser of brand B

If you are interested in hearing more about WebRTC standards, what are the latest advancements and what is still underwork join us for this free Webinar. To accommodate as many time zones as possible we will have 2 live sessions so head over to this information page and register for the one that best fits your preference.

If there are specific topics you would like to be covered in the Webinar or questions you would like to be answered please feel free to Contact Us.

Read more
Connected Data Peers in WebRTC

The non-Telecom Side of WebRTC Data Channel

Connected Data Peers in WebRTCGet rid off servers, save bandwidth! Easy to say, hard to realize. Swarmify, Viblast, Peer5, StreamRoot and Pipe focus their efforts on data transmission of video images and/or file transfer. These innovative start-ups have begun to launch their commercial products in 2014. Their forceful argument? WebRTC data channel uses peers to send data, creating opportunities for innovation and lower cost content distribution without the need for a browser plug-in.

Data channel gets ignored: Such a pity

There are more and more companies dealing with WebRTC but not many of them are looking at the data channel. Many of those who are using it are looking at it as an add-on to voice and video communications services. This is mainly because early adopters of WebRTC are coming mainly from the VoIP and telecom market. Many try to force it into their existing approaches instead of creating new services with it. Some have taken WebRTC to new domains and utilized only the benefits of its data channel part:

  • Peer-to-Peer communication
  • Zero download of plug-ins
  • Secured/encrypted communication

“WebRTC data channels has given developers new possibilities to interact on the web, and we think the biggest innovations will come from this area as WebRTC will become more mainstream” explains Nikolay Rodionov, co-founder of StreamRoot, a French startup providing peer-to-peer video distribution service. The start-up has three pilot customers (France Television, Orange, L’equipe) and claims to reduce bandwidth cost by 50% to 90% thanks to its video streaming technology and adaptive bitrate streaming tool. “Since video calling does not require a data channel to work, it gets largely ignored. Such a pity, since there are many interesting use cases of the data channel that would solve real world problems” says Peter Bojkov, COO of Viblast, a Bulgarian start-up providing scalable video streaming solutions.

Not only video streaming

Other startups are using the WebRTC data channel for a wider set of content distribution use cases. Swarmify recently launched their first commercially available service utilizing WebRTC to distribute website video and images. Pricing plans span from free to paid Enterprise grade options. “Free plans allow users to test Swarmify. It allows them to understand Simultaneous Connections and how this number can reduce their content distribution costs by using our service. Many customers are saving 50% to 75%“ stated Jesse Delia, Swarmify Partner. Peer5, a Palo Alto start-up, redesigned its platform so it would be useful for many use cases, not only video streaming, but also audio, games, image delivery and file transfer.
The new peer5 downloader is now out in beta. “Why are we doing all of this? Many developers had asked us to help them deliver their web apps, but unfortunately our solution was only for video.
Video is cool, but there are so many other varieties of media, and we wanted to provide a more inclusive and generic web peer-to-peer platform.
Our service is helpful in scenarios that require high bandwidth and great performance, and now it’s as encompassing as ever” explains Hadar Weiss, Peer5 Co-Founder and CTO. Pipe, a Berlin­based startup has brought the latest WebRTC technology to its peer­to­peer file transfer service on Facebook. The Pipe app allows people on Facebook to connect by sending and receiving files up to 1 GB in a way that is simple, fast, private and secure. According to Simon Hossell, Founder & CEO of Pipe. “This is ground­breaking technology, essentially re­wiring the Internet. WebRTC allows us to connect and communicate directly with each other through the computer browser ­ peer­to­peer ­ instead of exchanging data with remote third-party web servers.” Pipe was first made available on Facebook in June 2013, based on Adobe Flash. The new Pipe app has been completely rebuilt using JavaScript and integrating WebRTC, instead of Flash. This was also an opportunity to simplify the user experience and make the app more robust and reliable.

CDNs and content owners are moving to Peer-to-Peer

CDN service providers and content owners are bearing increasing cost as video becomes more and more pervasive. Some such as Netflix are already making their way towards this direction. WebRTC data channel can be a solution for this need; companies in this space create a network of peers that off-load the servers when possible and save significant cost. What is your experience with WebRTC data channel? Let us know in the comments below or contact us.

Read more