[FFmpeg-user] 2 pass encoding with hevc_nvenc

[Peter White]

04.09.2016 13:01, Carl Eugen Hoyos:
 > 2016-09-04 12:52 GMT+02:00 Peter White <peter.white at posteo.net>:
 >> 04.09.2016 12:21, Carl Eugen Hoyos:
 >
 >>>> i am trying to encode with a variable bitrate, 2 pass encoding
 >>>
 >>> How is this supposed to work (in a general sense, unrelated
 >>> to a codec or an implementation)?
 >>> Two-pass encoding indicates constant bitrate afaict.
 >
 > This should have been "average bitrate" which is not
 > the same as variable bitrate.

Agreed, average bitrate is the better term. I'd say it is closely
related to variable bitrate, tough. The bitrate *is* variable in both
modes after all, the only difference is that with ABR you can predict
the average bitrate and hence the resulting file size.

 >> No, it does not. If each frame got the same bitrate, which
 >> is the definition of constant bitrate (CBR)
 >
 > No, the actual definition of cbr (for mpeg-2 video or h.264)
 > is very difficult and cannot be part of a short email.

Interesting, I will read up on that, thanks for the hint.

 > (But using cbr with two-pass encoding makes not much
 > sense, I believe we agree on that.)

We definetly do.

 > If you don't want an average (but a variable) bitrate, I don't see
 > how two-pass encoding can help.

To be honest, I don't either, but x264, for example, does allow
to use CRF in the 1st pass. I have seen an example somewhere, a long
time ago, so I cannot say if I remember it correctly.
But it went like this: 1st pass in CRF, supply the "pass" parameter so
the log gets written as well. After the 1st pass one has a usable CRF
encoded file.  And if one wants, one can use the log from the 1st pass
and run a 2nd pass. If one then specifies the same bitrate the 1st
pass in CRF mode produced, the quality is supposed to be even better.
If the file size does not suit one's needs, simply adjust the bitrate
for the 2nd pass.
But I never saw the point of running two passes to improve the quality
of a file encoded with CRF mode. The quality improvement must be very
small, I reckon. But the encoding time doubles--not worth it.


Peter