Recherche avancée

Sur d’autres sites (5804)

• WebRTC predictions for 2016

  17 février 2016, par silvia

  I wrote these predictions in the first week of January and meant to publish them as encouragement to think about where WebRTC still needs some work. I’d like to be able to compare the state of WebRTC in the browser a year from now. Therefore, without further ado, here are my thoughts.

  WebRTC Browser support

  I’m quite optimistic when it comes to browser support for WebRTC. We have seen Edge bring in initial support last year and Apple looking to hire engineers to implement WebRTC. My prediction is that we will see the following developments in 2016 :

  • Edge will become interoperable with Chrome and Firefox, i.e. it will publish VP8/VP9 and H.264/H.265 support
  • Firefox of course continues to support both VP8/VP9 and H.264/H.265
  • Chrome will follow the spec and implement H.264/H.265 support (to add to their already existing VP8/VP9 support)
  • Safari will enter the WebRTC space but only with H.264/H.265 support

  Codec Observations

  With Edge and Safari entering the WebRTC space, there will be a larger focus on H.264/H.265. It will help with creating interoperability between the browsers.

  However, since there are so many flavours of H.264/H.265, I expect that when different browsers are used at different endpoints, we will get poor quality video calls because of having to negotiate a common denominator. Certainly, baseline will work interoperably, but better encoding quality and lower bandwidth will only be achieved if all endpoints use the same browser.

  Thus, we will get to the funny situation where we buy ourselves interoperability at the cost of video quality and bandwidth. I’d call that a “degree of interoperability” and not the best possible outcome.

  I’m going to go out on a limb and say that at this stage, Google is going to consider strongly to improve the case of VP8/VP9 by improving its bandwidth adaptability : I think they will buy themselves some SVC capability and make VP9 the best quality codec for live video conferencing. Thus, when Safari eventually follows the standard and also implements VP8/VP9 support, the interoperability win of H.264/H.265 will become only temporary overshadowed by a vastly better video quality when using VP9.

  The Enterprise Boundary

  Like all video conferencing technology, WebRTC is having a hard time dealing with the corporate boundary : firewalls and proxies get in the way of setting up video connections from within an enterprise to people outside.

  The telco world has come up with the concept of SBCs (session border controller). SBCs come packed with functionality to deal with security, signalling protocol translation, Quality of Service policing, regulatory requirements, statistics, billing, and even media service like transcoding.

  SBCs are a total overkill for a world where a large number of Web applications simply want to add a WebRTC feature – probably mostly to provide a video or audio customer support service, but it could be a live training session with call-in, or an interest group conference all.

  We cannot install a custom SBC solution for every WebRTC service provider in every enterprise. That’s like saying we need a custom Web proxy for every Web server. It doesn’t scale.

  Cloud services thrive on their ability to sell directly to an individual in an organisation on their credit card without that individual having to ask their IT department to put special rules in place. WebRTC will not make progress in the corporate environment unless this is fixed.

  We need a solution that allows all WebRTC services to get through an enterprise firewall and enterprise proxy. I think the WebRTC standards have done pretty well with firewalls and connecting to a TURN server on port 443 will do the trick most of the time. But enterprise proxies are the next frontier.

  What it takes is some kind of media packet forwarding service that sits on the firewall or in a proxy and allows WebRTC media packets through – maybe with some configuration that is necessary in the browsers or the Web app to add this service as another type of TURN server.

  I don’t have a full understanding of the problems involved, but I think such a solution is vital before WebRTC can go mainstream. I expect that this year we will see some clever people coming up with a solution for this and a new type of product will be born and rolled out to enterprises around the world.

  Summary

  So these are my predictions. In summary, they address the key areas where I think WebRTC still has to make progress : interoperability between browsers, video quality at low bitrates, and the enterprise boundary. I’m really curious to see where we stand with these a year from now.

  —

  It’s worth mentioning Philipp Hancke’s tweet reply to my post :

  https://datatracker.ietf.org/doc/draft-ietf-rtcweb-return/ … — we saw some clever people come up with a solution already. Now it needs to be implemented

