x264 AVC HD encodes: constant "green line" at bottom fo frames....

[sjchmura]

I have notice this and tried everything. No matter WHAT resizing filter I use (or even if I use one, just simple cropping) - I continue to have 1-2 rows at the bottom of hte encode that are green or multicolored. This does NOT happen with Nero Recode 7 even if I use the same AVIsynth script....

I have also ensured the final output is multiple of 16 in both the x and y direction.

Any suggestions???

[bond]

video always needs a resolution being a multiple of 16. if your res is not x16 (eg 1080p/i) you will get empty lines added to the picture for getting a x16 mod (eg 1088p/i)

a decoder should automatically not show those added lines. if the decoder you use still shows them, its propably buggy

so what decoder are you using?

[GodofaGap]

He said he used multiples of 16.

@sjchmura

can you post an example script?

[sjchmura]

Will do after I get home. I am using the AVIsynth creator in MEGUI and i AM USING MOD16 :)

I am using the nero stuff to decode (Nero 7 latest updates). Again, encoding with nero to the same resolution does NOT show the green lines

[Sharktooth]

nero decoder may be buggy.
check if ffdshow or mplayer show that line.

[lexor]

here is a sample that gives green lines with

That's not a sample, that's an avs file, but you do have a mistake in there.

1088-(4+2) = 1082 which is not mod 16, you should only need to do Crop(0,0,0,-8) (since the black line padding is at the bottom, you shouldn't crop any other side, it would ruins the aspect ratio in your case), alternatively use CropBottom(8), then resize to 1280x720. And why does it say that your source is progressive? it says 1080i in the name, the "i" indicate interlaced. So deinterlace then crop then resize.

[Sharktooth]

... and next time :readguid:

[lexor]

... and next time :readguid:
actually there are no guides on Doom9 for this, the only cropping guide I know of, is wrong and doesn't produce a mod16 resolution (it makes 720x360). so he can't follow your advice. on the other hand, after looking at the script again, he should
:readrule:

[sjchmura]

Thanks. I was using the AVIsynth generator in MEGUI! So I guess that is wrong.

BUt if you resize to 720p prior to encoding WHy do you get the green line. 720 is mod16 (so is 1280)...

[sjchmura]

MEGUI "analyze" is detecting the 1080i as progressive.

[lexor]

Thanks. I was using the AVIsynth generator in MEGUI! So I guess that is wrong.

BUt if you resize to 720p prior to encoding WHy do you get the green line. 720 is mod16 (so is 1280)...
because it is the resizer and not the encoder that puts it there, and the reason it's a line is because you did crop most of it, if you didn't crop top and bottom you would've ended up with a thick gray strip at the bottom (at least I do). Why? Dunno how the resizers do their thing, either they require mo16 resolution on input, or it is becaue after your original cropping the aspect ratio wasn't the same as 1.77 to which you were resizeing.

[Egladil]

I'm 99% sure you're dealing with telecined source, you have to IVTC it before encoding, then as others said, just crop 8 lines at the bottom.

My suggestion: educate yourself till you understand every single step, else your encodes will suck.

[sjchmura]

The soruces are only about 75% film so I have been using deinterlace selected by MEGUI. IVDENT() is usually chosen.

crop( 0, 4, -6, -2)

This DOES remove the black border btw from the HD transport streams doing it manually.

This is the problem with MEGUI and the rest - this is proof they don't work like they should for those of us not experts with x264. For example, Nero Recode works perfectly, cropping, etc. Unfortunatley the quality is not as good.

If the AVISynth creator is breaking the HD stream then it is a bad one in MEGUI. Nero clearly does it correctly (no green lines, aspect ratio preserved etc). I hope the ATEME encoder brings the quality to that of x264. Until then I think you are right - you just have to make your own scripts and not trust MEGUI (worthless). Hell, even the nicaudio is broken on EVERY SINGLE BattleStar Galactica 5.1 ATSC stream (you have to "force dshow encode" but that also fails if you use AC3filter 1.07a ....... etc). (ac3fix shows no errors, mpeg2repair shows no errors).

Thanks again, will try and report back if the "cropping" to non-mod-16 was the problem

Thanks for the help, I will try to CROP to mod 16, resize mod 16.

[Hurricane Neddy]

The soruces are only about 75% film so I have been using deinterlace selected by MEGUI. IVDENT() is usually chosen.

It's a movie so it's telecined. What you need to do is a proper IVTC not to deinterlace it.

[sjchmura]

BUt MEGUI is saying it is only 75% film. So it is choosing the more complex deinterlacer. Also, if you go frame by frame after deinterlace - to be honest, I can't see that many duplicate frames.

Maybe BSG is shot in 1080i.... I know they use HD film but not sure what they are using....

[Doom9]

This does NOT happen with Nero Recode 7 even if I use the same AVIsynth script....And yet you blame megui for it.. a weird logic you have there.
BUt MEGUI is saying it is only 75% film.No, dgindex says that, but I'm sure Don would appreciate some derogatory remarks about his software as much as those of us who wrote the code for cropping and resizing of megui do.

And while we're at it, you know what filenames like T:\Batman Begins 1080i DD5.1 REAL PROPER READ NFO-ALANiS.0000.d2vstand for. If you keep it to yourself it's only your business, but if you post something here, you make it my business and you know the forum rules know no pardon for this kind of thing.

And while we're at it, I'm getting sick and tired of the moaning about nicaudio.. and yet seeing not a single report with downloadable samples in the audio forum... don't bitch if you can't even back up your problem with a source and how on earth can you expect anything to be done with a proper bugreport in the proper place? Since decoding via dshow (I presume with ffdshow, or the old ac3filter, both of which are opensource), it is definitely possible to fix this.. but not with the approach you and everybody else is taking. Get a problematic source, cut a sample, make a proper report in the audio forum, make sure you mention which other decoder (other than azid which is closed source) can handle it, and if nic doesn't catch it, I'll remind him to check it out..

[sjchmura]

Sorry about the attachment - has been deleted.

So how large of an ac3 sample would you like me to post (how many megs) in the audio forum? Most "clips" you cut and save work fine unless they are large. I can post the file on "yousendit.com" if you would like to get it to nic to see.

Why is the 75% film wrong? If it were, and you deinterlaced, moved frame by from should you not see every 5th frame duplicated with the deinterlacing???

Again, ac3fix shows 0 errors so it is perplexing.

[Doom9]

Why is the 75% film wrong?Who says it is? I have high confidence in dgindex that way, it has yet to fail me once in that department. But, if your d2v contains just a little bit of ads and other crap or you've lost frames, that probably has an effect on the outcome. But 75% film still means it's a movie (and the filename confirms that) and should be IVTCd.. IVTC filters often have an option to deinterlace remaining combed lines so you lose the duplicate frames and get rid of any interlacing at the same time.

Again, ac3fix shows 0 errors so it is perplexing.I don't think the AC3 is corrupt, I tend to think nicaudio has a problem. Make the clip as short as possible but it needs to show the error. If nicaudio throws the error at the same timecode, just cut a few seconds before and a few after, and try again.. if it doesn't help, make it larger until the error happens again.

[sjchmura]

Ok, I have cut the clip to 11megs to get the error (same spot). You can PM me (or post) where I should post it so nic can look at it.

Thanks for the IVTC suggestion.... so which one should I use? 1. Nero Recode 7 does a terrible job (it states the sources are progressive when captured movies in 1080i) however the tearing is horrble. Clealryl the IVTC is not handled well.

2. The AVISynth Creator in MEGUI detects all these 1080i moveis in HD as "interlaced" so it uses the deinterlacing filters
3. THis is what I experimented with but the frames were "jerky" which is why I went with the analysis of MEGui (The battlestar captures are from NBC-HD so I made the commercial cuts in those using HDTV2MPEG 1.86 version - so this should only cut at b-frames and I made the cuts as SOON as it faded to black)

Telecide(reverse=false, swap=false, firstlast=false, post=true, threshold=15, dthreshold=9, blend=true, chroma=false, y0=0, y1=0)
Decimate(cycle=5,mode=0,threshold=0)

SO using the above it looked "jerky". IS this a problem with decimate or should I use a different IVTC filter???

Thanks for the help. Let me know how many AC3 samples you/nic would like to test. NBC-HD/Universal is 100% problematic for all captures (Firewire 1394 hack ->TS - www. thegreenbutton.com - had to plug them :)

Thanks for the help.

Steve

[Doom9]

Here's a list of upload locations: http://forum.doom9.org/showthread.php?t=96362
I guess a handful of clips won't hurt but one is a start.

[sjchmura]

>>audio please.

Sorry - will do it tonight. My MCE audio with the new AC3Filter got all messed up - had to fix or fiance not happy

>And I still don't get it.. if you crop only and preview the file >in virtualdub.. do you get a green line? and if you add the >resizer, do you get a green line now? Or do you only get the >green line after encoding (in that case, the encoder is to be blamed)?[/QUOTE]

I will check in vdub - have not done that. That will isolate if it is the encoder or avisynth crop.

[lexor]

so did you try to crop(0,0,0,-8) instead of that weird crop you had before, did it fix the green line?

[sjchmura]

Here is the first clip. MY upload/dsl is so damn slow today. I am uploading a whole Battlestar AC3 now

http://rapidshare.de/files/30053014/Star.Wars.ep3.DELAY-760ms.ac3

So this is the error. Encodes fine in nero or besweet.