AviSynth 2.5.7 RC-1 [Sept 16th]

[Fizick]

Kostarum Rex Persia,
No, wait version 2.6 or later for this feature.
v2.5.7 is mostly bugfix release

[IanB]

This will be better?
ref = child->GetFrame(n + offset, env);
...That will stand a chance of working. The other is just plain wrong!

PVideoFrame ref is a smart pointer. As long as ref is in scope you have an ownership stake in the associated VFB. When it goes out of scope or is reassigned your use is automatically released and any pointers you might have cannot be trusted anymore.

As I suggested many months ago it is safest to get all of your PVideoFrame's at the top of the code. This is a defensive coding technique that avoids confusion and complicated bugs like we have here.


This code is highly illegalpRef = child->GetFrame(n, env)->GetReadPtr(PLANAR_Y);The contents of the pointer pRef are invalid immediatly. The intermediate PVideoFrame goes out of scope immediatly. The returned pointer is pointing into a VFB that you do not have an ownership stake. The VFB is as such free and can be reused at any time. In the single tasking case the code may limp along and pretend to work, in the multitasking case ......


but your's cache algo is bugged anywayIt may well have bugs but this is not one of them. The MV code is not using the Avisynth API correctly. The cache is only there to try to prevent re-rendering of frame already rendered. It is not there to fix broken code. You are trying to fix a VFB ownership problem by using a side effect of CACHE_RANGE to trick the cache into keeping the VFB in use for you. In future versions this side effect may not exist.

I suggest you use CACHE_NOTHING while you work out all these MV bugs. Also the bugged version of AddGrain() that returned different grain each time you called it might help as useful diagnostic.

[Fizick]

thanks,
i tried use in MVAnalyse
ref = child->GetFrame(n + offset, env);
...
it does not cure the bug.

It seems, that bugged code is at mvClipArray->Update(n)

[IanB]

And many many more places :(
You gotta lot of fix'en to do.
If I can find time I will try to read thru the code.

[Fizick]

IanB, thanks for advise.
I really found many places,
but the main is:


void MVClip::Update(int n, IScriptEnvironment *env)
{
FakeGroupOfPlanes::Update(reinterpret_cast<const int*>(child->GetFrame(n, env)->GetReadPtr()));
}
...
mvClip.Update(n, env)


It is code for updating vector clip's data. I replace it by new code:


void MVClip::Update(PVideoFrame &fn, IScriptEnvironment *env)
{
FakeGroupOfPlanes::Update(reinterpret_cast<const int*>(fn->GetReadPtr()));
}
...
PVideoFrame mvn = mvClip.GetFrame(n, env); // store PVideoFrame
mvClip.Update(mvn, env);


But IMHO it may be considered not as MVTools bug, but as Avisynth bug (not cache, sorry, but smart pointers),
at least until you documented this info in http://www.avisynth.org/FilterSDK :)

So, if you find time, please write some small article to Avisynth SDK about VFB processing and cache. You may use code of any of my numerous bugged plugins as example "how to not to do" :)
But please provide "how to do" fragments too.
I recall http://forum.doom9.org/showthread.php?t=100715

To be on topic:
May be we must add SDK doc to AviSynth offline doc?

[smok3]

about offline (javascript) search engines..., well i think the easiest solution is to provide the docs as single html file as well, so anybody can use ctrl+F.

[tritical]

temporalsoften is missing a:

delete[] planeDisabled;

in its destructor resulting in a very, very small memory leak.

[Wilbert]

@IanB,

We talked about this before, but people still have the grey frames problem in DSS:

http://forum.doom9.org/showthread.php?t=116924

I remember from our conversation that it is not an AviSynth problem, but it is a problem nonetheless. I hope there will be some "fix" before v2.57 final it out.

[IanB]

Yes, I was going to change the default behaviour to "crash and burn" mode instead of doing grey frames mode. (But I am not sure people will be very happy with runtime exceptions being thrown and killing there encodes)

Perhaps somebody has some better ideas on how to resolve the issue. (and displaying the last good frame does not work at the start of the stream)

[Guest]

displaying the last good frame does not work at the start of the stream Then display the first good frame (that's what DGMPGDec does).

What exactly is the problem? Is there a thread with an analysis?

[IanB]

Nice thought, if only I could get a first good frame.

The problems is DirectShow doesn't deliver a frame, it just hangs. I added code to implement Timeouts instead of hanging forever, but I now have the problem of what to do with the failure. Currently the options are a "Grey Frame" or a runtime Exception, neither of which I am really happy with.

Most of the problems appear to be deadlocks in some non-descript spliter. AVS is probably more a victim of this because it builds 2 separate graphs, one for audio only and one for video only rather than a single graph that renders both audio and video and plays them synchronously. (Remember AVS GetFrame() and GetAudio() are independantly asynchronous)

[Ebobtron]

IanB
Although almost pathetically minor, when AviSynth is presented with a thoroughly useless script(no audio, no video, *no errors*), AviSynth spills the following message to video out.

“” The script’s return value was not a video clip “”
script example: (yes, just a single digit)
1

In light of today’s and future audio only capability, should this maybe read

“The script’s return value was not a clip” or whatever might be more accurate.

*no errors* above refers to the following not throwing an error when such a simple script which contains no syntax errors is used.

try
{
res = env->Invoke("Import", AVSValue(&scpt,1));
}
catch(AvisynthError err)

res.IsClip() does return false, so error detection is fine, just the wording to me seems wrong with the current version.

:thanks:

[IanB]

@Ebobtron,

Yes "video" clip is a tad redundant, like "PIN" Number, I think we can accomodate.

[Ebobtron]

It is me again,

While updating the user docs for FilmCutter (http://forum.doom9.org/showthread.php?t=97438) I noticed that the english versions of

getchannel.htm
and
directshowsource.htm

both contain the word "ordening".
I suppose in the place of "ordering" or is "ordening" suppose to be related to "ordinal".

From what I can tell ordening isn't a word, but what do I know.


Thanks again.

[foxyshadis]

Would a dev mind taking a look at this video (STR2311_cut.avi)? Avisynth consistently crashes (occasionally just a system exception) with LZOCodec-encoded videos. It decodes fine in vdub, and works fine if re-encoded to ffv1 or anything else before loading it into avisynth. You'll need LZOCodec (http://usuarios.lycos.es/lzocodec/) first. [Mirror (http://www.free-codecs.com/download/LZOcodec.htm)]

I just remembered that it internally uses YUY2 for everything, and setting pixel_type="YUY2" fixes it. I'll report the crash to the LZOCodec author, it must be crasing while convering to YV12.

[Fizick]

Ebobtron,
I will change it to "ordering"

[Fizick]

I want to ask about this (rathe old) change of v2.5.7:
* Bracketless call of argless function now get a cache. (Tritical)

what is agrless, and why agrless only get a cache?

[Wilbert]

what is agrless
"without arguments". A function call without arguments and without brackets. Remember the old discussion about filter and filter() where the internal cash of the former was disabled resulting (sometimes) in a speed loss?

link: http://forum.doom9.org/showthread.php?t=100166

[Fizick]

I remember this discussion, but I supposed, that now in v2.5.7 any filter call without brackets get a cache. But it is seems, that it is not a true for v2.5.7? So, only very small amount of filters like Weave (argless) will get a cache? And any other internal or external filter (which has some parameters) will not get a cache, when it is called without brackets (with default parameters assumed)?

[IanB]

No!, FIlter() and Filter(a, b, c) alway had and still do get a cache.

Filter previously did not get a cache. Now in 2.5.7 it gets one the same as the other cases (or so Tritical assures me :D )

[pandy]

Bug in ImageSource() function.

0-255 level conversion to 16-235 (16-240 for chroma) is always enabled...

[dbloom]

Back to the "Search" idea for the documentation...

Searching could be implemented by making a simple Javascript spider that uses XMLHTTPReq. Basically, when you do a search, it starts loading pages (the table of contents, then all pages linked to from the table of contents...) and presents a list of results that are the pages in which the keywords appear.

This should run pretty fast because all of the files are stored locally.

[Fizick]

IanB, thanks,
so more correct is:
* Bracketless call of argless function now get a cache too. (Tritical)
:)

dbloom,
I do not see any reason for special 'Avisynth-specific' search.
You say about common method.

[Wilbert]

Bug in ImageSource() function.

0-255 level conversion to 16-235 (16-240 for chroma) is always enabled...
I'm pretty sure this is not the case. Could you post a sample pic?

@Fizick,
IanB, thanks,
so more correct is:
* Bracketless call of argless function now get a cache too. (Tritical)
Yes.

[tritical]

Another minor bug, line 477 in avisynth_c.cpp should be changed from:

p->env->AtExit(shutdown_func_bridge, d);

to

p->env->AtExit(shutdown_func_bridge, dd);

Now in 2.5.7 it gets one the same as the other cases (or so Tritical assures me )
Not sure about assurances :D, but I do remember testing it at least (hopefully).

[foxyshadis]

Bug in ImageSource() function.

0-255 level conversion to 16-235 (16-240 for chroma) is always enabled...

ImageSource only imports in RGB, so I'm not sure how level conversion is even an issue. Unless you mean the JPEG decoder; JPEG is specified to be 0-255 YUV->0-255 RGB, and cannot use the normal "TV" mode. However, I've never seen avisynth incorrectly decode jpeg.

[IanB]

@Tritical, done, Thx!

@Pandy, ImageSource uses the DevIL image library and as foxyshadis points out we only ever decode to RGB. If the library incorrectly decodes an image to RGB[16..235] then please report it to the IL group.

As a work around do the followingImageSource("blah.jpg", pixel_type="RGB32")
Levels(16, 1.0, 235, 0, 255)

@Fizick, too, also, as well ;)

@dbloom, possible, please post some working samples.

[dbloom]

@dbloom, possible, please post some working samples.

working on it :)

[Fizick]

Here is some test result for avisynth v2.5.6a:

avisource("yuy2.avi")
limiter()
fluxsmootht()
I got fps=29


avisource("yuy2.avi")
limiter
fluxsmootht()
I got fps=24.

avisource("yuy2.avi")
degrainmedian()
degrainmedian()
I got fps =18


avisource("yuy2.avi")
degrainmedian
degrainmedian()
I got fps =10

With v2.5.7 result are fine (without slowdown).
But limiter and degrainmedian are not 'argless'.
So, more correct is:

* Bracketless call of function now get a cache

[pandy]

I'm pretty sure this is not the case. Could you post a sample pic?


This is source which i try to encode (ordinary RGB colorbar 0,255)
And this is simple script which i use for this...

ImageSource("0_255.png", end = 1499, fps = 25.0)
PointResize (720,576)
ConvertToYUY2(interlaced=False)
ColorYUV (analyze=true)

[foxyshadis]

You need ConvertToYUY2(matrix="PC.601") or "PC.709" in order to convert to YUV 0-255 levels. The default is "Rec601", that's where the range reduction is coming from.

[sh0dan]

I backported some changes to the 2.6 TCPDeliver (larger TCP buffers), and my own tests show a great improvement over the last version.

http://klauspost.googlepages.com/TCPDeliver_25_14oct2006.zip

You should be able to hit about 90% usage on the server, and 100% on the client, given optimal load distribution, but most likely, you'll just hit one of these in the real world.

Changes are in CVS, but not included in RC 1.

[pandy]

You need ConvertToYUY2(matrix="PC.601") or "PC.709" in order to convert to YUV 0-255 levels. The default is "Rec601", that's where the range reduction is coming from.

??????

Ok, i see... sorry, i forget about this - im not using ConvertToYUY2 in such way... I prefer rather ColorYUV (levels="PC->TV") method.
Sorry for mess!
Thank You foxyshadis!

[Isochroma]

Will the new TCPDeliver.dll work with 2.5.6a?

[sh0dan]

@Isochroma: Shouldn't be a problem. It should work with all 2.5 versions.

[DDogg]

I backported some changes to the 2.6 TCPDeliver (larger TCP buffers), and my own tests show a great improvement over the last version.

http://klauspost.googlepages.com/TCPDeliver_25_14oct2006.zip

You should be able to hit about 90% usage on the server, and 100% on the client, given optimal load distribution, but most likely, you'll just hit one of these in the real world.

Yes, and Yes. 90-100. Great job! I hope we can start a thread, finally, to concentrate the information on TCPDeliver into one easy to find reference. Maybe even some real docs might come out of it :)

[Wilbert]

Regarding AviSource and multichannel AC3/DTS. It doesn't work for me. I installed the AC3/DTS ACM codec: vac3acm (http://sourceforge.net/project/showfiles.php?group_id=66022). (There is also the AC3 ACM codec from fccHandler (http://fcchandler.home.comcast.net/AC3ACM/index.html), but i didn't try that one yet.)
If i open an Avi with AC3 or DTS in VirtualDub (1.7.0) it shows up as having 5 channels (i guess that's a bug of Avery's part, but i will contact him about it ...). It indeed uses vac3acm to decode the audio of the clip. But if i open them in AviSynth (latest v2.57):

AviSource(...)
Info()

info returns two channels for the audio stream.

[niiyan]

I made a Japanese translation team two month ago.
We are trying to translate AviSynth docs to Japanese.
But it will take a lot of time to complete translation.
So, we decided to release the pages we already finished translating.

You can download the Japanese version of AviSynth docs from here:
http://translation.avisynth.info/index_en.html

Now it includes only 9 pages.
But we will continue to tranalate, add new pages and release it once a month.

I have a few questions.

1. Is it possible to add Japanese translation to AviSynth installer after we complete translation?
2. Should we release this temporal Japanese translations under GPL? I mean, should we include gpl.txt?

[Fizick]

