AviSynth 2.6.0 RC1 [Jan 14th, 2015]

[StainlessS]

Dont know about ConvertAudio, but you could take a peek at Waveform by DavidHorman, better than AudioGraph.
http://forum.doom9.org/showthread.php?t=165703

EDIT: Not sure, think you may have had to include Internal.h for the ConvertAudio stuff.

[Wilbert]

and wondering by what the shortly removed ConvertAudio reference in the AviSynth.h header might have been replaced, as I find no documentation in the AviSynth26RC1 package, and also forum search with keyword 'ConvertAudio' gives no clue.

You need to add either convertaudio.h/convertaudio.cpp to your project or use Invoke:

  AVSValue cache_args[1] = { _clip };
  PClip ok_clip = env->Invoke("ConvertAudioToFloat", AVSValue(cache_args,1)).AsClip();

[martin53]

Thank you for the support. I must admit that FilterSDK/GettingStartedWithAudio even says "... It'll require you to include ConvertAudio.cpp ... " but I skipped that and it was just too unexpected one has to include AviSynth source.

[Wilbert]

Thank you for the support. I must admit that FilterSDK/GettingStartedWithAudio even says "... It'll require you to include ConvertAudio.cpp ... " but I skipped that and it was just too unexpected one has to include AviSynth source.

Yes it says so. The proper way is to use Invoke to convert the audio (then you don't need to include any source file). I will change that.

[burfadel]

Are any of the changes in Avisynth+ (MT-r1689) included in this Avisynth? It would make sense to merge the two. I realise that Avisynth+ (MT-r1689) is a third party offshoot, but it does work well!

[Wilbert]

Are any of the changes in Avisynth+ (MT-r1689) included in this Avisynth? It would make sense to merge the two.

I can't answer that. Will ask Ian about his plans.

[burfadel]

Originally Posted by Wilbert

I can't answer that. Will ask Ian about his plans.

Thanks!

[martin53]

Originally Posted by Wilbert

Yes it says so. The proper way is to use Invoke to convert the audio (then you don't need to include any source file). I will change that.

Currently, the code is

	if (vi.HasAudio()) {
		child->SetCacheHints(CACHE_AUDIO, 4096 * 1024);
		PClip aud_clip = ConvertAudio::Create(child, SAMPLE_INT16, SAMPLE_INT16);
	}

can you please point out the correct Invoke code for me once? I don't think I understand how to replace the above code yet.

I think it should be

	if (vi.HasAudio()) {
		child->SetCacheHints(CACHE_AUDIO, 4096 * 1024);
		AVSValue invoke_args[1] = { child };
		PClip aud_clip = env->Invoke("ConvertAudioTo16bit", AVSValue(invoke_args,1)).AsClip();
	}

in my case - but the cache code? and is '_clip' from your post #22 'child' here?

[StainlessS]

Looks ok to me but, what do I know

From docs

Invoke throws IScriptEnvironment :: NotFound if it can't find a matching function prototype.
You should be prepared to catch this unless you know that the function exists and will accept the given arguments.

A few examples (grabbed from MipSmooth - it uses invoke a lot):

try {
    AVSValue args[1] = { child };
    PClip reduced = env->Invoke("Reduceby2",AVSValue(args,1)).AsClip();
} catch (IScriptEnvironment::NotFound) {
    env->ThrowError("MyFilterError: Whoa! Could not Invoke reduce!");
}

ConvertAudio available since v2.5 so try/catch not an issue.

EDIT: On cache, I guess it provides a sensible default, Wilbert seemed to suggest invoke did not require it.
Give it a whirl.

EDIT: I think you will have to make a copy of vi, and copy contents over into it, and then update the audio related stuff.
There might be some weird stuff related to cache that you have to handle for following filters.
EDIT: Although in Prune(), I did not copy vi, just update contents of vi with eg

	vi.num_frames=OutFrameCount;					           // New Length of Output clip in Video Frames
	vi.num_audio_samples=vi.AudioSamplesFromFrames(OutFrameCount);		// New number of Audio Samples

[StainlessS]

M53, this seems to work ok, not much testing, does conversion before calling constructor, and just passes everything through untouched.

#include <windows.h>
#include "avisynth.h"

class audiotest : public GenericVideoFilter {   
public:
    audiotest(PClip _child,IScriptEnvironment* env);
    //    just pass it on using default audio handler of the ConvertAudioTo16bit filter
    //    void __stdcall GetAudio(void* buf, __int64 start, __int64 count, IScriptEnvironment* env);
    ~audiotest(){};
};

audiotest::audiotest(PClip _child,IScriptEnvironment* env) : GenericVideoFilter(_child) {
    // if(!vi.HasAudio()) env->ThrowError("audiotest: requires Audio"); // we already know it has audio
}

//void __stdcall audiotest::GetAudio(void* buf, __int64 start, __int64 count, IScriptEnvironment* env) {
//  start and count are in multichannel samples, and 'start' is beginning of requested output samples to store @ buf.
//    child->GetAudio(buf, start, count, env);
//}

AVSValue __cdecl Create_audiotest(AVSValue args, void* user_data, IScriptEnvironment* env) {
    PClip child   = args[0].AsClip();
    const VideoInfo &vi = child->GetVideoInfo();
    AVSValue ret;
    if (vi.HasAudio()) {
        // child->SetCacheHints(CACHE_AUDIO, 4096 * 1024);
        AVSValue invoke_args[1] = { child };
        PClip new_clip = env->Invoke("ConvertAudioTo16bit", AVSValue(invoke_args,1)).AsClip();
        new_clip->SetCacheHints(CACHE_AUDIO, 4096 * 1024);
        ret = new audiotest(new_clip,env);
    } else {
        ret = child;        // return original untouched
    }
    return ret;
}

extern "C" __declspec(dllexport) const char* __stdcall AvisynthPluginInit2(IScriptEnvironment* env) {
    env->AddFunction("audiotest", "c", Create_audiotest, 0);
    return "`audiotest' audiotest plugin";
}

EDIT: Line in blue added, not sure if in correct position, or should it be purple ?

[Wilbert]

EDIT: On cache, I guess it provides a sensible default, Wilbert seemed to suggest invoke did not require it.
Give it a whirl.

No, not on purpose. env->Invoke does not automatically insert a cache after the filter you invoke, so martin53's plugin might benefit a cache (can't see what his plugin is doing though).

[StainlessS]

There is some good stuff here on Cache:- http://forum.doom9.org/showthread.ph...50#post1595750

And presumably the line in blue two posts ahead is OKEY-DOKEY (and not on child before Invoke).

[martin53]

Thanks to you both. Will publish the 1st version now, I think it is good although I haven't performed significant tests on cache alternatives. But I don't experience peculiar slowness, either.

[StainlessS]

Small prob in colors_rgb.avsi,

global color_palegoldenrod          = $EEE8AA
global color_palegoldenrod          = $EEE8AA

Color occurs twice in file (have checked by extracting installer, not just my copy).

[Wilbert]

Color occurs twice in file (have checked by extracting installer, not just my copy).

Fixed it. Thanks.

[ultim]

Hi,

Among the changes in RC1, many ints in the public interface have been changed to size_ts, in a process to prepare for a 64-bit version. I would like to ask you to reconsider that, and revert those changes. The reason is, even though "official" AviSynth has never before supported x64, there are still a relatively large number of 64-bit plugins. These have existed for a long time, long before AviSynth+ (and some more sprouted after Avs+). These changes break all those plugins. Worse, these changes break those plugins without any real benefit. Changing frame offsets and datasizes to size_t, these can now hold values larger than 2GBs in 64-bit mode, but what video has a plane (or frame) size of 2GB? To summarize, I don't think these changes bring real value, but they necessitate the recompilation of all existing x64 plugins. Please consider reverting these changes.

[TheFluff]

I'm pretty sure those changes are necessary for VapourSynth interoperability, though! (VS uses separate pointers for the planes instead of storing offsets.)

Originally Posted by ultim

there are still a relatively large number of 64-bit plugins

[citation needed]

I'm also pretty sure the quality of the porting of most of the x64 plugins that actually do exist is rather low (and by that I mean someone just commented out everything that didn't work).

