[MEncoder-users] Quick question - advice appreciated

[Nicolas George]

Le quintidi 15 thermidor, an CCXIV, The Wanderer a écrit :
> One: Scan through the entire part which is to be played backwards,
> building an index of all the video frames (this is CPU-intensive,
> potentially memory-intensive, and would need to be repeated every time
> the file was loaded afresh), and then play that index backwards.
> 
> Two: Re-mux to a container which provides not only a "location of next
> frame" but a "location of previous frame" (this would require doing the
> index-building part of One, above, but only as a one-time step).
> Unfortunately, as far as I know no such container exists.

It is not as simple as that. Otherwise, it would be very easy, since your
solution one is already implemented (AVI, for example, has an index of all
frames).

But knowing where the previous frame is is not enough. Most efficient video
codecs use temporal compression (similarity between neighboring frames)
added to spatial compression (similarity between neighboring pixels).

To achieve real-time decoding, the temporal compression uses the frames in
an ordered, and roughly chronological way: each frames depends on the
previous one, which in turn depends on the previous one, and so on.
Sometimes, there is something like: frame n+2 depends on frame n, frame n+1
depends on both frame n and n+2, and subsequent frames do not depend on
frame n+1; if I am not mistaken, such frames are called B-frames; their
decoding can be safely skiped to speedup the decoding.

Anyway, to decode a frame, you have to decode most of the frames coming
before it. You have to do that either from the beginning of the video, or
from a frame that happens not to depend on any other frame. Such frames are
called keyframes, or I-frames. Keyframes are seek points in a video. Codecs
try to put keyframes at scene changes, both because it is a convenient place
to have a seek point, and because it is a place where temporal compression
does not help a lot.

There are some non-temporal codecs, the most common being probably DV,
another one being MJPEG (which is _not_ MPEG). But their bitrate is much
higher for a given quality.

So, to play a video backward, you have to start at the last keyframe, decode
every frame to the end and store the result in memory, then play them in
reverse order, and start again at the previous keyframe.

It can be done, and it can even be done in real-time, with just a burst of
buffer-filling at the start: it is possible to decode the next bunch of
frames while the previous is being displayed, and on the average, it
requires only to be able to decode one frame for each displayed frame.

On the other hand, it requires a lot of memory. For DVD-style MPEG2, there
are keyframes every half second or so, so a buffer of about 10 megabytes is
enough. On the other hand, DivX-style videos have only keyframes every 10
seconds or so. That is quite ok with nowadays computers with their enormous
amounts of memory, but it would have been just a few years ago.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 185 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mencoder-users/attachments/20060802/f9da45eb/attachment.pgp>