Problem Causing Mess Here

[Deano123]

Check out theses shots, call it what you want because i have no clue to what it is. Also its not only on 1 source its on everyone, its either something wrong in MeGUI or my plugins folder has a broken/damaged plugin causing conflict.

might anyone know whats causing this?

http://maxupload.com/img/A465D825.png

http://maxupload.com/img/2338E078.png

http://maxupload.com/img/687B9A95.png

http://maxupload.com/img/650CDF27.png

Script used:


DGDecode_mpeg2source("C:\.d2v")

tfm(order=0).tdecimate()

crop(4, 60, -4, -64)

LanczosResize(640,272) # Lanczos (Sharp)


Plugins Folder:

http://maxupload.com/img/CCFC44AB.png

Please if you dont mind could anyone have a look and see if anything is broken or damaged, in my plugins folder:

http://maxupload.com/58DF3A0C Plugins Folder (6MB)

thanks help is very much appreciated.

[mgh]

disable crop line and see if problem persists

[Leak]

How about the usual process of commenting out all lines after the source and then un-commenting them line by line to find the line that's causing this mess?

[Deano123]

How about the usual process of commenting out all lines after the source and then un-commenting them line by line to find the line that's causing this mess?

If i was to open my script in avsp and caught a frame with the lines, and leave the script untouched and clicked refresh (F5) the lines would go again. its like they are there then there not.

[Leak]

If i was to open my script in avsp and caught a frame with the lines, and leave the script untouched and clicked refresh (F5) the lines would go again. its like they are there then there not.
Well, if there's a problem in a plugin that only shows up after some time (which of course would be fixed temporarily by reloading the script) you still can use my above method, it'll just take longer.

But I honestly doubt that anyone will be able diagnose anything by looking at that ZIP file of yours...

[Deano123]

tfm(order=0).tdecimate() & Also Tryed Diffrent Deinterlacer FieldDeinterlace()

crop(4, 60, -4, -64)

LanczosResize(640,272) # Lanczos (Sharp)


Tryed With The Script Above Which Is Pretty Much Plain, But Still I Get That Problem.

http://maxupload.com/4744D2ED

[Ebobtron]

I tried your plug-ins with my computer and found no problems with my sources. Of course the test is meaningless as I had to change your DGDecode.dll to version 1.49 to match my source d2v files. Everything else is ok, or appears ok. So I would suggest that you upgrade your DGIndex installation. My vote is that the stuff is in your source. Upload some untouched source.

[Deano123]

I tried your plug-ins with my computer and found no problems with my sources. Of course the test is meaningless as I had to change your DGDecode.dll to version 1.49 to match my source d2v files. Everything else is ok, or appears ok. So I would suggest that you upgrade your DGIndex installation. My vote is that the stuff is in your source. Upload some untouched source.

I Really Doubt Its With The Source, Ive ripped from the same source as other rippers and they had no problem with it. gonna try the DGIndex upgrade.

[IanB]

@Deano123,

I have had a quick look at your files and can see nothing obviously wrong.

A thought :-

What YV12 codec are you using on your system? Add a ConvertToRGB() at the end of your script to bypass it and test.

Also are you having these problems in VirtualDub?

[Deano123]

@Deano123,

I have had a quick look at your files and can see nothing obviously wrong.

A thought :-

What YV12 codec are you using on your system? Add a ConvertToRGB() at the end of your script to bypass it and test.

Also are you having these problems in VirtualDub?

After entering "ConvertToRGB" i had got a message to enter "ConvertToYV12()" so i did. when the sample was finished encoding the amount of times theses lines showed up decreased, but there still there.

[Ebobtron]

www.xvid.org You can install xvid on your computer.
The Xvid encoding package has a good YV12 vfw (video for windows) decoder. Just download and install the package.

http://forum.doom9.org/showthread.php?s=&threadid=56972
Helix YV12 / I420 VFW Codecs
if your not sure which YV12 you have installed try one of these.

:)

[Deano123]

www.xvid.org You can install xvid on your computer.
The Xvid encoding package has a good YV12 vfw (video for windows) decoder. Just download and install the package.

http://forum.doom9.org/showthread.php?s=&threadid=56972
Helix YV12 / I420 VFW Codecs
if your not sure which YV12 you have installed try one of these.

:)

I Had XviD 1.1.3 Installed, But The YU12 Codec I Needed, Now The Problem Is Gone I Hope It Does'nt Come Back Heres A Clean Ripped Sample: http://maxupload.com/86D083EC (9.90MB)

thanks to everyone that helped!

[IanB]

Add a ConvertToRGB() at the end of your script to bypass it and test.After entering "ConvertToRGB" i had got a message to enter "ConvertToYV12()" so i did. when ...Which of course negates the whole purpose of the test!

When putting a ConvertToRGB() at the end of a script as a test, it is important that you find something to view the output that will accept and display raw RGB.

If the app you are using can't accept RGB then do not use it in this test. It may be what is causing the problem. You have to check each component separately to isolate the fault.

For future reference other things to test to isolate this sort of problem :-

1) ConvertToRGB() at the end of your script. This isolates faults with external YV12 handling, but assumes external RGB handling works correctly.

2) ConvertToYUY2() at the end of your script. This isolates faults with external YV12 handling, but assumes external YUY2 handling works correctly.

