search

CasparCG / server

CasparCG Server is a Windows and Linux software used to play out professional graphics, audio and video to multiple outputs. It has been in 24/7 broadcast production since 2006. Ready-to-use downloads are available under the Releases tab https://casparcg.com.
GNU General Public License v3.0
913 stars 268 forks source link

Decklink producer/consumer stops to work when not stopping same command #1012

Open PeterAkakpo opened 6 years ago

PeterAkakpo commented 6 years ago

Expected Behaviour

Decklink producer and consumer should behave just like the ffmpeg producer and consumer or should give a message saying the device is already in use, when a PLAY or ADD command is issued repeatedly on the same device.

Current Behaviour

The decklink device crashes, further commands to it does not work issuing PLAY 1-0 DECKLINK 1 outputs to the device. issuing same command again without first stopping the layer crashes the device, and further commands to it doesn't work.

Steps to Reproduce

Issue a command similar to this PLAY 1-0 DECKLINK 1 PLAY 1-0 DECKLINK 1 (this crashes the device)

ADD 1-99 DECKLINK DEVICE 1 FORMAT PAL ADD 1-99 DECKLINK DEVICE 1 FORMAT PAL (this crashes the device)

Environment

Attachments

Julusian commented 6 years ago

From what I remember when accidentally doing something similar, but I don't think it actually crashes the device. An exception is logged when it tries to start the second stream as the device is already in use, but the original will keep running.

It could be that for you the second PLAY/ADD is causing the first instance of the producer to stop, before the new one fails to initialise but that needs verifying

PeterAkakpo commented 6 years ago

yes it stop the first instance and the new one fails to initialize (when that happen, the screen goes black) and any further decklink command also fail until you restart casparcg server, that's what i meant by crashing.

Julusian commented 6 years ago

I am not getting any crashing when trying this. After it fails to initialise, the next attempt will complete successfully.

I think this behaviour can be called expected (not a bug). When running PLAY, the new producer fails after being loaded, at which point the old producer is being destroyed as expected, leaving with no producer. When running ADD, the old consumer is discarded first (it doesnt get destroyed for a frame or so until buffers are flushed), with the new one added and then immediately failing to initialise.

There is scope to improve on it though, especially in the logging, but this could easily be guarded against in a client.