Impossible to get a smooth deinterlaced PAL movie... BUT!

[Unicorn]

Hello everyone,

Recently I started to encode my huge collection of DVDs thanks to handbrake, and it's working very great so far.
But I have some troubles to get smooth deinterlaced movies and/or animes that are originally in PAL (it might work perfectly with the NTSC ones, I don't know).

I tried many different settings, like:
- Encoding at variable frames per seconds: 23.976, 24, 25 & 29.97.
- Trying "Decomb".
- Trying to deinterlace in "Fast", "Slow" & "Slower".
- Trying "Detelecine".
^ I also almost tried all the combinations above; it took a lot of time but I never found the perfect setting able to output a smooth movie/anime.

All the sequences looked choppy (sometimes it was subtle, but still visible during scrollings in animes, especially if their speed is faster than X).
I watched them frame by frame with Quicktime, and didn't noticed doubled frames; in most cases, I got 3-4 frames each seconds that seemed to use alpha between each other. Funnily, I was trying to encode FuliCuli, and that's what is shown as example in your wiki
So yes, visually the scrolling gives the weird impression to get stuck (or get slow, or even get backwards) quickly each second.

Anyway, there's a "BUT" in my subject! I just wanted to let you know that I found a solution, not using Handbrake but maybe you can implement it...?
Here's how I did, and I think it looked perfect:

1) I encoded the video WITHOUT deinterlacing.
2) Then I opened it in Quicktime, and enabled the "deinterlace" feature < This one DIDN'T work. I didn't see any difference.
3) Then I opened it in VLC, and noticed that there are many deinterlace options. NONE of them worked, EXCEPT the one called "moyenne" (I'm using the french version of VLC, in english it's probably "medium"). Anyway, using the "moyenne" deinterlace option, the result was great & smooth.

So, do you think it's possible for Hanbrake to add that VLC's "moyenne" deinterlace feature?
Or, even better, is there a perfect setting to get a smooth deinterlaced movie/anime from a PAL interlaced DVD? Maybe I simply missed something.

Thanks for your time!

[Deleted User 11865]

- Encoding at variable frames per seconds: 23.976, 24, 25 & 29.97.

How about "Same as source"?

[Unicorn]

I should have mentioned this one, but yes that's the 1st framerate option I tried
...And I thought that maybe HB was confused, that's why I also tried to manually select 25fps ( = PAL framerate).

Thanks for your answer though!

[tlindgren]

But I have some troubles to get smooth deinterlaced movies and/or animes that are originally in PAL (it might work perfectly with the NTSC ones, I don't know).

Normally interlaced PAL movies are done in 2:2 pulldown http://en.wikipedia.org/wiki/Telecine#2:2_pulldown, with a 4% speedup (video and audio).
This should be trivial to decomb (or deinterlace) using any of the settings you've tried already though the speedup will still be there (for mkv it can be fixed afterwards using mkvtoolnix).

But apparently some is now done in 2:2:2:2:2:2:2:2:2:2:2:3 (same page) which is less supported because it's not been common enough, it also requires much longer sequence to detect. Some video player (and Nvidia/ATI's accelerate video decoders) handles it and it should be easy to do correctly via AviSynth/Decomb filter. There's also some other uncommon cadences that it could be if the original framerate wasn't 23.976/24 fps (some old Anime).

All the sequences looked choppy (sometimes it was subtle, but still visible during scrollings in animes, especially if their speed is faster than X).
I watched them frame by frame with Quicktime, and didn't noticed doubled frames; in most cases, I got 3-4 frames each seconds that seemed to use alpha between each other.

I've not actually looked at 2:2:2:2:2:2:2:2:2:2:2:3 pull-down video but it does sound like what it would generate.

Are you using 0.9.3 or the latest snapshot? IIRC later version does have significant improvements in the Decomb filter (not sure about Detelecine) so it's worth trying that. I'd try Decomb/Default, FPS: 23.976 (and then try 24 fps), then the same but with Detelecine/Default 23.976/24 fps but I'm by no means sure it will handle this scenario.

3) Then I opened it in VLC, and noticed that there are many deinterlace options. NONE of them worked, EXCEPT the one called "moyenne" (I'm using the french version of VLC, in english it's probably "medium"). Anyway, using the "moyenne" deinterlace option, the result was great & smooth.

I suspect this must be "Mean", not medium (Google Translate offers "average" as the second option so it makes sense). http://wiki.videolan.org/Deinterlacing#Mean
If it's 2:2:2:2:2:2:2:2:2:2:2:3 pull-down doing Mean (Blend) should greatly reduce or remove the "telecine judder" just as you observed but doing this also drops a lot of (vertical) information leading to a blurry picture (adaptive deinterlacing avoids that but would probably reintroduce the judder since it doesn't know about the field shift every 0.5 seconds).

With a sample a few seconds long (no decomb/detelecine/deinterlace) of one of the scrolling sections of the movie it would probably be easy to confirm if this really is 2:2:2:2:2:2:2:2:2:2:2:3 pull-down video and write an Avisynth script that does the pull-down correctly.

If this is now common on PAL movies it would probably be good if HandBrake's detelecine filter handled it, the description of the MPlayer pullup filter on which it's supposedly based only talk about conventional NTSC pull-downs but it's possible that the code of one or the other had improved (or the documentation only covered the most common alternative). I can't help you there, but at least you're in the right board

[jbrjake]

@Unicorn: I need a short (<30 seconds) sample of the source, from a segment that demonstrates this problem.

@tlindgren:
First off, I don't know why you're telling people to change the framerate away from same as source. This is terrible advice.

If this is now common on PAL movies it would probably be good if HandBrake's detelecine filter handled it, the description of the MPlayer pullup filter on which it's supposedly based only talk about conventional NTSC pull-downs but it's possible that the code of one or the other had improved (or the documentation only covered the most common alternative).

Pullup already supports it. It's always supported it.