Re 'quote in parameters needing to be escaped' ok, I understand that.

Don't get me wrong, I'm all for better code.  I just don't think that's what we're talking about here.  The better option I think is to introduce something like property tree as the 'option carrier' for producers / consumers.  This structure is sufficiently flexible to carry the options of all the prodcuers / consumers while providing a common interface, and would easily support the scenario here.

In this patch, given that 'the better option' isn't currently a realistic option at this time. Is this patch an adequate implementation, given that we know its already not the best option.

I do continue to favour the option of a protocol structure like this:

  space delimited caspar parameters on the left -- space delimited ffmpeg parameters on the right.
  
I prefer that over:

  space delimited caspar parameters on the left ffmpegOptions "All the ffmpeg options in a string"

The second options seems unnecessarily nested to me.  Hence my 'clunky' comment.  But supposing we were to go with that strategy, that would mean that we tokenize / parse the nested set of options.  This could either be done in the protocol parser / command impl or in the ffmpeg producer / consumer directly.  I kind of had the impression that the producers / consumers should not be involved in command protocol details, but would be passed populated data structures representing their options.  Certainly that's the case with some of the more core components. e.g. The way that the protocols interact with the mixer for example.  That's why I think the 'better option' is for the producers / consumers to accept a property tree which would easily accommodate multiple 'realms' as we are discussing now and further remove protocol details from the producer / consumer.

ffmpeg I think, is a special case.  I think it is ok for us to say that ffmpeg is very fully featured, more feature full than we are willing to directly support in caspars protocol directly.  Therefore we are allowing developers of clients to pass arbitrary ffmpeg parameters in and 'see what happens'.  Over time I can imagine introducing features into the config file, and command protocol to facilitate making complex commands easier.  It could easily be argued that this is an unsafe thing to do; allowing users to put in arbitrary ffmpeg parameter.  But, I think in this case such a feature is beneficial.  It allows users to experiment, giving the rest of the community valuable feedback.  So, I'd like to suggest that allowing ffmpeg (and only ffmpeg) to have this special case feature is actually a good thing to do.

Re 'clients having special case code'.  Isn't that true of any new feature?  Not quite sure I understand what you mean.  e.g. For the introduction of the chroma code, or dshow usb camera clients would need new code to support the feature (unless the client is say putty).  Seems to me that all options on the table right now are not breaking changes (i.e. old clients continue to work as they have), and that clients would require code changes to take advantage of the new features exposed.

As I said at the top.  I'm happy to go with better options.  I'm just not convinced sufficiently to spend the time on any of the alternative options described so far.