Single Stream Transcoding Stopped Callback
Description
When developers need to understand the single stream transcoding tasks of the current App, they can refer to Callback Configuration Description to configure related callback interfaces. After initiating a Stop Single Stream Transcoding request, they can view the result of stopping the transcoding task through this callback.
Callback instructions
- Request method: POST.
The callback data format is JSON. You need to perform UrlDecode decoding on it.
- Request URL: Please contact ZEGOCLOUD Technical Support to configure the callback URL.
- Transfer protocol: HTTPS/HTTP. HTTPS is recommended.
Callback parameters
| Common parameters | Type | Description |
|---|---|---|
| Event | String | Callback event. This callback returns transcode_stop. |
| Appid | String | Unique identifier of the App. |
| Timestamp | String | Server current time, Unix timestamp. |
| Nonce | String | Random number. |
| Signature | String | Verification string. For details, see Verification instructions. |
| Business parameters | Type | Description |
|---|---|---|
| TaskId | String | Unique identifier ID of the single stream transcoding task. |
| UserId | String | User ID of the user who initiated the stop transcoding task, customized by the developer. |
| Sequence | Int | Sequence number of stopping the transcoding task. |
| Status | String | Status of the transcoding task. The return value is TranscodeStopped: The transcoding task has been stopped. |
| StopReason | Int | Reason for stopping the transcoding task:
|
Data example
{
"Event": "transcode_stop",
"Appid": "111111",
"Timestamp": "timestamp",
"Nonce": "nonce",
"Signature": "signature",
"TaskId": "2222",
"UserId": "2222",
"Sequence": 0,
"Status": "TranscodeStarted",
"StopReason": 0
}Return response
Return HTTP status code 2XX (e.g., 200) indicates success, and other responses indicate failure.
Callback retry strategy
If the ZEGO server does not receive a response, or the received HTTP status code is not 2XX (e.g., 200), it will attempt to retry, up to 5 retries. The interval between each retry request and the previous request is 2s, 4s, 8s, 16s, and 32s respectively. If the 5th retry still fails, no more retries will be made, and the callback will be lost.