IETF does not come to consensus on WebRTC MTI Codec

Well…. we had hoped there would be closure today, but alas, the big brains on the block did their best US-Politics impressions instead and managed not to come to consensus on which codec should be mandated to implement in WebRTC today.

Stay tuned for the next round…

Huge news in WebRTC/Video: Cisco open-sources, gives away free H.264

Cisco H.264 is open source and free

Just head of the November IETF meeting where the decision on which codec should be mandatory to implement in WebRTC, Cisco Systems’ Rowan Trollope has announced that Cisco will “provide an open source distribution of H.264 and do so while not passing on licensing costs to other parties” which opens up the ability for browser manufacturers to embed Cisco’s own H.264 code into their WebRTC browser stacks free of charge.

(There has been some work to show the true costs of H.264 licensing, and suffice to say, it has not been free up to this point. Estimates pin the cost to implement it in browsers for realtime communications at around $0.10 per browser. )

Cisco’s Michael Enescu, Cisco’s CTO of Open Source Initiatives actually let the ct out of the bag at 7am EST today, but few noticed.

What this means?

This essentially means that the way is cleared for the IETF to choose Cisco’s open source H.264 codec as “the standard” for HTML5 based native browser real time vide communications. The main pushback against choosing H.264 as the standard, and rather picking Google’s VP8 has come from those who have issues with licensing cost. Now a non-issue.

What this means for you is that the HTML5 real-time video codec likely to land in your favorite browser will be able to talk natively to the vast majority of other video, telepresence systems, surveillance systems and more in existence today, including those of Cisco… No plugins required.

What that means is that there is no longer an unfair advantage for thick apps like Skype. If or can do as good a live real-time bi-directional video stream as Skype, why bother fire up Skype when all it has in addition is a contact list… whereas Facebook has your social graph and Salesforce has all your sales data?

In fairness, this still needs to be voted on by the IETF, which will likely happen by November 8th.

More background

WebRTC is a free, open project that enables web browsers with Real-Time Communications (RTC) capabilities via simple Javascript APIs. Take a look at a video diving into WebRTC here It is likely to be a huge disruptor in the communications industry.

The WebRTC standards are being driven at the IETF (protocol level) and W3C (javascript api level), and both these groups are open and encourage participation of all interested parties…

Currently there are two competing standards for the must implement video codec: H.264 and VP8

If H.264 is made mandatory:

  • Users of web browsers will be able to interoperate natively with existing h.264 capable devices’ video streams.
  • Hardware acceleration of H.264 in graphics chipsets can be leveraged to improve quality and battery life
  • Browser makers may need to secure H.264 licenses to implement the codec, but they would know they are legally compliant

The big news here is that the third bullet of this list is now gone and is not a factor, which is HUGE news. 

If only VP8 is mandatory:

  • WebRTC will not directly interoperate with just about any of the existing video clients and hardware that existing video providers and other telecomm companies make (which are based on H.264)
  • Transcoders will need to be deployed at cost and cause more complexity and hairpinning
  • Google is giving VP8 away for free to all including browser makaers
  • There are still some potential outstanding patent disputes (notably from Nokia) against VP8, leaving browser makers open to potential legal action

But which one is “better”?
This is the heart of the conversation. The proponents of VP8 claim better performance of up to 10%, whereas proponents of H.264 show better results in their tests. Baselines and compression parameters will be tweaked by both… but I think on average performance of both will ultimately be similar enough to make this a wash. Whats more material is interoperability and licensing.

See IETF draft proposing H.264 be mandatory       See IETF draft proposing VP8 be mandatory

It is in the best interest of almost every single existing video user out there that H.264 be a MTI codec in this standard. Google’s own site doesnt even mention it. (They are pushing VP8)


What about iOS support?

If you read the FAQ on the Cisco site you’ll notice that iOS is explicitly omitted since Apple does not allow code to be installed at runtime. A few have panicked at this, but its highly likely that if H.264 is standardized upon for WebRTC that Apple will simply use their existing H.264 libraries which are used in FaceTime and light up the functionality in Safari anyway. In fact its likely then that Safari will be the only .264 browser on iOS thats actually hardware accelerated (Apple does not allow any other companies access to H.264 hardware acceleration on the platforms)


Jonathan Rosenberg’s Email to the IETF WebRTC working group mailer:

