VHS to DVD with Canopus ADVC110 - mostly filter/cleaning questions

[SerbianBoss]

Peachsmoother dont have interlaced option, but vague have.

So when using peachsmoother you must to separate fields or to bob video.

So script:

PeachSmoother(NoiseReduction=80)
VagueDenoiser(threshold=7, nsteps=8, interlaced=true)

isnt good.

Read this article:
http://forum.doom9.org/showthread.php?t=112551

And this is how to apply any filter for interlaced source
http://www.avisynth.org/InterlacedSmoothing

I didnt try yet this script

[Barnabas]

Z-C

Have you tried side by side comparisons of video from convolution-3d versus the nonlinear-smoothing loss free 3-d filter? On a wide range of video sources that people bring to me, I find they are very close in quality.

I have sometimes used both AVIsynth with one filter, and then opened up that script in Virtualdub for more filtering, like logo removal, or using some other Virtualdub only filters.

btw, MSU denoise has done almost nothing for any video I have tried it on.

[grannyGeek]

Z-C --
to verify field order you can separate the fields in a script, and step through frame by frame.
If you chose wrong for Top or Bottom, action will look jumpy and jerk backwards then forward.
Script like so –
aviSource(“C:\thisCap.avi”).AssumeBFF.SeparateFiel ds

As FulciLives said, I guess DV is always Bottom field first, but clips from other codecs can fool you, so I learned to do the test in self-defense.
(avs script for Info told me Bottom, but in truth, it was Top field first.)


If you are going to be mostly using aviSynth filters rather than VDub filters, maybe you will want to use a codec that captures in YUY2 so you won’t be needing those color conversions. (that’s why I switched from DV to Huffyuv .)

[guns1inger]

PeachSmoother doesn't have it nor seem to need it. It operates on interlaced footage without being told.

[Z-C]

Your tips have turned out to be very helpful. I appreciate all the help and have learned a lot! It has been so helpful that I will probably refer back every once in awhile to this thread.

I'm sorry to raise this again, but after working awhile with the filters it seems that the best results by far are with NeatVideo(trial for now). It simply does magic! and I have no better way to describe it!

The only disadvantage is speed. it takes around 14 hours to complete 30 mins of video footage, with less than mediocre settings.
I was wondering if anyone has an idea of how to improve things?

Just to make things clearer- I'm loading the movie into Vdub and apply the filter. then I frameserve to CCE and encode to Mpeg2 with 3pass VBR - so the filter is basically done together with the encoding process.

I believe that if I can use a built in encoder in Vdub things would become a little faster. Is there a built in MPEG2 encoder for Vdub that is as powerful as CCE?
And maybe you guys have an idea how to speed things up? mainly the speed is reduced due to the fact the encoding needs to go through 3 passes. So the filter is applied in each pass. Do you think there's a solution to apply the filter on the footage and then to encode filter-free, but without encoding twice?

With Regards,
Guy.

[jagabo]

Save from VirtualDub with HuffYUV compression (or uncompressed RGB if you can afford the disk space). Then use that file as your source for MPEG encoding.

As it stands now, you are filtering the video 3 times (once for each pass of the MPEG encoder). If you save to an intermediate file you will cut the filtering time by a factor of 3.

[Z-C]

But that would mean encoding twice? actually 3 times!

First time to DV. then with Huffyuv, and then to mpeg2. Wouldn't that decrease quality?
And Huffyuv is lossless right? I will also get a very big file(50gb?). I'm not sure I have enough space to keep both the large DV file and this one for every movie I make :/.

What about an integrated MPEG2 encoder for Vdub? or is that a bad idea?

[guns1inger]

There is one - although I can't remember the name of it. It isn't free, either.

However, that doesn't alter the fact that multi-pass encode requires multiple passes through the filters.

I have just finished a VHS clean up with a running time of just shy of 2 hours. It took 10 hours to do a single clean up pass of the avisynth script. A two pass VBR encode would be 20+ hours, and a 3 pass . . . .too long.

So a single pass to a lossless codec was the answer.

Single pass clean-up to lossless codec 10 hours
2 pass VBR encode in ProCoder 2 hours 45 minutes

