Interlace Checking

[chris319]

Here is a procedure I use to check whether video is truly interlaced.

Why this is important: in the U.S., many cable and broadcast networks such as CBS, NBC, PBS and many others require that video they broadcast be interlaced with a vertical resolution of 1080. If it's not 1080 interlaced they won't play it. See here for a list of broadcast and cable video standards:

https://en.wikipedia.org/wiki/High-definition_television_in_the_United_States

Today, 1080p (progressive) has become a popular video format but it is not acceptable to broadcasters who require 1080i interlaced video.

Here is how I check to see if a video is indeed interlaced.

You will need some video with a moving object. I like to use cars and trains with a slow, more-or-less constant rate of movement. You will also need the VLC video player.

In VLC, play the video you want to check and pause it when a moving object can be seen and is in motion.

This next step is very important. Right click on the VLC player screen. A context menu will appear. Select Video -> Deinterlace -> Off to make sure VLC's deinterlacer is OFF.

If the video is truly interlaced you will see line pairing right away. The line pairing will "jump out" at you. You can't miss it.

This method has been tested with Windows 10. It has not been tested with Mac or Linux but it may still work with those operating systems.

Now for the caveats.

MediaInfo is a wonderful program but it can be "faked out", in other words it sometimes gives false positives when checking for interlacing. So MediaInfo is not dependable for checking interlacing.

If you have a progressive-scan video that you need to convert to interlaced, below is some ffmpeg code which will convert progressive-scan video to interlaced.

ffmpeg -y  -i "C0008.MP4"  -s 1920x1080  -pix_fmt yuv422p  -vcodec mpeg2video  -vf  interlace=0,scale=out_color_matrix=bt709:out_range=limited  -flags +ilme+ildct  -r 29.97  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -acodec mp2  -f mpegts output.ts

The flag ilme means "interlace motion estimation" and ildct means "interlace discrete cosine transform". These flags can "fake out" MediaInfo if they are set but the video is not actually interlaced, i.e. a false positive.

In addition to interlacing, this code will convert the resolution to 1920 x 1080, set the chroma subsampling to 4:2:2 and the frame (not field) rate to 29.97 frames per second using the mpeg2 video codec. The various color settings will preserve color accuracy. If you are familiar with writing ffmpeg scripts you can experiment with the audio settings and video codec.

Consult the VLC documentation if you want to create a hotkey which will turn VLC's deinterlacer on and off.

[manono]

MediaInfo is a wonderful program but it can be "faked out", in other words it sometimes gives false positives when checking for interlacing. So MediaInfo is not dependable for checking interlacing.

The videos only have to be encoded as interlaced while the content can be progressive. There's a difference. In addition, telecining is okay and that's significantly different from interlacing. MediaInfo is correct; if it says the material is interlaced, then that's how it's been encoded.

[chris319]

The videos only have to be encoded as interlaced while the content can be progressive.

If you have progressive video that's encoded as such, 1080p for example, then you'll need to flag it as interlaced. The point remains that the ilme and ildct flags are needed to make MediaInfo show "interlaced". An OTA broadcaster may re-encode it to a lower bit rate anyway to fit within its channel plan.

If you're starting with 1080p I would think it preferable purely from a quality standpoint to flag it as 1080i and keep it progressive, assuming there are no compatibility issues. However, if a client rejects it and insists on true interlace, that's how to do it and check it.

If you need to convert from 1080 to 720p then use -s 1280 x 720 in the above ffmpeg code and eliminate the interlace argument and the ilme and ildct flags. Keep all of the color flags, though, to keep the colors true.

[Cornucopia]

These tips can be helpful, but be precise about the relationship with the framerate.

IOW, 1080p could be 1080p30(/25) or 1080p60(/50). 1080p30 can be fairly easily flagged as 1080i30, but 1080p60 cannot, because frames/fields need to actually be dropped (usually requiring re-encoding).

Scott

[chris319]

These tips can be helpful, but be precise about the relationship with the framerate.

One should always be mindful of frame rate, but the immediate purpose of this thread is whether the actual pictures are interlaced, i.e. alternate scan lines (pixel rows) appear every 1/60 second.

If you're delivering to broadcast or cable, they're going to specify the resolution, chroma subsampling and frame rate and be strict about it.

[poisondeathray]

Here is how I check to see if a video is indeed interlaced.

