TASEmulators/BizHawk

Bump up FFmpeg Writer above AVI Writer

CasualPokePlayer opened this issue · 4 comments

Probably want to stop prioritizing/defaulting the AVI writer. The AVI writer has clunky limitations, being it uses an ancient Windows specific API, 2GiB splits being required (no such limitation for ffmpeg), and for practical use requires the user to go install external codecs from who knows where (for the ffmpeg writer, it's just a single download streamlined by BizHawk that provides many, many options).

The 64 vs 32 bit has confused people many times as well -- since Bizhawk became 64 bit, it uses codes from the 64 bit vfw stack and not the 32 bit vfw stack. The heyday of vfw was with 32 bit codecs, so 64 bit ones can be harder to find, and users don't know the difference and don't know what they have installed.

FFmpeg obviously supports AVI. If we have a preset which results in the same format(s) as AviWriter, and is about as performant, then I say let's drop the dedicated option completely.

.avi itself is just a container, like mp4 and mkv, and the file format itself isn't subject to the 2GiB limit, that's just something imposed by Vfw being ancient garbage (although there's other limitations of the format which mp4/mkv solve). The only thing unique to Vfw are the codecs, which typically necessarily have to go through the Vfw interface (with all its issues), and even then those are just who knows what from who knows where (although imo what ffmpeg offers would be satisfactory/superior in any case). The main reason anyone would actually want to use Vfw in BizHawk is just to use the output with some tooling which only likes Vfw codecs for whatever reason (granted, I'm not sure how much of that still exists in the modern day).

I support moving ffmpeg above avi writer, but I don't support dropping the latter. One of the most powerful options for lossless encoding is Lagarith which is windows only and doesn't go with ffmpeg, it compresses very well and is very quick. Comparable ffmpeg codecs are either less compatible (x264) or compress worse (utvideo) or are slower (ffv1). So it's a balance thing.