Derive target bitrate from target quality by analyzing source video

[CryGuy]

Hi,

I'm using AviDemux and it's Nvenc H.264 encoder. However, there's no target quality mode offered like it is with the x264 encoder (crf mode). Instead, I must specify a bitrate. The problem is that I do not know the bitrate because it mainly depends on how much motion is taking place in the source video. So I'm looking for a way to have the source video analyzed, while passing a target quality (like crf) to this process. In the best case, the process outputs the target bitrate that is required to achieve the desired quality. Can this analyzation run be done with ffmpeg or another program?

Thanks

[KarMa]

Nvenc supports constQP, similar to CRF just the qp doesn't vary at all.
https://superuser.com/questions/1296374/best-settings-for-ffmpeg-with-nvenc

[CryGuy]

Nvenc supports constQP, similar to CRF just the qp doesn't vary at all.
https://superuser.com/questions/1296374/best-settings-for-ffmpeg-with-nvenc

Yes. I know. Using ffmpeg, I could even specify the -cq argument which is even exactly what I need.
But this does not help as I said: I'm using AviDemux. I have to enter a bit rate there. That's why I've asked how can I have a video analyzed by specifiying a quality value, and it outputs the bitrate required to achieve that quality (approximately).

[jagabo]

Haven't you answered your own question? Use ffmpeg with CQ, then AviDemux at whatever bitrate that gives. If you must do it all in AviDemux, encode with x264, veryfast, CRF. Then use 50 percent more bitrate than that delivers.

But in the end, it still won't deliver as good quality. Because single pass bitrate encoding can't give as good bitrate distribution as CQ encoding. You need multipass bitrate encoding to do that.

[CryGuy]

Don't know how I could have answered my own question. I explained why the reply before does not help and what is my goal and why. Your suggestion would be possible, but I'd like to have it analyzed once, then transcoded once, but not transcoded twice.

Anyway, my thinking was wrong regarding that I'd first have to cut the video before peforming that analyzation run. Though, it would be possible if I'd 1. cut it, 2. Nvencode it with 50 Mbit/s, 3. Have the video analyzed, 4. perform the final transcoding. But these were even three runs, hence it's not an option because it would be even more complicated than before. So I'll simply stay with x264 crf encoding.

Thanks

[jagabo]

I'd like to have it analyzed once, then transcoded once, but not transcoded twice.

The only way to know what bitrate is required is to encode the video. So you have to encode once with constant quality then encode with AviDemux's NVEnc at that resulting bitrate.

There was program long ago (I don't remember the name but it was back in the Xvid/Divx days) that would encode about 5 percent of the source video with CQ, sequences of about 100 frames spread throughout the length of the movie. From that it would get an idea what bitrate was needed. It would then encode the entire movie at that bitrate. That's not perfect because it's always possible it happened to sample mostly quiet sections and missed all the action sections, of vice versa. But it usually worked fairly well. AviDemux doesn't have that ability.

And like I said, single pass bitrate encoding can't have as good bitrate distribution as single pass CQ encoding so encoding at the same bitrate will not deliver the same quality. Here's an extreme example with a video that has a still frame for about 600 frames, 600 frames of normal motion, still for 600 frames, motion for 600 frames, a total of four cycles. The CQ encoding looks like:


[Attachment 49891 - Click to enlarge]

The single pass bitrate encoding (it overshot the requested bitrate by a bit):


[Attachment 49892 - Click to enlarge]

That was done with x264 but you'll see the same sort of problem with nvenc. The CQ encoding has a pretty flat distribution in the full motion sections. But the single pass bitrate encoding overshoots at the start of those sections (delivering higher quality per frame) then the bitrate drops until it's delivering lower quality per frame.

[manono]

There was program long ago (I don't remember the name but it was back in the Xvid/Divx days) that would encode about 5 percent of the source video with CQ, sequences of about 100 frames spread throughout the length of the movie.

I believe you're referring to AutoGK's compression test. It used AviSynth's SelectRangeEvery to choose the 5% of the video to encode, and then allowed for the forced keyframes added by all the cutting to come up with a recommendation. It worked pretty well and the OP could rig up his own compression test to do the same. However, it's trying to put a round peg into a square hole. The obvious answer is if one tool can't do the job, change tools. There's no reason in the world to use AviDemux. I've managed to live my life without ever installing it to any computer.