Avisynth+

[Atak_Snajpera]

Here version 306
https://github.com/Cyberbeing/xy-VSFilter/releases/tag/3.0.0.306

[pinterf]

Have you tried the newer betas? 3.1.0.746
https://forum.doom9.org/showthread.php?t=168282

[raffriff42]

Really nice collection.

Note#1
Why do you need to ##HACK in function GBR2YUV(clip C, bool "yuva")? P

Note#2
In restore_gamma (and where luts are used) you can use the Expr function for 32bit float case.Thanks a lot, pinterf.
#1 Marked HACK, because not tested thoroughly.
#2 Masktools stuff not updated to use Expr yet, will fix.
Will start a new thread on this (soon) to avoid yet more hijacking of the current thread...

[Groucho2004]

@StainlessS:

Would you consider providing a CHM documentation for a recent AviSynth+ state again if collecting all the differences to AviSynth 2.60 doesn't mean too much efforts?
The up-to-date documentation for Avisynth and Avisynth+ is here (http://avisynth.nl/index.php/Main_Page) which even highlights functionality differences between the two (see example here (http://avisynth.nl/index.php/Colorbars)) thanks to raffriff42 spending countless hours editing the pages.

There's probably a way to cram all that into an offline thingy, be it CHM or plain HTML although I prefer the online version since it always has the latest changes.

[pinterf]

Huh, it comes with a 2.5x avisynth header, and compiled to x64? Not a life insurance.
EDIT: I mean xy-vsfilter. Not an easy thing to recompile. Cannot find afx.h. One of the uglyest message a machine can say.

[StainlessS]

@StainlessS:

Would you consider providing a CHM documentation for a recent AviSynth+ state again if collecting all the differences to AviSynth 2.60 doesn't mean too much efforts?

I might need a few months to mentally prepare for the task. :)

Raff, did you see my prev post ? (#3944)

[Groucho2004]

Huh, it comes with a 2.5x avisynth header, and compiled to x64? Not a life insurance.Yes, there is a 2.5 header floating around. I think it originates from SEt's (JoshyD's?) 2.5.8 x64 version.

[Groucho2004]

Cannot find afx.h. One of the uglyest message a machine can say.Wow, MFC. It uses CString (and probably some other MFC stuff)!

[pinterf]

I have MFC / ATL as an installed feature though.

[qyot27]

The up-to-date documentation for Avisynth and Avisynth+ is here (http://avisynth.nl/index.php/Main_Page) which even highlights functionality differences between the two (see example here (http://avisynth.nl/index.php/Colorbars)) thanks to raffriff42 spending countless hours editing the pages.

There's probably a way to cram all that into an offline thingy, be it CHM or plain HTML although I prefer the online version since it always has the latest changes.

I might need a few months to mentally prepare for the task. :)
I migrated AviSynth+'s documentation to Sphinx a few years ago, although the distinct changes or comparison pages that got into the Wiki haven't been added. It's up-to-date with the 2.6 HTML documentation, at least. The instructions to build the docs exist on the MT branch's README.md file.

The benefit of moving the docs to Sphinx is that it can be easily edited (the source files are now virtually plain-text) and once rendered, it's searchable.

Basically, whatever benefit CHM docs provide, I'm confident that Sphinx is superior to it in virtually every way. You can output to HTML, PDF, ePub, latex, and several other formats (I only did testing with HTML, though, so the nice formatting of the HTML output isn't guaranteed or even there for any of the others).

[Atak_Snajpera]

Have you tried the newer betas? 3.1.0.746
https://forum.doom9.org/showthread.php?t=168282

Support for AviSynth has been dropped after 306
http://i.cubeupload.com/lIxKW1.png

[raffriff42]

Here's a strange one.BlankClip
_aaa
return Last

function aaa(clip C) {
return C.Subtitle("HOW DID I GET HERE??", align=5)
}
It shouldn't work, but it does (note leading underscore on function call)

[pinterf]

Seems that empty dll name plus underscore plus aaa works here
EDIT: When a function is not coming from a dll, the plugin_base_name is empty, the internal secondary 'canon_name' is simply _functionname.
https://github.com/pinterf/AviSynthPlus/blob/MT/avs_core/core/PluginManager.cpp#L209

[pinterf]

Looking at raffriff42's stuff (convert Tweak-like parameters for ColorYUV), plus because I have finally implemented ColorYUV for 32 bit float, I realized that gain, contrast and gramma parameter are not really convenient and intuitive.
So I have made a ColorYUV2 with the same parameter names but accepting the Tweak-like numbers instead.
My question is about the naming - I don't like this one with 2 suffix. AdjustYUV? YUVYUV? YUVYUVYUV? :)
Or should we add a new parameter to the existing ColorYUV list as a hint to treat the parameter ranges Tweak-like?
EDIT: ColorYUV2 is an existing one so is ruled out from the contest (StainlessS)

[StainlessS]

ColorYUV2(), Hmmm, https://forum.doom9.org/showthread.php?t=156774

https://forum.doom9.org/showthread.php?p=1378126&highlight=Coloyuv2#post1378126

http://www.mediafire.com/file/875czvfnigu72ds/ColorYUV2_25_dll_20120529.zip

[raffriff42]

For a name, I think maybe ColorYUVs (s for scaled).
In a similar way, I have made (http://avisynth.nl/images/Utils-r41.avsi) Levelsc where sc means scaled - I didn't want Levelss because someday StainLessS might want the name :devil:

[StainlessS]

LevelsS, fine with me. :)

Raff, did you see the ShowChannels post, ie #3944
### show original & 3 channels (Y, U, V or R, G, B) in quad split
#@ function ShowChannels(clip C, bool "analyze", bool "uinvert", bool "chroffset")

Presumably in honour of my plugin ShowChannels :)

ShowChannels:- https://forum.doom9.org/showthread.php?t=163829&highlight=ShowChannels


EDIT: Perhaps Viewchannels().

EDIT: To below Raff post, Thanx, Raff, just wanted to ensure that you had seen that post.

[VS_Fan]

TweakYUV

[raffriff42]

StainLessS, OK, I get your drift - I'm hijacking your filter name. Henceforth, my filter will be called ShowChannelsQuad.

[real.finder]

adding a new parameter to the existing ColorYUV list is better option in my opinion

[pinterf]

I have been working on some AVS+ enhancement routines for months without promoting it.
http://avisynth.nl/images/Utils-r41.avsi