Much shorter.

HDD is a reatively cheap commodity now, and a necessary tool of video work.

[Z-C]

I will use this solution if this is the only one. But I would like to hear other ideas if anyone else has them.

Still I'm trying to determine the quality loss in 3 different encodes. Is it even seen? or is it just theoretical?

What about MJPEG? I heard it's near lossless, and the output size might be reasonable. Or will that kind of encoding create a visible quality loss?

[jagabo]

Still I'm trying to determine the quality loss in 3 different encodes. Is it even seen? or is it just theoretical?

HuffYUV is lossless so you will lose nothing in that step. Actually, since VirtualDub filters work in an RGB colorspace you will lose a little color resolution and accuracy when HuffYUV converts from RGB to YUY2. But that loss will happen during an MPEG encode so you won't really be losing anything with the HuffYUV intermediate step.

HuffYUV will convert from RGB to YUV with a 4:2:2 subsampling. When you convert that to MPEG the 4:2:2 subsampling will be reduced to 4:2:0 (really a ratio of 4:1:1 but it's different than DV so the nomenclature is different). If you go directly from VirtualDub to your MPEG encoder the MPEG encoder will reduce the RGB to YUV 4:2:0 directly. There will little difference (depending on the exact algorithms used) between RGB -> 4:2:2 -> 4:2:0 and RGB -> 4:2:0.

http://en.wikipedia.org/wiki/Chroma_subsampling

You could also use Lagarith. It has a lossless RGB mode and it compresses a little better than HuffYUV (although RGB is bigger than YUY2 to start with so you'll probably get files of about the same size). But it's slower. That would still be faster than filtering 3 times.

MJPEG will be worse than HuffYUV because MJPEG isn't lossless. Actually, PicVideo has a lossless MJPEG codec. But its compression ratio is similar to HuffYUV or Lagarith.

[Z-C]

HuffYUV will convert from RGB to YUV with a 4:2:2 subsampling

Since my source is PAL DV which is already at 4:2:0, how will it use 4:2:2 subsampling?

In the HuffYUV settings there is an option saying: "Convert RGB to YUY2 when compressing". That will actually make things lossy, but it claims to still maintain great quality. Is it a bad idea to check this option? or I won't see any degradation due to this?
I'm asking this because having a 100gb file after encoding with Huffyuv is quite big. this can reduce the file to 55gb.

I'm also a bit afraid of having too many color mode changes(first vdub converts YUV to RGB, then RGB to YUY2 by huffyuv, and then YUV by an mpeg2 encoder)


Another option I saw to speed things up is disabling the Temporal filter of Neat Video. Is this alright? or will it maintain much noise? As far as I can see the real job is made by the spatial filter(I don't really know what each means, but that's just what I see).

With Regards,
Guy.

[jagabo]

Given your source is VHS and has very low horizontal chroma resolution, even 4:2:2 subsampling is overkill. You won't see any difference.

Since you can't avoid YUV to RGB conversion with VirtualDub filtering you don't have many choices. As I said earlier, RGB -> YUY2 -> YV12 conversion won't be significantly different than RGB -> YV12.

Regarding Neat Video's temporal filtering, you'll have to decide for yourself whether it's necessary.

[Z-C]

I'm still a bit confused. 4:2:2 is surely more than enough. But the thing is that when I capture into DV I get 4:2:0 subsampling. If HuffYUV uses 4:2:2 subsampling, where does it get the last 2? It's already 0, so there's no data there. Or am I mixing things up?

Regarding the color conversions - so it's basically safe for me to check that option("Convert RGB to YUY2 when compressing") - It does say that the file will no longer be lossless. But if what you say is correct then the decrease in quality is only theoretical right?

[jagabo]

when I capture into DV I get 4:2:0 subsampling. If HuffYUV uses 4:2:2 subsampling, where does it get the last 2?

VirtualDub will convert the input 4:2:0 video into 4:4:4 RGB. It does this by replicating the U and V values for all 4 Y values.

Y1, Y2, Y3, Y4, + U1 + V1 -->

Y1 U1 V1, Y2 U1 V1, Y3 U1 V1, Y4 U1 V1 -->

R1 G1 B1, R2 G2 B2, R3 G3 B3, R4 G4 B4

(In a 4:2:0 color subsampling the four values are a 2x2 array of pixels, not a 4x1 array as drawn here.)

When HuffYUV converts RGB to YUY2 it will take the average of pairs of U and V values:

R1 GB B1, R2 G2 B2, R3 G3 B3, R4 G4 B4 -->

Y1 U1 V1, Y2 U2 V2, Y3 U3 V3, Y4 U4 V4 -->

Y1 (U1+U2)/2 (V1+V2)/2, Y2 (U1+U2)/2 (V1+V2)/2, Y3 (U3+U4)/2 (V3+V4)/2, Y4 (U3+U4)/2 (V3+V4)/2

But in your case those pairs of U and V values were duplicates of the original U and V values from your 4:2:0 source. That is, U1 = U2 = (U1+U2)/2 etc. (except for any YUV->RGB->YUV conversion losses as explained below).

Regarding the color conversions - so it's basically safe for me to check that option("Convert RGB to YUY2 when compressing") - It does say that the file will no longer be lossless.

The loss comes from two operations:

1) The conversion from RGB to YUV and back is lossy. There is not a unique YUV value for each RGB value, and vice versa. There will always be some small loss of precision when converting RGB to YUV or YUV to RGB. This loss is normally limited to the least significant bit of each subchannel. For example, the blue value in an RGB source may be 125 before converting to YUV, and come back as 124 when converting YUV back to RGB.

2) The U and V channels of YUY2 (4:2:2) have half the horizontal resolution of the RGB (4:4:4) source. But since your real source is YUV 4:2:0 the RGB data doesn't have any additional resolution in the U and V channels. And in fact, since your real source is VHS tape it has far less U and V resolution than YUY2.

