Electrical or line echo is inherent to the PSTN, it has always been present and cannot be avoided because of the nature of the lines connected to homes and offices. These local or subscriber loop circuits use two wires to carry the voice signals while the voice channels use four wires for bi-directional communications beyond the first switch that is the local exchange. The conversion between the four wire and two wire electrical circuits is done by transformer called a telephone hybrid whose goal is to separate the signals’ directions and adapt the impedance of both circuits. Like all analog circuits, the hybrids can’t perfectly match the impedances and that causes part of the signal to be electrically reflected back; this is the source of electrical echo.

You might be asking yourself why this wasn’t a problem before VoIP was introduced, which brings us to the second characteristic of echo: delay. Echo can only be perceived by the human ear when it as a delay of 10ms or more but it only becomes disturbing when the delay exceeds 30ms and unacceptable at 50ms or more. In the days when telephony was all circuit switched, the delay was only caused by the length of electrical wires in the circuit connecting the two endpoints. Echo cancellers were only needed on long distance calls because only they involved long enough circuits to make the echo disturbing.

In a VoIP scenario we are not talking about circuit switching anymore since the core of the network is packet switched. Delays are guaranteed to exceed the 30ms threshold because of the additional time it takes to encode, packetize, route, decode and de-packetize the voice stream. This is why even local calls require a solution to the line echo problem.

There have been a lot of attempts made to solve this problem by either tuning the gains to minimize the effect of the echo or by implementing echo cancellation in software. Some of these software echo cancellers are good enough to resolve the issue but will impact the CPU usage of the system, lowering the number of channels that it can handle or raising the minimum hardware requirements. Today most interface card vendors include hardware echo cancellation in their latest products, to resolve the echo problem without taxing the host CPU.

Internet Video delivery is challenging because of factors such as high bitrates and sensitivity to delay or packet loss.

Video Streaming

In the past, video streaming was typically associated to RTSP, with RTP used for transmission.  This protocol uses “VCR-like” commands such as PLAY and PAUSE. In this scheme, the server has to keep track of the client’s state. The server starts playing a stream when giving the PLAY command, and has to maintain the state of each session in order to know what packet to send next. The video stream is based on a single “track”, a file with a fixed encoding profile that cannot change. The quality would quickly suffer when there was a shortage of bandwidth such as congestion leading to packet loss.

Today, HTTP based adaptive streaming services provide a more efficient means of delivery over the Internet.  Similarly to RTSP, the video stream can start playing out before the entire file has been downloaded. The main advantage of adaptive streaming however is that it allows the end point to adjust to changes in available bandwidth and delay.

Apple’s HTTP Live Streaming, SilverLight Smooth Streaming from Microsoft and Adobe’s HTTP Dynamic Streaming are notable examples of this technology. These applications manage a set of tracks, each with a different bit rate. The tracks are then divided into small segments (typically 2 seconds) for distribution to a wide variety of different display profiles.

The main innovation here is that if an endpoint sees a dynamic change in bandwidth (up or down) it can react by changing “tracks” to a higher- or lower-bandwidth track, offering the optimal quality. With a limited amount of local buffering the end point can guarantee an acceptable user experience. The popularity of commercial adaptive streaming applications proves that the quality is critical for Internet video.

Unlike traditional streaming protocols, HTTP based progressive download offers “smooth”  video transmission. These streaming techniques are very effective for stored premium content. In these scenarios, the content is encoded into multiple tracks “off-line” and then placed on the server for consumption. It is less useful for user-generated content, were the number of video clips is orders of magnitudes larger (think of YouTube for example). In those situations, it makes more sense to adapt the bandwidth on the fly for the requested clip (see below).

Video delivery Network

We’ve discussed video delivery from the point of view of the client and the server. The network infrastructure in between is another key factor in efficient delivery. Reducing the data sent by a central server to many clients will significantly reduce the possibility of congestion and packet loss. Multicasting, distributing and caching the data to edge nodes is an efficient way to reduce the original data throughput requirement from the central server. The edge node may also be responsible for dynamically adapting the content to the different profiles required by various terminal devices.

