Specifying pix_fmt on FFMPEG call about moviepy

[Zulko]

Thanks for this. What you describe seems to be what user @chunder made in a branch just a few days ago:

chunder@d107e6b

Do you confirm that this is what you want ? Or do you think it would be a better idea to make it an option ?

I asked the user for a merge request.

[alexbw]

This should work for me. I will test it soon.
I only know about needing yuv420p on OSX, I'm not sure if further options
for that flag are necessary.

On Fri, Mar 28, 2014 at 12:14 PM, Zulko [email protected] wrote:

Thanks for this. What you describe seems to be what user @chunderhttps://github.com/chundermade in a branch just a few days ago:

chunder@d107e6bhttps://github.com/chunder/moviepy/commit/d107e6b28339a6b703da141aac19bf31aff3bf07

Do you confirm that this is what you want ? Or do you think it would be a
better idea to make it an option ?

I asked the user for a merge request.

Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-38937357
.

[chunder]

Ya, I added this because my libx264 mp4s were not displaying on a couple of browsers (Chrome and IE I think). I found this ffmpeg ticket that is considering making yuv420p the default for libx264, since most players expect that.

http://trac.ffmpeg.org/ticket/658

I'll turn it into a pull request shortly.

[alexbw]

Any word on this? Would be immediately useful to myself and my labmates.

[Zulko]

Aw, sorry we didn't come back to you. Here is an update. Now the export of .mp4 videos is yuv240p (almost always) by default in to_videofile. ffmpeg_movie_from_frames is indeed totally deprecated, but I can change that by tommorow if you explain your needs. Do you need to work from separate frames ?

Now for the details. A few days ago @chunder merged a pull request that makes yuv420p the default for all video written with the libx264 codec (that is, the default codec every time you export to mp4).
Then I found that this actually crashed the video export if the videoclip exported had a non-even dimension, like 720x405 so I amended the program so that it will not use yuv240p in these cases.

I have plans to change ffmpeg_movie_from_frames into something that will look like this:

clip = DirectoryClip('directory/with/frames', fps=10)
clip.to_videoclip("my_assembled_movie.mp4")

The advantage being that you can process the clip as you like (the frames are numpy arrays) before writing it as a movie. I can do that by tomorrow if this is the issue.

[alexbw]

Thanks for the update.

I construct my movies like so --

images = np.array(...)
fps = 30.0
c = [mp.ImageClip(i) for i in images]
[setattr(c[i],'duration',1.0/fps) for i in range(len(c))];
cc = mp.concatenate(c)
cc.fps = fps
cc.to_RGB()
cc.to_videofile('/path/to/my/movie.mp4')

Will this take advantage of the new codepaths?

[Zulko]

• This should work as you want (i.e. output stuff with yuv240p pixel
  format).
• This is really not a nice code but hey, it's my fault, I didn't
  realize people would want to work from a sequence of pictures. I am
  coding a class that will make your life easier.
• I think the line cc.to_RGB() does nothing: everything is outplace
  in MoviePy. To use it you should write
  cc = cc.to_RGB()
• to_RGB is only useful to convert mask clips (greyscale black and
  white) to RGB clips. Are you sure you need it ?

I'll keep you posted.

Thanks for the update.

I construct my movies like so --

images = np.array(...)
fps = 30.0
c = [mp.ImageClip(i) for i in images]
[setattr(c[i],'duration',1.0/fps) for i in range(len(c))];
cc = mp.concatenate(c)
cc.fps = fps
cc.to_RGB()
cc.to_videofile('/path/to/my/movie.mp4')

Will this take advantage of the new codepaths?

—
Reply to this email directly or view it on GitHub
#27 (comment).

[alexbw]

I probably don't need the to_RGB, and checking some other code I wrote, I
actually dropped it.
My use case is pretty common in my field -- I'm doing a lot of image
processing on individual frames loaded from a raw data file, and then I'd
like to visualize the effects of my imaging processing quickly. Before
moviepy, I'd just write all the frames to a temp directory, and call ffmpeg
directly. Moviepy provides a much nicer wrapper.
Would be great if this was a one-liner, though, like

mp.fromarray(images,fps=30.0).to_videofile('/path/to/my/movie.mp4')