Some comments and clarifications.
- I have just checked, displaying YUV444P16 (Y416) now works with the latest (v41106) VdFilterMod.
- in AnalyzeFmt: "Note stats labeled "99%" actually 99.6% (255/256)"
This is true only for 8 bits.
For bit depths over 8 the resolution is finer, because pixel population is gathered into an array of 1024/4096...65536 entries. For float the population is also counted: using 65536 levels.
- float fullscale max is 1.0
(note: in the near future (I've already done some preparations) chroma in 32 bit float will go to -0.5..0.5 instead of current early decided 0..1.0. It'll solve the possible problems about "what is neutral grey chroma in float for a 0..1.0 range".
- when converting to float, we stretch 0..255, 0..1023.. 0..65535 into the 0..1 range. The conversion factor is not simply 2^N, but 2^N - 1.

[pinterf]

adding a new parameter to the existing ColorYUV list is better option in my opinion
Yes, let's not duplicate the very same function. f2c=true will do it.

[raffriff42]

pinterf, I appreciate the clarifications. I've noticed unexpected chroma output when converting float32 TV<->PC and now I see why.


Regarding ColorYUV, gamma has an issue - gamma is calculated between 0-255 instead of 16-235.

Here are some screenshots which (by the way) demo some Utils-r41 (http://avisynth.nl/images/Utils-r41.avsi) filters:

https://www.dropbox.com/s/kg8h4cif2s9zm4t/ColorYUV-gamma-test-21.png?raw=1
(linear response for comparison)

https://www.dropbox.com/s/bcmeekid3fp9nhc/ColorYUV-gamma-test-22.png?raw=1
(note elevated black and white levels)


https://www.dropbox.com/s/0slmrgwea9ur0k8/ColorYUV-gamma-test-23.png?raw=1
(black and white correctly unchanged)


Import(p + "Utils-r41.avsi")
s="""
BlankClip(pixel_type="YV12")
Grayramp(height=80, zigs=true)
ToPC
ColorYUV(gamma_y=f2c(1.5))
ToTV
HistogramTurn
"""
r=Eval(s)
ShowSnippet(s, r, size=24)

[raffriff42]

RGB48 & RGB64 : IsInterleaved property = false
(IsPlanar = false also)

[pinterf]

Thanks, that gamma thing found, classic avs is ok, for couriousity I'll check when it disappeared.

EDIT:
nothing has been disappeared.

The biggest difference I found is that in AVS+ the "PC->TV" and "TV->PC" conversion happens at the end of the gain-contrast-offset-gamma conversion, while classic Avisynth is doing that the the beginning of the process.

There is no correction before applying gamma in either versions. Assumes PC range.
This is why it worked for you with an input having PC levels.

Now when you want to have proper black levels you have to do similar like this:
ColorYUV(levels="TV->PC").ColorYUV(....,gamma_y=-40).ColorYUV(levels="PC->TV")
Which is obviously not a nice solution.

In theory, the ColorYUV function (after modification) would know that it should apply gamma on TV level.
We surely know that input is PC or TV range when levels="TV->PC" or "PC->TV" is given.
When none of the above levels parameters exist, coring=true would also indicate that the clip is TV range.

Probably levels="TV" (a newly allowed value for "levels") would help clarifying if none of the above mentioned options are set. (Why cannot we have frame properties in avs?)

[pinterf]

New build. So many things has been changed, now I really need feedback.

Download Avisynth+ r2636 (https://github.com/pinterf/AviSynthPlus/releases/tag/r2636-MT)

EDIT: 2632 link replaced


20180302 r2636
--------------
- Fix: Blur/Sharpen crashed when YUY2.width<8, RGB32.width<4, RGB64.width<2 (StainlessS)
- Fix: ColorYUV: don't apply TV range gamma for opt="coring" when explicit "PC->TV" is given
- Fix: ColorbarsHD: 32bit float properly zero(0.5)-centered chroma

20180301 r2632
--------------
- Fix: IsInterleaved returned false for RGB48 and RGB64 (raffriff42)
- Fix: SubTitle for Planar RGB/RGBA: wrong text colors (raffriff42)
- Fix: Packed->Planar RGB conversion failed on SSE2-only computers (SSSE3 instruction used)
- Enhanced: Blur, Sharpen
AVX2 for 8-16 bit planar colorspaces (>1.35x speed on i7-7770)
SSE2 for 32 bit float formats (>1.5x speed on i7-7770)
- Fix: Resizers for 32 bit float rare random garbage on right pixels (simd code NaN issue)
- Enhanced: Completely rewritten 16bit and float resizers, much faster (and not only with AVX2)
- Enhanced: 8 bit resizers: AVX2 support
- Enhanced: Speed up converting from RGB24/RGB48 to Planar RGB(A) - SSSE3, approx. doubled fps
- New: ConvertFPS supports 10-32 bits, planar RGB(A), YUV(A)
- New script function: int BitSetCount(int[, int, int, ...])
Function accepts one or more integer parameters
Returns the number of bits set to 1 in the number or the total number of '1' bits in the supplied integers.
- Cherry-picking from StainlessS' great RT_xxxx collection/and raffriff42 utils
- Modded script function: Hex(int , int "width"=0)
- New "width" parameter
- result is in uppercase
Width is 0 to 8, the _minimum_ width of the returned string. (8 hex digit is the max of Avisynth32 bit integer)
When width is 0 or not supplied then string length is a minimum needed.
Function now returns hex string in uppercase, instead of lowercase.
Example: Hex(255,4) returns "00FF".
- Modded script function: HexValue(String, "pos"=1)
- new pos parameter
Returns an int conversion of the supplied hexadecimal string.
Conversion will cease at the first non legal number base digit, without producing an error
Added optional pos arg default=1, start position in string of the HexString, 1 denotes the string beginning.
Will return 0 if error in 'pos' ie if pos is less than 1 or greater than string length.
- Modded script function: ReplaceStr(String, String, String[, Boolean "sig"=false])
- New parameter: sig for case insensitive search (Default false: exact search)
The uppercase/lowercase rules come from the current active code page of the OS.
- New script functions: TrimLeft, TrimRight, TrimAll for removing beginning/trailing whitespaces from a string.
Whitespaces: Tab (9), space (32), nbsp (160)
- New in ColorYUV:
New parameter: bool f2c="false".
When f2c=true, the function accepts the Tweak-like parameters for gain, gamma and contrast
E.g. use 0/0.5/1.0/1.5/2.0/3.0 instead of -256/-128/0/128/256/512
- New/Fixed in ColorYUV:
Parameter "levels" accepts "TV". (can be "TV->PC", "PC->TV", "PC->TV.Y")
Now gamma calculation is TV-range aware when either
- levels is "TV->PC" or
- coring = true or
- levels is "TV" (new - no level conversion but gamma will know proper handling)
Previously gamma was properly calculated only for PC range.
- New in ColorYUV:
32 bit float support.
- 32 bit float uses the Expr filter (8-16 bits is LUT-based). The expression is dynamically assembled for each plane, internal precision is float.
- One can specify bits=32 when showyuv=true -> test clip in YUV420PS format
For 32 bit clips "loose min" and "loose_max" (omitting the extreme 1/256 population from dark and bright pixels) statistics are computed
by splitting the 0..1 into 65536 uniform ranges.
- Modded: remove "scale" parameter from ConvertBits.
It was introduced at the very beginning of the 10+bit development, for 32bit float conversion - never used
- Enhanced: VfW: exporting Y416 (YUV444P16) to SSE2.
- 8-16 bit YUV chroma to 32 bit float: keep middle chroma level (e.g. 128 in 8 bits) at 0.5.
Calculate chroma as (x-128)/255.0 + 0.5 and not x/255.0 (Note: 32 bit float chroma center will be 0.0 in the future)
- New: Histogram parameter "keepsource"=true (raffriff42)
keepsource = false returns only the Histogram w/o the original picture.
Affects "classic", "levels" and "color", "color2", ignored (n/a) for the other modes
- New: Histogram type "color" to accept 10-32bit input and "bits"=8,9,..12 display range
- New: Histogram parameter "markers"=true
When markers = false:
For "classic": no "half" level line and no invalid luma zone coloring
For "levels": no "half" dotted line, no coloring (neither for YUV nor for RGB)
Ignored for the others at the moment.

[StainlessS]

ColorYUV(levels="TV->PC").ColorYUV(....,gamma_y=-40).ColorYUV(levels="PC->TV")
Which is obviously not a nice solution.


I used to always do like that.

- New/Fixed in ColorYUV:
Parameter "levels" accepts "TV". (can be "TV->PC", "PC->TV", "PC->TV.Y")
Now gamma calculation is TV-range aware when either
- levels is "TV->PC" or
- coring = true or
- levels is "TV" (new - no level conversion but gamma will know proper handling)
Previously gamma was properly calculated only for PC range.

Long time needed.

Lots of lovely new toys, thanx muchly :)

[LigH]

muchly

:confused: Does that exist at all?

[StainlessS]

Does that exist at all?

Muchly:- http://www.yourdictionary.com/muchly

adverb
Muchly is defined as a very informal way to say very much.
An example of muchly is when you really want something.


Informal very much: used mainly in the humorous phrase thanks muchly


Usage notes
Often regarded as a misconstruction of adverbial much.


From The Concise Oxford Dictionary, Ninth Edition, 1995. [EDIT: Before the avalanche of weird new words added to dictionaries]
Muchly: Adverb. jocular [Middle English from muchel].
Gandalf might have used it muchly, then again, he might not have.

EDIT: And yet this one got by unmentioned,
thanx muchly

EDIT: Ref below post (for LigH).
Methinks: (dated or humorous) it seems to me. [EDIT: Methinks that Bill Shakespeare probably oft used both Muchly and Methinks, and also Oft]

[pinterf]

Methinks you are right ;)

[StainlessS]

BugRep.

Was playing with S_Exlogo() v1.1, Script:- https://forum.doom9.org/showthread.php?t=154559&highlight=S_Exlogo

and was getting some kind of crash, isolated to this producing error in new avs+ (ok in avs standard).


BlankClip(Width=4,height=100,Pixel_type="YUY2",color=$808080)
Blur(1.0,0.0) # Oh no, the humanity, Error
# EDIT ADDED Alternatives
Blur(1.0) # Error
Blur(0.5) # Error


Dont know how long it has been a prob.

EDIT: Seems to be Access Violation in VDFM.
EDIT: YV12, no prob.

EDIT: This S_Exlogo() line produced error (when pat_v string is evaluated).

pat_v= ( \
Select(ok_v, \
("NoneDummy" ) , \
( (HBlur==0.0) ? "Crop(PX-4,PY,4,PH).BilinearResize(PW*4,PH).Crop(PW*3,0,PW,PH)" \
: "Crop(PX-4,PY,4,PH).Blur(HBlur,0.0).BilinearResize(PW*4,PH).Crop(PW*3,0,PW,PH)" ) , \
( (HBlur==0.0) ? "Crop(PX2, PY,4,PH).BilinearResize(PW*4,PH).Crop(0,0,PW,PH)" \
: "Crop(PX2, PY,4,PH).Blur(HBlur,0.0).BilinearResize(PW*4,PH).Crop(0,0,PW,PH)" ) , \
( (HBlur==0.0) ? "StackHorizontal(Crop(PX-2,PY,2,PH),Crop(PX2,PY,2,PH)).BilinearResize(PW*3,PH).Crop(PW,0,PW,PH)" \
: "StackHorizontal(Crop(PX-2,PY,2,PH),Crop(PX2,PY,2,PH)).Blur(HBlur,0.0)" + \
".BilinearResize(PW*3,PH).Crop(PW,0,PW,PH)" ) \
) \
)

[pinterf]

Thanks. Will look at it soon.
EDIT: This YUY2 bug probably exists since forever (quicky tested with r2266), occurs when width is less than 8.
EDIT2: Crash happens when RGB32 has width<4, and RGB64 width<2

[pinterf]

New build r2636, original post edited. Thanks StainlessS for the report.
https://forum.doom9.org/showthread.php?p=1835248#post1835248

[TomArrow]

Hello guys, new here.

I've been using AviSynth 32bit, now upgraded to AviSynth+ with that "use my old plugins" option.

Now my problem is, any time an error occurs, it seems I only get "Avisynth open failure: System exception - Access Violation". (Opening with VirtualDub or VirtualDub FilterMod)

64 Bit seems to output proper messages, for example when using with ffmpeg, but I am dependent on many 32 bit plugins from the old AviSynth.

Somewhere I read that the older release r1858-pfmod might work. I tried it (by replacing the dlls) and indeed now I got reasonable error messages like "function does not exist". I was even able to use loadPlugin to load ffms2 and load a clip with FFmpegsource2. The sad thing is, that version does not yet support deep color apparently, as it says it can't find the function ConvertBits.

Deep color is important to me and is the main reason I upgraded.

I am not sure what I'm doing wrong. I also tried running VirtualDub Filtermod as an administrator, no difference.

Interestingly, the error message does show the correct line in the script. When I move the loadPlugin for ffms2.dll down 2 lines, the error is shown as line 3 instead of 1.

But no matter what error it is, it's always just that System Exception. I can write "blahblurp" in there and still get a System Exception. This is not very helpful for debugging or finding errors.

I have a Windows 7 Ultimate 64 bit pc with an i7-3930k, 32GB RAM and a GTX 1070 on a Sabertooth X79, if it's any use.

Hope this can be resolved, as I have already tested the deep color functionality with the internal AVISource and it was pretty good! I hope to now be able to also use all my old plugins and get proper error messages.

Edit: I was able to avoid the error message altogether by calling ClearAutoloadDirs() in the beginning. Probably because I was using LoadPlugin anyway? Still, would be nice to resolve it.

[LigH]

As usual in case of problems: Use
AVSMeter.exe -avsinfo -log
to check for the availability of and possible issues with plugins.

[StainlessS]

TomArrow, At a guess, I might think plugin problem. Try Groucho2004 (on current avs+, forget older one)

AvsMeter -avsinfo -log

Post results.

EDIT: Arh, that pest LigH, is just too fast :)

EDIT: 64 bit provides error messages because it is not having a 32 bit plugin autoload problem.
Might also want to put ffms2 dll in autoload plugins directory, just to view the AvsMeter results relating to it. (can later remove)

EDIT: Some avs v2.6 plugins compiled with old avisynth header (prior to avisynth 2.6 Alpha 4) will crash if used on Avisynth v2.6 Alpha 4
and later, guessin that this may be the problem (because the older avs+ works ok, probably from pre alpha 4 era).

EDIT: Was your previous Avisynth version, before Avs 2.6 Alpha 4 ?

[TomArrow]

Damn you guys are fast. Thanks for the answers!

I tried what you said and entered that commandline, but all I get is a "Query Avisynth info..." stuck for minutes with CPU at 17% or so (probably one core).

Edit: Interesting point. So your theory is basically that there are incompatible plugins in my folder and they trigger the error, even if the one I'm actually requesting is not responsible for the error? (since I was able to load it with loadPlugin after disabling autoload)

[StainlessS]

v2.6 Alpha 4 and later sets some linkage stuff (below in blue), which is not done in plugins compiled before alpha 4.
When plugin accesses avisynth v2.6 Alpha 4 (and later) internal routines then below blue stuff not properly prepared and bang !!!


#ifdef AVISYNTH_PLUGIN_25
extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env) {
#else
const AVS_Linkage *AVS_linkage = 0;
extern "C" __declspec(dllexport) const char* __stdcall
AvisynthPluginInit3(IScriptEnvironment* env, const AVS_Linkage* const vectors) {
AVS_linkage = vectors;
#endif
env->AddFunction("DeCrack", "c[[Fade]f",Create_DeCrack, 0);
return "`DeCrack' DeCrack plugin";
// A freeform name of the plugin.
}


EDIT: AvsMeter will probably not be able to tell you anything about bad plugin that is not compiled with later avisynth header,
Avsmeter might well crash for same reason as avisynth with old plugin in plugins directory. [EDIT: dont know if it checks AVS_linkage for NULL]
You may have to manually pinpoint bad plugins by trial and error (clear plugins, then add in batches of maybe 10 and test, then remove and try next batch, until problem batch located, then narrow down to bad plug [there may be more than 1 bad plug])

EDIT:
Edit: Interesting point. So your theory is basically that there are incompatible plugins in my folder and they trigger the error, even if the one I'm actually requesting is not responsible for the error? (since I was able to load it with loadPlugin after disabling autoload)
Yes.

EDIT: Not sure, perhaps AVS_linkage=NULL, only produces a problem on last autoloaded bad plugin,
EDIT: Maybe not, I guess that AVS_linkage is private copy for each individual plugin.

EDIT: Found the problem thing here:- https://forum.doom9.org/showthread.php?p=1703427#post1703427
@Jenyok,
Are you using an old version of Avisynth v2.6, If so, you need to update as ClipClop uses new AvisynthPluginInit3() only available in Alpha 4+ ?
(Or alternatively use the v2.58 dll).
There will (I think) be a reciprocal problem if plugin compiled with pre-Alpha 4 header, and not using AvisynthPluginInit3().
[So as previously posted in this thread, I was on the 'right track', but a bit back-to-front :) ]

