https://github.com/MotionSpell/signals

A C++11 modular framework
https://github.com/MotionSpell/signals

Last synced: about 1 year ago
JSON representation

A C++11 modular framework

• Host: GitHub
• URL: https://github.com/MotionSpell/signals
• Owner: MotionSpell
• License: bsd-3-clause
• Created: 2015-03-21T10:34:09.000Z (over 11 years ago)
• Default Branch: master
• Last Pushed: 2025-05-09T18:11:35.000Z (about 1 year ago)
• Last Synced: 2025-05-09T19:25:06.490Z (about 1 year ago)
• Language: C++
• Homepage:
• Size: 5.91 MB
• Stars: 10
• Watchers: 10
• Forks: 7
• Open Issues: 1
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

          


**Table of Contents**  *generated with [DocToc](https://github.com/thlorenz/doctoc)*

- [Signals](#signals)

- [Introduction](#introduction)

- [Applications](#applications)

- [Build](#build)

- [Tests](#tests)

- [Documentation](#documentation)

Signals

=======

# Introduction

Signals is a modern C++ framework to build modular applications. It is currently used for building multimedia applications. Its architecture allows to extend to any domain. Signals is used by companies from the multimedia industry (audio, video and broadcast).

Signals is designed with the following goals:

 - Writing new modules must be easy and require minimal boilerplate. Especially for multimedia systems, you should not have to know about complex matters (types, internals, clocks, locking, ...) unless you need to ; according to our experience 90% of the applications use the same mechanisms.

 - Writing an application using these modules must be easy.

# Applications

Signals comes with several multimedia applications:

 - player: a generic multimedia player.

 - dashcastx: a rewrite of the GPAC dashcast application (any input to MPEG-DASH live) in less than 300 lines of code.

# Build

Please read [build.md](doc/build.md).

# Tests

Signals is built using TDD. There are plenty of tests. If you contribute please commit your tests first.

Unit tests should be self-validating, which means they shouldn't need the intervention of a human operator to validate the result (e.g, they shouldn't print anything on the console).

They should also be isolated. At best, they should depend upon no third-party code (except of course when testing the code making the direct calls to a third-party component).

You can check the code coverage of the test suite using ./scripts/cov.sh. This will generate an HTML report using gcov+lcov in 'cov-html'.

# Documentation

Documentation is both a set of markdown files and a doxygen. See in the [doc subdirectory](doc/).