What is XviD's "kludge" edition?

[Atamido]

Originally posted by sh0dan
An idea I've been curious about is "I-frames" referencing older I-frames. This could be efficient in many reallife situations, where scenes are shot with two or three different kameras. If a scenechange could reference a slightly older I-frame instead of being an I-frame itself, it might be possible to reduce the amount of I-frames.
This would of course require caching of I-frames and give slightly larger seek time. This exact situation is what prompted a change in the way that Matroska does frame referencing. Originally, there were two bit flags that were used to indicate the type of reference frame. The first one meant the frame was dependant on a previous frame, the second meant that the frame was dependant on the following frame. You could enable them both to indicate dependance on both the previous or following frame.

But, what if you want to do as you are suggesting and reference a frame that is far away? This was an obvious limitation of the design, so the bit-flags were removed, and an new Element was made to indicate the timecode of the frame that it is dependant on. With this design you could reference a frame that is 10 minutes away. You could also reference 5 frames at once. So, this would be very possible to do without any hacks like combining frames.

However, it should be noted that the level of complexity required to do compares for frames that far away is staggering, and not likely to happen any time soon.

[sh0dan]

Originally posted by Pamel
However, it should be noted that the level of complexity required to do compares for frames that far away is staggering, and not likely to happen any time soon.
Not if we are talking about the last 3-5 keyframes. Simple checks like:

if (b_WeNeedIFrame) {
// Size of pure inter-frame
int frame_bits = encode_intra(this_frame);
int use_reference = -1;

for (int i = 0; i < iframes_cached; i++ ) {

// Encode using motion compensated using last I-frames.
int inter_bits = encode_inter(this_frame, cached_frame[i]);

if (inter_bits < frame_bits) {
// this frame is smaller
use_reference = i;
frame_bits = inter_bits;
}
}
}

The above thing should be no problem in DirectShow, and since AVI is already pretty much out of the picture, a new container should be used anyway.

[MfA]

You would probably want to compare-against/use the final decoded images of the last couple of GOPs, rather than the I frames which started them. At least from a coding efficiency point of view, seeking will be a bitch of course.

[temporance]

This is not such a good idea, IMHO.

I-frames make up a very small percentage of total filesize, let's say 2%.

Let's say this idea makes each I-frame 50% smaller (by making them a special sort of P-frame). Ergo, it saves only 1% at the expense of greater complexity.

Percent bits used by I-frames becomes greater where lots of I-frames are improved for quicker seeking. But this idea makes seeking very difficult.

[Atamido]

Originally posted by sh0dan
Not if we are talking about the last 3-5 keyframes. Agreed.

However, if you wanted to do checks throughout the stream, then you could buffer maybe 30 frames, and then check the whole stream for matches, buffer another 30 frames, etc. Of course, that would take forever, and the more ram you had available to buffer, the faster it would go. Of course, you could get clever and only buffer the frames just before and after a scene change. That would drastically speed up this process of creating references to frames that are far away.

@temporance: I had no idea that I frames make such a very small percentage of the total file size. Where did you get this number from?

Edit: Typo. Was talking to my old fiance when typing this.

[temporance]

Originally posted by Pamel
@temporance: I had no idea that I frames make such a very large percentage of the total file size. Where did you get this number from? Hello Pamel,

I presume you're being sarcastic - 2% is about right and most of the time this means I-frame compression isn't too important.

I get my number from experience. Go to "File Information" in vdub and you can get a quick impression from a few xvid or divx files. Very high motion might cause the encoder to insert too many keyframes, so try it with more "average" content.

[shlezman]

I assume (like MFA) that the intresting frames are the last P before the previous I (the last frame before the scene change). So that there's only one additional frame to check.