🚀 go-pugleaf

In article <1992Aug4.190535.16650@aimla.com> you write:
>In article <1992Jul30.015410.5411@ccsd.uts.EDU.AU> ruben@europa.ee.uts.edu.au (Ruben Gonzalez) writes:
>>In article <8LE5E6I@zelator.in-berlin.de>, leo@zelator.in-berlin.de (Stefan Hartmann) writes:
>>|> In <l6ulkqINNjbu@calvin.usc.edu> alves@calvin.usc.edu (William Alves) writes:
>>|> 
>>|> >Does anyone with experience in MPEG have a feeling for how long it takes
>>|> >to encode full-motion, full-screen video, with enough compression to
>>|> >play off a CD-ROM (c. 150k/sec)? I have heard that it would take even
>>|>      [...]
>>|> 
>>|> Hi ,
>>|> I'm using the Xing Technology MPEG encoder, which works from 320x240
>>|> TGA frames .
>>|> It takes 1.5 second per frame to encode to a MPEG-file on a 
>>|> 486 PC (33Mhz) !
>>|> I think this is quite fast and all is done by software only !
>>|> 
>>|> Best regards Stefan Hartmann.
>>|> email to: leo@zelator.in-berlin.de
>>|> 
>>|> 
>>
>>This just seems too incredible to me. I can not possibly see how anybody 
>>can DCT transform a 320x240 frame at that speed on a 486. 
>>
>>Furthermore I can't see how you could do the motion compensation for an entire frame 
>>at that speed. The Motion compensation requires an extensive search around each 8x8
>>pixel block in the image, which amounts to millions of searches just for a single frame.
>>
>>Another problem which has me confused is that MPEG is not defined for Colourmap
>>based images which the Xing encoder must use. (you can't do decent real-time colour
>>quantisation at run time, the images must be pre-quantised, However DCTs do not work
>>very well with colourmapped images)
>>
>>I find it hard to believe that the Xing encoder is really MPEG as per the standard.
>>
>>Ruben.
>
>I agree.  We have a MPEG encoder, which I believe is sun SPARC based, and it
>runs about 100:1. (i.e. 1 second of video takes 100 seconds to encode).
>
>-mike d.

Time out for some rather nit-picky quibbles... having to do with
apples, oranges, etc.

1) The MPEG "standard" is not quite yet a standard (although it's
close).  Compliance testing is still a major headache for the ISO WG. 

2) Stefan was reporting his experience, which is OK, but his answer
has to be interpreted or extrapolated in the light of the difference
between William's original question of *full-screen* CD-ROM bitrates
vs. the Xing subset window at hard-disk transfer rates.

3) MPEG *only* tells you how to DEcode.  It *doesn't* tell you how to
ENcode.  Another way to say this is that it really defines the SYNTAX
of a valid bitstream, and which actions should be taken when
encountering certain bit patterns.  Also, there is considerable
latitude in how many B-frames between I- and P-frames, how many
P-frames between I-frames, etc.  (For a rough analogy, think of the
C source code for performing a certain function, like the Unix 'wc'
for counting lines, words, chars in a file.  There are many possible
VALID C programs which might be written to do this-- they might all
'conform' to both the specification of the language and also 'conform'
to the functional requirements of the user.  But there could easily be
a great diversity in the 'quality' of these different programs, in
terms of storage, resources, execution speed, robustness, etc.  AND in
particular, some of these programs would take perhaps more or less
time to create, or more or less skilled programmers, or other
resources.)

4) So, in a sense, you can spend as much or as little time as you wish
on encoding a frame, as long as the bitstream is valid, it
(theoretically) conforms to the (almost-finished) MPEG standard.
There is no quantitative requirement on how much it looks like the
original video, what color it is, how jerky the motion is, etc.  In
fact, there isn't anything in the current MPEG document which says
that a picture has to be displayed anywhere-- you simply must decode
valid bitstreams and "interpret" them appropriately.  This isn't
really as big a practical problem as it might at first seem.  The
customers will decide pretty quickly what they are willing to buy and
what they will pay for what they get.  

5) You have to remember that MPEG is a *very* low-level kind of
specification.  Think of the standard for putting down bits on a CD.
That says nothing about whether I will like the music on any
particular one, or whether the original master tapes had 300-3000 Hz
bandwidth instead of 20-20 000 Hz bandwidth.  Or the dynamic range.
Or how good my player and speakers are (not to mention my ears!).  BUT
probably close to every CD on the market can claim to meet the
"standard" for getting the bits down, the tracks in the right spacing,
error-correct codes done right, etc. 

So, all of you are pretty much *correct* in your statements, IMHO, but
with some interpretation required.  

I believe a reasonable-quality MPEG encoder for something that meets
the original question takes about 1200-1500 MIPS to do in real-time
(sort-of VAX MIPS; obviously on special-purpose hardware the
instructions per second could be lower).  So if the SPARC in question
is anywhere in the 10-15 MIPS range, then 100 to 1 seems about right.

Is it the Bellcore source code, or something developed elsewhere?
-- 
-- 
Fritz Whittington     Texas Instruments, 12840 Hillcrest #200, Dallas, TX 75230
fritz@csc.ti.com                Office: +1 214 917 7437    FAX: +1 214 917 7487
_Since I am not an official TI spokesperson, these opinions contain no spokes._