[ultim]

Originally Posted by TheFluff

I'm pretty sure those changes are necessary for VapourSynth interoperability, though! (VS uses separate pointers for the planes instead of storing offsets.)

So the x64 rc1 broke all its own plugins just so they can be also loaded in a completely different system if they are ever recompiled?

Originally Posted by TheFluff

there are still a relatively large number of 64-bit plugins
[citation needed]

No problem: [1], [2], [3], [4], [5], [6]

Edit: Added 6th link. This one is archive.org, but all the download links still work if you copy them.

[real.finder]

I note that some filters that work yv12 work also with yv411 but with Garbage chroma like TFM() or both luma and chroma, Is this ok?

[StainlessS]

Not sure what you are saying there but I'll take a guess.
I'm guessing that you have only just tried out v2.6 for the first time.
v2.5 filters (compiled with v2.5 Avisynth.h version 3) cannot tell the difference between YV12 and other planar formats.
If processing eg YV24 then the header used would give chroma rowsize and height as if for YV12, and the returned
chroma might appear only in the Top Left Hand side quarter of the frame, the rest of the frame may (or may not) contain
garbage chroma EDIT: 3/4 garbage chroma depends upon whether plugin does 'in-place' changes or creates new
chroma plane (garbage).
You can only use v2.6 planar compatible plugins with Avisynth v2.6 additional colorspaces.