Contact Support | System Status
Page Contents

    Generic Stream Concurrency (GSC) with the Native SDK for Android

    In this topic, you will learn how to set up and test Generic Stream Concurrency (GSC) with the Brightcove Native SDK for Android.

    Introduction

    Generic Stream Concurrency lets you define the number of video streams that a specific user can watch concurrently. Limiting stream concurrency helps you prevent content being stolen or illegally watched through the theft or inappropriate sharing of credentials.

    This feature is part of Playback Restrictions, and it’s an alternative to stream concurrency with DRM, which is an alternative solution.

    For details, see the Generic Stream Concurrency document.

    Requirements

    Here are the requirements for this feature:

    • You must use Brightcove Native SDK for Android version 6.17.2 or later

    Implementing stream concurrency

    To test Generic Stream Concurrency with your app, follow these steps:

    1. In your build.gradle file (or wherever you set your repositories block), add the following:

      maven {
        url 'http://repo.brightcove.com/snapshots'
       }
    2. In your gradle.properties (or wherever you set your dependency version for the Brightcove Native SDK for Android), set the version value to 6.17.2-SNAPSHOT. This will allow the pre-release snapshot build to be downloaded into Android Studio.

    3. In your player Activity’s onCreate method, add this line:

      brightcoveVideoView.setStreamConcurrencyEnabled(true);
    4. Optional: If you want to retrieve the list of active heartbeat sessions for your viewer ID (uid), add this optional line below the line above:

      brightcoveVideoView.setStreamConcurrencySessionsListener(sessionsList ->
        Log.v(TAG, "Stream Concurrency. Get Active Sessions: " + sessionsList.toString()));
    5. In the onCreate method, add an event listener for the DID_SET_VIDEO event, to set heartbeat headers:

      Map<String, String> requestHeaders = new HashMap<>();
        requestHeaders.put(ConcurrencyClient.HEARTBEAT_VIDEO_HEADER_KEY, video.getId());
        requestHeaders.put(ConcurrencyClient.HEARTBEAT_ACCOUNTID_HEADER_KEY, accountId);
        requestHeaders.put(BrightcoveTokenAuthorizer.BRIGHTCOVE_AUTHORIZATION_HEADER_KEY, jwtToken);
        brightcoveVideoView.setStreamConcurrencyRequestHeaders(requestHeaders);

    Limitations and known issues

    Please note that this feature is currently in pre-release testing, and is subject to change as we develop and enhance it. As of the release of this document, these limitations and known issues have been seen in testing:

    Chromecast

    Brightcove is currently working on Chromecast support for this feature. As this feature becomes available, we will test the Brightcove Native SDK for Android Chromecast support for GSC, which may result in a follow-on release of the SDK.

    Concurrency limiting with DRM

    Testing has shown that when using GSC with DRM-protected videos, if the account is enabled for DRM stream concurrency, the climit claim will be enforced on the license acquisition request, and an error message like this will be returned:

    {
    	"error": "Denied by stream limiting (create)"
    }

    Heartbeat frequency

    The Heartbeat frequency of second request is 30 seconds.

    Testing has shown for the second heartbeat request ONLY, that the frequency of this request is 30 seconds. We are investigating this.

    Device with blocked session

    A device with a blocked session can attempt to stop its session.

    Testing has shown that if a device attempts to stream a video that is already being playing on another device, a second device is blocked from playing the stream, as expected. However, the second device may then attempt to “stop” the session that it was attempting to create, which will result in a 404 response code from the GSC heartbeat service. Testing has also shown that this does not affect the first device’s ability to continue streaming the content.

    What has been tested?

    SDK testing is being done manually with:

    • The Brightcove Android SDK internal manual test app, PlaybackTest. This app allows selection from multiple test assets, and supports build variants so that comparison can be made with the same app, built from different Git branches, run on the same device.
    • The Brightcove Android SDK sample apps repo, in particular:
      • BasicSampleApp: This app was used in testing because it exercises the basic use case of retrieval and playback of a video asset.
      • BasicSsaiSampleApp: This app was used in testing because it exercises the SSAI use case.

    Automated testing is currently in the design phase.

    Videos tested

    • VideoCloud Clear, DRM and HLSe VOD assets, with and without SSAI, and requested through the Edge Playback Authorization (EPA) service.
    • VideoCloud Live DRM assets, without ads (Live DRM does not currently support server-side advertising)

    Test procedure

    • Use case: Ensure that a climit claim of 1 is enforced.
      • Load and play the test asset on a device (“Device1”). Device1 uses a JWT with uid and sid payloads.
      • Load the asset on a second device (“Device2”). Device2 uses a JWT with the same uid but a different sid value.
      • Expect: Device2 will be blocked from playback of the asset.
    • Use case: Ensure that the heartbeat requests resume after backgrounding and foregrounding the device.
      • Load and play the test asset on a device (“Device1”). Device1 uses a JWT with uid and sid payloads. Only a single device is required for this test.
      • After starting playback, background the player Activity. This can be done using the device’s Home button (or a comparable mechanism, such as swiping on a Google Pixel phone or tapping the Learn More button in an Ad UI).
      • After a few minutes, foreground the player Activity.
      • Expect: Device1 resumes heartbeat requests after foregrounding, on the same frequency as when the device was backgrounded.

    Page last updated on 22 Nov 2021