HandBrake equivalent to AviSynth FieldDeinterlace()

General questions or discussion about HandBrake, Video and/or audio transcoding, trends etc.
Post Reply
ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

HandBrake equivalent to AviSynth FieldDeinterlace()

Post by ExDeus » Thu Mar 05, 2009 12:49 am

I've tried HandBrake's decomb option with the default settings in the Windows GUI on 1080i pure NTSC video and was disappointed with the results. The frames look good individually, but lots of choppy, jerky motion during playback.

A while back, I experimented with a number of deinterlacing techniques in AviSynth. The method I preferred for this material was AssumeTFF().FieldDeinterlace().

Is there a HandBrake equivalent to AssumeTFF().FieldDeinterlace()? Is there something that should work better?

jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by jbrjake » Thu Mar 05, 2009 5:25 pm

So basically you want a bobber? Interpolate each field to a full frame and run at twice the FPS?

I'll add an eedi2-based one eventually.

ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by ExDeus » Fri Mar 06, 2009 8:16 am

I guess I don't know. Is that really all it does? It has combing thresholds and blending - how are those needed for bob?
Donald A. Graft wrote: Decomb Plugin for Avisynth 2.5 (Version 5.2.3) Reference Manual

FieldDeinterlace(): This filter provides functionality similar to the postprocessing function of Telecide. You can use it for pure interlaced streams (that is, those not containing telecined progressive frames). (The name refers to the fact that field mode differencing is used.) Do not use FieldDeinterlace after Telecide because the same functionality is built into Telecide.

FieldDeinterlace provides an option that allows you to specify whether all frames are to be deinterlaced or whether just frames detected to be combed are deinterlaced.

* * *

FieldDeinterlace(parameter_list)

full (true/false, default true) chooses whether to process all frames or just the frames that are detected as combed. Use full=true to process all frames.

threshold (0-255, default 20) sets the combed frame detection threshold. When running with full=false, you may want to increase this value if too many good frames are being deinterlaced, or reduce it if small combed areas are not getting caught. The default is a good general purpose value. Note that this threshold determines whether a frame is considered combed and needs to be deinterlaced; it is not the threshold you might be familiar with in Smart Deinterlacer. That threshold is determined by dthreshold (below); it is the threshold for deinterlacing the frames detected as combed. When full=true, threshold is ignored, but dthreshold remains functional.

dthreshold (0-255, default 7) sets the threshold for deinterlacing frames detected as combed. Note that this threshold is the threshold you might be familiar with in Smart Deinterlacer.

blend (true/false, default true) enables blending instead of interpolating in combed areas.

map (true/false, default false) enables display of the combing detection map (motion map). If full=true, the map is shown for all frames. If full=false, the map is shown only for frames detected as combed; non-combed frames are displayed normally. The map shows combed areas as bright cyan; non-combed areas are copied from the source frame and blended with gray.

chroma (true/false, default false) determines whether chroma combing is included in the decision made during postprocessing as to whether a frame is combed or not. If chroma=true, then chroma combing is included, otherwise it is not included. Note that chroma is always deinterlaced; this parameter affects only the decision about whether a frame is combed. It is useful for clips which have a large amount of luma/chroma interference, as might result from a poor comb filter. The interference can cause frames that are not combed to be detected as combed when chroma=true. By setting chroma=false, the effect of the interference can be eliminated. This option has no effect when full=true because all frames are considered combed.

ovr (string, default "") enables specification of an overrides file (see the section above called "Overriding Decomb Decisions"). The file must be in the same directory as the script file (the Avisynth current directory) and the filename must be enclosed in quotation marks, e.g., ovr="tango.fd".

show (true/false, default false) enables metrics to be displayed on the frame to assist with tweaking of thresholds. Also displays the software version.

debug is the same as described for Telecide.

jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by jbrjake » Fri Mar 06, 2009 5:05 pm

ExDeus wrote:I guess I don't know. Is that really all it does? It has combing thresholds and blending - how are those needed for bob?
Huh? You said you were using :
AssumeTFF().FieldDeinterlace()

