Some complaints about how live streaming is implemented

When a live stream starts, it should be given a video ID.

Currently, we would have to add handling for two different resource types (live streams, and videos) when ideally it should just be a type of video with a live status.

This is how Mux and Cloudflare Stream implement this feature.

Hey @blake ,

thanks a lot for your valuable feedback and the time you took to share your thoughts. I’ve noted some key advantages of the suggested change:

  • Unified Resource Handling: Simplifying the codebase by treating live streams as a type of video with a live status ensures a more streamlined and cohesive approach.
  • Consistent API design: This consistency in API design makes it easier for developers to work with both types of content using a familiar set of endpoints and methods.
  • Simplified Client Implementation: A unified approach reduces complexity on the client side, making it easier for developers to work with both live streams and recorded videos seamlessly.

We appreciate your input, and we’ll make sure to share this feedback with our team. Depending on their evaluation, we’ll consider implementing this in the future. In case you missed it, you can identify if a video was generated from a recording by looking at the livestream id in the video object:

 "source": {
        "type": "live",
        "liveStream": {
            "liveStreamId": "li7CPKHeNeTYtA52CzFCB",
            "links": [
                {
                    "rel": "self",
                    "uri": "/live-streams/li7CPKHeNeTYtA52CzFCB"
                }
            ]
        }
    },

Thanks again for your insights!