Deinterlace options

[asheimo]

I have been experimenting with other-transcode and finding I'm getting interlacing artifacts. So I was digging into the command line being passed. Yadif is being used for the protocol but I found in the past while using transcode-video that I needed to pass --handbrake-option decomb=bob to get smoother video output. So I tried bwdif=deint=interlaced[v] in the other-transcode command line and got the smoother result I was expecting. So I would like to request the ability to choose which version to use either yadif or bwdif, there are other options that can be used but I don't how much the application should or should not be expanded.

original command: ffmpeg -loglevel error -stats -ss 0 -t 1570.302 -i "k:\Video\EARL_FAIRY\Earl and Fairy s01e01.mkv" -filter_complex [0:0][0:2]overlay,yadif=deint=interlaced[v] -map [v] -c:v h264_nvenc -b:v 2000k -maxrate:v 6000k -rc:v vbr_hq -spatial-aq:v 1 -temporal-aq:v 1 -profile:v high -color_primaries:v smpte170m -color_trc:v bt709 -colorspace:v smpte170m -metadata:s:v title= -disposition:v default -map 0:1 -c:a:0 copy -metadata:s:a:0 title= -disposition:a:0 default -sn -metadata:g title= "Earl and Fairy s01e01.mkv"

my experiment: ffmpeg -loglevel error -stats -ss 0 -t 1570.302 -i "k:\Video\EARL_FAIRY\Earl and Fairy s01e01.mkv" -filter_complex [0:0][0:2]overlay,bwdif=deint=interlaced[v] -map [v] -c:v h264_nvenc -b:v 2000k -maxrate:v 6000k -rc:v vbr_hq -spatial-aq:v 1 -temporal-aq:v 1 -profile:v high -color_primaries:v smpte170m -color_trc:v bt709 -colorspace:v smpte170m -metadata:s:v title= -disposition:v default -map 0:1 -c:a:0 copy -metadata:s:a:0 title= -disposition:a:0 default -sn -metadata:g title= "Earl and Fairy s01e01.mkv"

[lisamelton]

@asheimo Sorry I took so long to comment. I saw the notification right before bed last night and had to think about this for awhile.

Implementing your request would require a new option because I don't want to break the existing --deinterlace API by adding an argument. But a new option might not future-proof this issue or even be appropriate.

I deliberately selected yadif as the default software-based deinterlacing filter for other-transcode because it behaves like the hardware-based filters of the same type, particularly the filter applied by Nvidia when the --cuvid option is used.

And in the future, hardware-accelerated deinterlacing could become the default behavior. I certainly hope it does, actually, since inserting a software pipeline between a hardware decoder and a software encoder really slows things down.

Have you tried the --cuvid option yet to see how that looks? It should work for you since you're also using the Nvidia encoder.

[asheimo]

@donmelton please don't apologize for having a well thought out answer.

so I did try the --cuvid option and find that on some files I get the same result as the yadif deinterlacing (jerky video when the scene pans) and on others I get the same result as the bwdif deinterlace (smooth movement when the scene pans).

Now let's take my hardware into account and see if that is part of the problem. I am using a GTX 950 currently, so an older model. As such the --cuvid option is actually slower than either yadif or bwdif. I do not know if just having a newer model such as a GTX 1660 would improve the actual deinterlacing but I would think that it would increase the speed.

[lisamelton]

@asheimo Thank you, sir. And thank you for trying the --cuvid option so quickly!

Yes, you will likely get better performance on a newer model Nvidia card. However, that can vary in rather unexpected ways.

I need to try encoding my few interlaced samples with both yadif and bwdif to see if I can perceive a difference. Especially during horizontal panning.

That said, I could see adding an option like this:

    --prefer-bwdif  prefer "bwdif" instead of "yadif" as deinterlace filter

...which would only be described in the --help full output.

This option would only affect output that was either automatically filtered or explicitly filtered when using the --deinterlace option.

But I'm not committing to releasing this yet. :) First, I'll see what using bwdif looks like to me.

Also, have you tried using the --detelecine option on these problem videos? I designed that filter (which is actually much different from the one in HandBrake by the same name) to solve a similar issue.

[asheimo]

Here is the clearest example that I can easily provide. If you need more I can try and gather them. I only have 0.5Mbps upload to I am trying to keep the samples small. Samples.zip

[lisamelton]

@asheimo Thanks! I will try these out tomorrow.

[lisamelton]

@asheimo OK, I've looked at all your samples and created several of my own. Thanks again for uploading these!

Both of your bwdif and --cuvid samples look much better in terms of horizontal panning than your yadif sample. However, your bwdif sample is the only one that strangely retains the original 29.97 frame rate. Both of your --cuvid and yadif samples have been properly converted to a 23.976 frame rate.

However, the version I transcoded from your original using the --detelecine option looks better than either of your bwdif and --cuvid samples. My version is just as smooth in terms of horizontal panning. More importantly, it has fewer "leftover" deinterlacing artifacts. And it's also been properly converted to a 23.976 frame rate.

Please try using the --detelecine option yourself and let me know what you think.

[asheimo]

@donmelton I've tried --detelecine option and agree it does look the best of all the samples. I was looking at the command for that and am unable to understand part of it;

fieldmatch=order=tff:combmatch=none,decimate

Why set the combmatch to none? I made a test with combmatch set to full and seems to improve the panning slightly more. Not enough to ask for a change but would like to understand the rationale. Also where does decimate come from? I looked through the ffmpeg help and don't see that as part of the fieldmatch options.

[lisamelton]

@asheimo I'm glad that using --detelecine looks better to you as well! I'm guessing you don't need bwdif anymore?

While setting combmatch to full might look slightly better in this particular sample, it does not look good in other videos that I've tried. I suspect the comb detection algorithm is not entirely reliable. It's also not necessary.

The , before decimate indicates that the result from the fieldmatch filter is piped to the separate decimate filter. And decimate is what actually drops the unnecessary frames.

This whole filter pipeline that I'm using is actually described in the FFmpeg documentation as a simple inverse telecine mechanism here:

https://ffmpeg.org/ffmpeg-all.html#toc-Examples-102

[asheimo]

@donmelton correct this will remove my request to add bwdif but would you consider adding --detelecineadv where the result is using the Advanced IVTC, with fallback on yadif for still combed frames method. I was able to see some improvement by using that variation and think it could be handy to have, not knowing if it would be difficult to implement or not

BTW, thanks very much for the link, I was using the documentation from the command which doesn't have the detail you pointed me too. I'm trying to educate myself so that I am not asking for things that are too out of line.

[lisamelton]

@asheimo I will consider an advanced option. But I'll need to do some testing first to see whether the improvement is enough to merit the extra complexity and additional API.

Thank you again for testing this and providing that example!

[asheimo]

@donmelton as an alternative would it be possible to allow passing ffmpeg specific commands? This is something that existed in Transcode-Video with the --handbrake-option. Just thinking out loud.

[lisamelton]

@asheimo OK, I tried the fieldmatch=order=tff:combmatch=full,yadif=deint=interlaced,decimate formula on some of my own files and I'm not convinced that looks any better than the current formula for the --detelecine option. And in one case, I think it made some artifacts more noticeable. Using it was also almost 100 FPS slower, too.

So I don't think adding an "advanced" option is all that useful. Thoughts?

[asheimo]

Ultimately you have a whole lot more experience with this process than I do currently. So I will trust your judgement that overall it does not add substantial value to the application. It would be a more niche case as the times I have seen any benefit is with anime.

[lisamelton]

@asheimo OK, I'll close this now but I'm willing to revisit at a later date. Thanks again for the discussion!