Handbrake - What does Modulus mean?

[hello_hello]

I think Handbrake's decomb filter is on by default and it attempts to take care of both deinterlacing and inverse-telecine. De-interlacing progressive video is not a good idea (it tends to blurr) and the decomb filter doesn't just blindly de-interlace everything. Apparently.... I've not used Handbrake much myself.

If a video is definitely interlaced, selecting "Bob" as the de-interlacing method is a good idea (or I think the decomb filter also has a "Bob" option). Instead of de-interlacing NTSC to 29.970fps progressive, or deinterlacing PAL to 25fps progressive, the output will be 59.940fps and 50fps respectively. Motion should look much smoother. When you watch interlaced video and it's being de-interlaced by the player, that's usually how it's done.

[hello_hello]

Did you explore different methods of signalling ? Container flags, vs stream SAR ?

Yes. Mostly I encode via MeGUI, and it sets both. The TVs in question are Samsung and the aspect ratio ignoring Bluray player is also a Samsung. The Sony Bluray player displays anamorphic encodes correctly. That was typical for Samsung a few years ago. I've no idea if they've lifted their game since then.
Mind you, aside from a lack of anamorphic support they're very good media players. They rarely refuse to play something.

There was a Sharp TV in the house and I'm fairly sure it's media player lacked anamorphic support, although I could be remembering incorrectly. It moved out with it's owner a fair while ago.

[jagabo]

I gave it to Irfanview to upscale as a quick test. Lanzcos resizing.
Resized directly from 720x576 to 1920x1080
Resized in two steps. 720x576 to 1024x576, then 1024x576 to 1920x1080

It just so happens that Lanczos works well at the 1024 intermediate. BlackmanResize() too. If you had used Spline36Resize() you would have seen this:



Most other resizers give moire artifacts similar to Spline36. And they all give similar artifacts at NTSC's intermediate of ~852x480.

[Hmmm]

I think Handbrake's decomb filter is on by default and it attempts to take care of both deinterlacing and inverse-telecine. De-interlacing progressive video is not a good idea (it tends to blurr) and the decomb filter doesn't just blindly de-interlace everything. Apparently.... I've not used Handbrake much myself.

Right now I am going to encode a Blu-ray TV episode, and BDInfo tells me the source is 1080p. That does mean 1080 progressive, right? In this case, I shouldn't use any deinterlacing method according to your statement and other sources as that hurts picture quality, but decomb? Hmm... I have to research what that is in more detail and whether it is needed for me. *starts searching*

[Hmmm]

