Non-Interactive Live Streaming

Guide to Uploading Streams to Sariska

Welcome to the comprehensive guide on uploading content to Sariska. Whether you're connecting your backend to Sariska for sports streaming cameras, utilizing HTTP backend servers, or integrating with OTT platforms and surveillance systems, this guide has got you covered. If you have use cases such as server-side ad ingestion or adding interactivity within the stream for the mentioned scenarios, you'll need to incorporate the conferencing SDK to achieve the same. This is the reason we have divided all live streaming use cases into two buckets: interactive and non-interactive. This categorization can quickly provide you with ideas on which method to use for your specific use cases.

Follow this concise guide to achieve everything in minutes.

1. Start streaming api call:

 --location 'https://api.sariska.io/terraform/v1/hooks/srs/startRecording' \
--header 'Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IjZlZWE4ZGZjZTU4MDgwZDljNzRhYWMyYWM2YjY4NmExYTdjZjEwMDI2MWUyNTcxMjMzMWM4OGRlOGY2MWM3MjciLCJ0eXAiOiJKV1QifQ.eyJjb250ZXh0Ijp7InVzZXIiOnsiaWQiOiJuNmtkb3JlaiIsImF2YXRhciI6IiNDM0MwMDQiLCJuYW1lIjoiQnJhamVuZHJhIn0sImdyb3VwIjoiMSJ9LCJzdWIiOiJnd2ZnbWp5cHdleWo2dnIydjR1MWlzIiwicm9vbSI6IioiLCJpYXQiOjE3MDM5NjEyNzMsIm5iZiI6MTcwMzk2MTI3MywiaXNzIjoic2FyaXNrYSIsImF1ZCI6Im1lZGlhX21lc3NhZ2luZ19jby1icm93c2luZyIsImV4cCI6MTcwNDEzNDA3M30.hVlkl73UORIa9JmKR9_vf0Tu889AkAmAedrCDq7q7xLloQo1Ulfw-2NBIVtbdvo24Ih0Lnp56Ltt28jT0NtjPs4u5L_bUrL6ugJTAL-O3K7NceiwZ6rTs80dTxKg3EheVHaTjrQPNfa_Pxq-gieIE8fe1J-zzQi6N3XyVP5eCGJPQF5EBznCAggL2NKMh4y1ruMN-l139pdS9EpKMXPh4aX1ivWh8yK4KQqw6yAVjehfjvFt94vD7EM0phDR0pq1ZGB3UTxfpZqeQnwjtddwUKGoxjnhkDq9Vada4q9vZi8t9svbinBqjsBDUW9-Vyn9NKZlnwqY5FwUNhgcJEBjsg' \
--header 'Content-Type: application/json' \
--data '{
    "is_direct_ingestion": true,
    "is_low_latency": true
}'

2. Output of the API:

{
    "started": true,
    "stream_path": "u14yfi6omm2pykwg/bk62ay2r0ujv4ep5",
    "srt_ingest_url": "srt://streaming-origin-nlb-udp-18e9b4f76e77d26e.elb.ap-south-1.amazonaws.com:10080?streamid=#!::h=ll_latency_h264,r=u14yfi6omm2pykwg/bk62ay2r0ujv4ep5,m=publish",
    "flv_ingest_url": "http://streaming-origin-nlb-tcp-42cfb50c096a82ed.elb.ap-south-1.amazonaws.com:8936/u14yfi6omm2pykwg/bk62ay2r0ujv4ep5.flv?vhost=ll_latency_h264",
    "rtmp_ingest_url": "rtmp://streaming-origin-nlb-tcp-42cfb50c096a82ed.elb.ap-south-1.amazonaws.com:1935/u14yfi6omm2pykwg/bk62ay2r0ujv4ep5?vhost=ll_latency_h264",
    "srt_play_url": "srt://streaming-origin-nlb-udp-18e9b4f76e77d26e.elb.ap-south-1.amazonaws.com:10080?streamid=#!::r=u14yfi6omm2pykwg/bk62ay2r0ujv4ep5,m=request,h=ll_latency_h264",
    "flv_play_url": "http://streaming-edge-nlb-tcp-d2d9b7821f042c80.elb.ap-south-1.amazonaws.com:8080/u14yfi6omm2pykwg/bk62ay2r0ujv4ep5.flv?domain=ll_latency_h264",
    "rtmp_play_url": "rtmp://streaming-edge-nlb-tcp-d2d9b7821f042c80.elb.ap-south-1.amazonaws.com:1935/u14yfi6omm2pykwg/bk62ay2r0ujv4ep5?domain=ll_latency_h264",
    "low_latency_hls_url": "https://low-latency-edge.sariska.io/u14yfi6omm2pykwg/bk62ay2r0ujv4ep5/original/playlist.m3u8"
}

3. Stop streaming api call: There is no api call for stop streaming call, stop streaming hook auto detected in the backend in case direct ingestion method.

Now, let's delve into the reasons behind having multiple player and ingestion URLs, examining each of them in detail. Understanding these elements is crucial as they directly impact the experience of live streams and integration time.

Players URL's:

  1. HLS (HTTP Live Streaming): Widely adopted globally, HLS operates over HTTP, offering compatibility with various devices and CDNs. By employing in-memory transcoding and optimized distribution( also called low-latency HLS), latency has been reduced to remarkable levels, reaching 1-2 seconds. You can use the low-latency HLS URL for the most optimal performance, as it falls back to normal when low latency is not supported by players.

  2. SRT: Boasting a low latency of 100 ms, SRT is not widely supported for video playback, limiting its usage in comparison to other protocols.

  3. RTMP: With a latency of 1-3 seconds, RTMP is well-suited for backend use cases and flash based devices, providing a reliable streaming solution.

  4. FLV: Featuring a latency of 3-5 seconds, FLV is suitable for backend use cases and flash based devices, catering to specific streaming needs.

Ingestion URL's:

  1. FLV Ingestion: Effortlessly upload FLV files to the Sariska streaming server via simple HTTP post calls, making the process as straightforward as posting your file through HTTP.

  2. RTMP Ingestion: RTMP (Real-Time Messaging Protocol) stands out as a well-established choice for live streaming, especially with Adobe Flash players. Note its limitations for newer applications and HEVC-encoded content due to the discontinuation of Adobe Flash.

  3. SRT Ingestion: SRT (Secure Reliable Transport) is an open-source, codec-agnostic protocol offering codec flexibility and gaining prominence as an RTMP successor. Its enhanced security features and improved reliability make it a preferred choice for content creators, broadcasters, and streaming platforms.

  4. RTSP Ingestion: RTSP (Real-Time Streaming Protocol) is ideal for ingesting streams from IP cameras to the Sariska server. This standard protocol ensures real-time control and delivery of audio and video data, making it suitable for diverse streaming applications.

Note: For RTSP, minimal manual effort is required, as the streaming process involves providing the RTSP server URL for configuration. Once configured, the system seamlessly pulls streams from IP cameras.

For a comprehensive understanding of API flags and enhanced features, please refer to the Swagger URL provided below. Enabling each feature is straightforward, requiring a simple 'true' parameter.

We have presented this information from a technical standpoint, emphasizing the versatility of this approach, given the myriad potential use cases. Explore the Swagger documentation for a detailed overview of API flags and enhanced functionalities

Last updated