Currently feng provides some sparse documentation about its internals you can generate documentation using doxygen from the git sources. The following text aims to give some additional high level insights about the structure before you dive into the doxy.
One of the main improvements over fenice is the modular design. Roughtly feng is splitted in its layers and in some functional modules. Each component will eventually provide some external hooks (e.g. rtcp feedbacks, scheduling behaviours) to enhance and experiment w/out having to dive in the full source.
Network layer: Socket management is implemented as a separated library called NetEmbryo. Feng is currently supporting UDP, TCP and SCTP
RTSP:
RTP:
RTCP:
Buffer management: The bufferpool system bridges the container parsing and packet producing modules to the delivery scheduler and then network layers. Through use of shared memory is possible use external helper applications like felix in order to have advanced features like distributed live streaming.
Mediathread: It encompass all the parsing and packetization activities beside rtp encapsulation. It could be split in two family of modules:
Parsers: provide facilities to packetize proper rtp payloads out of specific codec bitstreams.
Demuxers: read from traditional containers (like mkv, mov or nut) or more specific metademuxer like stream descriptions or editlists.
Other streaming servers support access and authentication in a quite complete and probably nice way. We could either try to come up with something similar (they tried to make it similar to apache way) or try to look at alternatives.
There are two metods defined, plain and digest. We should implement just plain and put it over tls, digest is a bit complex and tls should be better from a security point.
There are various ways to describe who has access to what, usually you either create a list with paths and the users that have access to them, sometimes you define groups of users and then use them with the before mentioned lists, sometimes you put a list of users next to the content or even INSIDE the content you want to restrict/grant the access to. Since reinventing the wheel while there are others already around more or less rounder it's pointless, it's better try to consider what others did for their needs:
Since we are aiming on the small and slick niche I think we could consider more and more the lighttpd way.
This page is just for planning.
The idea is being able to stream a live event from a real time encoded stream. Sounds quite simple but has a series of caveats. You have different streams (video, audio, subs, metadata) that got produced by independent sources more than often and that must be pushed to the network as soon as possible. The fact that the sources are independent means that is our task give some timestamps to make things synchronous (e.g voice – lips or voice – text), seeking is not supported since it is a live event.
Supporting live means that we have a resource that is particular:
A metademuxer act exactly as a standard demuxer, exposes the very same interface, but instead of reading from a file container it does any kind of manipulation over already mapped resources based on specific per resource configuration files.
Example configuration file
# Version 1 - free form text here
resource.mov 0.0 1.0
resource.ds 1.0 3.0
resource.nut 3.0 4.0TODO: move the configuration to the unified yaml based configuration, use an uniform uri handler for them
Example configuration file
stream
file_name mq:///video
encoding_name MPV
stream_end
stream
file_name mq:///audio
encoding_name MPA
stream_endFenice started with a simple and plain configuration file for the global settings and then another syntax was used for the stream description and in feng we had to add another for the compositions.
The overall results are the following:
The main configuration must provide support for host and base virtuals, that means that the following structure should be presented: The main configuration will reside in a feng.conf file as was before, just the path would be $sysconfdir/feng/feng.conf and optionally additional sub configuration files (like module specific configurations) can stay in separate files and be included from the main feng.conf.
It should allow (maybe in a second time) support for including additional configuration files (like the include directive present in many languages) and merge the informations.
The resource configuration should provide demuxer specific settings and additional information useful for the stream. There is a group of settings that is common to every demuxer. The resource configurations will be in substitution of the current .sd and .ds files, it will have a magic string on the first line to let the demuxer layer know it is a resource configuration without relying on the extension to guess which kind of file it is. They will reside in the avroot tree, each file name and path will be used as resource identifier.
…
The main idea is to use just a single syntax across the configurations. Resources, global settings, per path settings will share the same parser, that has to possibly be a robust library, we have limited resources and I'd rather spend our time implementing streaming features than minimalistic parsers while full featured, fast and complete ones are available already.
Pros:
Cons:
Pros:
Cons: