libswscale resizing artifacts

[danoon]

Resizing leaves some minor line artifacts. I noticed it on some movies I tried to encode and in particular this intro disney screen where the blue should be even.

Bad image: http://hidebehind.com/BFBD60
Good image: http://hidebehind.com/F714CD

I tried this on .85, .9 and svn build. It did not happen on .85 but it does happen on .9 and svn. And it only happens if there is resizing (if I add the -p switch for anamorphic then no problems). This leads me to suspect libswscale.

I was wondering if anyone has seen this or has any ideas as to what I might want to try. I'm not afraid to compile or patch. So just throw me an idea.

[superdump]

Is the bad image the encoded result or taken from the preview in the OS X GUI?

[danoon]

It is the encoded result. (PNG screen shot from VLC)

And just for clarification I used the windows commandline version of the app.

I'm not that familar with the code so I wasn't sure what part to look in to see what might be causing it. But it looks like the scaling takes place in hb\render.c in the function renderWork which is why I assumed it was a library problem and not necessarly HB code.

// Scale pic_crop into pic_render according to the context set up in renderInit
sws_scale(pv->context,
pv->pic_tmp_crop.data, pv->pic_tmp_crop.linesize,
0, title->height - (job->crop[0] + job->crop[1]),
pv->pic_tmp_out.data, pv->pic_tmp_out.linesize);

[superdump]

It's OK. I wrote the swscaler code (EDIT: the code in HandBrake that is, not the library itself). After a bit of testing in FFmpeg, scaling your source image I found a flag in swscaler named 'accurate rounding'. This appears to fix the issue, so if you could try this patch and tell me if it fixes the issue for you, I'll commit the fix. If you could also note the change in encoding speed, that would be appreciated.

[danoon]

That fixed it.

Command line I used for testing.

HandBrakeCLI.exe -i "d:\Family\Aladdin (1992).iso" -t 20 -a 1 -f mp4
-e x264 -q .646 --crf -E faac -B 160 --mixdown dpl2 -o "t:\h264\Aladdin (1992)(new).mp4" -c 1

With svn 923 and the official build .9 I saw the artificats of resizing. After applying the patch in this thread the artificats were gone.

I tested each version 3 times for speed. The patched (fixed) version is about 5% faster, but that is probably because my source had that large blue screen and it was easier for x264 for encode it when it was uniform in color instead of with those lines.

Thanks for the good work.

[deadamerican]

It's OK. I wrote the swscaler code. After a bit of testing in FFmpeg, scaling your source image I found a flag in swscaler named 'accurate rounding'. This appears to fix the issue, so if you could try this patch and tell me if it fixes the issue for you, I'll commit the fix. If you could also note the change in encoding speed, that would be appreciated.

This still happens with the latest release 0.9.1, does this patch still have to be applied?

[superdump]

Do you have some kind of information from which I can work? Is the scaling issue identical to the images posted previously in this thread? The patch was committed quite a while ago when this issue was reported and the fix should be in 0.9.1. More information please.

[deadamerican]

Do you have some kind of information from which I can work? Is the scaling issue identical to the images posted previously in this thread? The patch was committed quite a while ago when this issue was reported and the fix should be in 0.9.1. More information please.

It's exactly the same as the first one posted.

[danoon]

I too saw it on 0.9.1. But since 0.9.1 doesn't have any new features that weren't already in my svn compile I didn't follow up.

I just looked in svn and the original fix is still there. Looks like the problem is saintdev cast the resize flags to a 16-bit value to make it work on 64-bit linux, but SWS_ACCURATE_RND is 0x40000 which is a 32-bit value, so it got truncated/lost.

[superdump]

Correct. I'd already noticed this and have looked further into it as enabling accurate rounding on a 64-bit machine with MMX causes the segmentation fault every time. Unfortunately this is a known issue in libswscaler and it's not easy to fix.

http://lists.mplayerhq.hu/pipermail/ffm ... 24236.html

I'm going to work on a patch for libswscale that falls back to plain C when 64-bit with MMX is encountered. This is the easier workaround and a temporary fix until a proper fix is completed.

[quagga]

Hello,

I've been scouring the forums and I was wondering if any progress had been made on this issue. I have two movies I've encoded (iPod Hi-Rez) which display this banding problem. If I encode progressive for the AppleTV I don't have the bands. The progressives, however, won't play on the Ipod Touch.

I am still using 0.9.1 on FreeBSD. It is 32-bit FreeBSD 7.0 on a 64-bit Athlon X2.

[jbrjake]

I have two movies I've encoded (iPod Hi-Rez) which display this banding problem. If I encode progressive for the AppleTV I don't have the bands. The progressives, however, won't play on the Ipod Touch.

I have no idea what you mean by "encode progressive for the AppleTV"...

And no, no progress has been made on libswscale.

[quagga]

I have two movies I've encoded (iPod Hi-Rez) which display this banding problem. If I encode progressive for the AppleTV I don't have the bands. The progressives, however, won't play on the Ipod Touch.

I have no idea what you mean by "encode progressive for the AppleTV"...

And no, no progress has been made on libswscale.

Sorry, anamorphic not progressive (the -p flag). My brain latched on to the word progressive for p. The AppleTV encode didn't have the -w 640 specified as iPod Hi-Rez has.

Anyway, thank you for the info!