Using x264 Motion Vector Calculation to Degrain

[CarlEdman]

I currently use the avisynth MDegrain3 filter on all my sources and am very pleased with the results. The downside is that this filter (and its preparatory stages) are extremely CPU demanding. As a practical matter, MDegrain3 seems to take about as much CPU time as x264 at --veryslow --crf 18.

So what I was wondering is if there isn't a huge duplication of expensive effort going on. Does x264 not already have to calculate very accurate and detailed motion vectors, which I believe is the expensive part of MDegrain3? By doing this expensive task twice, once in avisynth and once in x264, encode speed is effectively halved.

How hard would it be for x264 to add an option to do the degraining with its own motion vectors and drop MDegrain3? Given the complexity of x264 and the skill of its main coder(s), I am sure it is not a trivial task, but a 100% speedup on encode would seem to make it worthwhile.

Is that something which is under consideration? Or would it just be too hard/non-standard-compliant (even if only available as an option)?

[gyth]

If MDegrain has any effect then the motion vectors should be recalculated.
x264 isn't interested in actual motion, just which parts of previous frames look alike to aid compression.

[akupenguin]

Not under consideration. And you would be sacrificing some quality of the degraining: motion estimation for video compression is not exactly the same task as motion estimation for video filtering.

[CarlEdman]

@akupgenuin: Too bad--I still think it might be worthwhile, but the developers know best of course.

@gyth: Yes, but "determining which parts of a frame look like which other parts of another frame" is what motion vectors are used for and is all that is needed for degraining. So the tasks are basically the same, or at least very similar.

[Dark Shikari]

@gyth: Yes, but "determining which parts of a frame look like which other parts of another frame" is what motion vectors are used for and is all that is needed for degraining.No, that's not entirely what motion vectors are used for. Motion vectors are used to minimize bit cost, which is a combination of residual and motion vector delta size.

[benwaggoner]

I could imagine a coarse initial motion search could be shared by later degraining and compression refinements, but it doesn't seem that likely to be helpful.

A bigger problem here might be that most degraining filters aren't nearly as well optimized as x264. And degraining well is pretty darn hard, and doesn't get simpler as the compression goes on by getting to reference compressed reference frames which already have reduced detail. Degraining is sort of a worst case of doing lossless I-frames AND high-precision motion searching (albeit with a small search radius).

[D3C0D3R]

Heh. Just leave this here.
http://doom10.org/index.php?topic=340.msg2462

After years its clearer for me why things happen this way.
x264 & MVTools search tries minimizes different metrics.
Yes. They using same alhorithms. But they find slightly divers.
AFAIK H264 store delta of computed mv and mean of neighbor vectors. So it preferable for size to choose unidirectional same-scale vectors.
(keeping in mind fact that mvs can occupy a considerable piece of encoded file)

Yes. x264 could store some intermediate calculations, but this choise rough and suboptimal in terms of filtering.
And will not save tons search time for MVTools.
Sitting on two chairs is off course possible, but not bring the expected gain.

Edit: For example:
We find great mv. Almost no residual. But in some cases cost (in bits) to store this vector so high that exceeds some anothers vector cost + its residual expenses.
As I understand @Dark post and RDO.