What a way to start a year...

First of... fancy making your Nokia Series 60 phone unable to receive any SMS until a full factory reset? Check out this dangerous exploit.

Next... Microsoft Zunes are dying with no explanation on 12AM 31st December 2008.

Lastly... is Steve Jobs really critically ill? That would be bad...

Wow.. it feels like only yesterday that I wrote my 2007 gear roundup... then the server died and I nearly lost my whole site! This time I have backed up my site already!

Cool thing about having a blog is how you can go back and reflect on what you were doing a year ago. So let's see what was I up to for 2008.

Most important purchase of the year would have to be my first DSLR camera. The Sony Alpha 350.

Thumbdrives got so ridiculously cheap I lost count of how many I bought.

An interesting piece of gear, which I find indispensable in recording gameplay videos and other things is the Pinnacle Video Transfer unit.

I bought quite a few figures.. like Haruhi here. Here's to hoping I don't get anymore.

There was a sudden increase in desktops in the household as I got some MiniITX based units like this for running Windows Home Server and other misc chores.

And of course... I haven't broken the curse of getting one new phone a year.

Happy New Year everyone! Here's to hoping 2009 is not as bad as it's looking right now!

One of the things that people tell you is that, if you're gonna make an online video, try to keep it under 10 mins or it's most likely the viewer is gonna get bored. I'll keep that in mind the next time I record a show with Yoroi, but how was I to know that just pointing a camera at ourselves and talking about the Sony Playstation Network was gonna take 17 minutes! (here's a tip, once the gameplay video shows up,hit the play button to pause live viewing of the stream to allow both streams to download completely so you can watch it without fear of breaking sync between the streams)

The other problem was that because we rely on 2 video streams, if we wanted to chop up the video, we'd need to make a few more sync points on the video itself. Which we didn't have... when we recorded this almost 30 MINUTE Xbox Live video.

We sound like 2 tired drunks because we were worn out trying to get the PS3 working for our recording, I'd detail the problems we had but then the fanboys would start crying foul!

I've made a few references to the Silverlight Streaming Service a few times before on my website but I never quite explained what it is before. A lot of people thinks that the Silverlight Streaming service (SLS) is meant for hosting and streaming videos that are delivered via a Silverlight based video player. And thus when people go to the website they're expecting to see something like YouTube or some other video service.

But SLS is NOT JUST for hosting videos, it's meant for hosting Silverlight Applications. With Silverlight, a content creator is able to create rich interactive applications and media experiences which of course can be hosted on their own server of choice. But then, bandwidth issues come into play. Take for examples the various video podcasts/reviews/shows  and deepzoom albums I have on my site. Like any other web content I could have just hosted the files on the server itself. And that would mean that people from around the region would be able to retrieve and view the files very quickly because the server is close to them.

But... what if the viewer was from another geographical region? What if my webhost's network pipe is being throttled or consumed by someone else who is being hosted on the same server network? As an independent developer while I am able to make rich media content, I do not have the ability to host the content on some super fast, globally distributed server network.

And that's where SLS comes into the picture. As I mentioned it's not just meant for videos but entire Silverlight Applications (this includes everything on the client side ie. Your XAP file, any additional resource files, images, sounds, etc. etc. The service is not for hosting backend applications such as ASP.Net)

How SLS works is that first you upload your application files to the service and then you use the HTML tags (typically an iframe) to refer to your application. Then when a browser requests for the application, that's when the magic happens, SLS has a bunch of distribution nodes around the globe, when a request for content comes in the content is blasted via a high speed network into the distribution node closest to where the request is coming from and the content is served from that node.

This technique in theory allows most users to be able to grab the content at an efficient rate since the content will be coming from a server that's closer to the user.

There are 2 problems with this approach though, the first is a minor issue. Because the content is cached in the distribution node, any changes that you might upload (ie, replacing the XAP or an image file) might not be immediately visible to you.

The 2nd problem is much more of a headache that someone realized over at the Silverlight forums. Because the distribution nodes are given unique URLs and identifiers, if you use Isolated Storage in your Silverlight application, it's very likely that everytime a user hits the page, they'll never be able to read back their previous settings.

But other than those 2 problems, I'm happy with SLS. I'm glad that it is able to deliver my video shows on a steady bitrate. Though I do wonder what's the experience like for people outside of our region?

One of the things which I realized when I made my YTBNSystem was that I needed to calculate the proper amount of bandwidth required for the best viewer experience. It's a very easy case for the single video streams (such as the one that featured the wall climbing car), the video is encoded for 350kbps which most people are able to obtain as long as their line isn't too busy working on some other transfers, not to mention, in a single video stream scenario it doesn't really matter if the video needs to be buffered the user experience isn't affected that much.

But when I want to display 2 video streams together, I need to find the most ideal bandwidth capacity that'll allow the videos to appear as if they were playing in sync.

So I sat down this morning, and starting testing out some encoding profiles, and I came up with this.

What I realized was that whenever I had a situation where I needed to display 2 video streams, the primary one is usually not important and thus can suffer loss in image quality and because it's just speech, the audio quality can also be dropped. But the supplement video would require a higher video and audio quality cause the user's main attention would be on the supplement.

So right now I've decided on these values

• Main video stream : 125kbps video data, 16kbps mono audio data 16khz sampling rate.
• Supplement video stream : 200kbps video data, 20kbps mono audio data 22.05khz sampling rate.

So the number still comes up to be about 350kbps, why did I settle on this number? Because I found that my line is capable of streaming a 350kbps video without it having to buffer, if it works well on my measly 1Mbps line, should be fine for most streamyx users.

Maybe I can go higher, but that's testing scheduled for another day.