View Full Version : InterFrame 2.8.2 - Framedoubling/60FPS/HFR conversion script
Pages :
1
2
3
4
5
6
7
[
8]
9
10
11
12
13
14
15
16
17
18
19
20
chainik_svp
27th March 2012, 15:34
Looks like SubJunk is responsible for all SVP here. That's not right ;)
Just finished more complete description (http://www.svp-team.com/wiki/Plugins:_SVPflow) for libs.
Yeah I know my English is awful but I do the best I can :devil:
May be it'll better to start a separate thread for svp libs?
to make SVP take what frame rate I give it as golden
SubJunk uses a "special build" with additional option for defining absolute target frame rate ;)
kolak
27th March 2012, 17:44
Looks like SubJunk is responsible for all SVP here. That's not right ;)
Just finished more complete description (http://www.svp-team.com/wiki/Plugins:_SVPflow) for libs.
Yeah I know my English is awful but I do the best I can :devil:
May be it'll better to start a separate thread for svp libs?
SubJunk uses a "special build" with additional option for defining absolute target frame rate ;)
Very useful!
:thanks:
mark0077
27th March 2012, 18:38
Thanks Chainik, got it working with those special dlls :)
Bernardd
27th March 2012, 20:35
Thanks Chainik and SubJunk for the special svpflow2.dll. In restoring old 8mm or Super 8, we need to be able to fix the frame rate.
SVSmoothFPS is more smart and flexible than MFlowFPS.
Thank you.
Bernard
kolak
27th March 2012, 20:53
Can I repeate question now:
How can I reduce mask/blur effect- bit to much form my taste- creates visible smearing. I tried changing cover and mask, but don't see any effect.
Algo=13 produces best results for me, but still has this halo effect- bit to much blurring around edges.
SubJunk
27th March 2012, 21:22
Yeah I know my English is awful but I do the best I can :devil:Your English is great!
May be it'll better to start a separate thread for svp libs?That could be less confusing
How can I reduce mask/blur effect- bit to much form my taste- creates visible smearing. I tried changing cover and mask, but don't see any effect.If you use Tuning="Smooth", OverrideArea="0" it should be disabled. Algo=13 itself causes a lot of blurring/doubling so for a more crisp image algo=23 is needed (which is what smooth tuning uses)
kolak
27th March 2012, 21:30
If you use Tuning="Smooth", OverrideArea="0" it should be disabled. Algo=13 itself causes a lot of blurring/doubling so for a more crisp image algo=23 is needed (which is what smooth tuning uses)
I'm not after that sharp image- just don't want that much blurriness around ages. It's mainly on the fast motion, where any moving abject has this blurred mask around it- in some cases it's does not look good. I would rather prefer to have "broken" image than blurred one, because in motion this is less visible. I will try your suggestion- thanks. It's also related to block size- in some cases increasing block size helps, but than other parts are not as good as with smaller blocks :) Maybe it needs some sort of adaptive block size :)
Overall all this is great script and results are very good and I hope will be even better, as this is still work in progress :)
SubJunk
30th March 2012, 05:43
InterFrame 2.0b2 is released :)
kolak
30th March 2012, 10:50
Thanks- looks like it's faster :)
Anyone else having a problem with piping a script with GPU=true to an encoder?
In essence, a script using InterFrame2 with GPU=true works fine with:
x264.exe script.avs --output out.264
but throws an error (x264 [error]: could not open input file `-') with:
avs2pipe.exe video script.avs | x264.exe --demuxer y4m - --output out.264
With GPU=false, all works as expected. The problem is not related to x264. I get the same error piping a script to other encoders.
P.S. I am using single threaded Avisynth.
kolak
4th April 2012, 17:59
Interframe 2, with GPU=true and algo=21 I have artefacts on the left and right edge of the footage. It looks like some grey mask.
This is just on some scenes, others are fine.
aegisofrime
4th April 2012, 18:00
For some reason, even with the latest version, GPU=false doesn't work very well. My frame counter just stops moving, indicating that processing has stopped.
Also, I just upgraded from a GTX 460 to a Radeon 7850 and it seems slower now. Now SVP perform better on nvidia hardware? Thanks.
chainik_svp
4th April 2012, 21:13
I just upgraded from a GTX 460 to a Radeon 7850 and it seems slower now.
What's the absolute FPS value? To see some difference between 450 and 460 it should be far more than 120 fps, and 7850 is definitely faster. Please post your results with 7850 to SVPmark database, it'll be interesting. It can be anything, for example 69xx cards just hung the whole system with OpenCL+D3D until 11.6 or 11.7 (?) drivers.
But it's obviously an offtopic in Interframe thread :)
with GPU=true and algo=21 I have artefacts on the left and right edge of the footage. It looks like some grey mask.
What if crop the source by several pixels on all sides? But anyway it's some kind of a bug, I think I know what're you talking about.
kolak
4th April 2012, 21:32
Can try cropping (it's 1920x1080 source with clean/normal edges)- it only happens with GPU=true. CPU mode does not have such a problem. I can try other algos, but I think it's only problem with algo=21 (it's definitely not happening with algo=13).
For my source (very fast motion) algo=21 with lambda=20 and plevel=1 produces well balanced output- clean edges with not much halos.
plevel<1 seams to affect motion a lot- not smooth output.
SubJunk
4th April 2012, 21:49
Interframe 2, with GPU=true and algo=21 I have artefacts on the left and right edge of the footage. It looks like some grey mask.
This is just on some scenes, others are fine.I think I noticed the same thing on one video last night too
chainik_svp
4th April 2012, 21:50
Please post a screenshot with these arts. But two adjacent source frames will be much helpful ;)
kolak
4th April 2012, 22:12
Simulated look:
http://i40.tinypic.com/2814kqr.jpg
I don't have this source on my laptop, but it looks like this.
Both sides will have this sort of grey mask- it will change size, shape a bit over many frames, but always look like this example. It will be few pixels deep and bit more grey than the one on the picture. I can post exact frame tomorrow.
SubJunk
4th April 2012, 22:46
Ah yeah that's different from what I meant. It looks like your source might have a light left border. Will wait to see it
kolak
4th April 2012, 23:00
I will post tomorrow grabs from this problematic source.
aegisofrime
5th April 2012, 05:57
What's the absolute FPS value? To see some difference between 450 and 460 it should be far more than 120 fps, and 7850 is definitely faster. Please post your results with 7850 to SVPmark database, it'll be interesting. It can be anything, for example 69xx cards just hung the whole system with OpenCL+D3D until 11.6 or 11.7 (?) drivers.
But it's obviously an offtopic in Interframe thread :)
Apologies, I actually meant to say Interframe but I wrote SVP since I figured that it is what is responsible for making use of the GPU in Interframe.
On my GTX 460, I used to be able to process 2 720p videos concurrently at around 12fps each. On my current Radeon 7850, I get around 6.8fps. Imagine my disappointment since I bought this Radeon 7850 partly because I thought it will enable Interframe to run faster, and cut down on my electricity costs at the same time.
However I know from my experience with Bitcoin mining that OpenCL code can perform differently on different GPUs, even if one GPU is faster than the other on paper.
Anyway, here's the scores from SVPMark:
Test summary
-----------------------
Date: 2012-04-05T12:54:31
CPU: Intel Core i7-2600K @3392 MHz [8 threads]
GPU: AMD/ATI Radeon HD 7800 [ver.1.4.1703]
Mode: FHD + GPU [17 threads]
Comment: 3.6
Overall scores
-----------------------
Synthetic CPU: MC2030
Synthetic GPU: MG3530
Real-life: FG2743
Details: synthetic
-----------------------
CPU: compose (single-threaded): 553
CPU: compose (multi-threaded): 2391
CPU: search (single-threaded): 415
CPU: search (multi-threaded): 1765
GPU: system -> GPU transfer: 555
GPU: GPU -> system transfer: 1310
GPU: calculations: 1636
GPU: total score: 4772
Details: real-life /FHD
-----------------------
decode video: 16.14x (387.4 fps)
48 fps - vectors search: 1.31x (62.7 fps)
60 fps - frame composition: 3.54x (212.2 fps)
48 fps - [SVP] fastest: 6.30x (302.5 fps)
48 fps - [SVP] simple 1: 4.53x (217.3 fps)
60 fps - [SVP] good: 2.34x (140.2 fps)
60 fps - [SVP] high: 1.83x (109.9 fps)
60 fps - [SVP] highest: 0.83x (50.0 fps)
72 fps - [SVP] simple 2: 4.20x (302.1 fps)
Edit: I took a look at your SVPMark database and you guys don't have any Radeon 7800 series cards in there. Guess I'm the first one :D
chainik_svp
5th April 2012, 09:51
here's the scores from SVPMark
GPU scores are too low, at least "system -> GPU transfer" value, may be it's a drivers bug.
Guess I'm the first one
I can't add your results to DB by hands ;)
kolak
5th April 2012, 09:58
Ah yeah that's different from what I meant. It looks like your source might have a light left border. Will wait to see it
Here it's:
http://i39.tinypic.com/15hilq9.jpg
Source has some thin grayish border (and I said it has clean edges-ups), so I assume this causes the problem.
aegisofrime
5th April 2012, 10:39
GPU scores are too low, at least "system -> GPU transfer" value, may be it's a drivers bug.
I can't add your results to DB by hands ;)
Indeed I noticed that too.
I registered an account with SVP just now but SVPMark returned authentication wrong. It returns correct now, and I will upload scores once my current encoding job is finished. :D
chainik_svp
5th April 2012, 10:47
Source has some thin grayish border (and I said it has clean edges-ups), so I assume this causes the problem.
Yep ;) Avatar remux also have 2px black borders for some reason :confused:
And I don't know what I could do with it if I've got real motion vector points outside the frame.
kolak
5th April 2012, 11:08
Why is it fine with algo=13 (and in CPU only mode)?
chainik_svp
5th April 2012, 11:27
In CPU mode vectors're brutally clipped at the blocks level.
I think algo=11 should give the same artifact, algo=13 could "mask" it with median function (but I need to check).
kolak
5th April 2012, 11:41
Yep, algo=11 same problem.
It's actually also on algo=13, but way less visible. I'm was so focus on the main frame that never noticed borders- hehe :)
CruNcher
5th April 2012, 13:34
GPU scores are too low, at least "system -> GPU transfer" value, may be it's a drivers bug.
I can't add your results to DB by hands ;)
I hope it's not the standard low copy back performance that goes on in the next generation as well though @ the time i read AMDs dev forums there where some special parts their about improving memory copy performance PCIE-E transfer speed code wise with their SDK especialy in the Compute section you find people their naging about the copy performance ;).
Huit
6th April 2012, 19:09
When I try to convert 1920x1080, 23.976fps footage I get an error from MS Visual C++ runtime Library:
Runtime Error!
Program C:\Program Files (x86)\MeGUI\tools\x264\avs4x264mod.exe
1280x720, 30fps works just fine.
Any ideas?
chainik_svp
6th April 2012, 22:05
Huit
1. Patch .exe with that tool (http://www.ntcore.com/4gb_patch.php), AND/OR
2.1. Lower value in SetMemoryMax() call, OR
2.2. Use modified Avisynth 2.5.8 build from SVP
I hope it's not the standard low copy back performance
It doesn't matter cause I'm not writing GPU benchmark ;)
On my GTX 460, I used to be able to process 2 720p videos concurrently at around 12fps each. On my current Radeon 7850, I get around 6.8fps.
I'm sure the problem is in something else. Two 720p is like one 1080p and even with the highest possible rendering settings any video card >=5770 can render >100 FHD frames per second.
Huit
6th April 2012, 23:11
Huit
1. Patch .exe with that tool (http://www.ntcore.com/4gb_patch.php), AND/OR
That did the trick.
Thank you very much! :) :) :)
aegisofrime
7th April 2012, 03:14
Huit
I'm sure the problem is in something else. Two 720p is like one 1080p and even with the highest possible rendering settings any video card >=5770 can render >100 FHD frames per second.
I have to apologize for being unclear again. :scared: What I described was Interframe in combination with QTGMC(Preset="slow",InputType=1) and encoding with x264 preset slower. So it's pretty heavy stuff there. It's not just Interframe or SVP by itself.
That said, do you think the low system to GPU transfers could be fixed on your end, like what Cruncher said? Or do I have to wait for AMD to release new drivers?
Thanks for your work as always!
mark0077
7th April 2012, 17:42
Hi all, what number of Cores are you setting Interframe to use?
I'm able to use max settings in Interframe 2.0 b2 (Medium profile) even with 1080p content, except I need to make one change. I need to reduce overlap from 2 to 0 to make 1080p not drop any frames. That seems to have a huge impact on performance for me.
I'm using Cores=15 on my Core i7 920 using gpu=true (GTX 295)
I notice however cpu usage is still only around 40% and many of the "cores/threads" don't seem to be getting used at all according to Windows Task Manager. Thats using overlap=2. With overlap=0 I get about 26% usage. I don't know if this 40% usage yet many frame drops when using overlap=2, is an indication that I could possible get a little more out of my machine or not in terms of settings, thats why I ask what settings you guys are using?
chainik_svp
7th April 2012, 21:50
aegisofrime
I can explain ;)
Let's say you've got 10 fps at output with 1080p (or 2x720p) source which means each output frame is processed in about 100 ms. I know from your SVPmark results that your system / video card can render >=212 frame per second. OK, 200, and each frame is rendered in 1000/200 = 5 ms. So, all your outer scripts make their work in 100-5=95 ms, and GPU renders a frame in 5 ms.
What if you change your new 7850 to something 5 (five) times slower? Rendering time will be 5*5=25 ms, total processing time = 95+25 = 120 ms, in other words - 8.3 fps.
Conclusion: using 5 times slower video card you'll get just 20% overall performance drop.
Of cause I assume that SVP libs are the only components in processing chain that uses GPU in any way.
mark0077
In SVP we're using 1.9*<num_of_HW_threads> in GPU mode and 1+<num_of_HW_threads> in CPU mode for maximum CPU usage. But:
- 23th shader seems to require more threads and
- it may not be enough with default Avisynth threads scheduler.
But if you're talking about real time playback it's a different story. Frame drops usually caused by splitter / decoder / renderer combination and not by CPU load.
mark0077
8th April 2012, 20:38
Hi chainik. What do you recommend I use for threads with shader 23 on core i7 920 + gpu
With overlap=0 I get 0 frame drops and with overlap=2 I get lots of drops although CPU and gpu usage is quite low. I'm not sure what's limiting the performance. Perhaps as you say it's 15 threads not being enough to get the most out of my setup?
chainik_svp
8th April 2012, 21:34
mark0077
That (http://www.svp-team.com/forum/profile.php?id=1337) is you, right? So why asking here where any "frame drops" is off-topic cause Interframe is an encoding script?
mark0077
9th April 2012, 00:13
Because choosing settings that makes the most of ones machines resources is one of the most important topics of this thread ;)
SubJunk
11th April 2012, 00:52
2.0b3 is released :)
Bernardd
11th April 2012, 13:39
Hi SubJunk,
Thank you for this new release with return some strings to int values. But i have one problem, OverrideArea changes are skipped.
Bernard
SubJunk
11th April 2012, 22:06
Hi Bernardd, you're right, thanks for reporting it. It will be fixed in the next release :)
SubJunk
12th April 2012, 07:16
2.0b4 is released :)
aegisofrime
15th April 2012, 07:32
Subjunk, have you encountered any problems with the speed of processing dropping to zero after the first few frames with GPU=false?
SubJunk
15th April 2012, 09:10
Not recently, but a few months ago I had that problem when using intensive scripts (like QTGMC) and I just had to adjust the SetMemoryMax and SetMTMode values to fix the stability.
aegisofrime
15th April 2012, 09:47
Version 2.0 was frustrating stability wise, but then I found out that removing SoraThread helps. 30% of my current processing job done so far, hopefully it will finish without a hitch.
SubJunk
17th April 2012, 05:27
Version 2.0 RC1 is released, which improves stability
aegisofrime
17th April 2012, 05:59
Thanks for 2.0RC1 SubJunk. It does seem more stable! Pity that I'm better off using my CPU rather than my GPU; It's actually slower than the CPU! I feel like I have gone backwards "upgrading" from a GTX 460 to a Radeon 7850. Never touching AMD again.
SubJunk
17th April 2012, 10:24
Bad luck on the GPU! I wonder if chainik_svp can shed some light on why that would be the case?
chainik_svp
17th April 2012, 11:01
I've already said (http://forum.doom9.org/showthread.php?p=1568951#post1568951) that I doubt about this's a 7850 issue.
Anyway don't be so upset, some said that GTX 680 isn't working at all with current drivers :D
aegisofrime
18th April 2012, 07:04
I've already said (http://forum.doom9.org/showthread.php?p=1568951#post1568951) that I doubt about this's a 7850 issue.
Anyway don't be so upset, some said that GTX 680 isn't working at all with current drivers :D
I understand your point. Is it possible that the slow GPU->System transfer speed is the main culprit? The GPU may be able to process the frames fast, but information is going back to the CPU too slowly. Ultimately, my processing chain is encoded by x264. Perhaps x264 is wasting time waiting for these frames from the GPU?
chainik_svp
18th April 2012, 09:51
The GPU may be able to process the frames fast, but information is going back to the CPU too slowly.
It's "slow" for 300 FHD frames per second but not for 10.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.