Blocking/Block Lines of distortion showing up in frames

[sujal]

I saw the notes about the snapshot build in a couple of other posts, so I will try that tonight, but I did want to post this just in case it was a new problem or there was some user error here. I'm getting this kind of distortion showing up several times or more in an encoded video. The distortion lasts for under a second usually and, like the image below, shows up with odd color patterns sometimes OR colors that are similar to the surrounding content but off a little.

The videos are copied from my DVDs using MTR, then encoded in Handbrake using the Apple TV preset. I've tried several videos all with the same issue.

Any suggestions here? I'm going to try re-encoding the videos with Snapshot 3 but I'm going to just use the preset settings.

Thanks,

Sujal

Code: Select all

[23:20:33] starting job
[23:20:33]  + device /Volumes/200 Shed/VOBS/ANY_GIVEN_SUNDAY Title 1 [ Entry Cell 1  -  48 Cells ]/VIDEO_TS/Any Given Sunday.VOB
[23:20:33]  + title 1, chapter(s) 1 to 1
[23:20:33]  + 720x480 -> 720x358, crop 60/62/0/0
[23:20:33]  + video frame rate: 23.976 fps
[23:20:33]  + video bitrate 2500 kbps, pass 0
[23:20:33]  + PixelRatio: 1, width:720, height: 358
[23:20:33]  + encoder x264
[23:20:33]    + x264 options: bframes=3:ref=1:subq=5:me=umh:no-fast-pskip=1:no-dct-decimate=1:trellis=2
[23:20:33]  + audio 160 kbps, 48000 Hz
[23:20:33]  + encoder faac
[23:20:33]    + 80bd, Unknown (AC3) (5.1 ch)
[23:20:33]      + Requested mixdown: Dolby Pro Logic II (HB_AMIXDOWN_DOLBYPLII)
[23:20:33]      + Actual mixdown: Dolby Pro Logic II (HB_AMIXDOWN_DOLBYPLII)
[23:20:33] thread b00c5000 started ("reader")
[23:20:33]  + output: /Users/sujal/Desktop/Any Given Sunday.VOB.mp4
[23:20:33] thread b0579000 started ("muxer")
[23:20:33] thread b05fb000 started ("MPEG-2 decoder (libmpeg2)")
[23:20:33] thread b06ff000 started ("Renderer")
[23:20:33] encx264: keyint-min: 24, keyint-max: 240
[23:20:33] encx264: encoding with stored aspect 32/27
[23:20:33] encx264: opening libx264 (pass 0)
x264 [warning]: width or height not divisible by 16 (720x358), compression will suffer.
x264 [info]: using SAR=32/27
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 SSSE3 Cache64 
[23:20:33] thread b08a6000 started ("H.264/AVC encoder (libx264)")
No accelerated IMDCT transform found
[23:20:33] thread b0928000 started ("AC3 decoder")
GUI ERROR dialog: dvd: DVDOpen failed (/Volumes/200 Shed/VOBS/ANY_GIVEN_SUNDAY Title 1 [ Entry Cell 1  -  48 Cells ]/VIDEO_TS/Any Given Sunday.VOB)
[23:20:33] file is MPEG Program Stream
[23:20:33] thread b0a31000 started ("AAC encoder (libfaac)")
[23:20:33] sync: expecting 231809 video frames
[23:20:33] sync: first pts is 56940
[23:20:33] Sync: Audio PTS (13397) < Video PTS (56940) by greater than 100ms, trashing audio to reconverge
[23:20:33] macgui: Using preset: HB-AppleTV
[23:20:33] Sync: Audio back in Sync at PTS 47957
[01:11:23] 5305.532227s: Film -> Video
[01:11:23] 5305.699219s: Video -> Film
[01:11:24] Sync: Video PTS discontinuity first (current buffer start=477515922, next buffer start=13211)
[01:11:25] Sync: Audio joined Video after discontinuity at PTS 3043
[01:16:01] hb_demux_ps: not a PS packet (0508c838)
[02:44:11] reader: done
[02:44:11] thread b00c5000 exited ("reader")
[02:44:22] 4125.751465s: Film -> Video
[02:44:23] sync: got 226112 frames, 231809 expected
[02:44:23] thread b0a31000 exited ("AAC encoder (libfaac)")
[02:44:23] thread b05fb000 exited ("MPEG-2 decoder (libmpeg2)")
[02:44:23] thread b08a6000 exited ("H.264/AVC encoder (libx264)")
[02:44:23] thread b06ff000 exited ("Renderer")
[02:44:23] thread b0928000 exited ("AC3 decoder")
[02:44:23] thread b05fb000 joined ("MPEG-2 decoder (libmpeg2)")
[02:44:23] thread b06ff000 joined ("Renderer")
[02:44:23] render: lost time: 0 (0 frames)
[02:44:23] render: gained time: 0 (0 frames) (0 not accounted for)
[02:44:23] fifo_close: trashing 0 buffer(s)
[02:44:23] fifo_close: trashing 0 buffer(s)
[02:44:23] thread b08a6000 joined ("H.264/AVC encoder (libx264)")
x264 [info]: slice I:3680  Avg QP:15.05  size: 32927  PSNR Mean Y:49.52 U:50.09 V:50.61 Avg:49.75 Global:49.16
x264 [info]: slice P:119673 Avg QP:17.17  size: 18057  PSNR Mean Y:47.13 U:48.06 V:48.61 Avg:47.45 Global:46.66
x264 [info]: slice B:102756 Avg QP:18.53  size:  6617  PSNR Mean Y:46.31 U:47.32 V:47.95 Avg:46.65 Global:45.86
x264 [info]: mb I  I16..4: 27.8%  0.0% 72.2%
x264 [info]: mb P  I16..4: 17.5%  0.0% 22.0%  P16..4: 22.5% 23.3% 13.6%  0.0%  0.0%    skip: 1.1%
x264 [info]: mb B  I16..4:  3.0%  0.0%  1.9%  B16..8: 40.7%  4.8%  6.5%  direct:23.3%  skip:19.7%
x264 [info]: final ratefactor: 15.57
x264 [info]: SSIM Mean Y:0.9876033
x264 [info]: PSNR Mean Y:46.797 U:47.761 V:48.343 Avg:47.124 Global:46.304 kb/s:2512.65
[02:44:23] thread b0928000 joined ("AC3 decoder")
[02:44:23] thread b0a31000 joined ("AAC encoder (libfaac)")
[02:44:23] thread b00c5000 joined ("reader")
[02:44:24] mux: file size, 3155470805 bytes
[02:44:24] mux: track 0, 2961987373 bytes, 2512.66 kbps
[02:44:24] mux: video bitrate error, +14928676 bytes
[02:44:24] mux: track 1, 188591169 bytes, 159.98 kbps
[02:44:24] mux: overhead, 7.32 bytes per frame
[02:44:24] thread b0579000 exited ("muxer")
[02:44:24] thread b0579000 joined ("muxer")
[02:44:24] fifo_close: trashing 0 buffer(s)
[02:44:24] fifo_close: trashing 0 buffer(s)
[02:44:24] fifo_close: trashing 0 buffer(s)
[02:44:24] fifo_close: trashing 1 buffer(s)
[02:44:24] fifo_close: trashing 1 buffer(s)
[02:44:24] fifo_close: trashing 0 buffer(s)
[02:44:24] fifo_close: trashing 0 buffer(s)
[02:44:24] fifo_close: trashing 1 buffer(s)
[02:44:24] fifo_close: trashing 11 buffer(s)
[02:44:24] Freed 6 buffers of size 512
[02:44:24] Freed 2 buffers of size 1024
[02:44:24] Freed 2048 buffers of size 2048
[02:44:24] Freed 0 buffers of size 4096
[02:44:24] Freed 0 buffers of size 8192
[02:44:24] Freed 36 buffers of size 16384
[02:44:24] Freed 0 buffers of size 32768
[02:44:24] Freed 65 buffers of size 518400
[02:44:24] Allocated 38485248 bytes of buffers on this pass and Freed 38485248 bytes, 0 bytes leaked
[02:44:24] thread b067d000 exited ("work")
[02:44:24] thread b067d000 joined ("work")
[02:44:24] libhb: work result = 0

