AviSynth 2.5.5 CVS Releases. [August 26th]

[sh0dan]

Hi!

I created this thread, for general discussion of the CVS binaries that are being released. Here would be a good place to post if you have new problems with CVS releases that you don't experience with the official releases.

I will also post here every time a new binary is released. So here goes:

August 26th Release Candidate 3 - all changes from 2.5.4:

- Reenabled optimizations. RC2 broke plugins.
- Fixed duplicated line in resize+crop operations (beta regression)
- Fixed "Unknown exception" in conditional filter expressions. (August 17th regression)
- Updated docs.
- Added: ImageReader/ImageSource now accepts relative paths in all configurations.
- Fixed: ImageReader now no longer reports errors/info upside-down.
- Added: DirectShowSource now requests interlaced material to avoid internal (crappy) WMV9 deinterlacer. (Thanks to Russel Lang)
- Fix: Huge stability fix by IanB. This should remove a bunch of "Evaluate: Unregnized exception", and crashes on reload in vdub.
- TDPDeliver: Simplification and cleanup. Planar pitches handled more consistently.
- Fix: DirectShowSource properly relasing filters on unload.
- Added: BlankClip now has color_yuv, that allows setting and YUV color for YUV clips.
- Added a huge list of color presets (http://www.avisynth.org/ColorPresets), that can be used instead of colors.
- Fixed problems causing random crashes and excessive memory problems in July 13th binary.
- Fixed errors in NON-MMX ColorKeyMask.
- Fixed Loop() when called with no video (stickboy)
- Added AssumeFPS(clip [, sync_audio=true/false]) (stickboy again).
- AssumeFPS: Added sanity check to ensure that denominator isn't zero.
- Fixed error not being thrown in Conditionalfilter on an invalid operator.
- Added first version of compression for TCPdeliver. LZO, Huffman and GZIP Huffman algorithms added. Docs here (http://www.avisynth.org/TCPDeliver).
- Fixed MergaLuma not giving correct results in some cases.
- Fixed DirectShowSource not releasing Graph/Files on unload/reload.
- Added TCPDeliver. (TCPServer/TCPSource) More info here (http://forum.doom9.org/showthread.php?s=&postid=460200#post460200) .
- Centre PointResize image.
- Fix VideoFrameBuffer cache corruption.
- Added FrameRate Numerator & Denominator script functions.
- General Convolution updates:
* fix matrix string env corruption
* roll divisor into iCountDiv logic - fix overflow problem
* make divisor a float
* add auto option to control autoscaling/normalizing feature
* support legacy syntax
* tidy indentation
- Fixed bug in PointResize.
- Turn: Fix concurrent use of RGB/YUY2 turnleft/right in same script.
- TurnLeft: Fix 1 pixel offset down in yuy2.
- Added: Turn180() function.
- Loop should now support all kinds of audio.
- Fixed wrong weights in interlaced YUY2 -> YV12 conversion.
- Added MMX optimizations to Overlay mode lighten+darken with opacity=1.0, with no mask.
- Removed overflow bug in ssrc upsampler.
- Fixed Audio cache crash if no audio.
- Cleaned up ApplyYV12 in textoverlay.
- Fixed float audio in Dissolve.
- Fixed audiobits clip properties now returning bits and not bytes.
- Added IsAudioFloat() and IsAudioInt() as clip properties.
- Added experimental "after_frame=true/false" to ScriptClip.
- Added FOURCC parameter to AviSource by stickboy.
- ImageReader: tweaked default parameters.
- ImageReader: made ColorBars parameters optional (like docs claim!)
- ImageReader: No more "Image not in range". First frame is ALWAYS frame 0.
- SSRC now has aligned data (slightly faster and SSE ready).
- Fixed ConditionalReader inaccuracies on integer interpolation.
- Updated SoftWire codegenerator to latest version.
- Fixed Mask() problem with footage with different pitches.
- Added Lanczos4Resize().
- Added french documentation.
- Added SSE float to int audioconversion.
- Added 3DNOW! optimizations to sample-type conversions int to float, and float to int. Much faster.
- Added float audio and multiple channels support to Dissolve.
- Subtract now clamps errors instead of overflowing.
- Added faster MMX to Invert by ARDA.
- Added WriteFile, WriteFileIf, WriteFileStart, WriteFileEnd. (WarpE)
- ImageReader: Static image support.
- ImageReader: Floating-point FPS.
- ImageReader: Aliased to ImageSource.
- ImageReader: Frames automatically flipped when necessary.
- ImageWriter: Optional "info" parameter to show filename.
- ImageReder/Imagewriter: All errors returned as text clips.
- AviSynth will no longer resize to non-mod4 widths in YV12 mode!
- Added MMX/ISSE chroma convertion to Overlay with YV12 input.
- Added MMX function for Overlay(mode="blend"), when a mask is used and opacity = 1.0.
- Dissolve can now handle audio input with different sample types.
- Dissolve now checks if samplerates are the same.
- Trim/Dissolve: Better error reporting.
- Added specific (and simpler) stereo mode to TimeStretch - no more drifting.
- Made ISSE YUY2 HorizontalReduceBy2() more "safe".
- Fixed missing plane in temporalsoften.
- Corrected some quirks in temporalsoften scenechange on artificial sources.
- Fixed IsParityKnown() in avisynth.h - thanks to stickboy.
- Random in scalemode is not returning limit value - thanks you stickboy!
- Added dll-name prefix to plugins as per {http://forum.doom9.org/showthread.php?s=&threadid=72235}.
- - Syntax is DLLNAME_function(), where DLLNAME is the filename of the dll containing the function.
- Updated DevIL libs; removed unneeded DevIL components; improved error reporting in ImageReader/ImageWriter.
- Added automatic audio cache.
- Added RGB24, YUY2 and YV12 MMX Invert() function.
- Fixed: Trim audio could crash, if sample types were different.
- Fixed crash-on-exit in SSRC, if rateconversion was skipped.
- Fixed one frame missing in temporalsoften.
- Fixed chroma moving half a pel in Overlay() with YV12-input mode.
- Updated Overlay(mode="multiply") to work more logical. Old functionality is no more!
- Added dotted lines at zero levels to view bias in Histogram(mode="stereo").
- Added CPU stuff to Info().
- Added generalconvolution divisor.
- Added audio cache after EnsureVBRMp3Sync.
- Fixed frame 0 bug in PlaneDifference
- Fixed Dissolve MMX was not accurate on very small overlaps.
- Dissolve: Dissolve throws an error if handed a negative overlap.
- Added TimeStretch (http://www.avisynth.org/index.php?page=TimeStretch). This filter can change speed of the sound without changing the pitch, and change the pitch of a sound without changing the length of a sound.
- Disabled avisynth_c plugin autoloading (no longer a compatible way to do so).
- DirectShowSource is now a plugin, and is automatically placed in the plugin directory by the installer.
- Fixed minor glitches in audio cache (out of range requests)

[Chainmax]

Originally posted by sh0dan:
Disabled avisynth_c plugin autoloading
Does that mean that plugins can't be autoloaded in this version?

[Wilbert]

Shodan refers to C-plugins (written in C instead of C++). You know, plugins of Kevin, Fizick and others.

[sh0dan]

... exactly! The plugins usually state they require the "avisynth_c" plugin to load.

[Si]

Just interested to know why you've made DirectShowSource a plugin :confused:

regards
Simon

[K-Dash]

Cool thx :D

[sh0dan]

Originally posted by siwalters
Just interested to know why you've made DirectShowSource a plugin :confused:

regards
Simon
To make AviSynth easier to compile. The DirectX SDK is no longer needed, and the platform SDK should be needed either.

[Chainmax]

Originally posted by Wilbert:
Shodan refers to C-plugins (written in C instead of C++). You know, plugins of Kevin, Fizick and others.
Originally posted by sh0dan:
... exactly! The plugins usually state they require the "avisynth_c" plugin to load.
Ok, I get it now. Thx for the explanation :).

[niiyan]

When I installed AviSynth_300104.exe, something strange happened.

By default, Install Location was ...

C:\Program Files\Avisynth2

So I tried to change the folder to ...

C:\Program Files\Avisynth 2.5

I clicked [Browse] button and selected "Avisynth 2.5" folder.
And then, back to installer, Destination Folder became ...

C:\Program Files\Avisynth 2.5\Avisynth 2.5

P.S. On other PC (AviSynth2 folder didn't exist), Destination Folder was "C:\Program Files\Avisynth 2.5" by default.
---
niiyan

[Bogalvator]

Timestretch is an excellent addition, I'm sure many people will find this useful.

Quick query:
Adjusting "Rate" is equivalent to using AssumeSampleRate and ResampleAudio, but at very high quality.

How do you mean "very high quality"? Higher than using AssumeSampleRate and SSRC?

By the way, is 'AssumeSampleRate' lossless in the same way that AssumeFPS() is? I.e. does AssumeSampleRate(50050).AssumeSampleRate(48000) return the exact wav file as the source?

[sh0dan]

If you can use SSRC, use it, but prefer TimeStretch over ResampleAudio.

You might also be able to reach higher precision, as rate is a float parameter, and not bound by interger round-offs like AssumeSampleRate and SSRC/Resampleaudio.

Otherwise you could do some ABX tests, and tell us, what you found to be the best, so we can update the docs.

And yes - AssumeSampleRate doesn't touch your samples - only the playback rate.

[sh0dan]

New alpha March 3rd - actually I got quite surprised, when I saw the length of the changelist:
- Updated DevIL libs; removed unneeded DevIL components; improved error reporting in ImageReader/ImageWriter.
- Added automatic audio cache.
- Added RGB24, YUY2 and YV12 MMX Invert() function.
- Fixed: Trim audio could crash, if sample types were different.
- Fixed crash-on-exit in SSRC, if rateconversion was skipped.
- Fixed one frame missing in temporalsoften.
- Fixed chroma moving half a pel in Layer() with YV12-input mode in Overlay.
- Updated Layer(mode="multiply") to work more logical. Old functionality is no more!
- Added dotted lines at zero levels to view bias in Histogram(mode="stereo").
- Added CPU stuff to Info().
- Added generalconvolution divisor.
- Added audio cache after EnsureVBRMp3Sync.
- Fixed frame 0 bug in PlaneDifference
- Fixed Dissolve MMX was not accurate on very small overlaps.
- Dissolve: Dissolve throws an error if handed a negative overlap.

[stickboy]

That off-by-one problem with Dissolve (http://forum.doom9.org/showthread.php?s=&threadid=70096) should be fixed too, right?

[sh0dan]

Yes! (Wow - changelist is getting even longer :) )

[Didée]

originally posted by Didée

/* walks away in a blissful mood, one arm wrapped around the new MaskTools, the other around the freshly bugfixed AviSynth */
;)

Thank you, sh0dan.

- Didée

[Richard Berg]

Speaking of Dissolve, I almost forgot -- need to try to find the access violation that Dissolve creates when fed by the ISSE version of HorizontalReduceBy2.

Also, if we're to point out bugs in the buglist (;)), "Fixed chroma moving half a pel in Layer() with YV12-input mode" should refer to Overlay(), I think.

[sh0dan]

@Richard: I could not reproduce the problem, but I tried eliminating a few "risky" operations in HorizontalReduceby2. I comitted the code - could you test?

[Wilbert]

Shodan, could you include the chm-files with the next CVS release (instead of the html docs)? They can be found here:

http://cvs.sourceforge.net/viewcvs.py/avisynth2/avisynth/distrib/docs/

Then we can find out if people prefer the html docs or the chm-files or both.

edit: perhaps it is a good idea to make this thread sticky?

[sh0dan]

@Wilbert: Stuck thread (and unstuck some old/dead ones)

I will replace the docs in the installer. This will probably make the installer a bit smaller.

Edit: I just looked at it - and to be honest, I don't find it nearly as good as the plain html version. The thread interface on the left is a major annoyance - it eats up too much space - it has to be unfolded on each startup. Futhermore I find it nice to have access to the documentation in my favorite browser.

I don't mind changing the installer, but are there any advantages, beside having documentation as a single file?

[Wilbert]

Edit: I just looked at it - and to be honest, I don't find it nearly as good as the plain html version.
That's a pity ...

The thread interface on the left is a major annoyance - it eats up too much space
That's true, but it is only a little bit more as it was previously (as in index.htm). You can make it smaller though. Maybe it is also possible to do that before compiling the chm file.

it has to be unfolded on each startup.
True.

Futhermore I find it nice to have access to the documentation in my favorite browser.
Ok, that's not possible in this case.

I don't mind changing the installer, but are there any advantages, beside having documentation as a single file?
You can search in all the documents at once. Besides that, I don't know.

Maybe you can include both (only for this cvs version), to find out what other people think about it? If people don't like it (or prefer the htmls), we can always upload the chm-files in a zip-file on sourceforge.

[Richard Berg]

@sh0dan - the HRB2 code in the CVS no longer generates a violation. For reference, my script:

colorbars(320,240)
converttoyuy2
trim(0,30)
horizontalreduceby2
fadeout(15)

[sh0dan]

New CVS binary up.

- AviSynth will no longer resize to non-mod4 widths in YV12 mode!
- Added MMX/ISSE chroma convertion to Overlay with YV12 input.
- Added MMX function for Overlay(mode="blend"), when a mask is used and opacity = 1.0.
- Dissolve can now handle audio input with different sample types.
- Dissolve now checks if samplerates are the same.
- Trim/Dissolve: Better error reporting.
- Added specific (and simpler) stereo mode to TimeStretch - no more drifting.
- Made ISSE YUY2 HorizontalReduceBy2() more "safe".
- Fixed missing plane in temporalsoften.
- Corrected some quirks in temporalsoften scenechange on artificial sources.
- Fixed IsParityKnown() in avisynth.h - thanks to stickboy.
- Random in scalemode is not returning limit value - thanks you stickboy!
- Added dll-name prefix to plugins as per {http://forum.doom9.org/showthread.php?s=&threadid=72235}.
- - Syntax is DLLNAME_function(), where DLLNAME is the filename of the dll containing the function.

[AmiRage]

Originally posted by sh0dan
AviSynth will longer resize to non-mod4 widths in YV12 mode!
There seems to be a simple "no" missing somewhere. ;)

But thanks anyway for this new CVS binary. :)

[Manao]

I tested dll-prefixes and resizing, both work well. However, when feeding non mod 4 resolutions to a resizer, the error message is the following : Unrecognise exceptionIt could imho be changed to Do not use non mod 4 resolution for resizingwhich is more comprehensible.

[sh0dan]

Strange - in debug mode it correctly throws a "Resize: YV12 width must be mutiple of 4." (including the spelling error ;)), but it bombs out with an access violation in Release mode.

[sh0dan]

March 20th:

- Added Lanczos4Resize().
- Added french documentation.
- Added SSE float to int audioconversion.
- Added 3DNOW! optimizations to sample-type conversions int to float, and float to int. Much faster.
- Added float audio and multiple channels support to Dissolve.
- Subtract now clamps errors instead of overflowing.
- Added faster MMX to Invert by ARDA.
- Added WriteFile, WriteFileIf, WriteFileStart, WriteFileEnd. (WarpE)
- ImageReader: Static image support.
- ImageReader: Floating-point FPS.
- ImageReader: Aliased to ImageSource.
- ImageReader: Frames automatically flipped when necessary.
- ImageWriter: Optional "info" parameter to show filename.
- ImageReder/Imagewriter: All errors returned as text clips.

[AmiRage]

Originally posted by sh0dan
- Added Lanczos4Resize().
Thanks again for a new version, but I've got a simple and maybe stupid question: What is Lanczos4Resize? :)

Edit: Just read somewhere that LanczosResize is Lanczos3?

Edit2: So Lanczos4 uses a different interpolation? Does it more sharpen/soften?

[sh0dan]

It's from this thread (http://forum.doom9.org/showthread.php?s=&threadid=72174). Lanczos3 is 3-tap, Lanczos4 is 4-tap. As noted in the thread the difference is very small.

Feel free to test and post your results!

[DDogg]

Added WriteFile, WriteFileIf, WriteFileStart, WriteFileEnd. (WarpE) Any reference threads on this? Search didn't turn up anything for me.

[stickboy]

Check the new documentation that's included with the binary. (BTW, I like the new look.)

TimeStretch docs are still missing though (though those are on avisynth.org). :(

[DDogg]

Yeah, Wow - examples and everything. Hats off to whomever did these new style docs. Really nice work! They look very professional.

[stickboy]

Originally posted by sh0dan
- Fixed missing plane in temporalsoften.
- Corrected some quirks in temporalsoften scenechange on artificial sources.Hmm... using the same TemporalSoften settings on a capture of traditional 2D animation, I'm encountering more ghosting now than I did before with 2.5.4. I suppose that's a necessary side-effect? Maybe the recommended settings in the docs should be adjusted?

[sh0dan]

@stickboy: You might want to decrease radius (first parameter) by one.

[Richard Berg]

@sh0dan -- I think there is an access violation in Antialiaser::ApplyYV12. Can you reproduce? E.g. when using the helper function like ApplyMessage(&frame, vi, "message", vi.width/4, 0xf0f0f0,0,0 , env)

[sh0dan]

@Richard: I haven't had any crashes directly linked to this funtion, but I'll walk through it anyway.

Edit: I looked through the function (and cleaned up the code), but couldn't find anything obviously wrong.

Which line?
Video size?

[Manao]

A small bug : In Compare(), to test whether both clip are in the same colorspace, the test made is ( vi.pixel_type != vi2.pixel_type ). It should be changed to !vi.IsSameColorspace(vi2) as you once advised me to do with YV12Subtract in the MaskTools.

[sh0dan]

Originally posted by Manao
A small bug : In Compare(), to test whether both clip are in the same colorspace, the test made is ( vi.pixel_type != vi2.pixel_type ). It should be changed to !vi.IsSameColorspace(vi2) as you once advised me to do with YV12Subtract in the MaskTools.
Thanks!

I updated error reporting in compare!

[Richard Berg]

The bug was a memory corruption from elsewhere in the code, fixed.

[Manao]

Another bug, found by kurtnoise : the following script raises an "unrecognized exception"source = MPEG2Source("R:\foo.d2v").converttorgb32()
return source.coloyyuv()Whereas, in the source code ( Avisynth 2.5.4 ), the first test made on the constructor of ColorYUV is : if (!vi.IsYUV())
env->ThrowError("ColorYUV: requires YUV input");
Any rgb colorspace raises the exception. Without the converttorgb(), it works fine.

[Mug Funky]

Subtract now clamps errors instead of overflowing.

w00t!

:)

and the fixed timestretch helps. haven't got a chance to test at the minute - recording audio :(

[hartford]

On short captures (50000 frames), Trim() works fine.

I did a capture 307070 frames in length. I get Trim()
errors when:


AVISource("e:\movie.avi").ConvertToYUY2.ConvertFPS(29.970)
Trim(11455,46215)+ \
Trim(51917,72984)+ \
Trim(80492,103373)+ \
Trim(109226,132161)+ \
Trim(139674,161373)+ \
Trim(166324,180310)+ \ # Incorrect first_frame
Trim(187806,209075)+ \ # Incorrect first_frame
Trim(214795,237133)+ \
Trim(244631,266036)+ \ # Incorrect first_frame
Trim(272786,290229)+ \ # Incorrect first_frame
Trim(296830,307044) # Incorrect first_frame



Each incorrect first_frame starts 24 frames before it should.
They all end at the correct frame.

If I remove the ".ConvertToYUY2.ConvertFPS(29.970)" the frame
count is correct.

Anyone else have this problem?
:confused:

[esby]

mmmm a stupid question before, harford

You are saying that you got Trim() errors
when using ConvertFPS(29.970)

so my <stupid> question is:
do you calculated the trim position with the convertFPS() or not...

If yes, it might be a bug indeed,
if not, it is not...
(convertFPS affects framerate,
and you might have some decals between the original clip and the convertFPS one)


esby

[stickboy]

Originally posted by hartford
On short captures (50000 frames), Trim() works fine.

I did a capture 307070 frames in length. I get Trim()
errors when:


AVISource("e:\movie.avi").ConvertToYUY2.ConvertFPS(29.970)
...
What's the original frame-rate and colorspace format?

It would be easier to reproduce if you gave an example like:
BlankClip(length=307070, fps=23.976, pixel_type="yv12")
ConvertToYUY2()
ConvertFPS(29.970)
ShowFrameNumber()
Trim(11455,46215)+ \
Trim(51917,72984)+ \
Trim(80492,103373)+ \
...

[hartford]

"do you calculated the trim position with the convertFPS() or not..."

No, I did not.


The original framerate is 29.968 fps Huffy


I did not realize that ConvertFPS() changed the frame count.

[esby]

You could probably use AssumeFPS() instead of convertFPS() here

esby

[hartford]

Thankyou, esby!

That works perfectly :D

[LigH]

The AviSynth 2.5.5 alpha 2004-03-20 is not available from SourceForge - almost 2 weeks later. What prevents it from being listed?

[sh0dan]

@Ligh: :confused: - Where is it not being listed?

[LigH]

Ah, damn it - looking at "200304", I read "2003-04" or "20..04".

A date format like "2004-03-20" would probably be

a) more percise, easier to read at the first glance
b) even well arranged for alphabetic sorting

