HandBrake

This is not a question on "howto" deinterlace. I have no issues with that.

I would like to know, if there are any additional setting I can type in the additional setting box which will interlace either interlaced video, or reinterlace progressively stacked fields, so it can once again be seen without the combing effect; and, with the fluid motion of interlace on monitors which support interlace or a simulated interlace on a progressive display. H264/X264 DOES support interlace video and so does MKV. There are settings I've used in Mencoder and have interlaced video in Avidemux.

Turning off deinterlacing does not preserve the interlace; instead, HandBrake stacks the fields, thus destroying the interlace so, it looks combed even on interlaced displays. This is common with most encoders so, it's not a bug. Some encoders have a checkbox (or in the codec settings such as X264) to check if the video is interlaced, which will preserve the fields individually rather than stacking them into one frame. There might be a code which will tell the encoder not to stack the fields, but leave them separate, in the additional settings box. I'm using Ubuntu 12.04. A future release of HandBrake could have a checkbox in the deinterlacing area which could preserve the interlace or even unstack the fields from a previous encoding, to reinterlace them. I've done this many times in Avidemux with very good results. Field swap would be nice too, when someone captures the top field first by accident....oops!

(I can't see why I would need an activity log since this question isn't about any errors which HandBrake is doing. The question is simply based on advanced settings (if any) I can do. I've searched the forum, but only "deinterlacing" is coming up Which is the opposite of what I'm wanting to do with HandBrake.)

I know this sounds strange, but it's really not. There are many reasons today to keep the interlacing. For one thing, the newer monitors can now support it as they are fast enough to do it at 60hz (US), often higher now, some reaching 120hz (active 3D in 1080i). The biggest issues with interlacing was displaying it on progressive monitors, which "stacked" the fields into one frame, thus creating that "combing" effect. Interlacing had pros and cons on CRTs too. Pro side was, reduced flicker, gives illusion of 60 fps, the con side produced an illusion of "scanning lines" which really weren't there. This was caused by the fact CRTs are incredibly fast as only 10% of the screen was even lite at a time. Today's monitor, though fast enough to interlace (or simulated it) are not so fast they create those "scan lines" effects. In short Interlaced video just looks more like "video" than "film" as you have better motion compensation. In fact, that's the new word for interlaced video "motion compensation". There is no broadcast standard in the US for 1080 Progressive. And most networks still use interlaced cameras at 1080i. So many TV shows and nearly all sporting events are interlaced. It's simply better to view interlaced video as interlaced than to deinterlace it. Deinterlacing causing artifacts too. It's only good if you cannot view it as interlaced.

Interlaced encoding is not officially supported, but can be done. You need to ensure no scaling takes place (using anamorphic Strict will do), as interlaced scaling is not supported and add tff=1 or bff=1 to your advanced x264 settings, depending on whether your source is top or bottom field first.

That actually works and is so simple too! Thanks. It preserved interlaced video and even re interlaced those which were stacked. It even corrects field orders, if someone goof them up. Yes I tested it on all three. And all one has to do is append :tff=1 or :bff=1 at the end of the advanced x264 settings in the box below.

It seems like a simple checkbox could be used, which would uncrop and use strict, in the picture settings.

Anyway thanks again.

Fascinating! Will HandBrake's scan show if your source was tff or bff?

I never showed anything like that, but in general Bottom is first. But, in doubt, I always encode a small portion of the file. if the bottom field first comes out with that jerky reverse field look, then you know the top field was first. What I would like to find is a filter which can auto sense when the fields got swap, when an capture drops a field rather than a frame, but haven't found a real one.

lostcub wrote:I never showed anything like that, but in general Bottom is first.

For DV, yes. AFAIK most TV/DVD/BD content is top field first.

Cropping should work so as long as all crop values are even (MacGUI enforces that, not sure about other UIs).