[golias]

I'm getting similar problems, and experimenting to see if I can find a setting which avoids these problems.

I've been making new rips of Firefly with 9.3, and almost every episode I've done runs into this problem about 5 minutes in.

It never happened to me with 9.2, but I don't want to go back if I can avoid it because I ***LOVE*** the comb filter in 9.3, especially for my anime shows. Hopefully somebody knows what's going on here and how to avoid it.

[rhester]

Can you reproduce playing back the same frame range (say, 50 frames prior through the distortion) when using VLC as a player? Trying to determine if this is a QuickTime bug or a legitimate issue with x264.

Rodney

[golias]

Can you reproduce playing back the same frame range (say, 50 frames prior through the distortion) when using VLC as a player? Trying to determine if this is a QuickTime bug or a legitimate issue with x264.

Rodney

I can't speak for the guy who provided you the screenshot & log, but in my case I find that, while *some* of these bad lines and blocks don't show up when playing via VLC or Plex, most of them do. It seems that Quicktime sometimes displays a few MORE bad frames than other players do, but I suspect it has more to do with VLC being somehow more "fault tolerant" than Quicktime is.

Most of the glitches with my Firefly encodes (among others) show up regardless of what player I use, and regardless of whether I'm playing back in full-screen or in an "actual size" window.

