Best Way to De-interlace HDV

[video_fan]

Staying within the narrowest possible range is the simplest and stupidest method to generate rounding errors using multiple filters.

There is not any need at all to use multiple filters like in your crazy coding

Math isn't your strong suit, is it?

No sir, it is. Sorry, but I thinik you are not a AviSynth expert, just a young playing with conversion and high number of bits non useful.

[rgr]

Any color other than gray indicates your lack of knowledge about HBD.

And there are very few edges here anyway; most are solid surfaces.
You could test it on grass or leaves.
Maybe the edges will be bluer, or maybe pinker? I don't know, check.

ColorBars.KillAudio.AssumeFPS(50).BilinearResize(8 0,480)
StackHorizontal(last,last,last,last,last,last,last ,last) # simulate more edges than in test picture
ConvertToYUV420(bits=8,quality=true)
SeparateFields().SelectEvery(4, 0, 3).Weave().AssumeTFF()
org=last

#ConvertToYUV444(bits=16,quality=true)
QTGMC(preset="slow")
Lanczos4Resize(1920,1080)
Lsfplus(preset="slow")
#ConvertToYUV420(bits=8,quality=true)
bad=last

org
ConvertToYUV444(bits=16,quality=true)
QTGMC(preset="slow")
Lanczos4Resize(1920,1080)
Lsfplus(preset="slow")
ConvertToYUV420(bits=8,quality=true)

#showdiff(last,org)
Overlay(bad,last,mode="difference")

[video_fan]

Any color other than gray indicates your lack of knowledge about HBD.

I confirm, useless crazy. Original question is "HDV files to put on YT", 4:2:0 MPEG2 compressed, then defects.

ColorBars code??? All results in the crazy code do not see in real life and "HDV files to put on YT", 4:2:0 MPEG2 compressed, then defects".

Sir, you must be really fool, sorry. Use original 4:2:0 and ColorMatrix("Rec.601->Rec.709") and receive a video better compared than video with "crazy code"

[rgr]

Any color other than gray indicates your lack of knowledge about HBD.

I confirm, useless crazy. Original question is "HDV files to put on YT", 4:2:0 MPEG2 compressed, then defects.

Every video needs to be well processed and denoised before being uploaded to YT, otherwise YT will do it. Of course you can do it poorly, no one is defending.

ColorBars code??? All results in the crazy code do not see in real life and "HDV files to put on YT", 4:2:0 MPEG2 compressed, then defects".

Can you imagine that a real capture has more edges than ColorBars or not so much? Are you just filming walls?

Sir, you must be really fool, sorry. Use original 4:2:0 and ColorMatrix("Rec.601->Rec.709") and receive a video better compared than video with "crazy code"

You even got the topic wrong because we're talking about HBD. And we can see your "better video" in the previous screenshot.
What's crazy is that someone filters a video with many filters, in YUV420P8, and produces such crap.

[video_fan]

Every video needs to be well processed and denoised before being uploaded to YT, otherwise YT will do it. Of course you can do it poorly, no one is defending.

processed not useless processed. denoise is not always needed for HDV, maybe more anti mosquito and anti blocks, and in AviSynth is easy to well denoise withou crazy code. Sir, you never worked with HDV files.

YT will processes and encode always.

Can you imagine that a real capture has more edges than ColorBars or not so much? Are you just filming walls?

no edges like color bars in real HDV. do you film color bars with the camera?

You even got the topic wrong because we're talking about HBD. And we can see your "better video" in the previous screenshot.

Sorry, I think we talking about "HDV files to put on YT", 4:2:0 MPEG2 compressed, then defects".
I attached no screenshot, if the screenshot is colorbars is science fiction not reality.

What's crazy is that someone filters a video with many filters, in YUV420P8, and produces such crap.

No crap produced for "HDV files to put on YT", 4:2:0 MPEG2 compressed, then defects" with 4:2:0 and Rec.601->Rec.709. Crap is crazy code.

[rgr]

Every video needs to be well processed and denoised before being uploaded to YT, otherwise YT will do it. Of course you can do it poorly, no one is defending.

processed not useless processed. denoise is not always needed for HDV, maybe more anti mosquito and anti blocks, and in AviSynth is easy to well denoise withou crazy code. Sir, you never worked with HDV files.

I guess you've never dealt with files like this after all. There are no anti-block filters needed, QTGMC+denoiser are absolutely sufficient. Possibly TemporalDegrain2/Neat Video if someone feels the need.

Can you imagine that a real capture has more edges than ColorBars or not so much? Are you just filming walls?

no edges like color bars in real HDV. do you film color bars with the camera?

What are you waiting for? Show me there's no difference before I prove something different to you again.

What's crazy is that someone filters a video with many filters, in YUV420P8, and produces such crap.

No crap produced for "HDV files to put on YT", 4:2:0 MPEG2 compressed, then defects" with 4:2:0 and Rec.601->Rec.709. Crap is crazy code.

You keep barking the same thing...

[rgr]

What are you waiting for? Show me there's no difference before I prove something different to you again.

I actually have the script open anyway, so it is no problem.



enhanced

[Sharc]

@rgr: Of course there exist "differences" in your comparison of post#32. But it is YOU who declared the 4:2:0 as "bad", and assumed your up-/downscaled version as "better". That's no proof or evidence of anything.

[rgr]

@rgr: Of course there exist "differences" in your comparison of post#32. But it is YOU who declared the 4:2:0 as "bad", and assumed your up-/downscaled version as "better".

You need to do a sharp logic trick to prove that working with higher accuracy (and lower rounding errors) is worse than working with lower accuracy (higher rounding errors).
You can try to simulate an even lower input resolution. Then you won't even have to look closely to draw conclusions.

[video_fan]

I guess you've never dealt with files like this after all. There are no anti-block filters needed, QTGMC+denoiser are absolutely sufficient. Possibly TemporalDegrain2/Neat Video if someone feels the need.

you do not guess well. I use many types of real tapes (no color bars) and many avisynth filters. your crazy code is useless.

What are you waiting for? Show me there's no difference before I prove something different to you again.

I do not have to show. Ask dellsam to use the crazy code and upload to youtube, then ask dellsam to use my code and upload to youtube, then we download the youtube video and compare.

You keep barking the same thing...

because you are not intelligent to understand, so need to repeat, sorry about that.

[rgr]

I guess you've never dealt with files like this after all. There are no anti-block filters needed, QTGMC+denoiser are absolutely sufficient. Possibly TemporalDegrain2/Neat Video if someone feels the need.

you do not guess well. I use many types of real tapes (no color bars) and many avisynth filters. your crazy code is useless.

And you still don't know anything. You still live in an 8-bit world.

What are you waiting for? Show me there's no difference before I prove something different to you again.

I do not have to show. Ask dellsam to use the crazy code and upload to youtube, then ask dellsam to use my code and upload to youtube, then we download the youtube video and compare.

You can't do it yourself?

You keep barking the same thing...

because you are not intelligent to understand, so need to repeat, sorry about that.

Evidence of your stupid posts above, and you're still barking, Doctor Associate Theoretician.

[video_fan]

And you still don't know anything. You still live in an 8-bit world.

I live in what is appropriate. 8-bit, 16-bit, 32-bit, 64-bit, excetera
You use useless world.

You can't do it yourself?

Yes I can, sorry. dear dellsam, could you please upload in YT the HDV video after the crazy code (i know is a fool request, sorry about that) and please upload in YT the HDV video after the simple code? We can after download the two videos, compare and decide who is wrong and who is ok

Evidence of your stupid posts above, and you're still barking, Doctor Associate Theoretician.

Sorry, I do not understand the Doctor. My posts are not stupid, your crazy code is stupid.

[rgr]

I live in what is appropriate.

Look and learn. Maybe someday you will succeed, Mr. Troll with a fake account (lollo, its you? )
https://forum.videohelp.com/attachments/93298-1786017189/u231kt4.png

[Sharc]

@rgr: Of course there exist "differences" in your comparison of post#32. But it is YOU who declared the 4:2:0 as "bad", and assumed your up-/downscaled version as "better".

You need to do a sharp logic trick to prove that working with higher accuracy (and lower rounding errors) is worse than working with lower accuracy (higher rounding errors).
You can try to simulate an even lower input resolution. Then you won't even have to look closely to draw conclusions.

My point was that one cannot "undo" the defects of a given digital source of a given resolution and given color subsampling format by just upsampling the chroma and increase the bitdepth. One has a least to apply some dithering (~adding "noise") or interpolation at some stage of the process, otherwise the extra bits have no effect. 5 is the same as 5.0 or 5.000000000.... What is lost in the source is lost, and any additions are 'artificial' in the sense of not existing in the source.
Similar, one cannot improve the true resolution (aka details) of a given video by just upscaling it to a larger frame size.

[rgr]

@rgr: Of course there exist "differences" in your comparison of post#32. But it is YOU who declared the 4:2:0 as "bad", and assumed your up-/downscaled version as "better".

You need to do a sharp logic trick to prove that working with higher accuracy (and lower rounding errors) is worse than working with lower accuracy (higher rounding errors).
You can try to simulate an even lower input resolution. Then you won't even have to look closely to draw conclusions.

My point was that one cannot "undo" the defects of a given digital source of a given resolution and given color subsampling format by just upsampling the chroma and increase the bitdepth. One has a least to apply some dithering (~adding "noise") or interpolation at some stage of the process, otherwise the extra bits have no effect. 5 is the same as 5.0 or 5.000000000.... What is lost in the source is lost, and any additions are 'artificial' in the sense of not existing in the source.
Similar, one cannot improve the true resolution (aka details) of a given video by just upscaling it to a larger frame size.

You just eliminated all upscaling algorithms (better or worse).

Now divide your number 5 by 2, multiply by 3, then divide by 3 again and multiply by 2.
Let me know what results you got in the integer space and what in the float space.
You won't have a better number 5, but at least it will still be 5.

[Sharc]

You won't have a better number 5, but at least it will still be 5.

Agreed. The rounding error/round trip error persists as long as one sticks to integer (finite bitdepth) maths. The chroma up/downsampling has its fixed (few) patterns though (4:4:4, 4:2:2, 4:2:0, 4:1:1) and the bitdepth is (visually) less relevant IMO for converting between these formats (not talking about the formerly notorious CUE, chroma uspampling error).

[dellsam34]

Here is a sample of the HDV file:

[dellsam34]

I still have a problem with AVSPmod, While LWLibavVideoSource option worked for importing mpeg-2, it does not carry over audio, just video, Back to the drawing board.

[Sharc]

You need to add the sourcefilter for audio as well

video=LWLibavVideoSource("Tilden Park.mpg")
audio=LWLibavAudioSource("Tilden Park.mpg")
audiodub(video,audio)
assumeTFF()
QTGMC(preset="slow")
spline36resize(1920,1080) #or an upscaler of your choice
# other filters of your choice here ...

Edit: And take a look at the histogram / waveform monitor. I would lower the darks and brights a bit, something simple would be

levels(26,1.0,255,16,235,coring=false)

[_Al_]

1. Create an AVS script:
BSsource("input.mpeg2")
ConverttoYUV422(bits=10, quality=true, interlaced=true)
QTGMC(preset="slow")
Lanczos4Resize(1920,1080)
Lsfplus(preset="slow")
PropSet("_SARNum", 1). PropSet("_SARDen", 1)
ConverttoRGB(quality=true).ConverttoYUV420(bits=8, matrix="709:l", quality=true)
Prefetch

2. Check the AVS script in VDub.

3. Compress the AVS file using FFmpeg:
ffmpeg.exe -AviSynth_flags all -i input.avs your_settings output.mp4

For better quality you can use Converttoyuv444 instead of YUV422.

