meguIV: The Official Akiba-Online DVD Encoder (v1.0.1.1)

[youmeus]

If the duplicate frames are consistent throughout then you only need this:

SelectEven() [or SelectOdd()]
InterpolateFPSx2()

It worked flawlessly, and looks really nice

A clip I recently encoded puzzles me though. The DVD source looks clearly interlaced at 60i but when I encode it using MeguIVit and the 60fps C: Slower + Light EdgeClean profile, without changing anything, it comes out looking nice, but motion is screwed up somehow. I was wondering if you could take a look at a sample of the clip for me?
I've uploaded a sample of both the DVD source, in MPEG format, and a sample of the encoded MP4 from MeguIVit.

Total size 13MB:

http://rapidshare.com/files/450896031/rocco_dvd-source.mpeg
http://rapidshare.com/files/450896032/rocco_meguivit-60fps.mp4


After a few seconds there is a hard right to left pan where one can clearly see the strange behaviour in motion on the MP4.
I was hoping you could shed some light on this anomaly.
erfectplan:

 

[Vitreous]

I think this is a parity issue - the alternating lines swapped from their usual positions. Try adding the line "ComplementParity()" just before the QuickTGMC line.

 

[youmeus]

I think this is a parity issue - the alternating lines swapped from their usual positions. Try adding the line "ComplementParity()" just before the QuickTGMC line.

Thanks. That seemed to fix the problem entirely

 

[youmeus]

I have a different clip, a short segment of a DVD, that I can't determine whether is interlaced or not. Media Info in Windows 7 claims that the clip is indeed interlaced, and I fast motion areas I can clearly something that resembles interlacing artifacts - but to me it doesn't look like interlaced scanlines rendered progressively. So I have a feeling that the material is progressive, but suffering from artifacts from a poor deinterlacing.

The clip is 6MB:
http://rapidshare.com/files/451047832/whack_dvd-source.vob

Can you confirm my suspicion of a progressive source here? Or is this something different?

Here's a sample image:

 

[Vitreous]

Yes this is progressive after poor deinterlacing. Use one of the three progressive repair modes of QuickTGMC:

QuickTGMC( Preset=whatever, InputType=1 ) # or InputType=2 or 3

BTW. You've used up your support tickets now

 

[youmeus]

BTW. You've used up your support tickets now

Hehe! I know
Thanks, I really appreciate it.

Now after having seen a number of examples of how powerful Avisynth is, I think I am gonna use my sparetime from now on to learn some of this from the ground up.
erfectplan:

 

[no__One]

youmeus: Yes, encoding is one of the most demanding things you can do with your machine. Putting it under a CPU stress test for hours at a time. The only effect I've noticed over the long period is that my cooling tends to become a little less efficient after months and months of frequent encoding. Others may have different stories. A few encodes will be fine, very frequent encoding - I guess it depends whether you want to keep your comp for many, many years, or if you tend to upgrade more frequently anyway.

IceManZ: Have you checked the "Non Deterministic" box in the x264 settings? That makes different output every time. I can see you have tweaked the x264 settings from the standard MeguIV(it) ones - you set threads to 3, but that will make it slower from the default of 0. What else did you change?

In any case, I get exactly the same output every time. The motion blur is working fine - it seems to be working on yours too. Maybe you were expecting exaggerated smears? No, motion blur simulates slightly different shutter speeds. Its not a special effect, but a subtle tweak. I'm pretty sure it works correctly, but I still prefer 60fps over 30fps with the correct shutter speed.

I am currently "out of town" so I do not have access to my "monstrous beast racing cut out for encoding" PC... I did so many tests that I couldn't keep track of everything I could edit.
Practice makes perfect, as it seems.:exhausted:
Cons by what is certain is that I have not touched the setting properties of x264.
If the default setting "Non Deterministic" is on, nothing has been changed. My tests are worn on the various parameters QuickTGMC3.0 only.
That is why I have great difficulty understanding why the same AVS script executed twice in succession does not lead to the same result ... uzzled:

