It simplifies things if getPipeline handles creation and starting
of the revid pipeline. We don't need to be doing this in multiple
places.
Approved-by: Trek Hopton
This change improves the mechanism that deals with recv requests
from non active macs. We're no only logging every minute so that
we don't clutter the logs. We're also dealing with both non active
and slate recvs with the same mechanism using a switch.
For control requests, we only update aspects of the broadcast if
they have changed. Therefore, if the urls list has not changed
the revid pipeline is not updated, similarly if the status has
not changed, we don't do anything there.
This change adds a file watcher and then uses this file watcher
to perform updates based on changes in a configuration file. This
configuration file contains logging parameters for the time being
in the hope that it will help with debugging.
Testing was also added for this functionality.
This change modifies vidforward to accept multiple RTMP URLs in
its control request handler. This allows for the creation of a
revid pipeline for a mac with multiple RTMP outputs.
This change adds functionality for broadcastManager state save.
This is done by marshalling the broadcastManager and saving to a
file. Loading is performed by unmarshalling an re-populating a
broadcastManager value. Testing has been added for this
functionality. Other functionality has been added a side effect.
This change adds a "watchdog notifier" utility which tracks the
health of request handlers and notifies an external systemd
watchdog if everything looks good. This allows us to cause a
termination if any request handlers get hung.
This includes adding facilities to handle termination signals
and err handling. Some modifications have been made to the file
input to accomodate the concurrency requirements. The slate
read mechanism is still fairly rudimentary and can only read
from a hardcoded file, but at this stage is for prototyping
purposes.
This change removes usage of netsender to provide remote
configuration of the service and replaces with a basic control
REST API with PUT and DELETE methods. PUT requests add or update
a broadcast, and DELETE removes a broadcast. In addition to these
changes, some modification of the NOOP lexer has been performed
including tuning of the controller.