I have had a look at the above, and AFAICS (a.o.):
- the fragmented moov size (property) added early on is not really used/useful
- buffer collection is forced to stay on a single pad for a certain fragment-duration.  Depending on this duration, and the settings of upstream queues, there is a risk that dataflow deadlocks.

In particular, it is preferable not to introduce the latter risk in the muxer, and it can likely be avoided using qtmux-in-house buffering (either in memory or file, for which code is already in place in some or the other form).

As such, going forward on this qtmux feature, I'll be using a fair share of the provided branch, but reorganize/modify to address above concerns and some other matters of consistent qtmux-style.  Also, some commits seem not directly related to fragmented support as such (which is not to say they are without merit).

Following is a "token commit" as obviously more than 1 was needed (but a whole git-log dump is not all that informative).  All together they should cover functionality that is provided in the aforementioned branch, notable exception (for now) being the wmv/wma support.  Feel free to provide comments/patch etc if something is amiss.

commit 68d5ab1a1dff106134cc645e2de25ba1ead07e80
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Mon Nov 15 15:17:59 2010 +0100

    qtmux: optionally create fragmented file
    
    In this mode, an initial empty moov (containing only stream metadata) is written,
    followed by fragments containing actual data (along with required metadata).
    New fragments are started either at keyframe (if such are sparse) or when
    property configured duration exceeded.
    
    Based on patch by Marc-André Lureau <mlureau@flumotion.com>
    
    Fixes #632911.