[John Mason]

What happens to 1080i HDTV program signals before they reach our STBs? I'm referring to the frequently mentioned ~1400(?)-pixel horizontal resolution limit for OTA signals.


Say, for example, a station wanted to deliver a full 1920X1080i static test pattern with a typical MPEG2/ATSC encoder. Could the encoder deliver the full resolution without artifacts to a 1920X1080-capable display? What happens with a live broadcast or D5-tape full-motion programming signal that fully 'stresses' MPEG2 encoding? If it's done, how is the encoder restricted to ~1400(?) to prevent artifacts?


Anyone know of websites, say, the operating manual for an encoder, that spells out such limits/adjustments? Thanks. -- John

 

[dr1394]

John,


Little busy right now, but I'll make a quick post now

with a link for you to read. Later today, I'll make a more

detailed and technical post that addresses the test pattern

issue.


Here's a link to a user manual for a Faroudja box that is

used in front of MPEG-2 encoders at some OTA DTV stations.

It does format conversion and filtering.

http://www.faroudja.com/products/DFTswmanual3_01.pdf


Ron

 

[dr1394]

Quote:

Say, for example, a station wanted to deliver a full 1920X1080i static test pattern with a typical MPEG2/ATSC encoder. Could the encoder deliver the full resolution without artifacts to a 1920X1080-capable display?

Yes. But maybe not without artifacts at approx. 17 Mbps

video rate.


To deliver a "perfect" test pattern of a horizontal sweep,

the MPEG-2 encoder should be configured with optimized

intra and non-intra quant matrices and be set to a

bitrate that allows all of the macroblocks to be

coded at or near the minimum quant level. This is

essentially the same way as how it's done on the Avia

DVD test disc, except they use single I-frames and set

the quant of each macroblock block by hand. The 16:9

resolution pattern on Avia is a single I-frame with

941720 bits (or about 28 Mbps for a stream of these

I-frames!!!).


What the right bitrate for a sweep pattern might be

can only be determined by actually coding it. It's

a pretty simple pattern, so it might not be too bad.
Quote:

What happens with a live broadcast or D5-tape full-motion programming signal that fully 'stresses' MPEG2 encoding? If it's done, how is the encoder restricted to ~1400(?) to prevent artifacts?

MPEG-2 encoders modulate the quant value on each macroblock

to "throttle" the number of coded bits. When the quant levels

are raised during a more difficult to encode sequence, the

first coefficients to be tossed are the one that represent

higher frequency information. This shows up as "blockiness".


To make for better coding, pre-filter boxes like the

Faroudja or Teranex are placed in the signal path before

the MPEG-2 encoder (MPEG-2 encoders do NOT do any

pre-filtering on their SDI or HD-SDI inputs unless they

are doing horizontal decimation, more on that below). How

much filtering that is being used is anyones guess. It's

probably justed dialed in by eyeballing it (a little

soft, but not too soft).


One mistake that was made in the ATSC specification was

not allowing horizontally decimated resolutions such

as 1440h x 1080v and 1280h x 1080v. If we are filtering

to an effective 1440 or 1280 wide resolution, then we

save more bits by sending at these decimated resolutions

(mostly by saving macroblock header bits). This is what's

done on SD resolution DirecTV and Dish MPEG-2 streams

all the time (at 544h x 480v, 480h x 480v and 352h x 480v).

What works for the goose (Satellite MPEG-2) also works

for the gander (OTA ATSC MPEG-2).


Ron

 

[bfdtv]

Ron,


Thanks for that post. Good information.


Do you have any guess as to extent to which these Faroudja / Teranex pre-filter boxes are deployed at broadcast affiliates? And are we certain that one or more networks do not use these boxes prior to encoding of the national / regional distribution signal?

 

[John Mason]

Thanks again, Ron, for the MPEG details. Always wondered how producers 'maxed out' the Avia or similar DVD test discs. Interesting.