There's nothing you can do about the first operation. If you want to use VirtualDub's filtering you have to live with the minor YUV/RGB conversion imprecision. And since your VHS source has lower resolution than YUY2 subsampling there's no real loss at the second operation.

[Z-C]

Wow! Thank you for the technical explanation!
It took me some time to understand it, but I think I got what you mean.
It's nice to think that just a few weeks ago all of these looked like chinese to me.

I understand the quality loss by color percision now. It doesn't worry me to much because it sounds negligible.
Besides, MPEG2(dvd) is 4:2:0 YV12 right? so If I use HuffYUV to convert from RGB to YUY2(4:2:2). When I encode to Mpeg2 and get 4:2:0 colorspace, there isn't really any conversation done. Since the pixels were already duplicated, they are actually still practically in 4:2:0 mode. Am I right here?

Regarding the second operation, just to make sure I understand correctly(and please correct me if I don't) - Basically it's more or less like the first operation? Chroma pixels were duplicated in the first place, so now when 'cutting' the horizontal chroma resolution when converting to YUY2, no data is really lost. Is this correct?


One other thing I don't get now, is why when I use peachsmoother-YV12 with avisynth without going through Vdub I get an error that says that it only works in YV12 colorspace. The original PAL DV file is 4:2:0, which is YV12.

EDIT: I also tried going back to the faster avisynth plug ins, I thought they might be a good solution for this movie, which isn't too noisy, and might be faster. The results were very creepy.
The example below was filtered with PeachSmoother&VagueDenoiser. However, I get this results with every settings and I get the same and even worse results with Convolution3d. Take a look at the lights.
The weird thing is that the left side and the right side are both taken with the same filter applied. The only change is that the left side picture with the smudged creepy lights was captured while the video was streaming, and the nice and clean picture on the right appears when stopping the stream on a certain frame. It looks like when I stop the playback - the frame refreshes to a much cleaner result. Any idea why this happens?



EDIT 2: In the original footage the lights looks just fine. However, After checking Neat video better, it seems that it also produces the smudged lights problem.

When playbacking in WMP, the results are much better, yet still a bit smudged. I know Vdub isn't the best playback software, but if Vdub was to be blamed, then why does the original footage look good?

[jagabo]

so If I use HuffYUV to convert from RGB to YUY2(4:2:2). When I encode to Mpeg2 and get 4:2:0 colorspace, there isn't really any conversation done.

Right, there are no further RGB/YUV conversion losses.

Since the pixels were already duplicated, they are actually still practically in 4:2:0 mode. Am I right here?

Yes. Some converters may try to interpolate when the convert from 4:2:0 to 4:2:2 but I'm pretty sure VirtualDub and AVISynth duplicate. You might think that interpolating (or usingsome kind of bilinear or bicubic filter) would generate better looking results. It does (the 411 filter for VirtualDub does this for 4:1:1 NTSC DV), but it leads to rounding errors if you go back and forth between full sampled and subsampled formats repeatedly.

Regarding the second operation, just to make sure I understand correctly (and please correct me if I don't) - Basically it's more or less like the first operation? Chroma pixels were duplicated in the first place, so now when 'cutting' the horizontal chroma resolution when converting to YUY2, no data is really lost. Is this correct?

That is correct.

One other thing I don't get now, is why when I use peachsmoother-YV12 with avisynth without going through Vdub I get an error that says that it only works in YV12 colorspace. The original PAL DV file is 4:2:0, which is YV12.

Although the PAL DV encoders use YV12 internally, the output of the DV decoder may not be YV12. For example, if you look at ffdshow's options, you can specify that the decoder output RGB32, RGB16, YV12, YUY2, etc.

[Z-C]

Great! It feels so much better to do things when you understand them, instead of just choosing the options because someone told you it's the way to go.
I really appreciate the thorough explanation. It helped a lot!

Unfortunately, the issues don't seem to end.
It seems I am encountering a practical problem at the moment.(the one mentioned in the EDIT two posts above). Hope you or anyone else could help with this.
I apologize for the endless questions I'm posting here. But it seems that this is the only place I get answers to my specific questions when I'm not sure what to do.

[jagabo]

Great! It feels so much better to do things when you understand them, instead of just choosing the options because someone told you it's the way to go.
I really appreciate the thorough explanation. It helped a lot!

Glad to help out. Actually I'm quite impressed that you dove right in and learned AVISynth and came to understand all this so quickly. You weren't kidding when you said "I'm a pretty fast learner"!

Unfortunately, the issues don't seem to end.
It seems I am encountering a practical problem at the moment.(the one mentioned in the EDIT two posts above). Hope you or anyone else could help with this.
I apologize for the endless questions I'm posting here. But it seems that this is the only place I get answers to my specific questions when I'm not sure what to do.

Here's what I think is happening:

Those filters contain temporal components. As they work they look at surrounding frames. When changes to a pixel aren't too drastic they assume it's noise and "average" with pixels from surrounding frames. When the changes are drastic they assume it's a scene change and don't average.

When you preview with VirtualDub the frames pass through the filters in sequence, one by one. Since the changes from frame to frame in those areas aren't too great the filters are applied. But if you move around using the slider you skip lots of frames. Maybe the frame that was displayed just before you stopped was completely different. So the filters weren't applied.

You can test for this by backing up 10 or 12 frames before that one, then using the right arrow key to step through frames. See if it looks like the "bad" one.

That type of artifact is one of the reasons I recommended not filtering.

[Z-C]

Thanks for the compliment . There's still a long way to go though.

About the artifacts - I tried what you said and I'm afraid this isn't the case here. As odd as it sounds - when playing the video in Vdub it looks bad like in the picture I posted. Yet, when I stop the playback, the same frame refreshes and looks great.
I also tried backing up a few frames with the arrow keys like you said - and everything looks perfect that way. Furthermore, I even held the arrow key for a few seconds for the movie to 'stream' by stepping through frames, and everything looks great and clean like the right picture in the image I posted.
It only occurs when pressing the 'play' button and playbacking in Vdub.

I encoded a short clip using different filters, to see what happens. When playbacking in Vdub they look bad too. When playbacking in other software I tried(WMP, BSplayer, Zoom Player) things look just fine.

I would just blame Vdub. But if that's the case then why does the source movie look fine all the time?

[FulciLives]

VirtualDub(Mod) is a wonderfull tool but it really is not made to be a "player" and the quality of "playback" will always look ... funky ... for lack of a better word.

So don't worry about it ... it's just VirtualDub and the way it displays the footage. The footage really isn't "like that" in reality.

Does that make sense?

- John "FulciLives" Coleman

[Z-C]

It makes sense But I'm not sure it's the case...

How do I know that the other players aren't showing things 'wrong'? Who knows, maybe they all are programmed like WMP so that's why in all 3 things look 'right'.

I know the Vdub isn't the best program for playbacking. But how would you explain the fact that it plays the original footage just fine, and the problems occur only with the filtered videos?

[FulciLives]

It makes sense But I'm not sure it's the case...

How do I know that the other players aren't showing things 'wrong'? Who knows, maybe they all are programmed like WMP so that's why in all 3 things look 'right'.

I know the Vdub isn't the best program for playbacking. But how would you explain the fact that it plays the original footage just fine, and the problems occur only with the filtered videos?

You could always cut out a small amount of video ... say a minute or so ... and encode it to MPEG-2 DVD spec and then use PowerDVD or WinDVD to play it back. That way you know exactly how it will look when converted (assuming you are going for MPEG-2 DVD spec in the end).

VirtualDubMod playback never looks "normal" to me but it gives you an idea at least. In short don't get so "caught up" in it all ... you are thinking too much! :P

- John "FulciLives" Coleman

[jagabo]

For me VirtualDub's display looks exactly the same as any other media player on the computer.

The Options -> Allow Video Overlays settings doesn't seem to do anythig on my computers. But as I understand it, it forces VirtualDub to use DirectDraw's video overlay features. Maybe some interaction with that is the issue.

http://www.virtualdub.org/blog/pivot/entry.php?id=91

[Z-C]

Amazing jagabo!
Thank you!

This has solved the issue! All other players I tested it in were using overlaying. And when I enabled that option in Vdub - things look just fine. There's still a small difference when scrolling with the arrow keys then when playbacking(the latter looking worse), but it basically seems to work fine now.

Any idea why that matters really? Like I said when playbacking the original footage it works fine without using overlay.

I dunno if WinDVD uses overlay, but testing the short encoded clip in it gave not so good results. They weren't as bad as in Vdub before the 'fix', but it was still pretty bad.

Maybe I'm thinking too much, but I'm a bit scared that it won't playback well on TV sets/LCD tvs.

[jagabo]

All other players I tested it in were using overlaying. And when I enabled that option in Vdub - things look just fine... Any idea why that matters really?

Are you running your desktop in 16 bit (or less) color? If so, change to 24 or 32 bit. Or conversely, maybe your video card's overlay feature is set to use 16 bit color?

[Z-C]

jagabo: My display is set to 32 bit. I tried finding anything that is related to Overlay bit settings but there's nothing of the sort. Only an option to make the video overlay zoom in. :/

[jagabo]

Try disabling and reenabling overlay in your graphics card's config applet. That often fixes overlay issues.

You can also try getting the latest drivers from the manufacturer. That may make it better. Or worse!

[Z-C]

If it's only a PC playback issue then I don't mind. Besides it seems to work fine when I enable overlay in vdub. So isn't the problem with the lack of overlay?

I'm a bit worried because WinDVD doesn't seem to playback it very well either.

I have the latest drivers I believe. I updated a few weeks ago. I will check again though.

[Z-C]

Newflash - It seems that the problem is with the MPEG2 encoding, and not with the filtering.

I tried encoding a filtered clip as Xvid - and it looks just fine without touching overlaying settings and stuff. Even WinDVD, which in any case playbacks the MPEG2 encoded material with artifacts, does a good job playbacking this.

I even encoded a short clip with NO filters at all as MPEG2. Suprisingly, the bad looking lights/pixel artifacts appear then too! I tried 2 different MPEG2 encoders and received the same results.

What do you guys think? maybe colorpsace conversions?

[jagabo]

I think this means your MPEG 2 decoder is doing something to the video as it decodes. Or, what bitrate are you using for your MPEG2 files? For a quick test try 8000 kbps CBR and see how it looks.