Recherche avancée

Sur d’autres sites (4289)

• 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

• nginx : [emerg] invalid port in url "http://192.168.0.100:80/live" in nginx.conf - Restreaming OBS to LAN

  17 novembre 2018, par popek069

  I want to restream OBS to LAN. So I set up nginx server. The server receive stream from OBS using RTMP and restreams it to HTTP to view from another device.
  Streaming from OBS works, but when I start nginx I get an error

  PS C:\Users\popek\Downloads\nginx> .\nginx.exe -s reload
  
  nginx: [emerg] invalid port in url "http://192.168.0.100:80/live" in C:\Users\popek\Downloads\nginx/conf/nginx.conf:187

  I’m new to nginx and I’m running Windows 10, nginx server and OBS are on the same pc with ip 192.168.0.100
  I’d like to also reencode stream using ffmpeg if it’s possible. I know ffmpeg, I don’t know only how to set input and output.

  Config : (nginx.conf)

  #user  nobody;
  
  # multiple workers works !
  
  worker_processes  2;
  
  
  
  #error_log  logs/error.log;
  
  #error_log  logs/error.log  notice;
  
  #error_log  logs/error.log  info;
  
  
  
  #pid        logs/nginx.pid;
  
  
  
  
  
  events {
  
      worker_connections  8192;
  
      # max value 32768, nginx recycling connections+registry optimization = 
  
      #   this.value * 20 = max concurrent connections currently tested with one worker
  
      #   C1000K should be possible depending there is enough ram/cpu power
  
      # multi_accept on;
  
  }
  
  
  
  
  
  http {
  
      #include      /nginx/conf/naxsi_core.rules;
  
      include       mime.types;
  
      default_type  application/octet-stream;
  
  
  
      #log_format  main  '$remote_addr:$remote_port - $remote_user [$time_local] "$request" '
  
      #                  '$status $body_bytes_sent "$http_referer" '
  
      #                  '"$http_user_agent" "$http_x_forwarded_for"';
  
  
  
      #access_log  logs/access.log  main;
  
  
  
  #     # loadbalancing PHP
  
  #     upstream myLoadBalancer {
  
  #         server 127.0.0.1:9001 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9002 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9003 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9004 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9005 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9006 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9007 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9008 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9009 weight=1 fail_timeout=5;
  
  #         server 127.0.0.1:9010 weight=1 fail_timeout=5;
  
  #         least_conn;
  
  #     }
  
  
  
      sendfile        off;
  
      #tcp_nopush     on;
  
  
  
      server_names_hash_bucket_size 128;
  
  
  
  ## Start: Timeouts ##
  
      client_body_timeout   10;
  
      client_header_timeout 10;
  
      keepalive_timeout     30;
  
      send_timeout          10;
  
      keepalive_requests    10;
  
  ## End: Timeouts ##
  
  
  
      #gzip  on;
  
  
  
      server {
  
          #listen       80;
  
          server_name  localhost;
  
  
  
          #charset koi8-r;
  
  
  
          #access_log  logs/host.access.log  main;
  
  
  
          ## Caching Static Files, put before first location
  
          #location ~* \.(jpg|jpeg|png|gif|ico|css|js)$ {
  
          #    expires 14d;
  
          #    add_header Vary Accept-Encoding;
  
          #}
  
  
  
  # For Naxsi remove the single # line for learn mode, or the ## lines for full WAF mode
  
          location / {
  
              #include    /nginx/conf/mysite.rules; # see also http block naxsi include line
  
              ##SecRulesEnabled;
  
                ##DeniedUrl "/RequestDenied";
  
                ##CheckRule "$SQL >= 8" BLOCK;
  
                ##CheckRule "$RFI >= 8" BLOCK;
  
                ##CheckRule "$TRAVERSAL >= 4" BLOCK;
  
                ##CheckRule "$XSS >= 8" BLOCK;
  
              root   html;
  
              index  index.html index.htm;
  
          }
  
  
  
  # For Naxsi remove the ## lines for full WAF mode, redirect location block used by naxsi
  
          ##location /RequestDenied {
  
          ##    return 412;
  
          ##}
  
  
  
  ## Lua examples !
  
  #         location /robots.txt {
  
  #           rewrite_by_lua '
  
  #             if ngx.var.http_host ~= "localhost" then
  
  #               return ngx.exec("/robots_disallow.txt");
  
  #             end
  
  #           ';
  
  #         }
  
  
  
          #error_page  404              /404.html;
  
  
  
          # redirect server error pages to the static page /50x.html
  
          #
  
          error_page   500 502 503 504  /50x.html;
  
          location = /50x.html {
  
              root   html;
  
          }
  
  
  
          # proxy the PHP scripts to Apache listening on 127.0.0.1:80
  
          #
  
          #location ~ \.php$ {
  
          #    proxy_pass   http://127.0.0.1;
  
          #}
  
  
  
          # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
  
          #
  
          #location ~ \.php$ {
  
          #    root           html;
  
          #    fastcgi_pass   127.0.0.1:9000; # single backend process
  
          #    fastcgi_pass   myLoadBalancer; # or multiple, see example above
  
          #    fastcgi_index  index.php;
  
          #    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
  
          #    include        fastcgi_params;
  
          #}
  
  
  
          # deny access to .htaccess files, if Apache's document root
  
          # concurs with nginx's one
  
          #
  
          #location ~ /\.ht {
  
          #    deny  all;
  
          #}
  
      }
  
  
  
  
  
      # another virtual host using mix of IP-, name-, and port-based configuration
  
      #
  
      #server {
  
      #    listen       8000;
  
      #    listen       somename:8080;
  
      #    server_name  somename  alias  another.alias;
  
  
  
      #    location / {
  
      #        root   html;
  
      #        index  index.html index.htm;
  
      #    }
  
      #}
  
  
  
  
  
      # HTTPS server
  
      #
  
      #server {
  
      #    listen       443 ssl spdy;
  
      #    server_name  localhost;
  
  
  
      #    ssl                  on;
  
      #    ssl_certificate      cert.pem;
  
      #    ssl_certificate_key  cert.key;
  
  
  
      #    ssl_session_timeout  5m;
  
  
  
      #    ssl_prefer_server_ciphers On;
  
      #    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  
      #    ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:ECDH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!eNULL:!MD5:!DSS:!EXP:!ADH:!LOW:!MEDIUM;
  
  
  
      #    location / {
  
      #        root   html;
  
      #        index  index.html index.htm;
  
      #    }
  
      #}
  
  
  
  }
  
  
  
  
  
  rtmp {
  
          server {
  
                  listen 1935;
  
                  chunk_size 4096;
  
  
  
                  application live {
  
                          live on;
  
                          record off;
  
                          hls on;
  
                          push http://192.168.0.100:80/live ;
  
                  }
  
          }
  
  }

• 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