Decklink Input missing back pressure

[sirfnomi]

Expected behaviour

play 1-1 Decklink 1 should play Decklink input with some buffer memory usage

Current behaviour

After this command system memory increasing continuously

---

Environment

• Server version: [v2.2 Beta 9]
• Operating system: [Windows 7]

---

[premultiply]

Is it the same if you loop the channels main decklink output back to the input? Dont care about video- and audiofeedback for this test. It is just about reference timing.

[sirfnomi]

after looping (Decklink Out to Back Decklink Input) memory usage is now normal.
one more thing i get warning in server console "in-sync changed"

[premultiply]

@ronag Obviously there is no frame synchronizer behavior for live inputs implemented yet.

If the SDI source is not genlocked to the output's clock reference then you will run into trouble sooner or later. Else if they are running on same timebase everything is fine.

In this case the input clock is running faster then the output (or channel?) clock and will buffer more and more frames into memory as they are read slower from frame buffer as they are written.

[ronag]

You might be right. I might look to it when I have time. Otherwise a PR is also welcome.

[sirfnomi]

ok, today i update Graphics Driver from some 2015 version to latest 2018. after this memory issue has been gone and also not getting any in-sync warning.

Graphics Card: Quadro K4000

[sirfnomi]

should i close this ??

[jesperstarkar]

I don't think so, as this should be considered a bug in my opinion.

[ronag]

This is a problem when you already have a problem, i.e. you are ingesting frames faster than you can handle... there are two ways to handle that, either you keep buffering or your start dropping... I guess dropping is the proper way to handle this though

[premultiply]

This would be only no problem when all(!) inputs and outputs are in perfect sync (genlocked to same sync source, professional environment).
But users try to ingest free running „standalone“ cameras, webstreams etc. These will be „faster“ or „slower“ then the internal „CasparCG Clock“. So buffers will underrun or overflow.
The same for the outputs and cross channel routing.

So the main basic question is at first: What is the clockmaster in CasparCG?

[ronag]

@premultiply: ah, very true, currently it's the slowest consumer with lock capabilities

[premultiply]

Then first of all this should be changed in geberal to a more predictive behavior.
For example clock of first output (consumer) of first channel.
Then all other channels have to run on this clockbase only. This is nessasary to allow for no delay routing of layers between channels.
Then all producers have to lock the the channel clock with an internal frame sync behavior (drop or double input frames if not in sync). Same for audio.

Means if all sources and outputs are genlocked the whole system will allow for lowest delay without any dropped or doubled frames.
If a source is not genlocked it may drop or double some frames over time - like any hardware mixer does.