topic Hey Mark, any luck with the in Media (Intel® Video Processing Library, Intel Media SDK)

2 Pass Encoding?

Dan_Haddix — Fri, 25 May 2012 06:22:40 GMT

Does the QuickSync encoder support a two pass mode? I've looked through the docs and I don't see anything about it. However I talked to the people at Main Concept and they said their QuickSync encoder does do two pass so it would seem it's possible. Are they doing something completely custom? Or am I missing something in the Media SDK?

Thanks,
Dan

2 Pass Encoding?

Anthony_P_Intel — Fri, 25 May 2012 18:17:11 GMT

HI Dan,

Yes, the Intel Media SDK supports a variety of algorithms for Rate Control. AVBR (Average Variable Bitrate) was added to API 1.3 (supported by Media SDK 2012). This is the mode that some applications refer to as 2 pass encoding. Please see the Media SDK Reference Manual for information on how to use this mode.

-Tony

2 Pass Encoding?

Dan_Haddix — Mon, 28 May 2012 20:20:52 GMT

Does the AVBR mode require you to feed the samples in twice, like a typical 2 pass encode where the first pass creates a stats file and the second pass creates the actual encoded frames?

The documentation on AVBR is very limited in the SDK

Dan

2 Pass Encoding?

Anthony_P_Intel — Tue, 29 May 2012 17:13:19 GMT

Hi Dan,

Sorry I was not clear with my post. The Intel Media SDK does not support "2 pass encoding" in the sense that it does not examining the entire stream twice. When the AVBR encode mode is used the encoding algorithm tries to achieve some of the same goals achieved with typical 2 pass encoding (which is why I believe some applications call it "2 pass", but the usage of Media SDK for AVBR is the same as other encoding models (as long as the initial encode parameters are setup correctly).

In other words, there is no API for using Media SDK with 2 passes.

-Tony

I would like to use Intel

zzz_z_ — Mon, 19 Sep 2016 18:46:00 GMT

I would like to use Intel Haswell QSV for 2 pass video encoding. I do realize that it is not doable in one click scenario.

What I think about is to run software 1st pass which is fast enough (in my case using ffmpeg). This task results with .mbtree stats file which basically carries data of information density of input video (or in English info on how to distrubute bitrate most efficiently depending on scene complexity). Then I would like to run h264_qsv 2nd pass with .mbtree file as input of required data distribution to haswell encoder.

When I do as described above, it doesn't really matter if I mention -pass 2 parameter in command line (to inform that ffmpeg should use the stats file for bitrate selection). Output files have the same md5 sums (with and without -pass parameter).

Any idea if it is even possible for QSV?

Thanks, Andrzej

Hi Andrzej,

Mark_L_Intel1 — Thu, 22 Sep 2016 00:16:00 GMT

Hi Dan,

What are you going to use the .mbtree file? I think your goal is to keep a flat bit rate and tweak the parameter for each frame.

Mark

I would like to you take a

zzz_z_ — Fri, 23 Sep 2016 18:02:00 GMT

I would like to you take a look at the two pictures below. They show bitrate distribution in a test video material.

1. x264, 2pass encoded, 4500kbps average bitrate

2. QSV ABR, 4500kbps

As you surely noticed, the QSV video output has pretty much constant bitrate. That means that encoder does not provide enough bitrate in most complex scenes and provides more than enough bitrate for simplier scenes (like low-motion). As a result a viewer could tell which video is lower quality, even though the two have pretty much the same average bitrate for entire file (435MB total for x264 file and 434MB for qsv).

That's because QSV only takes a number of consecutive frames (defined by look_ahead param) and it is not aware of the complexity of entire input material.

What I'd like to do it to provide this information about entire movie complexity to QSV encoder (we get this information by running 1st pass on video and it sits in .mbtree file, software way) so that it will be able to generate file with bitrate distribution very close to what I observe in x264 case. It is possible?

Hi Dan,

Mark_L_Intel1 — Fri, 23 Sep 2016 23:32:37 GMT

Hi Dan,

I understand more on your requirement now, I think there is a possibility for this requirement. Basically the current software has a FFmpeg wrapper which allows MSDK plugin to the FFmpeg framework, I will try some test to see if the 2 pass encoding can be done.

Give me sometime and I will get back to you soon.

Mark

Hey Mark, any luck with the

zzz_z_ — Tue, 11 Oct 2016 13:25:48 GMT

Hey Mark, any luck with the solution?

Yes, my plan is:

Mark_L_Intel1 — Wed, 12 Oct 2016 23:32:31 GMT

Yes, my plan is:

1. Confirming the ffmpeg 2 passes command sequence, try to uses the 2 pass process to improve the bitrate.

2. Use Media SDK wrapper to the ffmpeg to see if it can do the same work.

I have completed #1 although I didn't see the bitrate get improved; but I think this is not important for now. I will the Media SDK wrapper and see if it can do 2-pass process.

I will give you update soon.

Mark

Hi,

Gilles_V_ — Mon, 14 Nov 2016 22:41:45 GMT

Hi,

I am really interested in your outputs.

I tried to run a 2 pass encoding using FFMPEG 3.2, with both h264_qsv decoding and encoding.

It does not really look like to do the 2 passes as I have the same result as if I did 1 pass ..

Can you pleas share your cmd lines ?

Thanks

Hi, for purpose of this post

zzz_z_ — Tue, 15 Nov 2016 19:21:00 GMT

Hi, for purpose of this post i have used ffmpeg build N-81508-g99882d0.

For starters, let's make it really clear. I don't mind you using the qsv decoder, but this has nothing to do with the topic. Let's focus on qsv encoder only.

You're right, 2 pass encoding with h264_qsv does not work. That's the whole thing. I imagine that Intel has not implemented this functionality. There's not a single program that's capable of real 2pass encoding with intel qsv. The closest to the truth is MediaCoder which clearly states that functionality has not been implemented yet (when setting qsv with 2pass encoding).

I made two examples to make it clear.

I used a sample test video file, then executed first pass on it, to collect information on video complexity (log files present after running 1st pass, to be used later):

ffmpeg -y -i testfile.mp4 -c:v libx264 -preset slow -pass 1 -passlogfile logs.log -f mp4 /dev/null ( <-- NUL for windows versions)

For usage examples, please refer to: https://trac.ffmpeg.org/wiki/Encode/H.264

Then I executed 2nd pass:

1. ffmpeg with software libx264, 2nd pass:

ffmpeg -i testfile.mp4 -c:v libx264 -preset slow -b:v 2500k -pass 2 -passlogfile logs.log -c:a copy testfile_ffmpeg_libx264_2pass_2500k_avg.mkv

As you can see, software 2 pass does work good.

2. ffmpeg with hardware h264_qsv, 2nd pass:

ffmpeg -i testfile.mp4 -c:v h264_qsv -preset slow -b:v 2500k -pass 2 -passlogfile logs.log -c:a copy testfile_ffmpeg_h264_qsv_2pass_2500k_avg.mkv

Looks like qsv does not take log data into consideration. That's what we would like to accomplish.

Hi, any progress on that one?

zzz_z_ — Wed, 14 Dec 2016 06:53:11 GMT

Hi, any progress on that one?

Re: Hi, for purpose of this post

wyup — Mon, 25 Jan 2021 12:24:26 GMT

According to this , you can use -look_ahead 1 and -look_ahead_depth 100 to enable VBR algorithm to a certain extent. It 'might' help with the second pass.