3) Blankclip(Last) at the end of your script. This outputs a stream of all black frames and silent audio BUT with exactly the same parameters (height, width, colour space, fps, hz, bits, etc) as the normal output stream. This isolates faults in your avisynth script or avisynth itself. Alternate options with this test are to test with Color=$808080 (grey) and Color=$FFFFFF (white) in case the problems is a level arithmetic problem.

To track faults in a big system you must divide and conquor!

[Deano123]

:( Ripped The Whole Movie And Scanned Through It & Theres Still Traces Of Theses Lines. This Is Really Frustrating
Sample: http://maxupload.com/951B7E3C (10.0MB)

PS: Please Put In Simple Form What I Could Try.

[IanB]

1. Stop using MeGUI for testing! Use VirtualDub! We are only trying to analyse at this point.

Start with this script, to make sure MPeg2Source is working correctly :-DGDecode_mpeg2source("C:\.d2v")
# tfm(order=0).tdecimate()
# crop(4, 60, -4, -64)
# LanczosResize(640,272) # Lanczos (Sharp)
ConvertToRGB()Just use VDub as a timeline browser. Zoom the frame up 200% to make faults easier to see. Look at frames that have had problems before, look at other frames, go back for a 2nd look to make sure they are still good.

Next add some more features of your script :-DGDecode_mpeg2source("C:\.d2v")
# tfm(order=0).tdecimate()
crop(4, 60, -4, -64)
LanczosResize(640,272) # Lanczos (Sharp)
ConvertToRGB()Examine the same frames again, the only difference should be the images are cropped and now resized to 640x272 AND THERE WILL BE UNDEINTERLACED RESIZING ARTIFACTS.

Now examine the raw deinterlacer in your script :-DGDecode_mpeg2source("C:\.d2v")
tfm(order=0) # .tdecimate()
# crop(4, 60, -4, -64)
# LanczosResize(640,272) # Lanczos (Sharp)
ConvertToRGB()Examine the same frames again, this time they should be full size but deinterlaced BUT UNDECIMATED i.e. there will be duplicates.

Now add back in the TDecimate to your script :-DGDecode_mpeg2source("C:\.d2v")
tfm(order=0).tdecimate()
# crop(4, 60, -4, -64)
# LanczosResize(640,272) # Lanczos (Sharp)
ConvertToRGB()Examine the same frames again, this time they should be full size, deinterlaced and the duplicates should be gone.

Now add back in the crop and resize to your script :-DGDecode_mpeg2source("C:\.d2v")
tfm(order=0).tdecimate()
crop(4, 60, -4, -64)
LanczosResize(640,272) # Lanczos (Sharp)
ConvertToRGB()Examine the same frames again, this time they should be cropped and 640x272, pretty much as you expect the finished job to be.

Finally remove the ConverttoRGB from the end of your script :-DGDecode_mpeg2source("C:\.d2v")
tfm(order=0).tdecimate()
crop(4, 60, -4, -64)
LanczosResize(640,272) # Lanczos (Sharp)The output should be identical to the previous test.

Okay now open the script in MeGUI at the same time. Find your problem frames. Flip into VDub, check the same frames.

I assume at some point you will reproduce the problem, report back which test iteration got the problem for the next phase of testing. Test the previous iteration harder to make sure it is still clean.

If you get to the end with no fault in VDub and a hard fault in MeGUI, it is a MeGUI problem. PM a moderator to move this thread to the MeGUI forum and continue there.

[Deano123]

Followed the steps you provided, thanks.

VirtualDub does'nt show any sign of the frames with the problems, but when ripped in megui and played via VLC Player the frames with the problems are clearly visable: http://maxupload.com/AEA8E565

[IanB]

Well it looks like the problem is in the MeGUI end. Either MeGUI itself or the codec you are compressing with.

Use VDub to output a lossless compressed or raw .AVI from your script and feed that .AVI into MeGUI directly (i.e. no Avisynth involvement).

If the fault is not in the lossless .AVI and is still in your output file, it's pretty much a clincher.

If the fault goes away when using an intermediate lossless .AVI, the fault is most likely in how MeGUI interfaces with Avisynth.

[Deano123]

I Encoded The Lossless .avi & Feed That Into MeGUI & Ripped It, & Theres No Sign Of The Frames With The Problems.

[foxyshadis]

MeGUI doesn't handle the frames after creating the script, it must be the interface between x264 & avisnth - I think it looks like a stability/heat/psu problem, but it could be a lot of things.

[Deano123]

MeGUI doesn't handle the frames after creating the script, it must be the interface between x264 & avisnth - I think it looks like a stability/heat/psu problem, but it could be a lot of things.

Any Suggestion On What It Could Be?

[Deano123]

Any Other Suggestions? :(

[IanB]

must be the interface between x264 & avisynthWell have you reported the issue in this thread to the x264 crew?

I cannot build MeGUI or x264 and am not familiar with their code. This needs someone who is familiar and can debug the interface.

[foxyshadis]

No, since the x264 devs don't use windows, and I've been trying to reproduce or find an error in the avisynth code on my own. I very strongly suspect it's just flaky hardware, since there are no unusual versions of anything, or I'm sure it would be more widely reported.

[IanB]

But it apparently doesn't choke when you take direct AVS->x264 out of the equation. The images and samples presented just smack of pointer arithmetic errors.