The Content Delivery Network (CDN) model is often used for Internet video delivery. In a CDN, the video source or stream originates from a file server or broadcast TV headend. Popular video streams are stored (cached) at many or all of the CDN edge nodes. When a client requests the stream, it will be transparently redirected to the “closest” edge node. CDN architectures and optimization are quite an elaborate topic that we’ll save for another post.

CDNs help alleviate congestion in the core of a network like the public internet. However with the popularity of mobile video, the problem is slightly different. We not only need to reduce congestion in the core network, we now need to reduce congestion on the wireless link as well. To solve this problem we’re seeing edge routers become more sophisticated. Edge routers aimed at wireless deployments now have embedded DSP capabilities to do inline transrating: they can dynamically change the video bitrate to reduce it when network congestion occurs. These routers perform deep packet inspection (DPI) to determine that the contents are video, and then redirect the media to a DSP for dynamic transcoding/transrating.

As video continues to consume a larger and larger percentage of mobile data traffic, the combination of adaptive streaming, CDNs and inline transrating will become commonplace. In future posts we’ll go into more detail of each of these technologies.

A lot of noise and fuss has come out of the HTML5 video debate. There are in fact (at least) two debates going on. The first is Flash vs. HTML5. Here, it’s an old-world vs. new-world debate. The PC-era was good to Flash, but as mobile devices take on more clout, things like battery life, security, and touch-interfaces are used as arguments to kill flash and move to something new. The second debate is from within the HTML5 camp itself, where the choice of video codec has become a prickly subject. That subject should be left for another post.

The big news last week was that Microsoft announced how their forthcoming Internet Explorer 10 (IE10) will NOT support plug-ins, including Flash. Actually, this isn’t entirely true. The “Metro-style” version of IE10 will not support these plug-ins. There will also be a desktop version, but it’s not where Microsoft is headed. Desktop applications are seen as legacy support. This blog describes the differences quite well. This was obviously a bold decision, but anchored in the same reasoning as what I mentioned above. IE10 will be part of Windows 8 which is promoting touch interfaces, and better integration with Windows Phone 7.

We saw the first inklings of trouble for Flash when Steve Jobs announced that iOS devices would offer no support for Flash or Flash video. They took a lot of heat for it, and we eventually saw some Android phones touting Flash support as an important differentiating feature! It’s obvious today that Apple will not change course, and with Microsoft following suit, a trend is forming.

Slowly but surely we’ve seen people taking sides in this debate. Content owners and video portals were coming down on either side of the fence. Hulu for example has gone on record saying that HTML5 does not “meet all of our customers’ needs” (See “An Aside on HTML5″). YouTube launched an HTML5 “experiment” but warns of many shortcomings, such as limitations with full screen viewing and poor support for ads. I’m sure YouTube’s viewers are ok with ad-free videos, but Google’s management won’t get behind HTML5 if it kills off their revenue streams!

So the race is on between Adobe and the HTML5 world. Who can develop tools that developers love? Adobe hasn’t given up the fight. They’re now rolling out a final version of Adobe Flash Player 11, which will run across all popular desktop and mobile OSes including iOS (using Adobe AIR 3). In my opinion Adobe will carve itself out a nice niche, but eventually, as HTML5/Javascript tools become more complete, the overwhelming number of web-based sites and developers will prevail. We’ll see competitive tools come out that allow the creation of sophisticated games, media players and applications inside the browser itself.

In my previous article, we were using a System on Chip (SoC) DSP that would be the core processor of a compact BTS setup. The very same SoC can be used to provide the backhaul simultaneously to the cellular portion. With its multiple independent RF interfaces, our clients can connect both cellular and backhaul antenna directly on one device. The backhaul is also flexible, offering the option to use OFDM or cellular UE standard with high performance radio. Since we wanted that our clients be able to customize and adapt the backhaul modem to their specific needs (LOS, NLOS), we designed our DSP to be C programmable. That’s a lot of option for backhaul, all this while still having a cellular cell simultaneously covering around 20km. This design flexibility allows multiple backhaul options within a large cell SoC processor.

