Near Future improvements

0.  Replace current variance based motion estimation mode selection
	with DCT based selection.  
	Next Step: split predictors from Picture state and build a
	new QuantiseAndPutEncoding that predict's and transforms and
	quantisatises forall the motion estimates and selects the one that
	worked best for encoding.

	Alternatively: select using the base quantisation and use the old
	encoder...

1.  Add DCT quantisation reduction for macro blocks whose original image
	(INTRA) data is low-variance... this should help misty scenes

2.	Split into front-end and library (for gstreamer etc) 
	This will require removal of lots of nasty global scratch variables

4.	Seperate the transformation phase (ME, pred, DCT) from the bit allocation
	and coding phases. 
	This will provide the basis for two-pass encoding and pipelined encoding.

5.	Replace the current frame-based parallelism with striping in the 
	ME/pred/DCT routine.

6.	The rate control code is now a mess of int64_t , double and int. Needs
	tidying... 

Minor Tidying

2.	The order of return from block_dist1_MMXE is silly.  Why not
	retune in the order it is held and adjust find_best_one_pel_MMXE to
	suit.  

3.	For Motion estimation in -I 1 we really need both field *and* frame
	sub-sampled images for motion estimation to be optimal.


5.	The code for scene-change gop sizing and ending sequences can in
	some circumstances mess up as the sizing takes no account of
	the fact the when a sequence split occurs the I-frame tempref is
	0 not M-1.


Sometime....



1.  	Bring field sequence MC/prediction to same level as progressive	
	sequence.

	
2.	Improve locality of reference by motion-estimating entire 4x4, 2x2, 1x1
phases in a single pass rather doing each for each Macroblock.

3.  Check out using dist2 for initial MC calculations as well as final
	selection?

4.  Decouple motion estimation and encoding passes to allow backup-and-retry
	and two-pass encoding.

5.	Add low-passing for high-activity regions when a specified quantisation
	level is exceeded (or block boundary edge energy exceeds some threshold?).

6.	Sort out that wretched vbv verification code.

	The mblockq_ sub-routines intended specification should be documented...

7.	Code Hygiene...
	Is all theblock_count dependant code is o.k. for YUV422 and YUV444?



