NDN-RTC v1.2.3

Bugfixes

• Minor bugfixes

NDN-RTC v1.2.2

Features

• Introduced "main library thread" (background thread) which reduces total amount of threads NDN-RTC can create during operation. Now small tasks like updating something (session info) on timer are triggered by timers scheduled on main lib thread.
• Removed deprecated methods - remote session observers. Now user discovery is not NDN-RTC problem.
• All playout mechanisms are now operate on main lib thread.
• Voice thread is merged with main lib thread.

Bugfixes

• Minor bugfixes for pipeliner, media streams, buffer.

NDN-RTC v1.2.1

Features

• Compliance with the latest stable WebRTC version (branch-heads/44)
• Compliance with the latest stable NDN-CPP version (v0.7)

NDN-RTC v1.2.0

Features

• Improved statistics logging

  Does not interfere with running threads of NDN-RTC.

• Improved logging

  Running at default log level should be sufficient for discovering most streaming problems.

• Buffer level checks

  Playback fast-forwards if buffer grows greater than target size significantly.

• Refactoring & removed deprecated code

Bugfixes

• Corrupted frames

  Fixed corrupted frames bug from the previous release

• Playback hangs

  Fixed seldom playback hangs by using boost timers instead of unreliable webrtc events.

• Memory leaks

NDN-RTC v1.1.0

This release along with numerous fixes contains major improvement for the pipeliner mechanism.

Features:

• Pipeliner v2 (see below)
• Producer-published information about average segments number per frame type

Bugfixes:

• Clean staled interests from producer's PIT table every time new frame is published
• Use unix socket for connecting to a local NFD
• Playback adjustment fixes
• Reset decoder on rebufferings

Known issues:

• Rebufferings

  These are under active investigation. For some reason, consumer may experience interruptions in incoming media data streams for comparatively long periods of time (about 300ms). Such interruptions are fatal for default buffer size of 300ms and forces consumer to reset and start over. This behavior results in 1-1.5sec video interruptions for the end user.
  So far, there are two types of rebufferings discovered:

  • Network-induced - these occur as a consequences of delays in the network
  • Producer-induced - these occur when producer either drops frames or experience interruptions in performing frame encoding (the nature of which is under investigation).

• Corrupted video frames

  Sometimes, user may experience "video tearing" effects or corrupted frames for some short periods of time. The reasons for that are still not fully clear - as there are no observable incomplete frames or wrong frame decoding sequencing.

Pipeliner v2

There were two major improvements introduced in the pipeliner mechanism:

1. Data-driven interest expression.

   Interests for new frames are issued only when previous data has arrived. The number of outstanding interests is controlled by pre-defined parameter W:

   1. In the beginning of the algorithm W is initialized with some value.
   2. If W > 0, interest(s) for subsequent frame is issued and W gets decremented.
   3. Each time any data segment for a distinct frame arrives, W gets incremented and Step ii is performed.

   This idea may be simply presented by this picture (red arrows are issued interests and green arrows are arriving data segments:
   
   This approach gives simplicity in controlling pipeliner behavior when necessary:

   • if more interests need to be issued, W is increased:
     
   • if interests expression should be suppressed for some period, W is decreased:
     

   By manipulating parameter W and observing round-trip time value, consumer can eventually reach synchronization state with producer.

2. Start-up with key frames.

   Instead of fetching delta frames during the chase period, consumer now asks for the rightmost child in the key namespace. After receiving data for the key frame Kseed, consumer issues interests for Kseed+1 key frame and once it becomes available, starts fetching delta frames (red arrows represent interests/data for key frames and green arrows represent interests/data for delta frames):

NDN-RTC v1.0.1

Bundled audio:

Previously, each published audio segment contained just one audio sample (172 bytes, PCMU). However, segment size could be much bigger (depending on settings - up to default MTU size or bigger). Moreover, each audio segment gets NDN-overhead which is about 360 bytes (name + signature) which altogether makes it very inefficient to transfer audio samples - network overhead is bigger than the payload and the number of interests is inefficiently high. Average incoming bitrate for audio calls was about ~220 kbit/sec
Now, producer publishes segments which contain several audio samples (1000-byte segment can accommodate 5-6 audio samples) which decreases overall incoming bitrate up to ~100kbit/sec and outgoing interest rate to 10-12 interests per second.

NDN-RTC v1.0.0

NOTE: Demo app is not yet compatible with the this update!

This is a major release of NDN-RTC which underwent some serious code cleanup and refactoring. The library now has updated simpler interface which reflects media stream hierarchicy for producer:

Bugfixes:

• Proper handling of NDN-CPP exceptions
• Numerous error handling fixes

Features:

• Video streams are now provide interface for external capturer and external renderer