The very docs you're quoting at me say that using the line you've provided would *not* do combing detection because the default value for the full parameter is true and you're not specifying otherwise.

Beyond the very limited comb detection in neuron2's old filter (berrinam's for MeGUI is more sophisticated and a little closer to HandBrake's), it's just a very basic adaptive deinterlacer that can at times switch to blend mode. And for the blend mode it doesn't even use as many taps as HB's lowpass5 blender. I don't see how this is could be better than yadif, let alone eedi2.

I assumed you were encoding both fields because of your complaint about jerkiness. If you're not bobbing, just reducing temporal resolution, then I'm going to have to assume the jerkiness is from failing to detelecine before decombing.

ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by ExDeus » Sat Mar 07, 2009 6:57 am

jbrjake wrote:The very docs you're quoting at me say that using the line you've provided would *not* do combing detection because the default value for the full parameter is true and you're not specifying otherwise.
It's not doing combing detection - all frames are processed because full defaults to "true" - but each frame is still processed using the dthreshold param to determine whether decombing is actually applied.

To be clear, I'm asking here - not telling. I defer to you. I just thought selective decombing based on a threshold and blending/interpolating were not the techniques of a bobber. In addition, I'm not seeing the framerate doubled when using it.
jbrjake wrote:I assumed you were encoding both fields because of your complaint about jerkiness. If you're not bobbing, just reducing temporal resolution, then I'm going to have to assume the jerkiness is from failing to detelecine before decombing.
I'm doing some test encodes to compare HandBrake default decomb settings (1:2:6:9:80:16:16) vs. WinGUI default decomb settings (4:10:15:9:10:35:9) vs. FieldDeinterlace(). Why HB default vs. WinGUI default are different, I don't understand.

In looking at some of the content I originally saw issues with, it's possible there's mixed film/video content. One clip was a news story from "60 minutes", where live video is mixed in with some still photo zooming/panning, which is definitely produced by software, and could easily mess up the field order, just like CGI can.

In another instance, I was encoding "Late Night with Conan O'Brien" and "The Tonight Show", both of which have always been pure video in my experience. So with those, I wouldn't expect a sudden need to detelecine live music from the shows.

User avatar
s55
HandBrake Team
Posts: 9462
Joined: Sun Dec 24, 2006 1:05 pm

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by s55 » Sat Mar 07, 2009 8:23 pm

I'm doing some test encodes to compare HandBrake default decomb settings (1:2:6:9:80:16:16) vs. WinGUI default decomb settings (4:10:15:9:10:35:9) vs. FieldDeinterlace(). Why HB default vs. WinGUI default are different, I don't understand.
Simply because I have not updated it. Things change, I don't always update everything right away. The option wasn't even supposed to be in the gui. I've now removed it completely as it's no longer used. (custom setting can be set on the filters panel)

ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by ExDeus » Sun Mar 08, 2009 3:55 am

^ Thanks.

Since I shouldn't worry about the old settings in the WinGUI, if I'm still having trouble with jerky/stuttering movement with the default decomb settings in the CLI, I should be trying IVTC on the material, as jbrjake suggested.

What is that going to do to mostly (almost pure) video content?

jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by jbrjake » Sun Mar 08, 2009 7:09 pm

It's not doing combing detection - all frames are processed because full defaults to "true" - but each frame is still processed using the dthreshold param to determine whether decombing is actually applied.
Two posts ago you asked about combing threshold. Now you're talking about dtresh, which is the deinterlacing threshold, *not* the combing threshold. They have totally different sensitivities and are used for different purposes. Combing threshold is much less sensitive. Deinterlacing is much more sensitive. Everything dthresh masks is not combing, but rather pixels different enough from their vertically adjacent pixels that it's considered better to play it safe and deinterlace them anyway, even though they might not actually be combed, simply because it thinks or is forced to think that the frame overall shows combing.
I just thought selective decombing based on a threshold and blending/interpolating were not the techniques of a bobber.
And they're not, which is why in my last reply I explained that:

