View Full Version : What is the cause behind these horizontal lines in my encode?
Avish
15th April 2006, 09:39
Hi Guys,
http://img133.imageshack.us/img133/4889/nemo10tl.jpg
http://img133.imageshack.us/img133/6964/nemo2lq.jpg
These are the screen captures from my currently running encode of Finding Nemo. I'm using latest MeGUI & latest x264 builds. Pls take a look at the horizontal lines surrounding the orange fish. Can anyone tell me what's causing this? Is it some deinterlacing problem? Should I stop my encode?
Here is my encoder commandline if needed :
--pass 2 --bitrate 1500 --stats "I:\Finding_Nemo\Finding_Nemo_disc_1\VIDEO_TS\Finding_Nemo.stats" --ref 3 --bframes 3 --b-pyramid --weightb --filter -2,-1 --subme 6 --trellis 1 --analyse all --8x8dct --direct auto --me umh --cqmfile "C:\Program Files\x264\eqm_avc_hr.cfg" --progress --no-psnr --output "I:\Finding_Nemo\Finding_Nemo_disc_1\VIDEO_TS\Finding_Nemo.mkv" "I:\Finding_Nemo\Finding_Nemo_disc_1\VIDEO_TS\Finding_Nemo.avs"
successfully started encoding
Thanks.
DarkZell666
15th April 2006, 09:44
They do look like a deinterlacing problem.
I think the inloop filter has squashed out many of the deinterlacing artefacts but has left those we can see in because they have flashy colors around (black and orange is too contrasted to be noise, so it left them in).
I also see you used a cqm.
What was your avs script ?
This might tell us :)
Avish
15th April 2006, 09:53
They do look like a deinterlacing problem.
I think the inloop filter has squashed out many of the deinterlacing artefacts but has left those we can see in because they have flashy colors around (black and orange is too contrasted to be noise, so it left them in).
I also see you used a cqm.
What was your avs script ?
This might tell us :)
Thanks for the instant reply :)
I used MeGUI's script creater, here it is :
DGDecode_mpeg2source("I:\Finding_Nemo\Finding_Nemo_disc_1\VIDEO_TS\FN.d2v",cpu=4,info=3)
ColorMatrix(hints=true)
tfm().tdecimate()
#crop
LanczosResize(720,400) # Lanczos (Sharp)
#denoise
So should I stop my encode? coz there is no use continuing it now!!!:rolleyes:
And another important question What should I do to fix this problem?
shon3i
15th April 2006, 10:17
tfm().tdecimate()try instead this to put FieldDeinterlace(blend=false) what is source NTSC, PAL
Avish
15th April 2006, 10:58
try instead this to put what is source NTSC, PAL Well, DGIndex says 97% Film. And shouldn't I leave the deinterlacing method decision to MeGui? It analyzes the source for at least 10-15 mins!!
shon3i
15th April 2006, 11:15
Looks a like a bad DVD quality. So you can try FieldDeinterlace becouse i founded some DVD where need to ivtc and deinterlace.
Maybe this picture can help you
http://img83.imageshack.us/img83/6383/image0662vq.jpg
DarkZell666
15th April 2006, 11:19
I have no idea what tfm().tdecimate() should look like,
but inserting FieldDeinterlace() somewhere is a good idea (available in Decomb.dll I think)
Decimating and Deinterlacing isn't the same thing at all IIRC,
and both should be done for some sources.
Not sure if blend=false is a good idea, you'll have to try that yourself. Maybe blend=true would precisely remove some horizontal lines the deinterlacing process would leave behind ...
No idea, but it isn't a problem due to x264, this thread will surely be moved to the appropriate subforum soon :)
Edit : Nice diagram shon3i ;)
Avish
15th April 2006, 11:20
OK. I'll try what u guys have suggested & will post what happens!
And Mods, please move this thread to appropriate subforum soon.:)
Edit: Sorry Guys, FieldDeinterlace(blend=false) & FieldDeinterlace(blend=true) both didn't work. Infact it increased the horizontal lines a lot!!:rolleyes:
See the result: http://img88.imageshack.us/img88/7388/nemo28hp.jpg
So now I'm back to squere one.;)
Avish
15th April 2006, 12:48
This is strange!! I tried using MeGUI's D2V Creator & the file produced by it worked like charm!!! Now output video is clean with no horizontal lines!!! The reason I said its strange b'coz MeGUI is using the same DGIndex version which I used manually with the dafault settings and it obviously produced differenct results!!!
So using MeGUI from start to finish seems to be the solution for this.:D
berrinam
15th April 2006, 13:08
This is strange!! I tried using MeGUI's D2V Creator & the file produced by it worked like charm!!! Now output video is clean with no horizontal lines!!! The reason I said its strange b'coz MeGUI is using the same DGIndex version which I used manually with the dafault settings and it obviously produced differenct results!!!MeGUI checks the amount of the video which is declared as film, and force films if it is greater than 95% (which it was -- you said it was 97%).
My guess as to all your problems:
Since DGIndex was able to force film it, every field was matched perfectly, meaning that all progressive frames were recovered and the artifacts disappeared. Previously, though, MeGUI was correct in its recognition as a telecined (that means film) source, and suggested the correct filterchain to do an inverse telecine: tfm().tdecimate() is the best around. However, TFM lacked the information that DGIndex had access to (the flags on the video), and so got it mostly right, but was confused in places where the colors were very similar. Thus everything was done correctly (well, ignoring the fact that DGIndex should have been set to force film, as MeGUI does automatically), and it was a just a problem of TIVTC not matching frames perfectly.
Note: I don't know where you got your screenshots from, but they are at too high a resolution. When does your video ever go to 1024x768? Anyway, you should be careful with resizing, as that stuffs up interlacing.
foxyshadis
15th April 2006, 13:12
Most likely MeGUI automatically enabled force film.
If you do need to deinterlace after ivtc, it should be done like:
tfm(clip2=tdeint()).tdecimate()
as an extremely simple example. FieldDeinterlace, on the other hand, is a very artifacty deint and I'd never recommend it as a pp.
Avish
15th April 2006, 13:57
MeGUI checks the amount of the video which is declared as film, and force films if it is greater than 95% (which it was -- you said it was 97%).
My guess as to all your problems:
Since DGIndex was able to force film it, every field was matched perfectly, meaning that all progressive frames were recovered and the artifacts disappeared. Previously, though, MeGUI was correct in its recognition as a telecined (that means film) source, and suggested the correct filterchain to do an inverse telecine: tfm().tdecimate() is the best around. However, TFM lacked the information that DGIndex had access to (the flags on the video), and so got it mostly right, but was confused in places where the colors were very similar. Thus everything was done correctly (well, ignoring the fact that DGIndex should have been set to force film, as MeGUI does automatically), and it was a just a problem of TIVTC not matching frames perfectly.
Note: I don't know where you got your screenshots from, but they are at too high a resolution. When does your video ever go to 1024x768? Anyway, you should be careful with resizing, as that stuffs up interlacing.
Hahaha...I took screenshots while video was playing in Fullscreen, thats why its 1024x786. Actual video size is 720x400.:D
And thanks a million for the detailed explaination.:)
berrinam
16th April 2006, 00:47
If you do need to deinterlace after ivtc, it should be done like:
tfm(clip2=tdeint()).tdecimate()MeGUI recommends this+eedi2 for hybrid samples, but I thought that for pure film samples, PP wouldn't be needed (everything can be field-matched, right? ;)). Maybe I should suggest this in pure samples as well, just as backup.
foxyshadis
16th April 2006, 02:43
It should be able to work just fine for fully-flagged video, which is why this is weird. ColorMatrix should pass the hints through, too.
.... oh, right, tfm doesn't use hints unless you pass in the d2v="" and flags=1 or 4. I guess those readmes are good for something after all. >.>
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.