x264 2230 'damaged' lines

[turbojet]

When height is not a multiple of 4 there are damaged lines at the bottom. Here's some pictures, may need to zoom, most noticable in the lower left.

720p source (http://www.imagebam.com/image/e40e7a228898647)
x264 --video-filter crop:0,0,0,8/resize:720,402,1:1/select_every:2,1, damaged lines (http://www.imagebam.com/image/ea93e0228898664)
x264 --video-filter crop:0,0,0,8/resize:720,404,1:1/select_every:2,1 ok (http://www.imagebam.com/image/eca711228898678)
xvid 720x402 through avisynth is ok (http://www.imagebam.com/image/ee0b98228898690)

avisynth -> x264 had the same issue. Jeeb's x264 core 129 r2230 1cffe9f was used for testing.

[MasterNobody]

turbojet
Sorry, but I can't see anything wrong in your screenshots of Fringe even after zoom. Can you be more specific by marking problem region at screenshot. Also encoded samples and *full* command line can be helpful if you can show where the problem is.

P.S. btw Xvid is from different frame so can't be compared.
P.P.S. also it would be better if you make all resize/crop in avisynth and show source/encode after avisynth (to remove swscale from encoding path).

[Warpman]

I can see it. The last 3 lines are copied from above.

swscale bug?

[LoRd_MuldeR]

Yes, it only becomes apparent if you zoom really close, using a "nearest neighbor" resize.

I think you should find out whether this can be tracked down to the "resize" filter or to the "crop" filter, by using only one of them.

If it turns out to be caused by the "resize" filter, it may indeed be a bug in swscale. Might also be a build issue though...

[turbojet]

I think it's a longstanding x264 bug. I chose another source that didn't need to be cropped and might stand out a bit more, it takes specific scenes to really notice it. Look to the left of the leftmost crack in the brick under the window.

source okay (http://www.imagebam.com/image/df49db229022162)
720x402 x264 0.115.2008 4c552d8 from June 2011, damaged (http://www.imagebam.com/image/789789229022168)
720x402 damaged (http://www.imagebam.com/image/9e750a229022177)
720x404 okay (http://www.imagebam.com/image/4f0b10229022183)
xvid 720x402 okay (http://www.imagebam.com/image/dca092229022189)

All tests were done with latest avisynth 2.60 mt and x264.exe --output x264.mkv %1 --crf 19
Tested bilinear, bicubic, lanczos and spline144 resizers, same results.

While it might look just like a minor artifact in a picture it can be really distracting in video form, especially on checkerboard-like scenes. Here's a clip of this scene. (http://www.sendspace.com/file/efjmvb) The latest madvr crops these lines so you'll have to use a different video renderer.

[LoRd_MuldeR]

Why should only MadVR crop these lines? :confused:

Maybe those "problematic" lines are just the padding that is added unavoidably to all Non-Mod16 video and usually will never be seen by the user, because the player/decoder is supposed to crop it away?

If so, then MadVR would be showing the "expected" output. And whatever chain (decoder + renderer) you are using to trigger the issue is just ignoring the H.264 cropping flags ???

(BTW: I checked your example clip in VLC Player and cannot see an apparent problem)

[turbojet]

After your message about decoder and vlc I investigated more and found the culprit, nvcuvid in lavfilters. x264 produces fine output. Due to the cross posting rule should I link to this thread in the lavfilters thread or just hope nevcairiel sees this thread?

I have no idea why only madvr is cropping them, it just started doing so since 85.5, but it also stretches back to original resolution which isn't the correct aspect ratio.

[Guest]

Due to the cross posting rule should I link to this thread in the lavfilters thread or just hope nevcairiel sees this thread? Thank you for checking. Go right ahead and post there with a link to here as you wish. If you prefer I can move posts here to there but they may appear earlier than existing posts over there and so be missed.