Right now, there are some applications or library of SRS:
- Binary
objs/srs, generated by core/kernel/protocol/app/main.
- Binary
objs/srs_hls_ingester, generated by core/kernel/protocol/app/main. But, it's not compatible with config object, so it set the _srs_config to NULL. That's rediculous.
- Library
objs/lib/srs_librtmp.a, generated by core/kernel/protocol.
- Binaries
objs/research/library/*, generated by research and srs_librtmp.a.
SRS also support modules, for example, srs_hls_ingester is a module. For all SRS modules, the config object doesn't works well, because the config object is only for objs/srs. In another word, some objects are not available for modules, so we extract a service in src/service for modules.
Please refer to the arch https://github.com/ossrs/srs/tree/develop#modularity-architecture.
Right now, there are some applications or library of SRS:
objs/srs, generated bycore/kernel/protocol/app/main.objs/srs_hls_ingester, generated bycore/kernel/protocol/app/main. But, it's not compatible with config object, so it set the_srs_configto NULL. That's rediculous.objs/lib/srs_librtmp.a, generated bycore/kernel/protocol.objs/research/library/*, generated byresearchandsrs_librtmp.a.SRS also support modules, for example,
srs_hls_ingesteris a module. For all SRS modules, the config object doesn't works well, because the config object is only forobjs/srs. In another word, some objects are not available for modules, so we extract aserviceinsrc/servicefor modules.Please refer to the arch https://github.com/ossrs/srs/tree/develop#modularity-architecture.