Archive for February 2009
Progressive download CPU consumption
As progressive download consumes more CPU than streaming, I’ve decided to research this issue further.
I’ve implemented a possibility to throttle the bandwidth used for the progressive download. The throttling happens on the client side, by inserting some Thread.Sleeps in the loop where the downstream is being repeatedly read in a memory buffer.
And I could measure the following CPU loads:
|
Progressive download
(unconstrained)
|
40%
|
|
Throttled to 6mbit/s
|
28%
|
|
Throttled to 2mbit/s
|
23%
|
|
Throttled to 1mbit/s
|
18%
|
|
Adaptive Streaming
|
10%
|
In the adaptive streaming case, I believe, it is not only their more optimized download loop implementation, but also the fact that they use MP4 container format instead of ASF can play a role. Alex Zambelli describes Smooth Streaming Architecture in his blog (Smooth Streaming is an alias of adaptive streaming).
I will also test CPU consumption for the same movie when it is being streamed via Windows Media Services, when I obtain a new test server.
Video delivery
An excellent article describing in few short chapters many available video delivery technologies (different kinds of streaming and progressive download)
The only technology not (yet?) described is the Adaptive (aka Smooth) Streaming.
Working off requirements
People are different. I have to think about this axiom every time I see a statement I can’t apply for myself.
One of such statements is a wish to get ideal software requirements and to work them off, preferrably left alone.
Every time I’ve tried this approach, a produced a dead-born something, that has corresponded pretty much to the requirements, but nobody wanted to use it.
I’m confident, it is not a coincidence.
As a product owner, you know what a successful application must look like. You can communicate these requirements explicitely and verbally, or implicitely and non-verbally.
In the latter case, you have to make the developers to share your vision. When you succeed, they will evolve (even better and more complete) requirements on their own. In the former case, the communication channel is rather limited and too one-way-ish.
Without perfect knowledge, what exactly will make the app to success, developers will create just some set of bytes, albeit perfect in its internal architecture, but otherwise useless.
Making successful apps is more important to me than making apps with clear architecture.