If the other set of info at the top of this thread isn't enough for you to go on, I can do a re-encode of an episode and send you my data (and perhaps a screen-shot or two) when I can set some time aside to do so.

[rhester]

Well, if the OP confirms he sees this in VLC, the next thing I'd want to try is exactly the same encode minus PsyRDO.

Rodney

[golias]

Well, if the OP confirms he sees this in VLC, the next thing I'd want to try is exactly the same encode minus PsyRDO.

Rodney

Okay, after searching through the GUI features, the HB Wiki, the HB FAQ, the HB Forums and Google, I give up. What the heck is
PsyRDO and how to I go about removing it?

[rhester]

PsyRDO = psychovisual rate distortion optimization.

The basic concept is to leverage what we know about human perception to make encodes look 'better' even though they may not be as 'accurate'.

The advanced options string to disable both PsyRDO and PsyTrellis for experimentation purposes is "psy-rd=0,0".

Rodney

[golias]

PsyRDO = psychovisual rate distortion optimization.

The basic concept is to leverage what we know about human perception to make encodes look 'better' even though they may not be as 'accurate'.

The advanced options string to disable both PsyRDO and PsyTrellis for experimentation purposes is "psy-rd=0,0".

Rodney

Okay, I'm running an extraction using the "Constant Quality Rate" High Profile pre-set for the first three chapters of Firefly, episode 1 with "psy-rd=1,1" manually changed to "psy-rd=0,0". Let's see how it goes...

[rhester]

It's gotta be that or VAQ. If this shows the same problem, we'll try something else.

Rodney

[golias]

It's gotta be that or VAQ. If this shows the same problem, we'll try something else.

Rodney

Still getting ugly blocks during VLC playback for a few seconds, this time at about the 5:30 mark, lasting for 4 seconds (which is a completely different point than with the previous attempt).

So what are you suggesting I try with the "VAQ"?


... Okay, now this is weird.

I played back the test file in Quicktime, and while playback was mysteriously choppy, the block artifacts did not show up. With Plex, it played smoothly and also had no problem with those frames.

So I opened it in VLC again, this time skipping ahead to that scene and re-watching. It played back perfectly!

What the heck do you suppose is going on here?

[rhester]

How close did you get with the skip-ahead? It could be that you bypassed an I-frame that is gumming up the works.

Give this a try:

Under advanced options, in addition to the one you tried before, also include "aq-mode=0" and see if it makes a difference.

Rodney

[golias]

How close did you get with the skip-ahead? It could be that you bypassed an I-frame that is gumming up the works.

Give this a try:

Under advanced options, in addition to the one you tried before, also include "aq-mode=0" and see if it makes a difference.

Rodney

I jumped up to about 15 seconds before the glitch.

Trying the new setting out. I'll report back in a while.

[golias]

No weird blocks or lines via VLC this time (at least not in this five-minute sample), but playback did "skip" a couple times a minute (pausing both video and sound for a split-second and then continuing.)

