Search:

FWIW another blast from the past:
http://oldcomputers.net/
https://www.lemon64.com/game/borrowed-time

Compare with my file in post#20. Still prefer KISS? ;)

P.S. My resizing to square pixels is based on the assumption that the OP's original capture had a PAR of 10/11 (standard NTSC tape capture, 720x480@PAR 10/11). He cropped the sidebars (-> 704x480) which doesn't change the PAR, so still PAR=10/11. His "AI processing" upscaled the cropped picture 2x (=1408x960), which doesn't change the PAR, so still PAR=10/11. That's his intro_short.avi of post#5. I cropped it to 1404x742 to remove the top/bottom bars and side crud, which still doesn't change the PAR. Converting 1404x742@PAR 10/11 to square pixels with height 1080 gives a width of 1858, so 1858x1080 square pixels eventually padded on the sides to make it 1920x1080 overall, square pixels.

So how does the OP's avi (attachment to post #5) look, following your recipe above (not for DV, exception noted)? He wanted it 1920x1080 btw.
The OP will be grateful for a KISS after all the explanations he got :)

Edit:
FWIW here the result of my script in post#8 (same you would get with Hybrid)

It's just unfortunate that - for good technical reasons - neither analog consumer tape captures nor DV nor DVD are square pixel formats. So even for "go simple, go square" one should have a basic understanding of cropping and resizing to do it correctly. This includes using GUIs correctly. Even more so for interlaced footage.

Continue reading and studying. You need to understand the principle of square pixels and non-square pixles, and their relation as DAR=SARxPAR, with
DAR: Display Aspect Ratio (e.g. 4:3, 16:9, ....)
SAR: Storage Aspect Ratio = frame width/frame height (e.g. 720/480, 704/480, 1920/1080, ....)
PAR: Pixel Aspect Ratio (e.g. 8/9, 10/11, ....)

Remember:
- Out of these 3 (DAR, SAR, PAR) one can only freely select 2, the 3rd is then given! (btw. Hybrid solves a possible conflict automatically)
- Cropping and/or Padding does not change the PAR, but changes the DAR
- Resizing (except linear zooming) changes the PAR

Thank you!! Giving it a try as we speak. is this output normal?

[Parsed_fieldmatch_1 @ 0x557130774180] Frame #1539 at 51.3513 is still interlaced dup=1 drop=0 speed=5.51x
[Parsed_fieldmatch_1 @ 0x557130774180] Frame #3087 at 103.003 is still interlaced dup=1 drop=0 speed=5.27x
[Parsed_fieldmatch_1 @ 0x557130774180] Frame #3088 at 103.036 is still interlaced
[Parsed_fieldmatch_1 @ 0x557130774180] Frame #3148 at 105.038 is still interlaced dup=1 drop=0 speed=5.23x
[Parsed_fieldmatch_1 @ 0x557130774180] Frame #3149 at 105.072 is still interlaced[/QUOTE]

The source has few hiccups I think. The result should nevertheless be "ok" I would assume. Check it.

In ffmpeg try

ffmpeg -i "output.mkv" -an -c:v libx264 -preset slow -crf 18 -pix_fmt yuv420p -vf fps=30000/1001,fieldmatch,yadif=deint=interlaced,decimate "IVTC_.mp4"

Crop slightly into the pictures, something like

AVISource("intro short.avi")
crop(2,122,-2,-96) #1404x742
Spline36Resize(1858,1080) #square pixels assuming source PAR 10/11
Addborders(32,0,30,0) #pad to 1920x1080

