De-interlacing 30p/60i AVCHD from Panasonic G7

[adamskr]

On my Panasonic G7, I sometimes record for long periods of time in AVCHD. In the recording quality it is called '1920x1080,60i Image Sensor Output 30p'. From reading on the internet, this is just 30p but saved as 60i to be compliant with AVCHD specifications. However, I have been struggling with editing and using these clips.
From what I've read, if it is just 30p but marked as 60i, then there shouldn't be any de-interlacing needed. However, when I play the video without de-interlacing there are clear field lines.
I know it is definitely not true interlaced video, because when I play frame by frame with VLC on Bob de-interlacing, I essentially just get each frame repeated. What would be the correct de-interlacing method to use, in order to not lose any vertical resolution, while keeping it at the 29.970fps it is recording at?
I've attached a short test clip to show what I mean.
Many thanks

[poisondeathray]

Yes, it's 29.97p content , but field shifted

You could use avisynth and field match with TFM() . Basically that aligns each field with it's corresponding field pair, so you get back the original progressive image in full resolution

What editor are you using ? Most commercial NLE's will not handle this properly

[_Al_]

in Vapoursynth you can cut off first field and then weave it again like this:

import vapoursynth as vs
clip = vs.core.lsmas.LWLibavSource(r'F:/00014.MTS')
clip = vs.core.std.SeparateFields(clip)
clip = clip[1:-1] #cuts off first frame and last frame (as a fields now)   ,  [1:-1] means: [select second frame : to the end-1 frame]
clip = vs.core.std.DoubleWeave(clip)[::2] #DoubleWeave fields into a frame again and get every other frame ,   [::2] means: [first frame: last frame: step is 2]
#output is progressive 29.97p
clip.set_output()

so if using avisynth this might work as well

[Sharc]

It's fieldshifted video to make it compliant with playback devices which request the 'interlaced' structure.
For restoring the progressive frames you can do fieldmatching in Avisynth:

AssumeTFF()
TFM()

It gives 29.97p progressive frames. Assuming that your player or editor is compliant with this format.

Edit:
oopps, I was late.....

[adamskr]

Thanks for the great help so far. What I don't understand, is how does this differ from the standard 'PsF' system which shouldn't need de-interlacing - is it just a matter of the field order?
My main video editing software is DaVinci Resolve (Studio), but I occasionally use Vegas Pro. It would be great if this could be fixed with something like an OpenFX plugin, as there isn't really any way to run an Avisyth script in an NLE . So I guess I either need to process every video with the script first (and lose time and some quality in the process), or just rely on Resolve's native deinterlace setting (whatever algorithm that uses).

[poisondeathray]

Thanks for the great help so far. What I don't understand, is how does this differ from the standard 'PsF' system which shouldn't need de-interlacing - is it just a matter of the field order?
My main video editing software is DaVinci Resolve (Studio), but I occasionally use Vegas Pro. It would be great if this could be fixed with something like an OpenFX plugin, as there isn't really any way to run an Avisyth script in an NLE . So I guess I either need to process every video with the script first (and lose time and some quality in the process), or just rely on Resolve's native deinterlace setting (whatever algorithm that uses).

The difference is the field alignment

PsF would look like

Aa / Bb / Cc / Dd

Field shifting looks like

aB / bC / cD / dE

Where capital letter is "top" field, lower case letter is "bottom" field.



Although vegas can handle AVC transport streams, Resolve does not "like" AVC transport streams, so you'd have to re-encode if using Resolve anyways

Another option would be ffmpeg using -vf fieldmatch . You could batch encode your source files to an intermediate. If you use a high bitrate or near lossless intermediate it should work for either without any significant quality loss .

[_Al_]

Overall , this is not the way how to make a video footage if that Panasonic does it all the time, or even sometimes, you'd need to go thru this trouble all the time or at least check it. I would not use that mode.

[manono]

So I guess I either need to process every video with the script first (and lose time and some quality in the process), or just rely on Resolve's native deinterlace setting (whatever algorithm that uses).

Time, yes; quality, no. Save it as a lossless AVI. There's no destructive deinterlacing involved as TFM is just realigning the fields.

It's your camera. I agree with _Al_. You either find a way to record without the field-shifting or get another camera, or learn to live with it.

[adamskr]

The difference is the field alignment

PsF would look like

Aa / Bb / Cc / Dd

Field shifting looks like

aB / bC / cD / dE

Where capital letter is "top" field, lower case letter is "bottom" field.

Thank you, this makes a lot more sense! That explains why Bob deinterlacing has the first frame single instead of doubled like the rest

Although vegas can handle AVC transport streams, Resolve does not "like" AVC transport streams, so you'd have to re-encode if using Resolve anyways

From my experience over the last few years, it's got better and better. I remember when I first started using it on version 12.5, it really didn't like AVC but it has got better and no longer requires re-encoding as much.

Overall , this is not the way how to make a video footage if that Panasonic does it all the time, or even sometimes, you'd need to go thru this trouble all the time or at least check it. I would not use that mode.

I completely agree with you, to be honest I didn't really realise that it worked like this until recently. Unfortunately the camera allows continuous recording over 29 minutes in the AVCHD mode only, and sometimes decides that the card is full in MP4 when it really isn't, but allows further recording in AVCHD.

I think I'll re-encode to ProRes or DNxHR with FFMPEG in this case, I'll have to think about what I'll do in the future, probably have to live with the problem.