Present Perfect

One day we got a call from one of our customers across the globe who stream a wildlife channel. They told us that, instead of a broadcast of their channel, which was embedded on their home page, there was now an adult channel in its place. A very different kind of wildlife channel... Could we fix it as soon as possible?

I was pretty worried, because if it were our mistake that would be pretty embarassing. So I asked Zaheer, our resident DVB expert at the time, to investigate.

After a lot of debugging and head scratching he told me that there was nothing wrong on our side - the channel that was configured to capture was in fact an adult channel. In the end, we looked up the satellite channel names again, and then we noticed that our customer's channel was not in the place where it used to be. Apparently it had changed PID.

When we told them what happened, they told us, 'Oh yes, you are right. We got a notice from our satellite provider a few months ago that the number would change but we forgot all about it...' They didn't think to warn us.

I was just happy it wasn't our fault after all!

One day we got a call from one of our customers across the globe who stream a wildlife channel. They told us that, instead of a broadcast of their channel,...

Well, the cat has been out of the bag for a few days and I have been too busy to blog about it.

But today as I wait for my team to do a final deploy fixing a bug with too-long URL names for Flash Media Encoder, I have some spare time to mention what's going on and make some people an offer they cannot refuse.

So, for the past half year of so we've been hacking away at a new service to solve a very specific problem in streaming. From 2005-2010 the streaming world mostly settled on Flash as a common platform, which was an unstable equilibrium for everyone involved, but it seemed to work. However, with the amount of codecs, devices and platforms there are today, this equilibrium has been falling. The introduction of iPhone, Microsoft's heavy pushing of Silverlight (paying companies to stream in it - and funnily enough those companies usually stop using Silverlight when the money faucet closes), GoogleTV, the introduction of WebM, the arrival of HTML5 (ironically pushed by Apple - yay - even though their HTML5 sites usually only work in Safari - boo)... all these movements served to upset the status quo once again.

To the eye of the casual observer, it would seem that all streaming has standardized on H264, and so transmuxing technologies are popping up - taking the same video encoding and just remux it for different technologies. However, in practice, H264 is a collection of many techniques and profiles, different levels of complexity, and not all devices support the same profiles and techniques. If you want to stream to all H264 devices with just one encoding, you'll have to settle for the least common denominator in terms of quality, and you'll have to pick a resolution that works subpar for all of them.

Now, content producers hate this sort of situation. They just want to get the signal out there, because that's what matters. The codec and the streaming is just the technological means to get it across the internet. And now the market is asking them to put a bunch of machines in their facilities, learn a lot of technologies they'd rather not worry about, consume heaps of bandwidth to send each version online, and then have to do it all over again each time something changes out there - a new codec, a new device, a new favorite resolution, ...

Our answer to this problem is simple: send us one encoding, we will do the rest. Our service will take your live stream, transcode it to as many different encodings as you want, and hand them off to a CDN. That's basically it. Want full HTML5 coverage ? We'll do it for you - H264 single and multibitrate, Theora, WebM, and a Flash fallback. Want Silverlight, Flash RTMP, Windows Media MMS ? All there.

Services like this already exist for ondemand - see zencoder and encoding.com and Panda. Live is just inherently more difficult - you don't get to work with nice single finished files, and it has to happen right now. But this is exactly the sort of thing a framework like GStreamer is good for.

In reality we aren't doing anything new here - Flumotion runs a CDN that already provides this service to customers. The difference is that this time, you will be able to set it up yourself online. A standard integration time with any CDN is around two weeks. This service will cut that time down to five minutes. We're not quite there yet, but we're close.

What's that you say ? Something about an offer ? Oh, right. It's always pained me to see that, when we wanted to stream a conference for free, it was still quite a bit of work in the setup stage for our support team, and hence we didn't stream as many conferences as I would have liked to. Similarly, it pains me to see a lot of customers not even considering free formats.

So the offer is simple. If you are running an event or a conference that flies under a Free/Open banner, and you're willing to stream only in free formats (meaning, Theora and WebM), and you're willing to ride the rough wave of innovation as we shake out our last bugs, we want to help you out. Send us the signal, we'll do the rest. Drop me a line and let's see how we can set it up. Offer limited, standard handwavy disclaimers apply, you'll have to take my word for it, etc...

