Previewed video and output video are not the same

[dragon_warrior]

So I need help from you guys to help me solve a problem that I've never had before: the previewed video in AvsPMod and the output video after encoding are not the same. This is my script (pretty masochistic and long)

This is the difference between the preview and the output of the same scene
http://thumbnails38.imagebam.com/13441/820293134403724.jpg (http://www.imagebam.com/image/820293134403724) http://thumbnails26.imagebam.com/13441/028e3b134403753.jpg (http://www.imagebam.com/image/028e3b134403753)

I've tried to encode many times, but nothing's happened. Could anyone help me sort this out, thanks :thanks:

[CruNcher]

looks like left aliasing from the deinterlacing, bad ivtc ?, or wrong scaling

[dragon_warrior]

Whatever they are, I have managed to get rid of them in the preview but they still appear weirdly in the output

[CruNcher]

do you see them in every player ? try some different render modes, maybe this comes from your playback chain somehow, always a good thing is to test this on a standalone or easier now days a tablet :)
Ati and Nvidia like todo some pretty funny stuff in their drivers with Video depending on the render mode in Windows (and if it's buggy) such things can happen especially since Vista/7 where everything is Direct3D by default and capture able :)
So try some render modes that aren't influenced that heavy by the driver (overlay) :) also a sample would be nice showing that frame this way we can be sure it's not your playback chain :)

[dragon_warrior]

do you see them in every player ? try some different render modes, maybe this comes from your playback chain somehow, always a good thing is to test this on a standalone or easier now days a tablet :)
Ati and Nvidia like todo some pretty funny stuff in their drivers with Video depending on the render mode in Windows (and if it's buggy) such things can happen especially since Vista/7 where everything is Direct3D by default and capture able :)
So try some render modes that aren't influenced that heavy by the driver (overlay) :)

It's not the player that causes that problem, I'm sure

[CruNcher]

It's not the player that causes that problem, I'm sure

Ok (but im not only talking about the player since GPUs became more powerful they add alot to the playback chain that is not depended on the player @ all but more on the driver and the bugs inside them, especially if Video and 3D is melting together like happened with Vista/7 it becomes more complex) "previewed in AvsPMod" is it ok in every scaling ? or does it appear disapear based on the scaling ? i would say avpsmod preview is fooling with you ;) did you tried to play that .avs directly in mpc-hc for example do you see the same problem ?
daaa can also fail we just recently had a thread about this :)

So maybe this can help you http://forum.doom9.org/showthread.php?t=161323

[dragon_warrior]

I played the avs in MPC-HC with no flaws
Speaking of the daa, I didn't apply daa on those 'interlaced' frames, but nnedi3(), so imo daa couldn't be the cause ;-)

[CruNcher]

I played the avs in MPC-HC with no flaws
Speaking of the daa, I didn't apply daa on those 'interlaced' frames, but nnedi3(), so imo daa couldn't be the cause ;-)

Then their shouldn't be any flaws in the output either and so we either land @ the encoder or the playback chain :)

[dragon_warrior]

The encoder couldnt be the cause, either. I made another encode before this one w the same encoder.

[Didée]

"the encoder" ... "the encoder" ... "the encoder" .....

What IS the encoder anyway? Let me guess - it's x264.

I suspect it could be a hickup in Avisynth. The script is complex, perhaps it barely works out during a "simple" preview, but goes overboard when x264(?) comes into play with its own additional memory allocation, and requests "many frames" from the script.

Try to render a lossless intermediate from Vdub, with a simple intraframe compressor.

[CruNcher]

wouldn't a avs2yuv in between be as efficient in protecting the avs from evil x264 ;) :)

[Didée]

No need for joking. I'm not damning x264 "evil". But if the script's ressource usage is high, x264 might be the one drop causing the barrel (Avisynth) to overflow. Particularly, it is not clear to me if x264 running with all bells&whistels (many threads, big RC-lookahead, et al.) is really still using a strictly linear frame access pattern. Perhaps it does, perhaps not. I can't tell.

[dragon_warrior]

Yep, for 'encoder' I'm talking about x264, I'm using x264 core 115 r1995 c1e60b9
The uncompressed AVI produced by VirtualDub has artifacts that aren't present in the preview. How on earth could this thing happen?

[AzraelNewtype]

This is a stupid hack of a fix, but try cutting up the video with trims at the very last line and encode subsets, joining them at the end in mkvmerge. If it really is a memory thing causing parts to collapse, this might help.

