OTSubscriberVideoEventReason Constants Reference
| Declared in | OTSubscriberKit.h |
|---|
OTSubscriberVideoEventReason
Video enabled and disabled events are accompanied with a reason code, for determining why the video track was enabled/disabled.
Definition
typedef NS_ENUM(int32_t, OTSubscriberVideoEventReason ) {
OTSubscriberVideoEventPublisherPropertyChanged = 1,
OTSubscriberVideoEventSubscriberPropertyChanged = 2,
OTSubscriberVideoEventQualityChanged = 3,
OTSubscriberVideoEventCodecNotSupported = 4,
};
Constants
OTSubscriberVideoEventPublisherPropertyChanged-
The video event was caused by the stream’s publisher changing the value for OTPublisherKit.publishVideo.
Declared In
OTSubscriberKit.h. OTSubscriberVideoEventSubscriberPropertyChanged-
The video event was caused by a change to this subscriber’s OTSubscriberKit.subscribeToVideo property.
Declared In
OTSubscriberKit.h. OTSubscriberVideoEventQualityChanged-
The video event was caused by a change to the video stream quality. Stream quality may change due to network conditions or CPU usage on either the subscriber or publisher.
When enabled, audio fallback provides an event when the subscriber drops the video stream due to degraded video quality, resulting [OTSubscriberKitDelegate subscriberVideoDisabled:reason:] message is sent. When conditions improve, the video stream resumes, and the [OTSubscriberKitDelegate subscriberVideoEnabled:reason:] message is sent.
When the video stream is dropped, the subscriber continues to receive the audio stream, if there is one.
When the Subscriber’s stream quality deteriorates to a level that is low enough that the video stream is at risk of being disabled, the [OTSubscriberKitDelegate subscriberVideoDisableWarning:] message is sent. The [OTSubscriberKitDelegate subscriberVideoDisableWarning:] message is sent before the [OTSubscriberKitDelegate subscriberVideoDisabled:reason:] message is sent.
In routed sessions, the source of this video event can be either the Vonage Video Media Router (Subscriber Audio Fallback) or the publishing client (Publisher Audio Fallback). When the publishing client is the source, the corresponding stream for that subscriber will have its [OTStream hasVideo] property updated to
NOas an additional change alongside the video disabled message. Although this typically indicates network degradation on the publisher’s side, subscriber-reported metrics can influence fallback decisions, which may make the exact source of the degradation less clear.In relayed sessions, audio-only fallback is applied exclusively due to the publisher’s internal audio-fallback logic (Publisher Audio Fallback). In this case, the subscriber may stop receiving video due to network degradation, but the associated stream object will not have its [OTStream hasVideo] property updated, since the stream may still include video data for other subscribers with better network conditions. Note that although fallback originates from the publisher in relayed sessions, degradation may occur on either the publisher or subscriber side.
You can control audio-only fallback behavior by setting the corresponding properties when creating the publisher. By default, [OTPublisherKitSettings subscriberAudioFallbackEnabled] is set to
YES(except for screen-sharing publishers in routed sessions, where it isNO), and [OTPublisherKitSettings publisherAudioFallbackEnabled] is set toNO. To change this, set [OTPublisherKitSettings subscriberAudioFallbackEnabled] toNOto disable subscriber fallback, or set [OTPublisherKitSettings publisherAudioFallbackEnabled] toYESto enable publisher fallback. See OTPublisherKitSettings.Declared In
OTSubscriberKit.h. OTSubscriberVideoEventCodecNotSupported-
The video event was caused when video in the the subscriber stream was disabled because the stream uses a video codec (such as H.264) that is not supported on the device.
Declared In
OTSubscriberKit.h.
Declared In
OTSubscriberKit.h