in Hybrid (you can crop as you like and keep only a part of the top/bottom borders if you don't want to crop into the picture)

That's a different story...
In Avisynth


AVISource("intro short.avi")
crop(2,116,-2,-96)
Spline36Resize(1844,1080) #square pixels, assuming source PAR 10/11
Addborders(38,0,38,0) #pad to 1920x1080

Do accordingly in Hybrid

In Hybrid try:

Try something like

AVISource("bear.avi")
converttoYV16()
MCDegrainSharp() #or tweak Temporaldegrain2(....), the flicker is mostly in the U plane
# ... you may want to add some chroma sharpening here ...

768x576 including the borders[/quote]

If the image is 720x576 (704x576 + borders) and the PAR should be 12:11, then with a PAR of 1:1 it should be 786x576.[/QUOTE]
Yes, for a capture of analog video the PAR is ~12/11 for PAL. Including the side borders makes the frame 12/11x720=786 wide, and the DAR becomes 786/576=1.36 rather than 1.333....
A commercial or self-made DVD may have a different PAR though following the DVD standard rather than Rec601. DVD doesn't even specify the PAR explicitely, but only the DAR (like 4:3, 16:9), and many 4:3 DVDs play the active picture 2.3% squashed.


I don't know what ALL devices do, however, if they follow Rec.601 for the capturing of analog video the sampling frequency must be 13.5MHz, which for PAL results in a PAR of 59/54 (aka ~12/11 or 1150/1053) even though some devices may crop into the picture or add any borders. Cropping and padding do not change the PAR. However, if the devices apply some internal resizing or use some odd proprietary sampling frequency the PAR will change accordingly.
(PAR=Pixel Aspect Ratio).

No manipulation? As "color-under" technique using a low-frequency subcarrier is used in consumer videotape recording, the chroma has to be upconverted (heterodyned, mixed) to the PAL or NTSC color subcarrier upon playback for outputting it on the C wire to make it TV compliant, as far as I know. So even for S-Video (Y/C) there is some signal manipulation.
The difference between S-Video and Composite is that for Composite the Y (=luma+sync) and C signals are eventually summed onto 1 wire (yellow RCA = Y+C) by frequency-interleaving (preferably) requiring separation by some filtering for decoding, while separate Y/C on the 2 wires for S-Video do not depend on a subsequent (never perfect) luma-chroma separating filter.

FWIW trying sample2.mkv using DGTools/NVidia seems to cope reasonably well with the blinds

LWLibavVideoSource("D:\Temp\skh\sample2.mkv")
assumeTFF()
DGTelecide(mode=0,show=false)
DGDecimate(cycle=5,keep=4,show=false)

You may play with ColorYUV() in Avisynth, something along the line

colorYUV(gain_u=-0.0,gain_v=65.0,off_u=0,off_v=-50,cont_v=200, cont_u=100,autowhite=false,autogain=false)
(You can do similar with your RGB filters though, or ColorMill in Vdub .....)

or sometimes grayscale is an option

One may do this 1x ...2x when encountering a problem, or with tapes which have not been used for a decade, or after changing the VCR. Not a general recommendation to do it a few times, IMO.

Tinkering with color grading of an NLE?

You won't get definite answers on this subject, never. Just opinions and personal experience.


Depends much on tape quality and storage condition. The majority of tapes are probably 30+ years old these days, but in various conditions.

Yes

Playing the tapes means mechanical stress. Each playback damages the tape a tiny little bit. Never rewinding them is also problematic (fungi, mold, adhesion ...)

As above. Duplicates (copies) are of lower quality. But 2 versions mitigate the risk of a loss.

For sure I remember Scharfis_brain, the interlace Guru :). Learned a lot from him.

I'm asking the question. I am not stating that VDub's Deint or Bob is better. It is certainly simpler. I would like to know why going via AVISynth is better. If the question isn't already obvious to you, what visual difference/advantage is there between "separate Fields" and double rate deinterlacing/bobbing?


I don't know! All we want is a simple method to determine the field order. What sort of smart tool are you referring to?

Anyway, I asked the question of Lollo. How about you let him answer instead of quizzing me.[/QUOTE]
Well, you had a proposal what Hybrid should do in the other case. So I thought you could tell in this case a s well :)

Sure, so?

@Alwyn: using your (or any other) method(s), what would be your conclusion here (and what should a smart tool be reporting)?

In my past experience I could reduce dotcrawl significantly with the EH50 in passthrough. Use Composite IN (as you have composite only from your VCR as I understand) and S-Video OUT and enable the COMB Filter in the EH50.
There are also Dotcrawl filters available in Avisynth, but the EH50 was much more effective in my tests (quite some time ago I admit).[/QUOTE]

Hi Sharc

Here is the video with combfilter on in the EH50 and also with the VCR sharpness at its default of 9, i believe the other capture i did may have had the sharpness set to 1 (it goes upto 15, and 15 makes it very grainy).

Cheers

DMS[/QUOTE]

In my past experience I could reduce dotcrawl significantly with the EH50 in passthrough. Use Composite IN (as you have composite only from your VCR as I understand) and S-Video OUT and enable the COMB Filter in the EH50.
There are also Dotcrawl filters available in Avisynth, but the EH50 was much more effective in my tests (quite some time ago I admit).

