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.
auto-crop not re-setting when loading a new source
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.
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.
Re: auto-crop not re-setting when loading a new source
Does it behave any better with a nightly build?
Re: auto-crop not re-setting when loading a new source
I'll try to download some of the prior builds, as well as newer nightly builds, and see which versions show this issue.s55 wrote:Does it behave any better with a nightly build?
Re: auto-crop not re-setting when loading a new source
Please don't bother with old builds, unless s55 specifically asks for it. It's either fixed in the nightlies, or it's not.
Re: auto-crop not re-setting when loading a new source
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.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.
Re: auto-crop not re-setting when loading a new source
Current nightly build (5838) had no trouble here. It updated auto-cropping values for each new source.
Re: auto-crop not re-setting when loading a new source
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).
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).
Re: auto-crop not re-setting when loading a new source
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.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).
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.
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.