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. |
24th June 2019, 15:17 | #4741 | Link | |
Banana User
Join Date: Sep 2008
Posts: 985
|
Quote:
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. |
|
24th June 2019, 16:04 | #4742 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Please test this build
https://drive.google.com/open?id=1AQ...GX2ukXE4Uy7nWV |
25th June 2019, 17:46 | #4745 | Link | |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,493
|
It is stated in the Wiki that:
Quote:
Follow up question: what is GetOffset() for? |
|
25th June 2019, 17:51 | #4746 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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;}; } 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. |
25th June 2019, 18:00 | #4748 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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. |
25th June 2019, 19:51 | #4749 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
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) |
25th June 2019, 20:06 | #4750 | Link | ||
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Quote:
EDIT:- https://github.com/pinterf/AviSynthPlus/releases Quote:
__________________
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. |
||
26th June 2019, 16:10 | #4752 | Link | |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
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. Please ignore this post. EDIT: Dec 2018, Wonkey_Monkey already reported problem here:- https://forum.doom9.org/showthread.p...16#post1860916 Pinterf response Quote:
__________________
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; 17th April 2020 at 21:07. |
|
26th June 2019, 23:33 | #4753 | Link |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,493
|
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.
|
27th June 2019, 11:01 | #4754 | Link | |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
Quote:
|
|
27th June 2019, 13:07 | #4757 | Link | ||
Registered User
Join Date: Jan 2012
Location: Mesopotamia
Posts: 2,587
|
Quote:
Quote:
edit: it seems mpc problem Code:
Colorbars(pixel_type="YV12") ConvertBits(10) ConvertToY ConvertBits(8)
__________________
See My Avisynth Stuff Last edited by real.finder; 27th June 2019 at 13:12. |
||
27th June 2019, 14:10 | #4758 | Link |
Registered User
Join Date: Jan 2014
Posts: 2,309
|
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. |
27th June 2019, 22:26 | #4759 | Link |
Moderator
Join Date: Nov 2001
Location: Netherlands
Posts: 6,364
|
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.
|
27th June 2019, 22:48 | #4760 | Link | |
...?
Join Date: Nov 2005
Location: Florida
Posts: 1,419
|
Quote:
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. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|