Wrongly captured PAL VHS at 50fps... no chance to deinterlace?

[jbl_prof]

As many around the forum, I have already behind me countless hours of trial & error, searching for tips, knowledge and guides regarding the unthankful adventure of capturing VHS for archival and sharing purposes.

I got the capture part sort of covered (good SVHS, TBC), and was very happy with using the IOData GV-USB2 capture device.

After getting through around 15 tapes, I had the need to encode one of them for sharing purposes. To my dismay, I realized I had captured in 50fps instead of 25fps.

I had not realized that the drivers for the capture device and AmaRecTV combination I used led to the option of capturing in 25fps simply not appearing. I finally found a guide informing about the situation and how to avoid it here: https://aaproductions.net/gvusb2.htm

So I tried capturing one tape in 25fps, as it should. Interlaced outcome, which could "easily" be deinterlaced following the guidelines for Hybrid / QTGMC and outputing to smooth 50fps (bob).

I have no idea how to "save" my 50fps captures. Using the same method as above, the final encoded file has 100fps - my eyes tell me it looks good, I have no double frames when frame skipping after encoding...

Is there a way to "overwrite" somehow the captured files and "make" them 25fps without losing information? From what I tried so far, I either "convert it" via VirtualDub to 25fps and get a "slow motion" video, or I convert to 25fps by "decimating by 2", leaving out half the information I had.

Apologies in advance for the lack of knowledge!

[jagabo]

We need to see a sample of your 50 fps caps.

[jbl_prof]

We need to see a sample of your 50 fps caps.

Sure thing jagabo, thanks for the quick reply! Here's the sample, hope it's good enough.

[jagabo]

It looks like you can simply discard all the even numbered (0,2,4,6...) frames. In AviSynth:

LWLibavVideoSource("snippet50fps_3.avi", cache=false, prefer_hw=2) 
AssumeTFF()
SelectOdd()
QTGMC() # for viewing here

[Selur]

Or just apply field matching using TFM() and do denoising&co sepearately, or TFM() + QTGMC(mode=2 or 3).

[Alwyn]

Experimenting (as you do!) with the "clip" file, I found that if I double-rate deinterlaced it in VDub, every 4th field would go backwards (FFFBFFFBFFFB), as though the field order was wrong. Single-rate deinterlacing gives a duplicated field/frame for every second frame/field.

Can anybody explain what's up with the file?

Attached is my deinterlaced version of the clip showing the backward movement of each 4th frame.

[lollo]

every 4th field would go backwards (FFFBFFFBFFFB)

The jump is present in the orginal fields. You should stop to analyze a video architecture through a useless deinterlace operation

[jbl_prof]

Thank you all for the suggestions and quick support. I will surely try them out today evening after work.

every 4th field would go backwards (FFFBFFFBFFFB)

The jump is present in the orginal fields. You should stop to analyze a video architecture through a useless deinterlace operation

This realization and comment got me thinking... If the VCR outputs only 25fps / 50 fields per second, and my capture device captured 50fps, is it safe to assume that it inserted two extra frames per second? Did the device "interpolate" these extra frames between the two "real frames" of video? Is the 4th field going backwards an artifact from this possible interpolation?

Further questions / comments later after testing...

[Alwyn]

The jump is present in the orginal fields. You should stop to analyze a video architecture through a useless deinterlace operation

Yes, I know that. That is why I asked the question, which was... "Can anybody explain what's up with the file?".

If you can't answer, but instead just abuse people, please keep out of it.

[lollo]

No abuse, I just answered. But you are not able to understand.

[Alwyn]

I just answered. But you are not able to understand.

You didn't answer my question, you just stated what I had already said that I knew. My enquiry was WHY.

Forget it.

[lollo]

Ok, sorry, it was me not understanding.

The GV-USB 2 working in double rate mode is introducing that defect. Difficult to understand why, being a wrong setting from the OP.

[Alwyn]

Ok thanks.

[jagabo]

This realization and comment got me thinking... If the VCR outputs only 25fps / 50 fields per second, and my capture device captured 50fps, is it safe to assume that it inserted two extra frames per second? Did the device "interpolate" these extra frames between the two "real frames" of video? Is the 4th field going backwards an artifact from this possible interpolation?

Here's what's going on:

The interlaced analog signal is 50 fields per second, one field at a time, one field after another (there are no frames in the analog signal). Lets represent each field as a letter and number, the number indicates the timestamp of the field, the letter whether it's a top or bottom field (t or b):

0t  1b  2t  3b  4t  5b  6t  7b

The timestamps are all in the correct order and the sequence always alternates between top and bottom fields.

Normally when you capture at 25 fps, top field first, each top field is paired with the next field, a bottom field, into a frame, 25 frames per second:

0t1b  2t3b  4t5b  6t7b

I.e. every other field (0t 2t 4t 6t) is paired with the next field (1b 3b 5b 7b) to produce a frame. When you double rate deinterlace the fields are handled in sequence, first the top field of the frame is displayed, then the bottom:

0t  1b  2t  3b  4t  5b  6t  7b

So you see the fields in the same order as the original analog video, 50 fields per second.

But when your capture device is set to 50 fps you get each of the original fields paired with the next field:

0t1b  1b2t  2t3b  3b4t  4t5b  5b6t  6t7b  7b8t

Note that every other frame is now bottom field first, not top field first. If you double rate deinterlace the entire video as if every frame is top field first you get:

0t  1b  2t  1b  2t  3b  4t  3b  4t  5b  6t  5b  6t  7b

Every 4th frame jumps backward.

[jbl_prof]

After reading up on Avisynth (never used it), I tried out to the best of my abilities both suggestions in this thread but I used Hybrid for it. It seemed to me that it would be possible to input your suggestions through it. I am also "honored" to have received direct suggestions from Hybrids developer!

The jagabo method
First of all, your explanation of fields, frames, how they combine and what is happening in my captures is not only thorough but genius. Based on it, I can assume that, from a technical standpoint, dropping the Even Frames of my 50fps capture would allow me to keep the frames which combine the proper field pairs out of a 25fps capture. I got to work trying to arrive to your output file by implementing your code via Hybrid:

> Loaded the file "snippet50fps_3.avi"
> x264, CFR with 20 Quantization Factor
> Filtering -> Avisynth -> Reduction -> SelectEvery -> Cycle 2 Offsets: 1

Output file: interlace_odd.mkv (25ps interlaced)

Then I loaded the output file again in Hybrid and deinterlaced QTGMC (Vapoursynth) Bob

Output file: deinterlace_odd.mkv (50fps deinterlaced)

Although to my eyes, jagabo's image quality looks slightly better (more detail), it looks to me that I achieved a good result!

The Selur method

> Loaded the file "snippet50fps_3.avi"
> x264, CFR with 20 Quantization Factor
> Filtering -> (De)Interlace/Telecine -> Auto deinterlace handling: TIVTC-> Mode: 2-way match -> TDecimate: Mode 0, Cycle 2, CycleR 1, ConCycle 1, QTGMC Medium

Output file: output_selur.mp4

I cannot distinguish a significant difference, except for the fact that there are two extra frames, even when Hybrid showed me that the Output File would be 241 frames. I am sure I did something wrong.

I thank you both greatly for the help so far, as I still will have to reflect if I will proceed this way, or bite the bullet and capture all VHS properly again...

One final question:

VirtualDub has a function of changing the frame rate of a file, allowing to save a new file without encoding it I assume (no bitrate loss). Please see bellow:


[Attachment 81101 - Click to enlarge]
By using this method, would I not achieve the goal of eliminating "irrelevant frames" or the Even Frames in my 50fps capture and keep the original capture bitrate and properties? (Lagarith, Color: YUV 4:2:2) Wouldn't this be the closest possible to keeping the original capture for archival purposes without recapturing?

Or is it possible to use Hybrid, discard the Even Frames but do not encode the file?

[jagabo]

VirtualDub has a function of changing the frame rate of a file, allowing to save a new file without encoding it I assume (no bitrate loss). Please see bellow:


[Attachment 81101 - Click to enlarge]
By using this method, would I not achieve the goal of eliminating "irrelevant frames" or the Even Frames in my 50fps capture and keep the original capture bitrate and properties? (Lagarith, Color: YUV 4:2:2) Wouldn't this be the closest possible to keeping the original capture for archival purposes without recapturing?

Yes, since you're using an all keyframe lossless codec that should work in Video -> Direct Stream Copy mode. I'm not sure if it saves the even numbered frames or the odd numbered frames. But either way should work. Just the field order will be different.

Note that you are using a lossless codec so even if you decompress and recompress you will not incur any losses (aside from the fact that you're intentionally discarding every other frame). As long as there are no color format conversions in the process (eg, YUV 4:2:2 to YUV 4:2:0 or RGB).

[Alwyn]

Jagabo, thanks for the explanation of the backward frame.

[Sharc]

...... I got to work trying to arrive to your output file by implementing your code via Hybrid:

> Loaded the file "snippet50fps_3.avi"
> x264, CFR with 20 Quantization Factor
> Filtering -> Avisynth -> Reduction -> SelectEvery -> Cycle 2 Offsets: 1

Output file: interlace_odd.mkv (25ps interlaced)

Then I loaded the output file again in Hybrid and deinterlaced QTGMC (Vapoursynth) Bob

Output file: deinterlace_odd.mkv (50fps deinterlaced)

Although to my eyes, jagabo's image quality looks slightly better (more detail), it looks to me that I achieved a good result!

As I understand you encoded/recompressed the video 2x in Hybrid:
- 1x for producing the decimated 25fps
- 1x for QTGMC deinterlacing the above
You should try to do this in 1 hop. Every re-encoding/recompression will inevitably deteriorate the quality slightly.

Secondly, QTGMC's default settings (or your settings) may not be what jagabo has been using.

[Sharc]

Or is it possible to use Hybrid, discard the Even Frames but do not encode the file?

If you want to preserve the original quality of the capture for archiving you should export (encode) the decimated file to a lossless format (like ffv1, lagarith, huffyuv, utvideo......) or "visually lossless" format (e.g. x264 with low crf).

[Alwyn]

If you want to preserve the original quality of the capture for archiving you should export (encode) the decimated file to a lossless format

or as Jagabo explained, do a Direct Stream Copy out of Virtual Dub. In this case, it comes out as Interlaced BFF.

[jbl_prof]

As I understand you encoded/recompressed the video 2x in Hybrid:
- 1x for producing the decimated 25fps
- 1x for QTGMC deinterlacing the above
You should try to do this in 1 hop. Every re-encoding/recompression will inevitably deteriorate the quality slightly.

Secondly, QTGMC's default settings (or your settings) may not be what jagabo has been using.

You pointed that out correctly. If I would go with this method, I would then do as you suggest, but...

If you want to preserve the original quality of the capture for archiving you should export (encode) the decimated file to a lossless format

or as Jagabo explained, do a Direct Stream Copy out of Virtual Dub. In this case, it comes out as Interlaced BFF.

This is exactly what I will do, as I am satisfied with the end result: an interlaced 25fps AVI file, keeping the bitrate of the original lagarinth capture. This will be my archival copy - further processing can be done as normal, even if these files became "bottom field first" due to this step.

The only final test will be to compare a properly captured video with one of these "reduced frame rate" versions and do an A/B testing, to see if I notice any difference. This just to be aware if I am in fact loosing visible information or quality. Even if the difference is minimal, I believe I will be able to live with this solution, which saves me hours and hours of recapturing.

I may eventually post my opinion about this final test. Until then, many thanks for all the contributions!

[Sharc]

The only final test will be to compare a properly captured video with one of these "reduced frame rate" versions and do an A/B testing, to see if I notice any difference. This just to be aware if I am in fact loosing visible information or quality. Even if the difference is minimal, I believe I will be able to live with this solution, which saves me hours and hours of recapturing.

This A/B "test" is a bit moot IMO, because one cannot expect identical results from 2 analog capture processes. Even with perfect captures and equipment there will be subtle differences which one may perhaps not readily see by eye (so who cares?), but they are there. It's due to the analog nature of the capturing process.
But rest assured if the 50 fps capture has no other flaws (like dropped frames) the decimation as such will not introduce any losses. It will just remove redundant material.