[TomArrow]

Okay that makes sense, I will do that try-and-error for the batch of plugins when I find some time to do that. Meanwhile I'll just load manually. Thanks a lot!

[pinterf]

@raffriff42: Big thanks for the documentation update, I was just about to do that for recent r2636 changes and saw that you have already done that.
I have added one or two things (e.g. ColorYUV supports float, levels "TV", gamma handling, Histogram "bits") and clarified AddAlphaPlane that it can use a single Y clip or a number as the source for Alpha plane.
I hope I kept the standard formatting.

[raffriff42]

Yes, good work! You also caught an omission I made re: classic AviSynth - ColorYUV(levels="TV.Y")

[StainlessS]

EDIT: Oops, moved to Mvtools, then moved to here.
EDIT: Moved here from thread in Avisynth Usage

EDIT: Does NOT occur in AVS v2.61 standard.

Weird Colors in YUY2.

If using MPeg2source with UpConv=1 (YUY2) then wierd colors after MCDegrainSharp, OK if UpConv=0(YV12).

What is causing the problem (easy to solve, just dont use UpConv=1).

test.demuxed.log

Stream Type: Elementary
Profile: main@main
Frame Size: 720x576
Display Size: [not specified]
Aspect Ratio: 16:9 [3]
Frame Rate: 25.000000 fps
Video Type: PAL
Frame Type: Progressive
Coding Type: B
Colorimetry: BT.470-2 B,G*
Frame Structure: Frame
Field Order:
Coded Number: 252
Playback Number: 2
Frame Repeats: 0
Field Repeats: 0
VOB ID:
Cell ID:
Bitrate:
Bitrate (Avg):
Bitrate (Max):
Timestamp:
Elapsed: 0:00:00
Remain: FINISH
FPS:
Info:


