AviSynth 2.6.0 Alpha3 [May 25th, 2011]

[Gavino]

why do I get the wrong lines at the top when n>=26?

function layernonissue(clip base, clip over, int n) {
n<2?layer(base,over.crop(0,n-1,0,1),y=n-1):layer(layernonissue(base,over.crop(0,n-1,0,1),n-1),over.crop(0,n-1,0,1),y=n-1)
}
Because your script is wrong - you are passing a one-line clip on the recursive call, which then gets cropped beyond its end. (This should give an error, but doesn't, which is the bug you've already reported.)
The second parameter should just be over at all recursive levels. (Would have been easier using GScript ;))

The same error exists in overlayissue, which probably explains the crashes for large n.

[jmac698]

Great, that fixed one of the problems. There is still a huge amount of memory used in overlay, hundreds of MB.

#Overlay uses color conversions, this can be a problem if called many times
#you will see an increasing yellowish color at the top of the screen
#the script also uses a large amount of memory
#Layer has none of these issues
base=blankclip.trim(0,9)
over=colorbars.trim(0,9)
showissue=true#Be careful with overlayissue, large values of n cause excessive memory use leading to a crash
showissue?overlayissue(base,over,25):layernonissue(base.resetmask,over.resetmask,400)
function overlayissue(clip base, clip over, int n) {
n<2?overlay(base,over.crop(0,n-1,0,1),y=n-1):overlay(overlayissue(base,over,n-1),over.crop(0,n-1,0,1),y=n-1)
}
function layernonissue(clip base, clip over, int n) {
n<2?layer(base,over.crop(0,n-1,0,1),y=n-1):layer(layernonissue(base,over,n-1),over.crop(0,n-1,0,1),y=n-1)
}

[GRKNGLR]

There is no MT in either the Alpha 1 or 2 releases. I have noted SEt's changes for a subsequent release. I will very probably not be doing threading the messy SetMTmode() way.

When will an MT-supporting version be released? Will there be x64 support at the 2.6 release?

[kemuri-_9]

latest repository does not compile in .net 2008:


1>.\filters\levels.cpp(187) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>.\filters\levels.cpp(201) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>.\filters\levels.cpp(213) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>.\filters\levels.cpp(224) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
1>.\filters\levels.cpp(236) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int

since the fix is trivial i'll withhold posting a patch.

[yup]

I try last official Avisynth 2.6 with simple script
ImageSource("TSW Charger V4.4.jpg", end=0)
ConvertToYUY2()
nnediresize_YUY2()
function nnediresize2x(clip c, bool pY, bool pU, bool pV)
{
v = c.nnedi3(dh=true,Y=pY,U=pU,V=pV,field=0).turnleft()
v = v.nnedi3(dh=true,Y=pY,U=pU,V=pV,field=0).turnright()
return v
}

function nnediresize_YUY2(clip c)
{
cy = c
cu = c.utoy()
cv = c.vtoy()
cy = nnediresize2x(cy,true,false,false)
cu = nnediresize2x(cu,true,false,false)
cv = nnediresize2x(cv,true,false,false)
return ytouv(cu,cv,cy)
}

function nnediresize_YV12(clip c)
{
return nnediresize2x(c,true,true,true)
}

for enlarge image, it is work with YV12 colorspace, but not work with YUY2.
Please explain.
yup.

[IanB]

Sorry the YUY2 version of the YtoUV() code is broken. See post 132 above by Stainless.

The planar version works so you could use an intermediate YV16 and then convert that to YUY2 at the end.

Also a better workflow in 2.6 would be RGB -> YV24 -> nnedi3 -> YV16 -> YUY2, which would save doubling the chroma width.
ImageSource("TSW Charger V4.4.jpg", end=0) # RGB Format

ConvertToYV24() # No chroma subsampling

nnediresize_YUY2()

function nnediresize2x(clip c, bool pY, bool pU, bool pV)
{
v = c.nnedi3(dh=true,Y=pY,U=pU,V=pV,field=0).turnleft()
v = v.nnedi3(dh=true,Y=pY,U=pU,V=pV,field=0).turnright()
return v
}

