lisamelton / other_video_transcoding

Other tools to transcode videos.
MIT License
549 stars 25 forks source link

Crop not working on 4K movies #52

Closed ESClaus closed 2 years ago

ESClaus commented 4 years ago

Hi all,

I have noticed that crop isn't working on 4K titles. I am one of the lucky people to have a bluray drive that "supports" 4K. Does anyone have an easy way to get crop marks? I am currently running Staxrip since it will do it but it creates extra files in the process.

lisamelton commented 4 years ago

@TheClaus Do you meant that automatic crop detection isn't working for 4K inputs or that applying a manual crop isn't working?

BTW, I don't recommend cropping since it doesn't really improve performance or quality.

ESClaus commented 4 years ago

@donmelton it is auto cropping that isn't working. Manual crop works great.

lisamelton commented 4 years ago

@TheClaus Thanks for the clarification. OK, this could be due to some limitation or defect in the cropdetect filter within ffmpeg. Or maybe it's just the particular 4K content you're feeding it. The cropdetect filter works by examining luminance information in the input video to detect boundaries. It's possible that HDR information, which is typically used in 4K, is somehow confusing it. I don't know.

And, unfortunately, I don't have much 4K content to explore this right now. So I'll have to rely on The HiveMind™ to see if they can figure it out. Stay tuned...

asheimo commented 4 years ago

@TheClaus Could you post a log from a problematic other-transcode. Could you also include the Staxrip results for comparison. I'm trying to recreate your issue for debugging. Thanks.

ESClaus commented 4 years ago

@asheimo here is the logs from Staxrip. I didn't go all the way through the process because I have had issues in the past with settings not working that should work also other-transcode is so much better and easier.

The first one is the log. The next 3 are the AVS files created when I told it to crop. Also here is the other-transcode log.

47.Ronin.2013.Remux-2160p.HEVC-FraMeSToR_new_staxrip.log 47.Ronin.2013.Remux-2160p.HEVC-FraMeSToR_new.txt 47.Ronin.2013.Remux-2160p.HEVC-FraMeSToR_new_crop.txt 47.Ronin.2013.Remux-2160p.HEVC-FraMeSToR_new_source.txt

47.Ronin.2013.Remux-2160p.HEVC-FraMeSToR.mkv.log

uaos commented 4 years ago

@TheClaus what is the full input command that you're running using other-transcode? And just to confirm, does the input file have any change in aspect ratio?

ESClaus commented 4 years ago

@uaos this is what my command is. I am running this in a powershell script. The $mediaPath is the input of my file.

"other-transcode"$mediaPath" --nvenc --hevc --nvenc-temporal-aq --crop auto --add-audio 1"

As for the input file not having any changes. This was pulled from mediainfo. Width : 3 840 pixels Height : 2 160 pixels

catdroid75 commented 4 years ago

@TheClaus I've noticed this as well with some files from trucks. MediaInfo gives a good idea on if the script will properly detect the crop. Some 4K releases' crops are (including some with HDR) properly detected, others aren't.

My workaround for this is, I've started keeping a doc with crop settings for common aspect ratios and batch my 4k encodes by AR.

lisamelton commented 3 years ago

I just checked and this is still an issue with the latest version of ffmpeg and the cropdectect filter. Technically it's not a bug in other-transcode and I realize that's not very helpful. But at the moment, there's not much I can do about that.

I'll leave this issue open for now but it's likely to be closed if we don't see some movement from the FFmpeg development team on the filter. Sorry about that.

martinpickett commented 2 years ago

There is a fix for this! In FFmpeg lingo, you explicitly set the limit for the cropdetect filter to 24 (which is the default), however 24 is only appropriate for 8-bit colour inputs. 4K is usually HDR which is 10-bit colour and so you need a different limit. Luckily FFmpeg allows you to use a percentage limit (between 0.0 and 1.0) meaning you can have the same limit for all inputs, 8-bit or 10-bit. To replicate the default limit of 24 you need to use 0.09411765, which is a bit nasty, but I have found 0.095 works fine.

I have tested this with the three 4K films I have and it has worked for each one. I also tested on a handful of FHD Blu-Ray's and the same crop values were calculated as with the currently released version of other-transcode.

If it helps, the change is needed on line 1470, from '-filter:v', 'cropdetect=24:2', to '-filter:v', 'cropdetect=0.095:2',

lisamelton commented 2 years ago

@martinpickett Thanks. Where did you find this information? Did the FFmpeg team document how to get HDR crop detection to work anywhere?

Also, I'm really reluctant to alter this default since it would mean running through multiple FHD Blu-ray and SD DVD collections to see if any crops had changed. I think a better solution would be a new option that allows a custom setting, e.g. --cropdetect-params.

martinpickett commented 2 years ago

I do not know if the information is new, but I found the basics in the current FFmpeg documentation here https://ffmpeg.org/ffmpeg-all.html#cropdetect. As soon as it mentioned the maximum was 255 "for 8-bit based formats", I took a guess at the problem. A couple of sentences later it tells you you can set the value between 0.0 and 1.0. I then did a bit of experimenting.

I understand your reluctance. I hope, but cannot prove, that 0.095 == 24 and so you do not have to do anything like --cropdetect-params. Perhaps an undocumented --alt-cropdetect option which would use 0.095 could be added and then over time we can asses if it works as it should do?

lisamelton commented 2 years ago

@martinpickett Ah, yes. I have read that portion of the documentation many times. :) My last experiments with my few 4K rips did not render any useful results. I think it's time for me to look at the actual source code again to see what it's really doing. I'll let you know what I find out.

But I also don't want to add any undocumented options. I would prefer to get the design correct rather than do something hasty.

lisamelton commented 2 years ago

My thanks to @martinpickett (with whom I had a looooong conversation elsewhere) for this fix! Which is now checked in. :)

lisamelton commented 2 years ago

I'm closing this now since a fix for this is already checked in and a release is imminent.