test.demuxed.d2v (I modified path to .\test.demuxed.m2v so that it works from any path)

DGIndexProjectFile16
1
.\test.demuxed.m2v

Stream_Type=0
MPEG_Type=2
iDCT_Algorithm=6
YUVRGB_Scale=1
Luminance_Filter=0,0
Clipping=0,0,0,0
Aspect_Ratio=16:9
Picture_Size=720x576
Field_Operation=0
Frame_Rate=25000 (25/1)
Location=0,0,0,c65

900 5 0 0 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 340612 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 661168 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 985564 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 1305512 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 1621368 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 1937628 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 2253180 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 2569228 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 2883316 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 3193184 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 3499688 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 3807236 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 4115012 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 4424460 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 4726408 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 5023844 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 5317740 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 5616652 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 5912792 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2
900 5 0 6198648 0 0 0 32 32 92 b2 b2 a2 b2 b2 a2 b2 b2 a2 ff

FINISHED 100.00% VIDEO


test.demuxed.avs

VideoFileName = ".\test.demuxed.d2v"

# YV12 OK, YUY2 produces weird output
UPCONV=1 # 0=YV12, 1 = YUY2

MPEG2Source(VideoFileName,UpConv=UPCONV)

MCDegrainSharp_MOD() # simplified version 1 frame radius only, blocksize 8

