Use of vmaf & compressibility check

[dim-geo]

Hello,

Have you considered using VMAF and/or compressibility check in your framework?

The workflow that I have in mind is this one:

1. Choose a vmaf quality that is acceptable for you. 80%? 60%?

2. encode a small part of the original video (5% of the video in 30 seconds clips, spread equally to all video) in crf x

3. calculate vmaf of that clip, if the vmaf is high, then increase crf in order to decrease bitrate and go to step 1. If the vmaf is low, then decrease crf in order to increase bitrate and go to step 1. If the vmaf quality is ok, then you have your crf value for that video that wastes no bitrate.

4. Encode the whole video and inspect or vmaf it.

[lisamelton]

@dim-geo Sorry I took so long to reply. I've been traveling today.

Besides the fact that including a C library-based VMAF implementation in a Ruby-only Gem would not be practical, I don't have a lot of confidence in assessing video quality via some kind of objective algorithm. Especially for my target audience which are home transcoders.

Using VMAF, peak signal-to-noise ratios or a structural similarity indexes just take too much computation time and resources compared to judicious manual visual inspection.

I discuss this at length in the FAQ here:

https://github.com/donmelton/video_transcoding#how-do-you-assess-video-transcoding-quality

Of course, that doesn't mean I would prevent users from leveraging VMAF or other algorithms after transcoding. I just don't want to build those systems into my lightweight tools.

Does that make sense?

[dim-geo]

VMAF is a different kind of beast compared to PSNR and other 'objective' measurements.
VMAF is a perceptual video quality assessment algorithm.
The fact that is used & backed up by netflix, gives it more credit.
My main objection with it, is that it takes time to compute but it takes probably less personal time compared to rewatching a movie.

Another totally unrelated question and a suggestion:

1)How do you encode/handle grainy sources?

2)It would be beneficial I think to document all arguments/options of the tool in github page. Apologies if I din't find the page containing them.

[lisamelton]

@dim-geo As far as grainy sources go, I don't use any special filters or other handling for those. Typically you want to retain the grain so I rely on the encoder's default behavior.

Thanks for the suggestion about documentation. The problem though is that the README file is already too long. I think the right way to handle that is via a Wiki, and I do plan to create one in the future.