I’ve done some searching, but can’t seem to find an answer for this. If I
set up a stream in ffmpeg with a decklink card as the source (autodetecting
input), that works fine. If I then change the source (from 1080p30 to
1080p25, for example), the stream continues as a colour bar (as if the
signal did not return). The only indication that there was a change is a
single dropped frame. I can (theoretically) crash ffmpeg on this drop and
restart, but I would prefer not to have ffmpeg stop every time a frame is
Is there a better method of detecting a signal change? I do not need ffmpeg
to gracefully handle it (I am OK with stopping and restarting when this
happens), but I do need a way to catch when a different input is plugged in.
On Sunday, September 9, 2018 5:53:03 PM CDT Chris Bisset wrote:
> Is there a better method of detecting a signal change? I do not need ffmpeg
> to gracefully handle it (I am OK with stopping and restarting when this
> happens), but I do need a way to catch when a different input is plugged in.
The assumption made with video signal capture is that the format will remain
consistent and unbroken. This is the reason it generates color bars when input
signal is changed, to retain continuity. (Though if there is a dropped frame
then that is not working very well). There is really no way (via ffmpeg) to
deal with that, it’s just not within the scope of what it’s designed to do.
You might poke around in the SDK and see if there is a way you register a
callback to provide notification when the input changes, and then use that as
a mechanism to restart the ffmpeg process.