[opendtv] Re: Half Truths - Was More 1080p@60

At 4:17 PM -0500 12/6/07, Manfredi, Albert E wrote:
One thing is that the huge base of 24 fps movie archives, still growing,
is not going away anytime soon. So the 18/36/72 idea doesn't work well
for that.

Pay attention BERT!

From my post:

The task force recommended a family of frame rates with integer relationships; the most important members of this family being 24/36/72 fps. It is important to note that for bandwidth conservation this family could also support 12 and 18 fps.

Start with a refresh rate of 72 fps.

No divide it by integers:

72 / 2 = 36

72 / 3 = 24

72 / 4 = 18

72 / 5 = non integer result

72 / 6 = 12

Another point is that what you'd be doing in fact is always increasing
the bit rate compared with now.

Not even close to true.

There are two factors at work here:

1. Spatial Resolution - this is not a factor as it remains constant as the frame rate increases

2, Temporal Resolution - this is what we are discussing.

How does temporal resolution affect video compression codecs?

Believe it or not, higher frame rates actually help.

Here are the reasons (note that the family is ALL PROGRESSIVE):

In order to create the illusion of motion continuity at frame rates that are BELOW the flicker fusion frequency for most viewers (typically 40 to 50 fps) the shutter period for image taking must be increased to allow for some motion blur in each frame. IF we did not do this you would perceive very visible motion discontinuity (judder). This motion blur removes sharpness, especially in the edges of moving objects. The good news is that you can get away with more quantization error in these areas; the bad news is that this is what you will typically get from MPEG.

As the frame rate increases, you can use shorted shutter periods, and thus acquire sharper images. This helps the motion compensated prediction component of the MPEG algorithms, as it is easier to find block matches in the areas of motion. But FAR MORE IMPORTANT, you can increase the number of B-frames in a GOP, and B-frames are where the MPEG algorithms gain most of their coding efficiency.

The net result is that there is virtually no bit rate penalty in moving from say 60 fps to 72 fps,

I worked with Gary Demos on a project where film was shot at all of the frame rates in the proposed family. At 36 fps the quality of motion was very good, and the bits required for emission are actually lower than for 50/60 fps. This format could be used for a large percentage of TV content that is now shot at 50/60 interlaced frames per second.

Gary had Polaroid/Philips build a 720@72P video camera as part of a grant he received to develop advanced coding techniques. It was show for several years at the Philips NAB booth. The quality was stunning, especially for slow motion replays. And the emission bit rate penalty when compared to 720@60P. There were several presentations at HPE events (at the time the organization was called ITS). I'm sure Mark Schubin can verify all of this.

And there is another factor to be considered here. What happens when you improve temporal resolution rather than spatial resolution. We already know that 720P is a superior emission format in bandwidth constrained channels relative to 1080P. When we increase the frame rate, we also are able to increase the sharpness in areas of motion with very little impact on the emission bit rate. But if we increase the spatial resolution we place a significantly greater burden on the emission compression system.

1080@60P is already a big challenge because of camera sensitivity issues. I agree that using 1080@72P would only make this more of a challenge. Fortunately this is not necessary, as 720@72P can easily be implemented today.

Everything now possible with 24 fps, such as non-sports programming,
would most likely have to be transmitted at 36 fps. Everything now
possible at 50/60 fps, sports primarily, would have to migrate up to 72
fps. So all things equal, you're increasing the required bit rate every

See above. today 24P is ONLY used to create a Film Look - either for actual movie/episodic programming or documentary. Most NON-sports programming is still shot using interlaced SDTV, although we are starting to see more and more conversion to HD at either 720@60P or 1080@30i. So 36 FPS would actually reduce the emission bit rate required for many programs.

And for high motion programming like sports, the benefits of moving to 72P outweigh any penalty in emission bit rate. Another way to say this is that if you want to deliver HD sports at say 10-12 Mbps, you will DELIVER SIGNIFICANTLY better quality shooting 720@72P rather than 1080@60P.

All of this only applies to motion portrayal, of course. Flicker
reduction is done by "decoupling" the transmitted frame rate from the
displayed frame rate, as you frequently say, so it's never an issue.
(Not even in cinema.) So what computer displays do almost never applies
to these discussions, since they are primarily concerned with flicker
reduction and still graphics.

Flicker reduction is done BADLY these days in 60 Hz countries, ESPECIALLY for 24P source, by using non-integer frame repeat patterns. So we have to live with the 3:2 pull-up problems with MOST of the displays now on the market. The one benefit of the approach that Jeroen told us to look for is that with 120Hz refresh we can do an integer refresh - i.e. repeat each frame five times. Unfortunately, since this refresh rate improves the perception of detail in moving areas of the picture, 24P source does not benefit - if anything it is worse. Thus Philips is using real motion compensated prediction to create in-between frames to improve the fluidity of motion. This can de done for as 72 fps refresh as well, creating 2 in between frames instead of four. Now which one do you think requires more computing power?


P.S. After writing this I read Jeroen's excellent post about frame repetition versus motion compensated prediction. Life would be much easier for Jeroen if we had adopted the 24/36/72 fps family. But clever engineers have a way of working around politically motivated issues, and Moore's Law keeps give these guys the MIPs they need to do exotic processing.

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: