[mpeg2] Re: docs

[Warren Young <warren@etr-usa.com>]

Kees Cook wrote:
> 
> Gah.  How wonderful to have open standards that cost money.

The process of making those standards wasn't free.  Hell, they already
con all the participants into paying their own way to all the venues (or
getting their companies to pay, more like).  The costs that are left are
the administrative ones of running the ANSI and ISO organizations.

> > For this simple task, you might find a copy of the Mitchell book more
> > approachable.  It can be had for about $120.  It doesn't replace the
> > MPEG standards, but it's a whole lot easier to read.
> 
> Maybe I can skim it at Barnes and Noble...

I would be most impressed if you pulled that off.  :)  MPEG is not
simple, even at the limited level you're talking about.

> Okay, cool.  I was under the impression that the B and P frames might
> forward-reference a starting I-frame.  But GOP boundries makes sense.

There are such things as non-closed GOPs, which you'll have to handle. 
My previous message only considered the simple case of all GOPs being
closed -- i.e. independent.  This isn't very a common situation,
actually.

> "playback"?  Or decode view?  The _visual_ playback should be IBBP, right?
> (And, by the way, if the decode view is IPBB, why isn't the stream IPBB?)

Sorry, I got that backwards.  IPBB is the way the frames appear in the
file, but they're decoded IBBP.  The reason is that the B frames --
being "bidirectional" -- depend on the surrounding I frame and P frame
(or a pair of P frames farther on in the GOP) so the P frame has to be
sent ahead of the B frames that depend on it.

If the GOP isn't closed, the final B frame depends on the I frame
leading the next GOP.  If the encoder supports non-closed GOPs, you can
often ask it to close some or all of the GOPs.  This either makes the B
frame use forward prediction only (making it like a P frame) or makes
the encoder replace the last B frame in the GOP with a P frame.  Failing
that, you could probably keep the subsequent I frame, as you originally
suggested.

> Now, if I "reverse engineer" the MPEG formats I'm interested in, and
> "publish" this documentation, will ISO trying to beat me up?  

No.  They're just trying to recoup the administrative costs of making
standards.

There _are_ patents surrounding MPEG, but those only (?) affect people
writing MPEG video encoders.  I seriously doubt you'll have any
problems.  (There's also the MP3 issue, but that's encoder-related as
well, and most MPEG streams use MPEG-1 audio layer 2 ("MP2"), not layer
3.)

> Because I
> can't believe I'm the only person trying to find details on MPEG file
> formats.

Most people who are building MPEG software find a way to make some money
at it, so spending a few hundred bucks on documents is no big thing. 
It's really not much different from buying O'Reilly or FSF books, to
help support the community.  Sure, these ISO standards are a _tad_ more
expensive <grimmace> but they're also absolutely authoritative.  They
took many person-years to hammer out, and the market for them is small. 
I think the prices are justified.
-- 
= MPEG articles: http://tangentsoft.net/video/mpeg/
= 
= ICBM Address: 36.8274040 N, 108.0204086 W, alt. 1714m