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.

 

Go Back   Doom9's Forum > Capturing and Editing Video > Avisynth Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 24th June 2019, 15:17   #4741  |  Link
VoodooFX
Registered User
 
Join Date: Sep 2008
Posts: 78
Quote:
Originally Posted by pinterf View Post
It worked O.K.
But when I was trying to call it more than once
Code:
InpaintFunc(mask="test.bmp", loc="tl",mode="Deblend",speed=1) 
InpaintFunc(mask="test.bmp", loc="tl",mode="Both",speed=1)
Now it crashes, we are happy now

EDIT: The plugin somehow clears or is overwriting an existing framebuffer pointer?
The crash itself occurs at an internal RGB24-RGB32 conversion but since the destination frame does not exist (zero pointer) it will show "access violation".
I'll have a look at the dll source.
It should crash with one call (InpaintFunc is not meant to work in two instances).

Here I prepared example (should work extracted to "C:"): https://drive.google.com/open?id=1fK...0cezjsVcIL5iHb

Last edited by VoodooFX; 24th June 2019 at 15:20.
VoodooFX is offline   Reply With Quote
Old 24th June 2019, 16:04   #4742  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,240
Please test this build
https://drive.google.com/open?id=1AQ...GX2ukXE4Uy7nWV
pinterf is offline   Reply With Quote
Old 24th June 2019, 18:10   #4743  |  Link
VoodooFX
Registered User
 
Join Date: Sep 2008
Posts: 78
I tested new build, and both 32 & 64 bits doesn't crash. Thank you.
VoodooFX is offline   Reply With Quote
Old 25th June 2019, 06:01   #4744  |  Link
hello_hello
Registered User
 
Join Date: Mar 2011
Posts: 3,969
I also posted in the other thread, but the new AVSInPaint build is fine on XP too.

Thank you!
hello_hello is offline   Reply With Quote
Old 25th June 2019, 17:46   #4745  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 1,810
It is stated in the Wiki that:

Quote:
In AviSynth each frame is most of the time aligned to an address divideable by 16. The exception for this rule is when crop() has been used.
But when I use crop it seems like I always get an aligned address from GetReadPtr(). Is frame alignment now always enforced?

Follow up question: what is GetOffset() for?
__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 25th June 2019, 17:51   #4746  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 7,087
Default crop align for Avs+ is now (I think) True, wheareas False for Std Avs [EDIT: if not aligned via eg RoboCrop, then produces an error alert from AVS+, on return].

from Avs v2.58 Version Header 3 [the compressed help with SDK has both Version 6 (avs+) and v2.58 version 3 headers, for easy perusal],
Code:
  // generally you shouldn't use these three
  VideoFrameBuffer* GetFrameBuffer() const { return vfb; }
  int GetOffset() const { return offset; }
  int GetOffset(int plane) const { switch (plane) {case PLANAR_U: return offsetU;case PLANAR_V: return offsetV;default: return offset;}; }
For Planar, is usual to allocate single buffer, where Y plane is aligned at start of buffer, and U, and V somewhat later, GetOffset returns the offset from buffer base (methinks).

EDIT: When you swap U and V, all it probably does is swap offsets.
EDIT: Above also (I think) mirrors official standards for file based layout of raw YUV streams [with some alignment padding for offsets and also each individual raster line].
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 25th June 2019 at 18:10.
StainlessS is offline   Reply With Quote
Old 25th June 2019, 17:58   #4747  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 1,810
Oh okay, phew, I thought I'd be going wrong all these years.

After aligned cropping it seems that Offset ends up non-zero (e.g. 16). Not sure why, probably doesn't matter.
__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 25th June 2019, 18:00   #4748  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 7,087
I think current AVS+ alignement is 32 [EDIT: Actually 64] (avs std 16) (probably thinking about 64 next, or whatever eg AVX2/later requires).

EDIT: As shown above, having v2.58 Version 3 header Baked Code, is quite handy to have [the raw cookie dough code tells you very little].

EDIT: Below some meanderings, no idea why I just wrote it.

