Skip to content

Commit

Permalink
Merge branch 'main' into Add-tag-filter-to-analytics-specs
Browse files Browse the repository at this point in the history
  • Loading branch information
szekelyzol authored Jul 31, 2024
2 parents 09c7b5f + 1511f5f commit dcac1e0
Show file tree
Hide file tree
Showing 8 changed files with 143 additions and 356 deletions.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
106 changes: 67 additions & 39 deletions live-streaming/live-stream-best-practices.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,13 +6,6 @@ meta:

# Live stream best practices

## Starting a live stream

- When a stream is starting it might take up to 30 seconds for the playback to start delivering.
- Before starting the stream, it is important to have an intro (static picture, countdown and etc) to the beginning of the stream that will allow users to connect before the stream starts.
- In order to prevent the live stream from getting stuck (buffering indefinitely), please ensure that you are following the recommended [settings](#recommended-setting-for-ingestion).
- Make sure to verify that the connection speed is adequate and stable before the stream is starting.

## Streaming protocols

api.video supports `RTMPS`, `RTMP`, and `SRT` protocols for live streaming.
Expand All @@ -38,49 +31,84 @@ After this, take network connection into consideration - if you or your users st

Remember that both protocols have their pros and cons - with bad network conditions, viewers might encounter buffering with `RTMPS`, or they might encounter audio or visual glitches when using `SRT`.

## DVR - reading history in live streams
## Starting a live stream

- When a stream is starting it might take up to 30 seconds for the player to start delivering.
- api.video recommends that you add an intro image or a simple countdown before starting the stream. This gives users time to connect before the stream starts, and makes it clear that the stream is about to begin.
- To ensure that your live stream is running in optimal quality, check the [recommended settings](#recommended-setting-for-ingestion).
- Make sure you verify that your connection is stable and the speed is adequate before starting the stream.

When a live stream is ongoing, viewers can replay earlier content with the DVR feature. The available buffer is 1 hour, and is only available in live streams that are actively broadcasting.
## Ending a live stream

When the stream ends, api.video stores the stream for another 4 to 5 minutes, subsequently ending the stream and disposing of the cached video.
Make sure to use an outro like a static image or music at the end of the stream for about 30 seconds. This is a good way to indicate to the audience that the stream has ended.

## Ending the live stream
You should then request the API to complete the live stream, which stops the broadcast and the recording of the live stream as well. Read more about completing a live stream [here](/live-streaming/working-with-live-streams#complete-a-live-stream).

Make sure to use an outro (static picture, music and etc.) at the end of the stream for 30 seconds. This is a good way for users to indicate that the stream has ended.
## Requirements

When reaching the end of the playback, the player buffers until the live stream is deleted, which could take from 10 seconds to 5 minutes and could cause the live stream not to end properly even if you have stopped the broadcast.
This section lists the limitations and recommended settings for api.video's live streaming platform.

## Connectivity loss reconnection
### Codecs

Reconnection is handled by api.video, however, an edge case might occur (very slim chance), which will result in the inability to reconnect to the stream with good quality. In this case, we recommend creating a manual stream reconnection, where the streamer will create a new streaming key while the consumers will have to refresh their player instance.
* The **video codec must be H.264**.
* The **audio codec must be AAC or MP3**.

## Recommended setting for ingestion
### Reconnection to a live stream

Video codec: H.264
Audio codec: AAC/MP3
Bitrate encoding: CBR
Keyframe Interval: 2 second
The streaming software and hardware must be configured to reconnect in less than 1 minute in case of disconnection. During a disconnection on ingest side, reconnection must occur within 1 minute.

| Quality | Framerate | Video bitrate | Audio sample rate | Audio Bitrate |
| -------- | --------- | -------------------------- | ----------------- | ------------- |
| 240p | 25-30 fps | 300-700 Kbps | 44,1 kHz | 64 Kbps |
| 360p | 25-30 fps | 400-1000 Kbps | 44,1 kHz | 128 Kbps |
| 480p | 25-30 fps | 500-2000 Kbps | 44,1 kHz | 128 Kbps |
| 720p | (30 fps) | 25-30 fps 1500-4000 Kbps | 44,1 kHz | 128 Kbps |
| 720p | (60 fps) | 60 fps 2250-6000 Kbps | 44,1 kHz | 128 Kbps |
| 1080p | (30 fps) | 25-30 fps 3000-6000 Kbps | 44,1 kHz | 128 Kbps |
| 1080p | (60 fps) | 60 fps 4500-9000 Kbps | 44,1 kHz | 128 Kbps |
| 2160(4K) | (30 fps) | 25-30 fps 13000-34000 Kbps | 44,1 kHz | 192 Kbps |
| 2160(4K) | (60 fps) | 60 fps 20000-51000 Kbps | 44,1 kHz | 192 Kbps |
If reconnection does not happen within 1 minute, api.video considers the live stream as expired. Any new connection after this is treated as a new live stream event with a new DVR and a new recording.

## Recommendations

<Callout pad="2" type="info">
When [restreaming](/live-streaming/restreams), you should adapt the original live stream to fit the constraints of the restream destination's server requirements. api.video forwards the originating stream directly to the restream destination as received, without any modification.
</Callout>

- Bitrate encoding: CBR
- Keyframe Interval: 2 seconds

| Quality | Framerate | Video bitrate | Audio sample rate | Audio Bitrate |
| ----------------- | --------- | ----------------- | ----------------- | ------------- |
| 240p | 25-30 fps | 300-700 Kbps | 48 kHz | 64 Kbps |
| 360p | 25-30 fps | 400-1000 Kbps | 48 kHz | 128 Kbps |
| 480p | 25-30 fps | 500-2000 Kbps | 48 kHz | 128 Kbps |
| 720p (30 fps) | 25-30 fps | 1500-4000 Kbps | 48 kHz | 128 Kbps |
| 720p (60 fps) | 50-60 fps | 2250-6000 Kbps | 48 kHz | 128 Kbps |
| 1080p (30 fps) | 25-30 fps | 3000-6000 Kbps | 48 kHz | 128 Kbps |
| 1080p (60 fps) | 50-60 fps | 4500-9000 Kbps | 48 kHz | 128 Kbps |
| 2160p (30 fps) | 25-30 fps | 13000-34000 Kbps | 48 kHz | 192 Kbps |
| 2160p (60 fps) | 50-60 fps | 20000-51000 Kbps | 48 kHz | 192 Kbps |

## Limitations

<Callout pad="2" type="warning">
### Live stream recording

Live streams are recorded automatically. The length of each recording is fixed at 12 hours. When a recording reaches this length, a new recording is started.

### DVR

When a live stream is ongoing, viewers can replay earlier content with the DVR feature.

* The available duration for DVR is 1 hour.
* DVR is only available for live streams that are actively broadcasting.
* When a live stream is completed, api.video stores the DVR for as long as the duration the stream, but **at most for 1 hour**. For example, if the duration of the live stream is 15 minutes, then the DVR is available for 15 minutes after the stream is completed. Even if the stream is longer than 1 hour, the DVR is only kept for 1 hour. The cached DVR is subsequently deleted.

### Reusing a `streamKey`

You can create a new live event using the same `streamKey`, without keeping the DVR of the previous live event.

1. First, you should complete the previous live stream. Read more about completing a live stream [here](/live-streaming/working-with-live-streams#complete-a-live-stream).
2. After the previous live stream is completed, you can immediately reuse the `streamKey` with a new DVR and a new recording.

If you do not complete the previous live stream event, you must wait at least 1 minute 30 seconds to get a new DVR and recording before you can reuse a `streamKey` for a new event.

### Concurrent streaming

A live stream container only accepts a single live stream. It is not possible to create concurrent live streams on the same container.

### Sandbox limitations

* When using the sandbox environment, live streaming is limited to 24 hours.
* The **video codec must be H.264**
* The **audio codec must be AAC or MP3**
* DVR is exactly 1 hour
* During a disconnection on ingest side, re-connection must occur within 10 seconds
* When creating a new live event using the same `streamID` without keeping the DVR of a previous live, you must wait at least 5 minutes before re-using it
</Callout>
* Live streaming is limited to 30 minutes and will stop afterwards.
* Live stream recording length is fixed at 30 seconds, after which the recording is cut.
* Restreaming is only allowed for 2 minutes, after which the restreams are stopped.
10 changes: 1 addition & 9 deletions live-streaming/restreams.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,19 +6,11 @@ meta:

# Restreaming

<Callout pad="2" type="warning">
**Beta Feature**

Please note that Restreaming is currently a beta feature. The api.video engineering team is continuously working on improving the feature, thus issues may occur.

If you are experiencing an issue, please do not hesitate to contact our support team.
</Callout>

api.video enables you to broadcast a live stream to multiple platforms simultaneously. You can stream to Youtube, Twitch, and any other platform that supports streaming through `RTMPS` or `RTMP` protocols from one source.

## How it works

<Image src="/_assets/live-streaming/restreams/restreams-light.svg" src_dark="/_assets/live-streaming/restreams/restreams-dark.svg" alt="A diagram that shows RTMP restreaming on different platforms" />
<Image src="/_assets/live-streaming/restreams/restreaming-light.svg" src_dark="/_assets/live-streaming/restreams/restreaming-dark.svg" alt="A diagram that shows RTMP restreaming on different platforms" />

You can add restreams to an existing live stream or you can create a live stream that already includes the restream list.

Expand Down
2 changes: 1 addition & 1 deletion openapi.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -14751,7 +14751,7 @@ components:
data:
description: Returns an array of metrics and the timestamps .
type: array
items:
items:
type: object
properties:
emittedAt:
Expand Down
119 changes: 33 additions & 86 deletions sdks/player/apivideo-android-player-analytics.md
Original file line number Diff line number Diff line change
@@ -1,121 +1,68 @@
---
## THIS FILE IS AUTOMATICALLY GENERATED. DO NOT EDIT. IF YOU NEED TO CHANGE THIS FILE, CREATE A PR IN THE SOURCE REPOSITORY.
title: api.video Android Player analytics plugin
meta:
description: The official api.video Android Player analytics plugin for api.video. [api.video](https://api.video/) is the video infrastructure for product builders. Lightning fast video APIs for integrating, scaling, and managing on-demand & low latency live streaming features in your app.
title: api.video Android player analytics
meta:
description: The official api.video Android player analytics library for api.video. [api.video](https://api.video/) is the video infrastructure for product builders. Lightning fast video APIs for integrating, scaling, and managing on-demand & low latency live streaming features in your app.
---

# api.video Android Player analytics plugin

[api.video](https://api.video/) is the video infrastructure for product builders. Lightning fast video APIs for integrating, scaling, and managing on-demand & low latency live streaming features in your app.

## Project description

Android library to manually call the api.video analytics collector.

This is useful if you are using a video player for which we do not yet provide a ready-to-use
monitoring module.
This library sends player events from the player to api.video.

## Getting started

### Installation

#### Gradle

In your module `build.gradle`, add the following code in `dependencies`:
For ExoPlayer, add the following code in your module `build.gradle`:

```groovy
dependencies {
implementation 'video.api:android-player-analytics:2.0.2'
implementation 'video.api.player.analytics:android-player-analytics-exoplayer:3.0.0'
}
```

### Permissions
### Code sample

Register the ExoPlayer player analytics agent with:

```kotlin
import androidx.media3.exoplayer.ExoPlayer
import video.api.player.analytics.exoplayer.extensions.addApiVideoAnalyticsListener

val exoplayer = ExoPlayer.Builder(context).build()
val listener =
exoplayer.addApiVideoAnalyticsListener() // Register the ApiVideo exoplayer analytics listener so it sends player events to api.video.

In your `AndroidManifest.xml`, add the following code in `<manifest>`:
// Remove the analytics listener when you don't need it anymore.
exoplayer.removeAnalyticsListener(listener)
```

```xml
For a custom domain collector, use:

<uses-permission android:name="android.permission.INTERNET" />
```kotlin
val listener =
exoplayer.addApiVideoAnalyticsListener(collectorUrl = "https://collector.mycustomdomain.com") // Register the player analytics listener so it sends player events to api.video.
```

## Sample application

A demo application demonstrates how to use player analytics library.
A demo application demonstrates how to use player.
See [`/example`](https://github.com/apivideo/api.video-android-player-analytics/tree/main/example)
folder.

## Documentation

### Options

The analytics module constructor takes a `Options` parameter that contains the following options:

| Option name | Mandatory | Type | Description |
|--------------------:|-----------|-----------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------|
| mediaUrl | ** | | |
| yes** | String | url of the media (eg. `https://vod.api.video/vod/vi5oDagRVJBSKHxSiPux5rYD/hls/manifest.m3u8`) | |
| videoInfo | ** | | |
| yes** | VideoInfo | information containing analytics collector url, video type (vod or live) and video id | |
| metadata | no | ```Map<String, String>``` | object containing [metadata](https://api.video/blog/tutorials/dynamic-metadata/) |
| onSessionIdReceived | no | ```((sessionId: String) -> Unit)?``` | callback called once the session id has been received |
| onPing | no | ```((message: PlaybackPingMessage) -> Unit)?``` | callback called before sending the ping message |

Options instantiation is made with either mediaUrl or videoInfo.

Once the module is instantiated, the following methods have to be called to monitor the playback
events.

### ApiVideoPlayerAnalytics API

#### Event time or current time

If you know the event timestamp, you can use it as the `eventTime` parameter. If you don't know the
event timestamp, you can set the `currentTime` parameter with a scheduler.

**`play(eventTime: Float = currentTime): Future<void>`**

method to call when the video starts playing for the first time (in the case of a resume after

paused, use `resume()`)

**`resume(eventTime: Float = currentTime): Future<void>`**
While running the example, you can set your video Id:

method to call when the video playback is resumed after a pause
1. Enter a new media Id
2. Press on `Load` button

## Documentation

**`ready(eventTime: Float = currentTime): Future<void>`**

method to call once the player is ready to play the media


**`end(eventTime: Float = currentTime): Future<void>`**

method to call when the video is ended


**`seek(from: Float, to: Float): Future<void>`**

method to call when a seek event occurs, the `from` and `to` parameters are mandatory and should

contains the seek start & end times in seconds

**`pause(eventTime: Float = currentTime): Future<void>`**

method to call when the video is paused


**`destroy(eventTime: Float = currentTime): Future<void>`**

method to call when the video player is disposed (eg. when the use closes the navigation tab)


**`currentTime`**

field to call each time the playback time changes (it should be called often, the accuracy of the

collected data depends on it) if you don't know event time.
A complete [Android player analytics documentation](https://apivideo.github.io/api.video-android-player-analytics/) is
available.

### API documentation
## FAQ

A complete [API documentation](https://apivideo.github.io/api.video-android-player-analytics/) is available.
If you have any questions, ask us in the [community](https://community.api.video) or use [Issues](https://github.com/apivideo/api.video-android-player-analytics/issues).
4 changes: 2 additions & 2 deletions sdks/player/apivideo-android-player.md
Original file line number Diff line number Diff line change
Expand Up @@ -26,15 +26,15 @@ In your module `build.gradle`, add the following code in `dependencies`:

```groovy
dependencies {
implementation 'video.api:android-player:1.5.0'
implementation 'video.api:android-player:1.5.1'
}
```

For Jetpack Compose, also add the following code in `dependencies`:

```groovy
dependencies {
implementation 'video.api:android-compose-player:1.5.0'
implementation 'video.api:android-compose-player:1.5.1'
}
```

Expand Down
Loading

0 comments on commit dcac1e0

Please sign in to comment.