Bad interlace artefacts in a video. Can it be fixed?

[Srivas]

Hi everyone!

I have a dvd source that is badly interlaced. Need to prepare it for youtube. I tried QTGMC for deinterlacing and the results are pretty ok for static scenes, but any movement is still visibly jaggy. Is there any way to fix it or improve it? I will add a clip. Any help is very much appreciated!

It's PAL 25, BFF, 720x576

[Sharc]

Your source is TFF, not BFF.
Insert AssumeTFF() in your script before QTGMC().

[Alwyn]

Interesting, definitely TFF, but Mediainfo says it's BFF. You can't believe everything you read!

[Sharc]

Interesting, definitely TFF, but Mediainfo says it's BFF.

Wrongly flagged it seems. Field order is reported as unknown by ffprobe (?), and Mediainfo assumed BFF. Typical for .avi sources btw.

Edit: and here the report from ffmpeg:

 Stream #0:0(und): Video: wrapped_avframe, yuv420p(tv, bottom coded first (swapped)), 720x576 [SAR 64:45 DAR 16:9], q=2-31, 200 kb/s, 25 fps, 25 tbn (default)
    Metadata:
      handler_name    : VideoHandler
      vendor_id       : [0][0][0][0]
      encoder         : Lavc60.3.100 wrapped_avframe
frame=  100 fps=0.0 q=-0.0 Lsize=N/A time=00:00:03.96 bitrate=N/A speed=59.2x    0x
video:47kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
[Parsed_idet_0 @ 000002b5e0dfbf00] Repeated Fields: Neither:   101 Top:     0 Bottom:     0
[Parsed_idet_0 @ 000002b5e0dfbf00] Single frame detection: TFF:    90 BFF:     0 Progressive:     0 Undetermined:    11
[Parsed_idet_0 @ 000002b5e0dfbf00] Multi frame detection: TFF:    90 BFF:     0 Progressive:     0 Undetermined:    11

You can't believe everything you read!

Rule #1.

[Alwyn]

Typical for .avi sources btw.

It's from a DVD. I see VideoRedo also reports it as BFF, and it looks like VRD encoded it according to VDub.

MPEG 2 in an MP4 container... a bit of a mess.

[Sharc]

... and Mediainfo does get VHS-capture AVIs right (TFF).

Not my experience with huffyuv captures. I don't think that native .avi captures are flagged, maybe depending on the codec though. There are posts about this if I remember correctly.
If one wants to be on the safe side one should explicitly specify TFF or BFF for the decoder.

[lollo]

Not my experience with huffyuv captures.

Same here.

Mediainfo just reads what is written in the specific patterns (which can be false), or makes assumptions; it does not analyze the video. Any source should be checked manually!

[Alwyn]

@Sharc, I've never had a BFF analogue capture with 5 different cards over 3tb of captures.

@Srivas, you say you used QTGMC, but VDub and Mediainfo are reporting that sample MP4 as coming from VideoRedo. Is that correct? If so, you need to go into Profile options, set the codec to H264 and deinterlacing to Auto. Then you'll get a progressive H264 MP4. It appears that you are currently just choosing "MP4" in the profile list and doing nothing else.

Why your original MPEG/VOB field order is being reported incorrectly is a mystery, because VRD cannot change it, as far as I can see.

In any case, you now know what the issue is and you have a couple of solutions; set up QTGMC as per Sharc's point or use VRD as I suggest above.

[Sharc]

@Sharc, I've never had a BFF analogue capture with 5 different cards over 3tb of captures.

Lucky you, especially when Mediainfo reported it correctly
My PAL .avi captures are TFF as well, but MediaInfo doesn't even report the field order, and other analysis tools report it wrongly as BFF.....
Therefore I always do the test myself.
As I understand it, a VHS tape is captured field by field by field ..... it's a sequence of fields, and VHS doesn't have a "field order" like TFF or BFF. Top and bottom fields are assigned (and become relevant) only when the SW combines (weaves) the fields to interlaced frames (framebased). 480i frames (aka NTSC) are normally BFF, while 576i frames (aka PAL) are normally TFF, but the classic avi container has no provision to flag the field parity AFAIK (or perhaps as a normally unused option only introduced in some later revision, I don't really know). Hence a tool like MediaInfo can make a best guess based on vertical resolution only, or a more sophisticated tool could analyze a longer sequence of frames and estimate the field parity based on motion, similar what we do when inspecting the fields manually.

Bottom line: As much can go wrong, always do the test yourself with interlaced footage.

[Alwyn]

@Srivas, and, in case you're wondering how to check the field order, open the file in Virtual Dub, go Video>Filters>add, and from the list double-click on deinterlace.

Then click the radio buttons for "Interpolate using Yadif", and "Double Frame Rate, Top Field First".

Click OK twice to get back to the main screen, make sure you're looking at the Output pane and step through each frame which as movement. If you see back and forth movement, you've chosen the wrong field order. It will be obvious.

[Alwyn]

@Sharc, I have revised my earlier post. Let's stay on topic now.

[johnmeyer]

The first thing I do with any video someone sends to me (i.e., video that someone else has captured or worked with) is to view it through a one-line "separatefields()" AVISynth script to determine field order. I even do this for video which is supposedly progressive.

It is absolutely amazing how often field order gets screwed up no only because it was captured poorly, but because of the lack of knowledge in those who have previously worked on the video. What's more, the field problems are, unfortunately, usually a lot more difficult to deal with than merely doing an AssumeTFF() or bottom field statement.

[lollo]

We all agree on that, John. To really understand the nature of the source, a manual operation with AviSynth is needed.

In addition to the problems caused by poor captures or post-processing you mentioned, also material broadcasted by TVs are sometime messy in the field/frame architecture

[pandy]

In fact erroneous field dominance is quite common in broadcasting nowadays - frequently broadcast infrastructure is fixed on particular field dominance (like TFF) but source material is feed as opposite (for example as BFF from other area) - in Europe where traditionally TFF is used frequently advertisements created for US market (worldwide products such as games) are broadcasted with incorrect (swapped) field dominance.

Media info is another factor of problems - frequently information returned by Mediainfo is incorrect - as others already expressed - only eyes and perhaps motion detection tool can detect proper field dominance.

[johnmeyer]

In fact erroneous field dominance is quite common in broadcasting nowadays ...

I used to see this all the time, but haven't seen it for 3-4 years. It was very common during news broadcasts and, I assume, happened because they were taking video from dozens of sources, all with differing equipment and, because of deadlines, just simply put the video on the timeline, cut it, and then put it on the air. The result was -- as those who know what it looks like -- "vibrating" video during fast motions or pans.

My guess is that Avid, or whatever editing system most news stations use, added a feature that automatically does the field dominance test and makes the correction so the editor doesn't have to deal with it.

[Srivas]

And don't trust Mediainfo! Another good tip I learned.

[Srivas]

Thank you all for your elaborate input on this matter. My God, I missed the whole thread! I was waiting for a notification on my e-mail as usual and it always worked before. Not this time.) I became suspicious and checked the site myself to find out that all this input waiting for me.)

Anyway, the thing is that AssumeTFF() is the first thing I tried, BUT since I resized the source in NLE before the script it got screwed up anyway and I didn't have the brain to just try it directly on the source.

@Alwyn and @johnmeyer, that you for the tip for checking the field order, I was wondering how to do that.

I use VideoReDo to cut a clip without re-encoding, otherwise I work in Vegas Pro 14 for editing, then frameserve to Avisynth for QTGMC and use MeGui to run the script and for encoding.

It leads to another question that I want to understand. I do the editing in Vegas and resizing there is just practical for me, especially when it has to be keyframed to smoothen out camera jolts, bad panning,zooming etc. So in the case of interlaced materials should I first make it progressive, run a lossless encoding, and then do the rest of the editing in a second pass? Like how do you do that?

[Cornucopia]

That's not a good tip. Rather: understand MediaInfo's weaknesses/constraints, and have workarounds for them. Most of the time, MediaInfo is a great info resource.

Scott

[_Al_]

Not sure why everyone hates mediainfo for reading a label. It is not an analyzing tool.
edit: ok posted video is not avi

So question is: What is field order for actual DVD's VOB?

[johnmeyer]

Not sure why everyone hates mediainfo for reading a label. It is not an analyzing tool.
edit: ok posted video is not avi

So question is: What is field order for actual DVD's VOB?

I don't think anyone hates Mediainfo. It is a great tool. However, field order often has nothing to do with the field order flag. That is why, IMHO, you must always check the actual field order using the method I described.

As to field order on DVDs, it can be either upper or lower (i.e., TFF or BFF). I live in NTSC land and most DVDs are lower field first. Until HD arrived, I made all my DVDs lower field first.

However, I then found that my NLE (Vegas) had a nasty bug when you encoded MPEG-2 (for making a DVD) from HD source material. This was before we had 60p (progressive) HD, and most HD was interlaced. Interlaced NTSC HD from a camcorder is almost always top field first. Vegas had a bug that caused a tremendous amount of detail to be lost if you encoded bottom field first from that material. One of the longer threads I ever started over the in the old Sony Vegas forum was about that problem.

Point of the story: DVD field order can be either top or bottom; you always have to test to make sure before you proceed to do something with the video, other than just play it.

The simple workaround I eventually figured out was to simply encode the MPEG-2 for the DVD as top field first. The DVD player doesn't care and the set doesn't care. So for the next decade, all my DVDs that I created from my HD camcorders were always top field first.