Some ideas

[ReferenceDivx]

I've been looking through a lot of the source and have lots of good ideas. I hope to implement them in the near future.

My ideas include:

Adaptive quanitizer matrices that adjust to the individual characteristics of each frame using similar technology to dctune.

An improved luminance masking algorithm that is based on HVS.

Quality options for postprocessing and no postprocessing.

GMC would be a good option in the future(I'll let others think about this)

I want to work on areas that relate to the xvid's quality, and video quality metrics. Other ideas to come.

[MfA]

It is severely doubtfull wether you can get the bits you put into custom matrices back in coding gain IMO ... computational complexity is also an issue.

The rest seems to be planned for and will probably be worked on by the usual suspects, except for pre/post-processing. Especially a shame as far as pre-processing is concerned (since there is postprocessing available in other projects such as ffdshow). If you are going to calculate masking factors it would be very nice if you could use them for spatio-temporal filtering as well, instead of just for the quantization factor (which you wont always be able to adjust, because of the cost in bits to change it). A spatio-temporal filter using information from motion-compensation would be better at removing noise than the present filters such as convolution3d too (although you would probably have to perform motion compensation twice that way, the second time could be hinted though).

[-h]

A spatio-temporal filter using information from motion-compensation would be better at removing noise than the present filters such as convolution3d too (although you would probably have to perform motion compensation twice that way, the second time could be hinted though).

I started adapting XviD's ME towards this end, but it was immensely complex and wouldn't have given great results anyway (ME is geared towards lowest bit cost, not actual motion). Extrapolating motion in the past and future (for multiple references for temporal smoother) was a pain too.

I scrapped that and implemented EPZS with temporal/spatial smoothing in an avisynth filter with a few adjustments. I'm not sure when it'll be finished, as I noticed some improvements and am about halfway through implementing all of EPZS in XviD.

-h

[MfA]

The motion estimate might be more geared to true motion, but it's result would still be an extremely good predictor for the XviD motion search ... ideally it would be done in core at some point in time, and even though the motion searches have slightly different goal surely the two can be factored to share a lot of code?

I had a rather simple filter in mind which just took into account the high frequency content of the DFD to determine the strength of a spatial filter ... but since you are looking into more sophisticated methods have you looked at some of the papers out there on spatio-temporal kalman filtering?

[-h]

There is a heap of duplicate code in my method, but it is more modular and leaves motion_est.c/encoder.c a lot easier on the eyes. If B-frames are used, there will be no speed gain anyway as almost the same number of searches would be performed in the end (P-frames would search B-frames).

Do you mean papers like this (http://citeseer.nj.nec.com/patti98new.html) or this (http://citeseer.nj.nec.com/85526.html)? It's all new to me. Whatever happens to all the code that people write in the course of creating papers like those?

-h

[MfA]

If they cant sell it they store it away until noone understands it well enough to use it anymore, in neither case we get to see it of course, so others can do all the grunt work all over again and repeat the excercise. It's only partly academic research after all, if they dont have corporate sponsorship in the first place they are trying to get it ... and open sourcing everything would make their services less valuable.

At least in this line of research that is a valid excuse, in a lot of other areas it is simple unwillingness on the part of researchers to clean up their code enough to be able to distribute it. Some (http://www-stat.stanford.edu/~donoho/Reports/1995/wavelab.pdf) do see how this runs counter to the whole idea of academic research, and things are slowly changing.

The papers from mr. Tekalp were foremost in my mind when I mentioned it, there is also a book chapter at Inald Lagendijk's homepage (http://www-it.et.tudelft.nl/~inald/) (look for "Video Enhancement and Restoration", look a little further too ... lots of interesting stuff there, there are some papers on motion masking too for example) which provides a nice (if slightly outdated) overview and is a lot more readable than your average research paper.

[ReferenceDivx]

How are matrices being written to the header now in Mod Quant? Are they only being written to the file when the quant method changes from one to another? I'm thinking it would be more efficient to change the custom matrix every IFRAME, unless it could be proved that it would work better for each frame.

Also....

what does the normalize_quantizer_field function do? Does it normalize the quant values so there is less blocking? Ok i think i figured it out.

does it go like this
->->->->->->->->->->->->->->->->->->->->
->->->->->->->->->->->->->->->->->->->->
So does it normalize values that go down then?

Ok thanks.

[Suikun]

The individual quantizer of a block can't change more than +-2 to it's previous block's quantizer, so normalize_quantizer_field restricts them to thses boundries.