[opendtv] Re: Mediaflo Technology
- From: Mark Schubin <tvmark@xxxxxxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Fri, 10 Nov 2006 17:53:13 -0500 (GMT-05:00)
You are correct that Nyquist requires frequencies to be less than half the
sampling rate, but 441 for 440 would satisfy Nyquist. I rounded.
As for the sharp edges, mathematically, you are correct that they imply higher
frequencies, but they are a function of the display. If a display pixel gets a
value of, say, 126, it makes the whole pixel that value, from edge to edge. An
analog display will spread the energy over a broader area, but the peak will be
narrower, and it will be brighter (or darker, depending on the value) than the
surround. That analog peak can occur ANYWHERE in the analog line. Digital
pixels can occur only where their grid allows them to occur.
TTFN,
Mark
-----Original Message-----
>From: Tom Barry <trbarry@xxxxxxxxxxx>
>Sent: Nov 10, 2006 4:41 PM
>To: opendtv@xxxxxxxxxxxxx
>Subject: [opendtv] Re: Mediaflo Technology
>
>Mark -
>
>I think in order for nyquist to apply properly (such that you can calc
>with it) you would have to have the lines fading back to white and back
>in a sin wave, not with sharp edges which already imply higher frequencies.
>
>And the Nyquist limit for that for, say, at 720 pixels would have to be
>LESS than 720, say 718 lines or 359 complete cycles. But I believe a
>Fourier transform of these 359 (sinusoid) line pairs using 720 samples
>would indeed capture all the information, regardless of phase. So you
>would not have the blinking effect as something scrolled very slowly, or
>the confusion of motion compensation due to aliasing. And if you
>upscaled the subsequent sampled (but nyquist limited) image you could
>still get an exact representation of the original. But, again, this
>assumes the magnitude of the signal AT the Nyquist frequency and all
>higher frequencies was originally zero.
>
>Unfortunately I'm not sure the convenient discrete cosine transform used
>in the various MPEG's has this property. And turning things into a 8x8
>block based transform further limits the resolution to 7/8 of the
>nyquist frequency, much worse than my 359/360 in my example above.
>
>Of course all this is only an approximation since all the sampling
>theory assumes we are talking about a periodic waveform, which in turn
>probably implies the real original image (at much larger resolution)
>really contains only integer multiples of the sampling frequency. And
>that isn't generally true in any real image anyway.
>
>This means I'm still not so sure about the difference between digital
>and analog in this regard. It's hard to get a grip on some of this stuff.
>
>- Tom
>
>
>
>Mark Schubin wrote:
>> Consider a pair of vertical lines, one black and one white, each the
>> same width as a digital pixel. An ideal digital system would just
>> barely be able to reproduce them (they'd be at the Nyquist limit). An
>> analog system of the same Nyquist bandwidth would also reproduce them,
>> though sinusoidally instead of as black and white stripes.
>>
>> Now shift the lines one-half pixel horizontally. The analog system has
>> no trouble moving the sine wave by a 90-degree phase shift. The digital
>> system, however, is now all gray. Each pixel is getting both a black
>> value and a white value.
>>
>> Thus, Ron's 440 pixels per line actually compares favorably to a digital
>> system with 880 (which is more than Rec. 601's 720).
>>
>> TTFN,
>> Mark
>>
>>
>>
>> Tom Barry wrote:
>>
>>> I'm not sure I understand that. I thought a properly sampled signal
>>> with only Nyquist frequencies could accurately represent the input
>>> signal even in the face of shifting the image left or right a
>>> fractional pixel. Is that different in analog?
>>>
>>> Or is that not what you are referring to?
>>>
>>> - Tom
>>>
>>> Allen Le Roy Limberg wrote:
>>>
>>>> Comparing resolution of analog and digital systems on a pixel per
>>>> line count
>>>> ignores the important fact that edge position resolution is not
>>>> pixel-bounded in the analog transmission. No quantum shifts as in a
>>>> digital
>>>> sampled-data transmission.
>>>>
>>>> Al
>>>> ----- Original Message ----- From: "Craig Birkmaier" <craig@xxxxxxxxx>
>>>> To: <opendtv@xxxxxxxxxxxxx>
>>>> Sent: Friday, November 10, 2006 11:22 AM
>>>> Subject: [opendtv] Re: Mediaflo Technology
>>>>
>>>>
>>>>
>>>>> At 11:02 AM -0500 11/9/06, Mark Aitken wrote:
>>>>>
>>>>>> In-line response.
>>>>>>
>>>>>> Craig Birkmaier wrote:
>>>>>>
>>>>>>> 14 live streaming national interest
>>>>>>> 5 live streaming local interest
>>>>>>>
>>>>>>> 50 national and 15 local services that will deliver ~20 minutes of
>>>>>>> content per day to receiver cache.
>>>>>>
>>>>>>
>>>>>> What does local mean?
>>>>>
>>>>>
>>>>>
>>>>> I presume that this is content that is localized to the specific
>>>>> transmitter - for now it looks like Mediaflo will have one
>>>>> transmitter per market served; later they claim they will build out
>>>>> SFNs around markets. There is more detail about the service
>>>>> opportunities in the resources on the website, however, it is
>>>>> important to note that MediaFlo is NOT the operator of the system,
>>>>> per se. They are offering the service to existing system operators in
>>>>> each market as an adjunct to a cellular service. The operator in each
>>>>> market will have a strong say in what is carried, and the ability to
>>>>> partner with local content providers within that market to fill the
>>>>> "local" channels.
>>>>>
>>>>>
>>>>>> NTSC is 'effectively' 320 x 240? Really?
>>>>>
>>>>>
>>>>> You could argue that there is more horizontal resolution, but not
>>>>> vertical resolution The cable guys started out with 1/2 D1 MPEG-2
>>>>> encoding, which was 352 samples per line. I looked at several sites
>>>>> about the horizontal resolution of NTSC and the consensus sees to be
>>>>> about 330 dots per screen width when transmission losses are taken
>>>>> into consideration.
>>>>>
>>>>> There are two factors at work here:
>>>>>
>>>>> 1. Transmission bandwidth - Ron did the math to show what is
>>>>> "possible " if you can receive an NTSC signal perfectly. About 440
>>>>> pixels per line. The 240 pixels vertically does not take into account
>>>>> any positive benefit from "the interlace factor," which could add a
>>>>> bit more vertical detail, however, with Mediaflo, the signal must be
>>>>> de-interlaced for encoding as 320 x 240 progressive frames, thus it
>>>>> is unlikely that any additional detail will make it through the
>>>>> conversion process.
>>>>>
>>>>> 2. NTSC displays - the typical NTSC receiver has no more than 330
>>>>> dots/stripes per screen width. With higher quality tubes (usually
>>>>> with S-video inputs) the number of dots/stripes may increase to
>>>>> approximately 450-500.
>>>>>
>>>>> Bottom line, you are wasting bandwidth if you are inputting more than
>>>>> 480 samples per line into an NTSC encoder. We can use the full 704
>>>>> samples per line (ATSC) if we are encoding for DTV, but even here
>>>>> this may be overkill if we don't provide enough channel bandwidth
>>>>> (bit rate) to assure that the detail makes it through the encoder.
>>>>>
>>>>> MediaFlo says that the input source for their network will be
>>>>> primarily from satellite, and they expect MPEG-2 encoding at 704 x
>>>>> 480 or 720 x 480. If this stuff is not overly compressed, there
>>>>> should be enough detail left to produce a much higher quality 320 x
>>>>> 240 progressive stream than would be possible if one started with
>>>>> NTSC source (analog or encoded using MPEG-2).
>>>>>
>>>>> This all brings back memories from the early '90s when we noted that
>>>>> a properly encoded 480P signal (i.e. 854 x 480) would provide a very
>>>>> high quality viewing experience comparable to HDTV on many consumer
>>>>> displays.
>>>>>
>>>>> How quick we forget how poor NTSC quality actually is...
>>>>>
>>>>> Regards
>>>>> Craig
>>>>>
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>> You can UNSUBSCRIBE from the OpenDTV list in two ways:
>>>>>
>>>>> - Using the UNSUBSCRIBE command in your user configuration settings at
>>>>
>>>>
>>>> FreeLists.org
>>>>
>>>>> - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
>>>>
>>>>
>>>> unsubscribe in the subject line.
>>>>
>>>>
>>>>
>>>>
>>>> ----------------------------------------------------------------------
>>>> You can UNSUBSCRIBE from the OpenDTV list in two ways:
>>>>
>>>> - Using the UNSUBSCRIBE command in your user configuration settings
>>>> at FreeLists.org
>>>> - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the
>>>> word unsubscribe in the subject line.
>>>>
>>>>
>>>
>>
>>
>> ----------------------------------------------------------------------
>> You can UNSUBSCRIBE from the OpenDTV list in two ways:
>>
>> - Using the UNSUBSCRIBE command in your user configuration settings at
>> FreeLists.org
>> - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
>> unsubscribe in the subject line.
>>
>>
>
>--
>Tom Barry trbarry@xxxxxxxxxxx
>Find my resume and video filters at www.trbarry.com
>
>
>----------------------------------------------------------------------
>You can UNSUBSCRIBE from the OpenDTV list in two ways:
>
>- Using the UNSUBSCRIBE command in your user configuration settings at
>FreeLists.org
>
>- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
>unsubscribe in the subject line.
>
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