Sorry for looking only in a hurry.

[Sigmatador]

the smallest bug:

Lanczos4Resize() doesn't appears green in vdm :D

[sh0dan]

@Sigmatador: All built-in functions are defined in vdubmod - so vdubmod needs an update.

[LigH]

In contrary - AviSynth needs an interface to be queried for supported functions! ;)

At least, plugin DLLs shall provide an interface to query which functions they provide, as asked for some time ago. I hope you developers will set that on schedule for 3.0, to make the creation of AviSynth editors easier.

[sh0dan]

@LigH: I'll have a look at what's possible. It might be possible to use a similar scheme as the plugins have, but I don't know if it's possible.

Either way VdubMod needs an update :D

[vion11]

It might be possible to use a similar
scheme as the plugins have,
but I don't know if it's possible. Can you explain this scheme in simple words, please?
Does it include parameter layout?

[sh0dan]

A variable called $PluginFunctions$ is created containing the function names of all plugins separated by spaces.

For each plugin a variable called FUNCTIONNAME!Param$ (replace FUNCTIONNAME with the name of any function) contains the parameters (as defined in each plugin) as a string.

(Actually this is done every time env->AddFunction is called, so every plugin might add several functions)

[Richard Berg]

I committed a small change to avisynth.cpp that should allow internal functions to be exported as well. The list of functions is stored in $InternalFunctions$ and the parameter definitions are kept as $Plugin!NAME!Param$ for consistency's sake.