return last

Function MCDegrainSharp_MOD(clip c) {
BS=8
OS=4
c2 = c.blur(0.6)
super = c2.MSuper(pel=2, sharp=1)
super_rend = c.sharpen(0.6).MSuper(pel=2, sharp=1,levels=1)
bvec = MAnalyse(super, isb = true, delta = 1, blksize=BS, overlap=OS)
fvec = MAnalyse(super, isb = false, delta = 1, blksize=BS, overlap=OS)
Return c2.MDegrain1(super_rend, bvec,fvec,thSAD=400)
}


Upconv=0 (YV12, OK)
https://s20.postimg.cc/5otpzz9zx/test.demuxed_YV12.jpg (https://postimages.cc/)

Upconv=1 (YUY2, BAD)
https://s20.postimg.cc/9xyg27q4t/test.demuxed_YUY2.jpg (https://postimages.cc/)

Anybody any ideas as to the cause (just curious). [EDIT: Ignore this line, looks like avs+ prob]

Thanx in advance for any answers. [EDIT: Also ignore]

7z (~5.6MB) with about 10 secs m2v + d2v + log + avs)
http://www.mediafire.com/file/pjc49ynwxbpgjb0/WeirdText.7z

EDIT: Maybe Avs+ YUY2 blur still has problems (Still occurs with mvtools v2.5).
EDIT: I dont really notice any problem on live video, only came to light on subtitles[EDIT: credits].