Honestly, there absolutely must be a better method of post processing tfm than this that would avoid this problem in the first place, but the piecemeal encoding is worth a shot.

[dragon_warrior]

Thanks for the suggestion. I tried to break out the script into pieces, which later were rendered to uncompressed avi before loaded back to avisynth to be joined. I had to use ffmpegsource instead of avisource for it's way too off-colored. Though it worked quite well, the output appeared to exhibit more blockiness than the source.
So what is your idea of effective tfm post-processing? The frame replacement function is the only method I've thought of.

[AzraelNewtype]

Oh, I meant after your long list of processing so you didn't have to recalculate the frames. Avisynth evaluates backwards to avoid working on frames it doesn't need to, so you could just change it down there and not waste any processing time.

Anyway, in general I wind up using tfm like so:


dt = TDeint(order=1,field=1,type=1,edeint=nnedi3(field=1,threads=3),emask=TMM(order=1,field=1))
tfm(d2v=d2vs,pp=7,mode=2,order=1,clip2=dt)

Note that I have a quad core, adjust your thread count accordingly. The orders are obviously for TFF, swap them for BFF.

If you have some time to kill (not a lot for a music video really) you could do it two pass like so:

First:
tfm(d2v=d2vs,mode=2,order=1,output="matches.txt")

Second:
dt = TDeint(order=1,field=1,type=1,edeint=nnedi3(field=1,threads=3),emask=TMM(order=1,field=1))
tfm(d2v=d2vs,pp=7,mode=2,order=1,clip2=dt,input="matches.txt")


I'm positive this won't be perfect for every source in the world, but it's got to be a better starting point than one that requires 616 single frame replacements. You can theoretically raise mode higher too if you like, but this will almost assuredly make some bad matches on you at some points, choosing a lack of combing over smooth motion.

Incidentally, and this won't matter much here because we're only talking 12 pixels but it's worth noting, you can apply horizontal resizing/cropping prior to deinterlace/ivtc without a problem. Technically I guess you could crop vertical first too (maybe?) just don't even think of ever resizing that way beforehand.

If this manages to still look awful and need a mess of by-hand switches, I'd be curious to see just how bad that source is.

[dragon_warrior]

Your script is really nice but it will affect the whole video, which has frames that don't need post-processing :D May sounds perfectionistic but I want the bad frames fixed while maintaining the quality of the good ones.
As to the video, it's just contains several interlaced-like & aliased frames, which I have 'manually' fixed by sliding through all of its 8819 frames.
Any ideas?
*edit: If you want to have a look, then here it is: http://www.multiupload.com/3XJ2NLQTUG

[AzraelNewtype]

Your script is really nice but it will affect the whole video, which has frames that don't need post-processing :D

This isn't true. tfm post processing checks first for combing before doing any of its fix methods, and with the TMM mask even the frames that do have residual combing will be restricted to only using clip2's pixels to fix that without touching the rest of the frame. You can verify which frames tfm sees as combed and wants to postprocess by adding show=true to the arguments.

[dragon_warrior]

Oh, that's my bad. BTW, I used the script you addressed for 2-pass encoding but it seems uneffective. I finished 1st pass and got a text file full of lines that is over 100 kb, just as I hit F5 in AvsPMod window to preview before starting encoding, I notice the size is < 500 bytes and most of its content have gone. Could you please figure it out what I was doing wrong? Thanks

[Gavino]

I finished 1st pass and got a text file full of lines that is over 100 kb, just as I hit F5 in AvsPMod window to preview before starting encoding, I notice the size is < 500 bytes and most of its content have gone.
If you hit F5, the script is reloaded, thus starting again and overwriting the output file.

[dragon_warrior]

If you hit F5, the script is reloaded, thus starting again and overwriting the output file.

This time I didn't preview the video beforehand, but the video appears to be unchanged
This is what I used for 2-pass encoding
Pass 1
--pass 1 --preset veryslow --bitrate 1000 --zones 7642,7642,q=40 --output NUL "E:\Nhac\Music Videos\New Folder\unfaithful.avs"
Pass 2
--crf 17.0 --deblock -2:-1 --min-keyint 25 --b-adapt 2 --ref 6 --slices 4 --vbv-bufsize 14000 --vbv-maxrate 14000 --rc-lookahead 50 --merange 24 --me umh --subme 10 --trellis 2 --psy-rd 1.0:0.15 --nal-hrd vbr --colorprim bt470bg --transfer bt470bg --sar 10:11

Is it OK?