[opendtv] Re: Food for thought

At 4:23 AM +0000 2/23/07, Adam M. Costello wrote:

Craig Birkmaier <craig@xxxxxxxxx> wrote:


 to deliver the full quality of HDTV you'll need the equivalent of the
 bits required for about 4 SD services


Why is it 4 rather than 6?  (1920 * 1080) / (720 * 480) = 6.0.

And that's using the most generous DTV definition of SD.  To capture the
resolution of analog NTSC, 480*480 is sufficient (right?), which would
make the ratio 9.0.

AMC



Good question Adam.
There are two aspects to the answer, related to the spatial and temporal resolution of the source(s).
It is true that 1920 x 1080 has about 6 times the number of samples as an SD source. Some of these samples may represent the same information as in the SD source (the common 4:3 center area), and the remaining samples represent new, correlated information at the edges of the common area. In most cases the 1920 x 1080 source will have more detail information to encode as well.
Depending on the way in which the source has been sampled and processed, there will be varying amounts of entropy in the HD and SD source. By this I mean sampling errors, noise and other impairments that the encoder must deal with. If the SD source was oversampled, then resampled to SD resolution the samples will have less entropy (i.e. be more accurate) and thus will encode with greater efficiency. Entropy is the big problem for HD, as most current HD acquisition systems do not oversample, and noise is a major issue at the higher frequencies.
The good news for the HD source is that the highest frequencies will be quantized away first, and this will eliminate fine detail, not the lower frequencies common to both the SD and HD source. Bottom line, although there are 6 times more samples to encode, there is not 6 times the information content in SD and HD versions of the same source.
Then we get into the temporal domain - the motion content of the sources. HD actually helps with motion compensated prediction, as the extra samples are typically highly correlated with respect to the motion (not the noise). Typically we get more gain from the motion compensated predictions in HD source to help offset the increased levels of spatial detail that must be encoded.
So when comparing a single SD stream with an HD stream shooting the same source we may see a relationship in the range of 6x the complexity down to about 2x. I would note that Standard Definition DVDs are typically encoded at an average bit rate of 6-8 Mbps, with peaks that can reach 11 Mbps; even at these higher rates with lower temporal rate 24P source there are still scenes that are bit starved.
Now consider what happens when we start adding more sources that are un-correlated. We are no longer talking about 6X the number of samples representing the same temporal information, but rather, totally different information in both the spatial and temporal domain. If we used the same bit rates as DVDs for four SD sources we would need 24-32 Mbps average with peaks out to >40Mbps. In reality the four sources typically will not all peak at the same time, and we can use statistical multiplexing to give the sources that need more bits some help when other sources are less demanding.
Still, we are encoding a great deal of information, so when you try to cram 4-6 sources in a 19-24 Mbps broadcast multiplex, something has to give - typically this means pre-filtering the sources to reduce the information content. As you noted, NTSC can be encoded as 480 x 480, and it is not uncommon to see 352 x 480, especially with DBS services. Just remember, that most of the temporal information is not filtered out, we are just making the spatial samples more correlated as we filter down.
The more you pre-filter, the greater the number of sources you can cram in, within limits. for a 6 MHz channel this typically means about 18 MBps for video coding or an average bit rate of 3 Mbps. Four sources raises the average to 4.5 Mbps.
Finally, there is the special case for an SD/HD simulcast. In this case the temporal content is the same for both, and both peak at exactly the same time, further stressing the encoder during high motion content scenes. Here, layered encoding might make more sense, adding a spatial detail layer for the HD source, and a common base that encodes the temporal information once. Unfortunately, layered encoding has not seen much use, as it has its own efficiency issues relative to separate encoders for the SD and HD source.
In my opinion, we are bit starving everything that is being delivered today. There is too much pre-filtering to cam in more stuff, and we are not allowing enough overhead to deal with peak bit rate requirements. And anything that is being encoded in real-time cannot be optimized as well as source where a compressionist can fine tune the parameters in difficult scenes.
This suggests that downloading content - typically in non-real-time - has the potential to deliver significantly higher image quality that real-time streaming. We can increase the peak and average bit rate as needed, and we can correct packet errors, providing a perfect copy of the original source file.
At one time I advocated the notion of creating a metadata file for encoding information that could be used by a program distributor to help control statical multiplexes. The metadata file would contain peak and average bit rates for the program against a time line. The stat mux could use this data to look ahead at the combination of sources being multiplexed. IF there were moments where the peaks all combined to create a problem, it might be possible to apply slight offsets in the delivery time for each channel to level out these peaks. Even if the program segment times could not be changed, at least the encoder would know in advance how to apportion the bits - it might even look ahead and re-encode problem areas, applying additional pre-filtering to limit visible artifacts when the encoders/multiplex are stressed. 

I hope this helps...

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: