[MEncoder-users] Quick question - advice appreciated

[Markus]

Markus wrote:

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


Oops - sorry for that last top post. I think my wireless mouse repeated 
a paste a buch of times after I moved the reciever.

Hey, it's 3am here. ;)