If you're in the streaming industry, I will be demoing this new service next week on Wednesday around 2.00 pm local time in New York City, at Streaming Media East. And after that our Beta program starts.

Feel free to follow our twitter feed and find us on Facebook somewhere, as the kids these days say...

Happy streaming!

Well, the cat has been out of the bag for a few days and I have been too busy to blog about it. But today as I wait for my...

Our team is working on this great new system. It's really cool even though I can't say much about it. They've been surprising me with some inventive stuff. I saw a cool testing tool last month that allowed simulating the whole system on one machine, and it worked, and it detected bugs in the code that they were then able to fix and test again.

But we can't find a good QA engineer to come help us make this thing really rock. Most QA curriculums I get are written in .doc or .docx, show the person having only very vague Unix knowledge, and think Python is a snake best stayed away from.

We contracted a QA consulting company, and after a four day audit they concluded that we were not doing a simple web framework and they did not have the skills to test our system.

I'm sure there's a great QA engineer out there eager to test our multi-datacenter multi-server cluster system doing cool stuff, with some QA experience, some SCRUM experience maybe, some Linux experience please, and some Python experience if possible. But most of all, with a desire to learn, and some capability to start out on his/her own in one project and slowly grow a QA team from the inside out.

Come on, I know you're out there. Send us a mail!

If you're interested, here's the job description.

Our team is working on this great new system. It's really cool even though I can't say much about it. They've been surprising me with some inventive stuff. I saw...

For work, I'm re-reviewing servers and systems with the simple-but-not-easy goal of lowering the basic monthly cost per core. The world of racks, servers, CPU's and cores is a more complicated place than it was a few years ago, since in a few U's you can put anything from a bunch of small cheap servers up to monster boards with four CPU sockets and 12 core CPU's for a total of 48 CPU's in a 2U space. And a look at a Blade system still makes me drool, although I'm still not sure in what case a Blade really makes sense.

In any case, I tried to do a little comparison (which is hard, because you end up comparing apples and oranges) using Dell's online configurator.

On the one hand, filling racks with Poweredge R810, 4 x 8 core 1.86 GHz, Intel XeonL7555 machines, gets the price down 26 euro per core per month. Doing the same with Opterons, which surely aren't as powerful as the Intel ones, I can get a Poweredge R815, 48 cores quad Opteron 2.2 GHz, 6174, for 48 cores total, at 9.53 euro per core per month.

And then I thought a Blade would be an even better deal, but it turns out that it isn't really. The cost per core, with similar CPU's, really did come out pretty much the same as the R810 based solution. Probably not that surprising in the end since if you fill a machine with cores, the CPU cost will start dominating. But somehow I thought that Blades would end up being cheaper for maximum core power.

Maybe I'm approaching this the wrong way ? If the main concern is cost per core in a datacenter, how would you go about selecting systems ?

For work, I'm re-reviewing servers and systems with the simple-but-not-easy goal of lowering the basic monthly cost per core. The world of racks, servers, CPU's and cores is a more...

Dear interweb,

recently I've been doing a bunch of thinking on how to have productive developers. We've been having some discussions on the topic on the business side, and there are things that I take for granted that aren't always as obvious to the more commercial side. Things like, 'flow is the most important part', 'context switches should be avoided', or 'a 3 month deadline for development with 1.5 months of testing/deployment/... can be given double the development work with only 50% more time'.

So I started thinking it would be nice to be able to give a quick presentation to those people, explaining some of the basic concepts they should consider, and references to back it up (studies, papers, ...) that give some weight to the argument beyond 'trust me, I know because I'm a developer'.

I went out googling for something like this but I didn't find anything, possibly because I don't know what to look for. It seems like something useful for any kind of technical/dev manager.

If you have an idea, please let me know!

Dear interweb, recently I've been doing a bunch of thinking on how to have productive developers. We've been having some discussions on the topic on the business side, and there...