Start a UWP Project

Create a new Universal Windows solution in Visual Studio, and add the following DLLs as references:

FM.LiveSwitch.dll
FM.LiveSwitch.Uwp
FM.LiveSwitch.Uwp.Win2D
FM.LiveSwitch.Opus.dll
FM.LiveSwitch.Vpx.dll
FM.LiveSwitch.Yuv.dll

These provide you with the Opus and VP8/VP9 codecs. You also need some way to capture the user's audio. Note that video capture is provided natively by UWP, so no special library is needed for video capture. The default way to support audio capture is to use the NAudio library, which allows you to capture audio data from a user's microphone. To use the default configuration include FM.LiveSwitch.NAudio.dll.

H.264 support for UWP

You can add FM.LiveSwitch.OpenH264.dll as well, if you want to support the H.264 codec. However, the OpenH264 library cannot currently be downloaded at runtime due to UWP restrictions. To support H.264 for UWP you would have to include the OpenH264 binary provided by Cisco into your release and pay the corresponding royalties to MPEG LA (http://www.mpegla.com/main/programs/AVC/Pages/Intro.aspx).

If you are capturing audio and video then you need to add microphone and webcam device capabilities to your project. You must also add the internetClient and privateNetworkClient capabilities to your project to allow full network capabilities. You can use the Manifest Designer, or in Package.appxmanifest you can add these directly: Package.appxmanifest

<Capabilities>
    <Capability Name="internetClient" />
    <Capability Name="privateNetworkClientServer" />
    <Capability Name="internetClientServer" />
    <DeviceCapability Name="microphone" />
    <DeviceCapability Name="webcam" />
</Capabilities>

Necessary capabilities

To ensure that UWP clients can communicate over private networks you must include the privateNetworkClientServer capability.
To ensure UWP clients can act as servers for networking communication (enables the client to connect in answering SDP role, not just in the offering role) you must include the internetClientServer capability.

You also need to include architecture-specific builds for several of these libraries. These can be found in the UWP/Libraries/lib/win_x86 and UWP/Libraries/lib/win_x64 folders of the standard LiveSwitch distribution. The following rules apply:

If you are using FM.LiveSwitch.AudioProcessing.dll, include libaudioprocessingfm.dll.
If you are using FM.LiveSwitch.OpenH264.dll, include libopenh264fm.dll.
If you are using FM.LiveSwitch.Opus.dll, include libopusfm.dll.
If you are using FM.LiveSwitch.Vpx.dll, include libvpxfm.dll.
If you are using FM.LiveSwitch.Yuv.dll, include libyuvfm.dll.

To have the correct architecture-specific libraries copied into your build artifacts you can set up conditional build rules in your .csproj file. These libraries need to be in the root of your build artifacts. For example this rule ensures that the x64 libraries are copied to the root of the build artifacts for builds that target the x64 platform. Platforms and build configurations are edited in the Configuration Manager.

<ItemGroup Condition="'$(Platform)' == 'x64'">
    <Content Include="lib\win_x64\libaudioprocessingfm.dll">
      <Link>libaudioprocessingfm.dll</Link>
    </Content>
    <Content Include="lib\win_x64\libopusfm.dll">
      <Link>libopusfm.dll</Link>
    </Content>
    <Content Include="lib\win_x64\libvpxfm.dll">
      <Link>libvpxfm.dll</Link>
    </Content>
    <Content Include="lib\win_x64\libyuvfm.dll">
      <Link>libyuvfm.dll</Link>
    </Content>
  </ItemGroup>
  <ItemGroup Condition="'$(Platform)' == 'x86'">
    <Content Include="lib\win_x86\libaudioprocessingfm.dll">
      <Link>libaudioprocessingfm.dll</Link>
    </Content>
    <Content Include="lib\win_x86\libopusfm.dll">
      <Link>libopusfm.dll</Link>
    </Content>
    <Content Include="lib\win_x86\libvpxfm.dll">
      <Link>libvpxfm.dll</Link>
    </Content>
    <Content Include="lib\win_x86\libyuvfm.dll">
      <Link>libyuvfm.dll</Link>
    </Content>
  </ItemGroup>

Handle App Running in Background

By Default UWP suspends your app when the app is sent to background mode. In this state the memory is maintained but the code does not run. To prevent this from happening the app can use ExtendedExecutionForegroundSession to continue running the app. This method, however, uses restricted capabilities and needs permission from Microsoft to get published in the Microsoft Store.

Enable Restricted Capability

The first step is to add the ExtendedExecutedUnconstrained capability. This is added in Package.appxmanifest.

<Package
    ...
    xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities" IgnorableNamespaces="uap mp rescap">
    ...
    <Capabilities>
        <rescap:Capability Name="extendedExecutionUnconstrained"/>
    </Capabilities>
</Package>

With this set ExtendedExecutionForegroundSession mode is used instead of ExtendedExecutionSession.

Add ExtendedExecutionForegroundSession

There are three parts to working with ExtendedExecutionForegroundSession mode: Request, Disposal and Revocation. The request can be implemented as follows, and this code should be called early on in your app life cycle.

Request

private ExtendedExecutionForegroundSession ExtendedSession = null;

private async void BeginExtended()
{
    ExtendedSession = new ExtendedExecutionForegroundSession();
    ExtendedSession.Reason = ExtendedExecutionForegroundReason.Unconstrained;
    ExtendedSession.Description = "Long Running Processing";
    ExtendedSession.Revoked += SessionRevoked;
    ExtendedExecutionForegroundResult result = await ExtendedSession.RequestExtensionAsync();

    switch (result)
    {
        case ExtendedExecutionForegroundResult.Allowed:
            break;

        default:
            case ExtendedExecutionForegroundResult.Denied:
                ExtendedSession.Dispose();
                break;
    }
}

Disposal and Revocation can be can be handled by a single method as follows.

Disposal and Revocation

private void SessionRevoked(object sender, ExtendedExecutionForegroundRevokedEventArgs args)
{
    ExtendedSession.Dispose();
}

At this point ExtendedExecutionForeground is fully implemented and the app now runs in the background. There are two use cases to consider from here: Pausing/resuming media flow and preserving the media flow while the app is running in the background/foreground.

Pausing and Resuming Media Flow

In this use case, while the app is running in the background media flow is paused, and when the app returns to the foreground media flow is resumed. Here is an example which would need to be hooked into your app's UX. It makes use of pausing/resuming the LocalMedia object. See the UWP example app for the full example code.

private async void Current_VisibilityChanged(object sender, ExtendedExecutionForegroundRevokedEventArgs args)
{
    if (e.Visible)
    {
        await Application.Instance.ResumeLocalVideo().AsTask();
    }
    else
    {
        await Application.Instance.PauseLocalVideo().AsTask();
    }
}

Preserving Media Flow

In this use case, media flow is preserved as the app switches from foreground to background. This is even simpler than above as it is the default behaviour for ExtendedExecutionForegroundSession mode. The only difference between this scenario and the one above is that the video is no longer paused when switching to the background. To accomplish this simply do not hook into the Current_VisibilityChanged event and do not pause/resume LocalMedia.

For more information refer to: