-
Notifications
You must be signed in to change notification settings - Fork 268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exception thrown when adding an existing Decklink consumer in PAL format (identified for Quad 2 cards) #1449
Comments
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. |
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. |
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. |
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 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 CasparCG/help#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. 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.
The text was updated successfully, but these errors were encountered: