Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

interactive mpeg?

0 views
Skip to first unread message

Gordon Graber

unread,
Apr 21, 1997, 3:00:00 AM4/21/97
to

Hi,
I'm looking for information on the interactive nature of mpeg.
Specifically, does an mpeg animation contain the information necessary to
make it frame/time code addressable. That is: can I ( with the right
software ) jump randomly to any frame or point in time in an mpeg-1
animation, i.e. does mpeg-1 allow "random frame access".
Other questions might be, what would the right software be to allow
this?
If not mpeg-1, does the mpeg-2 spec make provisions for this?
I have perused a myriad of mpeg related web sites only to find no
information on this subject.
My impression is the mpeg-1 is sequential access only.
Am I correct about this? ( I don't want to be! )
Thanks for any ideas or help,
Gordon Graber - programmer
ggr...@blue.weeg.uiowa.edu

Maynard Handley

unread,
Apr 22, 1997, 3:00:00 AM4/22/97
to

In article <5jg4t8$g...@flood.weeg.uiowa.edu>, Gordon Graber
<ggr...@blue.weeg.uiowa.edu> wrote:


My QuickTime MPEG Extension <http://www.quicktime.apple.com>
(currently PowerMac only, but will possibly be part of QuickTime 3.0 for
Windows when that's released)
allows one frame-accurate random access (including backward playback and
backward stepping) of MPEG-1 streams in exactly the same way as any other
QuickTime Movie. This makes it easy to do what you want as either a user
or programmer.

To answer your question more generally, MPEG-1 does not contain this
information and MPEG-2 is no better. Such info as MPEG-1 and MPEG-2
streams contain is pretty much useless, either because it does not give
what you really want, or because half the encoders out there screw it up
and use the wrong values so you can never trust it.
Coding this sort of random access is a large project using quite a few
different tricks precisely because you, the programmer, have to do pretty
much everything with MPEG giving precious little help.

Maynard

--
My opinion only

Denis McLaughlin

unread,
Apr 23, 1997, 3:00:00 AM4/23/97
to

In article <handleym-220...@handma.apple.com>,

Maynard Handley <hand...@apple.com> wrote:
>In article <5jg4t8$g...@flood.weeg.uiowa.edu>, Gordon Graber
><ggr...@blue.weeg.uiowa.edu> wrote:
>
>> Hi,
>> I'm looking for information on the interactive nature of mpeg.
>> Specifically, does an mpeg animation contain the information necessary to
>> make it frame/time code addressable. That is: can I ( with the right
>> software ) jump randomly to any frame or point in time in an mpeg-1
>> animation, i.e. does mpeg-1 allow "random frame access".
>> Other questions might be, what would the right software be to allow
>> this?
>> If not mpeg-1, does the mpeg-2 spec make provisions for this?
>> I have perused a myriad of mpeg related web sites only to find no
>> information on this subject.
>> My impression is the mpeg-1 is sequential access only.
>> Am I correct about this? ( I don't want to be! )
>> Thanks for any ideas or help,
>> Gordon Graber - programmer
>
>To answer your question more generally, MPEG-1 does not contain this
>information and MPEG-2 is no better. Such info as MPEG-1 and MPEG-2
>streams contain is pretty much useless, either because it does not give
>what you really want, or because half the encoders out there screw it up
>and use the wrong values so you can never trust it.
>Coding this sort of random access is a large project using quite a few
>different tricks precisely because you, the programmer, have to do pretty
>much everything with MPEG giving precious little help.

Hmmm, I'm not sure I agree with this.

Both MPEG1 and MPEG2 streams use three types of frame encodings: I,
P and B. An I frame is intra-coded: it is essentially a compressed
image, with no dependencies on any frame that comes before or after
it. A P frame is a predictive frame: it is encoded by storing the
differences between the P frame and the most recent P or I frame. A B
frame is a back-coded or bidirectional frame: it involves computing the
difference between the immediately previous and subsequent I or P frames.

I frames have a relatively large encoded form, since they're an
actual full (though compressed image), but require relatively little
computation to decode. A P frame has a better compression ratio than
an I frame, but requires more computation, since to decode it you
must decode and store a previous frame, and then decode and apply the
differences stored in the P frame. The B frames have an even better
compression ratio, but require the most computation to decode, since
they require that both a previous and a subsequent frame be decoded and
stored, and then the B frame differences applied.

A typical encryption pattern for the software MPEG encoders I use
is something like: IBBPBBPBBP. That is, frame 1 is stored as an I
frame, and then frame 4 is stored as a P frame, based on frame 1. And
then frames 2 and 3 are stored as B frames, based on frame 1 and frame
4. Note that because of the dependencies of one frame on another, the
encoded frames are actually stored in the MPEG stream as 1-4-2-3.

So, what the heck does any of this have to do with random access
in an MPEG stream? Well, essentially, all MPEG streams are randomly
addressable, given time and computation enough, since all you have to
do is decode the targetted random frame, exactly as if you were playing
the animation. In practice, randomly jumping to a frame may incur more
work than may be the case with other systems, since jumping to a B frame
involves decoding 3 frames to arrive at the one you want. However,
it is quite straightforward to jump to an I frame.

On top of all this, MPEG supports GOPs, or groups of pictures. This
is a higher level 'packaging' of frames, specifically intended to allow
for easy random access to MPEG streams.

All of the above comes modulo my relative ignorance of MPEG: lots more
information can be had in excruciating detail at:

http://www.mpeg.org/~tristan/MPEG/starting-points.html


Denis

Gordon Graber

unread,
Apr 24, 1997, 3:00:00 AM4/24/97
to

In article <5jl4v6$5...@bmerhc5e.bnr.ca> Denis McLaughlin,

den...@nortel.ca writes:
>All of the above comes modulo my relative ignorance of MPEG: lots more
>information can be had in excruciating detail at:

Thanks to both of you, Maynard and Dennis for the info. I have been to
the above site with little luck. Too much information to easily sift
through. I have printed out several detailed explanations of mpeg from
different sources, but none mention anything about interactivity and
frame or time based access.
Another question I need an answer for is, if mpeg does allow some form
of interactivity, as Dennis indicates, are there any APIs that would make
programmatic access possible? Or am I going to have to roll my own?
Maynard says he has quicktime utility that might allow this. We are
looking to roll this into a web based strategy. We want to deliver video
across the web with parameters passed to the video telling it where to
start playing and so on.
Any ideas on how this might be looked at?
Thanks for any help,
Gordon Graber ggr...@blue.weeg.uiowa.edu

Denis McLaughlin

unread,
Apr 25, 1997, 3:00:00 AM4/25/97
to

In article <5jodgk$o...@flood.weeg.uiowa.edu>,

Gordon Graber <ggr...@blue.weeg.uiowa.edu> wrote:
>Thanks to both of you, Maynard and Dennis for the info. I have been to
>the above site with little luck. Too much information to easily sift
>through. I have printed out several detailed explanations of mpeg from
>different sources, but none mention anything about interactivity and
>frame or time based access.
> Another question I need an answer for is, if mpeg does allow some form
>of interactivity, as Dennis indicates, are there any APIs that would make
>programmatic access possible? Or am I going to have to roll my own?
> Maynard says he has quicktime utility that might allow this. We are
>looking to roll this into a web based strategy. We want to deliver video
>across the web with parameters passed to the video telling it where to
>start playing and so on.
> Any ideas on how this might be looked at?

Well, from the perspective of a confirmed Unix bit-head, I would just
grab the sources to the Berkeley MPEG decoder and start hacking. Shouldn't
be that hard, you could even do some interesting things like creating a
GOP or I frame index, storing the stream offset for specific frames.

But if you're looking for something more commercial, you might want to
try talking to folks that deliver commercial solutions, to see if they'll
contract for the functionality you want. I think the folk at www.mpegtv.com
are pretty all-round cool types (mostly because they have a port for Linux),
you might want to talk to them.


Denis

0 new messages