[opendtv] Re: 625 video quality is good enough....
- From: Craig Birkmaier <craig@xxxxxxxxx>
- To: opendtv@xxxxxxxxxxxxx
- Date: Tue, 19 Oct 2004 10:48:03 -0400
At 9:35 AM +0100 10/19/04, Alan Roberts wrote:
>If you've been reading this thread, you should already know that we're
>talking of the practical possibilities of getting 1080/50p and 60p to the
>viewer. At present, MPEG2 cannot reduce the raw data rate down to a
>practical value for transmission within the existing agreed spectrum
>allocations. I would have thought that was obvious.
This is mostly correct. Clearly the standard does not have a LEVEL to
support the sample clock rates needed for 1080 50/60P. But it is not
accurate to say that the MPEG-2 tools are incapable of being updated
to these sample rates.
Entropy coding is widely misunderstood. There are two critical
factors that impact performance. This most obvious is image entropy;
that is, the accuracy of the samples when compared to the stimulus
that is being captured. We can use synthetic test signals to get
around this issue, so that the MPEG tools can be evaluated at higher
clock rates. What we find is that it is information content that form
the fundamental limitations, when we remove other factors.
I can create a series of test sequences that will allow 4K x 4K @ 60P
to be encoded efficiently with the MPEG-2 tools; alternatively I can
break MP@ML (10.4 million samples/sec) with the right sequences.
Higher resolution rasters are only a problem IF they contain high
levels of useful information that would not be present at lower
acquisition resolutions. In some cases, higher resolutions can reduce
image entropy making it easier to encode. In many cases the opposite
is true. The reality is that noise is the other major issue with
entropy coding. Every sample that is affected by noise increases the
entropy that the encoder must deal with. The real problem with 1080
formats is noise. Increasing the frame rate only makes the problem
worse.
The reality is that the MPEG-2 tools are fairly crude. They had to be
at the time, as computational complexity was the gating factor.
MPEG-4, Windows Media, et al do a better job because there are enough
MIPS available today to use better techniques, at the expense of
computational complexity. This is especially true for some of the
major weaknesses of MPEG-2.
For example, I can produce a diagonal gradient for which MPEG cannot
reduce the data relative to the source at ALL. Every coefficient in
every DCT block will be different, and any attempt to quantize the
coefficient will result in visible banding. MPEG-4 has additional
tools to deal with gradients.
The reality of video compression is that there can be tremendous
spikes in the compressed data rates based on source complexity. Alan
is correct that we cannot get the data rate down to a practical value
for transmission within the exiting spectrum allocations. This is
equally true for DVD and DTV.
The DVD industry uses compressionists to deal with these spikes. I
have talked with many of these people about the size of these spikes.
It is NOT unusual for the data rate to spike above 25 Mbps during
tough sequences. Unfortunately, the peak channel capacity is about 11
Mbps, perhaps a bit more with good buffering techniques. The same is
true for HDTV - the peaks can routinely spike up to 30 Mbps or more
with the MPEG-2 tools. We have developed a bunch of techniques to
mask these problems. What we cannot do with MPEG-2 is eliminate these
spikes.
I look forward to the day when content producers will assume the
responsibility for compression quality. I would like to see carriage
contracts that specify that the program bits MUST be aired as
supplied - no recompression. This is completely reasonable if we move
to a philosophy of transferring files, rather than trying to managing
concurrent real time streaming. We will always have real-time events
that must be streamed, but the reality is that a large portion of
what we watch today is pre-produced.
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:
