[Feature]: Extend video transcoding support

[zackpollard]

Feature detail

Video transcoding has now been added for MOV files, however this should be extended. Making a note here as we discussed so this can be picked up and worked on:

• [x] We should convert anything that isn't already in the desired codec (h264 or VP9) or container (mp4), we should detect this using ffprobe
• [x] We should make quality (CRF, output resolution, encoding speed, etc) and potentially all ffmpeg settings customisable by the admin of the server
• [x] An admin page on the web interface for configuration options like the above
• [ ] We should allow hardware acceleration of the ffmpeg encode and decode (could be via the above, or auto detection of hardware presence)
• [x] Support remuxing container if not in supported format
• [x] Support re-encoding either audio or video if in incorrect format, rather than always both
• [x] Stop scaling up videos that are smaller than target quality
• [x] Stop scaling up videos that are in portrait mode

I believe this is everything we discussed around this, will update if I remember more.

Platform

Server

[JVT038]

Could it be possible to check whether direct streaming is possible, before transcoding? I know Edge supports HEVC for example (if the user paid), so transcoding would be unnecessary in that case. Also, a lot of modern mobile devices support HEVC as well. So check the compatibility before transcoding to save processing power.

[zackpollard]

I don't think we are planning to do live transcoding, we're going to be converting files at the point of upload and storing them on disk for simple playback. This will be configurable quality and format but default will likely be h264 in an mp4 container.

[bo0tzz]

Having the option to downscale 4k videos for playback in the clients would also be nice, not all my devices are entirely happy about playing 4k :D

[palitu]

I agree. I have a video that wont play in the web-ui, and also really doesn't need high res. I would be happy with live transcoding as an option, or a default setting for stored transcoded videos.

thanks :D

[akoyaxd]

It would also help to avoid #958

[EnochPrime]

Going on the assumption that there would not be live transcoding, it would be nice to have the following options:

1. Transcode to configured format on upload (current functionality)
2. Don't transcode, files that can't be played will display a note to download the file
3. Generate set of versions, but keep original as-is ("storage is cheap")
   • high resolution (same as 1)
   • low resolution (to save mobile data)
   • timeline version
   • etc.

[JosiahBull]

H264 is obviously great for wide device support for playback, but I'd personally support keeping the original version as @EnochPrime commented. I'd personally be miffed at losing my original quality backup.

Especially since H264 caps out at 2048x2048 8 bit iirc. Either storing the original as-is or converting to a format like H265 (to preserve 10 bit color, high resolution, and high framerates) would be ideal.

[EnochPrime]

I'd personally support keeping the original version

The original version is kept, I was mistaken on the process when I made that comment. The transcoded files are in addition to the original.

[bt90]

Isn't this just an additional preview file?

[printfuck]

I've added a bunch of already optimal webm files, which when transcoded (with default settings) grew to 10 times the size of the original file.

I think there should either be an option to:

• serve the original file, if it's smaller and on a customizable list of filetypes, that are allowed to be served to clients
• discard the transcoded files if they are bigger than the original, when uploading
• edit a list with filetypes, that shouldn't be transcoded

At least there should be an option to serve the original file by default. I feel like that's already there but I haven't found it yet.

[AngelaDMerkel]

I've added a bunch of already optimal webm files

I am in agreement with @printfuck in this respect. I have a bunch of 6K and 8K 12bit videos which are extremely highly compressed timelapses already optimised using ffmpeg. Converting to h264 does bad things to them and introduces pretty wild amounts of dithering.

We should make quality (CRF, output resolution, encoding speed, etc) and potentially all ffmpeg settings customisable by the admin of the server

At this point, you might as well add a codec option, or multi codec support. Everything I have supports h265 and does so with hardware acceleration. I'd much rather save the bandwidth with more modern compression than worry about support for a codec with wide adoption

[jrasm91]

I believe with the exception of hardware support everything in this issue has been implemented. Hardware support probably deserves its own issue anyways, so I'm going to go ahead and close this as completed. Happy to reopen if there are more pending enhancements though.

[jianglai]

Is there an issue to track hardware transcoding support?