The code compiles but I can't do a link until this rather long encoding job is finished :)

Edit: for the VDubMod authors reading this, ImageSource is also missing from the new list

[sh0dan]

Great job Richard!!

Regarding ImageReader/ImageSource. I would very much like to change it, so:

Frame 0 output = start.
Length of clip = end - start.

I can see no reason for including a bunch of frames that just say "Out-of-Range" before reaching frame "start".

I've made the changes - just wanted your objections before I comitted it . :)

[vion11]

Originally posted by Richard Berg
The list of functions is stored in $InternalFunctions$
and the parameter definitions are kept as $Plugin!NAME!Param$
for consistency's sake. Sounds very good! :)
How can one access this information?
Through the API? I'd prefer it....

[Richard Berg]

Stickboy and I discussed the ImageReader thing here (http://forum.doom9.org/showthread.php?s=&threadid=72477). "To me it's more intuitive to have it such that when VDub requests the 50th frame, you get file50.png."

Stickboy doesn't mind writing a wrapper function, and I'm coming to realize I'm the only one in the world who uses ImageReader as above, so whether you commit the update or not nobody will be offended :cool:

vion -- it uses the same quasi-"API" as the current plugin info. Should be a relatively minor tweak in VDM.

[vion11]

What a pity. :(
Have thought of a small step for you and
a big step for avisynth.

Is it worthwhile waiting for 2.6 or 3.0 ?

[Richard Berg]

I'm sorry, I don't know what you're talking about :confused: If you have a suggestion that's possible in 2.xx we may try it.

[vion11]

Simply want to ask Avisynth which functions are available
and what parameter at which position accept what data type.

What you have done for vdm more general for other editors.

[Richard Berg]

Any editor that can call IScriptEnvironment::GetVar() has access to this information.

[Richard Berg]

Thought I'd mention, before someone asks: it is not possible to return filter/plugin default values in the current framework

[sh0dan]

June 17th binary posted, changelist:


- Added MMX optimizations to Overlay mode lighten+darken with opacity=1.0, with no mask.
- Removed overflow bug in ssrc upsampler.
- Fixed Audio cache crash if no audio.
- Cleaned up ApplyYV12 in textoverlay.
- Fixed float audio in Dissolve.
- Fixed audiobits clip properties now returning bits and not bytes.
- Added IsAudioFloat() and IsAudioInt() as clip properties.
- Added experimental "after_frame=true/false" to ScriptClip.
- Added FOURCC parameter to AviSource by stickboy.
- ImageReader: tweaked default parameters.
- ImageReader: made ColorBars parameters optional (like docs claim!)
- ImageReader: No more "Image not in range". First frame is ALWAYS frame 0.
- SSRC now has aligned data (slightly faster and SSE ready).
- Fixed ConditionalReader inaccuracies on integer interpolation.
- Updated SoftWire codegenerator to latest version.
- Fixed Mask() problem with footage with different pitches.
- Added French documentation.


As you might have noticed, I haven't had much time for AviSynth the last months or two. I've just moved, and haven't got any 'net at my new place (yet). Add that up with a lot of work, and you pretty much get this result.

Also the CVS binary link page is soon to be changed - but since they are hosted at Sourceforge that will probably not be a big deal anyway.

Anyway - a new version for you to check - and as always feel free to post your feedback or problems.

[Wilbert]

Very nice!


As you might have noticed, I haven't had much time for AviSynth the last months or two. I've just moved, and haven't got any 'net at my new place (yet). Add that up with a lot of work, and you pretty much get this result.
I hope you moved to a nice place :)

Some questions:

1) I saw that also the french documentation is installed (when selecting it). How is that possible, because I don't see it in AviSynth_2.5.nsi?

2) Is TCPDeliver still not working properly?

[puschpull]

shodan: thank's, but why i use this new avisynth (17.6.2004) then VirtualDubMod hat problem !! (version 1.5.10.1 build 2439)
:-(


http://puschpull.org/doc/error.png

why i uninstal this new alfa version and return version from 20.3.2004, its all OK !
:-)

[sh0dan]

Originally posted by puschpull
shodan: thank's, but why i use this new avisynth (17.6.2004) then VirtualDubMod hat problem !! (version 1.5.10.1 build 2439)
:-(

Could you supply a bit more information:

1) Script you are opening.
2) Does it help to temporarily empty your plugin directory.
3) Smallest script to reproduce.

[puschpull]

Sh0dan: thanks !!!
Problem is with this plugins:
AntiBlink.dll (60 kB , 25.4.2004)
AvsTimerS.dll (48 kB , 7.3.2004)
avstimer.dll (12 kB , 7.3.2004)

Without this plugins in directory (C:\Program Files\AviSynth 2.5\plugins) run VirtualDubMod OK !
:-)

[kassandro]

Originally posted by puschpull
Sh0dan: thanks !!!
Problem is with this plugins:
AntiBlink.dll (60 kB , 25.4.2004)
AvsTimerS.dll (48 kB , 7.3.2004)
avstimer.dll (12 kB , 7.3.2004)

Without this plugins in directory (C:\Program Files\AviSynth 2.5\plugins) run VirtualDubMod OK !
:-)
I wonder that there are problems with my avstimer plugin, but you did something which you shouldn't do, namely to put both AvsTimerS.dll and avstimer.dll in the plugin directory. One is enough! Try first avstimer.dll. If it doesn't work, because of a missing dll, replace it by AvsTimerS.dll. Perhaps the new avisynth has problems with duplicate identifiers (AvsTimerS.dll and avstimer.dll define the same filters).

[puschpull]

