Date: 17 Nov 1996 21:43:58 -0800 From: pete@news.interworld.net (Peter Carah) To: freebsd-isp@freebsd.org Subject: Re: bang bang bang bang - lame lame lame lame Message-ID: <56ot2u$6kh@news.interworld.net> References: <199611131751.LAA23456@brasil.moneng.mei.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <199611131751.LAA23456@brasil.moneng.mei.com>, Joe Greco <jgreco@brasil.moneng.mei.com> wrote: ><someone else: >> So, while the telcos beat their heads into the wall trying to figure >> out some way of getting their cooshie monopolies back, I was >> thinking... >Well, let's see. >16M color support would require 3 bytes per bit, and at 786432 bits >per screen and 30 frames per second that is 70,778,880 bytes per >second. The MPEG advocates will try to convince me that they can >reduce that by an order of magnitude, so at 7,077,888 bytes per >second, that is hypothetically possible from a strictly network >bandwidth point of view. OK - I happen to work in MPEG compression; we routinely do cable TV compressions at 3.5mBIT/sec (picture only, at 1/4 frame (320x240) res; full NTSC res takes only about 4-5 mbit/sec for surprisingly good quality on most material. DSS is normally running at less than that for both pix and audio combined (and can be varied at will by the uplink folks :-). Double res in both dimensions won't increase the mpeg stream bit rate by 4x for equivalent visual quality. (also for movies, consider how many folks are satisfied to rent EP VHS tapes; 4mbit 1/4 res mpeg is usually better looking :-) Much mpeg encoding does take advantage of the fact that the real frame rate often isn't 30fps; it is 24 for all (current) movies and many other non-sports programs.. (and NOT 30fps for live video; you have to encode the fields separately so you get 60fps of half-res frames. Guess why DSS charges more for good sports time...) (D1 digital video is about 280mbits/sec, but if you really only send 24fps and 720x486 with subsampled color, it comes out to 134mbits at current byte sizes; so mpeg is getting 2-3 times better than 10% of this.) >To decode it in real time, however, and display it, would probably >require a very very fast machine... Now talking of NTSC or PAL resolution - IBM has a single chip decoder and 2 or 3-chip encoder at full video rate and resolution; The max encoded rate for that one is around 40mbits (per their web site; it's a little hard for me to believe). Normal encodings are around 4-5; CDI uses 1.2 mbit mpeg1 (and looks pretty bad accordingly)... Several others make similar chipsets. If you try to decode mpeg in a gp computer, it'd better be blazing fast, though; I do sample decodes on a (Ross-equipped) sparc 20 and get just over a frame per second using the "reference" mpeg2play. The asic's do lots of things in parallel. The expensive part would be the display itself. Remember the only part of our computer systems that hasn't come down by half in the last year or two :-) Your 1024x768x16mx60hz display will be several hundred $ by itself at 15 inch, and _lots_ more if 27 inch. >Lower resolutions might be much more workable. Conventional television >is much lower resolution than 1024x768. 720x486 for component digital and 646x486 for square-pixel digitized "analog". Comes out to 700k (8 or 10 bit) bytes per frame in 4:2:2 component digital, uncompressed. (4:2:2 is a fancy code for undersampled color and interlaced luminance :-) Double that res would probably be workable in a single-chip decoder in today's asic technology; ask the folks working on HDTV. Encoders are another story. -- Pete
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56ot2u$6kh>