PS: I am truly sorry I took so long to respond. I am currently a little overwhelmed ... Unfortunately for me.

 

[Vitreous]

That is why I have great difficulty understanding why the same AVS script executed twice in succession does not lead to the same result ... uzzled:

I cannot reproduce this effect you are getting. I encoded the same source that you did and got the same result every time. I am now using an up to date MeGUI and x264, plus new MeguIVit presets. I can only suggest you don't worry about it for now. There should be a new MeguIVit in a few weeks [I want to get certain optimizations into QuickTGMC before I start on the next version of MeguIVit], maybe that will solve this puzzle.

BTW. Non deterministic should be off.

 

[youmeus]

Hi folks

The past two weeks I have been working on cleaning some progressive wmv using MeguiIVit and Avisynth. After updating Megui, finding additional plugins etc. I managed to input many progressive video files from my HD. I am manually loading the files using the AVS Script Creator in the tools tab. Except for some minor problems it worked really well with denoising and edge cleaning although I had to convert color space frequently.

I am currently working on cleaning up some saw toothed edges on a wmv fron ANAN-AV featuring rare uncensored video of Hitomi Mizutani. I planned on sharing this with Akiba-Online but a strange phenomenon similar to the ComplementParity issue with interlaced fields being out of place was introduced in the output file:
On a 29sec, or 870frames long wmv segment here at 29.970fps that I got from trimming the source wmv in Windows Media File Editor, the output x264 MKV strangely has 873 frames as opposed to the 870 frames in the input file. But furthermore, when playing back the output file frame by frame there are a few times in the 29sec clip where a future frame is displayed transparently on top of the current frame like so:

This artifact is not present in the 29sec wmv input file.
After a frame or two the problem goes away and the image frame picks up from the current frame, thus making the movie stutter at realtime playback.
From what I can see it also looks like the transparent and out of place future frame has the exact same saw tooth edges as the input file in the very same frame, meaning that it wasn't edge cleaned. This is clearly visible on the guys shirt in the image.

I first encoded the segment using the placebo Avisynth preset and also knocked the CRF down to 0 while increasing the x264 preset to placebo. I didn't touch the Trellis or Denoise in the analysis tab. However I have tried using the default 30fps C: Slower + Light EdgeClean preset along with the default MeguiIVit 480p30fps x264 preset on the same segment and the problem persists. Strangely it isn't constant though since the artifact in question is affecting different frames in different, but what should be identical, encodes.

I have tried encoding segments of a few other wmvs but I can't seem to reproduce the problem - they encode and playback just fine.

Any idea on what may be causing this issue? Or is the wmv from ANAN-AV perhaps corrupted?
uzzled:

source segment:
http://rapidshare.com/files/453189773/segment.wmv

 

[Rollyco]

I've had that problem before. I can't exactly remember how I solved it... maybe it was a wrong .dll version in the Avisynth plugins folder...

 

[youmeus]

I've had that problem before. I can't exactly remember how I solved it... maybe it was a wrong .dll version in the Avisynth plugins folder...

Thanks for the feedback Rolly. Unfortunately my problems don't end here - I just discovered, after converting a longer segment, that I get inconsistent dupeframes throughout the clip aswell, at least when doubling the framerate with InterpolateFPSx2

 

[Vitreous]

youmeus: Random ghosting effects are often due to the source filter not liking the non-sequential frame access that QTGMC requires internally. Try DirectShowSource, FFVideoSource, DSS2 and anything else that will load your source. EDIT: One trick might be to just save the source out to a lossless avi with a script just containing an FFVideoSource or similar. Then process that avi.

My EdgeCleaning script will not fix those saw-tooth edges because it is only intended for noise. That source video has had some truly ugly processing on it that makes it almost impervious to repair. A simple QTGMC won't fix it. The best I could do was this:

SetMemoryMax(700)
FFVideoSource("...filename...")
a=QuickTGMC( Preset="Slow", InputType=2, Sharpness=0.2 )
b=QuickTGMC( Preset="Slow", InputType=3, Sharpness=0.2, PrevGlobals="Reuse" )
Repair(a,b,2)
QuickTGMC( Preset="Slow", InputType=1, Sharpness=0.2, PrevGlobals="Reuse" )
nnedi3_rpow2( rfactor=2, cshift="lanczosResize", fwidth=720, fheight=540 )

That's three QuickTGMC's and a NNEDI3 anti-alias, so it's ...s.l.o.w. There is a variant with 6 QuickTGMCs...! There is surely a different method to repair it.
In any case, that script needs the latest QuickTGMC - I've updated the QuickTGMC post in this thread.

 

[youmeus]

youmeus: Random ghosting effects are often due to the source filter not liking the non-sequential frame access that QTGMC requires internally. Try DirectShowSource, FFVideoSource, DSS2 and anything else that will load your source. EDIT: One trick might be to just save the source out to a lossless avi with a script just containing an FFVideoSource or similar. Then process that avi.

My EdgeCleaning script will not fix those saw-tooth edges because it is only intended for noise. That source video has had some truly ugly processing on it that makes it almost impervious to repair. A simple QTGMC won't fix it. The best I could do was this:

SetMemoryMax(700)
FFVideoSource("...filename...")
a=QuickTGMC( Preset="Slow", InputType=2, Sharpness=0.2 )
b=QuickTGMC( Preset="Slow", InputType=3, Sharpness=0.2, PrevGlobals="Reuse" )
Repair(a,b,2)
QuickTGMC( Preset="Slow", InputType=1, Sharpness=0.2, PrevGlobals="Reuse" )
nnedi3_rpow2( rfactor=2, cshift="lanczosResize", fwidth=720, fheight=540 )

That's three QuickTGMC's and a NNEDI3 anti-alias, so it's ...s.l.o.w. There is a variant with 6 QuickTGMCs...! There is surely a different method to repair it.
In any case, that script needs the latest QuickTGMC - I've updated the QuickTGMC post in this thread.

Thanks for this. My eyes are probably not as trained as yours when it comes to these things but from what I can see it did a phenomenal job!
It sped up the framerate though from 29.970fps to 30.303fps, but this was expected? Didn't process it with audio but I am gonna do that soon. I read that AssumeFPS will resample the audio if set to true, to match the video fps so I guess I should be good there.

Indeed it was slow as you mentioned - I was peaking at 1fps in the pre-render on a Dual Core 2, 2.6Ghz :exhausted:

After reading a bit on FFVideoSource at ffmpeg I noted that one of the advantages of using FFVideoSource was it's ability to renderframe accuracy. DirectShowSource handled this before I changed it to FFVideoSource. In the light of what you wrote in your previous post I take it that the source filter is the culprit in relation to the out of order frames and ghosting. So perhaps I'll try your advice on just render a lossless avi and check the speed on that for now.

 

[Vitreous]

Dunno what's happening with the 30.30fps. It's FFVideoSource which is making that change, maybe it needs tweaked settings. In any case, going to lossless avi will surely help. I often run a second pass of scripting on lossless AVIs and the speed is no different than expected.

 

[youmeus]

Dunno what's happening with the 30.30fps. It's FFVideoSource which is making that change, maybe it needs tweaked settings. In any case, going to lossless avi will surely help. I often run a second pass of scripting on lossless AVIs and the speed is no different than expected.

It did help. After converting to lossless AVI and processing that using your script the framerate is unaffected at 29.970fps, so that solved the framerate issue. Using your script on the lossless AVI as opposed to on the WMV itself even seemed to gain me some speed - so I'm up to a whopping 1.6fps now :joker:

By the way, for your interest, loading the WMV with FFVideoSource and then just applying the simple QTGMC repair mode InputType=3 and only that didn't seem to affect the framerate either, so maybe the 3xQTGMC script is affecting the framerate instead of FFVideoSource? I dunno.

