whipstein
commented
7 months ago I've found a way to make this work. By adding a 1 second delay prior to bar.finish() in this same file. This does seem like a bit of a crude way to make it work, but I'm not sure how else to get it to wait for the file to complete being written. I will submit a pull request with this update. If you think it's worthwhile, you can accept it or if you don't, reject it.
This solution solves #168. It just requires that the user supply the requisite log file output switches, as mentioned above.
When adding the option '--vmaf log_fmt=json --vmaf log_path=vmaf.json', the output file does not get written. This appears to be caused by the method used for monitoring the progress with tokio_process_stream. I haven't been able to figure out how to get this to work while being able to monitor the progress via the progress bar. In order to implement a clumsy fix, you can place a simple sleep ahead of line 83 in src/command/vmaf.rs that is longer than the total time for the calculation. This results in the output file being written as expected.
I've been modifying my own fork recently to add an SSIM calculation option. When running it, I get an output file whether running directly through ffmpeg CLI or via ab-av1. This appears to work because SSIM writes to the file as each frame is processed. With libvmaf, they output the file after all of the calculations have finished. I tried placing a sleep after the calculations finished, but that doesn't work. I'm probably not understanding how tokio is working on the process. Seems like it gets killed before it can write the file. Maybe there is a simple way to keep the process alive long enough to get the output file?
I wanted to add some of the capability of looking at more than just the mean VMAF as well as other metrics. This capability is necessary in order to get those calculations. I wanted to include some of these metrics in the crf-search to help fine tune it for more precise quality metric searches.