Wow. So many incorrect facts in that article. This type of ignorance really annoys me. The author knows absolutely nothing about the topic and should probably stick to writing about something he is more knowledgeable on. *Total amateur hour*.

Let's go down the list:

1. To say that 28Mbit is the minimum because of a compression ratio of 107:1 just demonstrates pure and utter ignorance of how digital codecs work.
2. DVD movies are not '4-8Mbits'. The maximum standard transport bitrate is 9.8Mbit. The disc maximum bitrate is 11Mbit with a 1Mbit overhead to allow for device buffer compensation.
3. Over the air is not 19.38Mbits. ATSC is 19.393Mbits. DVB-T with QAM64 weighs in at 24Mbit (the author was almost right - just didn't know what country, transport, and modulation standard he was talking about). And then you factor in the other elementary streams in the transport. 18.2Mbits is probably the max you will get.
4. The article compares live broadcasts to VOD. Hey, let's just forget about the fact that VOD can be encoded with multi-pass. Same thing right? Jesus.
5. 50% H264 won't beat MPEG2 at 2x the bitrate? Must mean all MPEG2 encoders are built alike.
6. The math for DOCSIS user allocation to bitrate is completely wrong. Let's ignore edge device caching, multicast delivery to the edge, and statmuxing!
7. AppleTV's maximum bitrate is 5Mbits, but 99% of the time encoding at 4.85Mbits yields the optimum bitrate with the added jitter and packet overhead.
8. Microsoft's HD quality can in many cases surpass over the air (ATSC) MPEG2 1080i. Most stations are going exclusively 720p24, and running at 12-14Mbits MPEG2. Some as low as 9-10.
9. 6-8Mbits is actually a 'sweet spot' for 720p24H264 in many implementations.

And lastly HD is defined strictly by resolution, format, aspect ratio, pixel count, frame/field and associated rate. People need to stop pulling some bitrate out of their ass just to tout that as being 'HD'. It's not, and pertains to user *perceived quality*. It is irrelevant to the spec.

AppleTV *fails* because it has horrid gamma representation and low-quality image enhancement on the H264/MPEG4 decoding, which actually ends up over-sharpening edges and producing artifacts that ruin the image.

Everyone criticizing this functionality doesn't realize that it is the first of it's kind commercially for a CE DVR (it's been around for years if not over a decade for professional gear though).

When you schedule a program to be recorded a packet is carouseled via true one-way push over the bird to your receiver. There is no two-way network here. You can't just slap a webserver on one end and call it quits.

Now maybe DTV can make this really useful and allow PPV recording over the air, and start datacasting other content to receivers.

I suspect their '5 minutes' comment is marketing drone speak for 'I don't really understand how this technology works'.

One instance where that would make sense would be in the case of a higher-bitrate data carousel carrying say the top 5 movies chunked up to facilitate 'instant on'. The carousel iterations may require a minimum of 5 minutes at datarate x for the box to aquire enough data chunks to start playback without fear of hitting a buffer underrun. My experience in this has been that this concept is a pipedream.

The other possibility is that they continuously trickle content to the box and send metadata announcements in an ancillary channel that has a announce time of 5 minutes. The maximum lead time from receiving the entire file to the first decode of new metadata would then be 5 minutes.

Pre-selecting items from a carousel is novel yet not original. The advantage is that the user can manage content. The disadvantage is that the lead time to obtain item B when eliminating item A is not decreased. Best to give them the illusion of queue management by simply hiding what they see on the OSD, and not what is on the drive (so when they change their minds, that 'old' content is suddenly instantly available).

This box is just another Moviebeam push device. Too late to market and doomed to failure -- unless they plan to implement broadband on the box from the get-go to dynamically populate the box using sat for popular content and broadband for user-NVOD.

Come on guys, how about some simple research. XStreamHD engineering management are ex-HNS and iDirect. Job openings call for FEC code, prepackaging content at the headend, RTP/RTSP experience, and satellite modem integration.

Obviously they are going to use a trickle delivery mechanism to get content onto the box, and local LAN RTP/RTSP streaming to ancillary STBs from the central receiver.

No-one at the consumer level pulls content using sat modems, there just isn't a business case for implementing turbo internet anymore.

Good god if you're going to post news at least read up on the technology you're dealing with. NACK implosion wrt network scalability for consumer rollouts is fundamental knowledge when it comes to data delivery over satellite.

Interesting that they are reinventing the wheel for so many pieces of their puzzle. I would venture to say rather stupid, as well, given the failure rate of systems doing this in the past (Moviebeam, Cyberstar, iBlast, Geocast, ...).

Entered!

1-6 are not shifter controls. A standard feature of premium sound systems in BMWs is a *6-disc CD changer*.

These all look like new design prototypes for iDrive controllers with enhancements for music control. That's the biggest problem I have with the current iDrive controller - having to reach to the dash for some functions.