Working on a plugin to update a published video

[GregRc]

Hi, I’m a french dev with some work to do on https://tube.reseau-canope.fr/, most notably making a plugin to allow updating a published video. That’s currently not possible and doesn’t seem to be in line for a near future, for reasons that are understandable but publishing is restricted in our instance, and those allowed users need that functionnality. I watched 2 of our admins updating a video with the shell, that sure was quite tedious and a plugin doing the same thing certainly would be appreciated. So, as Peertube contributions rules state that any dev work should be told first, here I am

This plugin would also allow that fonctionnality to some users profiles only (checkboxes in plugin setup), with a textarea so that reasons for video update are explained and logged (along with date and user who did the update).

Also, any tip or advice is welcome as I’m 100% new to Peertube, NodeJS and Typescript, being a PHP/Typo3 and JS/ES6 dev first :D. For now I have a local peertube v4 instance running fine on Docker, installed with some help from an admin. Cheers!

[EricG]

Hi, I’m a colleague of GregRc.
I copy/paste below some of our first ideas on how such a features could work, so don’t hesitate to challenge it with your own ideas.
(this feature allowing the replacement of the video source file an already existing video has granted a lot of votes and is now on the roadmap for Peertube v6 expected for the end of 2023).

So we imagine a new tab in the « Update » window of an existing video.
This tab will contain :

• a button to load the new video files from the hard disk (Questions : how to maintain the multiple import possibilities of Peertube : as an alternative, there could also be a field to specify the link to the video on youtube, no ? And for bitorrent users ?)
• a text box to enter the reason of the replacement

In the admin section (or in the config file ?), administrators could specify which user will have the right to access this tab (for example only admins, or admins and moderators, or the users too).
Even better, we could allow to override this global settings at a per user level (for example globally disabled for the users in the admin panel, but activated for user1 and user2 on their respective user’s settings pages).
Maybe it could be also usefull to be able to specify this for external authentification plugin (ldap, openID, etc.) ?

Then when an allowed user replace a video, we could save in the database the date of change, the user who did it, and the reason (even the name of the new file, it could be usefull). All thoses infos could be presented in a journal of the video (maybe accessible not only to the owner of the video, but also to the admin and moderators, and why not to the public (behind the 3 dots menu ?).

Of course, this replacement should be possible without changing the embed or download url of the previous version, which could have been used elsewhere.

So, any other ideas or warning about such feature ?
Best regards.

[EricG]

Hi, I’m still wondering about the better way to implement this incoming feature (through our plugin, and later through the official support announced in the roadmap).

I’m wondering where the info of the video version and replacement date should be displayed, in the visitor’s perspective, and for the administrator/moderator’s one.
The general idea IMHO is to displayed two date side-by-side : the « Originally published the… » and the « Last version published the… »

So I begin with the visitors perspective :

1- On the video page, just under the Title and in the metadata section below the description

Maybe the second place in my screenshot in enough ( « Originally published the… » and followed by the « Last version published the… »)

---

Then, for administrator/moderator (I think both could see the same info) :

1- in the Administration/Preview/Video section

In addition to the « Originnaly published the… » we should add the date of the last replacement of the video.

2- in the « Update video » page

In the advanced settings tab, we should add the replacement date (here it could be only the last replacement, or even better, a complete journal (diary ?) of all the replacement (where we could also add usefull informations like those described in my previous post, like user name, reason of replacement, name of the new files…)

By the way, on this screen capture, there is also the field « Name of the file » (the info bubble saying that it’s the name of the uploaded file) ; in case of a replacement via comand line, the field keeps displaying the name of the first uploaded file, not the last version. Maybe this could be fix right now ?

3- in the Administration/moderation page
Same idea here as in the Video section.

This makes me wonder if the auto-blaklist feature should be triggered also for a replacement ? I think we could use the same rules as for a new video (so administrators could enable auto-blacklist for a replacement, then de-activate it for a trusted user.

What do you think about it ? Thanks

[EricG]

Hi everyone, I thought this draft of specifications would have attracted more reactions

On our side, we are still working on it, but our dev GregRc is also occupied by other tasks, and keep going on learning how Peertube works. So I’m wondering how @Chocobozzz you plan to start working then deploy this feature :

• do you plan to re-use our plugin code (if released in time)
• or do you plan to start from zero (and let our plugin have it’s own behaviour in parallel) ?

In both situation, do you have some specifications already written for this ? (in a « user » perspective, I could contribute to it as I tried to do in my previous posts ; and in a dev perspective, GregRc could collaborate with you and other dev when he will start, and benefits from your advice).

Thanks in advance for your reply. Eric.

[Chocobozzz]

Hello,

We have a PR from an external contributor on Upload new version of video by kontrollanten · Pull Request #5601 · Chocobozzz/PeerTube · GitHub (I did not check the code yet).

We plan to develop this feature in few months so I haven’t taken the time to study this in detail, so sorry but I can’t answer at the moment.

[EricG]

Ok and thanks pointing me this PR.

I keep going listing here some key aspects and « warnings » about this incoming update video feature.

On our instance, we only transcode in HLS by default, to preserve storage.
But in some cases, we manually launch webtorrent transcoding after the first upload (for example when we need to embed Peertube video inside an H5P interactiv module in Moodle, which doesn’t support well HLS at this time).

But if for some reasons we have to replace the fisrt uploaded video file, only the HLS resolutions and the 1080 webtorrent resolution, are recreated from the newer uploaded file. I understand this is the normal behavior, because we previously set up « we only want HLS transcoding » in admin (and because the 1080 webtorrent is an intermediate transcoding requested for the HLS transcoding, right ?).

So IMHO, it would be smarter that the incoming update video feature (and maybe the CLI process already available) checks at first which transcoding already exists, and launch the same transcoding of the newer video during the replacement.
So if only HLS already exists, the newer video will be transcoded only in those HLS resolution.
But if Webtorrent resolution already exists (even if the admin settings doesn’t « ask » for it), those files are also transcoded and replaced.

Could this behavior have some negative side effects ?

Thanks for the ongoing brainstorming
Eric