Bookmark Wine's C: drive in Finder:1) With Finder open, press Shift+Command+G2) Type in ~/.wine/drive_c and press Enter.3) You should see two directories: Program Files and windows - this lets you know you're in the right folder.4) Use Finder's bookmarks to place a shortcut in the left pane. This makes dealing with Wine much easier.

Install AviSynth 2.6a5:1) Open a Terminal and copy/paste the following to download AviSynth 2.6 alpha 5:

We're not going to stay with 2.6a5, because there's a better alternative: AviSynth+ (http://avs-plus.net). Unfortunately, the installer (and the zip) provided can't be used with Wine because the official binaries weren't compiled with Visual Studio 2010 (this matters, because Wine currently doesn't like binaries that were built on newer versions of Visual Studio; eventually this will get fixed, but it hasn't yet). For that reason, I've compiled AviSynth+ r1576 with Visual Studio 2010:avisynth+_r1576.zip

Extract the zip file, and then copy or move AviSynth.dll and DevIL.dll to wine's windows\system32 folder. You can safely let it overwrite the 2.6a5 versions it finds there. Put the rest of the .dlls in wine's Program Files\AviSynth 2.5\plugins folder (DirectShowSource is the only one that it'll conflict with; you can let it overwrite, you can't use DirectShowSource under Wine anyway).

The AMVapp stuff:Not everything in the AMVapp is necessary here. The only ones you really need to pay attention to are:AVSPluginPack.exeHuffyuvSetup.exe

A few plugins from the plugin pack that need updating:FFmpegSource2:1) Latest build of the C-plugin*: http://www.mediafire.com/?mvgx2dfp1xam1nh2) Extract the zip, and move ffms2.dll, FFMS2.avsi, and ffmsindex.exe into Wine's C:\Program Files\AviSynth 2.5\plugins (allow it to replace them)

*I update the C-plugin builds more frequently than the offical builds are, which is the only reason I'm pointing to that particular build.The official releases are available from https://github.com/FFMS/ffms2/releases

3) Go into x264-tmod, and in the FFmpeg folder, create a new folder with the name x2644) To make it easier, rename x264_32_tMod-8bit-all.exe to x264.exe, and x264_32_tMod-10bit-all.exe to x264-10bit.exe. Don't touch the '64' files.5) Move only x264.exe and x264-10bit.exe into the newly-created x264 folder.6) Move the newly-created x264 folder into Wine's C:\Program Files

2) In the left pane, there are collapsible folders. Expand HKEY_CURRENT_USER and click on the Environment folder.3) In the right pane, there will be an item named PATH. Double-click on it to bring up a dialog.4) Add the following information to the END of the Value data box. Copy/paste for ease of use:

And use the 'Open Video File' option in the File menu to select the script you just created (remember, Wine sees your regular OSX filesystem as the Z: drive, so to find the script you probably need to navigate to Z:\Users\[your-username] and then to whatever folder you created the script in). If everything worked, it should now be displaying the script, which is just AviSynth's version info. Since I instructed you to replace 2.6a5's dlls with the ones from AviSynth+, that information should read:

