[Bf-committers] Remove Frameserver

[Dan McGrath]

Peter,

+1

When this particular thread started, I was thinking along the lines of
not many people that use this particular feature may actually read
this list and be aware that there was discussion to remove it, and
that it may upset some people who do use it in their pipeline somehow.

I have to thank you though, since before your reply, I never really
understood the purpose of the frameserver. It does sound like it is a
very useful tool to have in at least some form though (ie: python).
Neat that it interfaces with something like virtualDub.

What concerned me when I originally seen the post was that it was
falling under a category of being removed because of a bug report that
nobody (wanted to|knew how to|had time to) fix, and was simpler to
just erase it. In general not a very good thing to get in the habit of
doing, IMHO.


Dan

On Sun, Aug 5, 2012 at 5:18 AM, Peter Schlaile <peter at schlaile.de> wrote:
> 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
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers