A: All inquiries should be addressed to the MBC e-mail
firstname.lastname@example.org. Provide your name, title, company name,
address, e-mail address and your phone number. Write any questions in
Q: How can I join MBC?
A: Send your request with the above information to the same
e-mail address as above. You should also provide some indication of
the resources you have available, and you should be prepared to
accept the MBCís mission, goals, scope, and general bylaws (when
constituted), as well as be able to pay the fees.
Q: Can I just "audit" MBC's activities?
A: At the moment there are no secondary or tertiary
classes of MBC membership. Membership fees are $2,500 for GPC
membership, and another $2,500 (initial fee) specifically earmarked
for MBC activities. Fees might be raised or reduced as MBC officers
and members deem fit. Anyone is welcome to sit in on MBC meetings,
but without a membership you cannot vote, cannot dominate the meeting
discussion, and will probably not be fed by the host company. :-)
Q: How often are meetings held and where?
A: Meetings are held about once a month and are sponsored
by a member company in its hometown. Past meeting sponsors have been
Hewlett-Packard, Sun Microsystems, and Motorola. Send e-mail to
to request a list of upcoming meetings and locations.
Q: Is this a North America-only club?
A: Absolutely not. MBC is an international organization and
includes participants and technologies from Europe and Asia.
Q: How are you going to benchmark MPEG-2?
A: A number of technical sessions have been held in which
member companies have presented ideas on not only how to benchmark
MPEG-2, but also on how to deal with quality and reporting
considerations. MBC does not believe that there will be impossible
obstacles to overcome to develop appropriate benchmark(s) for MPEG-2,
but significant technical work remains to be done.
Q: Will this be an application-, functional-, or
system-level benchmark? What will be measured?
A: By group consensus, the MPEG-2 benchmark will be a
system-level benchmark that will test, at the very least, processor,
memory system, and graphics capabilities. The benchmark will
not, however, specify how MPEG-2 will be delivered, or
the platform on which it will be delivered. Companies can determine
the best way to deliver full-motion video and audio
(AC-3/MPEG-2/MPEG-1 Level 2, depending upon licensing issues), and
they get to define the term "best" (i.e. cheapest, highest quality,
or whatever). The benchmark will specify quality levels and provide
guidelines for MPEG-2 ISO compliance.
Q: Will I be able to use your benchmark to compare different
computer systems running MPEG-2 to determine which ones provide
A: That is the intention, but "better" might mean " good
enough for the money," "better-quality picture without dropping
frames," "how many frames can this machine pump through without
dropping a frame," or any number of other measurements that are being
decided upon by MBC members.
Q: How can you ensure that a benchmark will run on all
A: We can't. Platforms that donít even exist now might
become mainstream in just a few years; such is the nature of
multimedia. What we can say is that itís up to each member company to
port the benchmark to its platform of choice, and itís up to all
member firms to make sure that the benchmark is as portable as
possible given time/schedule pressures. Initially, it is expected
that the MBC MPEG-2 benchmark will run on Windows NT, MacOS, Windows
95, various versions of UNIX, VRTX, OS-9000, and perhaps others.
Viable ports will be determined by whether a reference MPEG-2 decoder
can be executed on the platform to verify conformance, and whether
the YUV, RGB, and/or video screen (LCD or CRT) can be accessed for
Q: What technologies do you expect to address in the MPEG-2
A: Initially, we will focus on MPEG-2 (including MPEG-1)
decoding with AC-3, MPEG-2, and/or MPEG-1 Layer 2 audio. Weíll
concentrate primarily on Main Profile at Main Level (MP@ML)
attributes that support up to 15 Mbps and will support Low profiles
as well. There will be a maximum of 720 horizontal pixels for MP@ML.
In the computer space, we are examining 256, 65,536 and 16-million
colors, and MPEG-1 and MPEG-2 resolutions for NTSC and PAL. In the
consumer space, we are looking at 12 bits/pixel (4:2:0) color at the
same resolutions as those under consideration for computers. The next
step will be improvements, updates and fixes to the MPEG-2 benchmark
in version 1.1. Version 2.0 will address video teleconferencing.
Q: What other technologies are under consideration for
A: In addition to those listed above, MPEG-2 encoding,
speech recognition, 3D positional sound, 3D entertainment-oriented
graphics, and multimedia Java-enabled Web pages.
Q: What process is the MBC using to select
A: We are using discussion, consensus, and ultimately a
vote of the member companies. It may be possible that benchmarks
developed from outside the committee will be submitted to the MBC. In
that case, the MBC would assume more of an evaluation role.
Q: You include "multimedia Java-enabled Web pages" in your
list of technologies you expect to address. Will this overlap with
A: No. SPECjava will benchmark Java performance, which means essentially benchmarking the computing platform, as well as the Java virtual machine, the browser, and perhaps the just-in-time compiler. It might include a component of video, perhaps even MPEG-2, in which case MBC is in a position to use its video expertise to assist SPEC with technical issues. SPECjava's MPEG-2 benchmark subcomponent is contained within a very precise environment (Java); MBC's is designed not to be constrained. The MBC's reporting rules and comparison metrics will not be similar to SPECís, and our benchmark(s) should be able to test MPEG-2 on web browsers, NCs, PCs, pocket MPEG-2 devices and other systems across OSs, microprocessors and other computing environments. The other key difference is that MBC will work on benchmarks in other multimedia technologies and application spaces, such as video teleconferencing. The MBC will work cooperatively with those developing SPECjava and we look forward to sharing technology and techniques with other SPEC groups.