.... was this from your original disc?
[/QUOTE]
Yes.

Really?
https://www.videohelp.com/search?q=DVD+authoring
https://www.videohelp.com/software?toolsearch=DVD+authoring&submit=Search&portable=&s=&orderby=Name&hits=50

@DMS: Sent you a PM

Yes. My variant was based on the proposal of @buzz1891, motion interpolated to 50fps, because I always fond baserate QTGMC to look "stroboscopic" due to the shorter camera aperture time of the 25i original footage. Could probably be improved by adding motion blur for baserate QTGMC though.

Can't help with StaxRip either.

All right. So when you feel that something does not look right, why don't you just take the one which looks right to YOU? That's all what counts at the end, and better than having sleepless nights about a possible ~2% aspect ratio error which may or may not exist.

I don't even think one can take the back wheel as a circle reference. It is distorted. Look at the fork of the wheel. Imagine what the fork would look like if the camera was pointed vertically onto the centre of the wheel - as it should for a meaningful circle test. The camera is directed from top&back onto the bike, resulting in a distorted, vertically squeezed wheel, inevitably.
Anyway, as has been said, that tilted view is useless for a test. The OP just wants to play games, as he got the info about anamorph (=non-square pixels) captures in his earlier thread and should know by now how to capture and convert to square pixels.

I guess the small difference we are debating are the infamous 2.3%, if this hurts someone at all.
What matters is to capture the source (VHS?) correctly in 720x576 for PAL (I think the OP is in PAL region), and stretch it according to its PAR (12/11, aka 59/54 in Vdub, for analog PAL capture). Doing a circle test on this single tilted picture is mumbo jumbo.
So yes the OP should provide a short sequence of the original unprocessed capture.

The front wheel looks to be more perpendicular to the camera axis with less perspective distortion than the real wheel which is closer to the camera. Also there is a small circle just below the boy's ellbow which looks more circular in the bottom picture.
Anyway - take the one YOU think is right.
(If it is an analog PAL VHS capture with small black borders each side stretch it with 12/11 and it should be correct.)

Edit: My green reference circles on Bild53 (small wheel below the boy's arm and around pedals)

Upper is wrong, lower is correct IMO.

Correct.
You didn't apply this rule with your examples in post#20, right? Were these captured with the default (procamp) settings? Or some global scenes compromise setting?

BTW FFmpeg's analysis is pretty reliable. It doesn't simply report flags but performs an analysis based on a defined number of frames (200 as below):


ffmpeg.exe -i "your_source" -filter:v idet -frames:v 200 -an -f null -
pause

Here the result of a .vob which was wrongly flagged and reported by MediaInfo accordingly as TFF:

Media Info doesn't display anything except "Interlaced" for Huff files.[/QUOTE]
Yes, noted.

FFprobe reports "unknown" - which is better than reporting nothing, I think.

ffprobe.exe "your_source" -show_format -show_streams |more
pause

Example:

Hybrid by default takes this info from MediaInfo AFAIK. So MediaInfo may be blamed.

Yes, the field order is not flagged in standard .avi container. And even when it is flagged (e.g. for DV (BFF) or other containers) there are many "opportunities" in a processing chain to flag it wrongly. So in any case make a manual check and set it right, independent of what tools may be reporting. Always.

Slightly different interpolating approach


ffms2("VTS_27_1 videohelp.mkv")
assumeTFF()
QTGMC(preset="fast")
Selectevery(4,1,3) #25fps
#25->50 interpolation:
z_ConvertFormat(pixel_type="RGBPS", colorspace_op="709:709:709:l=>rgb:709:709:f")
RIFE(gpu_thread=1, model=28, fps_num=50000, fps_den=1000, sc=true, sc_threshold=0.12)

, just use assumebff.qtgmc().selecteven and problem solved,...[/QUOTE]
Really? Leaves you with dropped/repeated frames IMO, means jerky playback (frames 100 ...200).[/QUOTE]

Yes, for selectodd, but not for selecteven.. for whatever reason[/QUOTE]
ok, makes a difference. The source framerate is 25fps interlaced. You loose some temporal resolution with the framerate reduced to 25fps progressive. Watching it realtime looks ok though. Deblocking/denoising is nice.

, just use assumebff.qtgmc().selecteven and problem solved,...[/QUOTE]
Really? Leaves you with dropped/repeated frames IMO, means jerky playback (frames 100 ...200).

Yes, speed is just one more dimension of "quality".