In any case, your advice on lossless AVI and the cleanup script certainly made this look stunning so thanks again :cheer:
Now I'm gonna let my machine tear through the full length of that movie tonight.

 

[astrayred]

Vitreous, I need some of your wisdom again if I may. I think the answer to this question might be appreciated by other users as well.

You know those DVD9 to DVD5 conversions that some people like to do? How best should one treat these sources? As you might know, they are very blocky and low in detail to begin with. I was thinking that I should deblock before applying QTGMC with this:

i=LAST
SeparateFields().PointResize(i.width,i.height)
Deblock_qed().AssumeFrameBased()
AssumeFrameBased().Deblock_qed()
GetParity(i) ? AssumeTFF() : AssumeBFF()
SeparateFields().SelectEvery(4,0,3).Weave()

Apparently, that's the script for applying Deblock_QED to interlaced sources that I get from D9.

Also, how should I tweak QTGMC settings for such a source? Any tips you could give would be greatly helpful!

 

[Vitreous]

I was thinking that I should deblock before applying QTGMC with this...

...
Deblock_qed().AssumeFrameBased()
AssumeFrameBased().Deblock_qed()
...

The basic idea is sound, separate the fields, resize to full-frame, do the deblocking, then resize back down and reweave. It's exactly what I do in QTGMC to use the denoisers on interlaced input.... But those two lines above look strange, surely it should be one line or the other, but not both...? I rarely use deblocking, so maybe there's something going on here I'm unaware of...

Also, how should I tweak QTGMC settings for such a source? Any tips you could give would be greatly helpful!

I'm just ripping an epic DVD9 at the moment. I've been using the new "EZDenoise" setting:

QuickTGMC( Preset="Slower", TR2=2, EZDenoise=1.33, NoisePreset="Slower", SourceMatch=2 )

With the slower NoisePresets, the denoiser will be motion compensated dfttest, which will actually have some deblocking effect (not as strong as Deblock_qed). The motion compensation means that it retains detail better. The TR2 adds a bit more smoothing (an MDegrain2 at the end). I use the source-match to prevent haloing but it's not really relevant to your query.

 

[youmeus]

The Script Video Previewer in Megui isn't always accurate?
I'm interpolating a 24fps clip to 60fps using MVFlowFps

AVISource("C:\Users\Brian\Desktop\hfyu_test.avi", audio=false).AssumeFPS(24000,1001)
source = AVISource("C:\Users\Brian\Desktop\hfyu_test.avi")
backward_vec = source.MVAnalyse(overlap=4, isb = true, pel=2, search=3, idx=1)
forward_vec = source.MVAnalyse(overlap=4, isb = false, pel=2, search=3, idx=1)
source.MVFlowFps(backward_vec, forward_vec, num=60, den=1, mask=0, idx=1)

When previewing the script everything looks interpolated and just fine when inspecting frame by frame. However, on the output MKV I get a world of dupe frames...

 

[Vitreous]

Why are there two source filters there? It means your AssumeFPS is effectively ignored. Try some different source filters anyway, they can behave randomly (not usually AviSource though). I've never been happy with the results of 24p to 60p mvflow... 48p might be better.

 

[youmeus]

Why are there two source filters there? It means your AssumeFPS is effectively ignored. Try some different source filters anyway, they can behave randomly (not usually AviSource though). I've never been happy with the results of 24p to 60p mvflow... 48p might be better.

Yeah that was causing a problem there. I couldn't find what I was doing wrong so I ended up speeding up the clip slightly to PAL Video and the audio too then interpolated to 50fps - That worked like a charm.
Other source filters didn't seem to make a difference.
The clip was from a DVD and was a hybrid of progressive and interlaced content but with consistency of 3 frames prog. followed by 2 interlaced fields through the entire clip so the deinterlacing analysis in Megui did a fine job for me with IVTC.
:cheer: