1) The DisplayLink 160 chip. Running uncompressed screen information
is an
OK solution, but of course it requires more hardware to actually
decode in real
time. My 3 Ghz dual core can do it, but I doubt all the interested
consumers have
that kind of power (many do, yes, but laptops are getting more
popular). Still
something to consider.
I've been thinking about this one. At first it seemed like having a
lossless compression would provide a great solution that could be used
for anything (video, CAD, games, ...). But it has some disadvantages.
We'd have to decode in the host computer, then reencode in the
DisplayLink's lossless codec. So it is less efficient. Then I
thought, why couldn't we use one of the video decoder chips in the
Ethervideo box, and have the host computer encode CAD/game/whatever
output into mpeg? The video case would be more efficient, and the
CAD/game/whatever cases wouldn't be any worse, modulo whatever
differences
there are in codec encoding overhead. Plus the small detail that the
current DisplayLink chips apparently do not support 1080.
Yes, very good point. I hadn't thought of just packaging in MPEG --
that sounds
like a better support-all solution.
No 1080 = no fun. The 160 is not out yet. Do we have an ETA?
3) The 900Mhz TI DSP. This looks fantastic! 7200 MACs, only $70, etc.
Is it fast enough?
I am probably going to start the crunching later this week, unless
somebody
else already has? For now, I think it is safe to assume color
transform and
8x8 IDCT in FPGA hardware. Besides that, we can't assume that
anything is
"free."
4) The Ambarella chip. This looks good, is low power, etc, but I
imagine it would
be more useful in an application that uses the encoding and
processing. We can
easily adjust our requirements to support this, however -- I linked
to an Engadget
article a while back with a bunch of people commenting that they
would buy a
PCI H.264 encoder accelerator in a second, and I don't see how an
ethernet one
is any different.
There is a market for a HD encoder. Some people want to be able to
take component output from a cable/sat box and timeshift it. I'm
not sure how large this market is.
With most major (sat/cable) companies already supporting DVR, it
probably
isn't strictly needed. It would be nice, however. Some people might
want to
use it to process video for web sending. Compressing a 15 minute video
from DV to 320x240 took upwards of 20 minutes on my laptop, and being
able to speed that up would be a market for YouTube posters. Heck, maybe
even video producer would have a useable linux environment at that
point.
I think the market for an
inexpensive decode box will be large.
Yes, as evidenced by the Apple TV and competition.
Do we have an idea of how
much extra it would cost to add encode?
Well, $247 - $40 = $200 minimum for ASIC (we could probably reduce this)
The point is that it is a lot.
If we use DSP + FPGA, it is free (development time). Go programmability!
I don't know if there are any other parts of encode that could be
sped up with
hardware (color transform? DCT?), but the advantage is that it
doesn't have to
be real time, just fast(er than a CPU).
The Fujitsu chip at $247
seems spendy, are there less expensive encoders? $247 would make
the box too expensive for people who only need decode.
It would also limit us to people who cared about FOSS -- with the
apple TV
and similar costing less, we won't be able to compete. I suggest
finding a
different option.
5) The broadcom chip (BCM7412). This in again a nice SoC solution.
Yes, the Broadcom chips look promising. Under $40 for the
BCM70010/BCM70012 sounds workable, and for our app we might not
need both chips, so it might be even cheaper. Do we have a price
for the BCM7412?
I couldn't find one on the Broadcom site. I can keep looking.
Another thought I had -- will we have a hard drive or support USB
storage?
Nicholas
_______________________________________________
Open-hardware-ethervideo mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-hardware-ethervideo