According to HandBrake's own website, it says it is a safe option to leave decomb on at all times. That sounds good! It does not, however, at least what I could see, offer information about what level of the decomb filter that is recommended. I assume "fast", as with most settings, is less accurate, but please do correct me if I'm wrong. HandBrake offers a "default" mode, but gives no info on what that default is (which might actually be a good thing as long as the results are decent enough so I don't have to learn a thousand things about the filter :P). It also offers "custom" and "bob" modes.

I have a feeling that "default" should be okay, but it also makes me unsure since there's no actual info on it. Anyone want to weigh on?

[jagabo]

According to HandBrake's own website, it says it is a safe option to leave decomb on at all times.

You should always disable filters your source doesn't need.

[Hmmm]

Alrighty then, thanks for clarifying! Both deinterlace and decomb set to Off, and I'll do a test encode now! fingers crossed for another excellent encode!

[hello_hello]

Most other resizers give moire artifacts similar to Spline36. And they all give similar artifacts at NTSC's intermediate of ~852x480.

I understand the concept and in a perfect world.... one where nobody ever makes a god awful movie based on Marvel Comic characters (I tried to sit through one tonight and I take my hat off to anyone who can).... you probably wouldn't resize, but while I'm fully aware doing so can cause unwanted side effects, I'm still not convinced the sky will fall.

I'm not arguing with the result of resizing your picture. I expected it. I'm still not sure how often you'd be resizing something similar in DVD video, or if you were, if it'd already be a mess. Many times I've noticed excessive haloing somewhere, or a moire effect etc, but checking usually reveals the problem is already present in the source video.

Anyway..... the $2 question remains..... so I'll try a third time. Of the two screenshots I posted, which looks better to you? Because I've owned my Samsung TV for about four and a half years now, and I've encoded many a DVD during that time, always resizing to square pixels, often resizing the height a little also, and I'm still confident the resized encodes tend to look better.

Since rethinking my outlook on the world and the shape of it's pixels, I've mentioned my thoughts here and there and the error of my ways are explained, and I generally ask for, but so far haven't received, a real world example of DVD video that suffers as much when stretched to 16:9 as it can in theory. Even half as much would do to begin with.....

[jagabo]

Anyway..... the $2 question remains..... so I'll try a third time. Of the two screenshots I posted, which looks better to you?

I prefer the one that went directly from 720x576 to 1920x1080*. Most TVs and DVD players I've seen use a bicubic filter to upscale so the result would be a little sharper. And the square pixel version would have its oversharpening halos further exacerbated.

* Though it might depend on the viewing conditions. If you're sitting far enough away the oversharpening halos aren't really visible, the picture just looks sharper.

[hello_hello]

Alrighty then, thanks for clarifying! Both deinterlace and decomb set to Off, and I'll do a test encode now! fingers crossed for another excellent encode!

If you know the source is progressive disabling the decomb filter is probably a good idea. I've played with it a little, but i think the decomb filter only de-interlaces when it detects combing (the effect of interlacing) and it de-interlaced differently according to how much combing it detect. The most common complaint about it I've read is regarding it missing combing at times, but that's probably an avoidable compromise. Either de-interlace everything or try to be a bit more clever about and risk getting it wrong now and then.

https://trac.handbrake.fr/wiki/Decomb#filters
By default:
When a frame shows a significant amount of combing, decomb runs a tweaked version of HandBrake's "Slower" deinterlacing filter. That's yadif, a spatially (within one frame) and temporally (between several frames) aware deinterlacer. The tweak is that it uses a looks at more pixels when generating the spatial predictions.
When a frame is only very slightly combed, decomb runs a blending deinterlacer called a lowpass-5 filter. This preserves more detail from the image than yadif, and in particular prevents noticeable deinterlacing artifacts on progressive video.

Handbrake's log file is fairly informative, I've not used it enough to understand exactly what it's doing and the GUI tells you pretty much nothing. But the log file attempts to keep you informed after the video is encoded. Something like:

decomb: deinterlaced 2274 | blended 582 | unfiltered 71 | total 2927

I was also under the impression the decomb filter was also responsible for pulldown removal, but I assume that's not correct? To this day I still have no idea how to give Handbrake a hybrid source, such as an NTSC DVD with some combination of pulldown/interlaced/progressive, and which filters should be enabled.

[hello_hello]

Anyway..... the $2 question remains..... so I'll try a third time. Of the two screenshots I posted, which looks better to you?

I prefer the one that went directly from 720x576 to 1920x1080*. Most TVs and DVD players I've seen use a bicubic filter to upscale so the result would be a little sharper. And the square pixel version would have its oversharpening halos further exacerbated.

* Though it might depend on the viewing conditions. If you're sitting far enough away the oversharpening halos aren't really visible, the picture just looks sharper.

So you prefer the first one based on how you think it might be processed and not based on how they look?

One the other side of that coin, it's fairly common for TVs to have built in noise removal and deblocking enabled by default which blurs the picture as a result.

But yes, I agree. On occasion, if I switch MPC-HC to bicubic upscaling, sometimes it can look borderline over- sharpened, but mostly if the DVD picture has already been sharpened and I tend not to using bicubic anyway. I prefer softer upscaling for the lower end of the viewing quality spectrum (ie low resolution Xvid encodes) and I can leave it that way for the square pixel DVD encodes because they've already been sharpened a little, and for 1080p it doesn't matter. I'll confess I do tend to give more weight to how it'll look when viewed with my equipped than I do to how it'll look when I'm not viewing it on something elses.

To be honest, I'm not even sure that sample is typical. It was just one I had handy to demonstrate the difference, and looking again I think it was a bad choice.
This is a MPC-HC screenshot from the anamorphic encode. No resizing anywhere. A minute or so in time earlier than the previous screenshot. What's your opinion? I think I might have picked an already sharpened video to use for the comparison. If so it wasn't one of my more clever moments. Does it look sharpened to you?

[manono]

I was also under the impression the decomb filter was also responsible for pulldown removal, but I assume that's not correct?

Not correct. And that's one of the several reasons I won't have anything to do with that program - it renames already named processes, and in doing so just manages to confuse and mislead people. You're referring to the 'detelecine' filter.

[jagabo]

So you prefer the first one based on how you think it might be processed and not based on how they look?

Based both on as they are, and as I think they will appear on TV.

To be honest, I'm not even sure that sample is typical. It was just one I had handy to demonstrate the difference, and looking again I think it was a bad choice.
This is a MPC-HC screenshot from the anamorphic encode. No resizing anywhere. A minute or so in time earlier than the previous screenshot. What's your opinion? I think I might have picked an already sharpened video to use for the comparison. If so it wasn't one of my more clever moments. Does it look sharpened to you?

I think it's a sharper than average. But not over done.

[hello_hello]

I think it's a sharper than average. But not over done.

Co-incidentally, I'd use almost those exact words to describe the result of spline36 stretching the width to a 16:9 resolution for encoding. Assuming, of course, the DVD isn't too much sharper than average to being with.

[hello_hello]

Not correct. And that's one of the several reasons I won't have anything to do with that program - it renames already named processes, and in doing so just manages to confuse and mislead people. You're referring to the 'detelecine' filter.

I knew the detelecine filter was there, and there's also a de-interlacing filter, but the decomb filter can be used (according to the Handbrake help files) for more clever deinterlacing and for some reason I thought it could also IVTC, but there's no mention of that in the help files so I guess I imagined that one.

Edit: I found this:
https://trac.handbrake.fr/wiki/PictureSettings#filters
Decomb / Deinterlace
A slider bar toggles between controls for the decomb filter and the deinterlacing filter. Both filters handle deinterlacing, and only can be used at a time.

The slider bar must be relatively new. Handbrake 0.9.9.5530 doesn't have one.

Would I be interpreting the following correctly?
https://trac.handbrake.fr/wiki/Telecine#vfr-in-hb
"Even if a source is entirely hard telecined, HandBrake's detelecining filter is stateless, and will produce variable output: if part of a scene has no movement, it won't detect any telecining since there will never be any combing, even in duplicate frames."

Wouldn't that be the definition of not detelecining?
I'm having trouble wrapping me head around that one, given I've spent most of my life believing the detelecine process always applies telecine removal.
The Handbrake detelicine process doesn't care about the frame rate, so if need be Handbrake "fixes" the frame rate according to what was specified. Therefore if you specify a constant 23.976fps for a purely telecined source, there might be places where the telecine filter is outputting up to 29.970fps and Handbrake discards as many as required for 23.976. Is it just because I'm very tired, or does that seem to icrease the potential for ugliness somewhat considerably?

Re-reading the earlier description of Handbrake's detelecine filter:
https://trac.handbrake.fr/wiki/Telecine#detelecine
When there's an obvious 3:2 pulldown pattern the detelecine filter outputs 29.979fps progressive where one in five frames is repeated. That seems familiar. Handbrake prefers not to keep duplicate frames, but if you tell it to output 29.970fps it will. Not ideal though. If you specify 23.976fps it'll drop one frame in five, and you'd have to assume the duplicates would be the first to go.

If you just leave the framerate as "Same as source," though, HandBrake will drop those duplicate frames and only those duplicate frames, with no extra dropping or copying of frames. We call this process Variable Frame Rate detelecine.

Sorry, I'm really thinking out load as I type, trying to get it straight in my head.

Is the end result of Handbrak's IVTC going to be typical IVTC?
We know the detelicine filter's output is 29.970fps if there's a steady 3:2 pull-down pattern.. We know if you tell Handbrake you want a "same as source" variable frame rate output it varies the frame rate by dropping duplicate frames. There's no mention of a frame rate reduction as such, or of the frame rate being averaging etc, only the dropping of duplicate frames. Therefore wouldn't the output still be 29.970fps progressive with the duplicate frames dropped rather than encoded, but still 29.970fps with one frame in five effectively repeated. Is it really?

Over the years I've seen a reasonable amount of Handbrake DVD encodes, and generally assumed some sort of user error..... so I searched the archives and found this:




MPC-HC says it's 29.970fps, despite the fact Reclock immediately contradicts it and claims 23.976fps.



So I invited ffdshow to the party. It's displaying a very steady frame duration of 33.3367ms which would be 29.970fps which it contradicts itself by displaying a frame rate that mostly wanders between about 23 and 24fps



It does give a reasonable indication there's effectively "missing" frames though. I started the frame count at 18040 and stepping through them one at a time caused ffdshow to display this sequence (there was steady movement).
18040, 18041, 18042, 18044, 18045, 18046, 18047., 18049, 18050.
At the other end of the encode, where there was nothing to see but static credits, ffdshow indicated all the frames were present and a fairly steady 29.970fps frame rate. Reclock was still claiming 23.976fps.

I thought I'd mention I tried a quick re-encode of the above encode and ffms2 output was not a typical frame rate and motion wasn't the smoothest, but if I told ffm2 to convert the frame rate and output a constant 29.970fps, and if I followed that with tfm().tdecimate() the output looked nice and smooth at 23.976fps.

I'm not sure if I'm missing the obvious or if Handbrake's detelecine works quite differently to what I expected. I've had enough for tonight though and I do need to catch up one some sleep. Comments would be welcome.

[manono]

...and in doing so just manages to confuse and mislead people.

I already mentioned I don't and won't use that program. A traditional AviSynth IVTC first performs the field matching followed by duplicate removal. From all you quoted it sounds like Handbrake's Detelecine does field matching but you then have to specify the 23.976fps to get it to remove the duplicate frames. That's similar to Telecide/Decimate and TFM/TDecimate, but those pairs are known partners in the process while if using Handbrake you have to turn on a separate filter somewhere else. And how is a newcomer supposed to understand all that gobbledygook you quoted?

Wouldn't that be the definition of not detelecining?

Yes, since, by definition, the very advanced inverse telecine filter it claims to be is supposed to return the video to its progressive 23.976 source framerate. All it's doing is field matching, and not even doing that when the video is 'static'. So,yes, I was slightly wrong. You need to specify the 23.976 framerate after turning on the Detelecine filter.

[hello_hello]

I'm still not sure what's going on with ffdshow but I managed to fix it's schizophrenia. I'd set it to decode so I could use the on screen display but today I enabled it's raw video decoder instead so it'd just process the LAV output. That way things made sense. The frame rate being displayed matched the frame durations.

What I'm seeing now is a combination of two constant frame rates. The output is either 23.976 (where there's motion) or 29.970 (where there's no motion). Nothing in between. I thought variable meant "any frame rate" but maybe when you encode NTSC and specify "same as source", Handbrake effectively switches between 23.976 or 29.970 as required. Which probably seems odd if you're encoding something that's pure "film" from beginning to end, but if that's the compromise needed for Handbrake to encode a combination of "film" and "video" correctly, rather than have to convert one to a common frame rate, maybe it's not a bad thing, especially if Handbrake's equivalent of "force film" is to simply set the output frame rate to a constant 23.976fps.

I'm sure for the sample I looked at, that's what's going on. A combination of two constant frame rates. There's still a few things I'm not sure of though, such as what's the difference between "same as source, constant frame rate" and "same as source, variable frame rate". I suspect for the former you get a constant 29.970fps and any "film" sections have one in five frame repeated, because I'm sure seen lots of Handbrake NTSC encodes like that.

I don't know if throwing the decomb filter into the mix would change any of that, but tomorrow I'll probably run a few test encodes and try to find out. My main problem with Handbrake has never been that I think it's a bad program, it's just been my inability to predict what it's going to do, and therefore not being able to tell it what I want. It's probably not hard once you know.

Edit:
https://trac.handbrake.fr/wiki/Telecine#vfr-in-hb
I just re-read the description of "Variable Frame Rate Detelecine" and I was wrong yesterday. It does mention a frame rate reduction to 23.976 for the "film" parts when "same as source" is chosen. I even quoted part of it. Obviously the penny didn't drop.

[thegog01]

Apple is only concerned with compatibility with Apple products.goldenslot