Foxeng, an engineer member at a Fox station, mentioned how they use a Teranex to upconvert Fox signals in a recent Fox-related post. A few years back a NYC CBS engineer mentioned they use(d) a Snell & Wilcox upconverter for SDTV. I skimmed through that pdf manual for the Faroudja DFT unit you hyperlinked above. The DFT appears to be for upconverting SDTV (480X720) to simulated HDTV resolutions. There's a short section mentioning filtering can be adjusted downward, but the manual doesn't describe inputs to the box at HDTV resolutions.


Still puzzled about your mention of not-allowed decimation for 1440X1080, etc. resolutions for ATSC. Earlier, in your excellent description of FIR filtering you outlined how subsamples can be made of frequencies representing resolutions from, say, 1440-1920, then reconstituted during decoding/display. Seems like this could enhance the overall impression of higher HDTV resolutions, although just subsampling the 1440-1920 range (already sampled by the HD camera or telecine), of course, isn't reproducing the original samples. Hard to picture how a series of subsampled, FIR-filtered, multibursts between 1440 and 1920 would reproduce. (Yes, few of us settle in for evenings of multibursts.)


Anyway, you mentioned, and I've read elsewhere, this subsampling at 1440-1920 isn't allowed with ATSC. I understand, though, that filtering for 1440-1920 frequently has already occurred before transmission to homes because the widely used Sony HDCAM (editing or capture) blocks >1440. That's why I queried about live or D5-tape programming. Regarding this decimation/subsampling you concluded: "What works for the goose (Satellite MPEG-2) also works for the gander (OTA ATSC MPEG-2)." It's not clear if you're saying subsampling/filtering is used when it supposedly isn't allowed. Interestingly, the Harmonic MPEG encoder pdf spec sheet you hyperlinked in your post several months back has these outputs: "1080i x 1920, 1440, 1280 pixels, 720p x 1280 pixels, 480P x 720, 704, 640 pixels." Again, it's not clear if such units are being used for 1440-1920 subfiltering (not prefiltering).


Perhaps some station engineers/technicians could elaborate on what takes place with live 1080i or D5 tapes not specifically prefiltered at 1440-1920? -- John

 

[PVR]

I have a program encoded as 1280x1080i.


Some decoders play it properly, and others

get confused...


Too late to go back and rewrite the specs (unfortunately).

 

[dr1394]

Since the ATSC specification was written during the

"dawn" of MPEG-2, the concept of horizontally decimated

resolutions wasn't quite in their mindset yet. Same goes

for the 720 wide versus 704 wide issue for SD resolution.


Way back when, 704 was chosen as the standard MPEG-2

horizontal resolution because at that time, the majority

of source material was NTSC. But NTSC really only has

711 active pixels, so it was felt that 704 would give

better coding (a few less macroblock headers and the

fact that active to black transitions take lot's of

bits since it can be a high frequency edge).


Nowadays, the difference between 704 and 720 wide is

moot. All encoders handle it because when the DVB standard

came out, they chose 720 (and we all scrambled to add

that to our encoder microcode). For decoders, it's even

less of a problem because no upsampling is changed (maybe

just some centering issues, but those often go unnoticed).


The 1440 and 1280 decimated resolutions for 1080i are a

different story. Since they are not specifically part

of ATSC, decoder vendors aren't always worried about

including the correct upsampling in their designs (as

PVR suggests). On the other hand, 544, 480 and 352

are part of the way DirecTV and Dish do things, so

almost every SD decoder on Earth handles those resolutions.


I've never been sure if sending resolutions outside

the ATSC specification is "illegal" (a DTV station could

get an FCC citation or "pink ticket") or if you can get

away with it (especially for 720h x 480v).


Ron

 

[John Mason]

Quote:

The 1440 and 1280 decimated resolutions for 1080i are a different story. Since they are not specifically part of ATSC, decoder vendors aren't always worried about including the correct upsampling in their designs (as PVR suggests).

By upsampling here, I conclude you mean upsampling from a (supposedly not-allowed) previous subsampling at 1280-1920 or 1440-1920. That differs completely, I presume, from a MPEG2-encoded 1080i HDTV signal that's missing frequencies at ~1440-1920 from Sony HDCAM processing or other reasons. With the subsampling, the decoder presumably must recognize the decimation-encoding signal--whatever that is--then upsample the 1440-1920 range to 'fill in' a resolution-diminished representation of this range.