function nnediresize_YUY2(clip c)
{
cy = c.ConvertToY8().ConvertToYV12() # Fast extract Y, blank chroma
cu = c.UtoY8().ConvertToYV12() # Fast extract U to Y, blank chroma
cv = c.VtoY8().ConvertToYV12() # Fast extract V to Y, blank chroma

cy = nnediresize2x(cy,true,false,false) # Double height and double width

cu = nnedi3(dh=true,Y=True,U=False,V=False,field=0) # Double height only
cv = nnedi3(dh=true,Y=True,U=False,V=False,field=0) # Double height only

YtoUV(cu,cv,cy) # YV16 output
return ConvertToYUY2() # Lossless conversion to YUY2
}The *toY8() are all zero cost (pointer flip only) for planar. The Y8 to YV12 costs a plane blit + 2 memfills. A normal YV24 to YV12 would cost a resize of the chroma but as we don't want them here we can save a lot. As nnedi3() is a 2.5 filter it must have YV12.

[yup]

IanB :thanks:
But I get error at line
cy = c.ConvertToY8().ConvertToYV12() # Fast extract Y, blank chroma
yup.

[IanB]

@yup,

And the error message is ???? :confused:

[yup]

IanB!
Please.
Line 5 it it is line calling nnediresize_YUY2(), Line 16 it it is line cy = c.ConvertToY8().ConvertToYV12() # Fast extract Y, blank chroma
yup.

[Gavino]

Sorry the YUY2 version of the YtoUV() code is broken.
Is this fixed in CVS?
Any timescale for getting a new release out?
On 18th Jan 2011, you said:
The bugfix list has become pretty meaty, perhaps I should devote some cycles to give people a release. I'll try to put some effort into fixing the offset errors in the planar conversions and then roll out another alpha release soon.
I know there are some third party CVS builds floating about, but a new official release (even if still alpha) would be a very welcome addition.

@yup:
Wouldn't it have been more useful just to quote the error message? - images can take some time to be approved by a mod.

[IanB]

@Yup,

Looks like ConvertToYV12() is broken with Y8 input. :( You will have to go from YV24 direct to YV12 and wear the performance hit with this alpha release.

A possible faster solution might beFastishY8toYV12(Clip C) {
UV = Blankclip(C, Width=C.Width()/2, Height=C.Height()/2, Color=$808080)
Return YtoUV(UV, UV, C)
}

And Join Date: Feb 2003, Posts: 549, and you still can't report error messages as text. Hint: Press Control-C in VirtualDubs Error Messagebox, this copies the error text to the clipboard.

@Gavino,

Yes, I think most of these bugs have been addressed, and I am crawling towards doing another interim release, this time it might actually be somewhat tested.

[pbristow]

IanB,

No feature requests or bug reports from me at this time, just wanted to say thankyou for all the effort you're putting into this new V2.6. I'm looking forward to trying out the next official build. :)
:thanks:

[Wilbert]

@yup,

I moved several 'nnedi3 resize' posts to a new thread (http://forum.doom9.org/showthread.php?t=160887).

[pwnsweet]

I think I may have found a bug with Avisynth 2.5.8, MeGUI or something else, but I think it's with AviSynth. Before I can confirm it is a bug, it would be appreciated it someone can replicate my workflow to confirm that they have the same problem.

I'm using MeGUI 2008 (svn) to encode my movies. Basically I'm having a problem where the color displayed in the avs script creator window is never the same as the source, but the resultant encoded video is. I experienced this issue when indexing an .m2ts Blu-ray file (with an MPEG-2 video stream) using DGindex. When the .d2v is loaded into avs script creator, I've got the option to enable or disable color correction in the filters tab. Setting this option to on or off changes the colors slightly in the preview window (most noticeably with greens and reds) but neither setting produces the same colors as the source. Interestingly though, the colors of the actual encoded video had the same colors as the source when color correction was turned off.

Now, I'm not sure if this is a bug in AviSynth or a bug with me (ie, I'm not comparing them properly). So here's how I compare.

