[FFmpeg-devel] Politics

[Daniel Cantarín]

 >
 > Incidentally, the "fps" filter is probably one of the simplest examples
 > of a filter that does not involve subtitles which would benefit from a
 > "heartbeat" mechanism.
 >
 > Currently in order to be able to output a frame, the fps filter needs
 > to have 2 frames buffered (or alternately, one frame and a timestampped
 > status like EOF). In the case of a long timestamp gap, this means that
 > it will produce no output frames until such time as the next frame is
 > read, meaning that downstream filters will be stalled, and if there are
 > any multi-input filters downstream, one of the inputs might end up with
 > too many frames in its input fifo.
 >
 > If the fps filter could receive periodic activations with an indication
 > that "pts has increased on the input without any new frame available",
 > it could incrementally fill in the gap in realtime, allowing downstream
 > filters to proceed.
 >

OMG! Thank you! This is so revealing to me!

One of the blackest magic I had to deal with when using filtergraphs
with live streaming, was that downstream stall situation you describe.
I have one of such multi-input filters, and it dod indeed stalled. In
fact, this filter spects a subtitle-converted-to-image stream, and subs
streams happen to be sparse: may have minutes without data.

But I've found that _somehow, dont ask me why_, if I put a split filter
after some other filter which happen to have fps filter before it, and
later I send one of those splitted streams to a nullsink, then the
downstream filters do activate, and the process never stalls.
I guess now that the split creates 2 frames, and that's the reason.

But yeah, as you also understand, this was one of the reasons I was
about to make my own "hearbeat" or "filler frames" filter.

Thanks,
Daniel.