Just slightly off topic, I presume there's no upsampling occurring with 1920X1080i that's lacking all frequencies needed for ~1440-1920. Assume a ~1920-capable display such as a graphics-grade 9-in-CRT FP with a standard STB. I outlined this in a "resolvable 1920" post. The assumption is, when there's no ~1440-1920-capable frequencies present after filtering, the FP simply displays shades of light or dark where resolvable details existed originally (film, telecine recording, live camera, D5/6 tape). What about a fixed-pixel system such as Toshiba's 57-in LCOS RPTV with literally 1920X1080 fixed pixels? In deinterlacing 1080i to 1080p as it does, wouldn't the 1080p Toshiba similarly display shades of light or dark where ~1440-1920 details existed originally?


Back to the 'special' MPEG2 encoding described above for maximizing resolution from DVD test discs. Perhaps something like this was used during the mid-1990s experts-committee approval of the ATSC system. As my simplified table of their test results shows, they measured 1780X400 pixels for a 5-rpm rotating test pattern and 1638X800 for a static pattern.


Perhaps, since the 'maximum-stress' MPEG2-compression only occurs for a tiny segment of a 16:9 image (closely spaced but minor segments area-wise of a resolution-wedge pattern), a mid-1990s encoder could handle it without significant artifacts. But then, for a full-motion detailed video scene, you encounter the noise and bad artifacts Birkmaier outlined during the late-90s Sony 1440-filtering demo (Part 7, about 1/3 down the text). Since by many accounts we're getting 1920X1080i prefiltered to roughly 1400X1080, what's the roadblock in MPEG2 encoding? Can't P4-level number-crunching microprocessor speeds, parallel-processing techniques, etc., etc., ever MPEG2-compress 1920X1080i motion video to ~17-Mbps? Believe, if you factor in STB reconstruction filtering, current OTA/satellite/cable 1080i is currently lacking about 40% of what HDTV researchers found we could resolve in homes. -- John

 

[PVR]

(The following are just my opinions and observations... I full expect that many would disagree)


Yes - we are saying that some decoders would not know how to properly (horizontally) stretch out the 1440x1080i to the 1920x1080 framebuffer for proper 16x9 display.


If the source was "pre-filtered" to about 1440x1080i (say because of HDcam, some digital VCR, or a Terranex), but encoded as "standard" 1080i then the "data" really has 1920 elements across but many of those elements are duplicates (or very similar) to the ones next to them because of the filtering. The MPEG2 encoder can work with this (doing compression) so the results isn't as much of a burden as the difference between 1920 vs 1440 suggests, but dr1394 points out that there is *some* overhead in encoding the extra elements on each line. Basically the picture gets broken up into a two different sizes of "checkerboards" of picture elements so that the compression algorythms can work on small blocks of data. With 1920 across there are more "checker boxes" to compress so there are bigger data tables, even if the overall amount of real data ends up being about the same.


So - overall - we are saying it is unfortunate that the ATSC spec didn't force decoder manufacturers to guarantee 1440x1080i and 1280x1080i as valid formats, because (at

Going to 720p as a US standard was a good idea, but I think it may have been a bit too much of a resolution sacrifice. If we had a slightly higher progressive format such as 1360x768p it might have been easier for everyone to agree that one format was the best choice.

 

[PVR]

>> what's the roadblock in MPEG2 encoding?


The basic roadblock is the MPEG2 algorythm itself. There are very many rigid parts of the spec.


Going to some MPEG4 variant, or an even more recent type of compression algorythm could result in some reduction in datarates needed for the same quality. Unfortunately the ATSC spec needed to set a hard target for a known compression algorythm at the time, otherwise no one would start building hardware for it. MPEG2 made sense at the time, and is still fairly decent, but we can always hope that someday ATSC2 comes along with a more effecient compression algorythm (or even a way to specify a decompression engine that accepts encoder definable decoding algorythms!). I would say it would likely be at least 10 years before anyone considers a new standard.


So in the near term we are more limited to improvements such as:

1> Better motion calculation to best leverage B & P frames.

2> Better 24fps detection to take advatage of repeat frame flags.

3> Encoder configuration tweaking so that the minimum amount of filtering is done but still avoiding Macro/DCT artifacts

(as dr1394 once said "it all comes down to soft vs blocky")


Newer encoders do the above better, so things will improve as more members of the broadcast chain upgrade their gen 1 equipment to newer/better encoders.


Since the source of a signal isn't sure exactly how it is going to get broadcast (ultimately) they can't be sure exactly how much pre-filtering to dial in. If some of their stations broadcast at full 19.3mbit/sec, but others multicast down to 12Mbit/sec, they may have to do extra pre-filtering and compromise the picture for everyone. Ideally the initial pre-filtering would be minimal, and pre-filtering would be minimal at a "mezzanine" level and any major filtering would be left up to the final broadcaster, but (unfortunately) not every small station can afford a good filtering engine so they are dependent on the filtering being done beforehand. Some sort of protocol so that the final encoders could send quality signals back to the filtering engines to dynamically fine tune things could probably help, but would be a nightmare to implement.


Well - I hope someone finds my rambling useful. I only half-way know what I am talking about so hopefully I didn't give out some misleading information.

 

[John Mason]

Originally posted by PVR
Quote:

Yes - we are saying that some decoders would not know how to properly (horizontally) stretch out the 1440x1080i to the 1920x1080 framebuffer for proper 16x9 display.

Also agree. Think you have to be clear when mentioning 1440-limited 1080i, though, as you point out later, whether you're talking about decimated (sub-sampled) 1440 or 1080i restricted to

 

[PVR]

The ATSC specs don't say anything about pre-filtering. You could pre-filter down to 192x108 and then upscale it to 1920x1080 and still call it 1080i... (although it would look like crap).


Not sure I follow your analogy with the blades of grass, but I think you are making a point (to which I agree) that perhaps we *are* better off that we are forced to use full 1920 across for 1080i because otherwise we would all be debating how well different decoders handle the horizontal upscaling on decimated signals!


I haven't been thinking that hard about the color subsampling. Just turn the chroma controls on your set all the way down and think about everything in the B&W world for now...

 

[dr1394]

Quote:

but dr1394 points out that there is *some* overhead in encoding the extra elements on each line

Here's some real numbers for you. This is a few frames

from a "Bikini Destinations" 1920h x 1080v bitstream.

Check out how many bits are used in macroblock headers

and motion vectors. These 2 numbers would be cut by

a 1440/1920 (0.75) ratio. The saved bits would be

available for DCT coefficients in the fewer blocks

that are coded. B-frames are the worst with over 50%

of the bits expended on macroblock headers and motion

vectors. For example, on the first B-frame, there are

101270 + 86478 = 188018 bits. We could save approx

47000 bits and use them for coefficients. There's

152380 bits used for coefficients, so 47000 is

about 30% more bits that can be spread across 25% less

macroblocks.
Code:

