Using the “Save images to movie” node, the image quality setting for H.264 doesn’t seem to make any difference. I would expect a different size movie for quality of 0.5 vs 1.0.
movietest.vuo (1.89 KB)
Same situation for H.265.
It seems to be working as expected in our testing, but let me know if you see something different.
For both H.264 and H.265, between quality 0 and 1 there’s a clear size difference. Between 0.5 and 1, there’s not necessarily much difference.
Vuo translates the quality slider into a bitrate value it passes to AV Foundation. If the movie can be fully encoded using a certain bitrate, then increasing the slider beyond that shouldn’t increase the quality or size.
Hmmm, well you are stricktly correct, the attached shows the case for encoding quality of 0.1 and 1.0. (before I was using higher values and didn’t see a difference.
A few comments
(changed status)
The original movie is H264 from QuickTime Pro, so it has expanded quite a bit going through the Vuo save process. Is this possibly because each frame is a keyframe?
We are not explicitly telling AV Foundation when to create keyframes; in the tests we performed, AV Foundation automatically created 1 keyframe for every 14 interframes. We suspect the size difference is because Vuo’s lowest compression quality setting is higher than the bitrate of your input movie.
At this point, we’re not seeing criteria for marking this as a bug.
I still maintain there is something wrong with the quality slider.
If I vary the quality range from 0.1 to 1, I would expect a “decent” difference in output movie size.
Vuo converts the normalized quality value into a bitrate (bits per second) using this expression:
MAX(0.01, quality) * pixelsWide * pixelsWide * framerate * fudge
…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). For example:
0.01 * 1024 * 768 * 60 * 0.75 = 346 Kbps
0.50 * 1024 * 768 * 60 * 0.75 = 17,280 Kbps
1.00 * 1024 * 768 * 60 * 0.75 = 34,560 Kbps
Those are the values Vuo tells AV Foundation. We tested exporting some movies, then viewed the average bitrate as reported by QuickTime Player:
Generate Checkerboard Image, H.264 quality 0.0 = 125 Kbps
Generate Checkerboard Image, H.264 quality 1.0 = 125 Kbps
Spin Kaleidoscope, H.264 quality 0.0 = 427 Kbps
Spin Kaleidoscope, H.264 quality 0.5 = 18,640 Kbps
Spin Kaleidoscope, H.264 quality 1.0 = 34,030 Kbps
Since the visual content of Generate Checkerboard Image is simple, it compresses easily, and AV Foundation reasonably decides not to waste bandwidth storing data that wouldn’t make any difference to the visual quality.
The visual content of Spin Kaleidoscope is more complex, so AV Foundation ends up using all of the available bandwidth, and the actual bitrate values end up pretty closely matching the bitrate Vuo requests.
We’re not sure how to improve the normalized-quality-to-bitrate conversion, since Vuo doesn’t know in advance how complex the image data is going to be. Any ideas on a better way to handle this?
Hmmm, that doesn’t explain what I was seeing which was almost no movie size difference (should be proprotional to bit rate) over a wide range of quality values. Can I suggest trying a “real” movie rather than CG style imagery, extract frames from a filmed video and reencode those.
I’m a bit busy but if you would like me to put a test together let me know.
Hi Paul,
I think that the data of ‘real movies’ is much less compressible without generating artifacts, therefor interframe codecs like h.264 don’t try to do too much.
In a movie every pixel is likely to change, interframe compression relies on pixels not changing, therefor less compression is possible equalling little change to data rate.
Just my laymans understanding.
I suggest trying the test with pjpeg codec or something of that ilk and would hope you’ll see more of the results you’re expecting.
Not so. h264 and any of the mpeg style variations do exactly that, degrade the content to meet the data rate. If I take a movie and compress it normally in h264 using the normally provided slider for quality or data rate, then I get a file size proprortional to the datarate and (of course) the movie quality suffers. That is just how it is supposed to work.
pjpeg is a little different because (I believe) it is largely within frame compression and no interframe compression. But even then I can dial up different data rates (or quality) and I get a good range of final movie sizes.
Please note, as per your comments, high variablity between frames does not affect the ability for temporal compression, at least not with the mpeg style compression. It can do it in time just as well as in space.
I’ll try to come up with a good example … time permitting.
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.
I chose some frames to encode using ffmpeg.
There are 2880 frames, if a movie is created at 30fps then the movie is 96 seconds long.
I encode using ffmpeg with something like
ffmpeg -r 30 -i frames/%04d.jpg -c:v libx264 -b:v 2M -maxrate 2M 2M.mp4
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.
Notes
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
(28801920108038/1024/1024/96)
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
ffmpeg -r 30 -i 200M.mp4 -c:v libx264 -b:v 20M -maxrate 20M 20M_from_200M.mp4
And as expected the resulting movie is 244MB.
Similarly for 2Mbps the movie is 24MB.
Hope this proves useful.
If you want to test with the movies I use please download from here
http://paulbourke.net/transient/VuoMovie/
Note they will only hang around there for a week or so.
Thanks for your investigation! We’ve downloaded your videos and we’ll analyze them and see what improvements we can make.
@pbourke, we’ve done some additional testing using your 200M.mp4 movie — comparing our results with Vuo 2.1.2 (AVFoundation) to your results with FFmpeg.
For this particular video content, Vuo’s quality slider (0 to 1) produces a different output movie size for each value on the slider. At about quality 1.5, we reach AVFoundation’s limit: it decides not to spend more than an average of 135 Mbit/sec on this particular video content. FFmpeg is apparently willing to go higher than that. However, our human eyes weren’t able to discern a difference between the movie saved by Vuo (135 Mbit/sec) and the original (200Mbit/sec).
I still maintain there is something wrong with the quality slider. If I vary the quality range from 0.1 to 1, I would expect a “decent” difference in output movie size.
We still haven’t been able to reproduce this problem. For your 200M.mp4, when the quality slider ranges from 0 to 1, the bitrate that Vuo requests from AVFoundation ranges from 0.9 to 89 Mbit/sec, and the actual bitrate of the output movie ranges from 0.9 to 94 Mbit/sec.
Since this is the original subject of the bug report, we’re changing the status to “not a bug”. Not saying that the movie encoding overall couldn’t be improved, but we’re not seeing a need to modify this specific aspect.
For all/any movie output nodes one needs to dictate the framerate.
Although that’s not universally true (QuickTime movies are designed around allowing the framerate to vary over time), a fixed framerate is very often desirable. With your feature request for adding a framerate input port, it would be possible to refine the bitrate calculation.
Vuos formula of MAX(0.01, quality) * pixelsWide * pixelsHigh * framerate * fudge is MBytes/sec not Mbits/sec! So out by a factor of 8.
It’s actually in bits per second. Since the role of the fudge factor is to estimate the compressed size based on the uncompressed size, its unit would be bits per square pixel. The resulting value is passed to AVFoundation, which expects a number in bits per second.