[MEncoder-users] Quick question - advice appreciated

Wed Aug 2 12:50:57 CEST 2006

 Wow that's cool!  I'm just glad to know that I didn't miss some obvious 
button or setting. I did grep the man page and google around a bit(the 
googles, they do nothing!).

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).
>
>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.
>  
>
>  
>
That all sounds good. So any suggestions on what would a command line or 
set of mencoder commands look like for accomplishing all that on a given 
file?