I have no plans to add such a checkbox (I don't think the other devs have any interest in officially supporting interlaced encoding either).

I was thinking if you scaled the horizontal, it shouldn't affect interlacing as interlacing is vertical. So If I wanted to take a 16x9 720:480 and scaled it wider to be true 16x9 it shouldn't affect it. I guess in theory, each field (if already interlaced) would be scaled individually as technically they are like half height frames. If you are unstacking the fields, that might be an issues. But, I could experiment. the worst thing which could happen is, I'll mess of the encoding or getting a nasty error.

As for bottom field first, it seems all my NTSC captures are bottom field first. Learned that the hard way! However, ATSC 480i could be top first and haven't worked with it directly, DVD seem to be top field first. All the Blurays I've come acrossed were all in 1080p, so I didn't bother to deal with interlacing. But, like I said, when in doubt encode a small amount and see. (better to test it first than to find out later after hours of encoding) It's obvious when they are reverse. Avidemux support interlacing in the x264 encoder (at least in the Linux version); however, I like HandBreak better. But it is harder to edit.

Going slightly of the topic. Has there been in thought about deinterlacing film content, by not deinterlacing the interlaced frames, by simply dropping the repeated fields/frames and restore it back to 24fps from the 30/25fps? I feel this would be a better approach, not only will it make a smaller file, but it could remove the judder effect on some monitors.

lostcub wrote:Going slightly of the topic. Has there been in thought about deinterlacing film content, by not deinterlacing the interlaced frames, by simply dropping the repeated fields/frames and restore it back to 24fps from the 30/25fps? I feel this would be a better approach, not only will it make a smaller file, but it could remove the judder effect on some monitors.

That's what the Detelecine filter is for. Here's a little something to read up on: https://trac.handbrake.fr/wiki/Telecine

Rodeo wrote:

lostcub wrote:I never showed anything like that, but in general Bottom is first.

For DV, yes. AFAIK most TV/DVD/BD content is top field first.

Correct, DV and DVCAM are the only formats I've encountered that are bottom field dominant.

DVD is unspecified; can be either.
Since DV is lff, DVDs from DV footage "should" be lff, even if the encoder is capable of making the switch.

Well, like I said previously, When in doubt test a small area of the video (especially with high horizontal motion). The last thing you want, is to have an encoding which took hours to encode to find the fields are reverse. Hey, professional broadcasters are still getting it wrong and with newer sets supporting interlace (or rather a simulated interlace over progressive AKA motion compensation.) their boo-boos come flickering through! Of course, I personally think some idiot checked the box to "reverse fields", but they're getting better at it. Digital hasn't always been friendly to the professional broadcaster. While reversed fields do cause artifacts on a 1080p monitor with a deinterlacer, most people don't really notice it, but those who pay attention to detail can easily see the artifacts, most deinterlacer can't completely correct it, at least real time ones; however, on 480i or 1080i displays it's quite annoying to everyone......quite.

While reversed fields do cause artifacts on a 1080p monitor with a deinterlacer, most people don't really notice it, but those who pay attention to detail can easily see the artifacts, most deinterlacer can't completely correct it, at least real time ones; however, on 480i or 1080i displays it's quite annoying to everyone......quite.

That's the longest run-on sentence I've read on this forum, to the best of my memory.
But I totally get what you are saying.
;?)

But, it's at least formated semi correctly; perhaps, I should have used semicolons?

perhaps, I should have used semicolons?

or periods.

I overuse semicolons; my life is but a maze of independent clauses.

Rodeo is correct about "no scaling". I had done an NTSC capture. I had captured a 16x9 on a 4x3 scale AKA "squeeze" format, to get more resolution, than letterboxed. HandBrake kept--well breaking with the bff=1 in the additional settings (or in the advanced settings). At first I thought it was the default setting which is variable frame rate; and, I forgot to change it. Apparently you can do variable in interlace. I wouldn't recommend for interlace, as smart TVs and DVD players probably won't support it. It turned out the crashing was caused by the rescaling, even if the vertical resolution is kept the same. I remuxed the file in MKVMerge to change the aspect ratio from 4x3 to 16x9. See, I can use periods too, when I don't feel like having long drawn out thoughts.

I have some DVD content (TV episodes) where some files have incorrect TFF/BFF interlacing flags set in the encoded file. It turns out that there is an 'idet' ffmpeg filter that ignores the flags and analyzes the actual video content to attempt interlacing detection:

http://www.aktau.be/2013/09/22/detectin ... th-ffmpeg/

I created a Perl script front-end to this:

http://pastebin.com/vQQKSFSB

By default, it returns the dominant type:
This is intended for scripting. It can also report verbose frame count types:
Some videos without a lot of motion might have a dominant number of frames identified as progressive:
For these, you can use the -i option to consider only the tff and bff interlaced frame counts:

That might be a little more complicated for Handbrake users. But, for the most part, for me, just adding bff=1 (even NTSC DVDs seems to be bff not just NTSC composite.) in the more options box in either the advanced or video section works for me. So, I can use basic setup and still encode interlaced. (I like to put it on placebo as it really does create a the smallest file, yet it has the best quality. It can take 24 hours or more, but worth it. I did a 1.2Gb encoding of a 90 minutes film. It appeared to the eye as the same high quality DVD with all the film grain and no banding or blockiness at all.) One thing to note: Many TV series are filmed, so they aren't truly interlaced. Dropping the interlaced frames used in the pulldown from 24 to 30 works best. The video card can do a more seamless frame rate conversion than the original interlacing. While TVs and Monitors can now do a simulated interlace on progressive, they are still progressive displays. Well technically, they aren't even progressive as the pictures is not scanned. It's pretty much drawn at the same time, which eliminates those "interlacing" lines on CRTs, which aren't really there. They were caused by the afterimage in the eye as less than 10% of the screen was lit at any given time.

I kinda wish there were filters which auto detects when field order changes. If a human can see it, one would think an algorithm would detect it more rapidly. Analogue captures can be plagued with this. They tend to drop fields rather than whole frames when timing goes off, thus the field order changes, often in mid scene too...naturally. I assume all capture devices actually capture each field as if it was a frame and that would make sense since, fields are separate images when they used to be broadcasted. Why would the old NTSC system send the bottom field first, I haven't a clue. To me it doesn't make sense, line 0 should come before 1. But, I'm sure there is a logical reason for it. However, it seems I only have to worry about that issue if I'm capturing analogue video.