* Add Scheduled Lives functionality through originallyPublishedAt
Implements #6604 by reusing the originallyPublishedAt field of isLive videos to mark "waiting for live" videos as scheduled at a set time.
* Hide scheduled lives from Browse Videos page
* Add tests for Scheduled Live videos
* Make scheduled lives use a dedicated scheduledAt field in the VideoLive table
* Plan live schedules to evolve in the future
* Use a dedicated table to store live schedules, so we can add multiple
schedules in the future and also add a title, description etc. for a
specific schedule
* Adapt REST API to use an array to store/get live schedules
* Add REST API param so it's the client choice to include or not
scheduled lives
* Export schedules info in user import/export
---------
Co-authored-by: Chocobozzz <me@florianbigard.com>
* Add NSFW flags to videos so the publisher can add more NSFW context
* Add NSFW summary to videos, similar to content warning system so the
publisher has a free text to describe NSFW aspect of its video
* Add additional "warn" NSFW policy: the video thumbnail is not blurred
and we display a tag below the video miniature, the video player
includes the NSFW warning (with context if available) and it also
prevent autoplay
* "blur" NSFW settings inherits "warn" policy and also blur the video
thumbnail
* Add NSFW flag settings to users so they can have more granular
control about what content they want to hide, warn or display
* add user agent video stats
closes#6832
* Disable indexes, support start/end dates
* move ua parsing to client
* Openapi, inline body request, update tests
---------
Co-authored-by: Chocobozzz <me@florianbigard.com>
* Split "my library" into "video space (channels, videos...)" and "my library (playlists, history...)"
* Split "admin" into "overview (users, videos...)", "moderation (abuses, blocks, registrations...)" and "settings (configuration, runners...)"
* Reorganize the header and the left menu: account settings/notifications are now in the header
* Add instance information context in the left menu
* Merge dedicated videos pages for "recently added", "trending", "local videos" into a "browse videos" page that includes quick filters
* Clean up entire CSS
* Clean CSS variables so it's easier to theme PeerTube (some new variables fallback to old variables to limit currnet themes breakages)
* Replace the current light theme into a new one (beige)
* Add a dark (brown) theme (included in PeerTube core)
* Fix accessibility issues with old light theme colors (white on orange button for example)
* Redesign the left menu, the horizontal menu, form controls and buttons, "Discover videos" page and common video filters panel
* Replace/remove/add some global icon
Allows:
* The HLS player to propose an "Audio only" resolution
* The live to output an "Audio only" resolution
* The live to ingest and output an "Audio only" stream
This feature is under a config for VOD videos and is enabled by default for lives
In the future we can imagine:
* To propose multiple audio streams for a specific video
* To ingest an audio only VOD and just output an audio only "video"
(the player would play the audio file and PeerTube would not
generate additional resolutions)
This commit introduce a new way to download videos:
* Add "/download/videos/generate/:videoId" endpoint where PeerTube can
mux an audio only and a video only file to a mp4 container
* The download client modal introduces a new default panel where the
user can choose resolutions it wants to download
Compat with text/html descriptions
Compat with SPDX for licences
Compat with missing sensitive attribute
Compat with missing tag attribute
Compat with missing video file magnet URI
Compat with missing streaming playlist segmentsSha256Url
Compat with optional comments/likes/dislikes/shares URI in video object
Add more debug logs when the object is not valid
* Comments and videos can be automatically tagged using core rules or
watched word lists
* These tags can be used to automatically filter videos and comments
* Introduce a new video comment policy where comments must be approved
first
* Comments may have to be approved if the user auto block them using
core rules or watched word lists
* Implement FEP-5624 to federate reply control policies