Hi Campbell, > Its helpful to remove because we shouldn't give users options that are > not useful/tested/ready-for-production...
> When you use software and get the impression that some parts are not > maintained - they crash or just fail, it doesn’t inspire confidence > you want when relying on software for important projects. Hmm. That's probably true. But I think, analyzing *why* something isn't used and how things can be done better is a lot more clever than just deleting code. Simply deleting the old plugin infrastructure without providing a new one, caused already a lot of grief with old plugin developers. The message to those developers was: well, we don't use it, so noone ever will, let's delete it. Please go away, find yourself another project. Not very nice! > I had a look over the frameserver docs: > http://wiki.blender.org/index.php/Dev:Source/Render/Frameserver > ... but I'm still not convinced this is really worth keeping - its 8 > bit channels. no alpha, no compression, Uhm, well, but you already noticed, that most video encoding engines do actually only work in 8 bit, right? With no alpha. And compression is the job of the encoding engine not the frame server. > that it can be setup to work > with scripts over a network is clever but not generally useful IMHO. the frame server is build as a simple HTTP-Server and keeps a directory hierarchie and could as well serve out EXR-frames or PPMs with other options, or PNGs, whatever you like. 8-bit PPMs with no compression were chosen in the first place, since the main intend was to provide a general interface to arbitrary video encoding engines. > This could be put in a similar category as "Compiling blender as a > python module" - its nifty and maybe very useful in some cases, but > I'd prefer to disable for regular builds (if not remove). Nope. Frameserving is pretty much standard. In video editing apps (take a look at VirtualDub). It's sad, that we haven't brought the sequencer to the state, where it is generally accepted as a video editor, but having some sort of frame serving functionality is certainly a must, if we want to. The reason why people seldomly report bugs in the sequencer is caused by the simple fact, that not so many people use blender as a video editor at all. The only way to master a DVD without the frame server in current blender is using a directory of still frames and do the encoding from the still frames. (You can't use ffmpeg in one pass mode for that and: you most probably won't use ffmpeg at all, if quality is of any concern :) .) Do that on long time lines (say: 3 hours) and watch your hard disk explode. The only reason, why I (as the author of the frameserver) haven't noticed it crashing for a long time, was the simple fact, that I don't create DVDs anymore. But you will certainly agree, that DVD creation is somewhat important? It wasn't just very important to me lately, that's why we got those unnoticed breakages in the first place. That said: it may be possible to add the same functionality using the current python interface (which you do know a lot better than me). I have no problems with the idea of moving the whole frame server functionality into a python add-on (if that is possible at all), provided that we *do* have such a functionality somewhere. Regards Peter _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