I open the source with Daum PotPlayer and then I open the preview window in avs script creator and compare them side by side with and without color correction. The result is neither setting produces the same colors as the source. When I'm comparing the encoded video to the source, I open the encoded mp4 in one PotPlayer window and the source in another and compare them side by side. The result is the encoded video only has the same color as the source when color correction is off. That's it.

Can someone please replicate this issue to see if they have the same problem? For reference, my source was Mission Imposssible 3 on Blu-ray. Alternatively, if there is a flaw in the way I compare, please point it out and explain why it's flawed so I can further my understanding (I'm noob). My script with color correction set to off is displayed below:

# Set DAR in encoder to 65 : 27. The following line is for automatic signalling
global MeGUI_darx = 65
global MeGUI_dary = 27
LoadPlugin("D:\stuff\megui\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\Temp\MI3\00003.d2v")
#deinterlace
crop( 0, 130, 0, -132)

Spline36Resize(1504,640) # Spline36 (Neutral)
#denoise

[poisondeathray]

I think I may have found a bug with Avisynth 2.5.8. Before I can confirm it is a bug, it would be appreciated it someone can replicate my workflow to confirm that they have the same problem.

I'm using MeGUI 2008 (svn) to encode my movies. Basically I'm having a problem where the color displayed in the avs script creator window is never the same as the source, but the resultant encoded video is. I experienced this issue when indexing an .m2ts Blu-ray file (with an MPEG-2 video stream) using DGindex. When the .d2v is loaded into avs script creator, I've got the option to enable or disable color correction in the filters tab. Setting this option to on or off changes the colors slightly in the preview window (most noticeably with greens and reds) but neither setting produces the same colors as the source. Interestingly though, the colors of the actual encoded video had the same colors as the source when color correction was turned off.

Now, I'm not sure if this is a bug in AviSynth or a bug with me (ie, I'm not comparing them properly). So here's how I compare.

I open the source with Daum PotPlayer and then I open the preview window in avs script creator and compare them side by side with and without color correction. The result is neither setting produces the same colors as the source. When I'm comparing the encoded video to the source, I open the encoded mp4 in one PotPlayer window and the source in another and compare them side by side. The result is the encoded video only has the same color as the source when color correction is off. That's it.

Can someone please replicate this issue to see if they have the same problem? For reference, my source was Mission Imposssible 3 on Blu-ray. Alternatively, if there is a flaw in the way I compare, please point it out and explain why it's flawed so I can further my understanding (I'm noob). My script with color correction set to off is displayed below:

# Set DAR in encoder to 65 : 27. The following line is for automatic signalling
global MeGUI_darx = 65
global MeGUI_dary = 27
LoadPlugin("D:\stuff\megui\tools\dgindex\DGDecode.dll")
DGDecode_mpeg2source("D:\Temp\MI3\00003.d2v")
#deinterlace
crop( 0, 130, 0, -132)

Spline36Resize(1504,640) # Spline36 (Neutral)
#denoise



probably a playback issue

the preview in megui uses rec601 to convert to rgb for display

your player is probably using rec709 for hd material

levels are untouched and you remain in YUV when you encode with that script using megui

ie. no additional RGB<=>YUV conversions are going on here , only when it's converted to RGB for display



To test this out, add converttorgb(matrix="rec709") to the end of your script, what does the preview look like in megui ? Comment it out (#)before you encode

[pbristow]

So, when you open both the source and the encoded video using *the same player* (PotPlayer), they have the same colours (provided you set colour correction to off). But if you open them in different players (one in PotPlayer, one in MeGui), they look different. Clearly then, the two players are disagreeing with each other about how the colours should be rendered on screen.

poisondeathray's explanation for that is probably correct... Or it could be a bug in either MeGui or PotPlayer. Nothing points to AviSynth as causing the problem.

Hope that helps. :)

[IanB]

An interim patch release.

Get AviSynth_110525.exe (4.9MiB) (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%203%20%5B110525%5D/AviSynth_110525.exe/download) from SourceForge.

Note, it's now a full release with the documentation component.

[Mini-Me]

An interim patch release.

