Large Blocking

[Revenent]

As of this post, it has not been checked into SVN yet... it won't appear in a nightly until the change has been checked in.

And no, I don't know when that will happen.

Will the change logs show when the new drop will go in?

[handbrakeuser2011]

I don't know when they'll finally bump FFMPEG, but if changeset 3760 is anything to go by it may be relatively soon if they are making changes to allow Handbrake to potentially work with the latest FFMPEG.

[Deleted User 11865]

We're still waiting on another fix before updating to the latest FFmpeg.

[handbrakeuser2011]

We're still waiting on another fix before updating to the latest FFmpeg.

What exactly is the fix still needed before FFMPEG is updated?

[Deleted User 11865]

It's another H.264 decoding fix, unrelated to this issue but it still makes sense to include it. An FFmpeg bump requires a certain amount of testing, so it's not something we do every week.

Also, this issue and your issue are unrelated.

[handbrakeuser2011]

It's another H.264 decoding fix, unrelated to this issue but it still makes sense to include it. An FFmpeg bump requires a certain amount of testing, so it's not something we do every week.

Also, this issue and your issue are unrelated.

I am still awaiting this fix as I hope it may fix the problem.

[Deleted User 11865]

I am still awaiting this fix as I hope it may fix the problem.

It won't. One of the first things I did with your sample was to test it against the latest FFmpeg (with the fix for this thread's issue), and it made no difference.

[weaver4]

So is the temp solution to disable b-pyramid on the Windows Version?

What ramifications does this have?

[s55]

Probably a slight increase in filesize for a given quality level.

For those who are going to constantly ask if it's been checked in. Don't. ffmpeg will be bumped when a number of issues are fixed. The current head has more issues than the previous builds so I wouldn't expect this to be resolved for a few weeks.
Trac shows all changes. Monitor that.

[Deleted User 11865]

So is the temp solution to disable b-pyramid on the Windows Version?

What ramifications does this have?

No. The only workaround for this particular issue is to use an older version of HandBrake.

[DFXThomas]

Does anyone know where to get the latest macintosh build without this problem (svn3598) ?
I am hestitating to go back all the way to 0.9.4... but 0.9.5 and the newest nightly are affected .

P.S. Nevermind ... found it in my downloads folder. Sometimes it's a good thing not to clean it up...

[Deleted User 11865]

Updated patch for the impatient

http://paste.handbrake.fr/pastebin.php?show=2100

[flapp3rs]

Updated patch for the impatient

http://paste.handbrake.fr/pastebin.php?show=2100

Sounds pretty good! But for the not so technical educted

What does that mean for me? Can i get a Windows binary that does not have that ffmpeg bug? Link?

If not: which old/nightly version with passthrough support for ac3 and dts can i use without this problem? Can someone provide a link to download?

Sorry, if this questions are silly, maybe it's just me

Thanks in advance!

[s55]

@flapp3rs - the patch has to be compiled into the source code. If your not comfortable compiling software, you'll have to wait for it to be checked in and then you'll be able to grab a nightly build

[flapp3rs]

@flapp3rs - the patch has to be compiled into the source code. If your not comfortable compiling software, you'll have to wait for it to be checked in and then you'll be able to grab a nightly build

Ok, i understood Thanks for claryfing this!I'am not able to patch and comile this.

Can someone reply to the 2nd part? Which compiled win binary can i use and download with ac3 and dts (or only ac3) passthrough. Older nigtly build without that bug? Which version is capble? I read svn3555 in this thread. Where can i get that?

Thanks in advance!

[JohnAStebbins]

We just bumped ffmpeg. So the next nightly build should fix this issue.
https://trac.handbrake.fr/changeset/3779

[flapp3rs]

Awesome

Thank you very much!

[Revenent]

It's an FFmpeg decoding bug. The issue shows up in HandBrake's static previews (though you couldn't see this in the WinGUI since it doesn't feature static previews), VLC 1.1.5 and MPlayer OSX Extended r14 (FFmpeg "r32568").

Edit: it seems that the cause of the bug is some assembly code introduced in FFmpeg svn-r25361 (does not occur when FFmpeg is compiled with --disable-asm). The issue is still present in the latest FFmpeg (svn-r26323).

The last version of HandBrake to work with your file is svn3598.

Sorry, silly newb here - are we talking about the playback software's decoder or the decoder in HB that decodes the source to something it can compress?

Edit: I have the same issue as well (http://forum.handbrake.fr/viewtopic.php?f=11&t=19495).

I just tried the last nightly build - no more artifacts in the section that I had before. I am doing a full encode to see if it is gone from the other areas as well.

[Revenent]

OK, did a full encoding. When I played it within Media Center, it had artifacts in the credits, but that was probably due to the fact that it was using FFMpeg, and it might still be affected.

When I play it with Media Player Classic - Home Cinema, no artifacts from those sections.

I think we're good to go on this one.

[weaver4]

I am still having some blocking with the latest build.

It appears to be less, but I see these artifiacts about every 10 minutes.

Same content encoded by HB on my mac has no problem.

[Deleted User 11865]

Start a new topic and provide the required information. This is not the same issue.