First pass file reuse

[schubi]

W7 64Bit - HB 0.10.5.0 64bit

No real problem, but questions belonging to the first pass.

The question comes from the moment, when I had to convert the same file again due to some
not cutted green lines in the finished mkv movie file.
(I searched for answers in google and in this forum and could not find one, hope its not double asked...)

So I would like to know:

1. Is it possible and how can I use the first pass file again (because it could be used again for the same
movie with the same settings and even within some changed settings)

2. Where is the first pass file stored? (I could not find it and in the queue there is only written the film.mkv as destination).

It would save a lot of time and computer power if you could help me by that.

Best regards and go on with this great software!
schubi

[Woodstock]

First pass doesn't do much except build statistics to make decisions; it is NOT stored.

[rollin_eng]

I'm not sure what use this would be, if you change your video settings then the first pass would change, if you don't change the video settings then HB is not really the right tool.

[schubi]

But if I look at the length of its time needed, it could be rather shorting a second or third
2-pass conversion...
Up to now I compare it with the 1st pass of e.g. VirtualDub or similar.
So I think, if I just change e.g. the crop from left side from 32 to 34 to get away a green line, there should be
no difference in the first pass.

[rollin_eng]

If you change the cropping, you will change the video to be encoded thus the stats will be different.

[Woodstock]

The part of handbrake that does the encoding does NOT hang on to anything from a previous encode - each is "stand alone".

If you're worried about adjusting parameters before a final encode, you SHOULD consider encoding just PART of the video, to make sure the cropping is "just so", before unleashing the "final, for sure this time (I think)" encode. Short encodes/inspections take a lot less time than full ones.

And you really only need two-pass when you're trying to hit a target bit rate - and, as rollin_eng points out, that is going to change with different cropping.

[schubi]

"The part of handbrake that does the encoding does NOT hang on to anything from a previous encode - each is "stand alone". "
Besides from first pass

As far I understood it, first pass is taken to optimize the given bitrate on the scenes as they will come,
so it looks at the source.
This should be the same in "Handbrake" or isn't, then I am wrong and understand your argue.

The look at the first pictures of the new video is also earliest possible after the first pass and first pass often lasts
similar time as second pass or is not much shorter.

Yes, I am targeting at the bit rate because I want to get the maximum present quality without going
into not present quality.

Ok, thanks for answering!

[rollin_eng]

Obviously the first pass statistics have to be stored somewhere but I'm not sure the devs will want to allow users to access them.

If you want the best quality encode you should be using CQ encoding rather than 2 pass.

[mduell]

"The part of handbrake that does the encoding does NOT hang on to anything from a previous encode - each is "stand alone". "
Besides from first pass

Nope.

As far I understood it, first pass is taken to optimize the given bitrate on the scenes as they will come, so it looks at the source.
This should be the same in "Handbrake" or isn't, then I am wrong and understand your argue.

You are wrong. The first pass changes depending on any change in pre-encoder settings, like cropping or filtering.

The look at the first pictures of the new video is also earliest possible after the first pass and first pass often lasts similar time as second pass or is not much shorter.

I'm not sure what this word salad is trying to say.

Yes, I am targeting at the bit rate because I want to get the maximum present quality without going into not present quality.

You are confused. You're wasting bits and/or degrading quality on just about every code.

[schubi]

"The part of handbrake that does the encoding does NOT hang on to anything from a previous encode - each is "stand alone". "
"Besides from first pass "
"Nope."
???
If first pass is not needed, what is it done for?

"I'm not sure what this word salad is trying to say."
Ok.

"You are confused..."
I for sure know, that I am loosing quality on each conversion.

But your answers, especially your "Nope." make not much sense to me.
So I do not see much sense to go on with this conversation...

And if the cropping of the destination file changes the parameters for the reading of the source file,
there is a big bug/error inside the program.

And sorry for my English!

