auto-crop not re-setting when loading a new source

HandBrake for Windows support
Forum rules
An Activity Log is required for support requests. Please read How-to get an activity log? for details on how and why this should be provided.
Post Reply
TimmyC
Posts: 13
Joined: Sun Jan 31, 2010 7:30 pm

auto-crop not re-setting when loading a new source

Post by TimmyC »

Thanks for all the work on Handbrake. It's an excellent program and I really appreciate it.

recently, Handbrake has not been re-setting the automatic crop when I load a new source.
In the past, after loading a new source I would get Handbrake to re-set the automatic cropping values by clicking back-and-forth between presets. But in recent weeks this has not worked.

This is only a problem when I add consecutive items to Handbrake's queue, without closing Handbrake. If I close Handbrake and re-open the program, it then gives correct auto-cropping values for the source.

This may be a known issue, or there may be an easy fix, but the behavior of the program is changed from some prior versions. I don't know how long this has been happening, but I suspect it is a fairly recent development. I have Handbrake set to auto-update, and am currently on 0.9.9.5530, 64-bit.
Note that I am only encoding from DVD source.

I have replicated this behavior on Win8 and Win7 computers (both x64, running Handbrake 0.9.9.5530).

I am uploading the logfiles for two DVD's I encoded back-to-back (without closing Handbrake before loading the second). The first DVD has a (correct) auto crop from 720 to 712. The second DVD should have no horizontal cropping, but also came in at 712 because settings from the first DVD carried over.

First DVD:
http://pastebin.com/6qRjUTDZ

Second DVD:
http://pastebin.com/YRs2tQ6Q


For now, if I am encoding multiple movies consecutively, I can add one to the queue, exit handbrake, re-open Handbrake (and keep the items recovered from the queue), load a new source, and this way I can get the proper automatic cropping for the 2nd source.
User avatar
s55
HandBrake Team
Posts: 10350
Joined: Sun Dec 24, 2006 1:05 pm

Re: auto-crop not re-setting when loading a new source

Post by s55 »

Does it behave any better with a nightly build?
TimmyC
Posts: 13
Joined: Sun Jan 31, 2010 7:30 pm

Re: auto-crop not re-setting when loading a new source

Post by TimmyC »

s55 wrote:Does it behave any better with a nightly build?
I'll try to download some of the prior builds, as well as newer nightly builds, and see which versions show this issue.
Deleted User 11865

Re: auto-crop not re-setting when loading a new source

Post by Deleted User 11865 »

Please don't bother with old builds, unless s55 specifically asks for it. It's either fixed in the nightlies, or it's not.
TimmyC
Posts: 13
Joined: Sun Jan 31, 2010 7:30 pm

Re: auto-crop not re-setting when loading a new source

Post by TimmyC »

Rodeo wrote:Please don't bother with old builds, unless s55 specifically asks for it. It's either fixed in the nightlies, or it's not.
all right. I was curious when the issue began, but you're right that the first thing to check is whether it's a problem going forward. I'll test this with nightly build(s) tomorrow and get back to you.
TimmyC
Posts: 13
Joined: Sun Jan 31, 2010 7:30 pm

Re: auto-crop not re-setting when loading a new source

Post by TimmyC »

Current nightly build (5838) had no trouble here. It updated auto-cropping values for each new source.
Deleted User 11865

Re: auto-crop not re-setting when loading a new source

Post by Deleted User 11865 »

Cool. 0.9.9 is too far behind though, so this won't be backported - you'll have to use the nightlies until the next release.

Note that the crop values were not wrong in the encode, as --crop was not added to the CLI query when autocrop was on (so the actual, correct autocrop values were used for the encode).
TimmyC
Posts: 13
Joined: Sun Jan 31, 2010 7:30 pm

Re: auto-crop not re-setting when loading a new source

Post by TimmyC »

Rodeo wrote:Cool. 0.9.9 is too far behind though, so this won't be backported - you'll have to use the nightlies until the next release.

Note that the crop values were not wrong in the encode, as --crop was not added to the CLI query when autocrop was on (so the actual, correct autocrop values were used for the encode).
I did some more checking on the encoded videos. What is happening is not the cropping itself, but rather the incorrect auto-crop values are being used to resize/scale the output video.
Here is a representative example. I'm attaching screen shot of Yamb, showing the apparent-cropped picture size, compared to an encode without erroneous auto-crop values.
Image
I'm also attaching screenshots from approx the same spot in both encodes of the movie, and while both contain the full-sized image (no cropping), the "cropped" version is simply scaled smaller.
Image
Image
Post Reply