* --------  Sequence Start Code at 0        ---------
* --------       GOP Start Code at 104      ---------
* --------          Intra frame at 112      ---------
* Frame number: 2              Average mquant: 4.64 
* --- Number of bits used ---
*     High level headers :   3858  (0.24%)
*     Macroblock headers :  33496  (2.06%)
*         Motion vectors :      0  (0.00%)
*       DCT coefficients : 1585738  (97.70%)
*                  Luma  : 1221808  (77.05%) 
*                Chroma  : 363930  (22.95%) 
* --- Macroblock types ---
*                  Intra :   8160  (100.00%) 
* --------  Bidirectional frame at 202956   ---------
* Frame number: 3              Average mquant: 4.67 
* --- Number of bits used ---
*     High level headers :   2956  (0.86%)
*     Macroblock headers : 101270  (29.52%)
*         Motion vectors :  86478  (25.21%)
*       DCT coefficients : 152380  (44.41%)
*                  Luma  : 125718  (82.50%) 
*                Chroma  :  26662  (17.50%) 
* --- Macroblock types ---
*                  Intra :      9  (0.11%) 
*          Frame Forward :   3876  (47.50%) 
*          Field Forward :     81  (0.99%) 
*         Frame Backward :   1737  (21.29%) 
*         Field Backward :     27  (0.33%) 
*    Frame Bidirectional :   1386  (16.99%) 
*    Field Bidirectional :    207  (2.54%) 
*                Skipped :    837  (10.26%) 
* --------  Bidirectional frame at 245936   ---------
* Frame number: 4              Average mquant: 4.75 
* --- Number of bits used ---
*     High level headers :   2952  (0.88%)
*     Macroblock headers :  98172  (29.31%)
*         Motion vectors : 100521  (30.01%)
*       DCT coefficients : 133282  (39.79%)
*                  Luma  : 108612  (81.49%) 
*                Chroma  :  24670  (18.51%) 
* --- Macroblock types ---
*                  Intra :     18  (0.22%) 
*          Frame Forward :   2465  (30.21%) 
*          Field Forward :    145  (1.78%) 
*         Frame Backward :   2371  (29.06%) 
*         Field Backward :    413  (5.06%) 
*    Frame Bidirectional :   1314  (16.10%) 
*    Field Bidirectional :    574  (7.03%) 
*                Skipped :    860  (10.54%) 
* --------      Predicted frame at 287908   ---------
* Frame number: 5              Average mquant: 3.44 
* --- Number of bits used ---
*     High level headers :   2956  (0.43%)
*     Macroblock headers : 101646  (14.72%)
*         Motion vectors :  62919  (9.11%)
*       DCT coefficients : 523081  (75.74%)
*                  Luma  : 425715  (81.39%) 
*                Chroma  :  97366  (18.61%) 
* --- Macroblock types ---
*                  Intra :    226  (2.77%) 
*          Frame Forward :   7544  (92.45%) 
*          Field Forward :    255  (3.12%) 
*                Skipped :    135  (1.65%) 
* --------  Bidirectional frame at 374336   ---------
* Frame number: 6              Average mquant: 4.43 
* --- Number of bits used ---
*     High level headers :   2956  (0.87%)
*     Macroblock headers :  99784  (29.43%)
*         Motion vectors :  84324  (24.87%)
*       DCT coefficients : 151953  (44.82%)
*                  Luma  : 127223  (83.73%) 
*                Chroma  :  24730  (16.27%) 
* --- Macroblock types ---
*                  Intra :     10  (0.12%) 
*          Frame Forward :   3167  (38.81%) 
*          Field Forward :     54  (0.66%) 
*         Frame Backward :   3098  (37.97%) 
*         Field Backward :     50  (0.61%) 
*    Frame Bidirectional :    894  (10.96%) 
*    Field Bidirectional :    138  (1.69%) 
*                Skipped :    749  (9.18%) 
* --------  Bidirectional frame at 416804   ---------
* Frame number: 7              Average mquant: 4.42 
* --- Number of bits used ---
*     High level headers :   2952  (0.89%)
*     Macroblock headers :  97276  (29.19%)
*         Motion vectors :  81867  (24.57%)
*       DCT coefficients : 151108  (45.35%)
*                  Luma  : 126284  (83.57%) 
*                Chroma  :  24824  (16.43%) 
* --- Macroblock types ---
*                  Intra :     14  (0.17%) 
*          Frame Forward :   1680  (20.59%) 
*          Field Forward :     16  (0.20%) 
*         Frame Backward :   4465  (54.72%) 
*         Field Backward :     94  (1.15%) 
*    Frame Bidirectional :    931  (11.41%) 
*    Field Bidirectional :     84  (1.03%) 
*                Skipped :    876  (10.74%) 
* --------      Predicted frame at 458544   ---------
* Frame number: 8              Average mquant: 3.12 
* --- Number of bits used ---
*     High level headers :   2956  (0.41%)
*     Macroblock headers : 106870  (14.70%)
*         Motion vectors :  61366  (8.44%)
*       DCT coefficients : 555922  (76.46%)
*                  Luma  : 447422  (80.48%) 
*                Chroma  : 108500  (19.52%) 
* --- Macroblock types ---
*                  Intra :    240  (2.94%) 
*          Frame Forward :   7603  (93.17%) 
*          Field Forward :    193  (2.37%) 
*                Skipped :    124  (1.52%) 
* --------  Bidirectional frame at 549532   ---------
* Frame number: 9              Average mquant: 4.42 
* --- Number of bits used ---
*     High level headers :   2956  (0.88%)
*     Macroblock headers : 100550  (29.89%)
*         Motion vectors :  82986  (24.67%)
*       DCT coefficients : 149939  (44.57%)
*                  Luma  : 121108  (80.77%) 
*                Chroma  :  28831  (19.23%) 
* --- Macroblock types ---
*                  Intra :     17  (0.21%) 
*          Frame Forward :   3396  (41.62%) 
*          Field Forward :     44  (0.54%) 
*         Frame Backward :   2884  (35.34%) 
*         Field Backward :     25  (0.31%) 
*    Frame Bidirectional :    930  (11.40%) 
*    Field Bidirectional :     51  (0.62%) 
*                Skipped :    813  (9.96%) 
* --------  Bidirectional frame at 591680   ---------
* Frame number: 10             Average mquant: 4.16 
* --- Number of bits used ---
*     High level headers :   2952  (0.82%)
*     Macroblock headers : 102916  (28.45%)
*         Motion vectors :  81195  (22.45%)
*       DCT coefficients : 174671  (48.29%)
*                  Luma  : 140396  (80.38%) 
*                Chroma  :  34275  (19.62%) 
* --- Macroblock types ---
*                  Intra :     15  (0.18%) 
*          Frame Forward :   2081  (25.50%) 
*          Field Forward :     31  (0.38%) 
*         Frame Backward :   4463  (54.69%) 
*         Field Backward :     73  (0.89%) 
*    Frame Bidirectional :    740  (9.07%) 
*    Field Bidirectional :     40  (0.49%) 
*                Skipped :    717  (8.79%)