niiyan,
thanks for contribution.
Yes, it will take a lot of time. But team work can speed-up (i know it).
Answers:
1. Yes, it is possible of course. Usually all "official" translations are placed to CVS at sourceforge.net by one of translator (coordinator of translation). He (you ?) must become Avisynth project member. Firstly register at sourceforge. Then ask project admin (Wilbert or Ian or Richard) to become project member (as document writer). Then you will be able to commit (and update) your files to CVS reposirary with special software (TortoiseCVS). You may put files one by one right now (tomorrow :)).
We will update installer to include these files when basic part will be translated.

2. The license terms of Avisynth documentation is interesting question. I am sure that it is GPL compatible at least:).

Do you want distribute the translation separately?
May be you can add some readme file and write that
"This translation is a draft version of a part of official Avisynth documentation. Avisynth is Copyright (C)..... under GPL..."
and include GPL.txt, yes.
You may add some translation history, authors, dictionary to this file (see "aboutrussian.htm").

[jmac698]

I found a bug in 2.56, maybe it can be addressed in new version. When resizing downwards, interlacing is not taken into account. If I reduce an interlaced video, there is ghosting in both fields now.
A practical use is restored upconverted material; where each field was resized.
I would ask for bool interlaced option in resizers.

[Mug Funky]

that's not exactly a bug, but a bool "interlaced" could be useful. preferred method for resizing interlaced is motion-adaptive bob and then resize though - no matter how an interlaced resize is done, it's working on half the information it needs, and you'll get slightly crunchy diagonals even if the per-field misalignment is taken care of.

[jmac698]

I know it will still be interlaced; if my intent is to resize without deinterlacing, then resizing fields is the only option.
If something was pointresize upconverted, then I am only recreating the original version. In real life there is a 4 tap hardware filter; but I can undo this fairly well.
Regardless of the most pleasing results, in no case should a possibly interlaced video be simply weaved and resized.

[Fizick]

generally, resizing is for progressive only,
so we can add "interlaced" flag, but it must produce the exception "Avisynth XXXResise: sorry, only progresive source supported!" :)

[IanB]

I would ask for bool interlaced option in resizers.Adding options like this only encourages people to use it. As M.F. points out it is a truely dreadfull way to resize interlaced material. The primative needed to implement this (mis)feature are available in the scripting language already.

[jmac698]

Then cause an error, document the issue in the manual. IMHO, I don't support a built-in filter doing something knowably horrible.

This was a reallife problem; mrestore doesn't work with some bobbers, it's a known issue. Only a simple bob() will work. For speed I had to resize first; that's when I noticed I can't resize interlaced properly. There is no workaround presently.
http://forum.doom9.org/showthread.php?p=903815#post903815

[foxyshadis]

Have you seen the simpleresize plugin? It comes with the very option you ask for, and already does the work to realign the fields properly.

[niiyan]

@Fizick

niiyan,
1. Yes, it is possible of course. Usually all "official" translations are placed to CVS at sourceforge.net by one of translator (coordinator of translation). He (you ?) must become Avisynth project member. Firstly register at sourceforge. Then ask project admin (Wilbert or Ian or Richard) to become project member (as document writer). Then you will be able to commit (and update) your files to CVS reposirary with special software (TortoiseCVS). You may put files one by one right now (tomorrow :)).
We will update installer to include these files when basic part will be translated.

I understand the process to commit translation files. But we've just started translation, so I will ask project admin again after finishing translation of basic part.

2. The license terms of Avisynth documentation is interesting question. I am sure that it is GPL compatible at least:).

Do you want distribute the translation separately?

Yes. I would like to distribute the Japanese translation separately and temporally until it is added to AviSynth installer.

We will discuss about the license later and decide whether we release the Japanese translation under GPL at least by next month.

[IanB]

filter doing something knowably horrible.No filter knows that an image is interlaced (or anything else for that matter), some very clever filters try to measure interlace'ness, all have problems getting it right. You the human are responsible for makeing valid choices in your scripts. I can't protect you from yourself. G.I.G.O. From the other thread your real problem is trashed video messes up your deinterlacing/bobing procedure. Learn to use SeparateFields, Weave and the subpixel cropping functionality of the resizers.

[Wilbert]

We will discuss about the license later and decide whether we release the Japanese translation under GPL at least by next month.
As i understand it GPL is only possible for code, and not for documentation. IF we want to license the documentation, we can use 'GNU Free Documentation License' or whatever. Of course we need the required permission from everyone involved when we should to do this.

[Fizick]

Wilbert,
GNU GPL is possible for documentation.
IMO the only expicitly declared avisynth license (by Ben and later) is GNU GPL or at least some compatible (like public domain) for some parts.
The switching to GNU FGL is hard for reason you say (and it is complex).
I want discuss with you a little later :)