View Full Version : Most important new feature
sh0dan
15th May 2003, 12:06
While we're still bugfixing AviSynth 2.5 to make it ready for non-beta state I would like the hear the community opinion on the "most important features".
New layer routines for YV12.
A rewritten layer function for YV12, which should be both faster and easier to use.
A 4:4:4 (non-subsampled) planar image format.
Introduce a new image format, that doesn't subsample chroma, but has same resolution in chroma as luma.
Enhance audio functions.
Go through all audio functions and ensure they operate as they should, and implement new functions for better support. This should also include a float-precision resampler.
Improve memory management.
Attempt to minimize the current memory usage.
DScaler plugin support.
See thread (http://forum.doom9.org/showthread.php?s=&threadid=51689) in the development section.
YV12 support for third party filter (write which one).
The source must of course be avavilable for the plugin. Be sure to link to the source if no-one else has already done so.
More documentation.
Work more intensely on documentation.
Other (write below).
Minor issues and bugfixes does not apply here - we are talking big picture here. Improvements in specific sections are ok.
Oh dear.. I don't know which to choose.. 4:4:4 YUV or YUV layer...
Wilbert
15th May 2003, 12:21
I voted for "Enhance audio functions". One of the reasons is that it is still not possible to do proper PAL2NTSC/NTSC2PAL conversions.
But I also would like to see "New layer routines for YV12", and mask working in a YUV format :) IIRC, the idea was to use the 4:4:4 image format for this.
Originally posted by sh0dan
A 4:4:4 (non-subsampled) planar image format.
Introduce a new image format, that doesn't subsample chroma, but has same resolution in chroma as luma.
Would this be of any use to the general user regarding video encoding? Faster? Like YV12 is for YUY2?
Acaila
15th May 2003, 12:36
Ok here's what I think:
New layer routines for YV12.
Sounds great, but I hardly ever use layer anyway (because it appears to be quite complicated). This doesn't mean I might not start using it someday though... :)
A 4:4:4 (non-subsampled) planar image format.
Since no codec that I know of can output 4:4:4 format, I believe this would only help internal accuracy in filtering. Maybe that's easier to work with as a developer, but speaking as a user I think the current way is good enough.
Enhance audio functions.
I never use audio in Avisynth, so I couldn't care less.
Improve memory management.
Great, the less memory it consumes the better. Currently I'm only limited to doing 'easy' tasks when something is encoding. And my system isn't super stable, so it tends to reboot when I stress memory/disc access during encoding :D. Which sucks, but is probably no fault of Avisynth, I admit.
DScaler plugin support.
Don't know what to do with them, because I've never used DScaler before. Are there (useful) plugins there that don't have an Avisynth equivalent yet?
YV12 support for third party filter (write which one).
Can't really think of anything out of the top of my head, except maybe the Wavelet Noise Reduction filter. But since the source isn't available that wouldn't be possible :(.
More documentation.
IMO the documentation is fine as it is (great job btw).
Actually I'm quite satisfied with the way Avisynth is currently working. But if I had to choose I'd go for the memory optimizations.
Hmmm, now that I think of it, I'd actually like something not on this list at all. An YUV colorspace with alpha. Come to think of it, "AYUV" is a 4:4:4 YUV colorspace, with alpha :D. So I'll go for that. Being able to use Mask+Layer in YUV would be awesome.
Defiler
15th May 2003, 13:42
I'd definitely like to see Avisynth become a more powerful tool for working with audio.
hakko504
15th May 2003, 13:47
Originally posted by mf
Hmmm, now that I think of it, I'd actually like something not on this list at all. An YUV colorspace with alpha. Come to think of it, "AYUV" is a 4:4:4 YUV colorspace, with alpha :D. So I'll go for that. Being able to use Mask+Layer in YUV would be awesome. I'm with mf on this one. That could be really powerful
Sigma9
15th May 2003, 15:01
Hi everybody
I have the feeling its time to say AVS is great in the state is is right now. Bugs are in every software, however here the response and correction time is orders of magnitude faster than in most other cases. Thus tx to all developers and sh0dan in particular.
When I start thinking in which area I "waste" most of my time when using AVS, it is actually in typing the scripts, get rid of typos, look up the filter-you-want, check its use and parameters...
So with that in mind I would love to have something which reduces this kind of everyday problems (or maybe my head is just too small to remember all those things or maybe I am too lazy to save and document my proven scripts :p ...), which could be
1. a good GUI (I know this has many disadvantages which mainly boil down to the fact that a GUI reduces the real power of a full script language)
2. a context-sensitve help system (or s.th. similar) including proven script templates. Sure it is possible to come to doom9 and look up the NTSC->PAL conversion when you first time have to do it. However, it is time consuming and even sometimes misleading...
3. an improved error-reporting system
I know these are mostly dreams and there is a lot of work realizing these. Still, I have the feeling I would not be the only one who would benefit.
What I would _not_ go for is audio stuff. AVSs real strength is in video processing, and I dont think it is a good idea to re-invent the wheel concerning audio - there are very many and very good processors out there, and moreover this field is floating (especially at this moment, see 5.1, 6.1, 7.1, ...), so whatever efford would be put into AVS could be old fashioned or even bad half a year later.
What I would appreciate, though, is kind of a standard interface to an audio processor (e.g., BeSweet) - this way one could in the future always benefit immediately from the great work of these folks.
Summary: 98% satisfied with the status quo, some dreams listed.
/Sigma9
Wilbert
15th May 2003, 15:15
What I would appreciate, though, is kind of a standard interface to an audio processor (e.g., BeSweet) - this way one could in the future always benefit immediately from the great work of these folks.
Oh, I forgot about this one. I would really be cool if we could do the following [just an example]:
# requires compressed audio pass through
LoadPlugin(besweet.dll)
video = avisource(..).filters
audio = some besweet command line you want to use on a dts/ac3/5.1wav/or whatever
audiodub(video,audio)
Then, set the audio in vdubmod on "direct stream copy" and voila.
Another point. Soon it will be possible to capture (in vdubmod) directly to matroska. A MKVSource would also be nice :)
sh0dan
15th May 2003, 15:40
Originally posted by mf
Hmmm, now that I think of it, I'd actually like something not on this list at all. An YUV colorspace with alpha. Come to think of it, "AYUV" is a 4:4:4 YUV colorspace, with alpha :D. So I'll go for that. Being able to use Mask+Layer in YUV would be awesome.
The most sensible (and generic way) would be to use luma from another clip as alpha - IMO it is very silly to have to use a channel you are not able to see (in RGB32). Specifying a luma channel as mask would make this considerably easier - and would also make it work on YV12. It would also make it possible to use all internal functions to create the mask. This would be a part of the redesigned YV12-Layer.
Regarding your earlier post: 4:4:4 is primarily for internal filtering precision as you point out - it would be a YUV alternative to RGB.
But of course it would always have to be converted before it can be outputted.
@Wilbert: I don't think compressed audio support would be possible within the current framework - unfortunately. However, exporting audio, or using besweet funtions for processing _might_ be possible however.
@Bach: Great - thanks for the links!
stax76
15th May 2003, 15:52
I wish there would be better scripting possibilities, things like if, else etc.
1. a good GUI (I know this has many disadvantages which mainly boil down to the fact that a GUI reduces the real power of a full script language)
there are already a couple of gui approaches, didn't you test or don't you like 'em? In case you don't like 'em you could make a suggestion how a application could look like. Doom9 lately did for a DVD -> MPEG4 tool or DDogg lately for a BeSweet GUI or you could make some suggestions for existing applications
Defiler
15th May 2003, 15:59
Originally posted by Wilbert
LoadPlugin(besweet.dll)
video = avisource(..).filters
audio = some besweet command line you want to use on a dts/ac3/5.1wav/or whatever
audiodub(video,audio)
Then, set the audio in vdubmod on "direct stream copy" and voila.
Oh my God that would be awesome. Seconded.
DSPguru
15th May 2003, 16:57
yes, it's really about time to see BeSynth :D !
there's a lot info in here (http://forum.doom9.org/showthread.php?s=&threadid=22590), and the dll is almost bugless.
see how powerful azidts v0.1 is by just using BeSweet.dll :)
WarpEnterprises
15th May 2003, 17:01
I vote for the functional completion of the internal routines,
that is (new) layer routines for YV12 and (enhanced) audio functions.
Please, please,please not again another image format!
Some way of "exporting" filter properties to editors,... to help those GUI's would be nice (as has started somehow already?)
About alpha-channel: at least for development it's nice to get the alpha channel together with the colors without having to worry about pitches, formats,...
But maybe we could stay with alpha for RGB and use a seperate clip for YUY2 and YV12 in the Layer functions.
What still is not completely checked is how RGB32 filters treat the alpha channel...
sh0dan
15th May 2003, 17:15
@WarpE: I will not change how Layer works - I will add all new code to a new function - so the current RGB32 code is safe. :)
A 4:4:4 YUV is pretty close to YV12, and 90% of all filters will have no problems dealing with it. The only filters that will be affected is those, where luma and chroma interact (most notably deinterlacers). Otherwise there work is mostly related to creating converters.
@DSPGuru: Agree!
Regarding GUI's. AviSynth will (probably) never be a GUI app - however I have thought of opening a "console", where warnings, errors and debug information could be.
Unarmed
16th May 2003, 02:15
I really have just one issue with AviSynth, currently - the fact that 2.5 cannot natively load plugins for older versions. Even if this were split off into a separate function - say, "LoadLegacyPlugin()" - I would be much happier.
I realize there are ways to get 2.0x plugins loaded now, but it's too counter-intuitive.
Originally posted by sh0dan
Regarding GUI's. AviSynth will (probably) never be a GUI app - however I have thought of opening a "console", where warnings, errors and debug information could be.
Well it wouldn't be hard to provide a standard way of requesting a filter's function which then either opens a dialog box and passes user-set settings to the application, or passes configurable parameters to the application, which will then create a standard dialog box where these settings can be edited, would it? AVISynth would still retain all its scripting powers, but it'll be just a little bit easier. Plus, as seen in Vdub filters, a settings box with a help button is really nice, so you don't have to go search for the readme in your filters dir ;).
sh0dan
16th May 2003, 12:29
@Unarmed: I'm not doing anything further to support 2.0 plugins - it takes 20 minutes MAX to recompile filters for AviSynth 2.5!
@mf: I'm listing things I'm actually capable of doing - and GUI programming is not one of those. I'd be very happy to help someone willing to take up the challenge, but it's not something I intend to do personally.
Mango Madness
16th May 2003, 15:30
Yes! besynth or the like would be most helpful. I'm very happy with the status quo but with all things, more precision, better optimizations and everything are always welcome. Thanks for all the work from the developers.
Prosper
17th May 2003, 02:58
Originally posted by sh0dan
Regarding GUI's. AviSynth will (probably) never be a GUI app - however I have thought of opening a "console", where warnings, errors and debug information could be.
That's a very cool idea. Opening up an mplayer-esque console to display various stats, real-time info, syntax and other errors.
Still, my vote goes to Audio enhancements
Defiler
17th May 2003, 06:17
Can I change my vote to "Fix the silent crash when refreshing or closing an AVS file in VirtualDubMod"? :D
It's done that to me like 60 times today. Heh.
bobby8798
18th May 2003, 19:17
YV12 support for Smooth Deinterlace would be fantastic
http://home.bip.net/gunnart/video/AVSPorts/SmoothDeinterlacer/
(YUY2 support is available , thanks to neuron2)
I never use audio with avisynth. There are other tools for that.
Paul Langemeijer
25th May 2003, 11:59
first post!...well actually my first post anyway.
my 'other' #1 = when uci specs are done ... ucisynth,
or just al available avisynth filters ported to it :)
my 'other' #2 = a flexible way to define new color-spaces for avisynth...just like yv12 was done, but without the hole new version circus...filters supporting a colorspace could be used right away, others need some conversions first. avisynth should figure the best colorspace out for itself, given the start and return colorspace are known.
my 'other' #3 = audio support. with filters available for different 'audio-spaces' actually just like colorspaces. when i'm using cooledit to filter some audio, it always does a conversion to pcm when loading an mp3. and when using the filters, most of them will start with an fft. that sort of thing is just plain silly.
sh0dan
26th May 2003, 19:19
@bobby8798: Agree - this is a very good deinterlacer, and I've been wanting to do this for some time. It is also a quite complex deinterlacer, so it'll probably take some time.
@Paul Langemeijer: Welcome aboard!
1) What's UCI?
2) Most colorspaces should be fit into AviSynth without breaking compatibility. Automatic colorspace conversion is IMO not an option - a colorspace conversion is too costly both quality and performancewise to do it without user interaction.
3) From 2.5 there is internal support of 8, 16 , 24 and 32 bit integer samples and 32 bit float point samples. Conversion is automatic between filters (as it doesn't have nearly the same impact as video).
Ad 3) Filters supply information about which sample types they support, and the audio is converted automatically to the "prefered" format maintaining as much quality as possible, if the filter doesn't support the input it recieves.
Paul Langemeijer
27th May 2003, 20:51
1) What's UCI?
universal codec interface .... an open source project.
http://uci.sourceforge.net/
2) Most colorspaces should be fit into AviSynth without breaking compatibility. Automatic colorspace conversion is IMO not an option - a colorspace conversion is too costly both quality and performancewise to do it without user interaction.
ok, how about an dumb-user-option that completes an avs-file with al color-conversions and such in it, and saves the avs file ?
the inserted lines should be easily recogniseble. so you can always edit the file again. perhaps an idea for a gui app :)
3) From 2.5 there is internal support of 8, 16 , 24 and 32 bit integer samples and 32 bit float point samples. Conversion is automatic between filters (as it doesn't have nearly the same impact as video).
Ad 3) Filters supply information about which sample types they support, and the audio is converted automatically to the "prefered" format maintaining as much quality as possible, if the filter doesn't support the input it recieves.
what i mean is that i think mp3-compression starts with an fast-fourrier-transform, using a spectrum-like sound representation. most filters, well at least the advanced filters also would start with a fft. so keeping the sound in an frequency representation would seem logic.
sh0dan
1st June 2003, 00:21
Now that 2.5.2 is released we can begin to look at the future. I very much agree with your priorities.
I know that DirectShowSource sound is also quite high on the wish-list - I just forgot about it - probably since I have no idea where to begin.
HarryM
1st June 2003, 07:51
I vote for newer YV12 layer (mainly with support for SSE/SSE2 and Athlon64, etc.) and for enhanced audio functions.
True 4:4:4 color space isn't important for practice.
About GUI,
was there a 'à la' Graphedit approach ever done?
I think filtering chain can be done representating graphedit chain,
especially when using opp avs notation...
for non opp, i think a default branching scheme could be used.
About audio,
I think audio should be processed separately,
unless it is possible to use direct audio streaming on the fly,
but it's the nandub sbc user that speaking here...
An alternate debug log file somewhere could be really useful,
especially when using autoload plugin
and having one of them crashing the avs load without any warning...
The 4:4:4 color space could be a good idea,
some people i know being bitching about the 'too strict' colorspace approach of avs, (saying avs only useful for 'dvd-ripping', I'm quoting them, it's not my opinion here).
About the 'dumb user color space mode':
if it ever done, it should be switchable,
because it forces the user to uses strategy using colorspace,
it's a little the same when comparing java & delphi exception handling
Delphi is very permissive and easy,
but since java is screaming at you at the slighty non catched error,
java might be better to do clean programmation in the end.
(Since you won't forget exceptions to handle)
And for me improving reliability is the best warranty for the avs future, the non bugged software being more important than a fastest but bugged one. :)
esby
DDogg
1st June 2003, 16:09
I know that DirectShowSource sound is also quite high on the wish-list Sh0dan, I know the whole directshow video and audio thing is a pain in your backside, but I certainly think it worthy of continued support as many times it is needed and I would add my request for a more robust and less finicky support of directshowsource for both video and audio.
I really expected for somebody to step up to the plate and offer assistance as you have voiced your need and desire for a directshow expert to assist you several times.
I wonder if you might get more penetration if D9 put your request on the news page? Also, I am curious why the DirectShow skills seem to be hard to find. Is it an unusual or arcane are of programming or just a boring one?
ErMaC
2nd June 2003, 11:33
I would like better AVISynth memory management to help with problems like the one talked about in this thread (http://forum.doom9.org/showthread.php?s=&threadid=51743).
Blankman
2nd June 2003, 15:16
My vote is in. Here's what I think:
New layer routines for YV12
I use this all the time. So it is on the top of my list. Yes!
A 4:4:4 (non-subsampled) planar image format
Nothing I use support it, so I'm indifferent.
Enhance audio functions
Maybe after I can afford to upgrade my 800 MHZ P-III PC-100 system, to a real powerhorse, I'll have enough bandwidth on the bus to frameserver from AVISynth to a Windows Media Player without delay or stutter. Right now it is on the bottom of my list.
Improve memory management
Has not been a problem. But Yes, I would like to be able to run AVISynth as lean as possible.
DScaler plugin support
Using DScaler is not on my radar at this time.
YV12 support for third party filter (write which one)
Don't care.
More documentation
Always room for improvement. Old timers get used to what is there and tend to forget how much of an effort it was to start writing serious scripts. Thank goodness for forums.
Cyberia
2nd June 2003, 17:15
My vote is for improved DirectShowSource as well as improved audio functionality. I'd like to be able to pass audio streams through AviSynth ala 'Direct Stream Copy' in VirtualDub. Let Vdub worry about the compression format, just demux the audio stream and pass it along.
Prettz
9th June 2003, 04:09
Originally posted by Cyberia
My vote is for improved DirectShowSource as well as improved audio functionality. I'd like to be able to pass audio streams through AviSynth ala 'Direct Stream Copy' in VirtualDub. Let Vdub worry about the compression format, just demux the audio stream and pass it along.
This is my vote. It would incredibly useful when you have both a .d2v file and a vbr mp3 or ogg file that both describe the whole movie, but you need to edit the movie inside avisynth with Trim, and need the audio to be editted accordingly.
The only way I know of at the moment to do this is to keep the audio as a wav file, dub it to the video in avisynth before editing, encode the video (muxing it with wav audio), then extract the audio track from the avi, encode it, and remux it (whew).
FredThompson
18th June 2003, 09:48
console-based file browser to chose source files and the ability to edit and thus reconfigure a script without having to reload the AVS file in whatever ap is using it would be great, sort of like a reset/reload capability.
If you've ever worked with a large number of short clips for mixed format, you've probably experienced the reason this could be helpful. (clip 19 is anime, turn on lines x, y and z, clip 20 is live-action, turn off x, y, z and turn on i, j and k...repeat until your brain goes numb.)
(edit: new stuff)
Support for bitmaps beyond external file creation:
BitmapFrame(startframenum,endframenum,filename,insert/overlay boolean)
Self-centering letterbox:
LetterboxCenter (width,height,color)
stickboy
20th June 2003, 09:33
I would like to see improvements to the scripting language (even if it comes at the cost of breaking old scripts).
Here are some possibilities: lexically-scoped namespaces for function names; I'd like to be able to define functions private in an .avsi file
real control structures (if, while, ...)
removing the need for explicit line continuation characters (\)
properly escapable strings
functions that can take a variable number of arguments (passing them as strings is a kludge)
first-class functions (passing function names as strings is also a kludge)
C-style evaluation order for arithmetic expressions
Richard Berg's Python (http://www.avisynth.org/index.php?page=WhyPython) idea
Loul
21st June 2003, 15:37
Paul Langemeijer's idea sounds inspiring.
It would be so cool to have an avisynth "debugger" which could tell you what looks wrong and what looks dubious (of course it would be perfect if it understands the most popular plug-ins syntax).
Bidoche
3rd July 2003, 12:17
lexically-scoped namespaces for function names; I'd like to be able to define functions private in an .avsi file
That would suppose heavy modifications in how environment works (it's him who learns and links functions).
So for now, it's no.
real control structures (if, while, ...)Are scheduled in 3.0
removing the need for explicit line continuation characters (\)The idea of switching between explicit line continuation and explicit line termination ( ; ) through a parser directive has been accepted.
properly escapable stringsI guess we could easily
functions that can take a variable number of arguments (passing them as strings is a kludge)This is a no-no. But you may have arrays instead.
first-class functions (passing function names as strings is also a kludge)functions are valid avsvalues in 3.0
C-style evaluation order for arithmetic expressionsIsn't it already the case ? (Never really looked into it)
Richard Berg's Python ideaNo idea.
stickboy
4th July 2003, 10:31
Originally posted by Bidoche
C-style evaluation order for arithmetic expressionsIsn't it already the case ? (Never really looked into it)
You're right, it is. Apparently the Avisynth documentation is wrong, which states that expressions are parsed right-to-left.
Wilbert
4th July 2003, 10:42
Why don't you check it. Calculate 1-2-3, and use string+subtitle to see what the outcome is. Or are you refering to something else?
stickboy
4th July 2003, 18:40
I did check it. Avisynth 2.52 parses left-to-right. That's why in my previous post I said Bidoche was correct and that the documentation is in error.
kilg0r3
4th July 2003, 18:44
yv12 support for peach smoother and the fairy, pixie, ... dusts.
FredThompson
4th July 2003, 20:22
Those aren't part of AviSynth.
Wilbert
5th July 2003, 13:17
I did check it. Avisynth 2.52 parses left-to-right. That's why in my previous post I said Bidoche was correct and that the documentation is in error.
Damn, you are right. It gives -4 :confused: We will correct this in the docs, after I checked it with older versions ...
WarpEnterprises
7th July 2003, 22:16
what's wrong with -4? The bug that it outputs 1-(2-3) = 0 was corrected some time ago.
The doc will be updated in a few minutes...
Wilbert
8th July 2003, 09:16
what's wrong with -4? The bug that it outputs 1-(2-3) = 0 was corrected some time ago.
Ok, apperently :) I didn't know that :) Do you know since when?
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.