->32-bit floating-point processing back and forth is really not necessary for posting HDV video on youtube
->heck, even using QTGMC slow is overkill we can use bwdif also for high definitions
->did someone actually said that 10bit is waste of time because everything is mapped as 16bits to memory internally
->real time footage is really not colorbars, I would really agree on that one
->fix levels, as Sharp suggests, is way up in the priority as oppose to floating point calculations, which might not cut levels, but it also does not fix them

I would really did a test as video_fan suggests. Just years back, I would actually even do it myself for this forum ...
And after doing so, please, lets do not elaborate on some 100x100 pixel blow ups to check some border, suggesting it looks a bit better, after blowing 10x more time obtaining that footage in a PC.

I like topics regarding levels, custom made luts, custom *.cube files, that fix always a particular camera, even within editor software while editing footage, (they differ from camera to camera), rather than using full blown 32 floating point calculations back and forth.

op needs to say what camcorder he uses/used, if BT709 is correct or not

[Sharc]

op needs to say what camcorder he uses/used, if BT709 is correct or not

MediaInfo reports his uploaded HDV file of post#47 as BT.709. So no matrix conversion is needed. Not even extra flagging is needed as players will assume 709 for HD (>720 vertical) per default. Of course flagging correctly does no harm either.

[hello_hello]

Interlaced 1080i has roughly the same spacial resolution as progressive 720p, although if the frame rates are the same 1080i has a higher temporal resolution.
Therefore you can generally deinterlace 1080i to double the frame rate and downscale to 720p and not lose any detail (ie 1080i at 29.97fps to 720p at 54.9fps).

I don't upload video to YouTube so I've no idea how their re-encoding works, but assuming 2k and 4k are re-encoded the same way by YouTube, there's probably no need to resize 1440x1080i to higher resolution than 1920x1080p after de-interlacing, especially if it's de-interlaced to double the frame rate. Of course if higher resolutions are encoded at a higher quality by YouTube, then upscaling might be worthwhile.

[aedipuss]

Here is a sample of the HDV file:

not to be picky but if it's HDV it should be an .m2t file

[_Al_]

correct, it should be m2t, so camera model or original file done by HDV capture should be evaluated

[dellsam34]

Here is a sample of the HDV file:

not to be picky but if it's HDV it should be an .m2t file

If any change it must have happened during import to computer, All I have is the files. I don't think it makes a difference for what I'm trying to accomplish.

[dellsam34]

video=LWLibavVideoSource("Tilden Park.mpg")
audio=LWLibavAudioSource("Tilden Park.mpg")
audiodub(video,audio)
assumeTFF()
QTGMC(preset="slow")
spline36resize(1920,1080) #or an upscaler of your choice
# other filters of your choice here ...

What is the difference between the LanczosResize and spline36resize?

[Sharc]

video=LWLibavVideoSource("Tilden Park.mpg")
audio=LWLibavAudioSource("Tilden Park.mpg")
audiodub(video,audio)
assumeTFF()
QTGMC(preset="slow")
spline36resize(1920,1080) #or an upscaler of your choice
# other filters of your choice here ...

What is the difference between the LanczosResize and spline36resize?

Compromise between blurring, sharpness vs ringing (halos)
Lanczos4 is sharper but has more ringing. Differences are subtle.

Here you can select various kernels and visualize their response for comparison.
https://web.archive.org/web/20170327075350/http:/svn.int64.org/viewvc/int64/resamplehq...c/kernels.html

[Alwyn]

Here you can select various kernels

4 shades of red!

Which is the "red red" one? Blackman3 or Spline64?

[Sharc]

Here you can select various kernels

4 shades of red!

Which is the "red red" one? Blackman3 or Spline64?

Hover the mouse over the name and the corresponding graphs/responses are highlighted.
Complaining before trying, eh?

[dellsam34]

Here you can select various kernels and visualize their response for comparison.
https://web.archive.org/web/20170327075350/http:/svn.int64.org/viewvc/int64/resamplehq...c/kernels.html

That's too deep for me, A visual zoomed in part of the frame would be ideal for me to see the actual differences. Maybe I'll do some testing on an SD capture sample from an analog tape and see for myself, I don't think I would notice big differences in HD materials.