Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specifying pix_fmt on FFMPEG call #27

Closed
alexbw opened this issue Mar 28, 2014 · 13 comments
Closed

Specifying pix_fmt on FFMPEG call #27

alexbw opened this issue Mar 28, 2014 · 13 comments

Comments

@alexbw
Copy link

alexbw commented Mar 28, 2014

The newer versions of FFMPEG default to a pixel format which is incompatible with Apple's Quicktime player. It would be convenient to offer the option to specify the pixel format, i.e. to add the flag

-pix_fmt yuv420p

to the ffmpeg call in ffmpeg_tools.py:ffmpeg_movie_from_frames.

There is a note that ffmpeg_movie_from_frames is almost deprecated. I can add the option, and propagate the keyword argument up to to_videofile and issue a pull request, but is this the most appropriate place to add the change?

@Zulko
Copy link
Owner

Zulko commented Mar 28, 2014

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
Copy link
Author

alexbw commented Mar 28, 2014

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 notifications@github.com 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
Copy link
Contributor

chunder commented Mar 28, 2014

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
Copy link
Author

alexbw commented Apr 7, 2014

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

@Zulko
Copy link
Owner

Zulko commented Apr 7, 2014

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
Copy link
Author

alexbw commented Apr 7, 2014

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
Copy link
Owner

Zulko commented Apr 7, 2014

  • 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
Copy link
Author

alexbw commented Apr 7, 2014

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 notifications@github.com 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
Copy link
Owner

Zulko commented Apr 7, 2014

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 notifications@github.com 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
Copy link
Author

alexbw commented Apr 7, 2014

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 notifications@github.com 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 notifications@github.com 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
Copy link
Owner

Zulko commented Apr 7, 2014

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
Copy link
Owner

Zulko commented Jun 19, 2014

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

@Zulko Zulko closed this as completed Jun 19, 2014
@alexbw
Copy link
Author

alexbw commented Jun 19, 2014

This works perfectly for me now.

On Thu, Jun 19, 2014 at 3:22 PM, Zulko notifications@github.com 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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants