Archived from groups: alt.tv.tech.hdtv (
More info?)
phil-news-nospam@ipal.net wrote:
> On Wed, 03 Aug 2005 15:02:24 -0400 Matthew L. Martin <nothere@notnow.never> wrote:
> | phil-news-nospam@ipal.net wrote:
> |> On Wed, 03 Aug 2005 13:16:51 -0400 Matthew L. Martin <nothere@notnow.never> wrote:
> |>
> |> |> As usual, you make up points. My point happens to be different than what
> |> |> you probably wanted to make. It seems you have no ability to see any other
> |> |> viewpoint besides your own, or to see all the bumbling design errors that
> |> |> the whole HDTV and DTV industry has introduced.
> |> |>
> |> |
> |> | Once again, thanks for pointing out that the real world implementations
> |> | that are already in place are all wrong. It's really too bad you weren't
> |> | asked your opinion way bach when. You could have just told them what to
> |> | do and everything would be perfect.
> |>
> |> Most of the issues can still be dealt with. For example decent displays
> |> can still be made that will natively operate in the major standard formats
> |> of 480i, 480p, 720p, and 1080i.
> |
> | Sure, they can be made, but why? There is no particular reason not to
> | scale all inputs to match the display's capabilities.
>
> Scaling has lower quality than displaying directly at that rate, unless
> the scaling is an integer ratio (for example displaying 480 as 960 is
> fine).
How odd. That's not the information I hear from people who actually
write scaling routines for a living. With a reasonable number of
significant digits and in real time, scaling artifacts for non integer
ratios have no more artifacts than for integer ratios.
If you doubt this, take a look at FFT and inverse FFT. I've coded these
and measured the THD of the results (for audio). Once the information is
in the frequency domain it is very easy to manipulate. Changing the
length of an audio segment without changing its frequency response is
pretty easy. The artifacts I measured were very low since I was using 64
bit floating point to caculate 16 bit samples.
> |> If they operate at all the frame rates,
> |> even better. This doesn't cost that much, as the computer display market
> |> has shown.
> |>
> |> A DTV tuner with an SVGA 15-pin connector for video output might be just
> |> the thing. Use your multiscan computer display and let it run each video
> |> format at its native, or easily doubled, scan rate. Tuners should NOT
> |> be attempting to do any complex conversions unless it _knows_ the display
> |> cannot do what it is getting over the air.
> |>
> |
> | Look, moron. They do know. All (as in _ALL_) STBs have selectable output
> | geometry. The intelligent user (unlike yourself who is neither auser or
> | intelligent) will set the STB to produce the geometry that looks best on
> | their display. The STB will then convert everything to match the output
> | geometry. Internal tuners don't need that setting for obvious reasons.
>
> This is proof that you post totally new things to attack people personally.
> A couple people have tried to defend you. They simply cannot in the face
> of your actual attitude problems.
Look, if you don't want to be called a moron, stop posting like a moron.
> | With reasonably good, and increasingly inexpensive, scalars it makes
> | good sense to have a simple display and a good scalar. This is
> | especially true for fixed pixel displays, a point you continue to
> | deliberately ignore.
>
> Good scalers in consumer products? An agile display is cheaper.
>
Once again you post proof of your ignorance. Please explain how a fixed
pixel display can be "agile".
--
Matthew
I'm a contractor. If you want an opinion, I'll sell you one.
Which one do you want?
/linuxhomepage.com/ http
/www.nabs.net/Cartoons/Dilbert/MoneyToConsultants.gif
Facebook
Twitter