[XviD-devel] vfw 2pass stats

[Dirk Knop]

Edouard Gomez wrote:

>Dirk Knop (dknop@gwdg.de) wrote:
>  
>
>>So to join the proposals made, the stats file could look like this:
>>
>>Frame No. | total bytes | texture bytes (or bits) | Frame Type | Frame 
>>Quant [|kblk|mblk|ublk (imho not necessary)]
>>000001 | 1024 |  1024 | I | 2 | [680|0|0]
>>000002 | 96 | 0 | P | 2 | [0|0|680]
>>    
>>
>
>1 -  forget about the |  symbols, it's better to  use single separator
>char (ie space 0x20 in our case).
>

I just added them for "better readability" in the example, of course the 
file itself should be "space delimited" or with ";" (so you could import 
it even with your favorite spreadsheet application ;) ) - sorry for not 
making that clear.

>2 -  We must  precise framenumber in  decoding order  framenumber, not
>encoding order else we'll have problems :)
>

As long as we know how the stats file is generated the order of the 
entries doesn't really matter as we know about it ;)
If we write a IPBBPI sequence to the bitstream I think we should write 
that order into the stats-file, too.
For 2nd pass we would scale in that order and deliver the input in it as 
well - it's the core that buffers some frames and should re-order 
appropiate.

>3 - u/k/m  blocks could be useful.  I remember a  paper (which url was
>given  in  this  list)  that  was  talking about  a  good  frame  size
>approximation using  numbers of  zeros written in  bit stream  for dct
>blocks.  u/k/mblocks   can  be  used  to  estimate   number  of  zeros
>written. But  we could try to  implment this paper rc  and then change
>u/b/kblocks to just a "zero bits written in stream for dct"
>
>Did someone  try to  implement this  ? Otherwise i'll  like to  try it
>myself.
>
Well, we have those information for so long but it never got used - if 
there is such a possibility I think it would be nice if we used it 
somehow :) I'm looking forward to your implementation!

>4 -  Concerning I/P/B decision,  2pass should have total  control over
>encoder,  else 2pass  algorithms will  just be  fooled by  the encoder
>behaviour.
>  
>
More than agreed here again :)

Thanks for the reply,

regards,
Dirk