Doom9's Forum - View Single Post - Repairing weird (NTSC -> PAL ?) blend

kriNon · 29th November 2017, 16:20

Hmm, sounds like you might be dealing with a similar issue to what I'm trying to fix currently. Although it's probably different to my source, what I have found is that if instead of using SelectOdd to get 25fps, I've been looking to find a better metric for measuring how much blending a frame has, and selecting odd/even based on which has less blending.

What I've been doing is comparing the edgemask of both frames, and choosing whichever frame has lower luma, however this method only has a ~70% success rate for my source. The logic behind this is that the blended frame should have more lines due to having the lines from the next/previous frame too. It tends to have issues with small differences between the frames, and only really works for frames with huge amounts of blending. Although what I did notice is that srestore(omode=3) works far better once I have decimated properly.

I'm struggling to think of logic that would work properly for constantly getting rid of the blended frame, because I'm having difficulty finding meaningful metrics that I can use that don't create too many false positives. I don't really want to be comparing frames to the previous/next two fields, because it is most likely that one if not more of those will be blended, which means I need to try to measure blending without knowing which frame it is blended with, making things a little more difficult. I've found that by using Srestore to decimate I get better results for the frames with very little blending, however my method has better results for the frames with a lot of blending. Another thing I've noticed is that I will get a mixture of good and bad frames, and the pattern is typically "GBGBBGBGBG" however whenever the scene changes it resets, and there is some variance, the pattern does not always hold true.

AnimeIVTC is giving you 20fps because it is decimating your clip, which probably doesn't require it, unless of course it was produced in 20fps, but that seems unlikely. Keep in mind that I haven't actually had a chance to have a look at your clip and that my advice is general, hopefully I've been able to help a bit though!

29th November 2017, 16:20	#2 \| Link
kriNon Registered User Join Date: Jul 2016 Posts: 39	Hmm, sounds like you might be dealing with a similar issue to what I'm trying to fix currently. Although it's probably different to my source, what I have found is that if instead of using SelectOdd to get 25fps, I've been looking to find a better metric for measuring how much blending a frame has, and selecting odd/even based on which has less blending. What I've been doing is comparing the edgemask of both frames, and choosing whichever frame has lower luma, however this method only has a ~70% success rate for my source. The logic behind this is that the blended frame should have more lines due to having the lines from the next/previous frame too. It tends to have issues with small differences between the frames, and only really works for frames with huge amounts of blending. Although what I did notice is that srestore(omode=3) works far better once I have decimated properly. I'm struggling to think of logic that would work properly for constantly getting rid of the blended frame, because I'm having difficulty finding meaningful metrics that I can use that don't create too many false positives. I don't really want to be comparing frames to the previous/next two fields, because it is most likely that one if not more of those will be blended, which means I need to try to measure blending without knowing which frame it is blended with, making things a little more difficult. I've found that by using Srestore to decimate I get better results for the frames with very little blending, however my method has better results for the frames with a lot of blending. Another thing I've noticed is that I will get a mixture of good and bad frames, and the pattern is typically "GBGBBGBGBG" however whenever the scene changes it resets, and there is some variance, the pattern does not always hold true. AnimeIVTC is giving you 20fps because it is decimating your clip, which probably doesn't require it, unless of course it was produced in 20fps, but that seems unlikely. Keep in mind that I haven't actually had a chance to have a look at your clip and that my advice is general, hopefully I've been able to help a bit though!