Generate storyboard on remote runners

[Flagelmann]

Describe the current behavior

I noticed the Peertube 6.x now, during the import phase on any video (I'm usually importing only MP4 Video files on my personal instance) on the backend the ffmpeg is always called and slowing the import process.

The transcoding is disabled globally but I still see that ffmpeg is being called. I have re-downloaded the video from the Perrtube web portal and I checked that the video file was not actually re-encoded at all, so no transcoding is happening but ffmpeg is still called anyway.

I suspect that this slowness is related to the generation of the storyboards using ffmpeg.

Is it possible to disable this behavior by adding even an additional option in the Peertube administration web section?

Steps to reproduce

1. Install Peertube 6.0.2
2. Import any video.
3. Keep track of the time needed to import the video after the upload process when clicking the Publish (without transcoding).
4. Using journalctl check an entry similar to the following:

2023-12-21 16:13:01.898 info: Processing generate storyboard of 206e171d-72e7-4980-9c5b-d4bb8f78aa1e in job 93774aa4-fca7-46fb-94c4-ff4ea8aec330.

Describe the expected behavior

I expected to see the same behavior as it was in Peertube 5.x, so no ffmpeg called during import phase if no transcoding is needed.

Additional information

• PeerTube instance:

  • Version: 6.0.3
  • NodeJS version: 18.17.0
  • Ffmpeg version: 4.1.11

• Browser name, version and platforms on which you could reproduce the bug: Chrome/Edge/Firefox

• Link to server log if relevant (journalctl or /var/www/peertube/storage/logs/): 2023-12-21 16:13:01.898 info: Processing generate storyboard of 206e171d-72e7-4980-9c5b-d4bb8f78aa1e in job 93774aa4-fca7-46fb-94c4-ff4ea8aec330.

[dhk2]

I to have noticed this behavior on a few of the 2 and 3 vcpu instances I help with. Very noticeable with larger channel imports. It maxes out the CPU well above the levels considered considerate for a shared VPS as well. Otherwise since the implementation of remote runners these cheap instances have been doing surprisingly well

Since the storyboard process uses FFMPEG, I was thinking the best solution would be to have the storyboard generation done by a remote runner, perhaps in conjunction with the initial vod-web-video-transcoding to save the bandwidth of sending the whole video just for the storyboard. Hadn't considered there'd be people who'd prefer the feature disabled completely.

[Flagelmann]

Well, actually it would be useful, I think, to have more chances to enable/disable most of the functionalities in Peertube software, as in that way the Peertube self-hosted instances could be tuned on different more or less powerful systems (like Raspberry Pi).

Specifically, for example, I do not need video storyboards so I would like to be able to enable/disable it based on my demand and not to be forced to use remote runners to offload the additional CPU computing just to be able to get a similar performance level of my self-hosted instance when storyboards were not available (Peertube 5.x).

So, finally, yes, it would be highly appreciated to be able to disable the storyboard generation process on new/imported videos.

[Chocobozzz]

Well, actually it would be useful, I think, to have more chances to enable/disable most of the functionalities in Peertube software, as in that way the Peertube self-hosted instances could be tuned on different more or less powerful systems (like Raspberry Pi).

Agreed, it's done in https://github.com/Chocobozzz/PeerTube/commit/b9077c83fcce0fab5bfcee0527be9256f6e517d0

[Flagelmann]

Hello,

I've just upgraded to 6.0.3.

Just to be sure, the ability to disable storyboard generation is not included in this new version, right?

Many thanks

[Chocobozzz]

Just to be sure, the ability to disable storyboard generation is not included in this new version, right?

Yes, it will be released in 6.1