Hi, Sorry to take so long to write this email, it's the one I mentioned about two weeks ago :-)
Currently, the cutter is responsible for accepting a "cutting list" and a number of movie, audio and picture files as input, and producing a single movie file as output. There are a couple of problems with this definition. Most importantly, there is no encapsulation of a "device". By this, I mean that if the cutter is only capable of reading and generating MJPEG files, then the user interface needs to suport MJPEG files itself. If another cutter supports DV AVI files, then the user interface needs expicit support for DV AVI files. And so on. Essentially, the user interface should always support the exact formats that the cutter provides, and even if I was to embed one of the best Linux movie players into the interface, I can't guarantee that this will be the case. My suggestion is that the cutter needs to be in charge of supplying the GUI with the pictures it wants to display, and essentailly be capable of performing all necessary manipulations on the video including playback. One problem with this - throwing frames from one process to another is going to be *slow*. So it makes more sense that the video is run entirely in the cutter, but remote controlled from the user interface (which won't be as slow). This suggests that the cutter has it's own player window, which then gets embedded into the user interface monitor window. This is going to mean a lot more work happens in the cutter than I had originally thought we would need, but I believe it is a more scalable and managable solution (to multiple cutters/multiple user interfaces) that what we would have otherwise. What do you think? Cheers, Jason -- Jason Wood Homepage : www.uchian.pwp.blueyonder.co.uk
