1 Topic by TCmullet (edited by TCmullet 10-03-2015 01:14:50)

  • Thanks: 6

Topic: "Local shift" not being handled in InterFrame

Would you please look at these? I've created and uploaded 2 short AVIs encoded losslessly with the x264vfw codec. Though short, they're still too big to be attachments, so they are on my own server.

http://www.tomsgoodfiles.com/Test-ba...-q0.504p30.avi
http://www.tomsgoodfiles.com/Test-ba...-q0.504p60.avi


The foreground has two talking heads; ignore them as it's the action behind them that is of interest. (This is a good clip to study this problem.)

The first clip (p30) was input to InterFrame, and yes GPU was true.

In the 2nd one (60fps output from InterFrame), please observe the "double" ball near the middle in frame 45.

OR if you'd rather simply see images, here are the 2 frames surrounding the generated frame:
http://www.tomsgoodfiles.com/p30-frame24.bmp
http://www.tomsgoodfiles.com/p30-frame25.bmp
http://www.tomsgoodfiles.com/p60-frame4 … rated).bmp
(also on my server as the .bmp files are each too big for the forum--I did not convert to jpg as I figured you need "real" content)

OR as PNG files:
http://www.tomsgoodfiles.com/p30-frame24.png
http://www.tomsgoodfiles.com/p30-frame25.png
http://www.tomsgoodfiles.com/p60-frame4 … rated).png
(Even as maximally compressed .png they are too big to attach.)

Why am I not able to generate a frame that positions the ball at the spot between those two balls (ONE ball which has made a "local shift" through space), but instead makes a "double exposure"? Especially in light of this promo graphic:
http://www.svp-team.com/wiki/File:Memc.jpg

As to why it's frame 45 and not 49 is unimportant at this point.  (That may have something to do with the x264 codec.)  As it is so ubiquitous (at least for me), this moving ball problem has been one of the biggest problems for me since I started using InterFrame.  (Not that I'll stop using it if we can't solve it.)

And here's my script:

SetMemoryMax(512)
SetMTMode(3,4)
Avisource("Test-ball-motion.x264v-q0.504p30.avi")
ConvertToYV12()
SetMTMode(2)
InterFrame(Cores=4,Tuning="Film",GPU=true)
#SR(1280,720,4)

2 Reply by Nintendo Maniac 64 (edited by Nintendo Maniac 64 10-03-2015 00:58:20)

Re: "Local shift" not being handled in InterFrame

Please use PNG rather than BMP since it gives identical lossless quality with a smaller filesize (sometimes much smaller).

3 Reply by TCmullet (edited by TCmullet 10-03-2015 01:16:08)

  • Thanks: 6

Re: "Local shift" not being handled in InterFrame

Nintendo Maniac 64 wrote:

Please use PNG rather than BMP since it gives identical lossless quality with a smaller filesize (sometimes much smaller).

Thank you.  You have just pushed my knowledge of PNG into the 21st century!  I knew they were there, but never bothered much with them.  My graphic program DOES allow saving to PNG.  When I picked 0=no compression, the file was BIGGER.  Then on Wikipedia I learn that all PNG files are lossless!  So I will go with "9" (compression level "best").

Edit:  They were much smaller, but still too big to attach.  So I've added 3 more links to my initial post.

Re: "Local shift" not being handled in InterFrame

TCmullet wrote:

Edit:  They were much smaller, but still too big to attach.  So I've added 3 more links to my initial post.

Most of the time people just use external image hosting sites like Imgur or Minus (I prefer the latter since the former sometimes has a tendency to re-encode PNGs above 1MB into JPEGs)

Also there's not really a point to having BMP links at all if you have the PNG links...

Re: "Local shift" not being handled in InterFrame

TCmullet

this's a very small ball  big_smile
while "promo graphic" demonstrates a car about 1/4 of a video frame

  • Thanks: 6

Re: "Local shift" not being handled in InterFrame

Chainik wrote:

TCmullet
this's a very small ball  big_smile
while "promo graphic" demonstrates a car about 1/4 of a video frame

True.  But please explain why size has much to do with it.  If *I* can see the ball, why can't software?  Or maybe you all can figure out a way to accommodate it.  Please express all knowledge about this.  I need to come to a point where we solve it or have full mutual knowledge that it is impossible.  (I have lots of video to process, and I'd hate to spend weeks or months doing it all, then have to come back and do it all again, simple due to not having known of this or that tweak that might have fixed it from the start.)

  • Thanks: 37

Re: "Local shift" not being handled in InterFrame

TCmullet wrote:

But please explain why size has much to do with it.  If *I* can see the ball, why can't software?

Because it deemed as noise because of its small size?

Not really sure how the code interprets motion of small object.
I guess it's down to motion vector grid? Smaller the grid is more accurate?

Re: "Local shift" not being handled in InterFrame

TCmullet

I'm afraid I just don't have enough words to explain.
Any explanation here needs at least a whiteboard to draw on, unless you'll natively speak Russian  big_smile
In fact I can't tell I fully understand how it really works...

You can start from there wink

9 Reply by TCmullet (edited by TCmullet 01-05-2015 22:04:35)

  • Thanks: 6

Re: "Local shift" not being handled in InterFrame

Back on Mar. 9th on SubJunk's Doom9 thread
http://forum.doom9.org/showthread.php?t … mp;page=41
(in which I was advised to move the discussion over to THIS forum), raffriff42 made this post:

The ball is probably moving too fast for the given search radius. It's also quite small and moving behind foreground objects. A very difficult problem.
Quote:
http://www.svp-team.com/wiki/SVP:Profile#Search_radius
Limits the maximum length of motion vectors. Large radius is not always better than small, because the found "far" motion vector may be incorrect, resulting in more artifacts.

I visited that link.  Can someone please point me to how I go about setting (experimenting) with the several possible settings for "search radius"?  I see no reference to "radius" in the code for InterFrame.  I really want to go forward on this.  Not a lengthy whiteboard discussion in Russian, but rather empirical experimentation that I can see the results of and set what I feel would be the best parameter for me.  What would I do to change the value of "search radius"?

(And it would also be nice if we could do this in the context of GameDrop4 as well.)