"I assumed you were encoding both fields because of your complaint about jerkiness. If you're not bobbing, just reducing temporal resolution, then I'm going to have to assume the jerkiness is from failing to detelecine before decombing."

Looking more closely at FDeint now, it seems like you're doing neither...you're just blending both moments in time together.
I should be trying IVTC on the material, as jbrjake suggested.

What is that going to do to mostly (almost pure) video content?
I am working under the assumption that your content is not purely video, because decomb does not produce jerkiness any more than any other deinterlacer that halves temporal resolution, and less than some since it's temporally adaptive. The only time you might see jerkiness is if you've got telecined frames and you're only deinterlacing them and leaving the now-progressive duplicate frames behind.

Skimming through the FieldDeinterlace source, it seems to work like this:

* If doing comb detection, run a simple combing detection algorithm over the frame. Consider a pixel combed if it's > thresh (20) different in intensity from the ones above/below.

* Run a more sensitive pass to generate a deinterlacing mask: consider a pixel a candidate to be deinterlaced if > dthresh (7) different in intensity from its vertical neighbors.

* If blending (default) run a simple blend on all pixels hit by the deinterlacing mask.

* If deinterlacing average the pixels above below for all pixels hit by the deinterlacing mask.

HandBrake's combing detector is newer than FieldDeinterlace's. It takes from tritical's AviSynth work the notions of tapping more pixels from each field and blurring them together (bob+blur) before looking for combing and of looking to the previous and next frames to only check for combing when there's been localized motion for each pixel.

Yadif doesn't use a full-blown deinterlacing mask as a separate pre-generated bitmap array, but it can still do a better job of deciding when to preserve data from the current field and when to deinterlace. It looks at more pixels above, below, and to the sides, and it has access to frames before and after. And since it's dealing with an interlaced source, each frame gives it 2 whole separate moments in time to analyze.

If blending is chosen, HandBrake's decomb uses a lowpass5 filter, which uses 5 pixels for samples in a vertical column, instead of just the one directly above or below. Which is to say, instead of:

Code: Select all

output = (input + pixel_below) / 2;
it's:

Code: Select all

output = ( pixel_2_above + 2*pixel_1_above + 6*input + 2*pixel_1_below + pixel_2_below) / 8;
When it comes to the actual interpolated pixel, yadif does way better than just averaging together the ones above and below. It does some simple edge detection, which means it can average together pixels along a diagonal if they seem like a better fit than the ones vertically above and below. If you're using decomb's defaults in 0.9.3, it does one better than that and uses a 4-tap cubic interpolator along the edge direction it finds (lifted from another Don Graft filter, actually). And in the next release, it'll have a much better interpolator, since I've ported tritical's eedi2 from AviSynth.

The only thing FieldDeinterlace does that HB doesn't is choose whether or not to blend a pixel based on how different it is from adjacent pixels. When decomb blends it does so on the entire frame without discrimination. I played with doing it on a per-pixel basis, but I found that the results weren't good enough. It would miss some combing that wasn't very different in pixel intensity from its neighbors, and deinterlace some parts that didn't need it but were different in pixel intensity. And sometimes these areas would change from frame-to-frame in noticeable ways. It's not a problem with yadif because it's spatially and temporally adaptive for each pixel, which works even better than a simple deinterlacing mask.

Another difference is that FieldDeinterlace is an either/or proposition -- always interpolate or always blend -- whereas HandBrake's decomb, by default, selects which filter to use on any given frame based on the combing detection mask. Only weakly combed or progressive-flagged frames get blended, the rest get interpolated. The parameters can be tweaked so that it only blends.

If you think that makes it really worthwhile, I'll look into porting FieldDeinterlace (would be very easy) but I think it'd be better to port TDeint.

ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by ExDeus » Sun Mar 08, 2009 11:56 pm

