Follow us on Facebook
Follow us on Twitter
Signalogic on LinkedIn

Home > Software Products > DeepLI™ Lawful Interception
DeepLI™ Lawful Interception software maps to the LEA domain in ESTI terminology
DeepLI™ Lawful Interception software maps to the LEA domain in ETSI HI
(Handover Interface) functional block diagram (ETSI TS 133 108 v14.0.0 ◳ Figure 4.1)

DeepLI™ Lawful Interception software supports flexible site models, including On-Premise, Co-Located, and SaaS (cloud LI)
DeepLI™ Lawful Interception software supports flexible site models,
including On-Premise, Co-Located, and SaaS (cloud LI). See Site Models below

DeepLI™ - Lawful Interception Software


Overview

DeepLI™ (Deep Lawful Interception) is a new generation of Lawful Interception software with emphasis on site model flexibility, extreme high capacity, superior audio quality, and deep learning. Site models include on-premise, co-located, and SaaS (cloud LI). Addition of deep learning support is ongoing, including speech recognition and diarization.

DeepLI is currently deployed in Tier 1 LEAs and carriers 1. Here are key reasons why:

DeepLI is based on shared library modules within SigSRF software (Github page) ◳, including packet media, streaming, voice codecs, algorithm, diagnostic, inference, and others. SigSRF provides the high capacity / high reliability foundation for DeepLI. SigSRF software functionality includes:

Demo versions of the mediaMin and mediaTest reference applications run on x86 Linux servers. Customized, application-specific trial / eval versions are also available. Online demos include codecs for EVS, AMR-NB, AMR-WB, and G711. Customized trial / eval versions can include additional codecs. For more information on the EVS codec, see the HPC EVS Codec product page ◳.

1 "Tier 1" means carriers approximately the size of T-Mobile (around 45B annual), and for LEAs means FBI level national agencies
2 For example, each session with two (2) EVS wideband streams and one (1) AMR-NB stream on an HP DL380 running Ubuntu Linux
3 Depending on business case discussions conducted under NDA
4 OpenLI ◳ is an open source project maintained by the University of Waikato ◳

Product Info

DeepLI with VoLTE Codecs     RTP Stream Merging Option     Speech Recognition Option

Signalogic Part P/Ns DSSIG-DEEPLI-VOLTE, DSSIG-DEEPLI-STREAM, DSSIG-DEEPLI_ASR
System
Manufacturer
Signalogic
Signalogic Logo
Description DeepLI Lawful Interception Software
Product Categories HPC (High Performance Computing), Media Resource Functions, Algorithms
Product Status Deployed

Default tab content (this text) shown when (i) no tabs are automatically selected, or (ii) if rel value for the tab ="#default".

Availability
Stock: 0
On Order: 0
Delivery: Electronic (secure download)
Pricing (USD)
Qty 1: Request Quote
MOQ: 1
                      

* Required fields
coCPU™ cores are optional for extreme
SWaP or server density perfomance applications;
application requirements discussion is required
Promotions
Current Promotions: None

Product Description - DeepLI Features

Site Models

On-Premise, Co-Located, SaaS (cloud LI)

Operating Modes

Telecom, Analytics. Both modes support packet send rates slower or faster than packet ptime, and Analytics mode includes an option for pcaps without arrival timestamps

Applications

mediaMin: ready-to-use LEA application, with output options including UDP/RTP, wav file, and pcap
 
mediaTest: test and measurement application for codecs, audio quality, stress tests, custom packet and jitter buffer settings, and more
 
All applications are reference applications, including best practice techniques and methods, full C/C++ source code and header files, Makefiles, and detailed, extensive notes and comments
 
All applications provide a well documented command line interface, including numerous quick start and functional test examples. See section 2, Command Line Usage, and section 6, Functional Testing, in SigSRF documentation ◳. See also "APIs" in this table

APIs

Two levels of API are available: (i) fine-grained control at the packet/media thread level, and (ii) simplified, minimal interface based on session setup and packet queue push/pull. The mediaMin application is based on the minimal API. Section 3.1, Minimum API Applications, in SigSRF documentation ◳ contains a source code example showing a packet push/pull loop implemented in 10 lines of C code

I/O

I/O includes UDP/RTP, pcap, and waveform file. IPv4 and IPv6 supported. wav, .au, compressed bitstream, and other file formats supported

Capacity

50 sessions per core 1

Stream Processing

Stream group setup and management, real-time RTP stream merging and deduplication, user-defined signal processing. RTP stream merging output options include real-time UDP packet flow, unified mono wav file and pcap, and per stream pcap and either mono or N-channel wav file. Stream deduplication removes reverb when the same source appears on multiple streams

Session Management

Static and dynamic session creation from (i) session configuration files, (ii) SDP info, (iii) IRI info, or some combination. Dynamic session creation includes an RTP audo-detect option. Live session control and modification

Codecs

EVS, AMR-NB, AMR-WB, AMR-WB+, G711, G729, G726

Jitter Buffer

Advanced options include dynamic re-ordering depth, packet loss mitigation, burst/gap compensation, SID and media packet repair, dynamic stream creation (RFC8108), on-demand flush, RFC7198 (temporal), live stats. Inter-stream packet rate mismatch and fluctuation compensated up to 20%

Multithreading

Multistream, multisession, multichannel, fully re-entrant, XDAIS compliant. See also "Capacity" in this table

DTX, SID, CNG

DTX can be applied and controlled on per session basis, or automated depending on codec type. VAD available for older codecs without inherent DTX support

PLC and FLC 2

Includes (i) codec decoder output and (ii) stream merging audio output

Voice/Packet Handling

DTMF, echo cancellation, sampling rate conversion, variable ptime, tone generation, and other audio and RTP processing

Stress and Functional Test

Documentation includes dozens of functional and stress test command lines and reference pcaps, along with test validation information

Logging

Event and packet logging. Packet logging includes SSRC group collation, analysis of dropped, missing, and duplicated packets, and timestamp matching

Energy Saver

Packet/media thread inactivity detection and throttle down, with user-specified settings

1 Xeon E5-2660 v0 @2.2 GHz, two (2) EVS wideband streams and one (1) AMR-NB stream per session, transcoded to G711. See section 5.0, High Capacity Operation, in SigSRF Documentation ◳ for more information
2 Packet Loss Concealment and Frame Loss Concealment

 

Site Models

Site models supported by DeepLI include On-Premise, Co-Located, and SaaS (cloud LI). The diagrams below show platform architecture and data flow for these models.

DeepLI™ Lawful Interception on-premise site model platform architecture and data flow diagram DeepLI™ Lawful Interception co-located site model platform architecture and data flow diagram DeepLI™ Lawful Interception SaaS site model platform architecture and data flow diagram
DeepLI™ Lawful Interception on-premise site model
platform architecture and data flow diagram

DeepLI™ Lawful Interception co-located site model
platform architecture and data flow diagram

DeepLI™ Lawful Interception SaaS site model
platform architecture and data flow diagram

Notes about the above diagams:
  1. SaaS models are flexible, depending on data privacy, session capacity, and other application-specific requirements
  2. High capacity figures quoted here and in SigSRF documentation ◳ require private servers, typically deployed in an On-Premise model

 

Telecom Mode

DeepLI™ telecom mode supports direct handling of bidirectional IP/UDP/RTP traffic. This mode is sometimes also referred to as "clocked" mode, as a wall clock reference is required for correct jitter buffer operation. Examples of telecom mode applications include network midpoints such as SBC (Session Border Controller) and media gateway, and endpoints such as handsets and softphones. Typically telecom applications have hard requirements for real-time performance and latency. A telecom mode data flow diagram is shown below.