That would be a PIL-like syntax that would be *incredibly *convenient.

On Mon, Apr 7, 2014 at 1:50 PM, Zulko [email protected] wrote:

• This should work as you want (i.e. output stuff with yuv240p pixel
  format).
• This is really not a nice code but hey, it's my fault, I didn't
  realize people would want to work from a sequence of pictures. I am
  coding a class that will make your life easier.
• I think the line cc.to_RGB() does nothing: everything is outplace
  in MoviePy. To use it you should write
  cc = cc.to_RGB()
• to_RGB is only useful to convert mask clips (greyscale black and
  white) to RGB clips. Are you sure you need it ?

I'll keep you posted.

Le 07/04/2014 19:40, Alex Wiltschko a écrit :

Thanks for the update.

I construct my movies like so --

images = np.array(...)
fps = 30.0
c = [mp.ImageClip(i) for i in images]
[setattr(c[i],'duration',1.0/fps) for i in range(len(c))];
cc = mp.concatenate(c)
cc.fps = fps
cc.to_RGB()
cc.to_videofile('/path/to/my/movie.mp4')

Will this take advantage of the new codepaths?

Reply to this email directly or view it on GitHub
#27 (comment).

Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-39761094
.

[Zulko]

That is where I am going:

 ImageSequenceClip( numpy_images_list 

,fps=30.0).to_videofile('movie.mp4')
ImageSequenceClip( image_files_list ,fps=12)
ImageSequenceClip( folder_with_images ,fps=12)

While we are at it, if you have a better idea for the class name...

What I meant in the previous clip is that I expected that people from
the scientific python world would prefer to use Matplotlib, which is not
bad at all for image-by-image visualization. Here are two videos I made
with Matplotlib a while ago:

https://www.youtube.com/watch?v=fT_n61iXQiE
https://www.youtube.com/watch?v=dr_YHExPWT0

I probably don't need the to_RGB, and checking some other code I wrote, I
actually dropped it.
My use case is pretty common in my field -- I'm doing a lot of image
processing on individual frames loaded from a raw data file, and then I'd
like to visualize the effects of my imaging processing quickly. Before
moviepy, I'd just write all the frames to a temp directory, and call
ffmpeg
directly. Moviepy provides a much nicer wrapper.
Would be great if this was a one-liner, though, like

mp.fromarray(images,fps=30.0).to_videofile('/path/to/my/movie.mp4')

That would be a PIL-like syntax that would be *incredibly *convenient.

On Mon, Apr 7, 2014 at 1:50 PM, Zulko [email protected] wrote:

• This should work as you want (i.e. output stuff with yuv240p pixel
  format).
• This is really not a nice code but hey, it's my fault, I didn't
  realize people would want to work from a sequence of pictures. I am
  coding a class that will make your life easier.
• I think the line cc.to_RGB() does nothing: everything is outplace
  in MoviePy. To use it you should write
  cc = cc.to_RGB()
• to_RGB is only useful to convert mask clips (greyscale black and
  white) to RGB clips. Are you sure you need it ?

I'll keep you posted.

Le 07/04/2014 19:40, Alex Wiltschko a écrit :

Thanks for the update.

I construct my movies like so --

images = np.array(...)
fps = 30.0
c = [mp.ImageClip(i) for i in images]
[setattr(c[i],'duration',1.0/fps) for i in range(len(c))];
cc = mp.concatenate(c)
cc.fps = fps
cc.to_RGB()
cc.to_videofile('/path/to/my/movie.mp4')

Will this take advantage of the new codepaths?

Reply to this email directly or view it on GitHub
#27 (comment).

Reply to this email directly or view it on
GitHubhttps://github.com//issues/27#issuecomment-39761094
.

—
Reply to this email directly or view it on GitHub
#27 (comment).

[alexbw]

I started using moviepy because I can composite by hand in PIL or ndimage,
and then write out to a movie orders of magnitude faster than if I was
using Matplotlib. So that's nice.

Why don't you just use
"Movie" or "Clip" universally, like PIL uses "Image"?

On Mon, Apr 7, 2014 at 2:07 PM, Zulko [email protected] wrote:

That is where I am going:

