Weird de-interlacing consequence

[Marcoh_]

Hey there,
a couple of weeks ago I went to a concert in my town and filmed some minutes of footage with my (not so) good old camera. I set 1080-60i, but when I checked the files on my pc, I noticed with mediainfo something strange:

Frame rate: 59,940 (60000/1001) fps
Original frame rate: 29,970 (30000/1001) fps
Tipo scansione: Interlaced
Ordine scansione: Top field first

As soon as I try to deinterlace with AviSynth (with QTGMC), I get a strange accelerated clip.
Is anyone able to suggest me the proper way to deinterlace those clips?

Here's one of the raw clips, in order to let you try: https://mega.nz/#!Qw5wxJYb!x5aBXIgusb8N09mRLCFvYoLtEsmd5gN5Lk8lgRN4Xk8
Thanks a lot.

[johnmeyer]

The file you uploaded is progressive, not interlaced.

[jagabo]

Some cameras indicate the field rate instead of the frame rate (MediaInfo and many other programs don't understand this). The video is really 29.97p with fields stored out of phase. Use TFM instead of QTGMC.

LSmashVideoSource("08 - Eclipse [1].MP4") 
AssumeTFF()
AssumeFPS(30000,1001)
TFM()

Note also that the video is full range YUV, not the normal limited range.

[pandy]

The file you uploaded is progressive, not interlaced.

Are you sure? Downloaded sample is interlaced...

[jagabo]

The file you uploaded is progressive, not interlaced.

Are you sure? Downloaded sample is interlaced...

It's interlaced but the underlying video is 29.97p.

[johnmeyer]

The file you uploaded is progressive, not interlaced.

Are you sure? Downloaded sample is interlaced...

Jagabo is correct when he says "It's interlaced but the underlying video is 29.97p." The video is definitely progressive.

This video once again illustrates that you cannot rely, ever, on the interlaced flags, or on what Mediainfo reports. The only way to determine what is going on with fields in a video is to run it through a one-line "separatefields()" AVISynth script and look at the results. I did that for this video, and there is absolutely no temporal difference between fields.

Thus, applying QTGMC is a complete waste of time and effort, unless you want to use its denoising. If you want to denoise with QTGMC (there are better ways to denoise), you would have to, for this video, use settings which completely turn off the deinterlacing.

[Marcoh_]

Thus, applying QTGMC is a complete waste of time and effort, unless you want to use its denoising. If you want to denoise with QTGMC (there are better ways to denoise), you would have to, for this video, use settings which completely turn off the deinterlacing.

It worked, thanks a lot to everyone.
Should mvtools (or something like that) work in order to clean this footage up?

Thanks again.

[johnmeyer]

What improvements are you trying to make? It is too dark to make it look normally exposed. There is virtually no detail in the video. The only thing that could be fixed is the shakiness. For that, try Deshaker.

[Marcoh_]

Yes, I know the source footage is really far from being good. Thanks again for all your tips.

[Mano Bakker]

No problem. I Downloaded the mp4 file . Played it in MPC HC and no interlace problems to see... so only the webplayer shows it.

Try to reder it as progressive (@59.94p) . Every field to a frame.

Grtz Mano

[Sharc]

The file you uploaded is progressive, not interlaced.

Are you sure? Downloaded sample is interlaced...

Jagabo is correct when he says "It's interlaced but the underlying video is 29.97p." The video is definitely progressive.

This video once again illustrates that you cannot rely, ever, on the interlaced flags, or on what Mediainfo reports. The only way to determine what is going on with fields in a video is to run it through a one-line "separatefields()" AVISynth script and look at the results. I did that for this video, and there is absolutely no temporal difference between fields.

In order to be compliant with the Blu-Ray standard progressive footage 1920x1080 has to be encoded or flagged as interlaced for 29.97fps. The flagging of progressive video as interlaced is often referred to as "fake-interlaced". So there is nothing unusual with the sample. It has just been encoded as a Blu-Ray compliant format.

[Marcoh_]

Note also that the video is full range YUV, not the normal limited range.

Really sorry to return to the subject once again, but I noticed another little issue.
I load the footage into AviSynth and after the trick you suggested above (TFF), I render the footage to uncompressed AVI in order to edit in Sony Vegas (without touching the colour range). But the .avi footage turns to be rather darker than the original source footage. Is that a matter of range?

Can anybody help me? And would you suggest me which colour range is the best choice to render the footage with x264? Thanks a lot again for your patience

[jagabo]

Note also that the video is full range YUV, not the normal limited range.

Really sorry to return to the subject once again, but I noticed another little issue.
I load the footage into AviSynth and after the trick you suggested above (TFF), I render the footage to uncompressed AVI in order to edit in Sony Vegas (without touching the colour range). But the .avi footage turns to be rather darker than the original source footage. Is that a matter of range?

Probably. I don't use Vegas but I know it's pretty schizophrenic with levels. Since you're using AviSynth add ColorYUV(levels="PC->TV"). That will reduce range from full to limited.

And would you suggest me which colour range is the best choice to render the footage with x264?

The standard for all commercial distribution formats (Blu-ray, DVD), youtube, etc. is limited range YUV; Y from 16 to 235, U and V from 16 to 240.