You will need some video with a moving object. I like to use cars and trains with a slow, more-or-less constant rate of movement. You will also need the VLC video player.

In VLC, play the video you want to check and pause it when a moving object can be seen and is in motion.

This next step is very important. Right click on the VLC player screen. A context menu will appear. Select Video -> Deinterlace -> Off to make sure VLC's deinterlacer is OFF.

If the video is truly interlaced you will see line pairing right away. The line pairing will "jump out" at you. You can't miss it.

This method has been tested with Windows 10. It has not been tested with Mac or Linux but it may still work with those operating systems.

A non deinterlacing preview method can be helpful for diagnosing the actual content - but that method can fail, because it's not looking at individual fields, it's actually looking at 2 fields weaved into a frame

eg. A field shifted source will look "interlaced" according to that method, but is actually progressive content .

eg. a movie or episodic drama tv show will be 23.976p but is telecined for broadcast. For the movie or TV show - if you set deinterlace off VLC, some frames will look "interlaced", others "progressive", depending on which frame you check within the 3:2 cadence

A more reliable method to check a 29.97i stream for content in VLC would be to set it to "bob" or "yadif2x" (Which essentially resizes fields to frames). When that is enabled (and assuming it works, VLC sometimes "sticks" or is buggy, there are other ways to check fields more reliably but the concept is the same) -

1) If you advance frame by frame and every frame is different during a motion sequence, it's interlaced content. (at least for that section, you can have mixed content). By That is interlace by definition (or at least one of them) . Each field represents a different moment in time.

2) If every frame pair is duplicate , it's 29.97p content . The field shifted variant will be detected by this

3) If you have 3:2 triplicates/duplicates - it's 23.976 content .

There are other cadence patterns but those 3 are the main ones you will find in a broadcast scenario

MediaInfo is a wonderful program but it can be "faked out", in other words it sometimes gives false positives when checking for interlacing. So MediaInfo is not dependable for checking interlacing.

Content has to be distinguished from encoding type, and flags. You can have interlaced content encoded progressively, or progressive content encoded interlaced. Mediainfo does not look at content (at all); it only looks at flags or encoding type - and it's pretty reliable for that.

If you have a progressive-scan video that you need to convert to interlaced, below is some ffmpeg code which will convert progressive-scan video to interlaced.

ffmpeg -y  -i "C0008.MP4"  -s 1920x1080  -pix_fmt yuv422p  -vcodec mpeg2video  -vf  interlace=0,scale=out_color_matrix=bt709:out_range=limited  -flags +ilme+ildct  -r 29.97  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -acodec mp2  -f mpegts output.ts

The flag ilme means "interlace motion estimation" and ildct means "interlace discrete cosine transform". These flags can "fake out" MediaInfo if they are set but the video is not actually interlaced, i.e. a false positive.

In addition to interlacing, this code will convert the resolution to 1920 x 1080, set the chroma subsampling to 4:2:2 and the frame (not field) rate to 29.97 frames per second using the mpeg2 video codec. The various color settings will preserve color accuracy. If you are familiar with writing ffmpeg scripts you can experiment with the audio settings and video codec.

This will only work for 29.97p content (29.97p content , encoded as 29.97i) . If you start with 23.976p, or 59.94p content (or any other framerate), it must be done differently .

[chris319]

Content has to be distinguished from encoding type, and flags.

Read the O.P. That's what we're doing here — we're bypassing MediaInfo and examining the picture content directly.

A more reliable method to check a 29.97i stream for content in VLC would be to set it to "bob" or "yadif2x"

I tried both of those and on VLC the difference between interlace and progressive is indistinguishable to the eye.

If you start with 23.976p, or 59.94p content (or any other framerate), it must be done differently .

I am starting with 59.94.

Would you care to post some ffmpeg code that does it "differently"?

[Cornucopia]

"I am starting with 59.94" yet you never stated that until now.

Scott

[poisondeathray]

A more reliable method to check a 29.97i stream for content in VLC would be to set it to "bob" or "yadif2x"

I tried both of those and on VLC the difference between interlace and progressive is indistinguishable to the eye.

As I mentioned, sometimes VLC sticks or is buggy.

If it doesn't distinguish , then use something more reliable , like avisynth , or vdub, or a NLE. The concept and procedure is the same and the procedure in any program - you need to either look at individual fields (bobbing or double rate deineterlacing is essentially looking at separated, resized fields). If you just look at frames, not fields (or resized fields), you're going to make mistakes

If you apply a bob deinterlace, advancing frame by frame, true 29.97i content will yield a different frame each step (25i content will too). 29.97p will yield duplicates (25p content will too) .

If you start with 23.976p, or 59.94p content (or any other framerate), it must be done differently .

I am starting with 59.94.

Would you care to post some ffmpeg code that does it "differently"?

59.94p content has to converted to actual 29.97i interlaced content. eg. -vf interlace

https://ffmpeg.org/ffmpeg-filters.html#interlace

[chris319]

59.94p content has to converted to actual 29.97i interlaced content. eg. -vf interlace

Reread the code I posted:

ffmpeg -y  -i "C0008.MP4"  -s 1920x1080  -pix_fmt yuv422p  -vcodec mpeg2video  -vf  interlace=0,scale=out_color_matrix=bt709:out_range=limited  -flags +ilme+ildct  -r 29.97  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -acodec mp2  -f mpegts output.ts

Note where it says "-r 29.97.

As I mentioned, sometimes VLC sticks or is buggy.

The vast majority of the time VLC is stable. It's been stable the times I've tested it. Switching to "bob" or "yadif2x" didn't work. Did you actually test those VLC deinterlacers before posting? Did you test them on interlaced and progressive video? Write yourself some ffmpeg scripts and test ffmpeg's various tinterlace modes.

use something more reliable , like avisynth

Write me some avisynth or vdub code and I'll try it.

[_Al_]

Avisynth:

ffvideosource("C0008.MP4")
AssumeTFF()
Separatefields()

Vapoursynth:

import vapoursynth as vs
clip = vs.core.ffms2.Source("C0008.MP4")
clip = vs.core.std.SeparateFields(clip, tff = True)
clip.set_output()

separatefields, does what is says, it is like bob, except it does not upscales to height, it just uses fields as a frame, so height is halved. So you just manually step during movement and you exactly see what the patters is.

[poisondeathray]

59.94p content has to converted to actual 29.97i interlaced content. eg. -vf interlace

Reread the code I posted:

ffmpeg -y  -i "C0008.MP4"  -s 1920x1080  -pix_fmt yuv422p  -vcodec mpeg2video  -vf  interlace=0,scale=out_color_matrix=bt709:out_range=limited  -flags +ilme+ildct  -r 29.97  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -acodec mp2  -f mpegts output.ts

Note where it says "-r 29.97.

Yes, I did see it, but I guess should have double checked. My bad - this does work (almost) correctly. It's unexpected (at least for me); normally in ffmpeg, you'd have to use a filter to create the actual interlace content; -flags +ilme+ildct are only encoding options, they should not affect the content (ie. they are not filters). -r 29.97 should only drop frames (1/2 the motion samples, not create interlace with full motion samples of 59.94 fields/s). But I guess it's hardcoded somewhere to do it

"almost" because it looks like the chroma isn't processed correctly (interlaced chroma errors).

As I mentioned, sometimes VLC sticks or is buggy.

The vast majority of the time VLC is stable. It's been stable the times I've tested it. Switching to "bob" or "yadif2x" didn't work. Did you actually test those VLC deinterlacers before posting? Did you test them on interlaced and progressive video? Write yourself some ffmpeg scripts and test ffmpeg's various tinterlace modes.

No - I assumed VLC would just work - but I warned you that VLC can be buggy. The point is still valid that you should look at fields (or separate fields resized to frames) to diagnose content properly (assuming the program works), or you might misdiagnose some types of streams.

-vf interlace works correctly (just checked) , no chroma errors

eg for 4:2:0 59.94p , to 4:2:2 interlaced (29.97i content)

-vf format=yuv422p,interlace

use something more reliable , like avisynth

Write me some avisynth or vdub code and I'll try it.

_Al_ gave some examples for avisynth,

In vdub, video=>filters => add=> deinterlace . Select yadif , double frame rate, top field first . (Or you could use bob instead of yadif)

[chris319]

Here is option 4 for tinterlace. Does regular "interlace" work differently without using -r 29.97?

interleave_top, 4’

Interleave the upper field from odd frames with the lower field from even frames, generating a frame with unchanged height at half frame rate.

[poisondeathray]

Here is option 4 for tinterlace. Does regular "interlace" work differently without using -r 29.97?

interleave_top, 4’

Interleave the upper field from odd frames with the lower field from even frames, generating a frame with unchanged height at half frame rate.

Can you clarify what you are asking ?

I didn't use -r 29.97 for -vf interlace ; it automatically sets it correctly (e.g. 59.94p source will become 29.97i , 50p source will become 25i)

-vf format=yuv422p,tinterlace=4 works correctly too, but the quality is worse at default (in terms of interlace flicker) than -vf interlace ; it needs to be lowpassed more


https://ffmpeg.org/ffmpeg-filters.html#interlace
https://ffmpeg.org/ffmpeg-filters.html#tinterlace
It looks like -vf interlace default settings is linear lowpass and it looks proper. But tinterlace has it as an option too you can enable under the flags setting

When creating interlace, there are some basic guides . There should be some old ones . Basically you cannot use thin text, thin lines. "Sharp" is worse than "blurry" for interlace in production. Everything almost always has to be lowpassed (basically a vertical blur to filter out higher frequencies)

[chris319]

I've answered my own question.

-vf interlace=1 enables lowpass filtering as you suggested and cuts the frame rate to 29.97. I don't know why you're worrying about frame rate when -vf interlace takes care of it. Anyone who takes the trouble to test this stuff finds this out.

-vf interlace=1 gives BFF.

[poisondeathray]

I've answered my own question.

-vf interlace=1 enables lowpass filtering as you suggested and cuts the frame rate to 29.97. I don't know why you're worrying about frame rate when -vf interlace takes care of it.

I'm not "worrying" about the frame rate. I told you I didn't even include it and it automatically sets it properly. You're the one that asked about it - you phrased as a question " Does regular "interlace" work differently without using -r 29.97?"

Anyone who takes the trouble to test this stuff finds this out.

Yes

-vf interlace=1 gives BFF.

TFF

[chris319]

-vf  tinterlace=4:vlpf

... gives TFF with lowpass filtering at 29.97.

[chris319]

I'm not "worrying" about the frame rate.

59.94p content has to converted to actual 29.97i interlaced content.

If you start with 23.976p, or 59.94p content (or any other framerate), it must be done differently .

Those are your words, my friend. You were the first to mention frame rate in this thread.

TFF

Run the code. MediaInfo clearly says BFF.

You would do well to test these assertions before you post them.

[poisondeathray]

I'm not "worrying" about the frame rate.

59.94p content has to converted to actual 29.97i interlaced content.

If you start with 23.976p, or 59.94p content (or any other framerate), it must be done differently .

Those are your words, my friend. You were the first to mention frame rate in this thread.

You're reading the posts out of order. That referring to the 1st post ; not your recent line of question about tinterlace and interlace. You didn't even use interlace=1 or tinterlace=4 in the 1st post ...

TFF

Run the code. MediaInfo clearly says BFF.

You would do well to test these assertions before you post them.

It even says TFF in the documentation by default

scan

This determines whether the interlaced frame is taken from the even (tff - default) or odd (bff) lines of the progressive frame.

I did. Maybe you probably didn't do it properly, or encode it properly ? or set the flags incorrectly ?

And HD is supposed to be TFF by convention anyways

[chris319]

VirtualDub can't open an .mp4 file.

Great.

[poisondeathray]

You can try vdub2

[chris319]

Here is the script. You tell me what's wrong.

NOTE that it uses interlace and not tinterlace.

ffmpeg -y  -i "C0008.MP4"  -s 1920x1080  -pix_fmt yuv422p  -vcodec mpeg2video  -vf  interlace=1,scale=out_color_matrix=bt709:out_range=limited  -flags +ilme+ildct  -r 29.97  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -acodec mp2  -f mpegts output.ts

[poisondeathray]

Here is the script. You tell me what's wrong.

NOTE that it uses interlace and not tinterlace.

ffmpeg -y  -i "C0008.MP4"  -s 1920x1080  -pix_fmt yuv422p  -vcodec mpeg2video  -vf  interlace=1,scale=out_color_matrix=bt709:out_range=limited  -flags +ilme+ildct  -r 29.97  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -acodec mp2  -f mpegts output.ts

