[MEncoder-users] Quick question - advice appreciated

[The Wanderer]

Nicolas George wrote:

> 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).

...??

My understanding from years of reading these mailing lists has been that
AVI does *not* have an index of all frames, but only an index of (at
most) all keyframes (or, at least, all I frames). Handling those frames
for backwards playing is trivial, but P (and, potentially, B) frames
make the issue noticeably more complicated.

> 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).

Yes, I know about that. That's exactly the reason why I didn't think any
existing format or program could do it - and why I'm so bewildered as to
how the program I used back in the day managed the job as well as it did
(especially considering that I was using a *133*-MHz system at the time).

> 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.

As well, transcoding to such a codec would A) increase the upfront
CPU/etc. requirements significantly and B) decrease video quality, while
still requiring the transcoding program to decode each frame and buffer
until either the next known I frame or EOF - and, when starting from a
format or even just a file without a sufficiently complete index (which
definitely exist), that leads to immense memory requirements.

> 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.

...yes... this differs from my One how, exactly? (Except that I somehow
missed mentioning the "decode each frame as you reach it" part -
apparently I was more tired than I realized. I had certainly considered
it when thinking about this issue in the past.)

> 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.

It also requires the buffer-filling every time you try to seek, and has
the potential for significant speed problems if there are memory or I/O
access-speed issues (as I've seen happen on my own current system, with
less-demanding code, rather a number of times).

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.