A Hackable Media Player For HDTV

An anonymous reader writes "Embedded Linux and an open, hacker-friendly architecture power the world's first high definition media player, the $499 Roku HD1000. The brainchild of ReplayTV inventor Anthony Wood, the device could touch off a cottage industry of third-party applications and media packs that work with its Linux-based OS and user-friendly media APIs. Out of the box, the HD1000 can stream MPEG and MPEG2, play music, loop JPEGs, and more to an HDTV -- all at the same time. Roku is selling "Art Packs" of everything from museum-quality art to hot-rod cars as memory cards that work with the device. And, the company will release a C/C++ SDK for the HD1000 before 2004. Finally, there's something to actually show on your $5,000 54-inch plasma TV or 37-inch LCD TV." (Roku is also one of the companies mentioned in an earlier posting about using hi-def displays as digital art galleries).

Comments

Why no DVI output?

[ethank]

I don't understand why they would create a system to showcase HDTV sets and not include DVI output on the system? Most, if not all newer HDTV sets include DVI inputs in order to facilitate pixel-perfect representation on the screen.

I would buy one of these (once I buy my nice little 42" LCD rear-proj from Sony :) ) but with no DVI output I think my other plan of putting my G4 out in the living room seems like a better plan.

Xbox?

[Anonymous Coward]

A modded Xbox can do the same thing (play mpeg2, divx etc.) off dvd-r or streamed off the network with HDTV output up to 1920p. See www.xboxmediacenter.com and www.xbins.org/xbmp.php.

Re:Xbox?

[GrassMunk]

key word being *modded* which is grey area at best. This system is legit and requires no modding. Yes i love my XBMP but i would have rather had a system that was just easy and didnt take up more room than my receiver.( the xbox is HUGE ).

how is it controlled?

[zuzulo]

One key component that I did not see addressed in the article is how you control this device. Is there a remote that lets you interact with a TV friendly menu system?

This question arises because one of the main headaches associated with my current streaming media system (home built) is that using the wireless mouse and keyboard to navigate is difficult from a reasonable TV/audio viewing and listening distance ...

If they have addressed this issue at all, I will have to buy one. I would love to get away from requiring a full PC in my entertainment rack since all it does is stream data from my fileservers anyway.

And yes, I have tried other embedded devices, but most have proprietary OS, and linux ones do not generally support my specific set of audio and video requirements.

Who cares? It's still digital

[Namarrgon]

Optical, coaxial - whatever, it's all digital, boys & girls. The ones and zeroes - and therefore the sound quality - is the same.

The advantage of optical cable is it's immune to RF noise, but you'd have to live in an unusually noisy environment for it to be bad enough to corrupt a relatively low-speed signal like that. I used to run ordinary S/PDIF over 20m of cheap-ass audio cable (computer to receiver's DACs), and couldn't pick the difference between a CD played on the computer to one played on the local CD-player.

I have a friend with an overpriced stereo system that actually uses fully balanced AES cables to run the digital signal from his CD transport to the DACs, but even he admits that's pure overkill.

I'd be more concerned about the picture quality loss from using analog component cables - a DVI connector would solve that, as someone else has pointed out.

Re:story text (what a great product)

[Ed Avis]

Checking that enough memory is definitely available for a fork() wouldn't make the speed drop significantly; all the kernel must do is make sure the memory is available and mark it as used, not actually allocate it and map it into the process's address space. You can still have copy-on-write as long as the space is there in case you need it later.

You would need more swap space, with most of it sitting unused most of the time 'just in case', but I don't think this is too bad: 60 gigs seems like a too-big estimate. Something like ten times physical RAM would be enough, surely, and that is easily affordable on modern hardware. Again, having extra swap space available doesn't mean more swapping will happen - only that if the memory is used later, the reserved swap space is there ready for use, rather than getting out of memory and killing processes.

OK - for desktop systems and most servers I think it's reasonable to have overallocation. Certainly for fork() and probably for malloc(), although I would like a malloc_yes_really() call for writing daemons which need to stay running no matter what and which do their own out-of-memory recovery.

But the article was talking about embedded systems. These often don't have swap space, but do have software which is aware of the memory limitations and tries to do the right thing. It can't do that if the kernel plays games with memory allocation and pretends to have space that isn't there. So guaranteed memory allocation needs to be available as an option, even if it's not the default.