possible divx5 bug: last frame a packed PB without N?

[bond]

i noticed some strange behaviour with two different tools (mp4box and 3ivx mp4 muxer) able to unpack packed bitstreams as outputted by divx5.1.1

the behaviour is that mp4box, after unpacking, outputs 1 frame more than there is in the input avi
now the author of mp4box and 3ivx meant that it might be possible that the stream ends with a packed PB frame without a N-vop (meaning the stream outputted by divx5 has one frame too few)
now if mp4box unpacks the PB, but has not N to remove, the stream will have one frame more than the input!
any opinions on that?

mp4box detects the n-vops via the "not coded" flag afaik

[tripnotik]

This is the same problem I mentionned in the thread on MP4Box. The problem is that when encoding in VFW, the codec never knows where the stream ends.

For example, when the encoding program reaches the end of the stream (there is no more input frames to feed the codec), because of the delay with b-frames the codec has not outputted the last frame. In order for the codec to output a frame, you have to give it something to encode. So the encoding program feeds it the last frame again until the encoder has nothing to output.

So the problem occurs when the last frame is encoded as a b-frame. That is why you say that there is a N-VOP missing. The codec didn't know the stream was ending and was planning to output the N-VOP the next frame. If you encode a simple test clip made with ColorBars in avisynth, you will see that the problem only occurs when the clip has an even number of frames (meaning the last frame would be a b-frame, assuming that there is only 1 I-frame).

Anyway, I hope I made sense. I've never been good at explaining things.

[bond]

thanks a lot for the explanation! :)