Recherche avancée

Sur d’autres sites (1835)

• Progress with rtc.io

  12 août 2014, par silvia

  At the end of July, I gave a presentation about WebRTC and rtc.io at the WDCNZ Web Dev Conference in beautiful Wellington, NZ.

  

  Putting that talk together reminded me about how far we have come in the last year both with the progress of WebRTC, its standards and browser implementations, as well as with our own small team at NICTA and our rtc.io WebRTC toolbox.

  

  One of the most exciting opportunities is still under-exploited : the data channel. When I talked about the above slide and pointed out Bananabread, PeerCDN, Copay, PubNub and also later WebTorrent, that’s where I really started to get Web Developers excited about WebRTC. They can totally see the shift in paradigm to peer-to-peer applications away from the Server-based architecture of the current Web.

  Many were also excited to learn more about rtc.io, our own npm nodules based approach to a JavaScript API for WebRTC.

  

  We believe that the World of JavaScript has reached a critical stage where we can no longer code by copy-and-paste of JavaScript snippets from all over the Web universe. We need a more structured module reuse approach to JavaScript. Node with JavaScript on the back end really only motivated this development. However, we’ve needed it for a long time on the front end, too. One big library (jquery anyone ?) that does everything that anyone could ever need on the front-end isn’t going to work any longer with the amount of functionality that we now expect Web applications to support. Just look at the insane growth of npm compared to other module collections :

  

  For those that – like myself – found it difficult to understand how to tap into the sheer power of npm modules as a font end developer, simply use browserify. npm modules are prepared following the CommonJS module definition spec. Browserify works natively with that and “compiles” all the dependencies of a npm modules into a single bundle.js file that you can use on the front end through a script tag as you would in plain HTML. You can learn more about browserify and module definitions and how to use browserify.

  For those of you not quite ready to dive in with browserify we have prepared prepared the rtc module, which exposes the most commonly used packages of rtc.io through an “RTC” object from a browserified JavaScript file. You can also directly download the JavaScript file from GitHub.

  

  So, I hope you enjoy rtc.io and I hope you enjoy my slides and large collection of interesting links inside the deck, and of course : enjoy WebRTC ! Thanks to Damon, JEeff, Cathy, Pete and Nathan – you’re an awesome team !

  On a side note, I was really excited to meet the author of browserify, James Halliday (@substack) at WDCNZ, whose talk on “building your own tools” seemed to take me back to the times where everything was done on the command-line. I think James is using Node and the Web in a way that would appeal to a Linux Kernel developer. Fascinating !!

  The post Progress with rtc.io first appeared on ginger’s thoughts.

• Why I became a HTML5 co-editor

  15 août 2012, par silvia

  A few weeks ago, I had the honor to be appointed as part of the editorial team of the W3C HTML5 specification.

  Since Ian Hickson had recently decided to focus solely on editing the WHATWG HTML living standard specification, the W3C started looking for other editors to take the existing HTML5 specification to REC level. REC level is what other standards organizations call a “ratified standard”.

  But what does REC level really mean for HTML ?

  In my probably somewhat subjective view, recommendation level means that a snapshot is taken of the continuously evolving HTML spec, which has a comprehensive feature set, that is implemented in a cross-browser interoperable way, has a complete test set for the features, and has received wide review. The latter implies that other groups in the W3C have had a chance to look at the specification and make sure it satisfies their basic requirements, which include e.g. applicability to all users (accessibility, internationalization), platforms, and devices (mobile, TV).

  Basically it means that we stop for a “moment”, take a deep breath, polish the feature set that we’ve been working on this far, and make sure we all agree on it, before we get back to changing the world with cool new stuff. In a software project we would call it a release branch with feature freeze.

  Now, as productive as that may sound for software – it’s not actually that exciting for a specification. Firstly, the most exciting things happen when writing new features. Secondly, development of browsers doesn’t just magically stop to get the release (REC) happening. And lastly, if we’ve done our specification work well, there should be only little work to do. Basically, it’s the unthankful work of tidying up that we’re looking at here.

  So, why am I doing it ? I am not doing this for money – I’m currently part-time contracting to Google’s accessibility team working on video accessibility and this editor work is not covered by my contract. It wasn’t possible to reconcile polishing work on a specification with the goals of my contract, which include pushing new accessibility features forward. Therefore, when invited, I decided to offer my spare time to the W3C.

  I’m giving this time under the condition that I’d only be looking at accessibility and video related sections. This is where my interest and expertise lie, and where I’m passionate to get things right. I want to make sure that we create accessibility features that will be implemented and that we polish existing video features. I want to make sure we don’t digress from implementations which continue to get updated and may follow the WHATWG spec or HTML.next or other needs.

  I am not yet completely sure what the editorship will entail. Will we look at tests, too ? Will we get involved in HTML.next ? This far we’ve been preparing for our work by setting up adequate version control repositories, building a spec creation process, discussing how to bridge to the WHATWG commits, and analysing the long list of bugs to see how to cope with them. There’s plenty of actual text editing work ahead and the team is shaping up well ! I look forward to the new experiences.

• Not able to configure FFserver for RTSP

  2 novembre 2015, par Sujith

  I am kind of new to the streaming world... so, please forgive me if I ask kind of dumb question.

  I am trying to stream my pre-recorded file over RTSP through FFserver.

  My config file is :

  RTSPPort 8544
  
  <feed>
  
      File /home/xyz/tmp/feed2.ffm
  
      FileMaxSize 200K
  
      ACL allow 127.0.0.1
  
  </feed>
  
  
  
  <stream>
  
      Feed feed2.ffm
  
      Format rtsp
  
      VideoFrameRate 15
  
      VideoSize 352x240
  
      VideoBitRate 256
  
      VideoBufferSize 40
  
      VideoGopSize 30
  
      AudioBitRate 64
  
      StartSendOnKey
  
  </stream>

  After starting the server, it give the below log :

  $ ./ffserver -f doc/ffserver.conf
  
  ffserver version 0.11.1 Copyright (c) 2000-2012 the FFmpeg developers
  
  built on Sep 17 2012 19:46:38 with gcc 4.1.2 20080704 (Red Hat 4.1.2-52)
  
  configuration: --enable-gpl --enable-libmp3lame --enable-libtheora --enable-libvo-aacenc 
  
  -enable-libvorbis --enable-libvpx --enable-libx264 --enable-version3
  
  libavutil 51. 54.100 / 51. 54.100
  
  libavcodec 54. 23.100 / 54. 23.100
  
  libavformat 54. 6.100 / 54. 6.100
  
  libavdevice 54. 0.100 / 54. 0.100
  
  libavfilter 2. 77.100 / 2. 77.100
  
  libswscale 2. 1.100 / 2. 1.100
  
  libswresample 0. 15.100 / 0. 15.100
  
  libpostproc 52. 0.100 / 52. 0.100
  
  Wed Sep 19 17:03:32 2012 FFserver started.

  And now from my VLC client I am trying to type the URL : rtsp ://xxx.xxx.xxx.xxx:8554/test.sdp

  But, what happens is that, there is no response on the ffserver.

  I have no clue what might be the problem. Thanks in advance.