search

Alkl58 / NotEnoughAV1Encodes

GUI for AV1 (aomenc, rav1e & svt-av1)
MIT License
543 stars 24 forks source link

Autocrop detect more pixels [BUG] #141

Closed dravenar closed 9 months ago

dravenar commented 1 year ago

Hi! I've tested the autocrop feature, but it's giving me 4 more pixels (2 up/2 down) than the correct crop. For instance, despite giving me 138/138, it returns 140/140 (up/down). I've measure a screenshot in an online Photoshop like, and the correct value is 138 (also in other software like Handbrake/Hybrid). The film is Scream (2022).

1 2

Thank you very much for your software!

Alkl58 commented 1 year ago

Hey, NEAV1E uses the crop detection of ffmpeg (cropdetect=24:16:0).

For that the most occuring detected value is selected: https://github.com/Alkl58/NotEnoughAV1Encodes/blob/bc4131cce8333a5e8ce8a07b3f2f246fe25d548b/NotEnoughAV1Encodes/MainWindow.xaml.cs#L1497

I am not sure how I could fix that.

dravenar commented 1 year ago

Hi, thank you very much for your response.

I have been looking on the internet for documentation on why the default values of ffmpeg in cropdetect are like this. But it seems that these values are based from past encode method, https://video.stackexchange.com/questions/15163/why-does-parameter-round-in-ffmpegs-cropdetect-default-to-16, when it seems that compressors used 16x16 blocks. Something that I do not think happens nowadays, in somple place, I've read that in the case of YUV 4:2:0, 2x2 blocks are used.

The problem with the round parameter is that if it has to be divisible by both width/height .

Set the value for which the width/height should be divisible by. The offset is automatically adjusted to center the video. Use 2 to get only even dimensions (needed for 4:2:2 video). 16 is best when encoding to most video codecs. Default value is 16. Then, those values are more accurate if they are divisible by 2 than by 16. So maybe, cropdetect=24:2:0 is better than cropdetect=24:16:0, as suggested in https://www.reddit.com/r/ffmpeg/comments/kkvwl4/ffmpegs_cropdetect_output_vs_handbrakes_output/ In any case, I think that something that detects black lines should be conservative. It's better to preserve some pixels with black bars than to remove some pixels with information
Alkl58 commented 9 months ago

Changed in the latest release.