Cool, I didn't know how flexible you can process with MVTools. It sounds great
for recreating motion vectors. Then, there are solutions that have some kind of
optimality (like
[https://people.csail.mit.edu/celiu/OpticalFlow/)](https://people.csail.mit.edu/celiu/OpticalFlow/\)).
I might
It might be easier to use Avisynth or Vapoursynth with MVTools directly:
* [MVTools from Avisynth wiki](http://avisynth.nl/index.php/MVTools)
* [MVTools technical page](http://avisynth.nl/index.php/MVTools)
Example to blur blocky area with occlusion mask
Hi mratsim, The libraries provide good medium level access. AFAIK they don't
expose motion vectors though. So I'd either extend and depend them or go bare
metal. I opted for the second choice (to also learn nim) and replicate this as
a starter:
What will you use it for?
If it's to manipulate video data, preprocess, trim, filter it (convolution,
denoising, etc), it might be much easier to use
[ffms2](https://github.com/FFMS/ffms2)
Or maybe provides bindings to Avisynth (Windows-only) or
It's perfectly fine to collate all definitions into a single type block. I
already handle includes programmatically. What would be an idiomatic way to
post-process .nim files? My naive approach would be to parse the AST, reorder
it and dump it. However, I'm not sure if nim parses a file that's
Yes, the reordering can be much manual work.
For the gintro module, I do it automatically now, but it takes a few minutes to
finish -- and it is based on gobject-introspection.
The ugly way is to put all types into a single type section at the front of the
module. Many modules from early days
One use case of us requires interfacing ffmpeg. I used cpp to circumvent many
of the c2nim limitations (e.g. macros within structs). However, I don't come to
grips with type definitions that aren't declared top to bottom.
Specifically, I had to reorder many types in the avformat.nim file.
*