Other stuff:There technically is a native port of AviSynth that runs on OS X and Linux: this is AvxSynth. However, there's only a handful (like, only 4 or 5) plugins that were ever ported and made to work with AvxSynth, so it's not as useful as running AviSynth itself under Wine. I mention it, because x264 and FFmpeg support using AvxSynth as the AviSynth script reader for native OSX and Linux builds (x264 enables it automatically, FFmpeg requires the user to pass --enable-avisynth to FFmpeg's configure script). Another benefit of this is that if the user builds FFmpeg with --enable-avisynth, and then builds a native version of mpv using that FFmpeg build, then mpv can preview scripts (and because it's not running under Wine, mpv using AvxSynth to watch a script isn't sluggish). I'll probably cover this in another post.

Of course, AvxSynth has an expiration date. The reason is that it's not based on AviSynth 2.6; it's based on 2.5.8 (this means a lot here, like not being able to use the YV24 colorspace). And much more importantly, AviSynth+ has cross-platform support on its roadmap - which means that the second that avsplus is able to be built and used successfully on Linux and OSX, AvxSynth will be instantly deprecated and the support in x264 and FFmpeg will be changed to look for and use avsplus on these operating systems.

Put simply, I don't know if there would be conflicts. If it was the standalone version of CrossOver (or WineBottler, although I don't know if they've kept synched with Wine development), I want to say that I doubt there'd be an issue. If it was installing Wine through MacPorts, then it could cause some issues - I'm not sure how up-to-date MacPorts' ports for some of the necessary programs are, and MacPorts and Homebrew generally don't tend to play nice together and can lead to headaches trying to keep things sorted out.

Which is actually just one of the release posts. But I make sure to edit them and point to the next release post whenever one happens, so there wouldn't be any dead links hanging around.

Also, Ut Video is now up to version 14.2.0 and includes 10-bit 4:2:2 support.

And since I mentioned it back at the beginning, I finally got around to an AvxSynth setup guide.

Installing AvxSynth and VapourSynth on OS X 10.9 Mavericks

Like I mentioned before, I would probably get around to this. Being on 10.9 is more of a necessity for AvxSynth, not because of OS restrictions (I was able to build/use it on 10.6, IIRC), but because before 10.9, getting Autotools set up correctly on OSX was a nightmare - it was so bad I usually did the Autotools invocation of the build process under an Ubuntu VM that had the host filesystem mounted, and then dropped back out of the VM to finish. 10.9 (or rather, Apple's removal of some of this stuff from the version of Xcode released with 10.9, not sure about 10.8) fixed this, so installing Autotools from Homebrew and using it natively is no longer painful.

That last paragraph should signal something here - to use AvxSynth on OSX, you have to compile it from source. It doesn't come as a binary, and while there was a Homebrew branch that added a formula for it, that was never merged upstream (and it was also incomplete and pulled in Qt even though you don't need it). For freshness' sake, a few other dependencies will also be built from source, but for others, you can just use Homebrew.

Some of the packages above may need to be forcibly linked into the Cellar (IIRC, pango and/or cairo have to be manually linked); Homebrew will tell you if that's the case, and give you the instructions on how to do it. I actually included some external tools (mkvtoolnix, mediainfo, etc.) for the sake of ease.

And now to actually build stuff. Anywhere there's a 'make' step, you can pass the -j# option to tell make to build with multiple threads (where # is the number of threads to use). iMacs are generally 2- or 4-core i5s or 4-core i7s, so this can provide a bit of a boost. Homebrew automatically selects this, apparently, and can deal with hyperthreading as well. For manually built software, it's up to the user to specify this. To that end, I'll actually assume 4 threads being used.

If you see AvxSynth's version info, you're good. You could also just write a script using FFVideoSource and/or FFAudioSource and see if it plays in mpv (for practical reasons, I strongly suggest using ffmsindex to index the video file first). If it plays in mpv, then you can also encode through FFmpeg. x264's support is automatic, but it requires that AvxSynth actually is set up correctly. mpv provides a direct proof of that. I'll get to mpv tricks in a future post.

'brew outdated' is optional; it'll show you which of your installed formulae are outdated and can be upgraded.

With the stuff installed from source, you can simply repeat the steps above to update them (assuming, of course, that you deleted the directories after you were done compiling the software). Git has the ability to update the source and after doing so, it is possible to simply re-run the make and make install steps to update the programs in question...if there haven't been any changes to the projects' buildsystems. That's a bit too heady to account for for novice or casual users, so my recommendation is to just delete the source directories when you're finished and if you ever want to upgrade those pieces, just re-run those parts of the guide.

In VapourSynth's case, FFMS2 exists only as a symbolic link in VS' autoload directory. What this means is that the ln -s part of VapourSynth's instructions doesn't need to be repeated every time, and if you decide to update FFMS2 by re-running that part of the guide, VapourSynth will see the updated version automatically. The same thing would also be true if you built FFMS2 from the C-plugin branch* and built it as a dual AvxSynth/VapourSynth plugin - the C-plugin branch's buildsystem does the symlinking automatically, removing the need for the user to do it (and AvxSynth doesn't mind the symlinking tactic either, but if you decide to do it this way, you have to pass the --disable-ffms2 option to AvxSynth when you configure it, so you can build FFMS2 later).

*Despite it being the C-plugin's branch, it only builds the C-plugin if --enable-avisynth is used, and that option can't be used for native OSX or Linux builds. If using --enable-avxsynth, it's using AvxSynth's C++ interface (i.e. the traditional/standard AviSynth plugin interface).

mpv is mostly a media player, as it's a [vastly, vastly improved] fork of mplayer and mplayer2. But it does have the ability to act as an encoder too. mplayer had mencoder; mplayer2 got rid of the mencoder code and it was replaced with a branch that added a video output module that used libavcodec (vo-lavc). That branch was never integrated upstream to mplayer2. mpv's development history basically arose from all the satellite branches of mplayer2 that met upstream resistance/were rarely merged from, and mpv was initially the result of those developers merging all of their branches together and moving development forward thereafter. So mpv contains the changes from the old vo-lavc branch and has for its entire history (or practically so).

One of the advantages of the mplayer family of media players is its profile system. In the configuration file (located at either ~/.mpv/config or ~/.config/mpv/config on *nix systems like OSX and Linux, or any number of disparate places on Windows), the user can set up a profile and use this as shorthand for sets of configuration options. For instance, this is the config file I use (the vo and ao options are different on different OSes; the example is from Windows):

And it would do so without me having to remember all those configuration options that you see listed in the xvidmp3 profile. Not that FFmpeg lacks the ability to write/use custom profiles, but it's not quite as straightforward as this is (all the profiles are separate files and the syntax to invoke them can be a bit cumbersome).

The thread title should probably be changed since this is no longer Mavericks-exclusive. I've been on Yosemite since around the time the final was officially released, and the setup works fine there too (even if most of it is simply what was installed under Mavericks before the upgrade, but nothing radical has changed here).

However, the VapourSynth instructions are no longer accurate. They've moved to autotools now, so the waf instructions will fail.