animation with 'ffmpeg' backend and 'savefig.bbox = tight' garbles video

[chipmuenk]

Using

• Matplotlib 1.5.0rc3 with Python 2.7.10 and Win 7 64 Bit (WinPython 2.7.10.3) or
• Matplotlib 1.5.1 with Python 3.4.4 and Win 7 64 Bit (WinPython 3.4.4.1)
• ffmpeg 20160512-git-cd244fa
  animation with 'ffmpeg' backend incompative with 'bounding_box=tight' #2483 seems to be back (or still there):

Setting savefig.bbox = tight either in matplotlibrc or as an rcParam garbles an mp4 video written by ffmpeg. Even starting the script with --verbose-debug gives no warning or message that something might be wrong.

I also cannot change the frame rate - neither interval nor fps has any effect, I always get 5 fps (this is consistent with the options passed to ffmpeg which always says '-r 5').

Example (slightly modded) taken from
https://jakevdp.github.io/blog/2012/08/18/matplotlib-animation-tutorial/ :

import numpy as np
import matplotlib.pyplot as plt
import matplotlib.animation as animation

plt.rcParams['animation.ffmpeg_path'] = 'D:/Programme/ffmpeg/bin/ffmpeg.exe'
plt.rcParams['savefig.bbox'] = 'tight'     # tight garbles the video!!!

movie_file = 'D:/Daten/basic_animation.mp4'
mywriter = animation.FFMpegWriter()

fig = plt.figure()
fig.set_size_inches(4, 5, True)
ax = plt.axes(xlim=(0, 2), ylim=(-2, 2))
line, = ax.plot([], [], lw=2)

def init():
    line.set_data([], [])
    return line,

def animate(i):
    x = np.linspace(0, 2, 1000)
    y = np.sin(2 * np.pi * (x - 0.01 * i))
    line.set_data(x, y)
    return line,

anim = animation.FuncAnimation(fig, animate, init_func=init,
                               interval = 1000, frames = 20, blit=True)

anim.save(movie_file, dpi=100, fps = 30, writer=mywriter, 
          extra_args=['-vcodec', 'libx264'])

plt.show()

[dopplershift]

I can reproduce the fps issue here locally on OSX on python 3.4, matplotlib 1.5.1. Not sure why -r 5 is getting passed.
(I'd say let's leave the 'tight' issue to #2483).

[tacaswell]

It might be worth using an rccontext in anim.save to force the bounding box to always be off?

This is an awfully large foot-cannon to have very lightly documented.

[dopplershift]

That's a really good idea--I'll go ahead and include that when I put up a PR to fix the fps issue.

[dopplershift]

Ok, so there are really two things that are different cases that we haven't hit before:

1. Using rcparams for tight bbox. We can address this using rc_context, as suggested by @tacaswell
2. Passing in a MovieWriter instance along with some kwargs that are used in the creation of a MovieWriter instance (when save needs to create one). The question is: Should we modify the passed in MovieWriter using the kwargs? Or should we just document that these are ignored if writer is a MovieWriter instance?

In the meanwhile, the work-around/intended use would be to do:

mywriter = animation.FFMpegWriter(fps=30, extra_args=['-vcodec', 'libx264'])

and

anim.save(movie_file, dpi=100, writer=mywriter)

Clearly, since I had to actually dig into this problem, it's not intuitive; I'm just not sure what the right answer is.

[chipmuenk]

The workaround works for me (for the fps issue) - thanx for the explanation and the quick solution!

For debugging purposes, it would be great to see messages created by the actual movie writer (ffmpeg in my case): An invalid parameter in the extra_args list e.g. just raises an IOError.

[dopplershift]

Having given this some thought, I think the right solution is to document the kwargs which will have no effect when writer is an instance of MovieWriter and to issue a warning when both are supplied (which will of course say the arguments should be supplied when creating the MovieWriter.)

Anyone else have any thoughts?

[tacaswell]

No one reads warnings 👿.

I lean towards raise, but would merge a PR which added the warnings.

[dopplershift]

raise works for me too. One point: raising the error could break code that "works". I think this is fine (since existing code can't be working as intended)...but how do we feel about that for matplotlib?

[tacaswell]

I tend to view that as ok, it is just telling users that code that wasn't working really isn't working.

[dopplershift]

Fixed by #6441 and #6421.