ndnrtc

Current implementation provides functions for producers to have only 1 audio stream and 1 video stream. Each media stream can have as much media threads as needed, which is fine. The idea lying behind streams and threads is following: media stream represents audio or video stream which is being captured from certain capturing device, whereas media stream thread represents media stream which was processed (encoded) with specific parameters. These parameters can be fetched from special session-info namespace which contains meta data for actual stream threads.

There is a need for supporting as many media streams as needed with preservation of media threads.
I.e. producer should provide full support for the namespace and provide functions for creation/deletion of media streams and media threads on-the-fly. Consumer should react to these changes accordingly (by switching to other media threads if one become unavailable, maybe some strategy logic should be implemented here).

In other words, the following media hierarchy should be provided by producer and supported by consumer:

• .../streams
  • .../video0
    • .../thread1
    • .../thread2
    • ...
    • .../threadN
  • .../video1
    • .../thread1
    • .../thread2
    • ...
    • .../threadM
  • .../audio0
    • .../thread1
    • .../thread2
    • ...
    • .../threadK
  • .../audio1
    • .../thread1
    • .../thread2
    • ...
    • .../threadL
  • ...
  • .../streamX
    • .../thread1
    • .../thread2
    • ...
    • .../threadS