Converting wrongly captured 59.94fps to 29.97fps

[waxstone]

As described in this post: https://forum.videohelp.com/threads/418048-Capturing-via-GV-USB2-in-correct-frame-rate...nd#post2772269

I'm trying to make sure that my raw captures are suitable for encoding.

My current setup is: Japanese VCR -> GV-USB2 -> Amarec

I reinstalled GV-USB2 drivers (after device issues) and now the correct frame rate option doesn't appear in Amarec, it shows 59.94 fps rather than 29.94. (All interlaced captures). I now have a workaround for this (manually entering in the correct frame rate into the box).

As a result I have captured 3TB of 50+ hours of footage in the wrong frame rate. Recapturing everything correctly will take a lot of time. Prior to this, all was captured fine in 29.94. Something happened inbetween.

Is there a way I can convert this existing 59.94 interlaced to 29.97 interlaced? This would save me from recapturing.

In terms end goal, I want all my footage to be converted to 59.94 to achieve that buttery smooth look. Another issue I'm struggling with is encoding workflow: https://forum.videohelp.com/threads/417773-Best-Hybrid-settings-for-encoding-broadcast-vhs-captures

(I generally just want to convert my captures to 59.94, soft noise reduction, correct aspect ratio, compressed to reduce space).

[jagabo]

If the software converted by duplicating each frame -- you can simply discard every other frame to convert back to 29.97 fps. Post a short sample for analysis.

[waxstone]

If the software converted by duplicating each frame -- you can simply discard every other frame to convert back to 29.97 fps. Post a short sample for analysis.

Please see attached sample, apologies for the size

[jagabo]

Your device/software captured at 59.94 frames per second by pairing fields but also duplicating fields:

01  12  23  34  45  56  67...

Each digit is a field and the number represents the original field number.

You can simply discard every other frame to get a proper 29.97 fps interlaced file. Either:

01  23  45  67...

In AviSynth that would be

AviSource("Sample59.94fps.avi")
SelectEven()
AssumeTFF()

Also, why is your video uncompressed RGB? It should have been captured as YUV 4:2:2. By converting to RGB you have crushed the brights (irretrievably blowing them out), and maybe the darks too. Maybe this was from the way you prepared the sample and the original is YUV?

[waxstone]

Your device/software captured at 59.94 frames per second by pairing fields but also duplicating fields:

01  12  23  34  45  56  67...

Each digit is a field and the number represents the original field number.

You can simply discard every other frame to get a proper 29.97 fps interlaced file. Either:

01  23  45  67...

In AviSynth that would be

AviSource("Sample59.94fps.avi")
SelectEven()
AssumeTFF()

Thanks very much I'll have a go at this

Also, why is your video uncompressed RGB? It should have been captured as YUV 4:2:2. By converting to RGB you have crushed the brights (irretrievably blowing them out), and maybe the darks too. Maybe this was from the way you prepared the sample and the original is YUV?

I used Virtualdub incorrectly to produce the sample. Please see attached new sample using Avidemux

[jagabo]

Good, you captured correctly as YUV 4:2:2. You can get a little more detail in the brights with something like ColorYUV(gain_y=-20).

[waxstone]

Good, you captured correctly as YUV 4:2:2. You can get a little more detail in the brights with something like ColorYUV(gain_y=-20).

Does it look like the script worked its magic? After this, hoping to deinterlace to 59.94fps.

[Sharc]

Good, you captured correctly as YUV 4:2:2. You can get a little more detail in the brights with something like ColorYUV(gain_y=-20).

Does it look like the script worked its magic? After this, hoping to deinterlace to 59.94fps.

It doesn't look right to me - assuming that this source was originally interlaced video rather than PsF (progressive)? You seem to have discarded one field. Deinterlacing it to 59.94 fps doesn't recreate the missing field of true interlaced video but rather returns duplicated frames.
Also, why RGBA instead of YUV?
Maybe upload a sample of the original capture so someone can analyze this source.

[Alwyn]

@Sharc, I believe the revised sample is in post #5.

[waxstone]

Good, you captured correctly as YUV 4:2:2. You can get a little more detail in the brights with something like ColorYUV(gain_y=-20).

Does it look like the script worked its magic? After this, hoping to deinterlace to 59.94fps.

It doesn't look right to me - assuming that this source was originally interlaced video rather than PsF (progressive)? You seem to have discarded one field. Deinterlacing it to 59.94 fps doesn't recreate the missing field of true interlaced video but rather returns duplicated frames.
Also, why RGBA instead of YUV?
Maybe upload a sample of the original capture so someone can analyze this source.

For the first sample "Sample59.94Fps V2.avi" I have applied the avisynth script to produce "Sample59.94Fps V2 FrameFix.avi" and then encoded "Sample59.94Fps V2 FrameFix_Encoded.mp4" which looks decent.

For the second sample "A003Sample.avi" I applied the avisynth script to produce "A003SampleFrameFix.avi" and then encoded to "A003SampleFrameFix_Encoded.mp4" which doesn't look great.

Both use the same settings in Handbrake. Any idea what's went wrong?

[jagabo]

Good, you captured correctly as YUV 4:2:2. You can get a little more detail in the brights with something like ColorYUV(gain_y=-20).

Does it look like the script worked its magic? After this, hoping to deinterlace to 59.94fps.

It looks like the video in that clip was progressive, encoded/broadcast as interlaced. Only the overlay near the end is interlaced.

[jagabo]

Both use the same settings in Handbrake. Any idea what's went wrong?

The problem stems from the fact that the field order alternates between TFF and BFF in your 59.94i clips. Which it starts with depends on where you cut in on the clip (and maybe where the capture device/software started).

Take an interlaced broadcast where fields are broadcast sequentially (there are no frames in an interlaced broadcast):

A b C d E f G h

Each letter represents a field, upper case letters are top fields, lower case letters are bottom fields. Note that the fields are broadcast in order an they always alternate between top and bottom fields.

A normal 29.97i capture would simple pair fields together into frames:

Ab Cd Ef Gh

Note that the frames are top field first, each field appears only once, and all frames are TFF.

Your 59.94i captures did this:

Ab bC Cd dE Ef fG Gh

Aside from the first field all fields are repeated. The even frames contain all the broadcast fields just like a normal TFF 29.97i cap. The Odd frames also contain all of the original fields (except the very first) but the field order is reversed, BFF. But which is TFF and which is BFF depends on where the recording started and/or where it is trimmed. For example, if you removed the first frame:

bC Cd dE Ef fG Gh

You now have a video where all the even number frames are BFF and all the odd numbered frames are TFF. Even worse, if you dropped any frames while capturing clips may switch from one to the other at those drops.

[Sharc]

.... Any idea what's went wrong?

In addition to what jagabo has explained your A003 is a poor capture. If you recapture it use the correct framerate 29.97 fps upfront.

[waxstone]

Both use the same settings in Handbrake. Any idea what's went wrong?

The problem stems from the fact that the field order alternates between TFF and BFF in your 59.94i clips. Which it starts with depends on where you cut in on the clip (and maybe where the capture device/software started).

You now have a video where all the even number frames are BFF and all the odd numbered frames are TFF. Even worse, if you dropped any frames while capturing clips may switch from one to the other at those drops.

.... Any idea what's went wrong?

In addition to what jagabo has explained your A003 is a poor capture. If you recapture it use the correct framerate 29.97 fps upfront.

So what you're basically saying is that I should recapture. I'm glad I have a definitive answer but I still have some questions.

These tapes contain a mix of anime programs including commercials. Is it likely that they are all interlaced, or would it be likely to have telecine (because of the animation)?

Is it possible that I can convert one 6 hour video using the same encoding setting? I'm looking for recommendations to have each tape encoded in one swoop. I'd like to use QTGMC as it's regarded as one of the best filters for encoding.

Could the field order swap within the content within the tape itself, or is the field order only established within in the video capture?

[Sharc]

Your question was why the A003 in post#10 are worse compared to the other 59.94fps captures.
If the only issue of your capture is the 59.94fps framerate but are otherwise ok you can solve the framerate problem with jagabo's script - as you have done already. If however there are additional issues like with your A003 capture you should think about a re-capture (adjust the tracking, maybe use a better VCR, maybe the tape is just in poor condition etc.).
There is no "one for all" script. Start with a decent capture, analyze it and then develop and apply a script as necessary.

[waxstone]

Your question was why the A003 in post#10 are worse compared to the other 59.94fps captures.
If the only issue of your capture is the 59.94fps framerate but are otherwise ok you can solve the framerate problem with jagabo's script - as you have done already. If however there are additional issues like with your A003 capture you should think about a re-capture (adjust the tracking, maybe use a better VCR, maybe the tape is just in poor condition etc.).
There is no "one for all" script. Start with a decent capture, analyze it and then develop and apply a script as necessary.

Okay I understand, so the does work correctly with no need for recapture? I misinterpreted what you had said.

Unfortunately the capture is of lower quality, it is a very old tape. I'm however using the best settings. To add, it was recorded in LP mode which afaik does have an impact on quality. The content has never been preserved before this.

I guess my main question then is how should I approach encoding as mentioned above. Should I split it into further segments using Avidemux? It's tricky.

[Sharc]

Should I split it into further segments using Avidemux?

Not necessarily, but I don't know what mix and glitches you have in your 6 hours tape capture ....
On material like your post#5 attachment you can try a script like

ffms2("Sample59.94fps_v2.avi") #or use your preferred source filter
crop(12,0,-12,-6)
Selecteven()
AssumeTFF()
separatefields().vinverse().weave()  #reduces residual combing
QTGMC(preset="fast")
colorYUV(gain_y=-20)
mcdegrainsharp() # or a denoiser of your choice ....
addborders(4,2,4,4)

Then encode this with x264 using SAR 10/11

[waxstone]

Should I split it into further segments using Avidemux?

Not necessarily, but I don't know what mix and glitches you have in your 6 hours tape capture ....
On material like your post#5 attachment you can try a script like

ffms2("Sample59.94fps_v2.avi") #or use your preferred source filter
crop(12,0,-12,-6)
Selecteven()
AssumeTFF()
separatefields().vinverse().weave()  #reduces residual combing
QTGMC(preset="fast")
colorYUV(gain_y=-20)
mcdegrainsharp() # or a denoiser of your choice ....
addborders(4,2,4,4)

Then encode this with x264 using SAR 10/11

I've been able to replicate this for the sample provided (except denoiser, i'll sort that another time), thanks for the scripting.

I'm going to extract some small samples of each recorded program using avidemux and then try to interpret field order.

Bit of a headache, do you have any recommendations for software to easily comb through and detect field order? Other than frame capture drop outs, is there anything else that can cause a field to swap order during a mixed recording and is it common?

[Sharc]

Bit of a headache, do you have any recommendations for software to easily comb through and detect field order?

In Avisynth apply the script:

<your source filter here>
AssumeTFF()
SeparateFields()
AssumeFPS(2)  #for slow motion playback

Now select a scene with motion and play this script (or step manually with your player through the clip).
For true interlaced video:
- if the motion advances look "natural" the video is TFF (TopFieldFirst) as assumed by 'AssumeTFF()'.
- if the motion is jerky backwars-forwards-backwards-..... the video is BFF (BottomFieldFirst)
Other patterns you will get for telecined, PsF, phase switched, other oddities like your 59.94 captures as explained by jagabo, or progressive video. You can find more post in this forum for such cases.

[jagabo]

I usually use something like:

LWlibavVideoSource("filename.ext")
AssumeTFF()
Bob()

The open that in an editor like VirtualDub2 that lets you step through the video frame by frame. Medium speed horizontal panning shots are usually best for checking motion. Even in animated material, where character animation is usually at 12 fps, panning shots are at full 24 fps.

[clashradio]

Should I split it into further segments using Avidemux?

Not necessarily, but I don't know what mix and glitches you have in your 6 hours tape capture ....
On material like your post#5 attachment you can try a script like

ffms2("Sample59.94fps_v2.avi") #or use your preferred source filter
crop(12,0,-12,-6)
Selecteven()
AssumeTFF()
separatefields().vinverse().weave()  #reduces residual combing
QTGMC(preset="fast")
colorYUV(gain_y=-20)
mcdegrainsharp() # or a denoiser of your choice ....
addborders(4,2,4,4)

Then encode this with x264 using SAR 10/11

Can I ask why you chose QTGMC "fast" and not "slow"?

[Sharc]

Should I split it into further segments using Avidemux?

Not necessarily, but I don't know what mix and glitches you have in your 6 hours tape capture ....
On material like your post#5 attachment you can try a script like

ffms2("Sample59.94fps_v2.avi") #or use your preferred source filter
crop(12,0,-12,-6)
Selecteven()
AssumeTFF()
separatefields().vinverse().weave()  #reduces residual combing
QTGMC(preset="fast")
colorYUV(gain_y=-20)
mcdegrainsharp() # or a denoiser of your choice ....
addborders(4,2,4,4)

Then encode this with x264 using SAR 10/11

Can I ask why you chose QTGMC "fast" and not "slow"?

Good enough for this proposal. Going slower has no real benefit here IMO as denoising is done later anyway. If you come to different conlusions just go ahead.

[waxstone]

Your device/software captured at 59.94 frames per second by pairing fields but also duplicating fields:

01  12  23  34  45  56  67...

Each digit is a field and the number represents the original field number.

You can simply discard every other frame to get a proper 29.97 fps interlaced file. Either:

01  23  45  67...

In AviSynth that would be

AviSource("Sample59.94fps.avi")
SelectEven()
AssumeTFF()

I'm struggling to remove the unnecessary frames from this video, I've tried assuming TFF and BFF, please see attached.

[Sharc]

It's telecined. You need to IVTC (InverseTelecine) it.

SelectEven()
AssumeTFF()
TFM().TDecimate()  #returns 23.976 fps progressive frames

[waxstone]

It's telecined. You need to IVTC (InverseTelecine) it.

SelectEven()
AssumeTFF()
TFM().TDecimate()  #returns 23.976 fps progressive frames

Would it be possible to return it to 29.97 fps (interlaced), so that I can then convert it to 59.94 fps (deinterlaced)? There is a mix of commercials and animation in the full video.

[jagabo]

It's telecined. You need to IVTC (InverseTelecine) it.

SelectEven()
AssumeTFF()
TFM().TDecimate()  #returns 23.976 fps progressive frames

Would it be possible to return it to 29.97 fps (interlaced), so that I can then convert it to 59.94 fps (deinterlaced)? There is a mix of commercials and animation in the full video.

There's no point in making it 59.94 fps. That will not make the motion smooth. The original source only has 24 different frames per second. Actually, most cartoons are animated at 12 frames per second, with only panning done at 24 frames per second. Even if you use motion interpolation to create intermediate frames it will not be very smooth -- that type of interpolation doesn't work well with cartoons. You will get lots of blended frames and gross distortions.

Note: I haven't seen the latest clip yet as I'm not at home. I'm taking Sharc's word for it that it's 24 fps.

[waxstone]

It's telecined. You need to IVTC (InverseTelecine) it.

SelectEven()
AssumeTFF()
TFM().TDecimate()  #returns 23.976 fps progressive frames

Would it be possible to return it to 29.97 fps (interlaced), so that I can then convert it to 59.94 fps (deinterlaced)? There is a mix of commercials and animation in the full video.

There's no point in making it 59.94 fps. That will not make the motion smooth. The original source only has 24 different frames per second. Actually, most cartoons are animated at 12 frames per second, with only panning done at 24 frames per second. Even if you use motion interpolation to create intermediate frames it will not be very smooth -- that type of interpolation doesn't work well with cartoons. You will get lots of blended frames and gross distortions.

Note: I haven't seen the latest clip yet as I'm not at home. I'm taking Sharc's word for it that it's 24 fps.

As this has been recorded from broadcast there is a mix of frame rates, (12, 24, 30) but ultimately 29.97 would mean that no frames are lost.

Please see attached example.

[Sharc]

Your NewSample2.avi is phase switched progressive video (captured at your 59.94fps).
You get progressive 29.97fps using

SelectEven() #59.94fps->29.97fps
AssumeBFF()
TFM()  #Field matching

[Sharc]

... and if you have in your 59.94fps captures a mix of true interlaced and telecined video it is probably easiest when you just bob-deinterlace it.

selecteven()  # 59.94fps -> 29.97fps
AssumeTFF() #or AssumeBFF()
QTGMC()

unless you split the videos into segments and process these individually

[jagabo]

Title sequences are often very different from the main body of the show. Titles are often overlaid as 30i video or 30p video, regardless of the frame rate of the underlying show. You may often find that the underlying video is slowed or sped up to match the theme song -- so the pulldown may not be the standard 3:2 pattern.

Since it's likely your six hour long 59.94 fps caps aren't perfect (no dropped/inserted frames) the easiest thing for you to do is recapture the video at the proper 29.97 fps then double frame rate deinterlace with QTGMC() or maybe BWDIF() or Yadif(), and encode at 59.94 fps.