I’d like to make an announcement material to the conversations around MTI video codecs in rtcweb.

Cisco is announcing today that we will take our H.264 implementation, and open source it under BSD license terms. Development and maintenance will be overseen by a board from industry and the open source community.  Furthermore, we will provide a binary form suitable for inclusion in applications across a number of different operating systems (Windows, MacOS, Linux x86, Linux ARM and Android ARM), and make this binary module available for download from the Internet. We will not pass on our MPEG-LA licensing costs for this module, and based on the current licensing environment, this will effectively make H.264 free for use on supported platforms.

We believe that this contribution to the community can help address the concerns many have raised around selection of H.264 as MTI. I firmly believe that with H.264 we can achieve maximal interoperability and now, do it with open source and for free (well, at least for others – its not free for Cisco J)

More information on the open source project can be found at, which is sparse now but more coming soon.


Jonathan R.

Jonathan Rosenberg, PhD

VP, CTO Collaboration

Cisco Systems

Its high time Facebook, Youtube and other ad-based websites allowed us to remove ads by charging a modest fee…

You have all seen the now famous cartoon:


I know Facebook, Youtube and other sites all make money from advertising, but my feeds are becoming awfully spammy…. and so are those of my friends.

Now, these sites make money for ad impressions and click-thru, but I almost never click any ads…I have advertised using Google’s services before and per-click costs can vary widely, but based on my habits on Facebook, I can’t be generating any revenue except maybe four or five times a year.

How about charging me marginally more money than Facebook makes from throwing ads at my eyeballs, for turning off all this garbage in my feed?

For me I think $1.99 or $2.99 a month is actually more money than Facebook makes from me, and would be happy paying it.

For a $10 a month budget I could turn off ads on Facebook, Youtube and a few other sites, and I am all for it.

Even better, why doesn’t someone less lazy and with better connections than me negotiate deals with the top sites and offer ad-free as a service I can spend my $25 a month on: I can join Ad-Free and turn off ads on all affiliated sites, and let the money trickle through to them – to turn off ALL ads across my top sites…

C’mon guys, lets us pay our way out from all the garbage.

Mounting iPod Touch to the wall for easy-access controller…

We have a bunch of Sonos speakers around the house, but Sonos is no longer updating their controller software and pushing users to iPods/iPads/iPhones – which makes complete sense.

One issue with this is we need a replacement for the dockable controllers, and an iPod touch is a natural candidate.

Today I created a mount for an iPod touch using a blank faceplate, some neodymium magnets and an Apple mini charger…

I hot glued some big magnets to the back of the faceplate, and superglued some very low profile magnets to the back of the iPod touch. Watch out! As soon as those magnets on the iPod touch get near it they want to drift to the magnetic parts inside the ‘touch.

I soldered leads to an Apple mini charger and hit it in the electrical box behind the faceplate…


Mophe Juicepack Helium seems to interfere with iPhone inline mics

I have found a HUGE problem with my Mohpie JucicePack Helium. In essence, it disables the inline Mic in Apple and 3rd party headsets… exactly what you don’t want when walking through an airport… which is exactly when I want a JuicePack!

  • If I place my iPhone 5 into the Mophie Juicepack Helium, and then connect a mic cable, the mic is not active.
  • If I thread the cable throughout he juice pack mic hole and plug it into the iPhone and then attach the Juicepack, the Mic works.
  • As soon as you disconnect and reconnect the mic cable… blammo. Dead mic again.

This basically means the JuicePack either disables your Mic… or is a royal pain in the ass..

To test to see if your iPhone thinks you have a mic attached to your headphone cable, you can use my app here, called MiCheck. This app will tell you if the iPhone thinks there is an external Mic connected or not:



Is your JuicePack doing the same?

A better cable for your Vamp Verza + iPhone 5

The cable that comes with the Vamp Verza for an iPhone 5 is a short cable thats pretty standard. The issue is that if you have headphones attached, and you put this rig in your pocket or case, the short cable takes a lot of strain since its on the bottom of the phone, and the Vamp’s headphone socket is on top.

To make a MUCH sturdier cable, I used a Griffin micro USB cable for $12 as well as an Apple MicroUSB to Lightning adapter for $20:


