According to poisondeathray, Mediainfo is unreliable for determining if video is interlaced or progressive because it only looks at the metadata tags rather than analyze the video. pdr recommended to load the video in a player that doesn't do any de-interlacing (bob, etc.) to look for combing artifacts during scenes with movement. Therefore I am wondering if this method works:
Frameserve video mpeg or mts source file via Avisynth into VirtualDub and look for combing.
Code:DirectShowSource("input.mpeg")Is this a reliable method?Code:DirectShowSource("input.MTS")
+ Reply to Thread
Results 1 to 11 of 11
The flag will only tell you how the video was encoded (assuming the encoder does a good job) it won't tell you whether the video was originally encoded progressive or deinterlaced at an earlier stage.
Just viewing it in a non deinterlacing player isn't perfect either; You can get cases where you will see combing, yet the video has progressive content. An example of that is "field shifting" . That is why examining individual fields is usually the most accurate way. There can be bizarre cadences and patterns that are more easily examined while in fields
If you're not necessarily needing to use VirtualDub, MeGUI might help make the process a little easier.
If you use the File/Open menu to open an mpeg file, MeGUI should offer to index it for you and extract the audio. Add the job to the queue and run it. When it's finished the Avisynth script creator will open with a preview allowing you to step back and forth between frames to your heart's content. You can also use the script creator to apply various types of de-interlacing and pulldown removal etc and preview the result (MeGUI will also analyse the video for you and offer an opinion but don't take the result as gospel). It might allow you to experiment a little more easily, and if you get stuck and can't work out what the best way to de-interlace might be, do what I do and post a small sample here.
I should have been more explicit that I am working only with original video shot by parents of my son's marching band. None of the video has been subjected to de-interlacing scripts. I am unable to say to the parent, however, "Is this video interlaced or progressive?" Their knowledge of such is non-existent. It is up to me to interrogate the video but Mediainfo is unreliable
Thank for all the suggestions. I had no idea that determining whether video was interlaced or progressive was so challenging. From what I can see there are a couple of methods:
- DGIndex/Avisynth/Virtualdub on mpeg2 sources
- MeGUI/Avisynth on mpeg2 and mpeg4 sources
Here is what I found:
- I tried DGIndex/Avisynth/Virtualdub on my HDV video that I know is progressive and was able to see the aa bb cc dd ee cadence. So that was good. I was not able to load my mpeg4 video.
- I moved on to the MeGUI approach. It was a little strange though as the Avisynth previewer seemed to really struggle decoding the video at various parts.
Here is a small screen shot with 1:1 pixel mapping of what I think looks like obvious combing due to interlaced content. Note that the red flags are moving really fast in the image.
Here is a screenshot from the MeGUI approach of my HDV progressive content that is blurred but no combing. It also had the aa bb cc dd ee cadence in DGIndex/Virtualdub. I should also add that the image looks stretched because the pixels are not square.
Thanks for all the help everyone. Let me know if I am missing anything.
What NLE are you using to combine the clips? Any of the halfway decent ones can handle interlacing ...halfway decently. In Premiere, for example, you can try different interpretations of the source footage and see which is best.
AVCHD can be a bit tricky to open in avisynth. DGAVCIndex (the AVC counterpart similar to DGIndex) has problems with PAFF streams (interlaced) and decoding. FFMS2 and L-Smash can have problems on some streams as well . If you a compatible Nvidia card, DG NV Tools is the preferred way to go for AVCHD streams (donationware)
Besides interlaced , and native progressive - beware some consumer camcorders (both AVCHD and HDV) have another mode of "24p" which isn't native progressive (although some newer models can shoot 24pN native). It is encoded interlaced 59.94 fields per second but has 3:2 hard pulldown . (You can think of it as "24p in 59.94i")
The one case where it's always wrong for consumer camcorders is the "24p in 59.94 fields/s " case . In canon camcorders it's the 24 pF mode. To mediainfo, it will look exactly the same as interlaced 59.94 fields/s . They shouldn't be using that mode for those types of events, but it sounds like he's getting footage from a bunch of parents/makes/models of cameras and they might not know any better.
1. Every time someone uses DirectShowSource without proving that all native AviSynth plugins have failed, ... dunno, I'm atheist. But imagine, if you don't know how to keep your selection of installed DirectShow filters clean, then don't be surprised that you get filtered video in the least possible quality, e.g. already blend-deinterlaced, instead of the exact decoder result, maybe even skipped frames.
poisondeathray gave good recommendations (DGDecNV/DGDecIM or L-SMASH Source/FFMS2* are often useful and recommendable).
*The most recent builds got rid of the Haali splitter and own Matroska splitter, and implemented libav Filters; still, remultiplexing to MKV with mkvmerge(GUI) first is worth a try in case opening original files fails.
2. MediaInfo will only report how the encoder was set up, but cannot analyze which kind of material it encoded. There are even cameras which switch to progressive recording mode in low exposure scenes, but don't encode in progressive AVC encoding mode. Don't trust in header fields. Always look at the video. Watch the clip field-wise, slowly, step by step:
# use a decoder-exact *Source plugin AssumeTFF() # or AssumeBFF(), try both alternatively Bob()
- motion-still-motion-still-motion-still... = progressive: enjoy
- motion-motion-motion-motion... = interlaced, correct field order: deinterlace
- forward-backward-forward-backward... = interlaced, wrong field order: deinterlace with the other field order
- motion-still-motion-still-still (2:3) ... = Telecine: IVTC
- clean...ghost...blend...ghost...clean... = complicated: pray that SRestore may help
scharfis_brain wrote a very comprehensive documentation about different interlacing methods (the good, the bad, the ugly...).
German original: exotisches Interlacing
english translation by StainlessS
Last edited by LigH.de; 9th Mar 2015 at 03:32.