Get AviSynth_110525.exe (4.9MiB) (http://sourceforge.net/projects/avisynth2/files/AviSynth_Alpha_Releases/AVS%202.6.0%20Alpha%203%20%5B110525%5D/AviSynth_110525.exe/download) from SourceForge.

Note, it's now a full release with the documentation component.

YAYYYY!!! It's funny, because I've been having some crashes this week with complex ScriptClip stuff, and I've been checking here for the past three days hoping for a new 2.6 release. I felt silly expecting it to be posted so imminently, but lo and behold! :)

I can't wait for the time to check it out. Thank you!

[Wilbert]

Thanks for the new release!

If I read the code correctly (and your adjusted documentation) i see that an YV12 clip (when converting to YV12 itself) is processed when ChromaInPlacement or ChromaOutPlacement is specified, right? (So this can be used to change the chroma placement in an YV12 clip.) I guess when both are specified and equal, the original clip can also be returned?


if (clip->GetVideoInfo().IsYV12()) {
if (!args[3].Defined() && !args[5].Defined()) || (args[3] == args[5])
return clip;
}

[IanB]

If I read the code correctly (and your adjusted documentation) i see that an YV12 clip (when converting to YV12 itself) is processed when ChromaInPlacement or ChromaOutPlacement is specified, right? (So this can be used to change the chroma placement in an YV12 clip.) I guess when both are specified and equal, the original clip can also be returned?AVSValue ... ConvertToPlanarGeneric::CreateYV12(...) {
...
if (clip->GetVideoInfo().IsYV12()) {
if (!args[3].Defined() && !args[5].Defined()) || (args[3] == args[5])
return clip;
}
...Yes it can be used to change the chroma placement in an YV12 clip.

And yes the code probably should check for ChromaInPlacement == ChromaOutPlacement, it currently relies on the resizer core to detect a null operation however the frame will still be plane split and reassembled so cost a needless set of blits.

[Mini-Me]

The new release has unfortunately not solved my crashes, so a question occurred to me: What's the best way to debug a crash in Avisynth?

I'm currently using a script that should take about 8 hours to complete. It previously crashed in places like a quarter to a third of the way through, and it just crashed at over 80% complete instead with Alpha3 (an improvement ;)). If I load the script through Virtualdub for rendering, I get "Dub/IO-Video error: (Unknown) (80004005)," and if I render the script to .avi through AvsPMod, it just suddenly skips to "Done" as if it finished (but the file isn't complete). Is there another way to run Avisynth that will give me more information about what's causing the crash?

Thanks for both your advice and your hard work! :)

[Wilbert]

And yes the code probably should check for ChromaInPlacement == ChromaOutPlacement, it currently relies on the resizer core to detect a null operation however the frame will still be plane split and reassembled so cost a needless set of blits.
Ok, i see what you mean. Second attempt:


AVSValue __cdecl ConvertToYV12::Create(AVSValue args, void*, IScriptEnvironment* env)
{
PClip clip = args[0].AsClip();
const VideoInfo& vi = clip->GetVideoInfo();

if (vi.IsYV12()) {
if (!args[3].Defined() && !args[5].Defined()) || (args[3] == args[5])
return clip;
}

if (vi.IsYUY2() && !args[3].Defined() && !args[4].Defined() && !args[5].Defined()) // User has not requested options, do it fast!
return new ConvertToYV12(clip,args[1].AsBool(false),env);

return ConvertToPlanarGeneric::CreateYV12(args,0,env);
}



@Mini-Me,
The new release has unfortunately not solved my crashes, so a question occurred to me: What's the best way to debug a crash in Avisynth?
Could you simplify your script as much as possible (retaining the crash) and post it?

[Gavino]

Thanks for all your work on the new release, Ian.

if (vi.IsYV12()) {
if (!args[3].Defined() && !args[5].Defined()) || (args[3] == args[5])
return clip;
}
You've got a misplaced bracket there. ;)
I think you mean
if ((!args[3].Defined() && !args[5].Defined()) || (args[3] == args[5]))

[pbristow]

Where can I find an up-to-date list (preferably with definitions, not just the abbreviations) of the colourspaces that are support by this release? I've found various posts that talk about what colourspaces are/were intended for Avisynth 2.6 and for 3.0, but I'm getting a confused picture of what's been implemented so far.

I know 2.6 has the YV16 (Like YV12 but the chroma is only halved in one dimension) and YV24 (chroma is full resolution) variants. What else? Do we have ways of storing 12 bit or 16 bit luma yet (plus the core filters to work with it, of course)?
I've been shying away from trying the development/alpha versions, but if 2.6.0.2 has the colourspaces I want to work in then I'll take the plunge! :)

[Mini-Me]

@Mini-Me,

Could you simplify your script as much as possible (retaining the crash) and post it?

I can post it, but simplifying it while retaining the crashes would probably be quite difficult. It calls a function that uses [G]ScriptClip recursion, and along with all of its helper functions, it's over 350 lines long. (A lot of the lines are comments, but taking those out before posting would probably be unwise.) The crashes seem to have a direct relationship with the complexity and amount of work done. I could strip out some features (effectiveness ;)) and robustness and bring it down to the core algorithm, and it might still crash, but it would probably take a lot longer and require a clip the length of The Ten Commandments movie (and it already takes hours of peaceful and effective operation before it suddenly fails). Would you still be interested in seeing it as-is?

I have another script that crashes in the same way, but it's just as long and probably more complex. Some months ago, I was getting crashes with simpler and non-recursive (but more numerous) [local] [G]ScriptClip functions, but the total combined length of the functions was similar.

[Wilbert]

Where can I find an up-to-date list (preferably with definitions, not just the abbreviations) of the colourspaces that are support by this release?
See http://avisynth.org/mediawiki/ConvertToRGB or http://avisynth.org/mediawiki/Filter_SDK/Data_storage .

Do we have ways of storing 12 bit or 16 bit luma yet (plus the core filters to work with it, of course)?
Nope to both questions.

@Gavino, yes thanks. I probably looked at vba too long where you don't need all those brackets.

[Wilbert]

@Gavino,

I merged a post of you (thread consisting of one post) in this thread: http://forum.doom9.org/showthread.php?p=1394689#post1394689 . Is that issue still relevant?
For some time, I have been puzzled (and mildly annoyed!) that using a run-time function like AverageLuma outside of a run-time filter (ScriptClip, etc) produces the error "Invalid arguments to function ...", especially when the source code contains logic to produce the more helpful "This filter can only be used within ConditionalFilter". So I decided to investigate properly.

The reason the more helpful (and presumably intended) message is not produced is that the code (in AveragePlane::AvgPlane and elsewhere) looks like this:
AVSValue cn = env->GetVar("current_frame");
if (!cn.IsInt())
env->ThrowError("Average Plane: This filter can only be used within ConditionalFilter");
However, if current_frame does not exist (the usual case outside the run-time environment), GetVar will throw a NotFound exception and the error-checking code will never be reached. The exception is propagated back to the parser, which is evaluating the original call to AverageLuma (etc), where it sees this as an inability to call and reports it as "Invalid arguments".

The solution is to use the exception-protected GetVar from conditional_reader.h instead of env->GetVar to read current_frame (in 4 places in conditional_functions.c). At the same time, the error message could be changed to refer to "run-time filters" instead of specifically to ConditionalFilter (which I suspect was the only one that existed when this code was written).

[Gavino]

@Gavino,

I merged a post of you (thread consisting of one post) in this thread: http://forum.doom9.org/showthread.php?p=1394689#post1394689 . Is that issue still relevant?
It's fixed now (by IanB in revision 1.10 of conditional_functions.cpp).

[IanB]

In general the construct (args[3] == args[5]) never expresses a useful intent. In most cases you should be comparing the contents of the AVSValue, i.e. (args[3].AsInt() == args[5].AsInt()).

In the case here to get Wilberts intent and avoid the redundant blits it would be :-
... (getPlacement(Arg[3].AsString(0)) == getPlacement(Arg[5].AsString(0)))




@Mini-Me,