Adding them together and looping them around to connect the Vamp is great, but they need some serious strain relief, provided by a zip tie:


Now the opposite is true when you remove the cable – it wants to push the connectors together, and you may lose the ziptie… so a little hot gluing later, I have a rock solid cable that blows away the POS standard cable:


Converting Ultimate Ears custom iPhone cables for JH Audio 13 Pros

Want a full iPhone compatible Microphone/Volume/Control cable for your JH Audio IEMs? The mic cable they sell only has the single control button as well as a Mac, and its HUGE:












Jerry Harvey’s old company, however, has a nice compact offering:









The issue here is that Ultimate Ears has a different plug/termination connector between the cables and the actual IEM… but it turns out, after testing the pinouts of the UE cable, it will work, it just needs a haircut…


So with my handy-dandy dremmel tool I carefully removed the plastic (which is a little “squishy” and not completely hard)

900x900px-LL-5de7e45e_DSC_4619 900x900px-LL-7e51fd39_DSC_4617 900x900px-LL-d4bc76d9_DSC_4615









If you’re going to do this yourself, a few pointers:

The connectors have a flat side and a side that bumps out to the cable:

DSC_4624 DSC_4621










I cut the sleeve off of the UE Cable at 90 degrees, but in hind sight, you want a slight angle where there is more plastic on the sides.





Ditching the Drobo

I was copying a file (2.5GB video file) to my Drobo locally, and according to the progress bar, the copy was happening at about 2.5MB per second.

On a FireWire 800 connection. To a 56% full drobo drive.

Ok, so I shut down, connected a western digital drive and tried the same thing. WAY faster.

Drobo tech supports claims that the Drobo array is completely healthy and is trying to convince me that I should be happy with this horrific transfer rate….

Here is the copy dialog when copying a file from my Mini server to an external WD hard drive over FireWire 800, a few seconds into the copy:


Here is that same file, that same FireWire 800 cable and a Drobo NAS:



10:00 – I’v been tot he store and picked up two G-Drive 4TB drives.

10:20 – SuperDuper is copying the contents of the Drobo to one of the G-Drives – the second will be a local Time Machine backup.

11:00 – About 40 minutes in, it looks like it will take over 100 hours to copy 2TB, where all the computer is doing is reading from Drobo. Xfer rate: 5.74MB/s far lower than the average of 70MB/s we SHOULD be getting from the Drobo.

4:09PM – Just figured out that with my Cable connection I can probably exceed 5MB/s download rate and should just restore from Crashplan.. Stopped copy, disconnected Drobo and restoring to new drive

Heading to Paris with XComGlobal

We are off to paris for the WebRTC conference…. with a MiFi with unlimited data in hand…

Rent and Avoid High Roaming Fees in 175 countries for a Low Flat Rate

Where would you travel with $5,000?
Enter XCom Global’s End of Summer Giveaway!

New Lightning Connector could support USB 3.0, not the end of the world.

The new preferred connector for Apple mobile devices was announced on September 12, 2012 after a long run of nearly ten years. The connector it replaces was first introduced in 2003.

Complaint #1: You’re making me ditch all my old cables, docks etc

Fair enough, we’re going to be forklifting a bunch of stuff… but lets keep some perspective… In that time the average mobile device from just about every other provider has switched at least once…from custom, to USB to Mini USB, to Micro USB etc…

So, in perspective while there is a change, and you’ll need to throw away all your old cables, or buy adapters… but based on their track record, those new cables should last you a long time.

Complaint #2: The new connector has 8 pins, while USB 3.0 has 9 – It can’t support USB 3.0 speeds!

The standard USB 3.0 spec includes 9 pins, but fear not – there is a duplicate ground on 4 and 7… so with the 8 pins of the Apple Lightning connector you absolutely could support USB 3.0 speeds:

Pin Name Description
2 D- Data -
3 D+ Data +
4 GND Ground
5 USB3_RX USB 3.0 Data Receive (differential)
6 USB3_RX USB 3.0 Data Receive (differential)
7 GND Ground
8 USB3_TX USB 3.0 Data Transmit (differential)
9 USB3_TX USB 3.0 Data Transmit (differential)

The real issue is whats inside the mobile devices.. and this current generation has USB 2.0 guts…


Get every new post delivered to your Inbox.

Join 426 other followers

%d bloggers like this: