VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or Try ConvertXtoDVD and convert all your movies to DVD. Free trial ! :)
+ Reply to Thread
Page 1 of 3
1 2 3 LastLast
Results 1 to 30 of 71
Thread
  1. 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.

    Code:
    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.
    Quote Quote  
  2. Originally Posted by chris319 View Post
    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.
    Quote Quote  
  3. 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.
    Quote Quote  
  4. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    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
    Quote Quote  
  5. 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.
    Quote Quote  
  6. Originally Posted by chris319 View Post

    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.

    Code:
    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 .
    Quote Quote  
  7. 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"?
    Quote Quote  
  8. Member Cornucopia's Avatar
    Join Date
    Oct 2001
    Location
    Deep in the Heart of Texas
    Search PM
    "I am starting with 59.94" yet you never stated that until now.

    Scott
    Quote Quote  
  9. Originally Posted by chris319 View Post

    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
    Quote Quote  
  10. 59.94p content has to converted to actual 29.97i interlaced content. eg. -vf interlace
    Reread the code I posted:

    Code:
    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.
    Quote Quote  
  11. Avisynth:
    Code:
    ffvideosource("C0008.MP4")
    AssumeTFF()
    Separatefields()
    Vapoursynth:
    Code:
    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.
    Last edited by _Al_; 27th Jun 2019 at 19:17.
    Quote Quote  
  12. Originally Posted by chris319 View Post
    59.94p content has to converted to actual 29.97i interlaced content. eg. -vf interlace
    Reread the code I posted:

    Code:
    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)
    Code:
    -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)
    Quote Quote  
  13. 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.
    Quote Quote  
  14. Originally Posted by chris319 View Post
    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)
    Quote Quote  
  15. 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.
    Quote Quote  
  16. Originally Posted by chris319 View Post
    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
    Quote Quote  
  17. Code:
    -vf  tinterlace=4:vlpf
    ... gives TFF with lowpass filtering at 29.97.
    Quote Quote  
  18. 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.
    Quote Quote  
  19. Originally Posted by chris319 View Post
    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
    Quote Quote  
  20. VirtualDub can't open an .mp4 file.

    Great.
    Quote Quote  
  21. You can try vdub2
    Quote Quote  
  22. Here is the script. You tell me what's wrong.

    NOTE that it uses interlace and not tinterlace.

    Code:
    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
    Quote Quote  
  23. Originally Posted by chris319 View Post
    Here is the script. You tell me what's wrong.

    NOTE that it uses interlace and not tinterlace.

    Code:
    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
    Quote Quote  
  24. 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.
    Quote Quote  
  25. 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?

    Code:
    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
    Last edited by chris319; 27th Jun 2019 at 23:08.
    Quote Quote  
  26. Originally Posted by chris319 View Post
    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.

    Code:
    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
    Code:
    -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

    Code:
    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
    Quote Quote  
  27. And "interlace" vs. "tinterlace=4:vlpf" produce bit identical results
    Quote Quote  
  28. 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
    Quote Quote  
  29. Oops! Too many interlace things.

    Code:
    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
    Quote Quote  
  30. 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

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



Similar Threads