Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
|
|
Thread Tools | Search this Thread | Display Modes |
11th November 2005, 07:12 | #41 | Link | |
Registered User
Join Date: Nov 2004
Location: Spain
Posts: 408
|
Hi all,
From Fizick's previous post: Quote:
|
|
11th November 2005, 09:53 | #42 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
The reason for the 10 frames was for buffering purposes. I wanted to avoid recomputations at all cost, and I didn't trust avisynth's cache at that time.
The frames are kept interpolated because, since I made the interpolation during the analysis, I can reuse it during the processing. Finally the compensation occurs in the analysis because it's there that it is the most efficient from a cpu cache point of view. Just after the ME, the block that will be used as compensation is in the cache. No need to recompute it, you just have to fetch it.
__________________
|
11th November 2005, 12:15 | #43 | Link |
Clouded
Join Date: Jul 2003
Location: Cambridge, UK
Posts: 1,148
|
Manao,
I thought about this one. How about: -- analyse giving only motion vectors -- compensate using motion vectors -- joint analyse/compensate function for efficiency... outputs compensated picture only It doesn't involve significant code duplication (even with multiple compensation methods), because we have templates available.
__________________
a.k.a. Clouded. Come and help by making sure your favourite AVISynth filters and scripts are listed. |
11th November 2005, 12:22 | #44 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
But compensation is computed only if downstream filters use it. And processing filters might need as well the MVs ( and they don't cost a lot to be written anyway ).
At the moment, downstream filters say what are their need : * compensation Y, U, V * block variance * block average luma * reference block average luma And the analysis filter computes the values needed by all the downstream filters that'll use its output. That way, values get computed only once, and where they are the most effective : in the analysis part, when everything is already in the cpu cache.
__________________
|
11th November 2005, 12:27 | #45 | Link |
Clouded
Join Date: Jul 2003
Location: Cambridge, UK
Posts: 1,148
|
Ah -- clever! I didn't realise the output was adaptive in that way. How do the downstream filters communicate with the analyse filter?
__________________
a.k.a. Clouded. Come and help by making sure your favourite AVISynth filters and scripts are listed. |
11th November 2005, 12:40 | #46 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
There's an object linked to the analysis filter that is written in the videoinfo.nchannels. It allows to send the analysis filter some information.
Ugly, hackish, yet, since I'm using a RGB colorspace to write mv / picture data, I figured that overriding the number of audio channels was no big deal.
__________________
|
11th November 2005, 16:28 | #47 | Link |
AviSynth plugger
Join Date: Nov 2003
Location: Russia
Posts: 2,183
|
Manao, mg262,
In my opinion, you (we) must create some common (general) format of vector clip for MVTool.dll and Motion.dll. (some version specific parameters may be too, of course). It will be useful some SuperAnalyze in MVTolls and SmartCompensate in Motion and vice versa! So we will must not duplicate every compensation-interpolation routine. That is why I ask for simplification of vector clip format in MVtools. |
11th November 2005, 19:30 | #48 | Link |
Clouded
Join Date: Jul 2003
Location: Cambridge, UK
Posts: 1,148
|
It seems easiest to write two conversion functions. I would not want to lose the flexibility to change format, and I imagine Manao would not want to lose efficiency. The current Motion format is certainly going to change (hence having both MotionVector and CompressedMotionVector in the code I sent you, so the change can be applied transparently). But it is temporarily as follows:
Motion vectors are stored in the luma of a YV12 VideoFrame, width equal to the original frame, 1/8 the height (rounded up to be even). Each 8x8 block has a 8 byte motion vector, x and y as 16:16 fixed point integers. I tested 4 byte motion vectors (2x 14:2), but the speed up due to cache effects was slightly smaller than the slowdown due to unpacking. I may use this anyway to save memory. I will certainly switch away from YV12, probably to Y8.
__________________
a.k.a. Clouded. Come and help by making sure your favourite AVISynth filters and scripts are listed. |
12th November 2005, 15:50 | #49 | Link |
AviSynth plugger
Join Date: Nov 2003
Location: Russia
Posts: 2,183
|
mg262,
why you do not want make me happy Please, consider to make new vector format more compatible with basic part of format of MVTools. For example: vector component vx, vy and SAD (as in MVTools). Some standart part of format can be fixed, and more complex and specific parts can placed to some reserved placed or behind them. In future i will prefer create my own plugin, used motion vectors (basic part of them)from both your plugins. New version 0.9.12.1 (Released 12.11.2005) Added experimental MVFlowFps function. Disabled MVInter function. Temporary changed size of internal frames buffer from 10 to 3 for memory usage decreasing. Speed must be tested for complex scripts. |
12th November 2005, 17:03 | #50 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Quick & ugly test, by just replacing MVT-0.9.11 with MVT-0.9.12.1. Script uses analysation of -4 ... +4 frames, and does 2 times compensation (1x preprocessed input, 1x original input). "idx" & Co. are optimized to not do more than what's needed (hopefully).
memory usage: drop by 15 MB (270 MB vs. 285 MB, Vdub as a whole, Windoze task manager) effective speed: drop by ~7% (130 frames/min vs. 140 frames/min in Vdub preview).
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
12th November 2005, 17:47 | #51 | Link |
Clouded
Join Date: Jul 2003
Location: Cambridge, UK
Posts: 1,148
|
Fizick,
There are many reasons; this is the quickest to explain: I need a very compact format (e.g. to allow cacheing of many motion vectors) so I am thinking of four bytes per vector; what you suggest seems like twelve bytes per vector. 3x overhead...
__________________
a.k.a. Clouded. Come and help by making sure your favourite AVISynth filters and scripts are listed. |
12th November 2005, 21:05 | #52 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
We could deinterleave sad from mvs in the MVTools. Furthermore, having a header saying how the content is organized would help. But I don't see the point in caching many motion vectors. That won't speed up a filter as soon as it needs to do some processing.
In the header, we could have the following data : * colorspace * width of the analysed clip * height of the analysed clip * block width * block height * mv precision * direction of the analysis ( forward / backward ) * number of frames between the analysed frame and the reference * payload id * payload size * padding to align to 16 Then we would have the motion vectors ( each coordinate on a 16 bits signed integer ), and the payload ( which could contain all the data needed by MVTools but not by Motion )
__________________
|
12th November 2005, 22:27 | #53 | Link | |
Clouded
Join Date: Jul 2003
Location: Cambridge, UK
Posts: 1,148
|
Quote:
In order to use the motion vectors in MVTools, you need to compute whatever additional information is requested by filters; so you need to run them through a conversion filter to generate this. What is the difficulty with having that filter read motion vectors in the Motion format and write them in the MVTools format?
__________________
a.k.a. Clouded. Come and help by making sure your favourite AVISynth filters and scripts are listed. Last edited by mg262; 12th November 2005 at 22:34. |
|
13th November 2005, 01:52 | #54 | Link |
AviSynth plugger
Join Date: Nov 2003
Location: Russia
Posts: 2,183
|
Didée,
Thanks for test. It was pel=1 or pel=2? mg262, but you do not write any header info. and do not output the SAD. O.K. Forget about it now. May be, when you impement more functions, you will need in more complex format. we will return to this topic. |
13th November 2005, 03:50 | #55 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 5,391
|
Ah, I tend to forget that pel=1 does exist Tests were with pel=2, blksize=16, searchparam=3.
Strangely, decreasing number of compensated frames to -3 ... +3, speed seemed to drop a little more, to about ~90% of MVT 0.9.11 (142 frames/min vs. 160 frames/min). However the script *is* complex, so the exact reasons might be in the darks. But atleast it seems the changes didn't make things faster. *** Another thought: Could sort of mimicking the "inter4v" mode of mpeg-4 codecs make sense? Because, while small blocksizes (8 or even 4) sometimes deal better with moving edges, and mostly better with occlusion areas, the large blocksize 16 seems much more reliable when large, uniform areas are moving. The wish to get the best of them both sometimes is coming up ... Or is this, in some way, already lying inbetween the new parameters you've added to mvanalyze? I'm not fully clear about these, and it's hard to see & understand what's happening _during_ the process of motion search, when you're looking "from outside" and only see the end result.
__________________
- We´re at the beginning of the end of mankind´s childhood - My little flickr gallery. (Yes indeed, I do have hobbies other than digital video!) |
13th November 2005, 19:39 | #56 | Link | |
AviSynth plugger
Join Date: Nov 2003
Location: Russia
Posts: 2,183
|
Quote:
Added experimental precise but slow MVFlowBlur function as scharfis_brain asked. Temporary changed size of internal frames buffer to 5. Parametersof MVFlowBlur are almost as you asked: blur: blur time interval between frames (in percent, default=25.0) prec: blur precision in pixel units. Maximal step between compensated blured pixels. Default =1 (most precise). But it is simple (without occlusion mask yet) and slow. |
|
14th November 2005, 17:38 | #58 | Link |
AviSynth plugger
Join Date: Nov 2003
Location: Russia
Posts: 2,183
|
v0.9.12.3 (Released 14.11.2005)
Fixed bug for croma for width not divisible by 16 in MVMask (introduced in v0.9.11). Some speed optimizing of MVFlowFps. Reset size of internal frames buffer to original value 10. Try various versions. |
14th November 2005, 20:05 | #59 | Link |
Retired AviSynth Dev ;)
Join Date: Nov 2001
Location: Dark Side of the Moon
Posts: 3,480
|
Fizick, your work is such a big improvement over the earlier versions! It's still quite buggy, but it shows so much potential!
Bugs observed in new functions: MvFlowFPS ml = 0 -> division by zero. MvFlowBlur blur > 100 -> occational access violation. The docs are very hard to read. I call out to everyone who understand them, and have the time, to help out in creating good tutorials and docs.
__________________
Regards, sh0dan // VoxPod |
14th November 2005, 20:12 | #60 | Link |
AviSynth plugger
Join Date: Nov 2003
Location: Russia
Posts: 2,183
|
sh0dan,
I will add parameters bound checking. About docs. It is more hard item. Soon I will create Russian doc. May be it will be more readeable (for those who understand Russian) Or you say about Manao's part of doc too? |
Thread Tools | Search this Thread |
Display Modes | |
|
|