That's not likely a good idea unless your video collection is already very poorly encoded. In addition to the rant below, re-encoding from a regular video codec

That's not likely a good idea unless your video collection is already very poorly encoded. In addition to the rant below, re-encoding from a regular video codec to another regular video codec is guaranteed to result in some loss of quality (I say "regular" because there are codecs specifically intended for this use-case like ProRes or H264's SVC). I think there's a widely-held misconception that the codec is the defining characteristic for video compression performance, that the codec is like a step-by-step procedure that all the encoders and decoders implement, so the choice of codec is the most important choice and different codecs are better or worse than others. This mostly isn't the case. You can think of a codec as something more like HTML + CSS + JS: there are some standards that define what your program can write and how it should be interpreted by other programs that read it. For a particular end-goal, there are many ways you could go about it. For example given a mock from a designer for a static webpage, you could produce a working copy by writing it up with clean HTML and CSS, with dirty HTML and CSS or you could just make a HTML page with a single <img> element. All of these could produce the same result but they go about it in vastly different ways that perform very differently. The same is true of video codecs. Different encoders, given similar parameters and the same inputs, can produce vastly different results, with vastly different performance characteristics. This is especially true of encoders with odd constraints, like hardware encoders, which are usually forced to do things very differently due to not having the same amount working memory, being power-constrained (especially on phones and SBCs) or not having enough space on the physical silicon to implement certain approaches. You can see benchmarks for some modern HEVC and AV1 encoders from MSU [0]. To see how different things can get, have a look at the 4K chart [1] and switch the "Plot Type" to "Speed/Quality". You can see that on one end, the Bytedance V265 encoder gives a 20% bitrate saving relative to x264 while taking half the time. On the other hand, the x265 encoder only gives a 13% bitrate saving despite taking 28% longer than x264. This is despite both V265 and x265 encoding the same codec. As for hardware encoders, reliable benchmarks are usually sparse but in general, there are two classes: - The kind used in embedded devices (phones, cameras, SBCs etc.) - these are usually built as accelerators so that the device's low-power CPU doesn't have to perform the computationally-intensive (and therefore energy/thermal-intensive) task of encoding video. They're usually built to handle realtime video, maybe slow-motion video and in terms of compression, they're not great. - The kind used in less power-constrained environments (e.g. as part of a dedicated PCI-e video encoder card used in a video workstation, or the kind added to a GPU or CPU) - these are also built as accelerators but they're no longer anywhere near as constrained by thermal and energy considerations. They're usually not able to reach the same kind of compression as a software encoder due to some techniques just being entirely out of the question but they're able to process video very very fast. NVIDIA's NVENC encoder is the best that I've tested here. If you really want to re-encode your library, I'd recommend getting a modern NVIDIA graphics card (recency matters a lot more than power) and using that instead of the SBC. It should be a lot faster than the SBC and the compression will be a lot better. EDIT: Also, I forgot to address the "and different codecs are better or worse than others" comment near the start of the post. What I was getting at here was mostly the widely-held belief that AV1 is "slower" or more computationally-expensive than HEVC. This isn't the case but I believe originates from comparisons of the unoptimized reference encoder to more mature HEVC encoders. If you look at [1], you'll see that SVT-AV1 performs very well. It's not yet beating Bytedance V265 but it does handily beat just about everything else on speed/quality, including x264. But that kinda ignores the main takeaway: the main thing you need to compare and judge is the encoder, not the codec. AV1 isn't slow, libaom is slow. HEVC doesn't compress better than H264, HEVC adds more tools, so that V265 can compress better than x264. [0]: http://www.compression.ru/video/codec_comparison/hevc_2019/ http://www.compression.ru/video/codec_comparison/hevc_2019/ [1]: http://www.compression.ru/video/codec_comparison/hevc_2019/download/4k_report_free_version/Free_4K_Video_Codec_Comparison_Report_2019_by_MSU.html http://www.compression.ru/video/codec_comparison/hevc_2019/d...