Live streaming

[Chocobozzz]

note: no particular code review is expected due to the amount of changes brought in this PR.

Common

• Lives are PeerTube videos with a special flag
• For now we handle live streams only with RTMP protocol (OBS etc)
• Lives use our HLS player with p2p-media-loader
• Every live have their own RTMP stream key (it's not per channel like on twitch for example) so users can create multiple lives in a specific channel
• Users can choose to save a replay of their live (disabled by default). In this case, PeerTube will check if the quota is not exceeded and may terminate the live if so
• A live can be blacklisted or deleted: then it will automatically be ended

UX to create a live:

• We added a Go live tab in the upload page
  
• Live attributes are mostly the same as videos attributes (except for the wait transcoding and schedule publication options)
• A new Live settings tab is available in the video edit form. It contains the RTMP information, live stream key and a checkbox allowing users to automatically save their live (if enabled by the admin)
  
• Then the live container is ready, and the user can send a RTMP stream
• The live URL is in the same format as the video URL
• A display live information option is available to the uploader to display live information (rtmp URL, stream key etc)
  
  
• If the save replay option is enabled, the live video will be replaced by the replay (which means the URL won't change)
• If the save replay option is disabled, the live will automatically be deleted
• A public live is displayed in videos list if it is published, ie when the streamer actually streams into it
• A live can be accessed using its URL, even if it's not published. If the live has not yet started, a message is displayed and the player is black
• The player will automatically play the video when the live is ready

Admin config

• Live streaming is disabled by default
• Allowing users to automatically save their live is disabled by default
• Admins can set a limit of created lives on their instance (to limit bandwidth issues)
• Admins can set a limit of created lives per user (to limit spam, and share resources)
• Admins can set a max duration for lives
• Live transcoding is disabled by default. If disabled, PeerTube will try to mux the RTMP stream which requires less CPU. I am not really sure if it will correctly work in every cases. Enabling transcoding ensures the stream will correctly be played by users. Admins can also enable additional transcoding resolutions, for low bandwidth users

Architecture:

• Live is just a video with isLive to true in DB. Then, the same API is used to fetch/update/delete a live video as a vod video
• There are 3 new endpoints for lives:
  • POST /videos/live to create a live (same parameter as to create a vod video + some additional params like saveReplay)
  • GET /videos/live/:videoId to fetch specific live info (rtmp URL, stream key, save replay)
  • PUT /videos/live/:videoId to update specific live info (save replay)
• When PeerTube receives a RTMP stream, it uses the stream key to retrieve live info. If everything is okay (video not blacklisted etc), PeerTube creates the ffmpeg command to mux or to transcode RTMP stream into HLS playlist
• PeerTube watches new added segments to generate a hash (for p2p-media-loader) and check if user quota and live duration are okay
• When the live ended a job is created to:
  • Delete the live if save replay is disabled
  • Generate the replay if save replay is enabled. In this case, PeerTube will concat ts segments into a fragmented mp4 file of all available live resolutions (depending on live transcoding resolutions enabled by the admin)
• There is a notification system using socketIO so clients can subscribe to live videos state change: /live-videos
• Views sent by clients and other instances expire after 5-10 minutes. This way we have an approximation of how many people watch a video. Unfortunately with the federation it's difficult to have an exact counter

TODO (to discuss)

• Real tests to adjust HLS playlist parameters (segments in the playlist, segments duration etc)
• Adjust RTMP server params (timeout etc)
• Real tests to know if just muxing works in most cases
• Real tests to adjust live transcoding settings
• Remember the stream key of the last ended live, so that the stream key does not change every time to create a live (pita to update the stream key in OBS parameter every time you want to stream for example)
• Community feedback
• User documentation https://framagit.org/framasoft/peertube/documentation/-/merge_requests/76
• ~(Angular bug?) When the player automatically plays a live, the *This live has not started yet. * message is not hidden
• Live notifications for admins? (a live started etc)~
• Allow admins to enable live only for specific accounts
• Dedicated views for lives (requires interviews, work and discussion with our UX designer/community)

[Chocobozzz]

Description updated. Miss OpenAPI doc and then ready to merge

[test2a]

@Chocobozzz hi. been waiting for the PR but the screenshot does not show "unlimited" in duration. does this mean we cannot have like the nasa livestream yet which is 24x7 live and does not require saving ?.

[Chocobozzz]

@Chocobozzz hi. been waiting for the PR but the screenshot does not show "unlimited" in duration. does this mean we cannot have like the nasa livestream yet which is 24x7 live and does not require saving ?.

Yes there is an unlimited option for every constraint field (lives per instance/user and duration)

[test2a]

@Chocobozzz max live duration does not show unlimited in the label like it does for two inputs above it. maybe that text was missed ?

[Chocobozzz]

max live duration does not show unlimited in the label like it does for two inputs above it. maybe that text was missed ?

Because it's a select that has the unlimited option, whereas the previous inputs are number fields.

Merging to avoid package.json/yarn.lock conflicts. Feel free to comment even if this PR is closed.

[kimsible]

Hi @Chocobozzz thanks and congrats for all the work and this well documented PR.

As I understand, the live use HLS player and transcoder. So we can't have an audio only live ?
Sometimes streamers may not want to have any video like a « radio libre » and with only a cover to picture the live.
Maybe you keep this feature for later ? or it is not technically possible due tu HLS for the moment ?

Live notifications for admins? (a live started etc)

I think it could be a good thing, since live can be very expensive for the server when transcoding is enabled.

Allow admins to enable live only for specific accounts

It could also be an interesting feature, we may want to have multiple type of creators (streamers, podcaster, vlogger...)

Dedicated views for lives (requires interviews, work and discussion with our UX designer/community)

It may be a good idea for a next PeerTube version ? If the live feature has new sub-features I think, we need take that path.

[rigelk]

or it is not technically possible due to HLS for the moment ?

@kimsible it is possible, HLS being already usable for audio-only videos anyway. I guess it has more to do with the fact we consider PeerTube to be for streaming videos first and foremost, and thus didn't consider radios at all in our interviews.

[Zykino]

Congratulation on achieving this! Hype!!! 🎉

Just a comment (not sure if it is better here or on Github): The stream infos (especially the key) should be hidden by default. The copy button should still work while hidden.
Twitch (and even streamlabs) hide the keys. On twitch there is even a popup to display the key. See my screenshots (from the french interface).

Default view of the streaming key

Clicking on "show" makes a confirmation popup appear.
Text is in french so I wont copy translate, but it tells in bold and red to never share the key and ask for confirmation.
The popup disappear after some times: the time to Shift+Tab and write this.

By the way what happens if 2 OBS start a stream on the same key ? Second override the first ?

[kimsible]

or it is not technically possible due to HLS for the moment ?

@kimsible it is possible, HLS being already usable for audio-only videos anyway. I guess it has more to do with the fact we consider PeerTube to be for streaming videos first and foremost, and thus didn't consider radios at all in our interviews.

Thanks for the details @rigelk.

we consider PeerTube to be for streaming videos first and foremost, and thus didn't consider radios at all in our interviews

This is hard to receive this argument though PeerTube can upload audio files (mp3, wav, ogg, ...). Even if audio files are put in a MP4 container, there is no video track or just a small 480p for video with cover.

This option should be available because, the live is something that requires lots of resources, some instances might limit the live for only audio and a cover for example.

But maybe, I didn't use the right term it's more podcast than « radio », I didn't meant a constant feed like we see on YouTube, just a short live but audio only, with eventually a cover.

[llebout]

Hello, awesome work!

How effective is the P2P media sharing? I imagine that the more delayed the stream is, the more effective it is because more peers will have the media but no one wants a delayed "live" stream, so availability of media is concentrated on the PeerTube instance which means the effectiveness of P2P media sharing is much worse. Is that correct? Does PeerTube intentionally delay viewers for more P2P media sharing effectiveness?

I think for more effectiveness one must create another protocol for P2P streaming (not RTMP, multicast RTMP over WebRTC?) and use multiple times the bandwidth on the recorder side to push media to several viewers at the same time which can then use their own bandwidth to push further. PeerTube instance being one of these "viewer" peers.

To sum up, the ordered nature of live streaming kills P2P data sharing effectiveness.

Thank you

[Chocobozzz]

@kimsible @rigelk

So we can't have an audio only live ?

@kimsible it is possible, HLS being already usable for audio-only videos anyway. I guess it has more to do with the fact we consider PeerTube to be for streaming videos first and foremost, and thus didn't consider radios at all in our interviews.

Unfortunately no, until we manage to play a mp4 without video stream in hls.js. I created an issue: #3281

@Zykino

By the way what happens if 2 OBS start a stream on the same key ? Second override the first ?

The second live will be rejected: https://github.com/Chocobozzz/PeerTube/blob/develop/server/tests/api/check-params/live.ts#L404

@Leo-LB

How effective is the P2P media sharing?

We don't really know for now. And it depends on many things: amount of segments in the playlist, segments size, how many segments are ahead (depends on the live lag) etc. We need to make some tests to adjust these parameters.

Is that correct? Does PeerTube intentionally delay viewers for more P2P media sharing effectiveness?

Yes and yes :) I think in the future we'll add a live attribute for uploaders so they decide the "live profile": aggressive (not that much lag but P2P not very effective) or the opposite (some lag but P2P effective).

[comster]

This is amazing! 🎉

If I can suggest a potential TODO / discussion that I haven't found yet...

What will it take to have pause and rewind support for live streams?

[erkinalp]

Pause&rewind requires server-side buffering.

[therahedwig]

Hey, I was thinking. If there is a possible limit on the amount of subsequent livestreams, might it be a good idea for an instance to have a reservation system? Right now, it's not really possible to communicate with other people on the same instance through peertube itself, and because livestreams often need to be planned out, it seems not unlikely that people would want to avoid scheduling conflicts. So, the ability to have a calendar, and to select a timespan on it for streaming (and to see who else is streaming at that moment), seems wise to me? Should I make a proper ticket for this?

[erkinalp]

Filed the ticket for OBS integration: https://ideas.obsproject.com/posts/1202/peertube-livestream-support

[DeadSuperHero]

Really amazing work so far!

I tested this out for the first time today. My only real concern is that the live player on my PeerTube instance was restricted to 480p, but OBS is broadcasting at 1080p. Was I missing a configuration setting somewhere? I enabled transcoding for the 1080p resolution in the admin settings, but haven't had any luck getting a higher resolution for my stream.

[DeadSuperHero]

Hey, sorry about that, false alarm - this was 100% user error on my part. I was not aware of the video output setting in OBS being lower than my input setting. PeerTube works perfectly as expected! :)

[prophpgeek]

When we are publishing a live stream to PeerTube from restream, it (randomly) gets disconnected and there are no logs that we can see/find to troubleshoot this error. Would really appreciate any help/ideas to fix this.

[tcitworld]

@prophpgeek Please open a new issue.