We want our clients to have a lot of flexibility to create their low cost, low power and easy to install BTS solution. In that mindset, we added a PCIe and USB interface to our SoC. This opens many interesting and original ways to take advantage the DSP. For example, using the PCIe or USB to connect a low cost Wi-FI module, we can provide outdoor Wi-FI for short range internet service. All that would be needed would be to connect a Wi-Fi module that will interact directly with the processor.

With three RF interfaces, inputs like for PCIe/USB and flexible backhaul. We created a Small Cell Processor  that lets System Designers run their imagination wild. I am looking forward to seeing the great things our clients will do with our device.

Fast-forward a few years, and what do you think we’ll see? Those same tablets will have pervasive 3G/4G connections. And those same kids will grow up a little. Within 1-2 years, I’m convinced we’ll see the proliferation of “backseat video chatting”. Does that sound crazy? It’ll be free, thanks to applications like Skype that just launched their full-screen video iPad app last week. Once these apps are well integrated to social media and presence, you’ll always know who you can “hang-out” with, as Google+ calls it. In fact, this may create the problem that Google+ is trying to solve with their “Hang-outs”. As far as I know, people aren’t just sitting at their computer, thinking, “I wish I could video chat my friends”. But when you’re stuck in the car for 8 hours, you’ll talk to anyone!

We’ll check back in a few years to see if this comes true. In the meanwhile, we’ll stick to desktop video conferencing.

As Wikipedia puts it: “Psychoacoustics is the scientific study of sound perception”. While there’s a lot of theoretical research on the topic, one of the main application of psychoacoustics is lossy audio coding. One of the first codecs to make use of psychoacoustic tricks — long before MP3 was born — is the G.711 (u-law/A-law) codec. In general, lossy audio codecs attempt to reduce the bitrate by coding the audio signal with just enough accuracy to avoid the distortion being audible.

What you can get away with

There are many types of distortion that can be inflicted on an audio signal without causing too much audible degradation. Here are some examples below.

Phase distortion

The human ear is almost completely insensitive to the phase of signals. For example, we can’t distinguish between a waveform and its inverted version (the only reason loudspeakers have a red and a black connector is to avoid wiring them 180 out-of-phase with each other and getting cancellation effects). As long as the phase distortion is constant (or nearly constant) in time and that the variation in group delay across frequencies isn’t enough to cause temporal smearing, then the phase can take a lot of abuse without anyone noticing. The audio samples below show the effect of applying an all-pass filter that completely distorts the phase, but leaves the amplitudes unmododified.

In practice, few codecs really take into account the irrelevance of phase because it’s a very hard to do it right. The main class of codecs that take advantage of this in some way are the very low bitrate parametric vocoders, such as LPC10 and MELP. These codecs just transmit a set of voice synthesis parameters (typically the pitch, the gain, and the shape of the spectrum) and send them to a decoder that does not even attempt to recover the phase.

Properly shaped noise

Noise that resembles the signal in both spectrum and temporal envelope can be very hard to hear. This is why perceptual audio codecs can achieve good audio quality despite having a really low signal-to-noise ratio (SNR). On that topic, it’s often said that lossy codecs such as MP3 “discarding frequencies that cannot be heard”. That’s just not how it works in practice. What really happens is that instead of representing each frequency component with the equivalent of 16-bit precision (which is what CDs and most wav files use), one can selectively use a much lower precision. The result is quantization noise, which lossy codecs attempt to shape in such a way as to make it inaudible.
Here’s an example that demonstrates just how much difference it can make. The same file was quantized with Vorbis at 64 kb/s, as well as with a 6-bit PCM quantizer (like a 6-bit wav file). The Vorbis file has an SNR of 16 dB, while the 6-bit PCM file has an SNR of 18 dB.

It’s pretty obvious that despite having 2 dB more noise, the Vorbis file sounds much better. The difference is that instead of having a constant, white quantization noise, the noise is shaped and sounds like this.

What you cannot get away with

Despite the fact that audio signals can tolerate a lot of abuse, there are some things that you just cannot do. The following artefacts will tend to make audio sound really bad.

Frame discontinuities (aka blocking artefacts)

In video coding, blocking artefacts can be somewhat annoying. In audio coding/processing, blocking artefacts are just so bad that it disqualifies any algorithm that cannot avoid them. This is why audio codecs use the Modified Discrete Cosine Transform (MDCT), rather than the plain Discrete Cosine Transform (DCT) used in most video codecs. The modification in the MDCT is the addition of a smooth transition (overlap) between the two DCTs. This makes a big difference as can be seen in the example below. Both files are coded at 40 kb/s using the Opus codec, but for one of them, Opus was modified to use the DCT rather than the MDCT.

Pre-echo

Pre-echo is the main problem that transform audio codecs (e.g. those based on the MDCT) try avoiding. It happens because transform codecs have a tendency to have their quantization noise spread evenly over an entire frame. In the case of a sharp transient, it means that noise appears before the transient, like a reversed echo (thus the term pre-echo). Here’s an extreme examples coding castanets using G.722.1C, one of the worse audio codecs when it comes to pre-echo:

The result is so bad that the castanets sound almost like maracas. There are multiple ways transform codecs use to avoid pre-echo:

• Block switching: using a shorter transform size when transients occur
• Temporal noise shaping (TNS): optimizing the fine temporal shape of the noise
• Time-frequency transformations (in the Opus codec): increasing the time resolution for bands that contain transients

The good news is that this growth is consistent with other economic trends, i.e. it is not a bubble, anomaly or any other one off event. The enterprise segment unlike the consumer segment has always been in synch with macro economics. Organizations, under the steely grip of the Chief Finance Officer (CFO), rarely spend money when none is coming in (unlike your wife…or husband!). In poor economic conditions enterprises preserve cash and refrain from major upgrades or purchases – PBxs and video conferencing equipment included. However under an improving economic outlook, as is the case today, purse strings loosen and investments showing a good Return on Investment (ROI) get approved.

The UC PBx has often proven to be such an investment, leading to improvements in company efficiency and effectiveness. Older TDM PBxs, supporting voice only, are no longer suitable for today’s “always connected” office worker. The UC PBX provides a platform on which multiple real-time communication services such as instant messaging (chat), presence information, telephony (IP telephony), video conferencing, and other collaboration tools may be connected.

As you would expect, companies driving and benefiting from this growth are market leaders Cisco and Avaya, who between them account for more than 60% of the total UC market. Following closely behind them are the “others” that include Mitel, Siemens, NEC and Alcatel-Lucent.
As more PBXs become connected it follows that the network also needs upgrading. This led to a 70% jump in enterprise session boarder controllers (SBCs). Beneficiaries of this boom include Samsung, NEC, Newport Networks as well as Alcatel-Lucent.

The final market segment, with a sunny horizon, is video conferencing and telepresence. According to the report this market will more than double by 2015. While Cisco is once again a Key player, others also got a jump on video, these include Radvison and Polycom among others.

In my opinion wholesale adoption of video in the enterprise is long overdue, and market growth still somewhat understated. I say this for a couple of reasons; firstly in the wake of recent oil prices travel is just too expensive and increasingly difficult to justify. Secondly, and I speak from personal experience, business travel is just not what it used to be. Flying, especially in economy, is uncomfortable, time consuming, and with the heightened security an invasion of privacy.
So a note to all those CFO’s, do your bit…. for the economy, the environment and the quality of life of your employers -buy a UC PBx and mandate video conferencing.

The title of this blog can be taken in two ways; firstly as a reflection of the undeniable uptake in video demand (Infonetics Research Newsletter) and secondly, an oblique reference to the fact that the ubiquitous X86 is no longer the best fit for today’s demanding video applications. Quite latterly the x86 is running hot, white hot in fact, due to the ever increasing demands made by real-time video transcoding.

How could this be?