DeepLI™ Lawful Interception telecom mode data flow diagram
DeepLI™ Lawful Interception telecom mode flow diagram

 

Analytics Mode

DeepLI™ analytics mode supports indirect handling of IP/UDP/RTP traffic, where traffic is encapsulated or "one step removed", having been captured, copied, or relayed from direct traffic for additional processing. This mode is sometimes also referred to as data driven or "clockless" mode, the latter description referring to jitter buffer packet processing either wholly or partially without a wall clock reference. In general, analytics mode applications operate after real-time traffic has already occurred, and process uni-directional traffic, although depending on the application it may be necessary to reproduce or emulate original real-time behavior and handle output endpoints. In addition to Lawful Interception, examples of analytics mode applications include web IT data analytics such as speaker identification and automatic speech recognition (ASR). An analytics mode data flow diagram is shown below.

DeepLI™ Lawful Interception analytics mode data flow diagram
DeepLI™ Lawful Interception analytics mode flow diagram

 

Audio Quality

DeepLI™ places utmost emphasis on audio quality. A number of areas in the software contain packet, media, and signal processing algorithms designed to achieve the highest possible audio quality. These include: In addition to detailed packet analysis and logging, DeepLI also support audio quality metrics and visualization. Below are some examples.

Wireshark capture showing 1 sec timing markers added to stream group output
Wireshark capture showing 1 sec timing markers added to stream group output

Because Wireshark will show time axis variations reflecting packet delta interval irregularity and timestamp gaps, any variation in spacing between timing markers indicates a potential problem. This makes the timing marker method a useful visualization tool for quickly finding timing issues, either in SigSRF software or application software.

Wireshark capture showing output buffer boundary timing markers added to stream group output
Wireshark capture showing output buffer boundary timing markers added to stream group output

In the output buffer boundary marker display above, the dynamic nature of the stream group gap handling algorithm can be seen in action, as it dynamically adjusts buffer sizes depending on incoming audio frame rate variation and underrun (gaps).

Audio Quality Testing

Audio quality testing is part subjective and part quantitative. Subjective testing takes a lot of time and several human listeners to agree that yes, quality is acceptable. In the extreme case, a panel of listeners is convened over several days and a Mean Opinion Score (MOS) is determined. This complexity makes quantitative testing methods desirable, although difficult. DeepLI incorporates the following quantitative audio quality test methods: Below is a run-time stats summary example.

DeepLI end-of-call run-time stats summary example, showing dynamic session creation of 3 EVS streams and one AMR-WB stream, child stream creation (RFC8108), and stream group output
DeepLI end-of-call run-time stats summary example, showing dynamic session creation of 3 EVS streams and one AMR-WB stream, child stream creation (RFC8108), and stream group output

As shown in the above example, run-time packet stats include packet loss, timing, and out-of-order, stream group underrun and overrun, jitter buffer stats, and more.

Below are examples of stream group wav output after sliding FFT spectrographic analysis using Hypersignal software, along with the corresponding time domain waveform displayed in Wireshark. These examples show clean, high quality output, with no wideband noise vertical lines that would indicate gaps, glitches, or other audio artifacts.

Frequency domain sliding FFT spectrographic analysis of stream group wav output (using Hypersignal heatmap option)
Frequency domain sliding FFT spectrographic analysis of stream group wav output (using Hypersignal heatmap option)

In the spectrographic analysis display below, early media ring tones can be identified by their stable frequency content over 100 msec to 1 sec, unlike speech which is typically "quasi-stationary" for no more than 20 msec.

Frequency domain sliding FFT spectrographic analysis of stream group wav output (using Hypersignal heatmap option). This example includes early media ring tones
Frequency domain sliding FFT spectrographic analysis of stream group wav output (using Hypersignal heatmap option). This example includes early media ring tones

Stream Alignment

Applications that merge RTP streams from multiple endpoints, such as conversational ASR and diarization, remote work groups, and lawful interception, often require extremely accurate stream alignment. Merged output must assemble in real-time, maintaining exactly regular sampling intervals. Endpoints with different latencies, packet send rates, and other variations make this task challenging. DeepLI™ handles this with a series of algorithms developed in US based labs due to multiple customer engagements in telecom, analytics, and embedded system applications.

Below is an overlay of Wireshark screen caps showing an example of multiple streams merged into a combined, real-time audio output.

DeepLI™ example of multiple stream alignment and real-time merging
DeepLI™ example of multiple stream alignment and real-time merging

 

High Capacity

DeepLI™ was architected from inception for high capacity, multicore, concurrent thread operation. Below is an htop screen capture showing 504 concurrent sessions running on a 32-core Xeon server.

DeepLI™ htop display showing high capacity packet/media processing, 504 concurrent sessions
DeepLI™ htop display showing high capacity packet/media processing, 504 concurrent sessions

The above htop display shows 12 mediaMin application threads and 10 packet/media threads running concurrently. Application threads are hyperthreaded (highlighted in yellow) and packet/media threads are not hyperthreaded (highlighted in red); i.e. one thread per physical x86 core. The area highlighted in orange indicates unused logical cores to allow maximum packet/media thread performance. Each packet/media thread is handling 48 to 51 sessions.

For more information, see section 5.0, High Capacity Operation, in SigSRF Documentation ◳.

For low capacity applications, license pricing scales depending on application needs. There is no requirement to pay for high capacity operation if not needed. But -- it's always there, available to be turned on should it be needed.

 

Test Regimen

Functional Tests

Due to many customer relationships over many years, Signalogic maintains a database of 100s of RTP media pcaps, covering an enormous range of test cases, including:

Stress Tests

Signalogic continuously runs stress tests on separate servers dedicated to 24/7 testing. These include repeating, random combinations of functional tests, high capacity tests, "extreme conditions" such as 1 msec packet push rates, packet gaps, removals, and other impairments, artificial Linux thread stalls, and others.

Capacity Tests

The SigSRF documentation includes a number of mediaTest and mediaMin command lines for capacity tests, including multiple application threads, multiple packet/media threads, and combinations. See the High Capacity section, above.

 

Application and Diagnostic Table

DeepLI™ application and diagnostic functionality is shown in the table below. General functional areas are shown at left, then further subdivided. Diagnostic functionality includes test and measurement capabilities provided by the mediaTest application. As noted above, both mediaMin and mediaTest are reference applications based on SigSRF shared library modules (SigSRF Github page ◳ ).

 

Functionality

Application

Diagnostic

I/O

UDP/RTP, IPv4 and/or IPv6

mM

mM, mT

pcap

mM

mM, mT

Waveform files, .wav, .au, .tim formats

mM

mM, mT

USB audio

 

mT

Compressed bitstream data files, .cod format (header full and compact header payload format modes supported), .bit, .amr and .awb formats

 

mT

Intercept
Management

Web interface providing intercept organization and configuration, control of mediaMin instances, and session creation definitions and stream group assignments

 

 

Session Creation

Static creation from session configuration files

mM

mM, mT

Dynamic creation from SDP info, stream RTP auto-detect

mM

mM

Dynamic creation from IRI info

mM

mM

Stream
Processing

Per stream processing, see "Packet Processing and Transcoding" table entry below. Stream group setup and management, RTP stream merging, stream deduplication, and user-defined signal processing. Merging includes real-time audio and UDP output, and pcap and wav file output (both mono and N-channel wav file). Stream deduplication removes reverb when the same source appears on multiple streams

mM

mM

Stream burst/gap compensation and rate misalignment correction

mM

mM

Packet Processing and Transcoding

Jitter buffer re-ordering depth, DTX, SID, CNG, packet loss mitigation, SID and media packet repair, dynamic stream creation (RFC8108), on-demand flush, RFC7198 (temporal), run-time stats

mM

mM, mT

Transcoding

mM

mM, mT

Variable ptime (transrating)

mM

mM, mT

DTMF event handling, tone detection and generation

mM

mM, mT

Sampling rate conversion

mM

mM, mT

AI and Deep Learning

Speech recognition, language detection, speaker identification, and diarization

mM

mM, mT

Test, Validation, Benchmarking, Interactive Debug

Stress test, single app thread, multiple packet/media threads, multiple sessions.  Event log validation

 

mM, mT

Stress test, multiple app threads, multiple packet/media threads, multiple sessions.  Event log validation

 

mT

Functional test and validation of audio quality and packet log

 

mM, mT

Low level API test, debug, and custom configuration for SigSRF shared library modules, including pktlib, voplib, streamlib, inferlib, alglib, diaglib, and hwlib

 

mT

Performance benchmarking for encoder + decoder, encoder-only, and decoder-only.  Command line entry for encoder bitrate, channel aware, DTX (VAD)

 

mT

Interactive commands, including debug output, pause/resume, stats, and profiling.  Stats include thread, session, stream group, channel, and energy saver.  Profiling includes CPU usage for packet/media thread, stream group, and codec processing

 

mT

Packet tracing

 

mT

PLC

Codec

mM

mM, mT

FLC

Stream group

mM

mM

Logging

Event

mM

 

Packet

mM

 

Application Specific Customization

Customization of API usage, diagnostics, logging, debug output, and stats output

mM

mM, MT

Energy Saver

Packet/media thread inactivity detection and throttle down

mM

mM


    Legend

mM = mediaMin

mT = mediaTest

Application Level

Partial demo available

Under development


    Notes

 

API Interface

DeepLI™ provides two levels of API: The mediaMin application is based on the minimal API. API header files are availble for inspection in the online SDK demos or upon request. Below is a mediaMin source code excerpt showing a packet push/pull loop implemented in 10 lines of C code.

 

/*** Packet push / pull loop excerpt from mediaMin source ***/

 

   do {

 

      if (fPause) continue;  /* skip push/pull loop if pause is in effect */

 

      if (Mode & USE_PACKET_ARRIVAL_TIMES) PushPackets(pkt_in_buf, hSessions, session_data, thread_info[thread_index].nSessionsCreated, thread_index);  /* in this mode, PushPackets() will push a packet for each session only if elapsed time exceeds the packet's arrival time */

 

   /* packet input interval elapsed ?  In Analytics mode (FTRT mode, -r0 cmd line entry) frameInterval is zero, so we push packets as fast as possible.  For cmd line entry -rN we push packets at N msec intervals */

      gettimeofday(&tv, NULL);  cur_time = tv.tv_sec * 1000000L + tv.tv_usec; if (!base_time) base_time = cur_time;

      if (cur_time - base_time < interval_count*frameInterval[0]*1000) continue;  interval_count++;  /* if interval has elapsed, push and pull packets, increment interval.  Comparison is in usec */

   /* read packets from input pcap files, push to packet/media thread */

      if (!(Mode & USE_PACKET_ARRIVAL_TIMES)) PushPackets(pkt_in_buf, hSessions, session_data, thread_info[thread_index].nSessionsCreated, thread_index);

      #ifdef SINGLE_STEP

      if (isMasterThread) { printf("After push\n"); fPause = 1; continue; }

      #endif

   /* pull available packets from packet/media thread, write to pcap files */

      PullPackets(pkt_out_buf, hSessions, DS_PULLPACKETS_JITTER_BUFFER, sizeof(pkt_out_buf), thread_index);

      PullPackets(pkt_out_buf, hSessions, DS_PULLPACKETS_TRANSCODED, sizeof(pkt_out_buf), thread_index);

      PullPackets(pkt_out_buf, hSessions, DS_PULLPACKETS_STREAM_GROUP, sizeof(pkt_out_buf), thread_index);

   /* check for end of input, end of packets send by packet/media thread (to which the session is assigned), flush sessions if needed */

      FlushCheck(hSessions, cur_time, &queue_check_time, thread_index);

   /* update screen counters */

      UpdateCounters(thread_index);

   /* update stress test conditions, if enabled.  Note that repeating tests exit the push/pull loop here, after each thread detects end of input and flushes sessions */

      if (!StressTestActions(hSessions, uFlags_session, thread_index)) break;

   } while (!ProcessKeys(hSessions, thread_index));  /* process interactive keyboard commands, continue until 'q' key is entered */

 

 

Note that packet output queues are separated into jitter buffer, transcoded, and stream group. For more information on the above source code excerpt, and packet push/pull queues, see SigSRF documentation ◳ section 3.1, Minimum API Applications.

 

Packet Logging

Upon application request, DeepLI generates a detailed packet log, including input packet history, jitter buffer output packet history, input packet statistics, and comparison / analysis of input vs. output. Below is an example packet log, edited for brevity.

Ingress Packet info for SSRC = 0x6506e546, first seq num = 8, last seq num = 13023 ...

Seq num 8              timestamp = 11200, pkt len = 6 SID
Seq num 9              timestamp = 13120, pkt len = 33
Seq num 10             timestamp = 13440, pkt len = 33
Seq num 11             timestamp = 13760, pkt len = 33
Seq num 12             timestamp = 14080, pkt len = 33
Seq num 13             timestamp = 14400, pkt len = 33
Seq num 14             timestamp = 14720, pkt len = 33
Seq num 15             timestamp = 15040, pkt len = 33
   :
   :
Seq num 85             timestamp = 176000, pkt len = 33
Seq num 86             timestamp = 176320, pkt len = 33
Seq num 88 ooo 87      timestamp = 176960, pkt len = 33
Seq num 87 ooo 88      timestamp = 176640, pkt len = 33
Seq num 89             timestamp = 177280, pkt len = 33
Seq num 90             timestamp = 177600, pkt len = 33
   :
   :
   :
[ additional input streams ]

Jitter Buffer Packet info for SSRC = 0x6506e546, first seq num = 8, last seq num = 51340 ...

Seq num 8              timestamp = 11200, pkt len = 6 SID
Seq num 9              timestamp = 11520, pkt len = 6 SID CNG-R
Seq num 10             timestamp = 11840, pkt len = 6 SID CNG-R
Seq num 11             timestamp = 12160, pkt len = 6 SID CNG-R
Seq num 12             timestamp = 12480, pkt len = 6 SID CNG-R
Seq num 13             timestamp = 12800, pkt len = 6 SID CNG-R
Seq num 14             timestamp = 13120, pkt len = 33
Seq num 15             timestamp = 13440, pkt len = 33
   :
   :
   :
[ additional output streams ]


** Packet Stats and Analysis **

Stream groups found = 1, group indexes = 0