jbrjake wrote:
ExDeus wrote:I just thought selective decombing based on a threshold and blending/interpolating were not the techniques of a bobber.
And they're not, which is why in my last reply I explained that... [jerkiness is from] failing to detelecine before decombing.
Sorry - I missed the point. I was still trying to figure out if FieldDeinterlace was a bobber. I believe now we are in agreement that it is not.
jbrjake wrote:
ExDeus wrote:What is that going to do to mostly (almost pure) video content?
... The only time you might see jerkiness is if you've got telecined frames and you're only deinterlacing them and leaving the now-progressive duplicate frames behind.
OK - I will take a look at my comparison encodes between FieldDeinterlace vs HB decomb vs HB detelecine+decomb. FieldDeinterlace has produced very good results for me in the past on content I had always found to be pure video. I mostly just hadn't expected to need to run an IVTC filter on a talking heads show like "60 Minutes".
jbrjake wrote:If you think that makes it really worthwhile, I'll look into porting FieldDeinterlace (would be very easy) but I think it'd be better to port TDeint.
I have no particular allegiance to FieldDeinterlace, it has just been the only reliable deinterlacer I've found for video content. Most of the content I encode is 1080i HDTV from live or live-to-tape shows. You've done a clear job of highlighting decomb's superiority, and I believe you, I just need to figure out how best to process pure video, or video with some film content. It may be that detelcine+decomb will do the trick.

I was unimpressed with TDeint on pure video. I used TDeint on some "Saturday Night Live" shows in the past, which, except for pre-recorded content, are all video. On segments with pure video, like the live musical performances, I found TDeint performed horribly. Lots of bad motion trails and pixelated blending/interpolating on fast movement. I'm sorry, I don't know the correct language to use. Fast movement resulted in a very pixelated motion blur.

Regardless of outcome, I appreciate the time you've put into this.

ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by ExDeus » Mon Mar 09, 2009 5:08 am

I did a test on a 1m51s clip of "Late Night with Conan O'Brien" that had looked noticeably different, and that should be pure video. DGIndex says it's 100% video, too.

The HandBrake encodes still look jerky to me. Perhaps my eyes just favor something in FieldDeinterlace.

I used Zoom Player for the frame count and AVInaptic for the duration. When I looked at the reported "actual FPS" in ZP, it was very close to the average FPS computed below.

Original:
3327 f

HB with default decomb options:
3325 f / 111.072 s = 29.936 fps

HB with detelecine+decomb defaults:
3321 f / 110.810703 s = 29.970 fps - reported duration
3321 f / 111.072 s = 29.900 fps - matched duration

MeGUI with FeildDeinterlace:
3328 f / 111.072 s = 29.963 fps


Then I looked a longer clip. The difference in frames is negligible, so the framerate is the same to three decimal places.

HB decomb:
69094 f / 2305.0175 s = 29.975 fps

MeGUI with FieldDeinterlace:
69097 f / 2305.12 s = 29.975 fps


If there isn't any real difference in framerate, I have to believe it's something else in the deinterlacer.

jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by jbrjake » Mon Mar 09, 2009 2:58 pm

....well like I said before, it appears that in FieldDeinterlace, since you're using default parameters, you're not really deinterlacing, in the sense of filling in missing data to scale a half-height field to full-frame height.. You're just blending both fields together. That's why I told you, about HandBrake's decomb, that "The parameters can be tweaked so that it only blends."...so you can try that out. Should be:

Code: Select all

--decomb=4
I'd be interested in seeing this clip.

BTW, that detelecine changes the FPS at all indicates that either your source is *not* purely video or detelecine is misfiring (very rare). DGIndex is not exactly reliable. The only real way to know if a source is telecined is brute force: check every frame for combing and then look for whether weaving a field from a combed frame with a field from an adjacent frame produces better metrics, which is what pullup (the detelecine filter HB uses) does.

Also, I would not suggest looking for jerky movement in an app like ZoomPlayer. I'm not positive it handles variable framerate video or out of order frames properly.

As far as TDeint vs. FieldDeinterlace, interesting to hear that. I've never used either myself (Mac user, through and through) so I'm only aware of these filters through reputation and code, not output.

ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by ExDeus » Wed Mar 11, 2009 9:11 am

jbrjake wrote:That's why I told you, about HandBrake's decomb, that "The parameters can be tweaked so that it only blends."...so you can try that out. Should be:

