DivX5 frames look different viewed "forward" or "backward"??

[Mentar]

I have a very very weird behaviour in one encode of mine. The settings were DivX5 2-pass with GMC and b-frames on at default values. During playback of the avi I noticed that there seemed to be occasional "flashes", so I reopened it in virtualdub and stepped through the movie frame by frame.

Now the surprise came. Stepping forward, I saw that one frame was blended between the original "correct" one and a ghost frame from some time ago. But this "ghosted" frame only appeared while stepping "forward" screen-wise. When I reached the frame by stepping "backwards" in Virtualdub, the ghosting did NOT appear.

How could the very same frame look different depending on whether you saw it forward or backward? Is this a codec error of b-frames?

I verified that the avs source was clean. It looks identical to the non-ghosted "backwards" frame.

Did anyone of you experience a similar behaviour? How can I get rid of this stuff? (I'll try another encode without b-frames for now)

[muralin]

something very similar happened to me.

i encoded Toy Story 2 - GNot, Vdub 2pass, Nandub for muxing video & audio

when i am in Nandub and drag the slider to a particular key frame (let us call it x), i see a picture. if i move forward to the next few key frames and go backwards, i see a different picture at frame x. weird. had never seen it before. I can reproduce this consistently.

[Ecuador]

Same here. Cutting and joining AVIs with B frames in VirtualDub has become a somewhat frustrating experience... A new version of VirtualDub that can solve this would be very welcome.

__________________
Ecuador.
http://www.geocities.com/ecuador_gr

[MaTTeR]

I'm seeing this as well with Vdub 1.4.9 and NanDub. This makes my comparison tests very hard to say the least;)

[Acaila]

I think that's to do with the fact that the B-frames are stored in front of the P-frames in the file, but during playback they are behind the P-frames.

So when you go forward in VDub you're seeing the sequence as it is played back normally, i.e. ->IPBPBI etc.
But when you search backwards you'll see the sequence as it is stored in the file, i.e. IBPBPI.

And I can imagine that would be really frustrating to watch :)

[Snollygoster]

Same Thing here but when you play the movie everything is being displayed perfectly.

[hippoth]

this behavior has nothing to do with b-frames and so on...it´s just a codec "error" ...virtualdub can´t manage it correctly since divx 5 is installed...I had the same prob with virtualdub 1.4.9 and a divx 4.12 (!!!) movie.
We need a correction of the codec or a new virtualdub :o)

[Ecuador]

Well, seems hippoth is correct... The same effect on my DivX 4.12 rips. Calling Avery Lee to the rescue! :)

[librex]

ok then, so I guess the only solution is to remove Divx5 altogether and go back to 4.12.

I can confirm that it has nothing to do with the bi-directionnal encoding as i've encountered this problem on both version (with bi-direct and w/o bi-direct) of my latest rip.

It's now almost impossible to split an AVI file in a clean way as you cant really find a valid keyframe (a real scene transition frame). For example, on my rip, when I finally found a keyframe that seemed to be ok, the first part of the AVI was playing almost 10 seconds past that frame and second part didnt start at the expected time either.

One final question: can you "force" a specific frame to become a keyframe (with VirtuaDub or Nandub for example?). As I understand it, this would not change the number of frames nor its sequencing and would only add some data to the overall AVI. Of course, you would have to re-encode the subsequent frames (up until the next key) but it something feasible isnt it?

Thanks for your answer (i'll post this question in the virtualdub forum too just to make sure..)

-librex-

[Acaila]

I've never seen this weird behaviour of DivX4 with VDub 148, can you confirm that both 149 and 148 do this? Or is it just 149?

[librex]

this behavior is specific to DivX5 (w/ or w/o bi-directionnal encoding). I've never seen this problem with DivX 4.11 or 4.12.

I tested with vdub 1.4.8 and it's the same problem. Must be related to the way the codec orders the keyframes.

It's very odd that when I go backward with vdub or nandub, the displayed output is completely wrong. And even if I dont seek keyframes backwards, cutting is never clean afterwards (the avi doesnt stop on the keyframe).

[GAteKeeper]

Originally posted by Acaila
I think that's to do with the fact that the B-frames are stored in front of the P-frames in the file, but during playback they are behind the P-frames.

So when you go forward in VDub you're seeing the sequence as it is played back normally, i.e. ->IPBPBI etc.
But when you search backwards you'll see the sequence as it is stored in the file, i.e. IBPBPI.

And I can imagine that would be really frustrating to watch :)

Grr, how many times:

B-Frames are bidirectional motion estimated off the adjacent frames and as such require them to be encoded and decoded before the B-Frame itself.

In playback the B-Frame is displayed before teh corresponding P-Frame but that same P-Frame has already been decoded as the B-Frame is predicted off it and so requires the frame to already be decoded.

i.e. in decoder: 1I 3P 2B 5I 4P 6I
But in display: 1I 2B 3P 4B 5P 6I

It is stored with the P-Frame first because this is how i comes out of the encoder and how it needs to be accessed.

GK