[XviD-devel] [BUG] First dev-api-4 bug

[Edouard Gomez]

Ok, i've been looking a bit at how the new API returns frame type. I
think the first frame has the wrong type if bframes are used.

How to spot the bug (do a step by step debug of):
./xvid_encraw -i sequence.yuv -w 352 -h 288 -t 0

The first code path does not set stats while the frame is effectively
coded as an IFrame without any delay because of the if(iFrameNum == 0)
test in enc_encode.

If bframes are not used, the first frame is reported as an IFrame.

e.g.

Without Bframes

$ ./xvid_encraw -i /mnt/vrac/test/sequences/hall_monitor-352x288.yuv -w 352 -h 288 -t 0 -quant 4
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003

Frame     0: type = I, enctime(ms) =  65.2, length(bytes) =  12819
Frame     1: type = P, enctime(ms) = 113.3, length(bytes) =   2961
Frame     2: type = P, enctime(ms) = 110.9, length(bytes) =   2725
[...]

With BFrames
$ ./xvid_encraw -i /mnt/vrac/test/sequences/hall_monitor-352x288.yuv -w 352 -h 288 -t 0 -quant 4 -bn 1
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003

Frame     0: type = Not coded, enctime(ms) =  65.8, length(bytes) = 12819
Frame     2: type = I, enctime(ms) = 112.8, length(bytes) =   2973
Frame     3: type = B, enctime(ms) = 245.2, length(bytes) =    482
[...]

As you can see, the frame  is really coded according to the length field
and the  returned value  by the  xvid_encode > 0.  The out_flags  of the
xvid_enc_frame_t structure is set to keyframe too. 

Encoder behavior is not good.  However i know the current xvid_encraw is
not bug free, but i think this is also related to core.

-- 
Edouard Gomez-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://edu.bnhof.de/pipermail/xvid-devel/attachments/20030309/51f04be9/attachment.bin