Sorry for breaking that and thank you for the fix!

I have a slight preference to re-override the_handle_subprocess inAVConvBase instead of adding the string test against the class name (which would also fix this in the case of a user sub-class ofAVConvBase which does not include 'AVConv' in the class name).

Or we could just remove the method override, which was only added in#8253 so that tests pass on systems where ffmpeg is a shim for avconv (i.e. oldish ubuntus, in particular Travis before the switch to trusty); but as far as I can guess things should still work in that case as long as one is not using the h264 codec.

@tacaswell That's exactly what I've done initially but I realized it makes the code less readable. The issue was with a specific version of ffmpeg but the test broader than it should be. So rather than overriding the method back to MovieWriter's version I found it better to restrain the test. That way we also keep the fact that AVConv is just FFMPEG with a different path.

@anntzer I didn't notice but ubuntu 12.0.4 ended is life April 28, 2017. So removing the override seems a good idea. Is there a way to know if there is still users of this OS ?

Whatever the decision for long-term I really believe this fix should be released as soon as possible. Now the animation module isunable to save anything with avconv (which is the only one available within debian stable).

There are still people using Windows XP, it is up to us whether we want to support them.

Haveffmpeg andavconv sorted out their issues an re-merged? My understanding was that avconv is a hostile fork of ffmpeg with a diverging CLI.

I think that restoring the non-libav rejecting version in the sub-class is clearer, bit more code, but less coupling.

We should probably leave filter for ffmpeg-shims-on-top-of-avconv in place until we are sure no main-line distros are shipping the shims (and it sounds like ffmpeg is not available on debian stable, do they ship the shims in it's place?).

Hi,
I've moved the fix as an overwriting in AVConvBase.
Since the commit that introduced the bug is quite recent I totally agree on just applying my patch and letting as it is for few years.