kassandro: I test what You say, but problem stay
if i copy AvsTimerS.dll (48 kB , 7.3.2004) or avstimer.dll (12 kB , 7.3.2004), VDubMod Crash :-(
without this plugins (one or two) it's all OK

[kassandro]

Originally posted by puschpull
kassandro: I test what You say, but problem stay
if i copy AvsTimerS.dll (48 kB , 7.3.2004) or avstimer.dll (12 kB , 7.3.2004), VDubMod Crash :-(
without this plugins (one or two) it's all OK
If avstimer.dll is only in the plugin directory but no filter from the plugin is used, then only the function AvisynthPluginInit2 is called. With this function the filters of the plugin are registered by delivering to Avisynth functions to creat instances of these filters. All this is nearly identical for all plugins (I just looked at other). Two things are different. Firstly I print a logo to debugview and secondly I return a real string instead of NULL. I have now disabled these two features and put up a new binary to www.avstimer.de.tf (http://www.avstimer.de.tf). Actually only avstimer.dll is new not AvsTimerS.dll. Could you please try the new avstimer.dll.

[puschpull]

kassandro: i download newest avstimer.dll (20.6.2004), but problem stay !
If I have only one plugin (avstimer.dll) in directory C:\Program Files\AviSynth 2.5\plugins
VDubMod Crash! :-(
http://puschpull.org/doc/error.png

[puschpull]

kassandro:

now i test the same problem in another my PC
here is all problem OK why i remove from plugins directory (Avisynth) plugin name: AntiBlink.dll (60 kB 25.4.2003),
AvsTimer.dll (11 kB 20.6.2004) and AvsTimerS.dll (48 kB 7.3.2004)
in every combination of this three plugins VDubMod Crash !

????????

[kassandro]

Originally posted by puschpull
kassandro:

now i test the same problem in another my PC
here is all problem OK why i remove from plugins directory (Avisynth) plugin name: AntiBlink.dll (60 kB 25.4.2003),
AvsTimer.dll (11 kB 20.6.2004) and AvsTimerS.dll (48 kB 7.3.2004)
in every combination of this three plugins VDubMod Crash !

????????
Thanks for your all efforts. I will install AVS 2.5.5 on my notebook next week to run my own tests, to see what is going on here.

[cweb]

Originally posted by puschpull
shodan: thank's, but why i use this new avisynth (17.6.2004) then VirtualDubMod hat problem !! (version 1.5.10.1 build 2439)
:-(


http://puschpull.org/doc/error.png

why i uninstal this new alfa version and return version from 20.3.2004, its all OK !
:-)

I have the same problem. Running win98se, Virtualdubmod 1.5.4.1 and
1.5.10.1 have the same problem with the new 17th june avisynth.
I went back to 20/3/2004 without problems.
It happens as soon as you open virtualdubmod, without any script.

Fixed it: the problem was antiblink2_avs25.dll in the plugins dir which I don't use anyway, so I moved it to a subdirectory. Now virtualdubmod opens without problems.

[cweb]

Originally posted by puschpull
kassandro:

now i test the same problem in another my PC
here is all problem OK why i remove from plugins directory (Avisynth) plugin name: AntiBlink.dll (60 kB 25.4.2003),
AvsTimer.dll (11 kB 20.6.2004) and AvsTimerS.dll (48 kB 7.3.2004)
in every combination of this three plugins VDubMod Crash !

????????

Just don't leave antiblink in your plugins dir and it will work.
Move it somewhere else.

[mkanel]

The documentation that comes with Avisynth 2.5.5 [June. 17th] has this example


# this will print the frame number, a ":" and the average luma for that frame
WriteFile(filename, "current_frame", ":", "AverageLuma") Write file sends an error message to the text file because of the ":"

This works:

colon= ":"
WriteFile(filename, "current_frame", "colon", "AverageLuma")

WriteFileEnd doesn't work in this exapmle from the documentation

filename = "c:\myprojects\output.txt"
# create a test video to get frames
Version()

# the expression here is only a variable, which is evaluated and put in the file
# you will get a file with the framenumber in each line
WriteFile(filename, "current_frame")

# this line is written when the script is opened
WriteFileStart(filename, """ "This is the header" """)

# and this when the script is closed
WriteFileEnd(filename, """ "Now the script was closed" """)

The header and frame numbers are written but not the "Now the script was closed"

#####################

Is there any way for WriteFile to write entries to the same line of a text file instead of always starting a new line? Could I send a backspace before a line of text to get the new line on the previous line?

#####################

I would like to use FrameEvaluate to assign a variable other than a clip. Something like

number = (FrameEvaluate("averageLuma>200")) ?number+1 :number-1 or text = (FrameEvaluate("averageLuma>200")) ?"text" + "abc" :"text" + "def" Is there any way to do this?

Thanks for all the new features. And thanks for keeping up with the documentation, it looks good.

Mike.

[Wilbert]

I corrected your first example.

The header and frame numbers are written but not the "Now the script was closed"
This example works for me :confused:



text = (FrameEvaluate("averageLuma>200")) ?"text" + "abc" :"text" + "def"

Is there any way to do this?

Yes, this is possible. Checkout ConditionalFilter: Advanced conditional filtering: parts I and III (http://www.avisynth.org/ConditionalFilter).

Something like:

function ME(clip c)
{
global w = c
global text = (luma>200) ? "text1" : "text2"
c = FrameEvaluate(c, "global luma = AverageLuma(w)")
}

v = AviSoure(...)

global c = v
global luma = 0
v = ScriptClip(v, "Subtitle(text)")
v = FrameEvaluate(v, "ME(c)")


It probably doesn't work, because I didn't check it. I hope you will get it to work. If not, feel free to ask.

[esby]

Time to ask a stupid question...

I updated my local version to the current cvs...

building in debug mode: ok , no problem it compiles...

but when building in release mode...
"SoundTouch.lib(FIRFilter.obj) : fatal error LNK1202: "
...\src\Release\vc60.pdb" is missing debugging information for referencing module


Will that get fixed?

thanks :)

esby

PS: if I ain't wrong, it's debugging information, which should not be used in release mode anyway... right?

[mkanel]

Wilbert,

Originally posted by Wilbert
This example works for me :confused:


Thanks for checking out my complaint. Your right WriteFileEnd works fine. I read the documentation but didn't grasp the obvious. I need to close the script, not just run it to invoke WriteFileEnd.

That leaves just one minor complaint. I'll post the output this time in case it helps. This is from the documentation.
# create a test video to get different frames
Version.Trim(0,2).FadeIn(2).ConvertToYV12 #Added Trim,changed FadeIn
filename = "D:\output.txt"
# this will print the frame number, a ":" and the average luma for that frame
WriteFile(filename, "current_frame", ":", "AverageLuma")

Here's the output
1Script error: syntax error
(, line 1, column 1)38.717766
2Script error: syntax error
(, line 1, column 1)62.042042
3Script error: syntax error
(, line 1, column 1)84.787239

It works if I define colon=":".
# create a test video to get different frames
Version.Trim(0,2).FadeIn(2).ConvertToYV12 #Added Trim,changed FadeIn
filename = "D:\output.txt"
colon = ":"
# this will print the frame number, a ":" and the average luma for that frame
WriteFile(filename, "current_frame", "colon", "AverageLuma")

Here's the output
1:38.717766
2:62.042042
3:84.787239

Thanks for your pointers and example concerning FrameEvaluate. That looks encouraging but I'll need some more time to experiment with it.

Mike.

[stickboy]

Right, that colon problem is a mistake in the documentation. Basically you need an extra set of quotes, so you can either to define colon=":" as you did, or you can use """:""".

[sh0dan]

New CVS version out!

News from last version (mostly courtesy of IanB)


- Added TCPDeliver. (TCPServer/TCPSource) More info here (http://forum.doom9.org/showthread.php?s=&postid=460200#post460200) .
- Centre PointResize image.
- Fix VideoFrameBuffer cache corruption.
- Added FrameRate Numerator & Denominator script functions.
- General Convolution updates:
* fix matrix string env corruption
* roll divisor into iCountDiv logic - fix overflow problem
* make divisor a float
* add auto option to control autoscaling/normalizing feature
* support legacy syntax
* tidy indentation
- Fixed bug in PointResize.
- Turn: Fix concurrent use of RGB/YUY2 turnleft/right in same script.
- TurnLeft: Fix 1 pixel offset down in yuy2.
- Added: Turn180() function.
- Loop should now support all kinds of audio.
- Fixed wrong weights in interlaced YUY2 -> YV12 conversion.


Enjoy.

[Fizick]

Good news! Because I know, that somebody want use turnleft-turnright with my DeScratch plugin right now.

[malkion]

Is the version @ SourceForge the correct latest release?

It says v2.5.5 beta (12-07-04), and it's dated July 11, 2004.

Cant wait to try the float divisor.

[Wilbert]

Yes, it is the latest :) (I guess Shodan compiled it on July 11th.)

[malkion]

I get a bug with this script.

internal error with coefficients.

vdub just says unrecognized exception on the 2nd resize..

loadplugin("e:\dll\dgdecode.dll")
mpeg2source("e:\medallion\the.d2v")
crop(0,58,-0,-64)

x=last.width
y=last.height

lanczosresize(x*2,y*2)
lanczosresize(x,y)

[sh0dan]

@IanB: It's reporting "Zero Coeff Total" - any idea why?

[Wilbert]

I also got a similar message yesterday, because (?) I forgot to crop mod4 vertically (it should give that mod4 warning). Dunno, if it is related.

[sh0dan]

ok - I'll remove the '0'-check, and post a new binary. SF.net is currently in "Read Only" mode, so I can neither commit the changes or upload new files. But I'll put it there as soon as it is possible.

btw - spend an hour (again) to trace down why Resize is unable to throw exceptions without causing an access violation, when the binary is compiled using optimizations.... But as last time... nothing. :(

Edit: New version uploaded.

13-07-04:
- Fixed occational crash in Resize

[malkion]

Originally posted by sh0dan
Edit: New version uploaded.

13-07-04:
- Fixed occational crash in Resize

Thanks sh0dan. SourceForge doesn't have it ready yet, will grab it when it is.

@Wilbert, I modified the script to mod 4.

mpeg2source("e:\medallion\the.d2v")
crop(0,60,-0,-64)

x=last.width
y=last.height

lanczosresize(x*2,y*2)
lanczosresize(x,y)

This still throws a crash. (Waiting on SourceForge now.. :)

[Boulder]

Choose another mirror, I got it off the university of Minnesota. For some odd reason I had to type the address manually, my browser wouldn't change the mirror (it wanted to download from OSDN).

[malkion]

Boulder,

Got it. Thanks. bug fixed.

[IanB]

Originally posted by sh0dan
@IanB: It's reporting "Zero Coeff Total" - any idea why? This is what I was getting all bent out shape about when I was analysing the code for PointResize. I couldn't prove the sum of the coefficients wouldn't be 0.0 for the higher order resizers, so to make absolutly sure I trapped for the condition, and sure enough someone found a case.

Reality :- Whenever the trap happened some element of the resize would be wrong, probably a chunk of 8 bytes, maybe not very visible. for (int j=0; j<fir_filter_size; ++j)
total += func->f((start_pos+j - pos) * filter_step);
// if (total == 0.0) // Just to be absolutly sure - IanB
// env->ThrowError("Resize: Internal error, zero coeff total.");
double total2 = 0.0;
for (int k=0; k<fir_filter_size; ++k) {
double total3 = total2 + func->f((start_pos+k - pos) * filter_step) / total;
// -- Code is screwed here if total==0.0 -- /^^^\

*cur++ = int(total3*FPScale+0.5) - int(total2*FPScale+0.5);
total2 = total3;
}
In hind site, the original fix I tried to just force total=1.0 when 0.0 would have been adequate.

When all the coeff are 0.0 there is no problem, just feed zeros into *cur++ (This is the case demonstrated).

It is in the case where the coeff sum to 0.0 that need very careful attention. It seems
total=0.5*sum[abs(coeff)] is a solution.

Thorts?

IanB

P.S. I propose the following code ...
double total = 0.0;
double total2 = 0.0;
for (int j=0; j<fir_filter_size; ++j) {
total += func->f((start_pos+j - pos) * filter_step);
total2 += fabs(func->f((start_pos+j - pos) * filter_step));
}
if (total == 0.0) {
if (total2 == 0.0)
total = 1.0; // All coeff are zero, just feed zeros
else
total = total2 / 2.0; // Coeff sum to zero, use a good guess
}
total2 = 0.0;
for (int k=0; k<fir_filter_size; ++k) {
...

[sh0dan]

Found the cause!

"pos" could get beyond image size, thus attempting to create resizers entirely outside the image.

The following code is my proposal:
if (original_width <= filter_support) {
env->ThrowError("Resize: Source image too small for this resize method");
}
This was never checked, but it will cause errors, if it isn't true.

This is the replacement for the coefficient calculation.
// the following code ensures that the coefficients add to exactly FPScale
double total = 0.0;

// Ensure that we have a valid position
double ok_pos = max(0.0,min(original_width - subrange_start,pos));

for (int j=0; j<fir_filter_size; ++j) { // Accumulate all coefficients
total += func->f((start_pos+j - ok_pos) * filter_step);
}

if (total == 0.0) {
// Shouldn't happend for valid positions.
#ifdef _DEBUG
env->ThrowError("Resizer: [Internal Error] Got Zero Coefficient");
#endif
total = 1.0;
}
[...]

[IanB]

Sh0dan,

And can you ( mathemagicly :devil: ) prove that the sum of the coeff can never be zero unless they are all zero?

This is what my total2=0.5*sum[fabs(coeff)] belt/braces is about.

IanB

P.S. If there is any doubt, how about this// the following code ensures that the coefficients add to exactly FPScale
double total = 0.0;
double total2 = 0.0;

// Ensure that we have a valid position
double ok_pos = max(0.0,min(original_width - subrange_start,pos));

for (int j=0; j<fir_filter_size; ++j) { // Accumulate all coefficients
double coeff = func->f((start_pos+j - ok_pos) * filter_step);
total += coeff;
total2 += fabs(coeff);
}

if (total == 0.0) {
if (total2 == 0.0) {
// Shouldn't happend for valid positions.
#ifdef _DEBUG
env->ThrowError("Resizer: [Internal Error] Got Zero Coefficient");
#endif
total = 1.0; // All coeff are zero, just feed zeros
}
else
total = total2 / 2.0; // Real bad luck, Coeff sum to zero, use a good guess
}
total2 = 0.0;
[...]

[Leak]

Originally posted by IanB
P.S. I propose the following code ...
[...]
for (int j=0; j<fir_filter_size; ++j) {
total += func->f((start_pos+j - pos) * filter_step);
total2 += fabs(func->f((start_pos+j - pos) * filter_step));
}
[...]

Please, if you're going to do this - store the right hand side of the "total+=" expression in a variable and feed that to fabs() instead of evaluating it 2 times, as I doubt an optimizing compiler will treat expressions containing a method call (which really isn't inline-able) as common subexpressions...

np: Luomo - Talk In Danger (Nohuume)

[Manao]

Leak : this is made at the initialization of the filter, so speed isn't really an issue.

IanB : Mathematically, it will be hard, because 'double' behavior is hard to modelize. However :

* except for pointresize, you always have a non zero coefficient.

* for bilinear, no problems, because the interpolating function is always positive.

* for bicubic, the interpolating function 'f' is defined on [-2, 2], negative on [-2,-1]U[1,2], positive elsewhere, and we take at least 4 coefficients, uniformely distributed, so we have at least 2 coefficients on [-1,1]. I don't know exactly how 'a' and 'b' influence the curb of the function, but in a 'usable' range for both these coefficients, I guess that abs(f) is a lot bigger on [-1,1] than on [-2,-1]U[1,2]. So it should be safe ( we pair positive and negative coefficients together, and we should always have the positive one greater in absolute than the negative one ).

* for lanczos3, the function is defined on [-3,3], negative on [-2,-1]U[1,2], positive elsewhere. We take at least 6 coefficients uniformely distributed. The same reasonning can apply

* also for lanczos4.

I proved nothing, but I really think you're on the safe side to suppose it's not possible.

[sh0dan]

No - thus the "total= 1.0", and the error message only present in the debug builds.

I removed the "total2"-stuff, because it doesn't really make any sense.

I thought about:total = (double)fir_filter_size; // Real bad luck, Coeff sum to zero, use a good guess- but it just doesn't make sense.

Consider:
fir size: 4 pixels
fir coefficients: [0.0, -0.5, -0.5, 1.0]
p: final pixel
p1-4: source pixels.

Then:
p = ( p1*0.0 + p2*-0.5 + p3*-0.5 + p4*1.0) / TOTALWhatever you choose for TOTAL, you will end up with p = 0 on a uniform surface (p1=p2=p3=p4)

Therefore I removed the cause for "total = 0", and just set total to 1.0, if it should (by mistake) be possible to get this result in the real world (ie. some strange border issue or something)

[Bidoche]

Maybe the simplest solution, would be to poison the input values by a small shift when a 0 happens.

ie instead of returning Resize(width, height)
you return Resize(width, height, .01, 0, width, height)

[IanB]

@Bidoche,

A little chicken before the egg, If we knew when a total==0 was about to happen we could do a lot better than poison the values, and if we don't know, which way do we nudge + or -?

Bumping denominators to dodge divide by zero conditions will always gets you in the long run.:)

IanB

[IanB]

Dear all,

Some of the updates I submitted didn't make the last CVS version cut.

- Fix VideoFrameBuffer cache corruption.
- General Convolution updates:
* support legacy syntax

I will have to wait for the next version. :cool:

Sorry for any inconvienience. :o

IanB

[sh0dan]

Just did a silent update - all the advertised features should now be in place! :cool:

[Bidoche]

@IanB

We don't need to know when it will happen.
When it does we just retry with slightly different margins value.

Like this :

[...]
if ( total == 0.0 )
throw PatternZeroTotalException(); //specific custom exception
[...]

//in code calling the pattern

try { //creating the pattern }
catch( PatternZeroTotalException& )
{
marginleft += 0.01;
//retry again
}

[Wilbert]

Bugreport from our friend mf:

c1 = MPEG2Source("F:\From_hell\from_hell.d2v")
c2 = BlankClip(c1)
ConditionalFilter(c1, c1, c2, "AverageLuma()", "morethan", "100", true)

always returns true (also when it is false), and also c1 is show in that case.


c1 = MPEG2Source("F:\From_hell\from_hell.d2v")
c2 = BlankClip(c1)
ConditionalFilter(c1, c1, c2, "AverageLuma()", ">", "100", true)

works though.

[IanB]

@Bidoche,

Yes, this would be a really cool :cool: OO implementation, I quite like it in concept, but the whole concept of dodging errors, like divide by zero, in this way leave me a little unconfortable.

The key assumption here is that the programmer understands the relationship between the input value he is bumping and the output value he is trapping against. If they are tightly, exactly and obviously related this works extremely well. If they are even slightly independant then no amount of bumping can guarrantee avoiding the condition in all cases.

I recently fixed a bug in someones code where this type of thinking had been used inside a loop. You guessed it, the code never exited, it bumped forever. :p

As it turns out bumping here wouldn't have helped as Sh0dan found the code was running off the edge of the picture by a lot. The whole deal with this deficiency in the resizer code is to understand where the total==0.0 can come from and adjust the code to avoid the problem totally.

Thankyou for pushing this point because it has made think about the consequences of trapping illegal values so ruthlessly. Sh0dan has the right answer by trapping only in debug mode, in fact we probably should leave the trap code active until we go to release candidate.;)

IanB:D

[sh0dan]

Originally posted by Wilbert
Bugreport from our friend mf:

c1 = MPEG2Source("F:\From_hell\from_hell.d2v")
c2 = BlankClip(c1)
ConditionalFilter(c1, c1, c2, "AverageLuma()", "morethan", "100", true)

always returns true (also when it is false), and also c1 is show in that case.

Hmm... It should actually throw an error, since it should be "greaterthan". I'll see why it doesn't.

Edit: Fixed.

[Manao]

Any resizing to non mod8 resolutions in YV12 shift the chroma horizontally ( by 20 - 30 pixels I guess ). I never saw that bug, but I tried several version between 2.54 and latest 2.55 alpha, and all show that behavior.

[ARDA]

I couldn't reproduce in my machines. Which decoder are you using? I remember some old xvid decoder's bug (mod4)ShOdan helped to fix. Which avysinth date version?.
I hope that can help you to find your problem.
ARDA

[Manao]

Damned, that's why I kept saying me "I already saw that thing somewhere..." I was the one reporting that bug and I totally forgot it. Thanks ARDA, the guilty is XviD 1.0.1. I'll PM Koepi about it.

[yaz]

the 'zero coeff. total' (outlined here (http://forum.doom9.org/showthread.php?s=&threadid=79603)) has gone but now i have 'Unrecognized exception' or(!) 'Access violation ... attempted 0x0000000' depending on what resolution i set. now it's not on loading but on encoding/playing back the script. i'm sure it's still the resizer but ... what ? (when i'm back to 170604 everything worx fine) pls ... is it me or avs ?
thx
y

[IanB]

@Yaz,

The usual please....

Copy of your script, parameters of your input file(s) (height, width, codec, etc)

IanB

[yaz]

Originally posted by IanB
Copy of your script, parameters of your input file(s) (height, width, codec, etc) sorry, but 'crossposting & replication is forbidden'. that's why i dropped only the link above. there u can find all details i have.
shortly, i've used this/that script with the same dvd source for months wout any problem. the first crash came with 120704. pls find what i found via the link.
at the moment (1400704) there's no problem when loading the script but it crashes vdm when encoding a/o mpc when playing back with errmsg i wrote. the crashpoint has no chracteristic feature (at least i haven't found any) & it does not even seems to be reproducible (i mean, i can't locate a specific frame triggering it, rather it occurs 'after some time').
when switched back to 170604 everything goes fine, so i'm sure it's avs and not me :-)
thx
y

[sh0dan]

I've re-checked the code that has changed, and I'm not sure the problem is in the resizer. It seems like something somewhere is being given a zero-pointer. It _could_ be related to recent cache changes.

Are anyone capable of reproducing this problem WITHOUT using a resizer?

[IanB]

BlankClip(100000, 720, 480, pixel_type="YV12")
Crop(12, 12, -12, -12, align=true)
LanczosResize(528, 288)Won't even load in AviSynth_120704.exe (Build:Jul 5 2004 [14:29:59])

Works A-Okay in AviSynth_140704.exe (Build:Jul 15 2004 [16:39:25])

Note - also a bug in installer! reinstalling looses Notepad association.

IanB

[tritical]

I'm wondering if anyone ever found out anything more about getting "Evaluate: unrecognized exception" instead of the actual error msg when calling env->ThrowError() in a filter constructor. I saw earlier in this thread ColorYUV, and the resampling filters had the same problem. In a filter I'm working on I call throwerror in the constructor and this happens. I ran a release build through debugging real quick and it seems it hits an access violation trying to write somewhere after the first exception is thrown, but I haven't been able to track down the exact problem location. If I build the filter in debug configuration it works correctly, probably since the catch all (catch(...)) in evaluate gets ifdef'd out when in debug mode... but also, the write access violation doesn't occur in debug mode. Funny thing is, it seems totally random... I can cause the problem to occur and not occur on my current filter simply by removing or adding one line from the
AVSValue __cdecl Create_Filtername(AVSValue args, void* user_data, IScriptEnvironment* env)
function. And the most confusing thing is, the line is just:

char pdir[80];

I don't even have to reference the variable or use it, and it will still cause the problem to happen. It isn't a problem with conflicting names or variables as it occurs with any name I give the variable. Anyways, just wondering if anyone knew what was going on, its not very important but is rather annoying :devil:. I'm using avisynth 2.5.5 build from march 18th.

[stickboy]

Originally posted by tritical
Funny thing is, it seems totally random... I can cause the problem to occur and not occur on my current filter simply by removing or adding one line from the
AVSValue __cdecl Create_Filtername(AVSValue args, void* user_data, IScriptEnvironment* env)
function. And the most confusing thing is, the line is just:

char pdir[80];

I don't even have to reference the variable or use it, and it will still cause the problem to happen.Maybe you're overflowing some buffer somewhere and corrupting the stack.

Have any sample code that demonstrates your problem?

[yaz]

Originally posted by sh0dan
... Are anyone capable of reproducing this problem WITHOUT using a resizer? ... resizer still has some problems (140704 does not accept 'any' frame-size values even if mod4) but i had no time for a thorough & consistent test. maybe tonight.
maybe i try to do a 'filter-drop test' (dropping them 1by1) but ... time is not on my side these days.
just a simpleton question. if avisynth's once broken like i wrote above, can i go on with a job-queue (taking the next script aso aso)or is it better to restart the system ?
thx
y

[tritical]

Well, I downloaded the latest source from the cvs and built avisynth.dll to try debugging it, but the problem seems to be gone using this version and I can't reproduce it. Should have tried grabbing the latest version to begin with, sorry.

[Wilbert]

@Sh0dan,

All links to pictures in the html docs are working now.

Before this we had only one pictures folder, but that way, either the chm file didn't link the pics correctly (due to bug in HTML Workshop) or the html files themselves didn't link them correctly.

So, I put the pictures folder in every language folder and updated the installer (contrary to what I thought months ago, the pics are included once).

[sh0dan]

@All: I think the problems in the current build isn't strickly related to the resizers. I'll release a test version.

@Wilbert: The documentation looks extremely good! I noticed the installer has grown ~300k to about 1.7Meg. I see that duplicated files are not included several times, so I cannot see where the 300 are going. Is it because of the new images in externalfilters?

[Wilbert]

The new images are 323 KB. So, that could be (I guess). I will compress them a bit more ...

[IanB]

Originally posted by sh0dan
@All: I think the problems in the current build isn't strickly related to the resizers. I'll release a test version.@Sh0dan,

Yes, I have been trying to find why constructors can't reliably env->ThrowError(...) in non-debug releases. So far not much luck, but I have had 1 (unreproducable) instance of the stack being overwritten. I'll keep on looking, as this is what I suspected was happening.

As for the memory management changes, I commented out "Plan B" mainly to give the reclaimation code (which previously failed miserably) a very hard workout (it is currently the only way to reuse frame buffers). Previously for purely linear scripts "Plan B" would be used exclusively and never see the problem in the reclaimation code, this may now be exposing other hidden problems. I have given it a fairly strong workout on both my old PII-MMX 400 and current P4, but it needs to be severly beaten with P-III, HT & AMD's processors as well.

I would rather find and fix any bugs in the memory management now but if you feel it is compounding other problems and making them hard to find then please uncomment the "Plan B" code.

IanB

P.S. A linear script has a single path from input to output. A non-linear script has forked branches like doing a separatefields() with selecteven() and selectodd() branches.

Edit: Sorry "Plan B" not "Method 2"

[IanB]

I have found using Plan C exclusively causes heap fragmentation and hence the uncontrolled growth of memory usage. So in the CVS tree I have restored plan B memory management and have also decreased the memory overdraft from 25% to 12.5%. I will keep pondering for a clean way to get the cache to update the frame buffer pool for LRU.:p

I hopefully have also fixed handling of memory > 1.6GB (a signed int overflow problem).;)

No luck finding the stack trasher :devil: yet. When it strikes it damages the exception handler data in the stack frame, usually causing an access violation in the kernel. Debug versions seem immune.:mad:

IanB

[DDogg]

I hesitate to call this a report as there is no hard data, but I have found that the newest build (AviSynth_140704.exe) causes CCE 2.67.00.27 to 'drop out' and prematurely end encoding at seemingly random stages of the encode.

Initially I thought I was pushing my CPU too hard. So, I ran Prime95 and it was solid. After scratching my head a bit I installed an older version of AviSynth I had in my dvd2svcd directory (avisynth253.exe). After that all encodes finished properly.

The good thing is I can replicate this seemingly at will by changing back to the later build. When new builds come out I can test to see if this situation still exists. I'm also happy to test any test builds if needed.

The script I was using is a resizing and cropping script build by FACAR which is r6d2's derivative of Gerti's semi-auto crop and resize. Since it is so long I will not post it unless requested, or I can answer a PM request with the script if desired.

Perhaps it is something else interacting with the newer build. If time permits I will try to pin things down a tad better.

[Leak]

Originally posted by DDogg
I hesitate to call this a report as there is no hard data, but I have found that the newest build (AviSynth_140704.exe) causes CCE 2.67.00.27 to 'drop out' and prematurely end encoding at seemingly random stages of the encode.

Initially I thought I was pushing my CPU too hard. So, I ran Prime95 and it was solid. After scratching my head a bit I installed an older version of AviSynth I had in my dvd2svcd directory (avisynth253.exe). After that all encodes finished properly.

I guess you're having the same problem that I've reported in this thread (http://forum.doom9.org/showthread.php?threadid=79504):

Actually, I was doing some tests today trying out a plugin I'm just working on, and when I was encoding a 24 minutes episode halfway through VirtualDubMod just disappeared on me. Well, a while after starting the job a second time I took a look at Process Explorer's output and noticed that VirtualDubMod's virtual size was over 1.4GB - okay, so this is just the address space the application takes up and not really the memory it uses, but I guess it's what tore VDubMod down after reaching the 2GB mark - IIRC that's the limit for each application's address space (unless you do some extra work to get it to give you 3GB)...

Grab Process Explorer at http://www.sysinternals.com/, start it and click on "View/Select columns...", then switch to the "Process Performance" tab and tick "Virtual Size".

Then just start encoding and watch the virtual size of your encoding process increase steadily, until it reaches 2GB - where it'll die on you.

np: Alter Ego - Transphormer (Transphormer)

[malkion]

I can report similar findings with the AviSynth_140704 build. One attempt at encoding had VDMod disappear halfway through. A 2nd attempt resulted in an internal error, as did a third. Rolling back to AviSynth_170604 results in no errors.

Script:

directshowsource
crop(4,0,-0,-0).lanczosresize(640,480)
mipsmooth(preset="animelq")
deen("a3d")
convolution3d("animebq")
fluxsmooth()
limiter()

I'm sure Sh0dan and IanB are ironing out the memory management issues mentioned above. No fancy resizing on this job, just a simple compression encode.

[IanB]

Dear all,

My bad, all version since I knobbled Plan B, Sun Jul 11 07:36:02 2004 UTC, will eventually exhaust the process address space limit (2GB).

The reason is Plan C releases only the frame buffer not the managing structures. When a new one is requested stupid windows heap allocater grabs a fresh block from the top of memory rather than reusing any of the previously freed chunks (it apparently want memory contiguously free at the end of the heap to reuse it). After a while the heap looks like swiss cheese. Avisynth strictly speaking never uses more than "memory_max"+25% but it is not counting all the holes between inuse blocks. When the inuse memory plus all the unused holes try to exceed 2GB it is very fatal.

Anyway no one seems to have reported the frame buffer corruption caused by Plan C I originally targeted the fix at, and you have all tested it to the point of heap collapse, so it's not all bad news.

IanB

[morsa]

can't some kind of "defragmenter" be included?

[Leak]

Originally posted by IanB
The reason is Plan C releases only the frame buffer not the managing structures. When a new one is requested stupid windows heap allocater grabs a fresh block from the top of memory rather than reusing any of the previously freed chunks (it apparently want memory contiguously free at the end of the heap to reuse it).

Yeah, without a garbage collector you'll get that... :(

Hmmm... do those structures themselves have fixed sizes? If not, instead of freeing them you could add them to a pool (i.e. an array or linked list) and take them out again and reset them when a new one is requested and the pool isn't empty, only really freeing objects when the pool exceeds some limit - overloading the new and delete operators makes this rather easy in C++. That would also eliminate the overhead allocating memory in the swiss cheese is going to bring with it...

Just thought for food.

np: Bigg Jus - Plantation Rhymes (Southern Hospitality Mix) (Black Mamba Serums v2.0)

[Bidoche]

I am not sure it's really Windows who is to blame.
But rather the C runtime coming with VC6.

[IanB]

@morsa,
> can't some kind of "defragmenter" be included?

@Leak
> instead of freeing them you could add them to a pool....

"Plan B" is exactly that it looks thru the existing list of FrameBuffers for one the right size and if it is not in use it reuses it. There are very few bug reports I can pair with the "Plan C" corruption I found, so "Plan B" must have been working well enough:D

Unfortunatly the list it scans is NOT in LRU order but in first created order, this tends to encourage Murphy's law and a buffer about to be needed usually is selected. I have a few schemes I am pondering to improve this. When I find my stack trasher, I'll commit some proper time to this.

@Bidoche,
> ...the C runtime coming with VC6.
True, but a little harsh. I am yet to find a heap manager that is totally immune from combing (or swiss cheese);)


IanB

[sh0dan]

Hi!

Mostly a fix for the crash-issues that were present in the latest version. Though remember this _is_ beta-stage software. The other stuff is minor fixes, and a rather large addition to TCPDeliver - requiering both client and server upgrades.

- Fixed problems causing random crashes and excessive memory problems in July 13th binary.
- Fixed errors in NON-MMX ColorKeyMask.
- Fixed Loop() when called with no video (stickboy)
- Added AssumeFPS(clip [, sync_audio=true/false]) (stickboy again).
- AssumeFPS: Added sanity check to ensure that denominator isn't zero.
- Fixed error not being thrown in Conditionalfilter on an invalid operator.
- Added first version of compression for TCPdeliver. LZO, Huffman and GZIP Huffman algorithms added. Docs here (http://www.avisynth.org/TCPDeliver).


Hey - also 3002nd post! :D

[sh0dan]

Silent update:
- Fixed MergaLuma not giving correct results in some cases.
- Fixed DirectShowSource not releasing Graph/Files on unload/reload.

[Kurtnoise]

I've a bug after installing the last beta (29/07/04 version).

When I load an avs script in VDM, I've an error :


Runtime Error !

Program: C:\Montage_Video\VDM\VirtualDubMod.exe

abnormal program termination


Whereas if I install the last alpha, everything is ok...:scared: Any idea ??

[Leak]

Originally posted by Kurtnoise13
I've a bug after installing the last beta (29/07/04 version).

When I load an avs script in VDM, I've an error.

Whereas if I install the last alpha, everything is ok...:scared: Any idea ??

Well, since the same version works for me (and probably quite a few other people), you might want to do the basic exercises for that case - try a script only containing "Version()", remove all plugins from your plugin folder, if it works then put them back one by one until the crash happens again, etc...

EDIT: Oh yeah, since I always forget that step - :script:, like Boulder said... :)

np: Dntel - Barbara Morgenstern Remix ((This Is) The Dream Of Evan And Chan)

[Boulder]

You should also post the script you've used to help the devs;)

[Kurtnoise]

Yeah...Leak, you're right. Problem solved to removing the plugins from the plugin folder ;) Error Source was Antiblink.dll...

Thank you anyway :cool:

[yaz]

Originally posted by sh0dan
... Silent update ...
great great great ... it's stable again :-) been tested for 3 days but no more occasional crash (so far ... or should i be more trustful ? :-)
thx a lot
y

[sh0dan]

August 17th:

I currently cannot browse the CVS, so this is the changes I remember:


- Added: ImageReader/ImageSource now accepts relative paths in all configurations.
- Fixed: ImageReader now no longer reports errors/info upside-down.
- Added: DirectShowSource now requests interlaced material to avoid internal (crappy) WMV9 deinterlacer. (Thanks to Russel Lang)
- Fix: Huge stability fix by IanB. This should remove a bunch of "Evaluate: Unregnized exception", and crashes on reload in vdub.
- TDPDeliver: Simplification and cleanup. Planar pitches handled more consistently.
- Fix: DirectShowSource properly relasing filters on unload.
- Added: BlankClip now has color_yuv, that allows setting and YUV color for YUV clips.
- Added a huge list of color presets (http://www.avisynth.org/ColorPresets), that can be used instead of colors.

[Didée]

Fine, fine, fine :)
Big thanks to all contributors.

- Fix: Huge stability fix by IanB. This should remove a bunch of "Evaluate: Unregnized exception", and crashes on reload in vdub.
Ah. Last weeks, there were times where I was spending more time on "where IS the damn error, my application disappears without message" than on actual scripting ...

***

Quick question:
Yesterday I wanted to process a pile of images through avisynth, but resize the input with different resizers from ffdshow.

Made two scripts:
- loader_script: "ImageReader(...)
- proc_script: "DirectShowSource("loader_script.avs") ... etc."

Problem:
Loading the proc_script through graphedit, ffdshow was linked into the DS chain as expected.
Loading the same script in VdubMod, ffdshow was not kicking in.

Where's my mistake :confused:

- Didée

[Wilbert]

@Sh0dan,

I committed two color_preset files (the short avsi one, and the long txt one). I thought perhaps the long one put too much variables in your memory. But, I guess you can use 1024 variables, so it shouldn't matter ???

[sh0dan]

Originally posted by Wilbert
@Sh0dan,

I committed two color_preset files (the short avsi one, and the long txt one). I thought perhaps the long one put too much variables in your memory. But, I guess you can use 1024 variables, so it shouldn't matter ???
The Variable table should be a linked list, with no size restrictions, beside available memory. Have I missed this setting somewhere?

[Wilbert]

Which setting? Is there a maximal number of variables which can be defined (or does that depend on the available amount of free memory)?

[Dreassica]

I'm getting scriptclip errormessages on all my usual qmf scripts i use with this latest version. They all worked fine with the previous builds.
errormsg is:

evaluate Unrecognised exception
([scriptclip] line 1}
([scriptclip] line 1}

[sh0dan]

Originally posted by Wilbert
Which setting? Is there a maximal number of variables which can be defined (or does that depend on the available amount of free memory)?
I just wondered where you got '1024' from?

@Dreassica: Could I get a link to the scripts?

[Dreassica]

U mean mine, or the qmf script from homie fr?
Cuz theres an example of that on avisynth.org

anyway, my script used is (using qmf 1.5b1):

function Low_Motion_Filter(clip c)
{
c = Deen(c,"w3d",1,4,4,11,12,0.25,4)
c = unfilter(c,0,-1)
c = undot(c)
return c
}
function Medium_Motion_Filter(clip c)
{
c = Deen(c,"w3d",1,8,7,6,6,0.35,6)
c = undot(c)
c = unfilter(c,-1,-2)
return c
}

function High_Motion_Filter(clip c)
{
c = Deen(c,"w3d",2,12,11,3,4,0.45,1)
c = unfilter(c,-2,-3)
c = undot(c)
return c
}
mpeg2source("F:\VIDEO_TS\10.d2v")
doubleweave().TPRIVTC("F:\VIDEO_TS\\10\10.tpr")
crop(10,4,696,476,align=true)
QMF(chroma=true,threshold_lm=2.9,threshold_hm=11.3)
bicubicresize(640,480,0,0.5)
tweak(cont=1.02,sat=1.3)
limiter()

[sh0dan]

@Dreassica: Thanks!

@IanB: Seems like there is still some optimizations bugs left. :(

I have do diable: "Global Optimizations" and "Full Optimization", otherwise we get a crash, in code very similar to what you experienced. I can however turn on "Frame-Pointer Omission" without experiencing problems. Your reaction?

[Wilbert]

I just wondered where you got '1024' from?
This turned out the be the maximal no of arguments of a function :)

[You Know]

YDifferenceFromPrevious
UDifferenceFromPrevious
VDifferenceFromPrevious

YDifferenceToNext
....

does not work anymore


Evaluate: Unrecognised exception!
([scriptclip] line 1)


all code post on help and web page (www.avisynth.org) fails ... for example

clip = AVISource("clip.avi",audio=false)
ScriptClip(clip, "Subtitle(String(YDifferenceFromPrevious))")


I come back to 2.5.5 beta 2 and works perfect, please fix
:(

[sh0dan]

@You Know: It's the same bug as described above. RC2 will probably be out soon.

[You Know]

problem descript from Dreassica??
ah OK

NB other function as AvarangeLuma ecc ecc works

[IanB]

Originally posted by sh0dan
@IanB: Seems like there is still some optimizations bugs left. :(

I have do disable: "Global Optimizations" and "Full Optimization", otherwise we get a crash, in code very similar to what you experienced. I can however turn on "Frame-Pointer Omission" without experiencing problems. Your reaction?

I was concerned that "Frame-Pointer Omission" was just shuffling the deck and sending the bug to ground, looks like it's true. :( I really have only classified the bug so far, not found the antidote yet.

Disabling "Global Optimizations" and "Full Optimization" is just about the whole lot, but this may be what we have to do. Perhaps we #pragma the few places (non-mmx getframe/getaudio) that optimizing is really important and hand check that code.

One further issue that may have been overlooked is that any routine on the call stack, with stack based objects created (most typically AVSValue's or {I,P}Clip's), at the time the exception is thrown is a candidate for this problem. This includes third party filters.

Until we find the recipe that 100% triggers the compiler to emit dud code. The only way I can think of to be sure is run with no optimatization (like you suggest) or hand check every routines entry setup code against the SEH destructor calls at the end, not a pleasant sounding task.

IanB :(

[sh0dan]

August 20th Release Candidate 2:


- Fixed "Unknown exception" in conditional filter expressions. (August 17th regression)
- Updated docs.

[LigH]

Usually, one assumes: Why using Crop and *Resize, if resizer functions may crop while resizing as well? In fact, this shall even be much more efficient than running one after each other (like DVD2SVCD vs. GordianKnot).

Well, unfortunately, there is a difference: Cropping wihle resizing doubles the bottom image line, while cropping and resizing is clean - using AviSynth from 29th July 2004 as well as the mentioned new RC2.

Please see examples in this thread in the German doom9/Gleitz forum (http://forum.gleitz.info/showthread.php?t=15459) (unfortunately, downloading binaries from my server became forbidden, so I only can attach files to threads now).

[You Know]

bug or limitation?

i have notice that (with beta 2) if i open larger avi 9/12 Gb after 5100th it freeze and repeat frame 5100 eternally

Have AVIFileSource a limit of 4GB?

EDIT: installed RC2 same problem with larger avi
recode 50% on anime movie :(((((((((

[esby]

Could you put more details ?
and the filterchain used?

esby

[You Know]

a1 = AVIFileSource("E:\part1.avi")
return a1


part1 file was 12.404.xxx KB (uncompress YV12 source)


a1 = AVIFileSource("F:\part3.avi")
return a1


part3 file was 9.404.000 KB (uncompress YV12 source)


a1 = AVIFileSource("C:\part2.avi")
return a1


part2 file was 12.3??.xxx KB (uncompress YV12 source)

with file of only 2GB it works :(

[esby]

mmmmm

I don't want to vex you, but if you are using segments of more than 2 or 4 gb,
you are bound to get problems (depending the os you are using).
(that s why vdub and other programs got the multi segmented avisource function)

(and in that case check multisegmented source loading function)

esby

[You Know]

Originally posted by esby
you are bound to get problems (depending the os you are using).

if you have FAT32 limit are 2^32 = 4gb file size with NTFS no.
C++ function can get and seek using a long but handicap can be bypass using int origin parameter ... i think no made example for now


Originally posted by esby
that s why vdub and other programs got the multi segmented avisource function[/B]

yes but i did not known there was this limitation. I open Part1.avi and append segment part2 and part3 with virtualdubmod and i can seek where i want in file and no size limitation !;)

Now i rencoding all (2fps script on 127343 frame lenght) using segment to 2048 but avisynth could support very large file as vdm can.

[You Know]

mfToon 0.52 script does not work with RC2. I think to rest on beta 2 for ever.
bye

[esby]

es but i did not known there was this limitation. I open Part1.avi and append segment part2 and part3 with virtualdubmod and i can seek where i want in file and no size limitation !

Now i rencoding all (2fps script on 127343 frame lenght) using segment to 2048 but avisynth could support very large file as vdm can.


just open the 3 files with vdubmod, set direct stream for video & audio
and use the save by segments feature, no?

esby

Are there other known issues of xp SP2 & avisynth btw?

[You Know]

Originally posted by esby
just open the 3 files with vdubmod, set direct stream for video & audio
and use the save by segments feature, no?

no comment ... maybe i have not enought space to segmet avi, if you can see part file are all on different partition.

Originally posted by esby
Are there other known issues of xp SP2 & avisynth btw?

my PC never seen xp, windows 2000 rulez

[LigH]

If you want to visualise the differences between "Resize incl. crop" and "Crop + resize", you may want to check this kind of "template":
MPEG2Source("DVDSource.d2v")
Clip1=Lanczos4Resize(512,208,0,72,720,440)
Clip2=Crop(0,72,720,440).Lanczos4Resize(512,208)
Subtract(Clip1,Clip2).Levels(96,1,160,0,255)

[sh0dan]

@LigH: Thanks - I'll look at it.

Edit: Fixed.

[sh0dan]

General update:

It seems like the new optimization settings break plugins. I've encountered problems with the "AviSynth Subtitler" plugin. Re-enabling optimizations FIXES the problem.

So for 2.5.5 I think we should keep the "old" optimization settings. Any thoughts?

[esby]

... optimization ... breaking plugins
Could it be the same types of problems that mug-funky is having with my last dsynth build?

esby

[LigH]

Fixed? Fine!
__

Another bug reported by the mentioned german user:
V1=AVISource("8kHz_Mono_CBRMP3.avi",audio=true,pixel_type="YV12")
\.Crop(14,2,424,332)
\.BilinearResize(336,240)
\.Blockbuster(method="noise",detail_min=1,detail_max=100,mean=0,variance=10,cache=2048)
\.AddBorders(8,0,8,0)
\.AssumeFPS(29.970,sync_audio=true)
\.SSRC(48000,fast=false)
A=AudioDub(V1,MergeChannels(GetChannel(V1,1),GetChannel(V1,1))
He expects the two channels to be identical; instead he reports changing sync/async and differences between both channels of a supposed dual-mono => stereo audio stream. Shall he try EnsureVBRMP3Sync (http://www.avisynth.org/EnsureVBRMP3Sync) although he has a CBR stream? Or is the sampling rate too low for SSRC? Or is SSRC really optimized for not-too-far downsampling? ResampleAudio(48000) instead shall work well.

[sh0dan]

He should definately try "EnsureVBRMP3Sync" first. This is in general recommended for ACM-compressed audio. I guess the audio cache helps resampleaudio here.

SSRC shouldn't have any problems with ratechanges this size.

[Wilbert]

After AssumeFPS(sync_audio=true) your audio has some weird samplerate.
I might be totally wrong, but I thought SSRC doesn't do "arbitrary" samplerate conversions.

from ssrc.c:

frqgcd = gcd(sfrq,dfrq);

fs1 = sfrq / frqgcd * dfrq;

if (fs1/dfrq == 1) osf = 1;
else if (fs1/dfrq % 2 == 0) osf = 2;
else if (fs1/dfrq % 3 == 0) osf = 3;
else {
fprintf(stderr,"Resampling from %dHz to %dHz is not supported.\n",sfrq,dfrq);
...
}


What you should do is

AVISource("8kHz_Mono_CBRMP3.avi",audio=true,pixel_type="YV12")
EnsureVBRMP3Sync # for audio cache
AssumeFPS(29.970,sync_audio=true)
AssumeSampleRate(8000)
SSRC(48000,fast=false)
...

[IanB]

Originally posted by sh0dan
General update:

It seems like the new optimization settings break plugins. I've encountered problems with the "AviSynth Subtitler" plugin. Re-enabling optimizations FIXES the problem.

So for 2.5.5 I think we should keep the "old" optimization settings. Any thoughts? While the compiler is definitly forgetting to emit some code at times, I am starting to doubt it is the optimiser causing it. Changing the /O... settings just seems to shuffles the deck, making the bug appear and hide apparently randomly.

Below is a CVS history extract of the "Release" cpp control strings.1.1 ! # ADD CPP /n.../GX /Zi /O2 /Ob2 /D..."AVISYNTH_EXPORTS" ...
1.6 ! # ADD CPP /n.../GX /Zi /O2 /Ob2 /D..."AVISYNTH_C_EXPORTS"...
1.13! # ADD CPP /n.../GX /O2 /Ob2 /D..."AVISYNTH_C_EXPORTS"...
1.17! # ADD CPP /n.../GX /Zi /O2 /Ob2 /D..."AVISYNTH_C_EXPORTS"...
1.18! # ADD CPP /n.../GX /Zd /O2 /Ob2 /D..."AVISYNTH_C_EXPORTS"...
1.19! # ADD CPP /n.../GX /Zd /O2 /Oy- /Ob2 /D..."AVISYNTH_C_EXPORTS"...

1.13! # SUBTRACT CPP /Z<none>
1.14-

/Zi Debug Program Database
/Zd Line numbers only
/Oy- Optimize Frame Pointer omission (don't!)

1.1 27 Nov 2003 restructured
1.6 08 Jan 2004 change /D "AVISYNTH_EXPORTS" --> /D "AVISYNTH_C_EXPORTS"
1.13 28 Jan 2004 delete /Zi
add subtract /Z
1.14 22 Feb 2004 delete subtract /Z
1.17 17 Jun 2004 add /Zi
1.18 05 Jul 2004 change /Zi --> /Zd
1.19 12 Aug 2004 add /Oy-The only effective optimiser change was my /Oy- suggestion. The other changes, "AVISYNTH_C_EXPORTS" in January and the various /Zi /Zd debug info changes I can't see having an effect. I am starting to look for other systematic changes made.

IanB :(

[Fizick]

... break plugins.
Yes, it is true for DeSpot.

[sh0dan]

Originally posted by IanB
[...]The only effective optimiser change was my /Oy- suggestion.
.. But that one broke the conditional filters (August 17th binary).

I think we'll have to live with the Resizer/ColorYUV crashing instead of reporting the correct error. At least until 2.55 is out the door.

[esby]

btw, since we are about compiler & performance setting,
what would be the performance impact to compile with rtti enabled actually?

esby

[DDogg]

Not complaining, but just wanted to mention that the speed of encoding the simple test script below is slower using AviSynth_200804 than with 2.54. Using 2.55 gives 1.763 RT and 2.54 shows 1.994. I'll try to do a comparison using a real source when time allows.

#start of CCESpeedTest01.avs
ColorBars (720,480)
ShowSMPTE(24)
converttoyuy2()
#end

[sh0dan]

@DDog: As you might have noticed we are struggling with optimizer errors. RC2 had most optimizations disabled, but broke plugins. So we are choosing the "lesser of two evils" in RC3 optimizations are reenabled.

RC3 released - nothing major:
- Reenabled optimizations. RC2 broke plugins.
- Fixed duplicated line in resize+crop operations (beta regression)


Test, test and test! :)

[LigH]

Another bug report for RC2 by user 'doxville' (he just registered here and is not yet able to post, so he is afraid that this bug is not seen before "release"):
AVISource("D:\capture.avi")
converttoYV12()
FadeIO(25)
deen()
Using deen_25_dll_20030119:

Without "FadeIO(25)", VirtualDub and MPC immediately crash without any message.

Using deen_25_dll_20030813:

Without "FadeIO(25)", an error message (http://forum.gleitz.info/attachment.php?attachmentid=68300) appears.

We know that Deen is ... well, a bit sensible. But at least, without parameters, it shall have been useable. More details, if you understand german, in this thread (http://forum.gleitz.info/showthread.php?t=15585).
__

Oh, sh0dan posted RC3 just while I was writing this - be sure he will check this issue with RC3 soon!

[sh0dan]

@LigH: Simultanious post ;)

Try RC3 - it might have a better impact in Deen. :)

[IanB]

@sh0dan,

I hesitate to suggest such a ham fisted solution but it may get us out of the bind. :sly:

As part of tracking down what was happening I encased everything intry {
...<stuff>...
}
catch (...) {
throw;
}so I had markers to breakpoint while debugging the optimised (scrambled) release code. It is effectivly a no-op but it did cause the compiler to emit the missing code (which of course defeated my debugging attempt :mad: )

There are of course no guarantees, I have a tame zoo of only 2 reproducable cases and it hides the bug in both. What do you think?

IanB :(

[DDogg]

As you might have noticed we are struggling with optimizer errors. Yep, knew that, but I would rather err toward redundant/useless info rather than not providing something that might have helped provide a clue.

Anyway, the RC3 build brought the speed back equivalent to 2.54 as I gather you expected. Thanks.

[FuPP]

Not sure this is the right place to post this but I experience a crash (in virtualdub for instance) with these lines. Is this a normal behaviour, is this a syntax problem, or does it show something going wrong ?

LoadPlugin("D:\video\avsfilters\yv12\DGdecode.dll")
mpeg2source("E:\tests\test.d2v",idct=6)
converttorgb24()
bilinearresize(576,432)
trim(30000,30100)

global debut=0

test()

function test(clip c)
{
debut=debut+1
return debut==10 ? c : test(c)
}

[You Know]

RC3
- Fixed duplicated line in resize+crop operations (beta regression)


beta 2 and RC2 function Resize

YV12 space

XXXResize(700, 398)

very dangerous color layer shift from Luma Layer see HERE (wwwstud.dsi.unive.it/~nfalco/doom9/YV12cs.jpg)

XXXResize(702, 398)
XXXResize(706, 398)

ecc ecc (not all value) -> Envaluare: Unrecognized error

[Wilbert]

@Shodan,

I removed the MS pics again (i can't put it in a table and put text next to it). They might be usefull though if we add it to sourceforge.

I got a few questions:

1) How does YV12 progressive/interlaced upsampling to YUY2 work?

2) How does YUY2 upsampling to 4:4:4 YUV work? Are the missing chroma samples (of the even pixels) averaged from the odd ones next it?

Or is it using this cubic convolution interpolation for (1) and (2), as in

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/YUVFormats.asp

3) What does FixBrokenChromaUpsampling exactly do (which samples is it replacing)?

Totally unrelated:

4) Did you already finished this filter:

http://forum.doom9.org/showthread.php?s=&threadid=81191

It would be nice if it is finished before the v2.55 release :)

[Manao]

You know : the chroma shifting is not created by avisynth, but by XviD's YV12 decoder. The bug was fixed in XviD beta 2 or 3, but came back with the XviD RCs.

[You Know]

Originally posted by Manao
You know : the chroma shifting is not created by avisynth, but by XviD's YV12 decoder. The bug was fixed in XviD beta 2 or 3, but came back with the XviD RCs.

i do not understand why you speak about xvid (i have 1.0.1) but img is taken after load avs script from virtual dub mod (are not take from compressed video)

[Manao]

Virtual dub is using XviD decoder to understand how to process YV12 raw data. Without it, you can't use an avisynth script that is outputting YV12 with virtual dub.

Do the following test to convince you that this decoder is really the culprit : Do a resize to 700x398, load it in virtual dub : it doesn't work ( chroma shift ). Now, do the same resize, and add a "Addborders(4,0,0,0)" at the end of the script : no chroma shifting. So inside avisynth, the result of the resize is correct.

[sh0dan]

Originally posted by Wilbert
1) How does YV12 progressive/interlaced upsampling to YUY2 work?

YUY2 to RGB is sampled by interpolating the missing chroma horizontally. (50/50 on each side of the missing pixel)

RGB to YUY2 has two modes. Default mode is using a 1-2-1 kernel to interpolate chroma. There is also ConvertBackToYUY2 which only uses chroma in the leftmost pixel - this can be used to avoid a half-pixel chroma drift to the left on multiple conversions.

2) How does YUY2 upsampling to 4:4:4 YUV work? Are the missing chroma samples (of the even pixels) averaged from the odd ones next it?
Where? The only place we have 4:4:4 is inside Overlay().


3) What does FixBrokenChromaUpsampling exactly do (which samples is it replacing)?

It is simply swapping the chroma samples to their correct lines.


4) Did you already finished this filter:

No - I have had no time to look at it at all.

[Wilbert]

YUY2 to RGB is sampled by interpolating the missing chroma horizontally. (50/50 on each side of the missing pixel)

RGB to YUY2 has two modes. Default mode is using a 1-2-1 kernel to interpolate chroma. There is also ConvertBackToYUY2 which only uses chroma in the leftmost pixel - this can be used to avoid a half-pixel chroma drift to the left on multiple conversions.
Ok, I understand that.

I'm still confused about YV12->YUY2 and FixBrokenChromaUpsampling though.

If I understand it correctly:

YV12 (progressive) -> YUY2:
* odd chroma lines are just copied.
* even chroma lines (2n) are the average of the lines 2n-1 and 2n+1.

YV12 (interlaced) -> YUY2:
* chroma lines (n) are the average of the lines n-2 and n+2 (alternating a 75-25 average).

How does FixBrokenChromaUpsampling attempt to correct this (ie interlaced YV12 upsampled progressively) by just swapping chroma samples? I must be missing something obvious :confused:

No - I have had no time to look at it at all.
I will make an unoptimized version myself :)

[tritical]

YV12 (progressive) -> YUY2:
* Uses alternating 75/25 25/75 averages of nearest chroma samples

YV12 (interlaced) -> YUY2:
* Is also using alternating 75/25 25/75 averages, but of the nearest chroma samples from the correct field

The above weights are from the mpeg2 specs (based off mpeg2 chroma placement)... I'm guessing yv12(interlaced)->yuy2 is using 75/25 for speed in isse instead of using 7/8,1/8 3/8,5/8 averages, which are what the samplings would suggest?

[IanB]

Originally posted by Wilbert
How does FixBrokenChromaUpsampling attempt to correct this (ie interlaced YV12 upsampled progressively) by just swapping chroma samples? I must be missing something obvious :confused:

"The MS DV codec upsamples the chroma channels incorrectly", this filter repairs that fault. Nothing specificaly to do with other upsampling errors.

For each group of 4 lines it swaps the chroma of the middle 2.1 --> 1
2 \/> 3
3 /\> 2
4 --> 4
5 --> 5
6 \/> 7
7 /\> 6
8 --> 8IanB

[Mug Funky]

hmm... ImageSequence.dll is crashing VDM. i hear of this happening quite a lot, but this is the first time i've been hit with the problem. is there a painfully simple solution (apart from moving this file out of the plugins directory?)

[esby]

Am I wrong, or was imagesequence (or an equivalent plugin) put in the core already?
-> imageReader() and imageWriter()?

esby

[Mug Funky]

that's what i'd thought... maybe that dll has been in my plugins directory for a very long time now...

[Fizick]

BTW, there are 3 different Avisynth.h files in released 2.55 source.
What is the best? :)
The last?

[IanB]

Originally posted by Fizick
BTW, there are 3 different Avisynth.h files in released 2.55 source.I assume you mean the following 3 :-

./avisynth/src/core/avisynth.h
./avisynth/src/plugins/DirectShowSource/avisynth.h
./avisynth/src/plugins/TCPDeliver/avisynth.h

The 1st is the one used to build the current avisynth.dll, so should be used to build new plugins (i.e. ones that want 2.55 exclusive features).

However if you desire backwards compatibility (say for 2.53 or 2.54) you should use the avisynth.h published at that time.

The 2 included with the plugins above are the previous version for that reason.

See http://cvs.sourceforge.net/viewcvs.py/avisynth2/avisynth/src/core/avisynth.h for the CVS history.

IanB

[Fizick]

I.e. if I will use avisynth.h from 2.55 source for my plugin build,
it will not work in Avisynth 2.54 ? :confused:

[IanB]

Originally posted by Fizick
I.e. if I will use avisynth.h from 2.55 source for my plugin build,
it will not work in Avisynth 2.54 ? :confused: Not quite. If you use features only available from 2.55 then expect unpredictable behaviour (crashes) in earlier versions.

By using the older avisynth.h the compiler protects you from yourself, if the features not defined then you cannot use it.

This is why changing avisynth.h requires so much thought and care. It is to maintain compatibility.

IanB

[Kintaro]

blur() is causing instant crashes on yv12 clips with width >=16

[IanB]

Your script please.

Edit: Don't bother, I take you mean width <= 16.

Problem is MMX code needs mod 8 pitch for loops.

Chroma width = 0.5 x Luma width so causes pitch <= 8 and hence crashes.

Workaround :- AddBorders and Crop

I'll fix the code and CVS it.

IanB

[esby]

To answer a bit more about "features only available from 2.55 then expect unpredictable behaviour (crashes) in earlier versions."

This is not totally unpredictable, but very predictable on some situation from what I tested while playing with dsynth.

The main problem about using new method, is that if you call them on an instance of an object that does not have the method, you'll got a crash, via a pure virtual function call (call to a method that does not exist).

For example dsynth redefines IClip and add some method.
for example CanDirectStreamVideo().
While there is no problem when calling internal filters with it, since they'll be defined with it, external filter, not based on dsynth will generate crash (pvfc).

Now the reverse approach, if you build a filter using the dsynth avisynth.h,
and if you try to load it with the normal avisynth, it will not load, since the version returned is different.
Supposing that you hack back the version reply, and have it loaded,
if a normal method of this filter is called, the execution will be carried out, as long these methods do not try to call any new methods on a child object. And if such child are normal object, you'll get pvfc again.

Now, if you call method that have been changed...
depending the way they were declared, the old version might be called (let's say a bugged one), and the new version may be called in some other case too. Which may result in unpredictable cases. Almost I am not myself sure of it, I will probably retest it tomorrow.

So, as IanB said, if your filter does not uses new function or method, it will probably load and work correctly, in the reverse case, expect non correct result as best, and crashes in most case.

esby

PS: Of course, you can say 'i will detect differences, and not call non existing method if the object are not the same type, but here the problem is that you don't have rtti enabled, so you can't really check the type back. But I believe you may detect it in a way or an other, if you know what to check for, and thus, avoid pvfc or erratic comportment on some specific part.