[opendtv] Re: Popular screen aspect ratios

  • From: Craig Birkmaier <craig@xxxxxxxxx>
  • To: opendtv@xxxxxxxxxxxxx
  • Date: Mon, 17 Jan 2011 08:19:50 -0500

At 6:48 PM -0600 1/16/11, Manfredi, Albert E wrote:

 > When stuff does not fill the screen someone did something wrong,
Nonsense. It is completely ordinary to receive 4:3 pillarboxed content from broadcasters, both in 1080i or 720p HD subchannels, or in 480i SD subchannels. It's also commonplace to see 2.35:1 material sent as letterboxed 16:9. You are simply wrong that broadcasters must always fill the frame, either now, *or* in the analog TV days.
Sorry, just a misunderstand of your question. Of course there will be unused screen areas in a world with multiple formats and aspect ratios. This is to be expected, and in my case is the preferred way to view the source - I would rather see the source as intended, even if this means there will be black surrounding one axis of the image while the other fills the screen. Others may prefer an accommodation mode that fill the screen using some form of zooming, distortion or both. That is what I mean by "source accommodation." But, IMHO, the default should always be to start with letterbox or pillarbox if the source does not match the display aspect ratio.
I thought you were talking about situations like that with Cliff where we wind up with a "postage stamp" presentation that cannot be zoomed to fill one axis of the screen. I have also seen distortions when the metadata is not set correctly by the compressionist. 




 No, I am demonstrating why 16:9 does not simply mean "anything other
 than 4:3." The simple fact, that you cannot deny, is that anamorphic
 stretching in DTVs is limited to only a ratio 1.77/1.33.



 This is completely wrong. What you note above is simply the RESTRICTION
 place on MPEG-2 by the ATSC standard.


This is the crux of your confusion.
Regardless of the restrictions placed on incoming MPEG-2 streams, the output side of STBs had to be restricted to some sensible set of display options. To avoid having to supply them with the sort of "infinite" programmability that PC graphics cards have. 

I think this is the crux of your obstinateness.

Let's take a closer look.
The MPEG standard allows any source to be encoded in multiple ways. One of the most common ways it is used to save channel bandwidth is to use shorter line lengths. For example, many cable and DBS systems use 352 x 480 to encode 704 x 480 source; the original ATSC standard does not support this, however, it has been added for new services such as MHP.
352 x 480 does is yet another non square pixel representation of the source. It must be scaled for proper presentation just as we must scale 704 x 480 to either 4:3 or 16:9 for proper presentation. In reality there are an almost infinite number of ways to encode the same source, as you can choose ANY macroblock increment for either the H or the V axis of samples using the MPEG-2 standard and syntax.
It is clearly obvious that it IS NOT necessary to limit displays "to some sensible set of display options" from the perspective of the encoding algorithm. Today there are a very large number of formats being delivered by the Internet, and theaters still display a wide range of movie formats.
There IS, however, an economic need to manufacture displays in a limited number of sizes and aspect ratio for practical reasons. I have no problem with the CE vendors choosing 16:9, although I argued for 2:1 and have no problem with 1.66:1, or even high resolution 1.33:1 for some applications. Likewise, I have no problem with broadcasters standardizing on 16:9 for acquisition. processing and distribution, although, when they are delivering content that uses another aspect ratio I do not want them to crop it.
Thus, I have no problem with the broadcaster's current approach of using a 16:9 container. It allows them to deliver other formats while maintaining compatibility with the limitations of the ATSC standard. I would prefer that they just encode the source in its native aspect ratio and send the metadata to properly decode it, but this is not possible with ATSC receivers.
In other words, I would prefer that the broadcasters use the encoding standard as intended, rather than imposing restrictions that make it impossible to view anything except the sources that conform to these restrictions.
Here is a real world example of how a CE company must deal with these limitations.
Let's assume that a manufacturer wants to build a DTV that is compatible with both the ATSC standard and the formats being used by the cable industry, so they can include Tru-2Way services, so that Bert does not need to use a separate STB. If they implement only the portions of the MPEG-2 standard needed for ATSC there will be many cable formats that the decoder will not be able to process. So their best approach is to implement a decoder that is fully conformant with MPEG-2 MP@ML for SD and MP@HL for HD. They could add their list of formats to the ATSC list, but why not just use the standard properly?
And as far as "the sort of "infinite" programmability that PC graphics cards have," is concerned, what's the problem? The real limits are performance based, not the output to the display or the MPEG formats that are permitted. This is why MPEG has Profiles and Levels - this defines the required tools and the performance level that the hardware must support.
Europe chose to restrict their original DTV deployment to MP@ML for several reasons: 

1. The cost of implementation for higher performance levels like MP@HL.
2. For compatibility with the installed base of PAL receivers.
Although HD broadcasting is still limited in Europe, consumers have purchased HDTVs for several reasons: 

1. There are other sources of widescreen and HD content like DVD and Blu Ray.
2. Widescreen SD fills a 16:9 display as opposed to watching it in letterbox on a small PAL display. 3. With the addition of a new STB they will be able to receive and view HD broadcast services.
The main point of discussing how computers deal with the issues we have been discussing is that they have solved these problems and thus can easily support any format on any display... 

Automatically.


As I have always thought, you continue to focus on only half the problem.
The truth is that you are the one who continues to focus on a subset of the problem... 

The Broadcast Subset.
We are now evolving into the next phase of digital television. A phase that requires that the DTV have the capability to deal with a wide range of potential sources including broadcasts, MVPD services, Over-The Top services, and packaged media formats like Blu Ray. They can do this by trying to support everything internally, or via the addition of external boxes that handle the stuff they don't understand.
If Apple can build a device for $99 that can handle the "everything approach" automatically, there is no reason that the CE vendor cannot do the same... 

From what we saw at CES it appears that this is the direction they are headed.
By the way, I have seen several recent stories that suggest that the next rev of Apple TV will output both 1280 x 720 and 1920 x 1080 native formats - the current version is "performance" limited to 720P.
This is my last post on this thread. We have beaten the issues to death, but I think the discussion was worthwhile. 

One last suggestion for Bert.
Please come join us in the 21st Century. It is true that in the analog world of the 20th Century, supporting limited options was an economic requirement. This was the nature of analog standards and CRT based TVs. In the Digital World of the 21st Century, however, it is no longer necessary to constrain devices unnecessarily. The real limits today are performance based - i.e. higher performance = higher cost.
Thus it is probably premature for everyone to start buying 4096 x 2048 displays, despite the fact that 4096 x 2048 cameras are being used for acquisition today. But this should not be an excuse for imposing restrictions that have virtually no impact on the cost of the mainstream devices that are manufactured today. 

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.

Other related posts:

  1. Home
  2. opendtv
  3. Archive
  4. 01-2011