Ensuring Authentication in Live Streaming Publishing

[mdsohelmia]

When publishing a live stream on platforms like YouTube or Twitch, users need to obtain a stream key and use broadcasting software like OBS to publish the live stream to the platform. Maintaining the confidentiality of your stream key is essential, as anyone who obtains it can stream on your behalf, potentially publishing prohibited content and resulting in your account being blocked by the platform.

[mauricioabreu]

Thank you @mdsohelmia

I'm currently working on providing transcoding profiles. After finishing it, I will work on providing a way to secure both ingest and playout using tokens.

[mauricioabreu]

@mdsohelmia I was checking this feature yesterday, and I realized that to ingest a stream regardless the source, the endpoint has an UUID and it servers as a stream key. I'll create a wiki to document it. What is your opinion?

[mauricioabreu]

Maybe supporting user/password would be a good idea in case people don't believe in security by obscurity

[mdsohelmia]

@mauricioabreu sorry for the late response.

We can workflow design something like :

Create Stream Using this Payload: POST http://localhost:3000/streams

{
   "inbound_protocol": "rtmp",
   "name": "live",
   "outbound_protocols": [
      "hls",
      "dash"
   ],
   "profiles": [
      {
         "audio_codec": "aac",
         "audio_rate": 128,
         "bitrate": 6000000,
         "fps": 30,
         "height": 1080,
         "name": "1080p",
         "video_codec": "h264",
         "width": 1920
      },
      {
         "audio_codec": "aac",
         "audio_rate": 128,
         "bitrate": 2000000,
         "fps": 30,
         "height": 720,
         "name": "720p",
         "video_codec": "h264",
         "width": 1280
      },
      {
         "audio_codec": "aac",
         "audio_rate": 128,
         "bitrate": 500000,
         "fps": 30,
         "height": 360,
         "name": "360p",
         "video_codec": "h264",
         "width": 640
      }
   ],
   "recording": true,
   "recording_format": "hls"
}

We will get a response after creating a Stream:

{
    "name": "live",
    "ingestion_url": "rtmp://localhost/live/",
    "ingestion_key": "live_12345678_abcdefgh",
    "recording": true,
    "recording_format": "mp4",
    "created_at": "",
    "profiles": [
          {
            "name": "1080p",
            "bitrate": 6000000,
            "fps": 30,
            "width": 1920,
            "height": 1080,
            "video_codec": "h264",
            "audio_codec": "aac",
            "audio_rate": 128
        },
        {
            "name": "720p",
            "bitrate": 2000000,
            "fps": 30,
            "width": 1280,
            "height": 720,
            "video_codec": "h264",
            "audio_codec": "aac",
            "audio_rate": 128
        },
        {
            "name": "360p",
            "bitrate": 500000,
            "fps": 30,
            "width": 640,
            "height": 360,
            "video_codec": "h264",
            "audio_codec": "aac",
            "audio_rate": 128
        }
    ]
}

[mauricioabreu]

We already have a generated UUID. Does that work?

Regarding your example payload, that sounds good. We have a similar payload, including audio as a separate channel that can be reused.

[mdsohelmia]

@mauricioabreu we can use UUID. it's working

[mauricioabreu]

Good @mdsohelmia I'm closing this one. However, feel free to reopen if think the opposite.