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. |
27th August 2015, 14:47 | #1224 | Link | |
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,664
|
Quote:
I also added this issue to GitHub: https://github.com/AviSynth/AviSynthPlus/issues/63 |
|
27th August 2015, 15:45 | #1225 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
Edit: Which nnedi3 are you using? Last edited by Groucho2004; 27th August 2015 at 18:19. |
|
28th August 2015, 04:56 | #1226 | Link | |||
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,664
|
Quote:
AviSynth+ r1576: Quote:
AviSynth 2.6: Quote:
I'm using jpsdr's nnedi3 (SSE4.2). Both AVS/AVS+ are using the the exact same plugins. |
|||
28th August 2015, 05:42 | #1227 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
While it was mentioned in the issue on Github, the drastic difference in memory consumption between r1576 and newer builds of avsplus is because r1576 still uses the old cache system that 2.6 does, just bugfixed and tweaked a bit with the rest of the performance boosts that were already present in 0.1. But the MT branch (which is where *all* post-r1576 builds come from, since there weren't any public builds made available prior to r1689, IIRC) has a redesigned cache system, leading to the much-reduced memory consumption and different thread count numbers. It's a bit of comparing apples to oranges there.
So more correctly, the drop-off in performance after r1765 is a regression that was introduced late in the cycle for the new cache system. I may go in and do some builds so we can try to bisect this, once I have access to my VS2013 build environment again. |
28th August 2015, 06:32 | #1228 | Link |
Pig on the wing
Join Date: Mar 2002
Location: Finland
Posts: 5,718
|
The performance issue aside, is r1825 generally safe to use for MT purposes or are there other issues still lurking?
__________________
And if the band you're in starts playing different tunes I'll see you on the dark side of the Moon... |
28th August 2015, 08:59 | #1229 | Link | |
Registered User
Join Date: Oct 2002
Location: France
Posts: 2,309
|
Quote:
|
|
28th August 2015, 23:47 | #1231 | Link |
Registered User
Join Date: Mar 2012
Location: Texas
Posts: 1,664
|
Can someone please make an AviSynth+ changelog (or list) that contains revision numbers and the corresponding commit hash? Since AviSynth+ uses revision numbers for it's releases is kinda hard to find the corresponding commit unless it's been tagged. I'm not familiar with GitHub so I'm not sure how to accomplish this.
Last edited by Reel.Deel; 29th August 2015 at 01:34. |
29th August 2015, 01:46 | #1232 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
That's actually impossible, because the commit count can change during merges because git slips commits into the history by date (and in fact, this is exactly what happened when the Sphinx docs were merged). This is expected git behavior. The reason some projects don't have this as an issue is because they don't do merges, and apply patchsets through git am.
The revision numbers are more akin to plain commit counts than static revision numbers like in Subversion. In fact, the method by which the number is generated is 'git rev-list --count HEAD'. The better option (although it wouldn't do anything to existing commits), would be to have the abbreviated commit hash visible in the output of Version(). The dumb way of doing it is to simply do 'git rev-list HEAD', and then open it in a spreadsheet so you can look at the row numbers or generate them in a column. But like I said, that only shows which commits were in those positions at the time you perform the operation, not forever. Last edited by qyot27; 29th August 2015 at 01:49. |
29th August 2015, 17:51 | #1234 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Pretty much, yes. Revision numbers are a form of commit counts, even in Subversion. The difference is that where Subversion's are static numbers and thus the revision number is always true for X commit, in normal git usage the number is only representative of the latest commit on the branch you're on (and since the most common usage for the numbers is as a constantly tracking upward number of commits, it works well enough). Like I said, some projects - x264, for instance - don't do merges and force git to keep a strictly linear history, in which case the revision numbers and commit hashes would be static and pretty much just like in Subversion. But those would definitely be the exceptions for projects using git, not the rule.
For AviSynth+, the revision numbers are really just a shorthand, and the only ones that might pack extra meaning are those that are shown in the Version() output for an official point release. That's why 'AviSynth+ r1576' is treated as synonymous with the official release of 'AviSynth+ 0.1'. Otherwise, the numbers are more for seeing how much activity has occurred between builds (or in relation to classic AviSynth; currently, avsplus is about 500 commits ahead or so). Whatever the number happens to be when 0.2 gets tagged and released will have the same popular association to it. |
29th August 2015, 18:40 | #1235 | Link |
German doom9/Gleitz SuMo
Join Date: Oct 2001
Location: Germany, rural Altmark
Posts: 6,753
|
It is certainly similar for x265 which uses Hg (Mercurial), a kind of git variant. There are version "milestones" and additional patch counts. But it seems not to progress as sequentially as expected either; I remember a point when the "stable" branch got merged into the "default" branch and should have raised the count of patches by about half a dozen, I expected, but it increased only by one... So I am not sure if only the patches in the "default" branch count, or if there are "meta patches" which don't increase the number after the version milestone. Only the hash pattern is sufficient as identification.
|
30th August 2015, 21:05 | #1237 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Okay, here's a pack of 4 different snapshots so that we can start narrowing down where in the last 100 commits this regression appeared:
http://www.mediafire.com/download/aj...bisect_test.7z I also included the git hash in the directory names so we know what the exact commits are. |
30th August 2015, 21:26 | #1238 | Link | |
Join Date: Mar 2006
Location: Barcelona
Posts: 5,034
|
Quote:
A script for quickly checking if the dll exhibits the "fps deterioration": Code:
SetMemoryMax(1024) colorbars(width = 640, height = 480, pixel_type = "yv12").killaudio().assumefps(25, 1).trim(0, 49999) AssumeTFF() QTGMC(Preset="Super Fast") Last edited by Groucho2004; 31st August 2015 at 22:01. |
|
31st August 2015, 01:16 | #1239 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Quote:
Code:
c4972da Fix leaking subframes. b361e59 Fix #37 by not using filter instances to get their MT mode. 422aae8 At least avoid leaking the VFBs when plugin or host is leaking. 3cb1122 Report invalid param of SelectEvery to user. |
|
31st August 2015, 03:37 | #1240 | Link |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Round 2:
http://www.mediafire.com/download/f2...test_round2.7z This has builds of the four commits I mentioned in the last post. |
Thread Tools | Search this Thread |
Display Modes | |
|
|