Code:
malloc/new

Library writers long ago found that it is inefficient to allocate small blocks of memory, as that produces memory fragmentation, and so slower finding of suitable sized mem block.
So, was usual in C library, when user requested block size of eg 1 bytes, to carve off 8 bytes, and hand pointer back to user. Only 1 byte of this block belonged to the user,
but there would be no error encountered if user used up to 8 bytes as carved out from free memory lists.
Memory size returned was rounded up to a multiple of 8 bytes, so requesting 1 to 8, would carve out 8 bytes, 9 to 16, 16 bytes etc.
An additional bonus of this round up to 8 bytes, was that the memory block when free'ed, there was always enough room in that block to create a link in a linked list, for use in the
free memory list arrangement. The free memory block kept track of 'itself', without any additional overhead, and mem fragmentation was much less and also faster to find block of
sufficient size. [link list struct would hold 32 bit int size of mem block, and 32 bit pointer to next link in list, both 4 byte values on 32 bit system].
Above round up to 8 bytes also enabled the ANSI spec that malloc() returns a pointer to mem bock that is castable to a memory block structure of any type [or words something like that],
ie, some structures need be located on a memory boundary of maybe 2 bytes, 4 bytes or 8 bytes. If the initial heap base pointer is rounded to multiple of 8 bytes, and all mem blocks are a multiple
of 8 bytes, so all malloc blocks will return a mem bufer on 8 byte boundary.

Unfortunately, above used to cause novice C proggers to cock up when allocating string buffers, for small strings (less than 8 chars), as there were no problems produced when forgetting
to add 1 bytes for the nul term sentinel (zero byte) at end of string. This due to habit of writing C examples using "fred" and "ted" sized strings.
Novice C proggers would get the impression that it was unnecessary to add that 1 extra byte for the nul term because they never experienced any errors,
but of course this is bad, and perhaps the hardest of all bugs to track down.

Imagine you created a DBase for some project, and that it held Name field, and Title field, and Address etc, but that in the title field, you forgot to add the 1 byte for nul term.
Your DBase might go on seemingly OK for 5 or more years without any trouble at all, then one day you get new accound created for title "Princess", exactly 8 bytes in length, but
requiring 9 bytes in total for the buffer. you ask for 8 bytes, and this time you actually need 9, kaboom!!!, you blast a byte that does not belong to you, belongs to some other
structure or maybe even a link in the free memory list. As you repeatedly save and load (at day end/start) the DBase, each and every time, the problem is likely to move about, causing
corruption in differeing parts of your DBase, and eventually it will be noticed and become a problem.
Where do you start to look for the problem ???, you got 5 years spare to keep tabs on your next newly created DBase?