You need to post your script so we can get some idea what your issue might be. As this is a long standing problem that spans multiple version you probably should start a new thread to discuss this problem in detail. A first initial guess given things fall out of the sky without an Avisymth exception report of some sort is you are exhausting the process address space. Reporting an error does need some free memory. Monitor the process virtual memory size, if it is growing and over 1.5GB then that is a very strong indicator.


@pbristow,

At the script level there is currently YV24, YV16, YV12 and YV411 as YUV tri-planar formats.

The core is currently capable of handling any planar format with 1, 2, or 4 times subsampling independently in horizontal and vertical directions, you just can't script it yet.

[pbristow]

Thanks, Wilbert and Ian. In other words, "we're getting there, be patient", eh? :)

[EDIT:] Ah, hang on... To clarify, Ian, do you mean the core can now handle any planar format *in any (likely) bit depth*? Or is it restricted to 8-bit components? (Colour subsampling doesn't worry me so much, as I find YV12 adequate for almost everything on that score - Although it's good to know that other options are available when required.)

[Mini-Me]

@Mini-Me,

You need to post your script so we can get some idea what your issue might be. As this is a long standing problem that spans multiple version you probably should start a new thread to discuss this problem in detail. A first initial guess given things fall out of the sky without an Avisymth exception report of some sort is you are exhausting the process address space. Reporting an error does need some free memory. Monitor the process virtual memory size, if it is growing and over 1.5GB then that is a very strong indicator.
Thanks, Ian. I knew that crashes span multiple versions, but I wasn't sure if I was experiencing a typical issue or an unusual one. Looking at the virtual memory, I have a script less than two hours in that's currently at 950,000 KB and growing...growing...so I'm pretty sure you're right. It's just continually allocating memory and rarely releasing anything. (It ended up crashing at 1,199,420 KB.) Is continuous memory growth by design, due to a memory leak in Avisynth, or specific to certain scripts (in which case I should start another thread as you suggest)?

Before I start a new thread and thrust a gargantuan script upon people (perhaps needlessly), I should ask: How does SetMemoryMax behave with a single Avisynth instance? If I set a limit, would that just make it crash faster, or would it compel Avisynth to try recycling its own resources?

[IanB]

@pbristow,

Yes 8 bit only. I have been reserving bit positions and fleshing out constants definitions in the 2.6 API in anticipation for supporting 16 and 32 bit data elements in a future version, but there is no associated code yet and no data format definitions.


@Mini-Me,

SetMemoryMax only sets the size of the frame buffer cache. It is independent of any other memory allocation. Memory usage due to the frame cache should ramp up pretty quickly to the limited value and stay there. Setting a lower SetMemoryMax value will make more memory available for other purposes and provide less cache buffer frames. It is pointless having more buffers available than are needed by the scripts temporal requirements. If each and every frame generated at each and every stage of a script is only ever used once then the cache is entirely useless. By definition a cache is only useful if a generated element is needed a second or subsequent time.

[StainlessS]

Not sure where I should post this.
Had problem with MergeChroma(c1,c2,weight=1.0) as in 2.58 documentation.
Looked in Avisynth source, there is no "weight" arg, should be
"LumaWeight" for MergeLuma() and "ChromaWeight" for MergeChroma().
Installed the new Alpha 3 and checked docs, still the same, needs
amending for next issue.

[Wilbert]

Had problem with MergeChroma(c1,c2,weight=1.0) as in 2.58 documentation.
Looked in Avisynth source, there is no "weight" arg, should be
"LumaWeight" for MergeLuma() and "ChromaWeight" for MergeChroma().
Installed the new Alpha 3 and checked docs, still the same, needs
amending for next issue.
Thanks for your report. I will correct the documentation.

[Gavino]

Thanks for your report. I will correct the documentation.
I think it would be better (and more consistent) to change the code instead, and use 'weight' for all three Merge filters. I know it would not be backwards compatible, but in practice it's unlikely to cause great problems to anyone.

[StainlessS]

I think it would be better (and more consistent) to change the code instead, and use 'weight' for all three Merge filters. I know it would not be backwards compatible, but in practice it's unlikely to cause great problems to anyone.

