Just added my votes for this.
Not necessarily for the method proposed but because I often find myself wondering what parts of a composition I should be exploring if I want to improve performance.
I think the performance metrics should be something enabled/disabled so as to not in themselves cause an overhead.
So, if the bitrate is X Mbps then the movie size should be (96*X/8)
If I choose 200Kbps then the movie should be at most 2.4MB. Confirmed. Granted it looks pretty bad.
If I choose 2Mbps then the movie should be at most 24MB (96*2/8). Confirmed.
If I choose 20Mbps then the movie should be at most 244MB (96*20/8). Confirmed.
If I choose 200Mbps then the movie should be at most 2.4GB (96*200/8). Confirmed.
1: Vuos formula of
MAX(0.01, quality) * pixelsWide * pixelsWide * framerate * fudge
is MBytes/sec not Mbits/sec! So out by a factor of 8.
I also suggest dropping the fudge factor, set to 1.0 unless there's a good reason.
2: One can choose an extremely wide range of bitrates, no problem and the file size should exactly reflect that.
4 orders of magnitude above from 0.2Mbps to 200Mbps, movie sizes from 2.4MB to 2.4GB.
File sizes match exactly proprotionately as expected.
3: The data rate of the frames uncompressed would be 1400Mbps
So 200Mbps has not saturated yet.
For tests in Vuo, one can try to recompress the 20M.mp4 or 200M.mp4 file into lower bit rates.
For example using ffmpeg
I note in an earlier reply that you say "...…where fudge is 0.75, based on our testing with a variety of image generators, and framerate is 60 (regardless of the actual framerate, since Vuo doesn't know in advance what the actual framerate will be).".
I suggest that is a problem. For all/any movie output nodes one needs to dictate the framerate.