This is a small explanation of the statistics tables generated by encodedv:

CYCLE are the cycles in the quantization loop until a matching QNO is found 
      (affects speed)

RUNS/CYCLE (for 3-pass VLC) : Tries to skip quantisation steps if it is 
      clear that a _lot_ more bits are needed. Makes things faster but 
      maybe quality drops a little bit. Smaller values mean better quality and
      larger values mean that you gained some speed.

QNO   is the quantization number. Larger values mean lesser quantization
      (15=no quantization at all!) and better quality. You will notice, that
      there are gaps between the values in the statistics. (Especially if 
      you choose "--vlc-passes=3", where qnos are most likely 15 or 8.)
      This is normal behaviour since depending on the quantization CLASS
      some QNOs don't gain you anything and are therefore skipped. There are
      even codes, that _never_ gain you anything regardless of the chosen
      classes.

CLASS is the quantization class. (Greater values mean higher quantization.) 
      This is used to quantizise larger AC coefficients more than smaller ones.
      For now, we use the following table 

               max AC-value
               0 - 11  |  12 - 23  |  24 - 35  | >35
               -----------------------------------------
             Y   0     |     1     |     2     |   3
            CR   1     |     2     |     3     |   3
            CB   2     |     3     |     3     |   3

      from the IEC documentation (which is only given for reference.)
      If you want to improve this, keep the following in mind:
      * These classes are chosen with the vlc code lengths in mind. 
        There is one code length for codes between 0..11, for 12..23 etc.
      * You _have_ to use class 3 for AC coeffs. larger than 255, since they
        can't get encoded otherwise.
      * It is sensible to quantizise CR and CB values more than Y values.
        (a) they don't matter that much and b) their bit budget is therefore
        smaller!)
      * Larger classes give you finer control over the QNO.
      * Smaller classes don't have necessarily better quality since you may
        be encoding quantization noise. That's from the IEC document. I don't
        know, why they consider picture details with extremely small
        coefficients as noise, but I agree that large coefficients don't 
        really need all the lower bits.
VLC OVERF is the number of vlc_encoder overflows you encountered. That means
      that some AC coefficients simply aren't encoded!
      At best it means your picture is somewhat blurred and at worst it has 
      a very psychedelic touch...
      This should only happen in two cases
      a) if you use "--vlc-passes==1,2" and QNO 0
      b) static_qno since the simple heuristic used can fail easily

DCT MODE is the DCT mode chosen. DCT248 is used for fast moving sequences, 
      where the two fields encoded differ a lot. DCT88 has generally better
      quality. The decision is based on the accumulated differences between 
      the two fields that are larger than a hard coded threshold divided
      by the same difference in x direction. This makes sure that spotlights
      are encoded with DCT 88 and not with DCT 248.
      Something like (sum_i abs(field1[i] - field2[i])) / 
	              sum_i abs(block[i+1] - block[i])) > dct_248_limit
TODO:
     - finally go to the library and get the header block specifications ;-)
     - think of a better way to implement static_qno for 1,3 vlc passes
     - do correct synchronisation between audio and video (synchronise
       against system clock since we can't be sure, that the soundcard
       clock is 100% accurate)
     - skip frames correctly
     - find a way to detect NTSC / PAL for video or finally add a 
       force-video-format option.