[XviD-devel] [CVS Commit] xvid_encraw

[suxen_drol]

On Sun, 9 Mar 2003 11:57:30 +0100 Edouard Gomez <ed.gomez at free.fr> wrote:
> Hmmm i have one question about the new API
> 
> In xvid.h we can see this comment:
> <quote>
> when bframes>0, you must pass _two_ of these to xvid_encore()
>      ie. xstats[2]; xvid_encore(..., xstats)
>      coding_type==XVID_TYPE_NOTHING if the stats are not given
> </quote>
> 
> But if  i have a cross reading  eye overthe encoder.c file,  i don't see
> where the second xvid_enc_stat_t element  is used. As i don't undertsand
> why  we need  this, could  you pete  explain why  2 elements  are needed
> there?

oops, this is a comment from an older api experiment of mine.
two elements are not needed.
i have removed the comment.


On Sun, 9 Mar 2003 12:33:42 +0100 Edouard Gomez <ed.gomez at free.fr> wrote:
> 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.

this is correct behaviour, the api deliberately seperates bitstream-statistics from
frame-statistics.

* bitstream-stats comprises of the encore() return value and out_flags
and are returned in bitstream-order.
* frame-stats comprises of the xvid_stats_t fields and are returned in
display order.

when we encode with max_bframes=0, encore will return bitstream-stats
and frame-stats are syncronized. below is my modified xvid_encraw.
fields on the left-hand-side of the pipe ("|") are bitstream-stats, and
fields on the right are frame statistics.

----------------------------------------------------------------------
C:\xvid\stable4\examples>..\build\win32\bin\xvid_encraw -t 0 -bn 0 -w 352 -h 288
 -i \download\video\mpeg4\yuv\foreman_cif.yuv -quant 4 -m 5 -n 9
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003

Frame    0: key=0, time= 220.0, length =  14879 | type = I  length =  14879
Frame    1: key=0, time= 280.0, length =   8368 | type = P  length =   8368
Frame    2: key=0, time= 330.0, length =   8673 | type = P  length =   8673
Frame    3: key=0, time= 220.0, length =   6966 | type = P  length =   6966
Frame    4: key=0, time= 160.0, length =   8391 | type = P  length =   8391
Frame    5: key=0, time= 170.0, length =   8233 | type = P  length =   8233
Frame    6: key=0, time= 160.0, length =   5587 | type = P  length =   5587
Frame    7: key=0, time= 170.0, length =   8853 | type = P  length =   8853
Frame    8: key=0, time= 160.0, length =  12608 | type = P  length =  12608
Avg: enctime(ms) = 207.78, fps =   4.81, length(bytes) =    9173
----------------------------------------------------------------------

when bframes are enabled the syncronization is lost:
we could return the frame type immedialtey for the first frame. its an
additional "special" case. 

----------------------------------------------------------------------
C:\xvid\stable4\examples>..\build\win32\bin\xvid_encraw -t 0 -bn 2 -w 352 -h 288
 -i \download\video\mpeg4\yuv\foreman_cif.yuv -quant 4 -m 5 -n 9
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003

Frame    0: key=0, time= 220.0, length =  14879 | type = N
Frame    1: key=0, time=  60.0, length =      0 | type = N
Frame    2: key=0, time= 380.0, length =  11531 | type = I  length =  14879
Frame    3: key=0, time= 600.0, length =   1797 | type = B  length =   1797
Frame    4: key=0, time= 110.0, length =      0 | type = N
Frame    5: key=0, time= 220.0, length =  12339 | type = P  length =  11531
Frame    6: key=0, time= 550.0, length =   2510 | type = B  length =   2510
Frame    7: key=0, time= 610.0, length =   2392 | type = B  length =   2392
Frame    8: key=0, time= 270.0, length =  14926 | type = P  length =  12339
Avg: enctime(ms) = 316.67, fps =   3.16, length(bytes) =    6708
----------------------------------------------------------------------

when bframes are enabled with PACKED mode, the bitstream-stats change
dramatically. frame-stats are more synchronized, because packed mode is
does not require delay.

Note: there appears to be a bug with the first packed frame-stats...

----------------------------------------------------------------------
C:\xvid\stable4\examples>..\build\win32\bin\xvid_encraw -t 0 -bn 2 -w 352 -h 288
 -i \download\video\mpeg4\yuv\foreman_cif.yuv -quant 4 -m 5 -n 9 -p 1
xvid_encraw - raw mpeg4 bitstream encoder written by Christoph Lampert 2002-2003
**XVID_PACKED

Frame    0: key=0, time= 110.0, length =  14895 | type = I  length =  14895
Frame    1: key=0, time=   0.0, length =      6 | type = I  length =  14901
Frame    2: key=0, time=1100.0, length =  13328 | type = B  length =   1797
Frame    3: key=0, time=   0.0, length =      6 | type = P  length =  11537
Frame    4: key=0, time=  50.0, length =      0
Frame    5: key=0, time= 720.0, length =  14849 | type = B  length =   2510
Frame    6: key=0, time= 550.0, length =   2392 | type = B  length =   2392
Frame    7: key=0, time=   0.0, length =      6 | type = P  length =  12345
Frame    8: key=0, time= 820.0, length =  17811 | type = B  length =   2884
Avg: enctime(ms) = 366.67, fps =   2.73, length(bytes) =    7032
----------------------------------------------------------------------

Ed: the the encoder returns delay only when neccessary. it could be
modified to fill the up queue initially. this might the encoder output
easier to understand?

-- pete; life is like a box of ammo