If it helps to know, my gear is a 2.0 GHz core duo mini w/2GB of memory connected to a 720p projector, with the files stored on a 2-TB MyBook connected by Firewire. I'm using all the defaults of the "Constant Quality Rate" pre-set, with the exception of the two parameters you told me to change. I've got the latest & greatest versions of HB, VLC, Plex, and Quicktime currently installed.

[golias]

And once again, playing it with another app, then going back and playing it in VLC, it runs smooth as silk.

Now I'm pretty unsure of what's going on.

Anyway, adding "aq-mode=0" seems to have cleaned up those moments of blocky-ness. Should I experiment with leaving that there and setting the psy-rd back to 1,1?

[golias]

Back to 1,1. Setting aq-mode=0 seems to be the big difference-maker.

60 percent Constant Quality looks a little less than perfect on my big screen, though. I'm going to jack it up to 70 and try doing the full episode. See how it turns out.

[jzietman]

70 is WAY too high. Seriously, your encode will be huge. Try 62 first, then if you're absolutely sure that you can tell the difference between that and the source, try 64.

[golias]

Okay, here's the latest results:

With ":psy-rd=0,0:aq-mode=0" appended to the end of the Advanced Option string, MOST of this problem has cleared up, but I still end up seeing an occasional frame with some big blocks of video error.

Backing up and re-playing the scene still reveals them, as does playback in windowed mode instead of full-screen.

Also, (not really relevant to this issue) on a 720p projection system, a constant quality of 64 looks A LOT better than 60, at least to me. Compression artifacts (beyond those that were on the original DVD) have pretty much vanished. The picture is fabulous.

If only we could get to the bottom of these glitches.

(EDIT: Oddly enough, the glitch I caught on my latest test, at 6:08 on episode 2 of Firefly, shows up every time when playing back with Plex, but both Quicktime and VLC seem to be able to play it with no problem. However, if I were to play the file all the way through on those other players, I bet I would find errors in other spots. That seems to be how it's going with all of these rips. :/ What makes this surprising is that Plex has usually been the most robust of the three apps at playing without blocks of distorted video on most of the files I've tested with so far.)

[rhester]

At this point, I'm not really sure what to offer. It's possible that what you're looking at is further encoding problems with x264 itself, but it sounds equally likely that it is some sort of player compatibility issue. In any event, unless you can identify a specific test case where x264 output consistently produces a bad frame regardless of player *on the same frame*, the x264 group isn't too likely to look very hard at it.

Rodney

[golias]

At this point, I'm not really sure what to offer. It's possible that what you're looking at is further encoding problems with x264 itself, but it sounds equally likely that it is some sort of player compatibility issue. In any event, unless you can identify a specific test case where x264 output consistently produces a bad frame regardless of player *on the same frame*, the x264 group isn't too likely to look very hard at it.

Rodney

I understand, but the fact remains that I've yet to encode an episode of anything free of these issues with HB 0.9.3, regardless of what player I use for playback.

If you were able to say "use this app for playback" and it would resolve all these issues, I'd probably move to using whatever player you recommended full-time (or try to find ways of fixing playback on my platform of choice), but this is a problem which happens regardless of what player I use, so that's a difficult answer to accept.

As much as I hate doing so, I don't see much choice but to go back to using 0.9.2, unless somebody can think of some other setting tweak that might solve these problems. I'm more than happy to keep experimenting if anybody has any suggestions.

[jbrjake]

As much as I hate doing so, I don't see much choice but to go back to using 0.9.2, unless somebody can think of some other setting tweak that might solve these problems. I'm more than happy to keep experimenting if anybody has any suggestions.

No one can suggest settings tweaks because you haven't even produced an activity log of one of the problem encodes. All we have is information from the original poster.

[golias]

As much as I hate doing so, I don't see much choice but to go back to using 0.9.2, unless somebody can think of some other setting tweak that might solve these problems. I'm more than happy to keep experimenting if anybody has any suggestions.

No one can suggest settings tweaks because you haven't even produced an activity log of one of the problem encodes. All we have is information from the original poster.

I can do so if you think it will be helpful, but I'm starting to suspect it's a glitch with the video card on the mini itself. I'm going to try playing some of these "bad" files through other hardware, and see what the result is.

If that's not it, I'll do another rip and save the log file to post here.

[jbrjake]

I can do so if you think it will be helpful

A log is always helpful.