Because of the C libs malloc/calloc/new etc optimisation stuff, you have to be paranoid about that 1 extra byte, and suggest always allocate string buffers via a single function
which auto adds the required extra nul term byte. [look up the non ANSI function 'strdup()' and knock it up yourself if not supplied with your compiler
[STRICT_ANSI (or whatever the define is) will exclude it even if it does exist in your compiler].

For x64, it is most likely [ie definite] that the 8 byte fragment size mentioned above will be 16 bytes, so if you request 1 bytes from malloc, you will actually get 16, making the
above mentioned failure to add 1 byte for nul term on string buffer, an even bigger problem for string buffer bug hunting.

Also, a little aside,
Some C docs for calloc() seem to have ommitted the fact that calloc will auto zero memory [where malloc does not], think maybe MicroSoft (or someone, forgot about this more than insignificant
fact and just missed it out), and everybody else copied the erroneous docs. Perhaps your compiler mentions this clearing of memory by calloc, perhaps not [somewhere about year 1992->2000, they all/many 
[cross platform] seemed to have forgotten about it].
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 26th June 2019 at 12:02.
StainlessS is offline   Reply With Quote
Old 25th June 2019, 19:51   #4749  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,240
Avs+ alignment is 64. Crop parameter align=false does nothing. Avx2 needs 32, but it's only the present (probably processors from the last five years all support Avx2) Avx512 is the future which likes 64. However Avx2 code in Expr likes 64 byte alignment as well.
Plugin writers would safely omit pre-Avx2 optimization nowadays. C, Avx2, avx512 (at least for avs+ plugins)
pinterf is offline   Reply With Quote
Old 25th June 2019, 20:06   #4750  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 7,087
Quote:
Avs+ alignment is 64
Is that a recent change in avs+ ?

EDIT:- https://github.com/pinterf/AviSynthPlus/releases

Quote:
Avisynth+ r2542 (20171114)
Fixes
...
modification, additions


Add: Expr filter
Add: Levels: 32 bit float format support
Optimized: Faster RGB (full scale) 10-16 bits to 8 bits conversion when dithering
Other: Default frame alignment is 64 bytes (was: 32 bytes). (independently of AVX512 support)
Built with Visual Studio 2017, v141_xp toolset
some fixes in avisynth_c.h (C interface header file)
experimental x64 build with size_t frame offsets for testing more properly written C interfaces
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 25th June 2019 at 20:20.
StainlessS is offline   Reply With Quote
Old 25th June 2019, 20:53   #4751  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 1,810
Excellent, I shall optimise to my heart's content. I only have AVX though
__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 26th June 2019, 16:10   #4752  |  Link
StainlessS
HeartlessS Usurer
 
StainlessS's Avatar
 
Join Date: Dec 2009
Location: Over the rainbow
Posts: 7,087
Not sure if this has been posted recently already or not (looked back a half dozen pages could not find)

Code:
Colorbars(pixel_type="YV12")
ConvertBits(10)           # return this looks ok
return ConvertToY8        # EDIT: ConvertToY() Same


EDIT: With info added


Treating it a RGB ? (I think may have already been reported, seem to remember upside down thing).

EDIT: Think may be same problem as posted on here:- https://forum.doom9.org/showthread.p...92#post1868592
2nd code block

Code:
ConvertToYV12
#ConvertToYV16
#ConvertToYV24
#ConvertToYV411           # ConvertBits Will Fail
#ConvertToY8              # ConvertBits() 10, 12, 14, and 32 will fail (Upside down weird colors), 16 OK.
Think was also reported in Avs+ thread, but cannot find it.

Please ignore this post.

EDIT: Dec 2018, Wonkey_Monkey already reported problem here:- https://forum.doom9.org/showthread.p...16#post1860916

Pinterf response
Quote:
Thanks. Seems that it's not guarded by an error message to allow only 8 bit sources. Based on the upside down result, it simply runs on the 8 bit packed rgb case.
__________________
I sometimes post sober.
StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace

"Some infinities are bigger than other infinities", but how many of them are infinitely bigger ???

Last edited by StainlessS; 26th June 2019 at 16:33.
StainlessS is offline   Reply With Quote
Old 26th June 2019, 23:33   #4753  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 1,810
pinterf, would you consider updating colorbars some day to support all the new colour spaces? It'd be very handy to have an extremely fast source filter for every colour space (beyond using blankclip), and it could be done as an in-constructor call to the various converters, with caching of the result.
__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 27th June 2019, 11:01   #4754  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,240
Quote:
Originally Posted by wonkey_monkey View Post
pinterf, would you consider updating colorbars some day to support all the new colour spaces? It'd be very handy to have an extremely fast source filter for every colour space (beyond using blankclip), and it could be done as an in-constructor call to the various converters, with caching of the result.
Are you missing the 4:2:2 colorspaces such as YV16? The others seem to be supported (source: online documentation)
pinterf is offline   Reply With Quote
Old 27th June 2019, 11:55   #4755  |  Link
wonkey_monkey
Formerly davidh*****
 
wonkey_monkey's Avatar
 
Join Date: Jan 2004
Posts: 1,810
Those, and RGB24/48. I'm trying to be more inconclusive these days and to make sure my filter is fast for every colour space

The YUV float colour spaces seem to be wrong (unbiased chroma?):

__________________
My AviSynth filters / I'm the Doctor
wonkey_monkey is offline   Reply With Quote
Old 27th June 2019, 12:44   #4756  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,240
Quote:
Originally Posted by wonkey_monkey View Post

The YUV float colour spaces seem to be wrong (unbiased chroma?):
Yeah, unbiased chroma. I have fixed it in both ColorBars version, those were hopefully the last ones in connection with zero-based chroma thing.
pinterf is offline   Reply With Quote
Old 27th June 2019, 13:07   #4757  |  Link
real.finder
Registered User
 
Join Date: Jan 2012
Location: Mesopotamia
Posts: 1,281
Quote:
Originally Posted by StainlessS View Post
Not sure if this has been posted recently already or not (looked back a half dozen pages could not find)

Code:
Colorbars(pixel_type="YV12")
ConvertBits(10)           # return this looks ok
return ConvertToY8        # EDIT: ConvertToY() Same


EDIT: With info added


Treating it a RGB ? (I think may have already been reported, seem to remember upside down thing).

EDIT: Think may be same problem as posted on here:- https://forum.doom9.org/showthread.p...92#post1868592
2nd code block

Code:
ConvertToYV12
#ConvertToYV16
#ConvertToYV24
#ConvertToYV411           # ConvertBits Will Fail
#ConvertToY8              # ConvertBits() 10, 12, 14, and 32 will fail (Upside down weird colors), 16 OK.
I just test this with ConvertToY (which should be ok)
Quote:
Colorbars(pixel_type="YV12")
ConvertBits(10)
ConvertToY
yes there are bug here

edit: it seems mpc problem
Code:
Colorbars(pixel_type="YV12")
ConvertBits(10)
ConvertToY
ConvertBits(8)
work ok
__________________
My Avisynth Stuff

Last edited by real.finder; 27th June 2019 at 13:12.
real.finder is offline   Reply With Quote
Old 27th June 2019, 14:10   #4758  |  Link
pinterf
Registered User
 
Join Date: Jan 2014
Posts: 1,240
Test build r2888
https://drive.google.com/open?id=1nf...nn7KziYTf0BO_Q

For new features and fixes since r2772 see readme_history.txt or the shorter readme.txt.
pinterf is offline   Reply With Quote
Old 27th June 2019, 22:26   #4759  |  Link
Wilbert
Moderator
 
Join Date: Nov 2001
Location: Netherlands
Posts: 6,335
Quote:
Originally Posted by pinterf View Post
Yep, since months, I will do it as soon as I have time. Probably soon.

And then? Since ultim recently gave us access to the original Avisynth+ repo, we'll have to think about what to do next.
I would vote for making a stable 0.3 release. I will be convienient for the documentation (so people can easily see what is supported in this release) and what is supported in newer non-stables releases.
Wilbert is offline   Reply With Quote
Old 27th June 2019, 22:48   #4760  |  Link
qyot27
...?
 
qyot27's Avatar
 
Join Date: Nov 2005
Location: Florida
Posts: 1,062
Quote:
Originally Posted by Wilbert View Post
I would vote for making a stable 0.3 release. I will be convienient for the documentation (so people can easily see what is supported in this release) and what is supported in newer non-stables releases.
If we were going to go with 0.x versioning, IMO it would be 0.4. 0.2 was very nearly officially released around the r1828 mark, and 0.3 would very likely have been the addition of high bit depth pixfmts and GCC compliancy, with 0.4 being where we'd be now.

That said, I've been leaning more toward jumping the major version too (that's still in a development branch; I won't push it upstream unless/until there's discussion about it). Namely because there are programs that check for version numbers and got confused by AviSynth+ starting over at 0.x (sure, the proper way would have been to check AVISYNTH_INTERFACE_VERSION, but there's also user confusion over the versioning, and the inadequacy of using sequential revisions on the idea of integrating with pkg-config).

Last edited by qyot27; 27th June 2019 at 22:50.
qyot27 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 22:47.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.