0.9.2 Pixelation Problems w/iPod Preset

[erise]

I've been doing some encoding with HandBrake 0.9.2. All the files I encoded using the AppleTV preset have turned out great. But every encode that I've done with the iPod High-Rez preset (on multiple sources both with and without deinterlacing) has had problems. The videos look excellent most of the time. But about every 30 seconds or so, the image becomes extremely pixelated for about a second then goes back to normal. This is an example from one of the encodes of what I'm talking about:

[rhester]

Known limitation of the x264 encoder when encoding I-frames with VBV. They're working on it.

Rodney

[SicMX]

I had the same problem when deinterlacing. The fix was to do two-pass with turbo first pass. Give that a shot

[rhester]

Apologies, the VBV issue only occurs with 1-pass encoding.

Rodney

[erise]

All my iPod High-Rez encodes were actually with 2-pass encoding, some with and some without deinterlacing. The pixelation issue happened with all of them.

[rhester]

This looks like essentially the same issue - 2-pass VBV is implemented slightly differently, in that it is likely to clobber P-frames (whereas 1-pass will harm I-frames). I know the x264 group is still looking into this, but there is no current ETA on a fix.

Rodney

[S Paris]

I've experience the same problem since upgrading to 0.9.2

I've noticed that turbo first pass leads to the worst pixelation, normal speed first pass removes most but not all of them, and if I up the bitrate to 2000kbps with normal speed first pass then that pixelation disappears - at least for the part of the movie (simpsons) I used to test this.

BTW, if the updated libraries are the problem, is the any possibilities of putting the old ones back while keeping the improved sound capabilities of 0.9.2?

[rhester]

The x264 update did not create this issue - it has existed for literally more than a year. If you change your workflow, you make it more likely to see the issue.

Rodney

[HarbingerZero]

I've resolved to downgrading to 0.91 for now and continuing with business as usual. First time this comes up for me in years of usage.

[jbrjake]

To isolate what I suspect the problem is, it'd be helpful to know if the artifacts go away if chapter markers are disabled.

[S Paris]

Hi jbrjake

I ripped a chapter of the Simpsons with and without chapter markers and although the artefacts are still there when chapters markers were disabled, they were much more subtle.

Incidentally, these artefacts aren't consistent: encoding the same chapter multiple times creates them in various places, making them hard to track down. Also, even though I started encoding using the loose anamorphic setting, I tried an encode using a regular 640x setting (the same settings I have used for as long as I can remember) and I also found those weird artefacts there as well... I never encountered them in any previous versions of HB.

Hope this helps.

[ssj2_goha]

Hi jbrjake

I ripped a chapter of the Simpsons with and without chapter markers and although the artefacts are still there when chapters markers were disabled, they were much more subtle.

Incidentally, these artefacts aren't consistent: encoding the same chapter multiple times creates them in various places, making them hard to track down. Also, even though I started encoding using the loose anamorphic setting, I tried an encode using a regular 640x setting (the same settings I have used for as long as I can remember) and I also found those weird artefacts there as well... I never encountered them in any previous versions of HB.

Hope this helps.

I just ripped this move too and had the same blocks it is really weird.

[reyn8322]

I have had this problem since upgrading to 0.9.2 also. Never occurred in 0.9.1. Only thing that seems to make much of a difference is bumping up bitrate to at least 1800kbps.

[S Paris]

Hi everyone

I've just read about changesets 1319 and 1320. I'm not a programmer or developer so I don't fully understand what the changes are but it sounds as if it's related to the problems we're having here.

Can anyone confirm this?

[dynaflash]

Hi everyone

I've just read about changesets 1319 and 1320. I'm not a programmer or developer so I don't fully understand what the changes are but it sounds as if it's related to the problems we're having here.

Can anyone confirm this?

This one should fix it. http://trac.handbrake.fr/changeset/1319

[S Paris]

This one should fix it. http://trac.handbrake.fr/changeset/1319

Thanks dynaflash! Excellent news.

Will you guys release a 0.9.2.1 update or will we have to wait for 0.9.3 to experiment with it?

I know it's possible to compile your latest builds, but as a lowly user it's not something I'm comfortable with

[dynaflash]

Frankly you are likely going to have to wait for a 0.9.3 update its not a big enough bug to warrant another release ( I know that depends on how you like to encode) .

One thing I might suggest, at the risk of breaking iPod compatibility due to short bitrate spikes (which is what vbv is for) is remove the vbv buffering constraints by deleting

Code: Select all

:vbv-maxrate=1500:vbv-bufsize=2000

from the options string in the advanced panel.

Again, I state that this may definitely cause the iPod to not take your movie and/or drop frames and "stutter" at the very least. But it will likely vary depending on your source and which model of iPod you have (5 and 5.5 G's can handle smaller bitrate spikes than the newer ones). But if you do not want to compile from source and want to try something to help it out. Again, complex scenes and/or grainy scenes will cause these short bitrate spikes, so expect to see issues there.

Another thing to try is a 2 pass encode using the stock settings. 0.9.2 has a 2 pass vbv patch already applied that *might* get you around the bug in 1 pass vbv. Though not sure, I have never tried.

At the expense of increased encoding time, my first shot would be the 2 pass approach to rule that out (or in as the case may be) and go from there.

[S Paris]

Hi Dynaflash

Thanks for all the advice. Thing is, although the problem was really bad using 1 pass, the pixelation persisted when using 2-pass (turbo pass was worse than "normal speed").

I own a 5G iPod as well as an iPod touch and like playing my movies on them and/or my Mac mini, so I would definitely like for my files to play on all devices...

Maybe I should compile the latest build after all... I remember there was a link to how to do it but I'm unable to find it again. Could you help me out and point me to it again?

Thanks again.

[iyorch]

Oops! I didn't read this post before posting my problem. I have the same one and it has happened to me in all my encoded movies since I've upgraded to this 0.9.2 version.

I've been testing a little with the "Lifted" shortfilm from Pixar. I've changed some advanced settings: specially the SUBPIXEL MOTION ESTIMATION: setting it to DEFAULT (4), originally set in 6. This makes the video looks a little bit better but stills have the pixel distortion.

[dynaflash]

http://trac.handbrake.fr/wiki/CompileGuide

[iyorch]

One thing I might suggest, at the risk of breaking iPod compatibility due to short bitrate spikes (which is what vbv is for) is remove the vbv buffering constraints by deleting

Code: Select all

:vbv-maxrate=1500:vbv-bufsize=2000

from the options string in the advanced panel.

I think this solved my problem. I've tried this using the iPod High-rez preset for the Pixar's "Lifted" shorfilm and it looks perfectly on my iPod 5.5G. I've selected too the Mixed References option and deselected the No-Fast-P-Skip.Thanx!

[rhester]

OoI've changed some advanced settings: specially the SUBPIXEL MOTION ESTIMATION: setting it to DEFAULT (4), originally set in 6. This makes the video looks a little bit better but stills have the pixel distortion.

If changing subme from 6 to 4 actually improves the visual quality, something is terribly wrong. It should hurt, not help.

Rodney

[erise]

Another thing to try is a 2 pass encode using the stock settings. 0.9.2 has a 2 pass vbv patch already applied that *might* get you around the bug in 1 pass vbv. Though not sure, I have never tried.

At the expense of increased encoding time, my first shot would be the 2 pass approach to rule that out (or in as the case may be) and go from there.

I just tried a 2-pass encode with the latest HandBrake SVN, using the iPod High-Rez preset with default settings (other than 2-pass) and I still see the pixelation problem. I'll try a single pass encode now to see if it still has problems as well.

[S Paris]

I'm afraid I can corroborate erise's experience: working with the latest build (1320) I too attempted a two-pass iPod High-Rez encode of the same film I tried previously and I got the same pixelation problems.

Regretfully, the problem persists...

[iyorch]

I'm afraid I can corroborate erise's experience: working with the latest build (1320) I too attempted a two-pass iPod High-Rez encode of the same film I tried previously and I got the same pixelation problems.

Regretfully, the problem persists...

Why don't you erase the advanced line code that dynaflash wrote: :vbv-maxrate=1500:vbv-bufsize=2000. It helped me and still compatible. Or maybe you should downgrading to 0.9.1.