From: Mads B. D. <ma...@dy...> - 2009-05-11 10:03:11
|
Fredag 08 maj 2009 skrev Dan Dennedy: > > I have a patch ready to implement sequential rendering (one job after > > another). Do you think there is any reason to keep parallel rendering or > > can I get rid of it? > > I think since MLT has multi-threading, and we are trying to increase > the parallelism, that sequential-only makes sense. If this were > managing a clustered rendering system, it would be a different story But isn't it the case that only a few encodings work well with the multithreads in ffmpeg? > > :-). Also, eventually MLT will have a multi-consumer option to allow a > > single decode and processing, and that will output in parallel. > However, that will require other changes in the dialog. Until this is in place, why not keep parallel rendering in? I can easily imagine encoding on an 8 core machine, would be a shame not to be able to utilize it fully in some use cases. Regards Mads -- Mads Bondo Dydensborg ma...@dy... http://www.madsdydensborg.dk/ United States Patent 6,368,227: A method of swing on a swing is disclosed, in which a user positioned on a standard swing suspended by two chains from a substantially horizontal tree branch induces side to side motion by pulling alternately on one chain and then the other. -- This is not a joke - go look it up. |
From: Dan D. <da...@de...> - 2009-05-11 17:16:19
|
On Mon, May 11, 2009 at 3:03 AM, Mads Bondo Dydensborg <ma...@dy...> wrote: > Fredag 08 maj 2009 skrev Dan Dennedy: >> > I have a patch ready to implement sequential rendering (one job after >> > another). Do you think there is any reason to keep parallel rendering or >> > can I get rid of it? >> >> I think since MLT has multi-threading, and we are trying to increase >> the parallelism, that sequential-only makes sense. If this were >> managing a clustered rendering system, it would be a different story > > But isn't it the case that only a few encodings work well with the > multithreads in ffmpeg? Yes, but the most popular ones including MPEG-2, MPEG-4, H.264, and DV. Besides, in MLT, at the minimum, the reading, demuxing, decoding, and processing takes place on one thread, the encoding on another, and the control and monitoring in another. Also, I am soon able to put the reading, demuxing, and decoding of each clip into its own thread, which will help a lot during transitions. Not to mention that FFmpeg can do multi-threaded decoding of some formats. That is already a lot of parallelism for today's standards, which admittedly is changing quickly. >> :-). Also, eventually MLT will have a multi-consumer option to allow a >> >> single decode and processing, and that will output in parallel. >> However, that will require other changes in the dialog. > > Until this is in place, why not keep parallel rendering in? I can easily > imagine encoding on an 8 core machine, would be a shame not to be able to > utilize it fully in some use cases. I am not opposed to it, but I think it should default to not parallel. I also propose a preference item to set the number of encoding threads, and that would add a 'threads' property to the render job. It should probably take into consideration that the decode and encode are currently separate, heavy threads and use N-1. Maybe this same item can determine whether and how many jobs can run in parallel, but that could be somewhat tricky to implement - if not rather handy! -- +-DRD-+ |