Open leftearsons opened 1 year ago
I just identified that the issue is also present when using 720p5000 output format, but with a much lower frequency (it occured 4 times during two days, when regularly re-adding the Decklink consumer every one hour).
This behaviour has been around for as long as I can remember, at least since 2.1. It happens because destroying the old consumer gets done asynchronously, and so initializing the new producer happens first resulting in the failure as the decklink is still in use. I don't have any ideas on an easy fix for this, as it needs to be done asynchronously.
I don't have any ideas on an easy fix for this, as it needs to be done asynchronously.
Just issue a REMOVE command first and the ADD command a few seconds later (from the client).
Indeed @didikunz, that is an easy and obvious workaround, but does not actually solve the problem because the output would become black for those seconds, which of course is not acceptable.
the output would become black for those seconds, which of course is not acceptable.
I expect that having some black on the output is unavoidable. Even if CasparCG were to handle this case correctly, it would still be closing and re-initialising the decklink. At best it may freeze for some frames, but it could also show some black.
Thanks for your comment @Julusian. The fact is that on version 2.07 that i was last using before switching to 2.3.3, there was no freeze or black frames in between when CasparCG was auto reloading the SDI output.
Interesting.. I would have thought that because the decklink is being prerolled with black, that it would actually output that..
But the key change is that in 2.0 producers and consumers were destroyed synchronously, in 2.1 and later this is being done asynchronously. The benefit being that if removing a consumer/producer (where there arent the same access limitations) takes some time, the new consumer can start being created before that destruction completes. I am struggling to see much benefit for consumers, as they are so rarely changed so am open to rethinking this, but that requires time.
I do think you have a very unusual use case here though, what is the reason for needing to remove and readd the same decklink to a channel?
@Julusian thank you for your time. The real reason for using this "technique" (reload an SDI output), is to deal with audio disappearing issue https://github.com/CasparCG/help/issues/24
In practice, for PAL and 720p5000 formats i was reloading the SDI output every 1 hour, while for 1080i5000 format i was reloading the SDI output every 30 minutes. This way, the audio buffers (as shown in the diagnostics window) were resetting while no black or frozen frames would exist in the channel output (at least up until version 2.07).
Based on the design you described above, what about using a synchronous approach only when the exact same producer/consumer is already in use?
Expected behaviour
When adding a Decklink consumer to a channel, we would expect it to be added successfully, regardless of whether the consumer is already added or not, regardless of the channel output format and regardless of the Decklink card type used (Quad 1 or Quad 2).
Current behaviour
When adding a Decklink consumer to a PAL configured channel, in case the Decklink consumer is already added and the Decklink card type is Quad 2, an exception is thrown preventing it from loading successfully.
For non-PAL output format (720p5000 & 1080i5000 have been tested), as well as for Decklink Quad 1 cards, the issue is not present, allowing the Decklink consumer to be added successfully.
Below is the error log output after running the steps below:
Steps to reproduce
ADD 1 DECKLINK 1 EMBEDDED_AUDIO LOW_LATENCY
ADD 1 DECKLINK 1 EMBEDDED_AUDIO LOW_LATENCY
Result: An exception should be thrown and the Decklink consumer should be forcefully removed from the channel
Environment
The issue is present on all versions from release
2.3.3 stable
forward.Issue was not present in version 2.07, but i have not tested versions in between.