Smarter Transcode Videos All (reset) Behaviour

[kevincox]

I have searched the existing feature requests, both open and closed, to make sure this is not a duplicate request.

• Yes

The feature

Right now when you change your transcoding settings they will only apply to new videos unless you click the "ALL" button. However the all button is pretty disruptive because it first deletes all existing transcodes, then queues the new jobs. This means that for a period of time (possibly days or weeks depending on number of videos, settings and sever speed) lots of videos will have no transcoded version which can have pretty significant effects such as preventing web-based playback.

There are a handful of ways that this could be improved.

1. Don't delete the old video until the new transcode is available (or the new settings decided that a transcode isn't needed).
2. Prioritize videos without a transcode available. (ie. transcode new uploads before re-transcoding old files)
3. General prioritization (for example transcoding shared, in album or newer videos first)

This would make re-transcoding nearly transparent which would make it a much better experience to change your transcoding settings or to take advantage of improvements to the encoders.

This would also have made my initial onboarding significantly better. When I onboarded I decided to encode using pretty slow AV1 settings. However this takes a long time and many of my videos weren't playable on the web until the task completed (about a week). With smarter re-encoding settings I could have done something like this:

1. Encode to h264 with fairly quick settings to get web-compatible previews working for all assets.
2. Start a very slow second encode with my higher quality settings to run slowly in the background. (I don't really care if this takes a few weeks because at least my videos are playable in the meantime even if not efficient).

Platform

• Server
• Web
• Mobile

[kevincox]

A similar feature would be nice for Smart Search indexing. Right now changing a model requires a reset which is very slow and means that search is very limited for a while. It would be great if the new indexes could be created first, then the search engine swaps over and deletes the old models. But this is different and more complex than the video feature being discussed here.

[Atemu]

A possible workaround I just discovered/thought of would be to re-encode one video at a time using the "refresh encoded video" function and then always wait for there to be no more transcoding in the job queue before you enqueue the next video.

This way it would only be one asset at a time that might have degraded service and it's unlikely (though not impossible) for a user to be affected by that particular video at any given moment.

[kevincox]

Yeah, that could definitely work as an external approach. Maybe next time I come across this I'll write a script to drive this slowly from outside. Obviously it would still be nice to have this integrated.