[opendtv] Re: (no subject)
- From: "Manfredi, Albert E" <albert.e.manfredi@xxxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Wed, 9 Dec 2009 15:07:07 -0600
Dan Grimes wrote:
> I am not an expert on MPEG2 so someone please correct me if I
> am wrong. As I understand it, MPEG2 only specifies the
> components that represent the picture and the overall process
> to how those components are achieved. But it does not specify
> what mathematical formulas, what I am defining as the
> algorithms, are used to achieve those components.
MPEG-2 defines both the transport stream (TS) and an image compression
algorithm. The image compression algorithm is the same one that the ITU calls
"H.262."
Most of the time, when the popular press says "MPEG-2," they are talking about
H.262 compression carried over MPEG-2 TS. H.262 uses only 8X8 block sizes,
discrete cosine transforms (rather than FFT), and floating point arithmetic.
And when the popular press says "MPEG-4" related to TV, they are usually
talking about H.264 compression, also carried over MPEG-2 TS. (They call this
MPEG-4 only because AVC/H.264 is filed under MPEG-4 Part 10.) H.264 uses
variable block sizes, an integer transform which approximates the DCT, and
integer arithmetic.
So, if you change the compression algorithm, you are going to be changing the
way the image is encoded, EVEN IF you might be keeping the same MPEG-2
Transport Stream as your link layer technology.
> In defining the terms, is it proper to define an overall
> encoding process or standard as an algorithm or is the
> mathematical formulas within each process the real algorithm,
> or are both?
I'd say that the algorithm IS the mathematical formulas, and they are certainly
part of the encoding process. The encoding process also includes other things,
like creating standard packet sizes, forward error correction techniques,
standard IDs in packet headers to identify the packets, max/min packet rates,
image frame rates, pixels per image frame, and so on.
> Now, I realize that these improvements have already been
> taking place for decades, that we are getting ever closer to
> the theoretical limit of MPEG2, and that the changes in the
> processes do not bring dramatic change at this point. And I
> am not suggesting we could or should get 1080/60P within ATSC
> as it stands (I believe this was the original proposal that
> created the discussion). I am merely suggesting that
> pre-filtering, or tweaking the standard's defined variables
> (e.g.,GOP length), is not the only way to get more pixels/time
> or PSNR within a target bit-rate.
If we stick with ATSC, then in the basic ASTC streams (i.e. not talking about
M/H), you're constrained to using H.262 compression. That means, DCT, 8X8
blocks, floating point, zig-zag pattern, etc. There is wiggle room, and the
encoders are improving. But when you say "different mathematical formulas,
variables, number standards, etc." that will usually constitute a different
compression algorithm, ergo different encoding process.
So IMO, if you are going to allow 1080/60p over ATSC, might as well only do
that when you add H.264 compression in the "main" ATSC streams. No sense going
through the pain of a new encoding standard without at the same time updating
the compression algorithm in that standard.
Bert
----------------------------------------------------------------------
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:
