How to "stabilize" an Xvid/DivX video?

[Vivaldi]

This isn't a speciffic problem he's trying to figure out. It's just a general question as to the actual, technical, why divX doesn't work. And why it's compatibility changes. Get it? he just wants to know why.

I suppose someone could just ask zero1 to come in here and write a page or so in the most complex technical jargon that explains it perfectly, but to understand it you need to have taken a grad-level course on video encoding algorithms.

It'd shut up the threads where people insist on proof alot quicker, whether they actually understand it or not.

[Zero1]

Well the reason DivX and XviD don't work well for editing, along with any other inter frame codecs as Kalium pointed out, is simple. It's just the nature of the compression. In most instances you have 3 different types of frame, I-frames, P-frames and B-frames. Now you don't always need B-frames to break things, you can do that fine just using I and P frames, but B-frames adds to the failure.

I-frames are intra frames. These are for lack of a better word, standalone frames meaning they can be decoded as is, just like still image formats, which makes them ideal for editing.

P-frames are predicted frames. A crude description would be that these frames contain the difference from the previous frame and "overlay" it. Take a news reader for example. You have an image that is mostly static but only their head and mouth moves any reasonable amount. An I-frame would store the full image, then the P-frame would store what has changed since that I-frame, so for example in a perfect world it would only store his mouth movements and apply that over the previous image. This obviously saves space because you are only coding stuff that changes.

B-frames are bi-directionally predicted frames. Without getting too technical, they rely on information from other frames too and due to their nature, require more processing power to decode than I or P-frames. In addition to this, B-frames are not properly supported in AVI. They exist by way of a hack. One hack is to read X amount of frames and display Y amount of frames, creating a frame lag. Normally it's not much of a lag, 2 frames usually, but for H.264 it can be a huge lag. The point is, you don't want lag in your AMV or it will not sync. The other hack is to pack frames together. VfW has a one frame in, one frame out limitation, so in order to gain the information required to decode a B-frame, you need to pack the B-frame with another frame so they get forced to the decoder at the same time. This is obviously not good either.

Well now that we know that P and B frames rely on previous and future frames for the information to decode them, that gives us something to work on. What would happen if you removed the previous frame and it happend to be that a P-frame needed to reference that frame? (remember because a P-frame only contains the difference and not a full image). Well you wouldn't have anything for that P-frame to reference, so you would get a garbage image, or the decoder and/or editing software would hang/crash/explode taking your house with it.

Now I won't even go into the differences between coded and displayed order of frames or H.264, but let's take this sequence of 14 frames for example.

I P B B P B B P B B P B B P

It could be the start of a scene change, and you want to cut out a few of the frames. Let's say after the scene change, you want the sequence starting after frame 6 (An I-frame usually gets coded for the first frame after a significant scene change). With your razor tool, you would need to cut the stream as below:

I P B B P B | B P B B P B B P

But here is where you can hit a problem. With the sequence cut and the excess deleted, it means where you cut it starts with a B-frame which requires information from the previous B-frame (which is gone), the P-frame before that (which is also gone) and so on until you reach the I-frame. It has to work it's way back to the I-frame, then work forward applying the changes of all the frames until it reaches the frame you requested. This can be slow (as you might expect having to seek back and then forward) and unstable.

Providing the decoder is decent, you may get away with this, but it's not ideal. As I mentioned earlier, we also have the problem of B-frames. This is probably more likely to mess up something like Premiere with the frames being packed, out of order or laggy. I know that the XviD out wasn't working last time I tried.

In short, avoid editing with codecs you would usually use for distribution. This includes MPEG-2 since that also has P and B-frames. MPEG-2 might not be as bad because the container was designed to handle B-frames, and also you can serve it via AVISynth, which may be an option for DivX/XviD, but a slow and risky one.

It is possible to create editable XviD videos, but if you already figured out how to do that then you probably already knew of the problems and hence looked for that possibility. I won't tell you how because it will spread around that "Wow, Zero1 says you can edit with XviD", people will be trying to use already compressed episodes and suffering the problems since they were encoded for viewing rather than editing. Even if I did tell you how to do it, it would require re-encoding the videos (which it sounds like you are trying to avoid by editing directly), plus it would decrease the quality slightly (perhaps barring bait and switch if it would work with all what I said above).

The short answer is edit with DivX/XviD if you wish, but expect problems. If you get problems, don't complain about them because you were warned. Explore the possibility of using AVISynth if you are really strapped for space, or just convert to lossless like everyone else. If you have a good disk speed or RAID array, editing is a breeze.

[YennoX]

I admit defeat. My question has been answered I suppose.