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) :-)