I don't have "C0008.MP4" , but testing on another 1080p59.94 source, that looks like it produces chroma errors, BFF content, and flagged BFF . (interlaced HD is supposed to be TFF by convention) . For testing purposes I added -q:v 2 to increase the video bitrate- I don't want to confuse code issues with encoding artifacts

The code I posted above in post #12 does it correctly, TFF, no chroma errors, at least on my test source. There might be other issues with your source that are contributing

[poisondeathray]

OK I'm wrong again in my assumptions . My bad. You did have it right in the 1st post for the interlace=0 part . So it had nothing to do with -flags

Interlace=0 is an actually analog for interlace=scan=0 or TFF . interlace=1 actually means interlace=scan=1 or BFF

I assumed incorrectly that "0" was toggle off, "1" was toggle on


For the chroma errors - when you specify -pix_fmt separately out of the linear filter chain, it upsamples 4:2:0 to 4:2:2 in an interlaced fashion, but it's still progressive, so you get the chroma upsampling errors , if you specify it within the same linear filter chain, you have control over how it's done in order. 4:2:0 to 4:2:2 while still progressive, then apply the interlace filter.

[chris319]

When I write a VideoDub2 script, what is the file extension supposed to be?

Please test this script and see if it passes muster with you. It has been modified per your suggestion. Will the video be lowpass filtered?

ffmpeg -y  -i "C0008.MP4"  -s 1920x1080 -vcodec mpeg2video  -vf  tinterlace=4:vlpf,format=yuv422p,interlace,scale=out_color_matrix=bt709:out_range=limited  -flags +ilme+ildct  -r 29.97  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -acodec mp2  -f mpegts output.ts

[poisondeathray]

When I write a VideoDub2 script, what is the file extension supposed to be?

Please test this script and see if it passes muster with you. It has been modified per your suggestion.

ffmpeg -y  -i "C0008.MP4"  -s 1920x1080 -vcodec mpeg2video  -vf  tinterlace=4:vlpf,format=yuv422p,interlace,scale=out_color_matrix=bt709:out_range=limited  -flags +ilme+ildct  -r 29.97  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -acodec mp2  -f mpegts output.ts

I don't see the logic there - you have both tinterlace and interlace ? Normally you would use one or the other
-s 1920x1080 will be redundant if the source is 1920x1080

But I check it and it's definitely messed up

Post 12 works , I verified it earlier . Tested encoding to both AVC , and MPEG2

-vf format=yuv422p,interlace

(and "interlace" by itself is really interlace=scan=0 or TFF)

You can add everything else back . I took, out -r and -s because they are redundant

ffmpeg -y  -i "C0008.MP4" -vcodec mpeg2video  -vf  format=yuv422p,interlace,scale=out_color_matrix=bt709:out_range=limited  -flags +ilme+ildct color_primaries bt709  -color_trc bt709  -colorspace bt709  -acodec mp2  -f mpegts output.ts

If there is something "different" about your MP4, sometimes FFMpeg will take the flags or metadata and react slightly differently. I'm assuming it's normal, progressive, flagged progressive, normal range, sar undefined or 1:1 , etc... or you might have to override something

[poisondeathray]

And "interlace" vs. "tinterlace=4:vlpf" produce bit identical results

[poisondeathray]

And what was the reason for scale=out_color_matrix=bt709ut_range=limited ? I'm asking because that might be affected depending on where you place it in the filter chain. A "normal" YUV video should not require that

[chris319]

Oops! Too many interlace things.

ffmpeg -y  -i "C0008.MP4"  -s 1920x1080 -vcodec mpeg2video  -vf  format=yuv422p,interlace,scale=out_color_matrix=bt709:out_range=limited  -flags +ilme+ildct  -r 29.97  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -acodec mp2  -f mpegts output.ts

[poisondeathray]

In general, progressive processing (while you're still at 59.94p) , is better. For everything. So if you're scaling, color work, filters , doing any sort of manipulations etc.. you have all the pixel data to work with. Interlace discards 1/2 the spatial data. It also has restrictions on how you do certain operations

So if you have reasons for keeping those in (scale=out_color_matrix=bt709ut_range=limited), I can't see any harm in moving -vf interlace to the very end of the chain, it's probably safer anyways. Basically do everything else first while progressive, and interlace it at the end

-vf  format=yuv422p,scale=out_color_matrix=bt709:out_range=limited,interlace