Ron

 

[PVR]

Those are some nice measurements, Ron!

Good thing you used the Bikini Destinations tape!

 

[PVR]

It looks like the Macroblock headers and motion vectors accound for maybe 40% of the video stream... So take 25% of that and maybe you could see about a 10% improvement in the video stream datarate. Take into account audio and other packets, and you are looking at more like 8%. Not a huge amount, but enough to wish that it could have been supported.

 

[dr1394]

Quote:

Originally posted by PVR Those are some nice measurements, Ron! Good thing you used the Bikini Destinations tape!

Of course, it's the tutorial bitstream of choice. Here's

the image that goes with the 3rd B-frame.


Ron

 

[John Mason]

Quote:

Originally posted by PVR The ATSC specs don't say anything about pre-filtering. You could pre-filter down to 192x108 and then upscale it to 1920x1080 and still call it 1080i... (although it would look like crap).

Presume this is in response to my comment above: "Think you have to be clear when mentioning 1440-limited 1080i, though, as you point out later, whether you're talking about decimated (sub-sampled) 1440 or 1080i restricted to

 

[John Mason]

Quote:

Originally posted by dr1394 Here's some real numbers for you. This is a few frames from a "Bikini Destinations" 1920h x 1080v bitstream. Check out how many bits are used in macroblock headers and motion vectors. These 2 numbers would be cut by a 1440/1920 (0.75) ratio. The saved bits would be available for DCT coefficients in the fewer blocks that are coded. B-frames are the worst with over 50% of the bits expended on macroblock headers and motion vectors. For example, on the first B-frame, there are 101270 + 86478 = 188018 bits. We could save approx 47000 bits and use them for coefficients. There's 152380 bits used for coefficients, so 47000 is about 30% more bits that can be spread across 25% less macroblocks.

Thanks for the HDNet example, Ron, although most of the analysis is beyond me, other than my assumption that more 'bit space' with a 'full' ~17-Mbps video (of 19.39 Mbps ATSC) is desired because that enables more motion vectors for moving details and thus higher resolutions. Assume that's the hang-up for high-resolution 1080i.


