Filesink truncates file on GST_EVENT_FLUSH_STOP

Why does filesink truncate file on GST_EVENT_FLUSH_STOP event?

Recently I have been debugging a moderately complex pipeline that receives video and audio from several sources, merges it using matroskamux and saves into file using filesink. The problem was that upon ending the recording, the file became corrupted each time audio was present. Fast-forwarding a few days of debugging and headache, I found the culprit: an audio source generates fllush event for some reason, which matroskamux sends forward and filesink receives (thus destroying recorded data).

But why does filesink have such a destructive response to GST_EVENT_FLUSH_STOP at all? According to the documentation: “A flush event is sent both downstream and upstream to clear any pending data from the pipeline”. Nothing is ever said about deleting data from filesystem. Such behaviour is hard to expect without carefully reading source code.

A flush start/stop usually doesn’t just clear out pending data, but also resets things incl. the timeline back to 0, so it’s not as unreasonable a behaviour as it might seem.

Sources usually don’t send flush events by themselves, that would usually be triggered by a flushing seek requests (although the adaptive demuxers do/did that at some point in some circumstances I think, a fix for which was either recently merged or is pending in gitlab IIRC).