Absolutely, that had occured to me but dismissed suggesting it.
No-one seems to have noticed it before, so change it to the
more sensible and less demanding and more obvious
choice

[IanB]

Yes it makes more sense to just use "Weight" everywhere, I will add some aliases to the Merge_filter AVSFunctions to match the doco and maintain legacy compatibility.

[Mounir]

Question for IAnB:
Does this alpha version convert correctly YV12 to YUY2 and perhaps RGB >YV12 aswell ?
See the related Chroma shift topic here (http://forum.doom9.org/showthread.php?t=147629&page=2)

Edit:
Oh yeah before i do something wrong, all the filters work with the v2.6 or should i keep the v2.58 in case ?

Also i have a problem with mediacoder (not your concern i know) it seems it don't support avisynth 2.6 (it can't decode a simple script) What software do you recommend (with v2.6 support) so i can encode in x264, thank you

[Chikuzen]

What software do you recommend (with v2.6 support) so i can encode in x264, thank you
x264CLI completely supports the features of avs2.6 at present.

[IanB]

Question for IanB:
Does this alpha version convert correctly YV12 to YUY2 and perhaps RGB >YV12 as well ?
See the related Chroma shift topic here (http://forum.doom9.org/showthread.php?t=147629&page=2)
The intent is yes, I have tested the new code, but I also wrote it, so may have a blinkered view. ;) Report any bugs here.

Edit:
Oh yeah before I do something wrong, all the filters work with the v2.6 or should i keep the v2.58 in case ?
2.6 is intended to be a pure superset of 2.58, all 2.58 scripts should work identically under 2.6 (bug fixes excepted :D ) Of course under 2.6 you can do 2.6 things, e.g YV24, YV16, etc, that are not supported under 2.58.

Also I have a problem with mediacoder (not your concern i know). It seems it doesn't support avisynth 2.6 (it can't decode a simple script) What software do you recommend (with v2.6 support) so i can encode in x264, thank you
As long as your script outputs a 2.58 colour space, i.e. RGB24, RGB32, YUY2 or YV12, then is should work. The interfaces have not changed, they have only been extended.

VirtualDub supports YV24, YV16 and Y8 formats. Older versions have the chroma plane order reversed. Global OPT_VDubPlanarHack=True can be used to work around the problem.

[StainlessS]

[I][B]
Also i have a problem with mediacoder (not your concern i know) i'ts seems it don't support avisynth 2.6 (it can't decode a simple script)

Have just installed the update to Mediacoder:-
MediaCoder2011-update-5158.exe and just did a short test
render via Avisynth 2.6 Alpha 3, with no real problem. I dont
like feeding AVS directly into Mediacoder (lately), as it seems
to always detect the AVS as Interlaced and you get a log entry
saying something like:

"x264 [Warning]: interlace + weightp is not implemented"

in the console (press F6). If the AVS does nothing other
than AVISource(), you still have an interlaced detection, but
if you feed the same clip in directly, it correctly finds it to
be progressive.

If you have recently installed an update, perhaps you did as I
did and canceled an x264 download, if so then you may find
that there is no x264.exe in your codecs directory as MC
directly overwrites the file, you would get an error 14 and
a redirect to the damn website to see what that means.

MC has had a LOT of problems of late, always a good idea to
have a known working version, all MC versions for about a
year (I think) are not considered stable. Try the Last stable
release.

[Mounir]

The intent is yes, I have tested the new code, but I also wrote it, so may have a blinkered view. ;) Report any bugs here.

So the convertions are internal no need of the script now if i understand you correctly we're back to regular converttoyv12() etc...Please confirm

[IanB]

@Mounir,

Why don't you test it and then let everybody know the results. As I said the intent is yes!

[Mounir]

Have just installed the update to Mediacoder:-
MediaCoder2011-update-5158.exe and just did a short test
render via Avisynth 2.6 Alpha 3, with no real problem. I dont
like feeding AVS directly into Mediacoder (lately), as it seems
to always detect the AVS as Interlaced and you get a log entry
saying something like:

"x264 [Warning]: interlace + weightp is not implemented"

in the console (press F6). If the AVS does nothing other
than AVISource(), you still have an interlaced detection, but
if you feed the same clip in directly, it correctly finds it to
be progressive.


I have no such problem i'd say it's the opposite i'm struggling to make an interlaced encode because mediacoder always want a progressive source.

Anyways, i've updated avisynth and mediacoder, it seems to be working ok for now

[upyzl]

Many thanks!!

I'm very glad to see there's update for this!!!

[leeperry]

Is there any way to get >8bit video processing in Avisynth 2.6?

Why are plugins coders forced to use kludges to get 16bit out of 2.6? :(

[Wilbert]

Is there any way to get >8bit video processing in Avisynth 2.6?

Why are plugins coders forced to use kludges to get 16bit out of 2.6?
You are acting like your nick. In case you didn't notice it there is only one main developer doing all the hard work. Limited 16 bit video processing is reserved for one of the future versions of AviSynth. If we add it now there will be never a stable 2.60 version.

[leeperry]

16 bit video processing is reserved for one of the future versions of AviSynth.
Well, it'd be like audio software working in 16int internally(instead of 32/64fp)....but ok, good to know that 16bit support is on the TODO list indeed :)

I wasn't being sarcastic, or anything like that....merely asking a simple question :o

[poisondeathray]

.tif images seem to be flipped vertical with ImageSource() or ImageReader() in 2.6 alpha 3

-Doesn't occur with 2.6 alpha 2, or 2.58, or 2.57

-occurs in avspmod preview and vdub preview (so less likely an avsp bug)

-other image formats like .jpg, .png are decoded ok , but when converted to .tif they are flipped

-doesn't matter if it's ".tiff" or ".tif" , both are flipped

-seems independent of odd/even resolution (e.g. 427px width image vs. 428px width image)


or is it just me ? I can upload some sample images, but it's pretty easy to replicate this behaviour on random images

[Wilbert]

-other image formats like .jpg, .png are decoded ok , but when converted to .tif they are flipped
..
or is it just me ?
No, i can replicate that. We changed this when adding support for DevIL 1.7.8. It seems that with the included library (devil.dll 1.6.6) it is flipped, and with the latest library (devil.dll 1.7.8) it's not flipped. That's annoying.

@IanB, the following should correct it

/* old:
if ( !lstrcmpi(ext, "jpeg") || !lstrcmpi(ext, "jpg") || !lstrcmpi(ext, "jpe") || !lstrcmpi(ext, "dds") ||
!lstrcmpi(ext, "pal") || !lstrcmpi(ext, "psd") || !lstrcmpi(ext, "pcx") || !lstrcmpi(ext, "png") ||
!lstrcmpi(ext, "pbm") || !lstrcmpi(ext, "pgm") || !lstrcmpi(ext, "ppm") || !lstrcmpi(ext, "tif") ||
!lstrcmpi(ext, "tiff") || !lstrcmpi(ext, "gif") || !lstrcmpi(ext, "exr") || !lstrcmpi(ext, "jp2") ||
!lstrcmpi(ext, "hdr") )
{
should_flip = true;
}
*/

if ( !lstrcmpi(ext, "jpeg") || !lstrcmpi(ext, "jpg") || !lstrcmpi(ext, "jpe") || !lstrcmpi(ext, "dds") ||
!lstrcmpi(ext, "pal") || !lstrcmpi(ext, "psd") || !lstrcmpi(ext, "pcx") || !lstrcmpi(ext, "png") ||
!lstrcmpi(ext, "pbm") || !lstrcmpi(ext, "pgm") || !lstrcmpi(ext, "ppm") || !lstrcmpi(ext, "gif") ||
!lstrcmpi(ext, "exr") || !lstrcmpi(ext, "jp2") || !lstrcmpi(ext, "hdr") )
{
should_flip = true;
}

if ((DevIL_Version > 166) && (!lstrcmpi(ext, "tif") || !lstrcmpi(ext, "tiff")))
{
should_flip = true;
}


When calling ImageSourceAnim there should be a version check too.