Reading video frames via avisynth.h/dll, some questions to developers

[jonny]

I'm writing an encoder and i'm making experiments reading the frames directly via avisynth.dll (and of course using avisynth.h).

I manually create the BITMAPINFOHEADER structure as is expected to be returned by AVIStreamReadFormat (A)

I manually pack the frames as is expected to be returned via AVIStreamRead (B)


1 - Is there a better way to make (A) & (B) (using the classes exported by the dll)?

2 - Are there risks that things are broken after a new AviSynth version came out (atm i was thinking to compile 2 versions, one for the avs2.0x family and one for the avs2.5x family)?

Many thanks in advance.
jonny

PS: and many thanks for the great work!

[sh0dan]

Wouldn't the easiest way be to use the VFW interface?

There is not much speed to be gained from accessing frames directly, if anything at all.

What are you planning to do, that makes rebuilds necessary?

[jonny]

Wouldn't the easiest way be to use the VFW interface?

I already do this, but i'm making some experiments with avisynth.dll too.

What are you planning to do, that makes rebuilds necessary?

So the answer of 2 is yes, isn't it?

[sh0dan]

It's a bit hard to answer, when I don't know what you're thinking of, that's all. ;)

All I can say is "probably not" - but bugs get found all the time -unfortunately. ;)

[jonny]

I see, thanks for the answer (probably going with vfw will give me less trouble ... i hope :))

[sh0dan]

At least, that's what we "guarantee" will work.

Memory is shared between AviSynth and the client application, so you're only at best avoiding one bitblit, which is insignificant, when comparing it to what else is going on.

VFW itself has only a very small impact.

[jonny]

Yep, my target was better code, not mainly speed gain.
The code for the avisynth way is more compact and readable imo, and i like it more than the vfw version (i know, it's a strange explanation :))

[sh0dan]

Oh now I see what you're getting at.

The best way would probably be for your app. to act as a plugin, and append itself as the last filter in the filter chain. That way you have access to all the needed functions, and you are able to request all the frames you need without going through VFW.

This isn't currently possible in all cases (a return statement would destroy that ability for instance), but it would be a nice addition to the current fucntionality.

I'll have to consider this a bit more, for a possible solution.
But opening a script and thereafter applying a filter right before the video is delivered by vfw would be nice.

[jonny]

Let me know if i've got the idea.

I should write a plugin, something like this:

encode(codec_fcc,codec_data,output_file)

codec_fcc = fcc of the codec to use
codec_data = codec configuration encoded in exadecimal (for ICSetState, are there problems if the string is too long?)
output_file = file to write (for example in avi format)

I append this function at the end of the script.
After this, opening the script (with an external frontend program) will start the encoding (something like Nic's mpeg2decoder & the d2v file generation).

For the "return" or "end" problem, a solution could be using another script:

AVISource("myclip.avs")
encode(...)

have i got your idea?

[Richard Berg]

The best way would probably be for your app. to act as a plugin, and append itself as the last filter in the filter chain. That way you have access to all the needed functions, and you are able to request all the frames you need without going through VFW.

This isn't currently possible in all cases (a return statement would destroy that ability for instance), but it would be a nice addition to the current fucntionality.
What also might work is passing the desired script to Invoke -- you get the frames as needed and can also access internal AVS functions.

[Dark-Cracker]

@Richard

How could we get the result of a frame if we want to add it the "tweak" filter (for the color) it could be used to made a preview on the change color on the fly. by passing the .avs file and the filter settings at the avisynth.dll this could add the possibility to made preview on the fly for each avisynth filter.

Thx,
Bye.

[jonny]

If this can help i've taken (the starting thread idea) from http://christophe.paris.free.fr/temp/axenc000.zip (by [Toff], released in the avs2avi thread here: http://forum.doom9.org/showthread.php?s=&threadid=36768&perpage=20&pagenumber=12)

[Richard Berg]

Originally posted by Dark-Cracker
@Richard

How could we get the result of a frame if we want to add it the "tweak" filter (for the color) it could be used to made a preview on the change color on the fly. by passing the .avs file and the filter settings at the avisynth.dll this could add the possibility to made preview on the fly for each avisynth filter.

Thx,
Bye.
Assuming I understand you correctly: you can call Invoke() a second time, passing as arguments Tweak + the frame returned from Invoke-ing the original script.

I did something similar, for example, when I made an http server application that needed to call different ConvertTo[colorspace] commands at runtime (i.e., after executing a given script).

[ErMaC]

This kind of interface directly to AVISynth.dll will be important in the future if/when AVISynth starts doing things that VFW can't handle, like VFR :P
I think this would be a good test case to see if it's possible to bypass the whole VFW interface in an application that accesses AVS files.

[Richard Berg]

I agree: direct control is much more powerful. Which is why I think we need to wrap the ScriptEnvironment interface in something a little more flexible like a COM component or OCX container -- right now, calling avisynth.dll directly will break with just about any version that's not linked against the exact same .lib file.

[jonny]

Something like this will be marvellous!
(and will potentially open new ways to work with AviSynth ;))

[Belgabor]

Originally posted by Richard Berg
I agree: direct control is much more powerful. Which is why I think we need to wrap the ScriptEnvironment interface in something a little more flexible like a COM component or OCX container -- right now, calling avisynth.dll directly will break with just about any version that's not linked against the exact same .lib file.
Not that I don't agree with the wrapping, but that last argument is not true, just use it dynamically via LoadLibrary :)
At least thats the way I do it in VDubMod for the version info (which works with ALL AviSynth versions [at least those I could get my hands on ;)]).

Cheers
Belgabor

[Nic]

OT: Oh, I see from the code how you get the avisynth version...interesting :) I was doing it by getting the DLL's VersionInfo resource for my dvd2avi. I wonder if I should change it to your way....hmmm

-Nic

[DoC hEx]

Hi,

I’m looking for something like the COM/OCX talked about above, as I want to create a DLL that will load an AVS script file and then upon request return the requested frame in an RGB format, like the way MPEG2DEC.dll does it, i.e. a long series of colours, to the calling program.

So I was wondering if OCX talked about will be developed by the AVS crew?

[Bidoche]

COM interfaces are supposed to be created for 3.0, but it'll have to wait. It will probably still missing in the first alphas.
Personally, I don't intend to put some work into it before then, but if anybody else wants to put some thought into it, he'll be very welcome.

For OCX, I just don't know. (What is OCX anyway ;p)

[DoC hEx]

Thanks for the Info, it wasn't till after I posted this did I read the topic on "News V3.0".

OCX, I think it’s just an old name for ActiveX, although I don't know if that might now be called 'COM' as they're always changing the name to jump onto some new marketing hype.