• Chrome’s New Audio Notifier

  30 janvier 2014, par Multimedia Mike — General

  Version 32 of Google’s Chrome web browser introduced this nifty feature :

  
  
  

  When a browser tab has an element that is producing audio, the browser’s tab shows the above audio notification icon to inform the user. I have seen that people have a few questions about this, specifically :

  1. How does this feature work ?
  2. Why wasn’t this done sooner ?
  3. Are other browsers going to follow suit ?

  Short answers : 1) Chrome offers a new plugin API that the Flash Player is now using, as are Chrome’s internal media playing facilities ; 2) this feature was contingent on the new plugin infrastructure mentioned in the previous answer ; 3) other browsers would require the same infrastructure support.

  Longer answers follow…

  Plugin History
  Plugins were originally based on the Netscape Plugin API. This was developed in the early 1990s in order to support embedding PDFs into the Netscape web browser. The NPAPI does things like providing graphics contexts for drawing and input processing, and mediate network requests through the browser’s network facilities.

  What NPAPI doesn’t do is handle audio. In the early-mid 1990s, audio support was not a widespread consideration in the consumer PC arena. Due to the lack of audio API support, if a plugin wanted to play audio, it had to go outside of the plugin framework.

  
  
  

  There are a few downsides to this approach :

  • If a plugin wants to play audio, it needs to access unique audio APIs on each supported platform. One of the most famous things I’ve ever written deals concerns this nightmare on Linux. (The picture worth a thousand words.)
  • Plugin necessarily needs free unrestricted access to system facilities, i.e., security measures like sandboxing become more difficult without restricting functionality.
  • Since the browser doesn’t mediate access to the audio APIs, the browser can’t reasonably be expected to know when a plugin is accessing the audio resources.

  So that last item hopefully answers the question of why it has been so difficult for NPAPI-supporting browsers to implement what seems like it would be simple functionality, like implementing a per-tab audio notifier.

  Plugin Future
  Since Google released Chrome in an effort to facilitate advancements on the client side of the internet, they have made numerous efforts to modernize various legacy aspects of web technology. These efforts include the SPDY protocol, Native Client, WebM/WebP, and something call the Pepper Plugin API (PPAPI). This is a more modern take on the classic plugin architecture to supplant the aging NPAPI :

  
  
  

  Right away, we see that the job of the plugin writer is greatly simplified. Where was this API years ago when I was writing my API jungle piece ?

  The Linux version of Chrome was apparently the first version that packaged the Pepper version of the Flash Player (doing so fixed an obnoxious bug in the Linux Flash Player interaction with GTK). Now, it looks like Windows and Mac have followed suit. Digging into the Chrome directory on a Windows 7 installation :

  AppData\Local\Google\Chrome\Application[version]\PepperFlash\pepflashplayer.dll

  This directory exists for version 31 as well, which is still hanging around my system.

  So, to re-iterate : Chrome has a new plugin API that plugins use to access the audio API. Chrome knows when the API is accessed and that allows the browser to display the audio notifier on a tab.

  Other Browsers
  What about other browsers ? “Mozilla is not interested in or working on Pepper at this time. See the Chrome Pepper pages.”

• Introducing WebM, an open web media project

  20 mai 2010, par noreply@blogger.com (christosap)

  A key factor in the web’s success is that its core technologies such as HTML, HTTP, TCP/IP, etc. are open and freely implementable. Though video is also now core to the web experience, there is unfortunately no open and free video format that is on par with the leading commercial choices. To that end, we are excited to introduce WebM, a broadly-backed community effort to develop a world-class media format for the open web.

  WebM includes :
  

  • VP8, a high-quality video codec we are releasing today under a BSD-style, royalty-free license
  • Vorbis, an already open source and broadly implemented audio codec
  • a container format based on a subset of the Matroska media container

  The team that created VP8 have been pioneers in video codec development for over a decade. VP8 delivers high quality video while efficiently adapting to the varying processing and bandwidth conditions found on today’s broad range of web-connected devices. VP8’s efficient bandwidth usage will mean lower serving costs for content publishers and high quality video for end-users. The codec’s relative simplicity makes it easy to integrate into existing environments and requires less manual tuning to produce high quality results. These existing attributes and the rapid innovation we expect through the open-development process make VP8 well suited for the unique requirements of video on the web.

  A developer preview of WebM and VP8, including source code, specs, and encoding tools is available today at www.webmproject.org.

  We want to thank the many industry leaders and web community members who are collaborating on the development of WebM and integrating it into their products. Check out what Mozilla, Opera, Google Chrome, Adobe, and many others below have to say about the importance of WebM to the future of web video.

  
  

  AMD

  ARM

  Brightcove

  Broadcom

  Collabora

  Digital Rapids

  Encoding.com

  Grab Networks

  iLinc

  INLET

  Kaltura

  Logitech

  MIPS

  Nvidia

  Ooyala

  Qualcomm

  Skype

  Sorenson

  Telestream
  

  Texas Instruments

  Verisilicon

  ViewCast

  Wildform

  
  

  Posted by Jeremy Doig, Engineering Director of video and Mike Jazayeri, Group Product Manager, Google