It's still not clear what the MPEG-2 encoder hardware hang-up is if it's a question of electronic technology. (Do camera CCDs need to be cryogenically cooled to trim most ~1400-1920 noise?) More than 8 years after ATSC's approval, it appears a 1920X1080i spec was put in place that has no prospects of being met--without slicing off about 40% of its top resolution (~1400 limits minus ~15 reconstruction filtering).


Understand HDNet's 1080 60i is about the best there is, but it's not clear what they're typically beaming down to subscribers (as far as upper resolution limits). A while back here, you'll recall, PVR posted a hyperlinked screen shot of HDNet's resolution-wedge test pattern. The pattern seems to be restricted to about 1200-lines resolution and his system, for some reason, didn't resolve that, even though it's presumably full-resolution 1080i capable.


It'd be great to hear from HDNet tech folks, or others doing necessary ATSC prefiltering at broadcast stations (from MPEG-2 limitations), on this topic. -- John

 

[PVR]

Well, I guess we are all over the map here...


#1: Agreed - it seems that all 1080i ATSC signals that we can receive has had some amount of pre-filtering done. Either by the camera, or intentionally by some equipment along the way. HDnet is often touted as one of the sharpest, best sources of HD... So when ~their~ HD test pattern shows obvious high frequency filtering it seems clear that everyone is doing it to some degree. It is basically a necessity to avoid blocky artifacts at ATSC datarates. This is why some industry insiders say that consumers have never seen "real" HD. You need to see live feeds from the cameras on studio monitors to see what it can really do.


#2: Agreed - (basically) no one is broadcasting an intentionally horizontally decimated 1080i signal right now. Ron's point that it could be more efficient is well taken, but no one wants to risk supporting non standard streams with a multitude of decoders out there. I think Bell ExpressVU tried some 1280x1080i for a while, but they have the luxury of knowing that there is only one type of decoder (model 6000) that they sell for HD viewing... So if they come up with a scheme that works with the 6000 decoder then they can broadcast it.


#3: Scaling algorithms are not standardized by any means. Different vendors will market how theirs is better. When Ron talks about "taps" he is mentioning one of the key pieces in a good scaler. Generally the more "taps" a scaler has the better. Your example of 1920x1080i to 1366x768p is apropos here. I use that conversion on one of my HiPix PCs all the time. The end result looks very close (to my eyes) to the same material viewed as 1080p from a software deinterlacing system (DVHStool with Elecard filters). I played the same show on the HiPix converted to 1360x768p, and then on the software scaler as 1920x1080p and used the A/B switch on my monitor to compare. The result was surprisingly (to me) more similar looking than I would have imagined. The same comparison of 1920x1080p compared to 1280x720p shows that the 1080 signal does have more noticable detail on most shows, but the 1360x768p comes much closer to representing all the real detail we have in a 1080 signal (given all the pre-filtering).

I think the HiPix has a "15 tap scaler", and the 1360x768p mode has 3:2 pulldown removal on properly flagged sources.

As another comparison of how different things can be, the JVC DiLA projectors accept 1920x1080i inputs, but have to convert them to 1365x768p res to make a 16x9 image on their digital display chips. The JVC uses a unique scaling technology that attempts to preserve higher frequency details by showing different bits in different field updates. Sort of a "trick of the eye" that some may argue is completely wasted on the viewer, and others may argue that it gives it a superior, yet hard to define quality improvement.

(I am still trying to find a good description of this technology, but check out page 9 of this document)
http://www.large-screen.com/jvc_publ...20Brochure.pdf

 

[John Mason]

Appreciate the great scaling details, PVR. Hope my aside about 1080i for fixed-pixel displays didn't divert "MPEG Gurus and DTV Station techs" completely.


There was a great thread about JVC's hybrid progressive/interlace 'pixel stuffing' technique a few years back by Mark Foster. Nearly sold me on buying one. The original may be gone, but I copied it to a thread in the >$5k FPs forum. -- John