# Monday, 29 December 2008

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!

Monday, 29 December 2008 22:40:11 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [1]  | 

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?

Monday, 29 December 2008 22:32:50 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Sunday, 28 December 2008

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.

Sunday, 28 December 2008 18:49:28 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Saturday, 27 December 2008

After an embarrassing incident of forgetting to bring a storage device with me when I was going to my cousin's place to copy something I decided I need to get a thumbdrive that I can carry with me everywhere I go so this doesn't happen again. So I went out and got this.


A small in size, yet big in capacity flash memory drive. And it seems like it's no slouch in the performance department too meeting Windows Vista's Readyboost Performance requirements. All this for a price of less than RM50... how far we've come in this area.

Anyway I decided I needed to keep this in my wallet's coin pouch, but the fact that it has exposed contacts means I needed some way of protecting it. A strip of duct tape and various failed experiments later I ended up with this.


A little protective sleeve for the drive, the entire drive just slips into the thing so that parts pretty well covered.

Who knows.. in a few months maybe I might be getting a 16GB or 32Gb one in this size.. and for the same price?

Saturday, 27 December 2008 14:47:58 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [0]  | 
# Friday, 26 December 2008

So I bought a RC car for WZ to chase around.




Pictures cannot express how nifty this is. It's time for a quick show, please install the Microsoft Silverlight 2.0 plugin to view the video below. Just click on the button you see below if the video doesn't show up to install it.

Friday, 26 December 2008 09:07:59 (Malay Peninsula Standard Time, UTC+08:00)  #    Comments [2]  |