Code: Select all

--decomb=4
I gave that a try. I think it looks better, but it still looks off to me compared to FieldDeinterlace. I just can't quite spot the exact differences. It's almost like a strobe effect in some of the movement.
jbrjake wrote:I'd be interested in seeing this clip.
Sent you a PM.
jbrjake wrote:Also, I would not suggest looking for jerky movement in an app like ZoomPlayer. I'm not positive it handles variable framerate video or out of order frames properly.
I've been using ZoomPlayer because that's what I normally use for playback, and the FieldDeinterlace clips looked good. But now that you say that, it seems stupid to only compare with one player. What do you suggest using?

I tried using MPC-HC, and sometimes the differences don't look so big anymore. I've watched the same clip so many times now, it's growing difficult to discern the exact differences between the encodes. Sometimes it seems very obvious, and others not so much.

I don't know. I'll be curious to hear what you see.

jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by jbrjake » Wed Mar 11, 2009 3:42 pm

Ah....I didn't realize you were using MKV. See if the jerkiness is still there if you encode to MP4 and play back in VLC or MPlayer (real MPlayer, not MediaPlayerClassic or some other Windows app).

Doing frame by frame comparisons of your test encodes, I think you're seeing some container-induced jerkiness from MKV.

Now, there's a clear difference between the regular detelecine+decomb encode versus the FD encode, because of the FD encode using blending. It might seem a little smoother because it's preserving more temporal resolution from the source. Like, when Conan's guest is introduced, and the camera cuts to the one showing him walking out from behind the curtain, in the FD encode there's a blended transition frame half from one camera half from the other. In the detelecine+decomb encode, the whole frame is from the second camera. But the encode you did with HB's decomb in blend mode shows both halves of the transition as well. So if you still think it's jerky in blend mode, that definitely rules out the temporal resolution possibility and makes me suspect the container.

Quality wise, while I'm of course biased, I liked the look of regular decomb best, blend decomb second, and FD third. The loss of detail in FD is really noticeable when the guest waves hello.

ExDeus
Posts: 43
Joined: Mon Mar 02, 2009 7:13 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by ExDeus » Thu Mar 12, 2009 6:19 am

jbrjake wrote:Doing frame by frame comparisons of your test encodes, I think you're seeing some container-induced jerkiness from MKV.
I will try out an MP4 in one of players you suggested. Just testing MPC-HC already makes a difference. I think playback is smoother. I should've tested other players earlier.

One nice feature ZP does have is very easy frame skip fwd/back. It made very easy to compare frames, and I do see the difference.
jbrjake wrote:Quality wise, while I'm of course biased, I liked the look of regular decomb best, blend decomb second, and FD third. The loss of detail in FD is really noticeable when the guest waves hello.
You're right about the quality on the individual frames. Stepping through the frames, it is very easy to tell the increased detail that HB decomb leaves in the picture. Particularly in the fast movement - Fred Armisen (the guest) waving, the fast camera pan as he walks across, or Conan's pat on the shoulder.

In that fine detail, though, I also see more pixelation in some areas. I think perhaps my eye favors the blending of motion blur, where the detail is very soft, to the fine detail with more encoding artifacts - pixelation and off colors - in the picture. I'm thinking those flashes of hard-to-encode video in the fast movement are what my brain picks out and views as choppy movement - like a persistence of vision filter that just says, "well that doesn't look right, throw that crap away."

I PMed you a link to the source clip.

If anyone cares, here are my test encodes: http://rapidshare.de/files/46001616/Lat ... 0.rar.html

jbrjake
Veteran User
Posts: 4805
Joined: Wed Dec 13, 2006 1:38 am

Re: HandBrake equivalent to AviSynth FieldDeinterlace()

Post by jbrjake » Thu Mar 12, 2009 4:33 pm

ExDeus wrote:In that fine detail, though, I also see more pixelation in some areas.
You might just be encountering yadif's notoriously poor edge direction detection that tends to leave behind jaggy edge on sloping lines.

Post Reply