Stream group 0, 3 streams

  Stream 0, channel 0, SSRC = 0x13883145, 156 input pkts, 156 output pkts

    Input packets = 156, ooo packets = 0, SID packets = 0, seq numbers = 0..155, missing seq numbers = 0, max consec missing seq numbers = 0
    Input packet loss = 0.000%
    Input ooo = 0.000%, max ooo = 0

    Output packets = 156, ooo packets = 0, seq numbers = 0..155, missing seq numbers = 0, max consec missing seq numbers = 0, SID packets = 0, SID R packets = 0, repaired SID packets = 0, repaired media packets = 0
    Output packet loss = 0.000%
    Output ooo = 0.000%, max ooo = 0

    Packets dropped by jitter buffer = 0
    Packets duplicated by jitter buffer = 0
    Timestamp mismatches = 0

  Stream 1, channel 2, SSRC = 0x6506e546, 12912 input pkts, 51333 output pkts

    Input packets = 12912, ooo packets = 1346, SID packets = 5652, seq numbers = 8..13023, missing seq numbers = 104, max consec missing seq numbers = 1
    Input packet loss = 0.805%
    Input ooo = 5.212%, max ooo = 2

    Output packets = 51333, ooo packets = 0, seq numbers = 8..51340, missing seq numbers = 0, max consec missing seq numbers = 0, SID packets = 5702, SID R packets = 38320, repaired SID packets = 53, repaired media packets = 51
    Output packet loss = 0.000%
    Output ooo = 0.000%, max ooo = 0

    Packets dropped by jitter buffer = 0
    Packets duplicated by jitter buffer = 0
    Timestamp mismatches = 0

  Stream 2, channel 4, SSRC = 0xb6ef05cc, 50862 input pkts, 51325 output pkts

    Input packets = 50862, ooo packets = 8876, SID packets = 0, seq numbers = 65..51389, missing seq numbers = 463, max consec missing seq numbers = 2
    Input packet loss = 0.910%
    Input ooo = 8.726%, max ooo = 2

    Output packets = 51325, ooo packets = 0, seq numbers = 65..51389, missing seq numbers = 0, max consec missing seq numbers = 0, SID packets = 0, SID R packets = 0, repaired SID packets = 0, repaired media packets = 463
    Output packet loss = 0.000%
    Output ooo = 0.000%, max ooo = 0

    Packets dropped by jitter buffer = 0
    Packets duplicated by jitter buffer = 0
    Timestamp mismatches = 0

Note in the above packet log example, out-of-order input packets are marked as "ooo".

mediaMin and mediaTest Demos

The SigSRF SDK download page (Github) ◳ contains free, limited demo versions of the mediaMin and mediaTest reference applications, including source code, along with several mediaMin and mediaTest command line examples ◳. In addition to Lawful Interception functionality and OpenLI support ◳, the demos provide test, measurement, diagnostic, and event / packet logging examples. Demo limitations include number of concurrent sessions, number of packets processed, and functionality. To remove or relax functionality limits, customized trial versions are available upon request and subsequent to business case discussion. All C/C++ source code for both applications is published.

Published Source Code

Published C/C++ source code includes:

Published source code is stored on Github and is available in online demo packages.

1 As noted in API Interface above, the mediaMin application relies only on the "minimal API" interface.

Related Applications

Other available software related to DeepLI:

How to Get a Quote

Enter the fields shown above, including:

Then click on "Get Quote / Info" to receive pricing via e-mail.

Related Items

1) Codec Wav Samples, before and after encode/decode ◳

2) mediaMin and mediaTest demo download (Github page) ◳

mediaTest high capacity media session transcoding screen capture
mediaTest high capacity media session transcoding screen capture, showing EVS codec performance benchmarking in diagnostic mode

3) Surveillance Video Suspect Detection and Tracking ◳

Surveillance video suspect detection
                           Vidilant suspect detection software screen capture of surveillance video analysis

4) ffmpeg Acceleration ◳

FFmpeg Accelerator / HPC card for servers.  FFmpeg streaming command line interface
                           FFmpeg screen capture with c66x acceleration enabled


Tech Support

Signalogic's engineering staff designs, develops, maintains, operates, and tests software and hardware in the company's in-house lab, using servers from HP, Dell, Supermicro, Artesyn, Advantech, and others, and Linux installations including CentOS, Ubuntu, Red Hat, Wind River, Gentoo, and more. Customers can submit technical questions via e-mail, phone, or Skype chat.

Signalogic engineers are experts in server and embedded system development. Contract development is available, for example product based quotations with NRE modifications to customer specs. Signalogic is a member of third-party programs for HP, Dell, Intel, and Texas Instruments. A high level of expert, sustained, and detailed tech support is a distinct advantage of working with Signalogic.