FWIW, you'll have the same problem with virtually all non-streaming formats, because they require writing the headers AFTER having outputted/processed the contents (aka: It's not a problem with GStreamer but with the format you're trying to use).

Using fast-start is just a 'hack' for what you should really be doing:
* Outputting to a file,
* Reading from that file afterwards (once it's written the headers).

Either:
* use fast-start (which will internally use a temporary file and not outputting anything before it's processed the *WHOLE* input), BIG LATENCY.
* use filesink. And read the file afterwards.
* Or finally use a streaming format (like ogg or mpeg-ts).

Be that as it may, I think all such muxers should output at least a warning, if not an error, in this case. Writing broken files and not even telling the user about it isn't cool.

We should be able to detect whether downstream supports 'seeking' or not, either via a SEEKING query on start-up and/or at the end when we push the newsegment event before rewriting the header (if the push fails because we're shutting down posting an error should be fine as well, since we can probably assume it will be dropped as the bus is flushing)

I might be missing a point/code/API, but it seems that a (base)sink (so also appsink) typically gracefully accepts a newsegment event in any case, so no way to know something went wrong there.  Any (downstream) QUERY_SEEKING handling seems not in place either.

You're right. I thought we added the query at least to filesink at some point, but it seems not. Still, I think we *should* be able to query this one way or another, so we can do the right thing.

What are the suggested options here? Forward the query/event in basesink and let the implementing class decide?

I guess appsink should have a seek-data signal so that application can do the right thing. 

Again, using appsink for these things is not the right thing to do. You would be better off writing a gstreamer plugin to handle all cases correctly.

So there are multiple things to fix here:
a) seek signal in appsink
b) SEEKING query handling in basesink
c) NEWSEGMENT event handling basesink

Anybody going to work on this? :)

It sounds liek a corner case. Could qtmux atleast throw an error for now?

SEEKING query is now implemented in many sinks, and I believe qtmux defaults to streamable=TRUE now if downstream is not seekable (and logging a warning into the debug log).

Can this be closed ? If not, what's left to do?

Sebastian, can we close this now ?

I think so