Well let’s first consider that video, thus far, has largely been an on demand service, i.e. stored then streamed as required. This is unlike voice that not only has to be real-time but also low latency. Consequently the underlying supporting infrastructure equipment has to be different. Voice leverages the agile real-time benefits of the DSP, while video hitches a ride on the standard X86 server platforms already used by the internet.
However, this is rapidly changing as the proliferation of mobile video and video conferencing creates the need for real time video also. Given that a single 1080P video channel takes as much processing power as say 1000 channels of voice! At least two issues come to mind; processing speed and network bandwidth.

Yes the x86 could do this…..just add more servers (Intel would be very happy). However this is not quite that simple as larger scale economics starts to make a big impact. For example server farms take-up considerable real-estate (like the central offices of old), and even the most green ones consumer a considerable amount of power. In a recent announcement concerning Apple’s planned data centre in North Carolina a lease was signed to deliver a staggering 2.28 megawatts of critical power. So would a milli-Watt or even a micro-Watt spent at the component level would make a difference -you bet it would.

So what consumes all this power? Many things, but if ranked by system designers (and I am sure it is) transcoding would be number 1 on their list. Transcoding is basically the art of converting from one format or standard to another, not too difficult, but remember this has to be real-time and without error – a bit more difficult. Video content is exchanged between a wide variety of equipments; smart phones, camcorders, video phones, laptops, desktop PCs, and HDTVs just to name a few. Each has its own resolution and coding / decoding requirements. Unfortunately no one single format for exchanging video exists, multiple standards exist creating a huge burden on server processing engines. The current x86 internet based server is just not up to the task.

So to use a much used quote “cometh the hour cometh the man” The hour being the need to transcode between multiple video standards and the man being the asynchronous DSP. No ordinary DSP, but a DSP that brings a step function improvement in efficiency, not only the x86 but over its synchronous counterparts.

This efficiency manifests in two ways, real estate savings and power savings. This efficiency is not achieved through tricks of lithography (65nm, 35nm…etc) or through expensive and convoluted power saving schemes but through a real fundamental architectural advantage. Put simply, in asynchronous architecture the clock tree is eliminated. In one fell swoop both the power consumed and silicon real-estate can be reduced. So what about the MIPs? While MIPs are an important benchmark metric, they are difficult to apply to an asynchronous engine (since there is no clock). So let’s look at how effective the engine is in the real world; compared to a typical server class dual quad core Xeon, an asynchronous DSP can easily provide a 15 times gain in channel density without a corresponding increase in power consumption. Alternatively the same channel density (as the Xeon set-up) can be delivered with a power reduction of up to 62%.
Now just imagine by how much Apple could reduce their hydro bill and rental costs!

Chief Executive Chambers, in keeping with his promise, sought ways to bring expenses in line with earnings.  At the time he probably hoped this would be achieved through an uptick in revenue rather than having to yield an axe.  Unfortunately the latter became necessary, and the Flip phone was “flipped” according to a recent release.

So was it a mistake to exit this business or was it a mistake to enter in the first place?  While Cisco is the undisputed ICON of the telecommunication infrastructure it is not well recognised by the consumer.  This crown rests firmly on the head of Apple. Why would anyone in their right mind take on Apple in their own backyard?    With the CISCO Linksys router business firmly established, the shiny allure of the consumer market called one again.  Addressing both the insatiable demand of social networking and mobility, the video handset market must have seemed an easy choice and entering the market via acquisition was clearly a smart decision.   As you would expect from CISCO this decision was also anchored to its core competencies by creating an increased demand for network bandwidth. How better than by populating the world with bandwidth hungry HD cameras.  In its category the FLIP was still the top selling video camera in the US with 26 percent market share (according to IDC).

Judging whether a decision is right or wrong is always easy when it’s not your decision to make.  So with impartiality in mind,  I say the decision was right when it was made to buy and is just as right (if not more right) now that it has been made to exit.

Although often clouded in negativity, corporate restructure can also bring positivity, for employees, customers and suppliers alike.  Observers of this latest announcement should focus on the positives: focus on what CISCO is doing, not what they are not doing.  In the corporate announcement announcing its exit from the flip business CISCO declared its steadfastness to its five key company priorities; core routing; switching and services; collaboration; architectures; and video.