Note that the problem here is that the source file is at *MUCH* too low a bitrate and is thus full of encoding artifacts. The transcode then spends a normal amount of bits replicating all the encoding artifacts as closely as possible.

The fact is we'll *always* transcode, because we're deliberately producing a consistent format (which by the way will be changing soon to better support native iOS playback using VP9 in an HTTP Live Streaming structure). Knowing the format, size, frame rate, keyframe intervals, and cues-data structure are within sensible limits helps with ensuring playback is consistent and functional.

What we could do, perhaps, is detect when an input file is *ridiculously low bitrate* and maybe constrain our output bitrate so we produce similar artifacts at a lower bitrate instead of nearly identical artifacts at the normal bitrate. But this feels pretty low priority to me, and it might not get gotten to.

(More generally, the version of TMH you're running might still have the old dreadful encoding params for VP9 which bias it towards using a high bitrate on complex input -- which is what "noisy" encoding artifacts look like!)