Real Time Communications Bits

In the last months those terms have been appearing often in the WebRTC codebase and discussions.  In this post I will try to give a very brief description of the meaning, behaviour and implementation status , and attach some comments or source code that can be helpful to illustrate those features.     Pacing or Smoothing When transmitting video it is common to have peaks of traffic when sending a video frame because it is consisting on lots of RTP packets (from 1 to even 50 in case of a key frame) that are sent in the same instant of time.   The solution to alleviate that problem is to add some spacing between those packets or even between frames if needed.    This is known as pacing or smoothing and in case of the Google WebRTC implementation it is enabled by default in the latests versions.     // Set the pacing target bitrate and the bitrate up to which we are allowed to   // pad. We will send padding packets to increase the total bitrate until we   // reach |pad_up_to_bitrat

Finally Cisco has released the source code of the announced open source H.264 implementation: https://github.com/cisco/openh264 Code looks promising although still work in progress (not every platform supported yet) and the features included in encoder and decoder are impressive (simulcast, resolution, quality adaptation...). The binary module (the compiled version of that code) is not yet available, but apparently Mozilla could be already working on the integration in Firefox. This is a great video explaining how is this code and binary module going to work and the implications of that behavior: http://vimeo.com/79578794 These are obviously good news although I still disagree on the inclusion of H.264 as mandatory to implement codec for WebRTC.  The web can not be based on technologies requiring royalties to be used even if Cisco is generous to pay for it for some platforms during some amount of time. BTW, I still maintain my bet of not having a MTI codec in WebRTC.