SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : C-Cube -- Ignore unavailable to you. Want to Upgrade?


To: Stoctrash who wrote (36163)9/23/1998 7:20:00 PM
From: Ron Mayer  Respond to of 50808
 
sw encode speculation

FredE wrote: <<speeds well above 500MHz and...caches of ...2 Mbytes>> ...

I would think half baked MPEG1 encode would be a year or two with a new high end machine....then maybe 3 years for MPEG2 encode??
HQ Broadcast type...5-7 years?

Were you thinking longer or shorter time frame??


I think you're right about depending on how flaky an encoder and how strong a machine.

I think "Flaky" is an interesting tradeoff between computation-power, image-quality, and amount-of-compression.

In spare time I was playing with tuning an encoder to today's machines by taking shortcuts on the encoding algorithm; and how much image-quality I can recover by just throwing more bits at it (not compressing as well). If bandwidth grows really fast (i.e. broadcom's 56 MEGAbit chip biz.yahoo.com, the amount of compression won't matter as much and this might find some market.

It'd be nice if it's flexible enough to specify any 2 of the 3 parameters (processing power, image quality, bandwidth) and have real-time encoder software make a best-effort attempt at the third.

I expect to see software like that in time for DVD-RAM to get cheap; though the quality will be worse than hardware solutions, but it'll be cheap so lotsa computer companies will use it anyway. [sounds familiar :-(]

Broadcast quality, highly compressed, real-time, etc I think will take longer to be done in software. Perhaps never because the definition of "broadcast quality encoder" may evolve (either in image-quality or pack-more-channels-in-given-bitrate) along with any improvements in encoders; and for real-time encoding, hardware should always be a little ahead.

(of course if current encoders contain a sparc or r3000 or javaVM today, the best "hardware encoder" architecture in 2005 may contain a 1GHz pentium-XXX with 8MB on-chip cache) :-)