Best regards
schubi
(Software engineer VB6, ABAP, Java, C#)

[whistlerz]

Just a side suggestion if you want to quickly verify your crop settings and not waste time encoding (even doing a small test encode)...

Using MPV, downloadable here: https://mpv.io/installation/

Code: Select all

mpv --no-audio --vf "lavfi=[drawbox=x:y:w:h:invert:t]" "SOURCE FILENAME.EXT"
   x:y = offset coordinates from top left for box
   w:h = width and height of the box
   t = thickness of inverted line

Example:
mpv --no-audio --vf "lavfi=[drawbox=0:138:1920:804:invert:10]" "Movie (2017).mkv"

In Handbrake crop settings: left = x, top = y, right and bottom = do the math to get the desired width and height.

That will play the source file with an inverted box drawn on the inside edge of your desired crop, allowing you to tune in your exact crop before running any encodes or first passes or anything.

[Woodstock]

The reason for the question in the first place was to deal with some artifacts (green lines) introduced by the encoding process. Does mpv duplicate the same artifacts to give accurate numbers for the original poster?

[whistlerz]

The reason for the question in the first place was to deal with some artifacts (green lines) introduced by the encoding process. Does mpv duplicate the same artifacts to give accurate numbers for the original poster?

Nope, just an open source player that happens to do a few things I find useful in my workflow. But...

But if I look at the length of its time needed, it could be rather shorting a second or third
2-pass conversion...
Up to now I compare it with the 1st pass of e.g. VirtualDub or similar.
So I think, if I just change e.g. the crop from left side from 32 to 34 to get away a green line, there should be
no difference in the first pass.

If cropping was the problem (i.e. if the green lines are in the source and need to be cropped out), it seemed like it could be a helpful tip to nail the crop beforehand. Sorry for the diversion if that's not the case.

[rollin_eng]

And if the cropping of the destination file changes the parameters for the reading of the source file,
there is a big bug/error inside the program.

The cropping is done on the read side as you are telling the encoder to ignore those bits

[schubi]

Sorry, after a few months I can state:
This software is not much more than a Laptop heater, because the developers are not able to put
several prozesses into several steps, where one could reuse like for example the 1.pass information,
if 1.pass has been passed and nothing is changed, either the mkv source nor the settings!
*thumb down*

Other teams of developers has been able to do so (for example VirtualDub/Mod)...!

[rollin_eng]

That's a bit harsh.

HB is a very good video encoder, just because it doesn't do one thing that you want doesn't make it bad.

You have also not really explained what use keeping the 1st pass statistics does, as has been said if you change any video encoder settings your stats will change.

As you stated earlier you are a software engineer, you should have no problems looking at the source code and adjusting it to your needs.

[mduell]

With fast first pass this would save like 10% on encoding time?

[schubi]

To remember:
This discussion started, because I asked, where HB stores the results of the
first pass to reuse it and I got told, this is not stored because its needed
to generate again...

And I say:
If you make a first pass, it has nothing to do with the settings for the second pass!
You make a video analysis of what you have (from the mkv as source),
not for the result you want to!
So it saves really a lot of time and heating of the CPU and more... if you can reuse
the first pass for any second pass of your 2pass conversion.
And if the first pass is needed each time again if you run a conversion for the same
movie (maybe to optimize the result), then something is basically done wrong,
because you could have saved the results from first pass.
And VD/VDM does it, StaxRip does it, so there is nothing to say anymore.
I put this software to trash (by the way have a better understanding for its name)
and that´s it.
Thanks

[mduell]

The myopia is strong with this one.

[Woodstock]

If you're worried about handbrake overheating your laptop, why are you running such a CPU-intensive application on a device with marginal cooling?

As has been explained to you, if you change the settings between runs, the "first pass" from the previous run would be invalid for the current run. Saving it would simply take up storage space.

If you are NOT changing things, why did you stop the first encode?

[JohnAStebbins]

The only way you can re-use the first-pass file on subsequent encodes is if you do not change any settings that affect first-pass results. Do you know what settings will change first-pass results? There are very few settings you can change that *will not* change the results.

Yes, you can use VirtualDubMod manually in StaxRip to reuse the first pass. But this will allow you to reuse a first pass that is invalid for the settings you are using for your second pass. Garbage in garbage out. StaxRip does nothing to protect you from doing something stupid in this scenario.

Rather than let the user create garbage files (or run a second pass that fails on the final frame, which I *have* seen happen), HandBrake ensures that you use a valid first-pass file every time by running the first pass with your current settings every time.

If you know what settings will change first pass results and require the ability to reuse first pass results, then HandBrake is not the tool for you (unless, as others have pointed out, you wish to modify HandBrake yourself).

[Woodstock]

To the original poster: Do you HAVE to encode the ENTIRE file to determine if your settings are incorrect?

I would think encoding a couple of minutes would be enough to determine that the cropping needed adjusting, or a different film tune is needed.

The reason for doing a two-pass encode is (usually) to hit a target bit rate. When the bit rate isn't a limiting factor, using 1 pass and constant quality would be significantly faster than wondering how to save a first pass result.

In your original post, you listed reasons you might need to re-run the encode. Every one of them would invalidate the first pass information, starting with the different crop affecting the bit rate being calculated in the first pass. Forgot the source was interlaced? Any de-interlace setting changes the bit rate.