Hi. I'm interested in knowing if it's possible to use openMosix, DistrIT, or something like that, to distribute or parallelize Mencoder? I understand that this isn't an incredibly easy thing to ask for, especially when someone is working with a task like mencoder, but is there a way to split up the individual tasks, like having one machine work on audio, one machine on video resizing/ filters, one machine on compression, anything like that? Also, would it be possible to have this work in an environment of mixed systems/archetectures? I'm running Windows, Linux, and Mac OS X machines on my LAN, and with lots of idle CPU power sitting around, I figure I might try and distribute the load. Duct Tape Tip No. 23: Tape furnace ductwork* *We have never actually tried this one, and have no idea if it works. Therefore, we can only suggest this use, not actually recomend it. --The Duct Tape Book by Jim and Tim
On Thursday, 05 May 2005 at 23:08, Kichigai Mentat wrote:
Hi. I'm interested in knowing if it's possible to use openMosix, DistrIT, or something like that, to distribute or parallelize Mencoder?
No, it's not possible. MEncoder is one-threaded and this won't change in the foreseeable future. Regards, R. PS. Don't send HTML mail to this list. -- MPlayer RPMs maintainer: http://rpm.greysector.net/mplayer/ "I am Grey. I stand between the candle and the star. We are Grey. We stand between the darkness ... and the light." -- Delenn in Grey Council in Babylon 5:"Babylon Squared"
On Thu, 5 May 2005 23:32:41 +0200 Dominik 'Rathann' Mierzejewski <dominik@rangers.eu.org> wrote:
MEncoder is one-threaded and this won't change in the foreseeable future.
Mencoder may be single-threaded, but lavc isn't so limited. Just look for "threads" in the manual.
On Fri, May 06, 2005 at 06:00:26AM -0700, RC wrote:
On Thu, 5 May 2005 23:32:41 +0200 Dominik 'Rathann' Mierzejewski <dominik@rangers.eu.org> wrote:
MEncoder is one-threaded and this won't change in the foreseeable future.
Mencoder may be single-threaded, but lavc isn't so limited. Just look for "threads" in the manual.
Still splitting it across different machines will make it slow as hell. Rich
On Fri, May 06, 2005 at 06:00:26AM -0700, RC wrote:
On Thu, 5 May 2005 23:32:41 +0200 Dominik 'Rathann' Mierzejewski <dominik@rangers.eu.org> wrote:
MEncoder is one-threaded and this won't change in the foreseeable future.
Mencoder may be single-threaded, but lavc isn't so limited. Just look for "threads" in the manual.
Still splitting it across different machines will make it slow as hell. Do you mean that due to the process of forcing lavc to parallelize over multiple machines, it will be as slow as hell, or that in
On May 6, 2005, at 10.33, Rich Felker wrote: theory, parallelizing a mencoder job period would be slow as hell?
Rich
_______________________________________________ MPlayer-users mailing list MPlayer-users@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-users
Hi, On Fri, May 06, 2005 at 03:06:50PM -0500, Kichigai Mentat wrote:
Still splitting it across different machines will make it slow as hell. Do you mean that due to the process of forcing lavc to parallelize over multiple machines, it will be as slow as hell, or that in
On May 6, 2005, at 10.33, Rich Felker wrote: theory, parallelizing a mencoder job period would be slow as hell?
Well, there is lots of data to shuffle around, so you would at least need an extremely fast network - since I doubt that you have something like Myrinet or infiniband lying around I'd say there are more effective ways of speeding things up. Well, you might be able to encode files in parts (first PC first hour, second PC second hour) and then create one big file out of them, but that sure is non-trivial and might have not-so nice side-effects (not exactly fitting together, A-V desync etc. Greetings, Reimar Döffinger
Hi, On Fri, May 06, 2005 at 03:06:50PM -0500, Kichigai Mentat wrote:
On May 6, 2005, at 10.33, Rich Felker wrote:
Still splitting it across different machines will make it slow as hell.
Do you mean that due to the process of forcing lavc to parallelize over multiple machines, it will be as slow as hell, or that in theory, parallelizing a mencoder job period would be slow as hell?
Well, there is lots of data to shuffle around, so you would at least need an extremely fast network - since I doubt that you have something like Myrinet or infiniband lying around I'd say there are more effective ways of speeding things up. Well, you might be able to encode files in parts (first PC first hour, second PC second hour) and then create one big file out of them, but that sure is non-trivial and might have not-so nice side-effects (not exactly fitting together, A-V desync etc. Actually, I was thinking about that, in a way. Less of chopping the video up, time segment by time segment, but dividing the entire
On May 6, 2005, at 15.30, Reimar Döffinger wrote: process up, task by task. One machine do video decompression and resizing, one do audio processing, one do deinterlacing and re- encoding, or something like that.
Greetings, Reimar Döffinger
_______________________________________________ MPlayer-users mailing list MPlayer-users@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-users
On Fri, May 06, 2005 at 03:32:01PM -0500, Kichigai Mentat wrote:
Actually, I was thinking about that, in a way. Less of chopping the video up, time segment by time segment, but dividing the entire process up, task by task. One machine do video decompression and resizing, one do audio processing, one do deinterlacing and re- encoding, or something like that.
Ok, so you have one machine that decodes, and another that encodes. In between the video is uncompressed, right? Then how are you going to transmit video form one machine to another? Yes, I know, you have network, but this is REALLY some data. Let's see 640x272 24bpp 25.000 fps video. Thats 640*272*3=522240 bytes per frame, 25 frames per second. Suppose the movie is 2 hours long. That means you have 522240*25*60*60*2=87 GB of data to transmit via network. How long is that going to take? I don't think it's gonna be much faster than encoding at a single machine. Torinthiel -- Waclaw "Torinthiel" Schiller GG#: 542916, 3073512 torinthiel(at)megapolis(dot)pl gpg: 0906A2CE fpr: EE3E DFB4 C4D6 E22E 8999 D714 7CEB CDDC 0906 A2CE "No classmates may be used during this examination"
On Fri, May 06, 2005 at 10:30:46PM +0200, Reimar Döffinger wrote:
Hi, On Fri, May 06, 2005 at 03:06:50PM -0500, Kichigai Mentat wrote:
Still splitting it across different machines will make it slow as hell. Do you mean that due to the process of forcing lavc to parallelize over multiple machines, it will be as slow as hell, or that in
On May 6, 2005, at 10.33, Rich Felker wrote: theory, parallelizing a mencoder job period would be slow as hell?
Well, there is lots of data to shuffle around, so you would at least need an extremely fast network - since I doubt that you have something like Myrinet or infiniband lying around I'd say there are more effective ways of speeding things up.
No, the network needs to be infinite speed in order not to slow it down. The entire encode process is memory-io bound; processing takes essentially 0 time. Even if the network is as fast as main memory (in practice it's at least 10-100 times slower) it would still make encoding take twice as long. If you want to distribute encoding, there are some decent ways to do it, like encoding audio on a separate machine then muxing later. No special distributed-computing crap is needed for this. Just run separate processes on each computer. Rich
"The real problem with hunting elephants is carrying the decoys." (fortune spew) On May 6, 2005, at 15.57, Rich Felker wrote:
On Fri, May 06, 2005 at 10:30:46PM +0200, Reimar Döffinger wrote:
Hi, On Fri, May 06, 2005 at 03:06:50PM -0500, Kichigai Mentat wrote:
On May 6, 2005, at 10.33, Rich Felker wrote:
Still splitting it across different machines will make it slow as hell.
Do you mean that due to the process of forcing lavc to parallelize over multiple machines, it will be as slow as hell, or that in theory, parallelizing a mencoder job period would be slow as hell?
Well, there is lots of data to shuffle around, so you would at least need an extremely fast network - since I doubt that you have something like Myrinet or infiniband lying around I'd say there are more effective ways of speeding things up.
No, the network needs to be infinite speed in order not to slow it down. The entire encode process is memory-io bound; processing takes essentially 0 time. Even if the network is as fast as main memory (in practice it's at least 10-100 times slower) it would still make encoding take twice as long.
If you want to distribute encoding, there are some decent ways to do it, like encoding audio on a separate machine then muxing later. I think I mentioned that, but not in so many words. No special distributed-computing crap is needed for this. Just run separate processes on each computer.
Rich
_______________________________________________ MPlayer-users mailing list MPlayer-users@mplayerhq.hu http://mplayerhq.hu/mailman/listinfo/mplayer-users
participants (6)
-
Dominik 'Rathann' Mierzejewski -
Kichigai Mentat -
RC -
Reimar Döffinger -
Rich Felker -
Torinthiel