[MEncoder-users] Quick question - advice appreciated
Markus
markus at wearethem.com
Wed Aug 2 13:42:06 CEST 2006
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.
>
>
>------------------------------------------------------------------------
>
>
>
So could you work your way backwards and decode each frame from one
keyframe to the next , and then jump back to the one before it and work
your way back to the current one. Rinse, repeat.
Is there any codec out there by itself that would be suitable for this?
If not, it's mine mine mine you hear me!! I call it! Patent patent
patent! :D
Is there some raw/ugly codec out there that just stores every single
frame like, raw? Then you could just do that index thing or whatever and
play it all backwards along with the audio(whole other baileywick to
reverse as well I imagine, not to mention sync). Then convert -that-
to xvid or divx or whatever.
I like the idea if doing it on the fly too. That would be cool, even if
there was a delay. We could build a tool into mplayer that lets you pick
out a time slice. Even if you have to wait for it to decode it on the
spot, it would be totally worth it.
Wish I knew more about how it all worked...
More information about the MEncoder-users
mailing list