Status: 

Vuo version: 

OS version: 

  • macOS 10.13

How severely does this bug affect you?: 

●●●○ — It prevents me from completing a specific task with Vuo.

Steps causing the bug to occur: 

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.

Compositions: 

AttachmentSize
Binary Data movietest.vuo1.89 KB

Comments

It seems to be working as

jstrecker's picture
Submitted by
Status:
Waiting for review by Vuo Support Team
»
Not a bug

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

pbourke's picture
Submitted by

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 1. 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? 2. The movie size difference between a quality of 0.1 and 1.0 is "small".

The original movie is H264

jmcc's picture
Submitted by
Status:
Waiting for review by Vuo Support Team
»
Waiting for more information from reporter

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.

Paul,

jmcc's picture
Submitted by

Paul,

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

pbourke's picture
Submitted by

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,

Scratchpole's picture
Submitted by

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

pbourke's picture
Submitted by

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

pbourke's picture
Submitted by

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

pbourke's picture
Submitted by

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.

Moderator note: 

Removed broken link