Call to Arms: AVTECH4

[Mister Hatt]

I think the point of a guide should be to make sure people actually understand what they're doing. IMO it is useless to talk about frameserving in a basics guide as that requires in-depth knowledge of video theory, which most readers do not actually have. What happens is you end up with a bunch of people with no clue copypasting bad scripts and not understanding what is happening or why. Better to keep theory out of it for people who don't want to spend the time on it, and just cover what they REALLY need to know. Frameserving in general I think is an advanced topic already.

[Qyot27]

so I wish to hold off the guide to until vapoursynth is completely up and running on all OSes. It currently is in a mostly usable state on Windows (though it still needs a buncha improvements), but for the other OSes it's left to building from source.

And with the way these things usually go, that'll probably be the way it stays. /cynical

The most you may need to do for Mac users is step them through installing homebrew, since its probably inevitable for it to get a formula at some point (considering AvxSynth already has one, but there's no reason to use that for anything but academic curiosity...you're still better off just using AviSynth 2.6 under Wine). There's probably zero need to worry about Linux users, since A) the source distros likely already have it available in the user areas or will in short order (there's already an AUR for Arch users), and B) the INSTALL file that comes with the source code covers how to build it.

Waiting on Ubuntu probably means waiting on Debian, and if not, who knows how long that'll take considering how long it took for MediaInfo to finally get into Universe (it didn't get in there until Precise, aka 12.04, aka the current release that only came out six months ago - prior to that you had to use the project's official PPA). There's no way it'll be in the repos for 12.10 (13.04 *might* be a possibility but still pretty damn unlikely), since the distro itself is only now wanting to shift its main version of Python to 3.x. The alternate solution is to wait on a PPA - unlikely, IMO - or for there to be a ruleset added to the source so that using apt's automatic dependency resolution+build system is possible (discounting that they could just go ahead and use the instructions in INSTALL).

I wouldn't wait on Fedora, either, for largely the same reason: the INSTALL instructions are probably enough, or someone will come up with a user-submitted or quasi-unofficial repository like the situation that darwinx has been in for the last few releases.

Other than that, there's just too much variety in package management solutions and software provided by them to wait on the distros themselves having it available through their official repositories. There's a certain point where the operating principle for Linux is that for most of them, the user should be assumed to know how to deal with installation from source, or to know how to find the unofficial repositories themselves and use those - any more than that and you aren't teaching them anything about VapourSynth, you're teaching them how to use their own operating system. The big distros are often notoriously sluggish on getting this stuff included or up-to-date (hell, getting up-to-date versions of mplayer[2] or ffmpeg/libav or x264 is already typically left to the user compiling them on their own because the official maintainers can't be arsed to do it, or only do it every six months unless there's a security issue).

Which also brings up the point that even if VapourSynth gets in, you still have to deal with all the other software not necessarily being up-to-date, again throwing it back to the users having to build everything again. So I'd just ignore the point on getting it installed and have it laid out for usage. Installation instructions can be added later, or you could link to established guides elsewhere about doing it, if it was really necessary.




All of this ignoring the part where there's been this disconnect between AviSynth scripting and CLI use for a long time, for insanely dumb reasons. Comparatively speaking, AviSynth syntax (or Python syntax) is a lot more complex than the build process or general CLI use. Having to open the Terminal or Command Prompt to do some preparation shouldn't be treated as a deterrent. After all, if the requisite steps are all right there and only need to be copy-pasted, it's the user's own fault for being lazy (or stubborn) if they don't want to follow them. There's only so much hand-holding you can do.

[Qyot27]

(considering AvxSynth already has one, but there's no reason to use that for anything but academic curiosity...you're still better off just using AviSynth 2.6 under Wine)

Now I kind of have to eat my words, even if the external filter situation hasn't changed much. While it hasn't been finalized yet, there is a rewrite of the AviSynth parser in libavformat which would allow ffmpeg to use AvxSynth to open .avs scripts directly on Linux, as well as a patch for mplayer2 to accomplish the same thing through mpdemux.

Of course, from personal testing, the ffmpeg patch applies cleanly and builds without errors, but trying to actually use a script causes a segfault. You can, however, tell that it is doing what it's supposed to, because it can probe the .avs format, just not continue beyond that. That'll end up getting sorted out, though.

The mplayer2 patch, on the other hand, does work. And this means you don't have to do any piping, and you can actually seek forward and backward in a script. And it supports taking/playing audio, which (along with the inability to pipe in y4m format) was one of the deficiencies of the avxFrameServer application. This does also allow for the use of mplayer2's vo-lavc branch to do transcoding from scripts.