EDIT: Replacing MCDegrainSharp_MOD with blur(0.6) removes problem, maybe its the Sharpen inside MCDegrainSharp that is the problem.

[pinterf]

EDIT: Maybe Avs+ YUY2 blur still has problems[EDIT: credits].
Thanks.
sharpen(0.6) does it.

[StainlessS]

Yep, thanx I just figured that out too. :)

[pinterf]

Found an old comment
// sse2/mmx versions are not identical to C. Sharpen(1.0, 1.0) has ugly artifacts
I removed the sse/mmx code to run it in plain C and it became O.K. Now let's find the bug in the SIMD code.
EDIT: YUY2 sharpen overflow fixed on Github

[real.finder]

The old bug is back, but now it's dither_lut16 is the culprit.
It seems that under Win10 (?) configuration it understands only the decimal separator of the current input local.

Just replace the decimal point to commas in yexpr parameter and it will work fine. (the used ReplaceStr is built-in in AVS+)

function Dither_Luma_Rebuild (clip src, float "s0", float "c",int "uv", bool "lsb", bool "lsb_in", bool "lsb_out", int "mode", float "ampn", bool "slice"){
[...]
src
lsb ? (lsb_in ? Dither_lut16 (yexpr=ReplaceStr(e,".",","),expr="x 32768 - 32768 * 28672 / 32768 +",y=3, u=uv, v=uv) : \
Dither_lut8 (yexpr=ReplaceStr(e,".",","),expr="x 128 - 32768 * 112 / 32768 +" ,y=3, u=uv, v=uv)) : \
avs26 ? mt_lut(yexpr=e,expr="x range_half - range_half * 112 scaleb / range_half +",y=3, u=uv, v=uv) : \
mt_lut(yexpr=e,expr="x 128 - 128 * 112 / 128 +" ,y=3, u=uv, v=uv)

[...]
}


btw, will this make the systems that use dot has wrong outputs?

[LigH]

Of course.

Systems with a locale using a decimal dot need a decimal dot. If there are locale-independent functions to process numbers, they should default to this syntax.
Systems with a locale using a decimal comma need a decimal comma if numbers are processed depending on the locale.

It would be pretty strange if there were no more locale-independent number functions available under Windows 10, that would interrupt international data exchange in text form.

Implementing a locale-aware conversion in the script would be quite annoying, but possibly not impossible?! But finding a locale-independent implementation that works in Windows 10 as well should be preferable.

[tormento]

Implementing a locale-aware conversion in the script would be quite annoying, but possibly not impossible?! But finding a locale-independent implementation that works in Windows 10 as well should be preferable.
It should be AVS+ to work accordingly to windows local settings, not the script itself.

[Motenai Yoda]

I do no agree, it should indipendent from windows locale

also 666 posts on post #3999 :devil:

[LigH]

Resist the dark side you must.

And an international portability of scripts can only work when the syntax (here: of numbers) is locale-independent.

Locale-dependent handling of numbers is fine in user interfaces, where an immediate relation between the widget a user fills with a value and the layout of the keyboard the user utilizes can be assumed.