Installation
Installation and service operation
The vod2cbm service is distributed as a CentOS/Red Hat RPM and is available
as ew-vod2cbm.service when installed. It works both on RH 7 and 8 and
compatible versions.
To install version x.y.z, the rpm command can be used as follows:
yum install ./ew-vod2cbm-x.y.z-1.el8.x86_64.rpm
The service can be controlled with the standard systemctl commands:
systemctl start ew-vod2cbm
systemctl stop ew-vod2cbm
systemctl status ew-vod2cbm
Logs from the service can be seen using journalctl -u ew-vod2cbm.
The unit file is available in /usr/lib/systemd/system/ew-vod2cbm.service and
starts ew-vod2cbm, serving port 8090 by default.
When run as a service, ew-vod2cbm reads its initial configuration from
/etc/edgeware/ew-vod2cbm/config.json. The configuration may contain a schedule
for looping channels. Non-looping channels must be created over the Channel
REST API. For details on scheduling please refer to the
API Reference
To uninstall the service, do:
yum remove ew-vod2cbm
When uninstalling or upgrading it is recommended to first stop the service.
1 - Upgrades
Upgrade of ew-vod2cbm
Upgrade to v1.2.x from v1.0.x
There is a new parameter padLastGop in the REST API,
as well as the local JSON configuration for a channel/schedule.
If that is not set, a last shorter GoP will be truncated from
an asset. Set it if you want the new padding functionality to
be applied.
Upgrade to v1.0.x from v0.10.x
The main new thing is the online license file that must be
available in order to run the service fully.
Upgrade to v0.10.x from v.0.8.x
The command-line parameter -gopdurms is no longer needed or supported.
The config file is also no longer mandatory.
The command-line parameter -s3 has changed name to -s3file.
Upgrade to v0.8.x from v.0.6.x
The segmentation and splicing is now based on GoPs instead of segments.
There is a new mandatory parameter, defaultGopDurMS that must
be provided in the configuration file, or provided as a command line option
-gopdurms.
The config file has changed to be based on GoPs instead of segments.
Therefore, there are a few new parameters for each channel:
"segDurMS" -> "gopDurMS"
"combineNrSegs" -> "nrGopsPerSegment":
Here, the gopDurMS must be the GoP duration for all input
video variants of all input content. The actual segment duration
of the content is not relevant. The end GoP may be shorter,
but is then dropped.
The input segment duration is not fixed, as long each video segment consists
of an integral number of GoP. The output segments are generated by combining
nrGopsPerSegment GoPs, with a possible adjustment where ads start and stop.
Another update of the channel configuration is inside “schedule” where
"Programs" -> "Entries"
For dynamics schedules, it is recommended to use the
REST API to handle channels.