[l33tmeatwad]

No, see, that IS the problem with the guide. Most of the concepts and explanations need to be done step by step along with the scripts, if at all. People are ENTIRELY skipping the theory guides currently, plus they sound more complicated than they should, yet aren't quite as comprehensive.

For instance, avtech3 still does not mention colormatrix, which is important. It's not even that hard, and you don't even have to get into details. People don't need to know what are the white points and primaries. They just need to know that BDs are Rec. 709, DVDs are Rec. 601, and in playback anything up to 1024x600 is considered Rec. 601, whereas anything beyond is considered Rec. 709 and thus they need to convert the matrix when they're upscaling/downscaling through that resolution. Which isn't hard at all to do.

So yes, I believe simple explanation snippets along with the code, step by step in the guide, will be much less overwhelming and easier to understand.

I agree, having been working with editors on Skype a lot, they are way less willing to learn conceptual stuff and are very intimidated by the current "book" that is the AV guide here on the org. Most everyone wants to know how to do something when they need to do it and want basics instructions. I like the idea of basic and advanced guides as well, I've found that some will just ignore guides altogether if they are too advanced and will continue doing things the wrong way...

I think the point of a guide should be to make sure people actually understand what they're doing. IMO it is useless to talk about frameserving in a basics guide as that requires in-depth knowledge of video theory, which most readers do not actually have. What happens is you end up with a bunch of people with no clue copypasting bad scripts and not understanding what is happening or why. Better to keep theory out of it for people who don't want to spend the time on it, and just cover what they REALLY need to know. Frameserving in general I think is an advanced topic already.

While I agree it would be BETTER and EASIER for everyone if they actually learned stuff in depth, but not every editor wants to learn how to become an advanced "encoder" who knows tons of stuff about AviSynth and all the settings in x264. Editors are quite honest about this and are very willing to say they don't care, haha...

[l33tmeatwad]

I think this is a project that needs to be visited sooner rather than later. I understand the idea of picking one standard, but the slow development of VapourSynth really points to it being years before this is updated if we wait on that. I really think users would benefit greatly from a guide that is a bit easier to find what they need and is up to date.

[Zarxrax]

Yea, and avisynth+ is looking pretty sweet now. Vaporsynth is conceptually a nice thing, but I don't see it getting to the point avisynth is for a LONG time.

[l33tmeatwad]

Yea, and avisynth+ is looking pretty sweet now. Vaporsynth is conceptually a nice thing, but I don't see it getting to the point avisynth is for a LONG time.

Yeah, I agree and I personally think most users here would not use VapourSynth anyways...the steep learning curve, difficult structure, and the very unforgiving nature of the scripting would be a nightmare for the average user (especially since they struggle so much with AviSynth which is WORLDS easier).

[BasharOfTheAges]

You really think most people are actually trying to understand avisynth and not just copy-pasting lines from the guides or forum posts verbatim?

[l33tmeatwad]

You really think most people are actually trying to understand avisynth and not just copy-pasting lines from the guides or forum posts verbatim?

I wouldn't disagree with that, the problem with VapourSynth is that the script structure REQUIRES you to learn how it works, while AviSynth users can just simply copy paste one function and put it in their script.

What that basically means is, the help forum would get a LOT busier and users would constantly be asking for entire scripts to be written for them...

[Qyot27]

VapourSynth's main strength is the integration with Python, even if it's not technically part of the core. The Cython bindings are just that; as others have mentioned before, bindings for other languages - even AviSynth - could be written and then you'd have to deal with their internal syntactical issues while using the VapourSynth core...although somehow I have a feeling that even if VS bindings for AviSynth appeared, it wouldn't lessen the syntax burden that much - you may not need to populate variables all the time, but you'd probably still need the verbose namespacing stuff or some mechanism to translate to and from.

And that's why its greatest strength is also its greatest weakness. Most people are just too lazy to want to deal with learning Python, even rudimentary Python (or dislike the syntax for philosophical or technical reasons, even if they do understand it), although if you're writing a media application using Python, the Cython bindings would make VapourSynth a natural choice.


Also, oh-shit-HuffYUV-just-got-updated-to-support-high-bit-depths-and-colorspaces. Or ffvhuff, more accurately, but still. The extended colorspaces @8bit were added about a week and a half ago, but I checked my RSS feeds a few minutes ago and saw these:
http://git.videolan.org/?p=ffmpeg.git;a ... 9bb42db793
http://git.videolan.org/?p=ffmpeg.git;a ... 857bb6b31b