Closed asheimo closed 4 years ago
@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.
@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.
@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.
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
@asheimo Thanks! I will try these out tomorrow.
@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.
@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.
@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:
@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.
@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!
@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.
@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?
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.
@asheimo OK, I'll close this now but I'm willing to revisit at a later date. Thanks again for the discussion!
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 usingtranscode-video
that I needed to pass--handbrake-option decomb=bob
to get smoother video output. So I triedbwdif=deint=interlaced[v]
in theother-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 eitheryadif
orbwdif
, 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"