pbourke's picture

Paul (@pbourke)


3 years ago
3 years ago
3 years ago
pbourke's picture

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.

pbourke's picture

OBJ material images not saved when exporting as app


Vuo version: 

OS version: 

  • macOS 10.14

How severely does this bug affect you?: 

●●○○ — It's annoying but I can work around it.

Steps causing the bug to occur: 

  1. Create a composition that loads an OBJ file with a MTL file that references image textures.
  2. Export to an app
  3. The textures are not copied into the resources, only the OBJ and MTL it references.

Have you found a workaround?: 

Yes, one can copy the image textures into the built application resources directory.

Other notes: 

The OBJ file is obviously being parsed to find the MTL. The same needs to occur for the MTL file.

pbourke's picture
Paul commented on Paul's Bug Report, “Movie format quality setting ignored.

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.


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


Note they will only hang around there for a week or so.

pbourke's picture
Paul commented on Paul's Bug Report, “Movie format quality setting ignored.

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.