ImageSequenceClip( numpy_images_list
,fps=30.0).to_videofile('movie.mp4')
ImageSequenceClip( image_files_list ,fps=12)
ImageSequenceClip( folder_with_images ,fps=12)

While we are at it, if you have a better idea for the class name...

What I meant in the previous clip is that I expected that people from
the scientific python world would prefer to use Matplotlib, which is not
bad at all for image-by-image visualization. Here are two videos I made
with Matplotlib a while ago:

https://www.youtube.com/watch?v=fT_n61iXQiE
https://www.youtube.com/watch?v=dr_YHExPWT0

Le 07/04/2014 19:56, Alex Wiltschko a écrit :

I probably don't need the to_RGB, and checking some other code I wrote, I
actually dropped it.
My use case is pretty common in my field -- I'm doing a lot of image

processing on individual frames loaded from a raw data file, and then I'd
like to visualize the effects of my imaging processing quickly. Before
moviepy, I'd just write all the frames to a temp directory, and call
ffmpeg
directly. Moviepy provides a much nicer wrapper.
Would be great if this was a one-liner, though, like

mp.fromarray(images,fps=30.0).to_videofile('/path/to/my/movie.mp4')

That would be a PIL-like syntax that would be *incredibly *convenient.

On Mon, Apr 7, 2014 at 1:50 PM, Zulko [email protected] wrote:

• This should work as you want (i.e. output stuff with yuv240p pixel
  format).
• This is really not a nice code but hey, it's my fault, I didn't
  realize people would want to work from a sequence of pictures. I am
  coding a class that will make your life easier.
• I think the line cc.to_RGB() does nothing: everything is outplace
  in MoviePy. To use it you should write
  cc = cc.to_RGB()
• to_RGB is only useful to convert mask clips (greyscale black and
  white) to RGB clips. Are you sure you need it ?

I'll keep you posted.

Le 07/04/2014 19:40, Alex Wiltschko a écrit :

Thanks for the update.

I construct my movies like so --

images = np.array(...)
fps = 30.0
c = [mp.ImageClip(i) for i in images]
[setattr(c[i],'duration',1.0/fps) for i in range(len(c))];
cc = mp.concatenate(c)
cc.fps = fps
cc.to_RGB()
cc.to_videofile('/path/to/my/movie.mp4')

Will this take advantage of the new codepaths?

Reply to this email directly or view it on GitHub
#27 (comment).

Reply to this email directly or view it on
GitHubhttps://github.com//issues/27#issuecomment-39761094

.

Reply to this email directly or view it on GitHub
#27 (comment).

Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-39763257
.

[Zulko]

I started using moviepy because I can composite by hand in PIL or
ndimage,
and then write out to a movie orders of magnitude faster than if I was
using Matplotlib. So that's nice.
Yes. I think the main difference is that Matplotlib writes the frames to
files before making a movie.

Something I forgot to mention: if you generate all the numpy frames in
advance you may end up with memory problems for long animations. An
alternative is to generate the frames on-the-flight:

FPS=12
def generate_frame(t):
     index = int(FPS*t)
     npimage = generate_numpy_image_( index )
     return npimage

animation = VideoClip(get_frame = generate_frame)
animation.to_videofile('test.mp4', fps=FPS)

Why don't you just use
"Movie" or "Clip" universally, like PIL uses "Image"?
I am not 100% convinced of the organization, but here are the main
reasons. There are at least two kinds of clips, AudioClips and
VideoClips. Then there are optimizations that make me want a special
class, ImageClip, for clips with no movement. Then I consider
CompositeVideoClips as special (but it is more debattable).
Another reason is lisibility:

a = VideoFileClip('mymovie.mp4')
b = ImageClip('mypic.jpeg')
c = CompositeVideoClip([a, b])

Here any newbie can tell me that these objects are instances of the
class Clip, and how they have been obtained.

[Zulko]

I'm closing this thread (unless you still have unresolved issues ?). Thanks for the feedback !

[alexbw]

This works perfectly for me now.

On Thu, Jun 19, 2014 at 3:22 PM, Zulko [email protected] wrote:

I'm closing this thread (unless you still have unresolved issues ?).
Thanks for the feedback !

—
Reply to this email directly or view it on GitHub
#27 (comment).